diff --git a/Makefile b/Makefile
index 006b2c63..d5e17a24 100644
--- a/Makefile
+++ b/Makefile
@@ -264,7 +264,7 @@ generate-config-reference: build
LAYOUT_NOTICE_END="{{% /notice %}}" \
LAYOUT_HINT_START="{{% notice hint %}}" \
LAYOUT_HINT_END="{{% /notice %}}" \
- LAYOUT_UPLINK="[go to top](#topbar)" \
+ LAYOUT_UPLINK="[go to top](#reference)" \
$(abspath $(BINARY)) generate --config-reference > $(CONFIG_REFERENCE_DIR)/index.md
syslog:
diff --git a/docs/config.toml b/docs/config.toml
index 9e7f1e2d..e906a63c 100644
--- a/docs/config.toml
+++ b/docs/config.toml
@@ -7,7 +7,7 @@ publishdir = "../public/"
# For search functionality
[outputs]
- home = [ "HTML", "RSS", "JSON"]
+ home = [ "HTML", "RSS", "SEARCH", "SEARCHPAGE"]
[params]
# Change default color scheme with a variant one.
@@ -30,3 +30,22 @@ publishdir = "../public/"
identifier = "resticdoc"
url = "https://restic.readthedocs.io/"
weight = 30
+
+[markup]
+ [markup.highlight]
+ # line numbers in a table layout will shift if code is wrapping, so better
+ # use inline; besides that visually both layouts have the same look and behavior
+ lineNumbersInTable = false
+
+ # if `guessSyntax = true`, there will be no unstyled code even if no language
+ # was given BUT Mermaid and Math codefences will not work anymore! So this is a
+ # mandatory setting for your site if you want to use Mermaid or Math codefences
+ guessSyntax = false
+
+ # the shipped variants come with their own modified chroma syntax highlightning
+ # style which is imported in theme-relearn-light.css, theme-relearn-dark.css, etc.;
+ # if you want to use a predefined style instead:
+ # - remove `noClasses` or set `noClasses = true`
+ # - set `style` to a predefined style name
+ noClasses = false
+ # style = "tango"
diff --git a/docs/content/_index.md b/docs/content/_index.md
index dbc1bf68..ec84b472 100644
--- a/docs/content/_index.md
+++ b/docs/content/_index.md
@@ -1,3 +1,6 @@
+---
+archetype: "home"
+---
# resticprofile
Configuration profiles manager for [restic backup](https://restic.net/)
diff --git a/docs/content/configuration/_index.md b/docs/content/configuration/_index.md
index 59490080..5904ddde 100644
--- a/docs/content/configuration/_index.md
+++ b/docs/content/configuration/_index.md
@@ -1,20 +1,18 @@
+++
-chapter = true
+archetype = "chapter"
pre = "2. "
-title = "Configuration"
-weight = 10
+title = "Configuration file"
+weight = 2
+++
-# Configuration file
-
* A configuration is a set of _profiles_.
* Each profile is in a new section that has the name of the profile.
* Inside each profile, you can specify different flags for each command.
* A command definition is in a subsection of the name of the command.
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
[profile_name]
@@ -24,7 +22,7 @@ weight = 10
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
profile_name:
@@ -34,7 +32,7 @@ profile_name:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
profile_name {
@@ -46,7 +44,7 @@ profile_name {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -72,13 +70,13 @@ There's **one exception**: the flag `--repo` is named `repository` in the config
So let's say you normally use this simple command:
```shell
-$ restic --repo "local:/backup" --password-file "password.txt" --verbose backup /home
+restic --repo "local:/backup" --password-file "password.txt" --verbose backup /home
```
For resticprofile to generate this command automatically for you, here's the configuration file:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
# indentation is not needed but it makes it easier to read ;)
@@ -95,7 +93,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -111,7 +109,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -126,7 +124,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -153,7 +151,7 @@ You may have noticed the `source` flag is accepting an array of values (inside b
Now, assuming this configuration file is named `profiles.conf` in the current folder (it's the default config file name), you can simply run
```shell
-$ resticprofile backup
+resticprofile backup
```
and resticprofile will do its magic and generate the command line for you.
@@ -161,7 +159,7 @@ and resticprofile will do its magic and generate the command line for you.
If you have any doubt on what it's running, you can try a `--dry-run`:
```shell
-$ resticprofile --dry-run backup
+resticprofile --dry-run backup
2022/05/18 17:14:07 profile 'default': starting 'backup'
2022/05/18 17:14:07 dry-run: /usr/bin/restic backup --password-file password.txt --repo local:/backup --verbose /home
2022/05/18 17:14:07 profile 'default': finished 'backup'
diff --git a/docs/content/configuration/copy/index.md b/docs/content/configuration/copy/index.md
index 16c2139d..5f1c8952 100644
--- a/docs/content/configuration/copy/index.md
+++ b/docs/content/configuration/copy/index.md
@@ -11,8 +11,8 @@ weight: 17
The copy command needs two repositories (and quite likely 2 different set of keys). You can configure a `copy` section like this:
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -29,7 +29,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -45,7 +45,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
@@ -72,8 +72,8 @@ You will note that the secondary repository doesn't need to have a `2` behind it
If you want to initialize the *copy* repository using the `copy-chunker-params` flag, it needs to be called `initialize-copy-chunker-params` instead. As such, this flag does not exist on the `copy` target which is why we need to prefix it.
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -91,7 +91,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -108,7 +108,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
diff --git a/docs/content/configuration/examples/_index.md b/docs/content/configuration/examples/_index.md
index 789659cb..c9aa5be9 100644
--- a/docs/content/configuration/examples/_index.md
+++ b/docs/content/configuration/examples/_index.md
@@ -8,8 +8,8 @@ weight: 5
Here's a simple configuration file using a Microsoft Azure backend. You will notice that the `env` section lets you define environment variables:
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -31,7 +31,7 @@ version = "1"
source = [ "/", "/var" ]
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -57,7 +57,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -87,8 +87,8 @@ default {
Here's a more complex configuration file showing profile inheritance and two backup profiles using the same repository:
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -213,7 +213,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -347,7 +347,7 @@ src:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
global {
@@ -428,8 +428,8 @@ self {
## Configuration example for Windows
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -463,7 +463,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -499,7 +499,7 @@ test:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
global {
@@ -535,8 +535,8 @@ test {
Simple example sending a file via stdin
-{{< tabs groupId="config-with-hcl" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-hcl" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -561,7 +561,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -586,7 +586,7 @@ mysql:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
# sending stream through stdin
diff --git a/docs/content/configuration/getting_started/_index.md b/docs/content/configuration/getting_started/_index.md
index adbf9d86..f7a5cab1 100644
--- a/docs/content/configuration/getting_started/_index.md
+++ b/docs/content/configuration/getting_started/_index.md
@@ -62,8 +62,8 @@ In this example, we're going to call our profile `default`. You don't need to sp
Create a file named `profiles` with the extension of your choice (.toml, .yaml, .hcl or .json)
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
#:schema {{< absolute "jsonschema/config-1.json" nohtml >}}
@@ -82,7 +82,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
# yaml-language-server: $schema={{< absolute "jsonschema/config-1.json" nohtml >}}
@@ -100,7 +100,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -115,7 +115,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -230,8 +230,8 @@ Let's imagine you want to backup your files every day during your lunch break.
Add a line in your configuration (in the **default -> backup** section) with an option called `schedule` and a value of `12:30`. Your configuration should now look like:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
#:schema {{< absolute "jsonschema/config-1.json" nohtml >}}
@@ -251,7 +251,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
# yaml-language-server: $schema={{< absolute "jsonschema/config-1.json" nohtml >}}
@@ -270,7 +270,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -286,7 +286,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/configuration/http_hooks/index.md b/docs/content/configuration/http_hooks/index.md
index 56c1362d..b01182a6 100644
--- a/docs/content/configuration/http_hooks/index.md
+++ b/docs/content/configuration/http_hooks/index.md
@@ -42,8 +42,8 @@ The configuration is the same for each of these 4 types of hooks:
### Example sending monitoring information to healthchecks.io:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -103,7 +103,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -157,7 +157,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" {
@@ -220,7 +220,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -311,6 +311,9 @@ Here's the flow of HTTP hooks:
```mermaid
graph TD
+ LOCK(set resticprofile lock)
+ UNLOCK(delete resticprofile lock)
+ LOCK --> SB
SB('send-before') --> RUN
RUN(run restic command, or group of commands)
RUN -->|Success| SA
@@ -318,8 +321,14 @@ graph TD
SA('send-after') --> SF
SAF('send-after-fail') --> SF
SF('send-finally')
+ SF --> UNLOCK
```
+{{% notice style="warning" title="resticprofile lock" %}}
+The local resticprofile lock is surrounding the whole process. It means that the `run-after-fail` target is not called if the lock cannot be obtained. This is a limitation of the current implementation.
+{{% /notice %}}
+
+
### body-template
You can use a standard go template to build the webhook body. It has to be defined in a separate file (otherwise it would clash with the configuration as a go template itself).
@@ -353,8 +362,8 @@ The field `exitCode` will be blank if no error occured.
And here's an example of a configuration using a body template:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -376,7 +385,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -398,7 +407,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" {
@@ -420,7 +429,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -447,7 +456,7 @@ profile:
{{% /tab %}}
{{% /tabs %}}
-### CA certificates
+### Self-signed certificates
If your monitoring system is using self-signed certificates, you can import them in resticprofile (and you don't need to rely on the `skip-tls-verification` flag)
@@ -467,8 +476,8 @@ The format is like:
### global configuration example
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -480,7 +489,7 @@ version = "1"
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -493,7 +502,7 @@ global:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
@@ -504,7 +513,7 @@ global {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/configuration/include/_index.md b/docs/content/configuration/include/_index.md
index 7ae3e844..96a1da74 100644
--- a/docs/content/configuration/include/_index.md
+++ b/docs/content/configuration/include/_index.md
@@ -1,5 +1,5 @@
---
-title: "Include"
+title: "Includes"
date: 2022-05-02T20:00:00+02:00
tags: ["v0.18.0"]
weight: 15
@@ -8,8 +8,8 @@ weight: 15
The configuration may be split into multiple files by adding `includes = "glob-pattern"` to the main configuration file.
E.g. the following `profiles.conf` loads configurations from `conf.d` and `profiles.d`:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -24,7 +24,7 @@ includes = ["conf.d/*.conf", "profiles.d/*.yaml", "profiles.d/*.toml"]
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -40,7 +40,7 @@ global:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
@@ -52,7 +52,7 @@ global {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -75,10 +75,12 @@ global {
Included configuration files may use any supported format and settings are merged so that multiple files can extend the same profiles.
The HCL format is special in that it cannot be mixed with other formats.
-Included files cannot include nested files. Specifying `includes` inside an included file has no effect.
-
Within included files, the current [configuration path]({{< ref "/configuration/path/#how-paths-inside-the-configuration-are-resolved" >}}) is not changed. Path resolution remains relative to the path of the main configuration file.
+{{% notice style="note" %}}
+Included files cannot include nested files. Specifying `includes` inside an included file has no effect.
+{{% /notice %}}
+
## Configuration Merging
Loading a configuration file involves loading the physical file from disk and applying all [variables]({{< ref "/configuration/variables" >}}) and [templates]({{< ref "/configuration/templates" >}}) prior to parsing the file in a supported format `hcl`, `json`, `toml` and `yaml`. This means [variables]({{< ref "/configuration/variables" >}}) and [templates]({{< ref "/configuration/templates" >}}) must create valid configuration markup that can be parsed or loading will fail.
@@ -109,8 +111,8 @@ Configuration **merging** follows the logic:
* Lists of values or lists of objects are considered properties not config structure and will be replaced
-{{< tabs groupId="include-merging-example" >}}
-{{% tab name="Final configuration" %}}
+{{< tabs groupid="include-merging-example" >}}
+{{% tab title="profiles.yaml" %}}
```yaml
version: "1"
@@ -120,28 +122,10 @@ includes:
- second.yaml
default:
- initialize: true
+
backup:
- exclude:
- - .*
- source:
- - /etc
- - /opt
-```
-
-{{% /tab %}}
-{{% tab name="profiles.yaml" %}}
-```yaml
-version: "1"
-includes:
- - first.yaml
- - second.yaml
-
-default:
-
- backup:
source:
- /usr
@@ -150,7 +134,7 @@ default:
```
{{% /tab %}}
-{{% tab name="first.yaml" %}}
+{{% tab title="first.yaml" %}}
```yaml
version: "1"
@@ -162,6 +146,8 @@ version: "1"
default:
initialize: false
backup:
+
+
source:
- /etc
- /opt
@@ -170,7 +156,7 @@ default:
```
{{% /tab %}}
-{{% tab name="second.yaml" %}}
+{{% tab title="second.yaml" %}}
```yaml
version: "1"
@@ -189,9 +175,33 @@ default:
```
+{{% /tab %}}
+{{% tab title="Final configuration" %}}
+
+```yaml
+version: "1"
+
+includes:
+ - first.yaml
+ - second.yaml
+
+default:
+ initialize: true
+ backup:
+ exclude:
+ - .*
+ source:
+ - /etc
+ - /opt
+```
+
{{% /tab %}}
{{% /tabs %}}
+{{% notice style="tip" %}}
+You can use `resticprofile [.]show` (or `resticprofile [--name ] show`) to see the resulting configuration after merging.
+{{% /notice %}}
+
{{% notice style="note" %}}
diff --git a/docs/content/configuration/inheritance/_index.md b/docs/content/configuration/inheritance/_index.md
index 85430d49..15b246b3 100644
--- a/docs/content/configuration/inheritance/_index.md
+++ b/docs/content/configuration/inheritance/_index.md
@@ -5,7 +5,7 @@ weight: 16
---
{{% notice style="tip" %}}
-You can use `resticprofile [.]show` to see the effect inheritance on a profile
+You can use `resticprofile [.]show` (or `resticprofile [--name ] show`) to see the effect inheritance has on a profile
{{% /notice %}}
## Profile Inheritance
@@ -21,8 +21,8 @@ Profile configuration merging follows the same logic as [configuration merging](
* There is no default inheritance. If `inherit` is not set, no inheritance applies
-{{< tabs groupId="profile-inheritance-example" >}}
-{{% tab name="Profile 'base' (yaml)" %}}
+{{< tabs groupid="profile-inheritance-example" >}}
+{{% tab title="Profile 'base' (yaml)" %}}
```yaml
version: "1"
@@ -50,7 +50,7 @@ base:
```
{{% /tab %}}
-{{% tab name="Profile 'backup-homes' (yaml)" %}}
+{{% tab title="Profile 'backup-homes' (yaml)" %}}
```yaml
@@ -78,7 +78,7 @@ backup-homes:
```
{{% /tab %}}
-{{% tab name="... after applying 'inherit'" %}}
+{{% tab title="... after applying 'inherit'" %}}
```yaml
version: "1"
@@ -138,8 +138,8 @@ Assuming the parent profile declares the list property ``:
* `...` or `__APPEND` appends to the list property
* `...` or `__PREPEND` prepends to the list property
-{{< tabs groupId="config-with-inheritance-list-append" >}}
-{{% tab name="yaml" %}}
+{{< tabs groupid="config-with-inheritance-list-append" >}}
+{{% tab title="yaml" %}}
```yaml
version: 2
@@ -160,7 +160,7 @@ profiles:
```
{{% /tab %}}
-{{% tab name="toml" %}}
+{{% tab title="toml" %}}
```toml
version = 2
@@ -196,8 +196,8 @@ Configuration values inside a mixin may be parametrized with variables following
Unlike configuration [variables]({{< ref "/configuration/variables" >}}) and [templates]({{< ref "/configuration/templates" >}}), mixins create parsed configuration structure not config markup that requires parsing. This allows mixins to be defined in one supported config format (`yaml`, `toml`, `json`) while being used in any other supported format when the configuration is split into multiple [includes]({{< ref "/configuration/include/#configuration-merging" >}}).
-{{< tabs groupId="config-with-mixins" >}}
-{{% tab name="yaml" %}}
+{{< tabs groupid="config-with-mixins" >}}
+{{% tab title="yaml" %}}
```yaml
version: 2
@@ -213,7 +213,7 @@ profiles:
```
{{% /tab %}}
-{{% tab name="yaml (with vars)" %}}
+{{% tab title="yaml (with vars)" %}}
```yaml
version: 2
@@ -238,7 +238,7 @@ profiles:
```
{{% /tab %}}
-{{% tab name="toml" %}}
+{{% tab title="toml" %}}
```toml
version = 2
@@ -252,7 +252,7 @@ use = "name-of-mixin"
```
{{% /tab %}}
-{{% tab name="toml (with vars)" %}}
+{{% tab title="toml (with vars)" %}}
```toml
version = 2
@@ -304,8 +304,8 @@ List properties that have been inherited from a parent can be modified (append/p
#### Mixin Example
-{{< tabs groupId="config-with-mixins-examples" >}}
-{{% tab name="yaml" %}}
+{{< tabs groupid="config-with-mixins-examples" >}}
+{{% tab title="yaml" %}}
```yaml
# file format version 2
@@ -360,7 +360,7 @@ profiles:
```
{{% /tab %}}
-{{% tab name="toml" %}}
+{{% tab title="toml" %}}
```toml
# file format version 2
@@ -424,8 +424,8 @@ Resticprofile applies a filter (see `global.restic-arguments-filter`) to decide
For example, a flag like `insecure-tls` can be set at profile level and will be used whenever restic is started with this profile. Most supported flags can be set in this way at profile level, see [reference]({{< ref "/configuration/reference" >}}) for details.
-{{< tabs groupId="config-with-common-flags-in-profile" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-common-flags-in-profile" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -438,7 +438,7 @@ source = "/"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -451,7 +451,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -464,7 +464,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -485,12 +485,12 @@ default {
Resulting in the following restic commandline:
```
-> resticprofile --dry-run backup
+resticprofile --dry-run backup
...
dry-run: /usr/local/bin/restic backup --insecure-tls --repo rest:https://backup-host/my-repo /
-> resticprofile --dry-run prune
+resticprofile --dry-run prune
...
dry-run: /usr/local/bin/restic prune --insecure-tls --repo rest:https://backup-host/my-repo
```
diff --git a/docs/content/configuration/jsonschema/index.md b/docs/content/configuration/jsonschema/index.md
index 91de2afe..43d180e3 100644
--- a/docs/content/configuration/jsonschema/index.md
+++ b/docs/content/configuration/jsonschema/index.md
@@ -37,8 +37,8 @@ As an alternative to URLs, schemas can be generated locally with:
To use a schema with **vscode**, begin your config files with:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
``````toml
#:schema {{< absolute "jsonschema/config-2.json" nohtml >}}
@@ -46,7 +46,7 @@ version = "2"
``````
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
``````yaml
# yaml-language-server: $schema={{< absolute "jsonschema/config-2.json" nohtml >}}
@@ -54,7 +54,7 @@ version: "2"
``````
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
``````json
{
"$schema": "{{< absolute "jsonschema/config-2.json" nohtml >}}",
diff --git a/docs/content/configuration/logs/_index.md b/docs/content/configuration/logs/_index.md
index 564dfe74..4a17ef7b 100644
--- a/docs/content/configuration/logs/_index.md
+++ b/docs/content/configuration/logs/_index.md
@@ -11,9 +11,9 @@ You can redirect the logs to a local file, a temporary file or a syslog server.
## Destination
The log destination syntax is a such:
-* `filename` => redirects all the logs to the local file called **filename**
-* `temp:filename` => redirects all the logs to a temporary file available during the whole session, and deleted afterwards.
-* `tcp://syslog_server:514` or `udp://syslog_server:514` => redirects all the logs to the **syslog** server.
+* `filename` {{% icon icon="arrow-right" %}} redirects all the logs to the local file called **filename**
+* `temp:filename` {{% icon icon="arrow-right" %}} redirects all the logs to a temporary file available during the whole session, and deleted afterwards.
+* `tcp://syslog_server:514` or `udp://syslog_server:514` {{% icon icon="arrow-right" %}} redirects all the logs to the **syslog** server.
{{% notice tip %}}
If the location cannot be opened, **resticprofile** will default to send the logs to the console.
@@ -32,8 +32,8 @@ resticprofile --log backup.log backup
You can keep the logs displayed on the console when you run **resticprofile** commands manually, but send the logs somewhere else when **resticprofile** is started from a schedule.
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -46,7 +46,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -59,7 +59,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" "backup" {
@@ -70,7 +70,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -90,10 +90,12 @@ profile:
## Send logs to a temporary file
+This can be done by using the [template]({{< ref "/configuration/templates" >}}) function `tempFile`.
+
This is to cover a special case when you want to upload the logs one by one to a remote location in a `run-finally` or a `run-after-fail` target.
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -109,7 +111,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -126,7 +128,7 @@ backup_current:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" "backup" {
@@ -140,7 +142,7 @@ backup_current:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/configuration/path/_index.md b/docs/content/configuration/path/_index.md
index 477768b2..d7ad4500 100644
--- a/docs/content/configuration/path/_index.md
+++ b/docs/content/configuration/path/_index.md
@@ -24,8 +24,8 @@ resticprofile is started from `/home/user/`, the individual paths are resolved t
* **backup.source**: `/home/user/files`
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
# indentation is not needed but it makes it easier to read ;)
@@ -43,7 +43,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -60,7 +60,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -76,7 +76,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/configuration/run_hooks/index.md b/docs/content/configuration/run_hooks/index.md
index 8d0ff89e..476c753f 100644
--- a/docs/content/configuration/run_hooks/index.md
+++ b/docs/content/configuration/run_hooks/index.md
@@ -14,8 +14,8 @@ resticprofile has 2 places where you can run commands around restic:
Here's an example of all the external commands that you can run during the execution of a profile:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -36,7 +36,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -56,7 +56,7 @@ documents:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
documents {
@@ -76,7 +76,7 @@ documents {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -152,6 +152,8 @@ Maybe it's easier to understand with a flow diagram:
```mermaid
flowchart TB
+ LOCK(set resticprofile lock)
+ UNLOCK(delete resticprofile lock)
PRB('run-before' from profile)
PRA('run-after' from profile)
@@ -173,6 +175,7 @@ flowchart TB
BRF --> PRF
end
+ LOCK --> PRB
PRB -->|Error| PFAIL
PRB -->|Success| BRB
@@ -191,20 +194,24 @@ flowchart TB
PRA -->|Error| PFAIL
PRA -->|Success| Finally
PFAIL --> Finally
+ Finally --> UNLOCK
style Backup fill:#9990,stroke:#9990
style Failure fill:#9990,stroke:#9990
style Finally fill:#9991,stroke:#9994,stroke-width:4px
```
+{{% notice style="warning" title="resticprofile lock" %}}
+The local resticprofile lock is surrounding the whole process. It means that the `run-after-fail` target is not called if the lock cannot be obtained. This is a limitation of the current implementation.
+{{% /notice %}}
## Run commands on stream errors
In addition to hooks around profile and command execution, resticprofile allows to monitor the standard error stream of the current running command and trigger a custom hook when an output error line matches a regular expression pattern.
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -219,7 +226,7 @@ min-matches = 5
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -232,7 +239,7 @@ default:
min-matches: 5
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -245,7 +252,7 @@ default {
}
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -279,8 +286,8 @@ The `run` command inherits the environment of the monitored command on a pattern
The following example shows how this could have been used with restic to address `check` failures caused by over usage of `/tmp/` (restic fixed this problem in 0.14.0):
-{{< tabs groupId="config-without-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-without-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -297,7 +304,7 @@ run = "cat - | cut -d : -f 2 - | grep -E 'mkdir /tmp[^ \\.]+$' | sed 's/mkdir/mk
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
diff --git a/docs/content/configuration/templates/index.md b/docs/content/configuration/templates/index.md
index b8f44b13..ed8b806d 100644
--- a/docs/content/configuration/templates/index.md
+++ b/docs/content/configuration/templates/index.md
@@ -1,7 +1,7 @@
---
title: "Templates"
date: 2022-05-16T20:04:35+01:00
-weight: 26
+weight: 25
---
@@ -30,8 +30,8 @@ Note the **dot** after the name: it's used to pass the variables to the template
Here's a working example:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
#
@@ -132,7 +132,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
@@ -224,7 +224,7 @@ azure-mysql:
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
#
@@ -318,7 +318,7 @@ azure-mysql:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{{ define "backup_root" }}
diff --git a/docs/content/configuration/variables/index.md b/docs/content/configuration/variables/index.md
index 3b443d3b..a871593a 100644
--- a/docs/content/configuration/variables/index.md
+++ b/docs/content/configuration/variables/index.md
@@ -1,15 +1,19 @@
---
title: "Variables"
date: 2022-05-16T20:04:35+01:00
-weight: 25
+weight: 26
---
## Variable expansion in configuration file
-You might want to reuse the same configuration (or bits of it) on different environments. One way of doing it is to create a generic configuration where
-specific bits will be replaced by a variable.
+You might want to reuse the same configuration (or bits of it) on different environments. One way of doing it is to create a generic configuration where specific bits can be replaced by a variable.
-## Pre-defined variables
+### There are two kinds of variables:
+- **template variables**: These variables are fixed once the full configuration file is loaded: [includes]({{< ref "configuration/include" >}}) are loaded, and [inheritance]({{< ref "/configuration/inheritance" >}}) is resolved. These variables are replaced by their value **before** the configuration is parsed.
+- **runtime variables**: These variables are replaced by their value **after** the configuration is parsed. In other words: these variables are replaced by their value just before the command is executed.
+
+## Template variables
+### Pre-defined variables
The syntax for using a pre-defined variable is:
@@ -67,12 +71,12 @@ The variable `.Now` also allows to derive a relative `Time`. For example `{{ (.N
is 6 months and 14 days before now.
-### Example
+#### Example
You can use a combination of inheritance and variables in the resticprofile configuration file like so:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -122,7 +126,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
---
@@ -180,7 +184,7 @@ src:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"generic" = {
@@ -229,7 +233,7 @@ src:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -348,7 +352,7 @@ Now you can reuse the same generic configuration in another profile.
You might have noticed the `read-data-subset` in the `check` section which will read a seventh of the data every day, meaning the whole repository data will be
checked over a week. You can find [more information about this trick](https://stackoverflow.com/a/72465098).
-## Hand-made variables
+### Hand-made variables
But you can also define variables yourself. Hand-made variables starts with a `$` ([PHP](https://en.wikipedia.org/wiki/PHP) anyone?) and get declared and
assigned with the `:=` operator ([Pascal](https://en.wikipedia.org/wiki/Pascal_(programming_language)) anyone?). Here's an example:
@@ -362,12 +366,12 @@ profile:
tag: "{{ $name }}"
```
-### Example
+#### Example
Here's an example of a configuration on Linux where I use a variable `$mountpoint` set to a USB drive mount point:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -391,7 +395,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -417,7 +421,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
global {
@@ -443,7 +447,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{{ $mountpoint := "/mnt/external" }}
@@ -474,7 +478,7 @@ default {
{{% /tabs %}}
-## Variable expansion in configuration **values**
+## Runtime variable expansion
Variable expansion as described in the previous section using the `{{ .Var }}` syntax refers to [template variables]({{< ref "/configuration/templates" >}}) that are expanded prior to parsing the configuration file.
This means they must be used carefully to create correct config markup, but they are also very flexible.
@@ -487,8 +491,8 @@ If not specified differently, these variables resolve to the corresponding envir
Backup current dir (`$PWD`) but prevent backup of `$HOME` where the repository is located:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -504,7 +508,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -520,7 +524,7 @@ default:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
default {
@@ -535,7 +539,7 @@ default {
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/configuration/warnings/index.md b/docs/content/configuration/warnings/index.md
index 2f31c0a3..10ad4ef0 100644
--- a/docs/content/configuration/warnings/index.md
+++ b/docs/content/configuration/warnings/index.md
@@ -11,10 +11,10 @@ But the version 0.13.0 introduced a parameter to avoid this behaviour and consid
A restic warning occurs when it cannot read some files, but a snapshot was successfully created.
-### Let me introduce no-error-on-warning
+### no-error-on-warning
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -27,7 +27,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
@@ -39,7 +39,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" = {
@@ -51,7 +51,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/contributions/_index.md b/docs/content/contributions/_index.md
index ff8d18c9..24f081b4 100644
--- a/docs/content/contributions/_index.md
+++ b/docs/content/contributions/_index.md
@@ -1,11 +1,10 @@
+++
-chapter = true
+archetype = "chapter"
pre = "6. "
title = "Contributions"
-weight = 40
+weight = 6
+++
-# Contributions
Please share your resticprofile recipes, fancy configuration files, or tips and tricks.
diff --git a/docs/content/installation/_index.md b/docs/content/installation/_index.md
index 3fd01062..7eacf461 100644
--- a/docs/content/installation/_index.md
+++ b/docs/content/installation/_index.md
@@ -1,10 +1,8 @@
+++
-chapter = true
+archetype = "chapter"
pre = "1. "
title = "Installation"
-weight = 5
+weight = 1
+++
-# Installation
-
{{% children %}}
diff --git a/docs/content/installation/docker/_index.md b/docs/content/installation/docker/_index.md
index 4e1d700e..2ed6133e 100644
--- a/docs/content/installation/docker/_index.md
+++ b/docs/content/installation/docker/_index.md
@@ -17,12 +17,12 @@ Depending on your operating system, the backup might be **slower**. Volumes moun
By default, the resticprofile container starts at `/resticprofile`. So you can feed a configuration this way:
```shell
-$ docker run -it --rm -v $PWD/examples:/resticprofile creativeprojects/resticprofile
+docker run -it --rm -v $PWD/examples:/resticprofile creativeprojects/resticprofile
```
You can list your profiles:
```shell
-$ docker run -it --rm -v $PWD/examples:/resticprofile creativeprojects/resticprofile profiles
+docker run -it --rm -v $PWD/examples:/resticprofile creativeprojects/resticprofile profiles
```
### Container host name
@@ -32,7 +32,7 @@ Each time a container is started, it gets assigned a new random name.
You might want to force a hostname when starting your container via docker run (flags `-h` or `--hostname`):
```shell
-$ docker run -it --rm -v $PWD:/resticprofile -h my-hostname creativeprojects/resticprofile -n profile backup
+docker run -it --rm -v $PWD:/resticprofile -h my-hostname creativeprojects/resticprofile -n profile backup
```
### Platforms
diff --git a/docs/content/installation/linux/_index.md b/docs/content/installation/linux/_index.md
index a0c7b7d2..f3e022a3 100644
--- a/docs/content/installation/linux/_index.md
+++ b/docs/content/installation/linux/_index.md
@@ -10,7 +10,7 @@ weight: 10
Here's a simple script to download the binary automatically. It works on mac OS X, FreeBSD and Linux:
```shell
-$ curl -sfL https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh | sh
+curl -sfL https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh | sh
```
It should copy resticprofile in a `bin` directory under your current directory.
@@ -18,9 +18,9 @@ It should copy resticprofile in a `bin` directory under your current directory.
If you need more control, you can save the shell script and run it manually:
```shell
-$ curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
-$ chmod +x install.sh
-$ sudo ./install.sh -b /usr/local/bin
+curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
+chmod +x install.sh
+sudo ./install.sh -b /usr/local/bin
```
It will install resticprofile in `/usr/local/bin/`
@@ -30,34 +30,38 @@ It will install resticprofile in `/usr/local/bin/`
There's a Linux [homebrew](https://brew.sh/) tap for resticprofile:
```shell
-$ brew tap creativeprojects/tap
-$ brew install resticprofile
+brew tap creativeprojects/tap
+brew install resticprofile
```
You can also install `restic` at the same time with `--with-restic` flag:
```shell
-$ brew install resticprofile --with-restic
+brew install resticprofile --with-restic
```
You can test that resticprofile is properly installed (make sure you have restic installed or the test will fail):
```shell
-$ brew test resticprofile
+brew test resticprofile
```
Upgrading resticprofile installed via homebrew is very easy:
```shell
-$ brew update
-$ brew upgrade resticprofile
+brew update
+brew upgrade resticprofile
```
+{{% notice style="note" %}}
+The resticprofile command `self-update` is not available when installed via homebrew.
+{{% /notice %}}
+
### Note on installing on Linux via Homebrew
When testing homebrew after spinning new Linux virtual machines, I noticed resticprofile wouldn't install without a compiler installed on the machine.
Even though resticprofile is distributed as a **binary**, it looks like homebrew needs access to a compiler.
Depending on your distribution you will need to install gcc:
-* `$ sudo yum install gcc`
-* `$ sudo apt install gcc`
+* `sudo yum install gcc`
+* `sudo apt install gcc`
diff --git a/docs/content/installation/macosx/_index.md b/docs/content/installation/macosx/_index.md
index b76bcea0..82897d90 100644
--- a/docs/content/installation/macosx/_index.md
+++ b/docs/content/installation/macosx/_index.md
@@ -9,35 +9,38 @@ weight: 11
There's a [homebrew](https://brew.sh/) tap for resticprofile:
```shell
-$ brew tap creativeprojects/tap
-$ brew install resticprofile
+brew tap creativeprojects/tap
+brew install resticprofile
```
You can also install `restic` at the same time with `--with-restic` flag:
```shell
-$ brew install resticprofile --with-restic
+brew install resticprofile --with-restic
```
You can test that resticprofile is properly installed (make sure you have restic installed or the test will fail):
```shell
-$ brew test resticprofile
+brew test resticprofile
```
Upgrading resticprofile installed via homebrew is very easy:
```shell
-$ brew update
-$ brew upgrade resticprofile
+brew update
+brew upgrade resticprofile
```
+{{% notice style="note" %}}
+The resticprofile command `self-update` is not available when installed via homebrew.
+{{% /notice %}}
## Installation via a script
Here's a simple script to download the binary automatically. It works on mac OS X, FreeBSD and Linux:
```shell
-$ curl -sfL https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh | sh
+curl -sfL https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh | sh
```
It should copy resticprofile in a `bin` directory under your current directory.
@@ -45,9 +48,9 @@ It should copy resticprofile in a `bin` directory under your current directory.
If you need more control, you can save the shell script and run it manually:
```shell
-$ curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
-$ chmod +x install.sh
-$ sudo ./install.sh -b /usr/local/bin
+curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
+chmod +x install.sh
+sudo ./install.sh -b /usr/local/bin
```
It will install resticprofile in `/usr/local/bin/`
diff --git a/docs/content/installation/shell/_index.md b/docs/content/installation/shell/_index.md
index e1ede84c..2e86fd7e 100644
--- a/docs/content/installation/shell/_index.md
+++ b/docs/content/installation/shell/_index.md
@@ -20,6 +20,6 @@ eval "$(resticprofile generate --zsh-completion)"
To install them permanently:
```shell
-$ resticprofile generate --bash-completion > /etc/bash_completion.d/resticprofile
-$ chmod +x /etc/bash_completion.d/resticprofile
+resticprofile generate --bash-completion > /etc/bash_completion.d/resticprofile
+chmod +x /etc/bash_completion.d/resticprofile
```
diff --git a/docs/content/installation/source/_index.md b/docs/content/installation/source/_index.md
index f94292e2..83af24ee 100644
--- a/docs/content/installation/source/_index.md
+++ b/docs/content/installation/source/_index.md
@@ -13,9 +13,9 @@ You can download the source code and compile it, it's actually very easy! all yo
To compile from sources:
```shell
-$ git clone https://github.com/creativeprojects/resticprofile.git
-$ cd resticprofile
-$ make build
+git clone https://github.com/creativeprojects/resticprofile.git
+cd resticprofile
+make build
```
Your compiled binary (`resticprofile` or `resticprofile.exe`) is available in the current folder.
@@ -23,23 +23,23 @@ Your compiled binary (`resticprofile` or `resticprofile.exe`) is available in th
To install the binary in your user path:
```shell
-$ make install
+make install
```
To build all common platforms (`build-mac`, `build-linux`, `build-pi` & `build-windows`):
```shell
-$ make build-all
+make build-all
```
Alternatively, a **go-only** build (without `GNU Make`) is accomplished with:
```shell
-$ git clone https://github.com/creativeprojects/resticprofile.git
-$ cd resticprofile
-$ go mod download
-$ go generate ./...
-$ go build -o resticprofile .
+git clone https://github.com/creativeprojects/resticprofile.git
+cd resticprofile
+go mod download
+go generate ./...
+go build -o resticprofile .
```
diff --git a/docs/content/installation/upgrade/_index.md b/docs/content/installation/upgrade/_index.md
index 61345a11..5969a7dc 100644
--- a/docs/content/installation/upgrade/_index.md
+++ b/docs/content/installation/upgrade/_index.md
@@ -7,19 +7,28 @@ weight: 20
Once installed, you can easily upgrade resticprofile to the latest release using this command:
```shell
-$ resticprofile self-update
+resticprofile self-update
```
-_Please note on versions before 0.10.0, there was an issue with self-updating from linux with ARM processors (like a raspberry pi). This was fixed in version 0.10.0_
+{{% notice style="note" %}}
+The `self-update` command is not available when installed via homebrew.
+You should use `brew upgrade resticprofile` instead.
+{{% /notice %}}
+
+
resticprofile will check for a new version from GitHub releases and asks you if you want to update to the new version. If you add the flag `-q` or `--quiet` to the command line, it will update automatically without asking.
```shell
-$ resticprofile --quiet self-update
+resticprofile --quiet self-update
```
and since version 0.11.0:
```shell
-$ resticprofile self-update --quiet
+resticprofile self-update --quiet
```
+
+{{% notice style="info" %}}
+On versions before 0.10.0, there was an issue with self-updating from linux with ARM processors (like a raspberry pi). This was fixed in version 0.10.0
+{{% /notice %}}
diff --git a/docs/content/installation/windows/_index.md b/docs/content/installation/windows/_index.md
index 1c300a4c..60e3c973 100644
--- a/docs/content/installation/windows/_index.md
+++ b/docs/content/installation/windows/_index.md
@@ -11,8 +11,8 @@ weight: 12
You can use a script if you're using bash in Windows (via WSL, git bash, etc.)
```shell
-$ curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
-$ ./install.sh
+curl -LO https://raw.githubusercontent.com/creativeprojects/resticprofile/master/install.sh
+./install.sh
```
It will create a `bin` directory under your current directory and place `resticprofile.exe` in it.
diff --git a/docs/content/schedules/_index.md b/docs/content/schedules/_index.md
index cfe64840..bf8eafe0 100644
--- a/docs/content/schedules/_index.md
+++ b/docs/content/schedules/_index.md
@@ -1,14 +1,12 @@
+++
-chapter = true
+archetype = "chapter"
pre = "4. "
title = "Schedules"
-weight = 20
+weight = 4
+++
-# Scheduled backups
-
-resticprofile is capable of managing scheduled backups for you using:
+resticprofile is capable of managing scheduled backups for you. Under the hood it's using:
- **launchd** on macOS X
- **Task Scheduler** on Windows
- **systemd** where available (Linux and other BSDs)
@@ -16,8 +14,8 @@ resticprofile is capable of managing scheduled backups for you using:
On unixes (except macOS) resticprofile is using **systemd** by default. **crond** can be used instead if configured in `global` `scheduler` parameter:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
[global]
@@ -25,7 +23,7 @@ On unixes (except macOS) resticprofile is using **systemd** by default. **crond*
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
---
@@ -34,7 +32,7 @@ global:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"global" = {
@@ -43,7 +41,7 @@ global:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -68,9 +66,10 @@ These 5 profile sections are accepting a schedule configuration:
- prune (version 0.11.0)
- copy (version 0.16.0)
-which mean you can schedule `backup`, `forget`, `prune`, `check` and `copy` independently (I recommend to use a local `lock` in this case).
+which mean you can schedule `backup`, `forget`, `prune`, `check` and `copy` independently (I recommend using a [local lock]({{< ref "/usage/locks" >}}) in this case).
## retention schedule is deprecated
-**Important**:
-starting from version 0.11.0 the schedule of the `retention` section is **deprecated**: Use the `forget` section instead.
+Starting from version 0.11.0, directly scheduling the `retention` section is **deprecated**: Use the `forget` section for direct schedule instead.
+
+The retention section is designed to be associated with a `backup` section, not to be scheduled independently.
diff --git a/docs/content/schedules/commands/index.md b/docs/content/schedules/commands/index.md
index bd206af0..eb5d9613 100644
--- a/docs/content/schedules/commands/index.md
+++ b/docs/content/schedules/commands/index.md
@@ -13,9 +13,9 @@ All internal commands either operate on the profile selected by `--name`, on the
Examples:
```shell
-$ resticprofile --name profile schedule
-$ resticprofile --name group schedule
-$ resticprofile schedule --all
+resticprofile --name profile schedule
+resticprofile --name group schedule
+resticprofile schedule --all
```
Please note, schedules are always independent of each other no matter whether they have been created with `--all`, by group or from a single profile.
@@ -38,4 +38,4 @@ Remove all the schedules defined on the selected profile or profiles.
Print the status on all the installed schedules of the selected profile or profiles.
-The display of the `status` command will be OS dependant. Please see the examples below on which output you can expect from it.
+The display of the `status` command will be OS dependant. Please refer to the [examples]({{< ref "/schedules/examples" >}}) on which output you can expect from it.
diff --git a/docs/content/schedules/configuration/index.md b/docs/content/schedules/configuration/index.md
index 4e5ae457..0b60fb58 100644
--- a/docs/content/schedules/configuration/index.md
+++ b/docs/content/schedules/configuration/index.md
@@ -6,8 +6,8 @@ weight: 10
The schedule configuration consists of a few parameters which can be added on each profile:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
[profile.backup]
@@ -20,7 +20,7 @@ The schedule configuration consists of a few parameters which can be added on ea
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
profile:
@@ -34,7 +34,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" "backup" {
@@ -48,7 +48,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -175,8 +175,8 @@ The `schedule` can be a string or an array of string (to allow for multiple sche
Here's an example of a scheduling configuration:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
[default]
@@ -203,7 +203,7 @@ Here's an example of a scheduling configuration:
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
default:
@@ -229,7 +229,7 @@ self:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"default" = {
@@ -261,7 +261,7 @@ self:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/schedules/examples/index.md b/docs/content/schedules/examples/index.md
index 6e660c1c..feabe59a 100644
--- a/docs/content/schedules/examples/index.md
+++ b/docs/content/schedules/examples/index.md
@@ -6,7 +6,11 @@ weight: 30
### Examples of scheduling commands under Windows
-If you create a task with `user` permission under Windows, you will need to enter your password to validate the task. It's a requirement of the task scheduler. I'm inviting you to review the code to make sure I'm not emailing your password to myself. Seriously you shouldn't trust anyone.
+{{% notice note %}}
+If you create a task with `user` permission under Windows, you will need to enter your password to validate the task.
+
+It's a requirement of the task scheduler. I'm inviting you to review the code to make sure I'm not emailing your password to myself. Seriously you shouldn't trust anyone.
+{{% /notice %}}
Example of the `schedule` command under Windows (with git bash):
@@ -111,8 +115,8 @@ $ resticprofile -c examples/windows.yaml -n self unschedule
With this example of configuration for Linux:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -137,7 +141,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -161,7 +165,7 @@ test1:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"default" = {
@@ -188,7 +192,7 @@ test1:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/schedules/launchd/index.md b/docs/content/schedules/launchd/index.md
index f62c898e..2ff079b1 100644
--- a/docs/content/schedules/launchd/index.md
+++ b/docs/content/schedules/launchd/index.md
@@ -22,7 +22,7 @@ For this to happen, you need to start the agent or daemon from a console window
If your profile is a backup profile called `remote`, the command to run manually is:
```shell
-% launchctl start local.resticprofile.remote.backup
+launchctl start local.resticprofile.remote.backup
```
Once you grant the permission, the background agents/daemon will be able to run normally.
diff --git a/docs/content/schedules/systemd/index.md b/docs/content/schedules/systemd/index.md
index 33267cf8..a0fc1435 100644
--- a/docs/content/schedules/systemd/index.md
+++ b/docs/content/schedules/systemd/index.md
@@ -10,9 +10,9 @@ weight: 105
resticprofile has the ability to create systemd timer and service files.
systemd can be used in place of cron to schedule backups.
-User systemd units are created under the user's systemd profile (~/.config/systemd/user).
+User systemd units are created under the user's systemd profile (`~/.config/systemd/user`).
-System units are created in /etc/systemd/system
+System units are created in `/etc/systemd/system`
## systemd calendars
@@ -24,7 +24,8 @@ Testing systemd calendars can be done with the systemd-analyze application.
systemd-analyze will display when the next trigger will happen:
```shell
-$ systemd-analyze calendar 'daily'
+systemd-analyze calendar 'daily'
+
Original form: daily
Normalized form: *-*-* 00:00:00
Next elapse: Sat 2020-04-18 00:00:00 CDT
@@ -49,8 +50,8 @@ Since version 0.16.0, you now can describe your own templates if you need to add
The format used is a [go template](https://pkg.go.dev/text/template) and you need to specify your own unit and/or timer file in the global section of the configuration (it will apply to all your profiles):
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
[global]
@@ -59,7 +60,7 @@ The format used is a [go template](https://pkg.go.dev/text/template) and you nee
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
---
@@ -69,7 +70,7 @@ global:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"global" = {
@@ -79,7 +80,7 @@ global:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/status/_index.md b/docs/content/status/_index.md
index e3e97418..1a4b1063 100644
--- a/docs/content/status/_index.md
+++ b/docs/content/status/_index.md
@@ -1,21 +1,19 @@
+++
-chapter = true
+archetype = "chapter"
pre = "5. "
-title = "Status"
-weight = 30
+title = "Status file"
+weight = 5
+++
-# Status file for easy monitoring
-
If you need to escalate the result of your backup to a monitoring system, you can definitely use the `run-after` and `run-after-fail` scripting.
But sometimes we just need something simple that a monitoring system can regularly check. For that matter, resticprofile can generate a simple JSON file with the details of the latest backup/forget/check command. For example I have a Zabbix agent [checking this file](https://github.com/creativeprojects/resticprofile/tree/master/contrib/zabbix) once a day, and so you can hook up any monitoring system that can interpret a JSON file.
In your profile, you simply need to add a new parameter, which is the location of your status file
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -25,7 +23,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -35,7 +33,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" {
@@ -44,7 +42,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -108,8 +106,8 @@ This is a technical limitation to ensure restic displays terminal output correct
`extended-status` is **not set by default because it hides any output from restic**
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -124,7 +122,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -140,7 +138,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"profile" = {
@@ -155,7 +153,7 @@ profile:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/status/prometheus/index.md b/docs/content/status/prometheus/index.md
index 03bc5d88..3052f908 100644
--- a/docs/content/status/prometheus/index.md
+++ b/docs/content/status/prometheus/index.md
@@ -9,8 +9,8 @@ weight: 5
resticprofile can generate a prometheus file, or send the report to a push gateway. For now, only a `backup` command will generate a report.
Here's a configuration example with both options to generate a file and send to a push gateway:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -26,7 +26,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -42,7 +42,7 @@ root:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"root" = {
@@ -58,7 +58,7 @@ root:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -140,8 +140,8 @@ If you need more control over the job label, you can use the `prometheus-push-jo
You can add your own prometheus labels. Please note they will be applied to **all** the metrics.
Here's an example:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -160,7 +160,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -178,7 +178,7 @@ root:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"root" = {
@@ -198,7 +198,7 @@ root:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/usage/_index.md b/docs/content/usage/_index.md
index 08f4bc8b..ee27f428 100644
--- a/docs/content/usage/_index.md
+++ b/docs/content/usage/_index.md
@@ -1,26 +1,24 @@
+++
-chapter = true
+archetype = "chapter"
pre = "3. "
-title = "Usage"
-weight = 15
+title = "Using resticprofile"
+weight = 3
tags = ["v0.17.0"]
+++
-# Using resticprofile
-
Here are a few examples how to run resticprofile (using the main example configuration file)
-See all snapshots of your `[default]` profile:
+See all snapshots of your `default` profile:
```shell
-$ resticprofile
+resticprofile
```
See all available profiles in your configuration file (and the restic commands where some flags are defined):
```shell
-$ resticprofile profiles
+resticprofile profiles
Profiles available (name, sections, description):
root: (backup, copy, forget, retention)
@@ -35,68 +33,35 @@ Groups available (name, profiles, description):
Backup root & src profiles (using _full-backup_ group shown earlier)
```shell
-$ resticprofile --name "full-backup" backup
+resticprofile --name "full-backup" backup
```
or using the syntax introduced in v0.17.0:
```shell
-$ resticprofile full-backup.backup
+resticprofile full-backup.backup
```
Assuming the _stdin_ profile from the configuration file shown before, the command to send a mysqldump to the backup is as simple as:
```shell
-$ mysqldump --all-databases --order-by-primary | resticprofile --name stdin backup
+mysqldump --all-databases --order-by-primary | resticprofile --name stdin backup
```
or using the syntax introduced in v0.17.0:
```shell
-$ mysqldump --all-databases --order-by-primary | resticprofile stdin.backup
+mysqldump --all-databases --order-by-primary | resticprofile stdin.backup
```
Mount the default profile (_default_) in /mnt/restic:
```shell
-$ resticprofile mount /mnt/restic
+resticprofile mount /mnt/restic
```
Display quick help
```shell
-$ resticprofile --help
-
-Usage of resticprofile:
- resticprofile [resticprofile flags] [profile name.][restic command] [restic flags]
- resticprofile [resticprofile flags] [profile name.][resticprofile command] [command specific flags]
-
-resticprofile flags:
- -c, --config string configuration file (default "profiles")
- --dry-run display the restic commands instead of running them
- -f, --format string file format of the configuration (default is to use the file extension)
- -h, --help display this help
- --lock-wait duration wait up to duration to acquire a lock (syntax "1h5m30s")
- -l, --log string logs to a target instead of the console
- -n, --name string profile name (default "default")
- --no-ansi disable ansi control characters (disable console colouring)
- --no-lock skip profile lock file
- --no-prio don't set any priority on load: used when started from a service that has already set the priority
- -q, --quiet display only warnings and errors
- --theme string console colouring theme (dark, light, none) (default "light")
- --trace display even more debugging information
- -v, --verbose display some debugging information
- -w, --wait wait at the end until the user presses the enter key
-
-resticprofile own commands:
- version display version (run in verbose mode for detailed information)
- self-update update to latest resticprofile (use -q/--quiet flag to update without confirmation)
- profiles display profile names from the configuration file
- show show all the details of the current profile
- schedule schedule jobs from a profile (use --all flag to schedule all jobs of all profiles)
- unschedule remove scheduled jobs of a profile (use --all flag to unschedule all profiles)
- status display the status of scheduled jobs (use --all flag for all profiles)
- generate generate resources (--random-key [size], --bash-completion & --zsh-completion)
-
-
+resticprofile --help
```
A command is either a restic command or a resticprofile own command.
@@ -106,15 +71,16 @@ A command is either a restic command or a resticprofile own command.
There are not many options on the command line, most of the options are in the configuration file.
-* **[-h]**: Display quick help
-* **[-c | --config] configuration_file**: Specify a configuration file other than the default
+* **[-h | --help]**: Display quick help
+* **[-c | --config] configuration_file**: Specify a configuration file other than the default ("profiles")
* **[-f | --format] configuration_format**: Specify the configuration file format: `toml`, `yaml`, `json` or `hcl`
* **[-n | --name] profile_name**: Profile section to use from the configuration file.
You can also use `[profile_name].[command]` syntax instead, this will only work if `-n` is not set.
Using `-n [profile_name] [command]` or `[profile_name].[command]` both select profile and command and are technically equivalent.
-* **[--dry-run]**: Doesn't run the restic command but display the command line instead
+* **[--dry-run]**: Doesn't run the restic commands but display the command lines instead
* **[-q | --quiet]**: Force resticprofile and restic to be quiet (override any configuration from the profile)
* **[-v | --verbose]**: Force resticprofile and restic to be verbose (override any configuration from the profile)
+* **[--trace]**: Display even more debugging information
* **[--no-ansi]**: Disable console colouring (to save output into a log file)
* **[--no-lock]**: Disable resticprofile locks, neither create nor fail on a lock. restic locks are unaffected by this option.
* **[--theme]**: Can be `light`, `dark` or `none`. The colours will adjust to a
@@ -128,3 +94,4 @@ into a command or http hook by referencing it with `{{ tempDir }}/...` or `{{ te
This is only useful in Windows when resticprofile is started from explorer and the console window closes automatically at the end.
* **[resticprofile OR restic command]**: Like snapshots, backup, check, prune, forget, mount, etc.
* **[additional flags]**: Any additional flags to pass to the restic command line
+
diff --git a/docs/content/usage/keyfile/index.md b/docs/content/usage/keyfile/index.md
index dcb41151..8b31a124 100644
--- a/docs/content/usage/keyfile/index.md
+++ b/docs/content/usage/keyfile/index.md
@@ -9,15 +9,16 @@ weight: 10
resticprofile has a handy tool to generate cryptographically secure random keys encoded in base64. You can simply put this key into a file and use it as a strong key for restic.
- On Linux and FreeBSD, the generator uses `getrandom(2)` if available, `/dev/urandom` otherwise.
-- On OpenBSD, the generator uses `getentropy(2)`.
+- On OpenBSD and macOS, the generator uses `getentropy(2)`.
- On other Unix-like systems, the generator reads from `/dev/urandom`.
-- On Windows systems, the generator uses the CryptGenRandom API.
-- On Wasm, the generator uses the Web Crypto API.
+- On Windows systems, the generator uses the uses the RtlGenRandom API.
+- On JS/Wasm, the generator uses the Web Crypto API.
+- On WASIP1/Wasm, the generator uses `random_get` from `wasi_snapshot_preview1`.
[Reference from the Go documentation](https://golang.org/pkg/crypto/rand/#pkg-variables)
```shell
-$ resticprofile generate --random-key
+resticprofile generate --random-key
```
generates a 1024 bytes random key (converted into 1368 base64 characters) and displays it on the console
@@ -25,5 +26,5 @@ generates a 1024 bytes random key (converted into 1368 base64 characters) and di
To generate a different size of key, you can specify the bytes length on the command line:
```shell
-$ resticprofile generate --random-key 2048
+resticprofile generate --random-key 2048
```
diff --git a/docs/content/usage/locks/index.md b/docs/content/usage/locks/index.md
index b9341560..112d8b24 100644
--- a/docs/content/usage/locks/index.md
+++ b/docs/content/usage/locks/index.md
@@ -12,8 +12,8 @@ Since resticprofile can run several commands in a profile, it could be better to
For this to happen you can specify a lock file in each profile:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -35,7 +35,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -57,7 +57,7 @@ src:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"src" = {
@@ -80,7 +80,7 @@ src:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -123,8 +123,8 @@ For that matter, if you add the flag `force-inactive-lock` to your profile, rest
* **resticprofile locks**: Check for the presence of a process with the PID indicated in the lockfile. If it can't find any, it will try to delete the lock and continue the operation (locking again, running profile and so on...)
* **restic locks**: Evaluate if a restic command failed on acquiring a lock. If the lock is older than `restic-stale-lock-age`, invoke `restic unlock` and retry the command that failed (can be disabled by setting `restic-stale-lock-age` to 0, default is 1h).
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -138,7 +138,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -152,7 +152,7 @@ src:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"global" = {
@@ -166,7 +166,7 @@ src:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
@@ -200,8 +200,8 @@ Note: The lock wait duration is cumulative. If various locks in one profile-run
resticprofile can retry restic commands that fail on acquiring a lock and can also ask restic to unlock stale locks. The behaviour is controlled by 2 settings inside the `global` section:
-{{< tabs groupId="config-with-json" >}}
-{{% tab name="toml" %}}
+{{< tabs groupid="config-with-json" >}}
+{{% tab title="toml" %}}
```toml
version = "1"
@@ -216,7 +216,7 @@ version = "1"
```
{{% /tab %}}
-{{% tab name="yaml" %}}
+{{% tab title="yaml" %}}
```yaml
version: "1"
@@ -231,7 +231,7 @@ global:
```
{{% /tab %}}
-{{% tab name="hcl" %}}
+{{% tab title="hcl" %}}
```hcl
"global" = {
@@ -245,7 +245,7 @@ global:
```
{{% /tab %}}
-{{% tab name="json" %}}
+{{% tab title="json" %}}
```json
{
diff --git a/docs/content/usage/noroot/index.md b/docs/content/usage/noroot/index.md
new file mode 100644
index 00000000..870ff285
--- /dev/null
+++ b/docs/content/usage/noroot/index.md
@@ -0,0 +1,60 @@
+---
+title: "No root backup on Linux"
+date: 2022-05-16T20:26:09+01:00
+weight: 25
+hidden: true # for this to work we might need https://pkg.go.dev/kernel.org/pub/linux/libs/security/libcap/cap
+---
+
+{{%notice info %}}
+This section is mostly copied from the `restic` documentation:
+
+[Backing up your system without running restic as root](https://restic.readthedocs.io/en/latest/080_examples.html#backing-up-your-system-without-running-restic-as-root)
+{{% /notice %}}
+
+## Backing up your system without running resticprofile as root
+
+Creating a complete backup of a machine requires a privileged process that is able to read all files. On UNIX-like systems this is traditionally the root user. Processes running as root have superpower. They cannot only read all files but do also have the power to modify the system in any possible way.
+
+With great power comes great responsibility. If a process running as root malfunctions, is exploited, or simply configured in a wrong way it can cause any possible damage to the system. This means you only want to run programs as root that you trust completely. And even if you trust a program, it is good and common practice to run it with the least possible privileges.
+
+### Capabilities on Linux
+
+Fortunately, Linux has functionality to divide root’s power into single separate capabilities. You can remove these from a process running as root to restrict it. And you can add capabilities to a process running as a normal user, which is what we are going to do.
+
+### Full backup without root
+
+To be able to completely backup a system, restic has to read all the files. Luckily Linux knows a capability that allows precisely this. We can assign this single capability to restic and then run it as an unprivileged user.
+
+First we create a new user called restic that is going to create the backups:
+
+```shell
+useradd --system --create-home --shell /sbin/nologin restic
+```
+
+Then we download and install the **resticprofile** and **restic** binary into the user’s home directory (please refer to the respective installation sections). Let's save both binaries in the `~/bin` directory.
+
+Before we assign any special capability to the binaries, we restrict their permissions so that only root and the newly created restic user can execute them. Otherwise another - *possibly untrusted* - user could misuse the privileged binaries to circumvent file access controls.
+
+```shell
+chown root:restic ~restic/bin/restic
+chmod 750 ~restic/bin/restic
+chown root:restic ~restic/bin/resticprofile
+chmod 750 ~restic/bin/resticprofile
+```
+
+Finally we can use **setcap** to add an extended attribute to the binaries. On every execution the system will read the extended attribute, interpret it and assign capabilities accordingly.
+
+```shell
+setcap cap_dac_read_search=+ep ~restic/bin/restic
+setcap cap_dac_read_search=pie ~restic/bin/resticprofile
+```
+
+{{%notice warning %}}
+The capabilities of the **setcap** command only applies to this specific copy of the binaries. If you run `restic self-update` or in any other way replace or update the binaries, the capabilities you added above will not be in effect for the new binaries. To mitigate this, simply run the **setcap** commands again, to make sure that the new binaries have the same and intended capabilities.
+{{% /notice %}}
+
+From now on the user restic can run **resticprofile** to backup the whole system.
+
+```shell
+sudo -u restic /home/restic/bin/resticprofile backup
+```
diff --git a/docs/content/usage/version/index.md b/docs/content/usage/version/index.md
index 11a6835f..f0695aa0 100644
--- a/docs/content/usage/version/index.md
+++ b/docs/content/usage/version/index.md
@@ -4,8 +4,8 @@ date: 2022-05-16T20:21:01+01:00
weight: 5
---
-The `version` command displays resticprofile version. If run in vebose mode (using `--verbose` flag) additional information such as OS version or golang version or modules are displayed as well.
+The `version` command displays resticprofile version. If run in verbose mode (using `--verbose` flag) additional information such as OS version, golang version and modules are displayed as well.
```shell
-$ resticprofile --verbose version
+resticprofile --verbose version
```
\ No newline at end of file
diff --git a/docs/themes/hugo-theme-relearn b/docs/themes/hugo-theme-relearn
index 7916aec6..d33761c0 160000
--- a/docs/themes/hugo-theme-relearn
+++ b/docs/themes/hugo-theme-relearn
@@ -1 +1 @@
-Subproject commit 7916aec686c33175be4da6c6f4c447f44ed2cf17
+Subproject commit d33761c03fba02fa9cdf9f26382f3e90c3502910
diff --git a/run-flow.md b/run-flow.md
deleted file mode 100644
index 269764f7..00000000
--- a/run-flow.md
+++ /dev/null
@@ -1,47 +0,0 @@
-
-```mermaid
-flowchart TB
- PRB('run-before' from profile)
- PRA('run-after' from profile)
-
- subgraph Backup [ ]
- BRB('run-before' from backup section)
- BRA('run-after' from backup section)
- RUN(run restic backup with check and/or retention if configured)
- end
-
- subgraph Failure [ ]
- BFAIL('run-after-fail' from backup section)
- PFAIL('run-after-fail' from profile)
- end
-
- subgraph Finally [ ]
- direction TB
- BRF('run-finally' from backup section)
- PRF('run-finally' from profile)
- BRF --> PRF
- end
-
- PRB -->|Error| PFAIL
- PRB -->|Success| BRB
-
- BRB -->|Error| BFAIL
- BRB -->|Success| RUN
-
- RUN -->|Error| BFAIL
- RUN -->|Success| BRA
-
- BRA -->|Error| BFAIL
- BRA -->|Success| PRA
-
- BFAIL -->|Error| Finally
- BFAIL --> PFAIL
-
- PRA -->|Error| PFAIL
- PRA -->|Success| Finally
- PFAIL --> Finally
-
- style Backup fill:#9990,stroke:#9990
- style Failure fill:#9990,stroke:#9990
- style Finally fill:#9991,stroke:#9994,stroke-width:4px
-```