Start formalizing how new features are flagged by version in documentation.
This commit is contained in:
parent
dfc4db1860
commit
cc32f0018b
6 changed files with 29 additions and 15 deletions
2
NEWS
2
NEWS
|
@ -1,5 +1,5 @@
|
|||
1.6.4.dev0
|
||||
* #546: Keep your repository passphrases and database passwords outside of borgmatic's
|
||||
* #546, #382: Keep your repository passphrases and database passwords outside of borgmatic's
|
||||
configuration file with environment variable interpolation. See the documentation for more
|
||||
information: https://torsion.org/borgmatic/docs/how-to/provide-your-passwords/
|
||||
|
||||
|
|
|
@ -28,6 +28,8 @@ hooks:
|
|||
- umount /some/filesystem
|
||||
```
|
||||
|
||||
<span class="minilink minilink-addedin">New in version 1.6.0</span>
|
||||
|
||||
The `before_backup` and `after_backup` hooks each run once per repository in a
|
||||
configuration file. `before_backup` hooks runs right before the `create`
|
||||
action for a particular repository, and `after_backup` hooks run afterwards,
|
||||
|
|
|
@ -74,8 +74,10 @@ See [Borg's check documentation](https://borgbackup.readthedocs.io/en/stable/usa
|
|||
|
||||
### Check frequency
|
||||
|
||||
As of borgmatic 1.6.2, you can optionally configure checks to run on a
|
||||
periodic basis rather than every time borgmatic runs checks. For instance:
|
||||
<span class="minilink minilink-addedin">New in version 1.6.2</span>
|
||||
|
||||
You can optionally configure checks to run on a periodic basis rather than
|
||||
every time borgmatic runs checks. For instance:
|
||||
|
||||
```yaml
|
||||
consistency:
|
||||
|
|
|
@ -53,10 +53,11 @@ borgmatic info
|
|||
|
||||
### Searching for a file
|
||||
|
||||
<span class="minilink minilink-addedin">New in version 1.6.3</span>
|
||||
|
||||
Let's say you've accidentally deleted a file and want to find the backup
|
||||
archive(s) containing it. `borgmatic list` provides a `--find` flag for
|
||||
exactly this purpose (as of borgmatic 1.6.3). For instance, if you're looking
|
||||
for a `foo.txt`:
|
||||
exactly this purpose. For instance, if you're looking for a `foo.txt`:
|
||||
|
||||
```bash
|
||||
borgmatic list --find foo.txt
|
||||
|
|
|
@ -123,11 +123,7 @@ Once this include gets merged in, the resulting configuration would have a
|
|||
`keep_hourly` value of `24` and an overridden `keep_daily` value of `5`.
|
||||
|
||||
When there's an option collision between the local file and the merged
|
||||
include, the local file's option takes precedence. And as of borgmatic 1.6.0,
|
||||
this feature performs a deep merge, meaning that values are merged at all
|
||||
levels in the two configuration files. Colliding list values are appended
|
||||
together. This allows you to include common configuration—up to full borgmatic
|
||||
configuration files—while overriding only the parts you want to customize.
|
||||
include, the local file's option takes precedence.
|
||||
|
||||
Note that this `<<` include merging syntax is only for merging in mappings
|
||||
(configuration options and their values). But if you'd like to include a
|
||||
|
@ -139,6 +135,17 @@ global level, another `<<` within each configuration section, etc. (This is a
|
|||
YAML limitation.)
|
||||
|
||||
|
||||
### Deep merge
|
||||
|
||||
<span class="minilink minilink-addedin">New in version 1.6.0</span>
|
||||
|
||||
borgmatic performs a deep merge of merged include files, meaning that values
|
||||
are merged at all levels in the two configuration files. Colliding list values
|
||||
are appended together. This allows you to include common configuration—up to
|
||||
full borgmatic configuration files—while overriding only the parts you want to
|
||||
customize.
|
||||
|
||||
|
||||
## Configuration overrides
|
||||
|
||||
In more complex multi-application setups, you may want to override particular
|
||||
|
|
|
@ -13,11 +13,12 @@ treating those secrets like any other option value. But if you'd rather store
|
|||
them outside of borgmatic, whether for convenience or security reasons, read
|
||||
on.
|
||||
|
||||
As of version 1.6.4, borgmatic supports interpolating arbitrary environment
|
||||
variables directly into option values in your configuration file. That means
|
||||
you can instruct borgmatic to pull your repository passphrase, your database
|
||||
passwords, or any other option values from environment variables. For
|
||||
instance:
|
||||
<span class="minilink minilink-addedin">New in version 1.6.4</span>
|
||||
|
||||
borgmatic supports interpolating arbitrary environment variables directly into
|
||||
option values in your configuration file. That means you can instruct
|
||||
borgmatic to pull your repository passphrase, your database passwords, or any
|
||||
other option values from environment variables. For instance:
|
||||
|
||||
```yaml
|
||||
storage:
|
||||
|
@ -47,6 +48,7 @@ hooks:
|
|||
This uses the `MY_DATABASE_PASSWORD` environment variable as your database
|
||||
password.
|
||||
|
||||
|
||||
### Interpolation defaults
|
||||
|
||||
If you'd like to set a default for your environment variables, you can do so with the following syntax:
|
||||
|
|
Loading…
Reference in a new issue