asif/MailcowBackup
1
0
Fork 0
Code Issues Releases 10 Wiki Activity

Asif Bacchus 2020-05-24 02:20:32 -06:00
parent c1b93ba383
commit bbc6b3020e
1 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
4.0-Configuration-files.md

@ -1,6 +1,4 @@
## configuration files # backup.details file
### backup.details file
This file contains all the data needed to access your borg remote data repo. The included sample file is **fully commented** and should be fairly simple for you to customize. Blank lines and those starting with a '#' are ignored. This script assumes you are adhering to generally accepted security best-practices and using SSH keys to access your repo along with a password and/or repo-key. **No provision** has been made for SSH access via password or a non-encrypted repo which does not at least require a password. ALL configuration keys are required except the following: This file contains all the data needed to access your borg remote data repo. The included sample file is **fully commented** and should be fairly simple for you to customize. Blank lines and those starting with a '#' are ignored. This script assumes you are adhering to generally accepted security best-practices and using SSH keys to access your repo along with a password and/or repo-key. **No provision** has been made for SSH access via password or a non-encrypted repo which does not at least require a password. ALL configuration keys are required except the following:
@ -28,26 +26,30 @@ chown root:root ./backup.details
chmod 600 ./backup.details chmod 600 ./backup.details
``` ```
#### borgRepoPassphrase ## borgRepoPassphrase
If you leave the *borgRepoPassphrase* parameter undefined, the script will insert a dummy passphrase for you. In the case of an unencrypted repo, I have no idea if borg checks this dummy passphrase and fails or simply ignores it and happily continues. I have no idea because I've never tested an unencypted repo and, really, you shouldn't be running in such a configuration! Sorry, I won't test this corner case unless I have several requests to do so and implement support for this feature. File an issue if you need this functionality. For reference, a dummy passphase is inserted because otherwise borg sits waiting (literally) forever for a passphrase to be supplied. With a dummy passphrase, it just fails and issues an error which allows the script to exit properly and log the error. If you leave the *borgRepoPassphrase* parameter undefined, the script will insert a dummy passphrase for you. In the case of an unencrypted repo, I have no idea if borg checks this dummy passphrase and fails or simply ignores it and happily continues. I have no idea because I've never tested an unencypted repo and, really, you shouldn't be running in such a configuration! Sorry, I won't test this corner case unless I have several requests to do so and implement support for this feature. File an issue if you need this functionality. For reference, a dummy passphase is inserted because otherwise borg sits waiting (literally) forever for a passphrase to be supplied. With a dummy passphrase, it just fails and issues an error which allows the script to exit properly and log the error.
#### borgKeyfileLocation ## borgKeyfileLocation
If you skip this parameter, borg will use its internal default location in the event it requires a key file to access your repo. This is only relevant for repos created using the *keyfile* option since *repokey* locations store the key within the repo itself and rely solely on the passphrase for decryption. If you are using a *keyfile* style repo and store your keys in a non-default location, this configuration key is **required**. If you skip this parameter, borg will use its internal default location in the event it requires a key file to access your repo. This is only relevant for repos created using the *keyfile* option since *repokey* locations store the key within the repo itself and rely solely on the passphrase for decryption. If you are using a *keyfile* style repo and store your keys in a non-default location, this configuration key is **required**.
#### borgXtraListPath ## borgXtraListPath
Please see [page 4.1](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.1-Extra-backup-locations) in this wiki. Please see [page 4.1](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.1-Extra-backup-locations) in this wiki.
#### borgExcludeListPath ## borgExcludeListPath
Please see [page 4.2](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.2-Excluded-backup-locations) in this wiki. Please see [page 4.2](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.2-Excluded-backup-locations) in this wiki.
#### borgPruneSettings ## borgPruneSettings
If you omit this, the script will **not** run borg prune to remove old archives within your repo. Running borg prune is highly recommended to control the history and size of your repo, but if you want to skip this operation then simply comment-out this configuration key. I've provided a few examples and notes on [page 4.3](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.3-Prune-timeframe-examples) but please also refer to the [borg prune documentation](https://borgbackup.readthedocs.io/en/stable/usage/prune.html) for details about how to set this configuration key if you want the script to automatically run borg prune. If you omit this, the script will **not** run borg prune to remove old archives within your repo. Running borg prune is highly recommended to control the history and size of your repo, but if you want to skip this operation then simply comment-out this configuration key. I've provided a few examples and notes on [page 4.3](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.3-Prune-timeframe-examples) but please also refer to the [borg prune documentation](https://borgbackup.readthedocs.io/en/stable/usage/prune.html) for details about how to set this configuration key if you want the script to automatically run borg prune.
#### borgRemote ## borgRemote
If your remote server does not support running the borg server-side component, then you can omit this configuration key. This will result in much slower performance, so I'd suggest talking to your provider if this is the case. If your remote server does not support running the borg server-side component, then you can omit this configuration key. This will result in much slower performance, so I'd suggest talking to your provider if this is the case.
## examples
I've provided few examples of using the configuration details file on [page 4.4](https://git.asifbacchus.app/asif/MailcowBackup/wiki/4.4-Configuration-examples). If you're stuck, file an issue and I'll try to help you out.