-
-
Notifications
You must be signed in to change notification settings - Fork 0
Environment variables
Settings in docker-backup are changed using environment variables.
To change an environment variable, simply assign it a new value in the environment: section of your docker-compose.yml.
Example of how to set the CREATE_CHECKSUMS environment variable to false:
version: "3.7"
services:
backup:
image: niclaslindstedt/docker-backup:latest
volumes:
- nginx-config:/volumes/nginx-config
- /mnt/data/backups:/backup
- /mnt/nas/backups:/lts
environment:
- CREATE_CHECKSUMS=false
Default: tgz
The type of archive you want your backups to be stored using. If you need to keep permissions on your backups intact, use the tgz archive type, which is the default one. If you have a lot of similar files, you should use the 7z archive type, since it is very good at compressing similar files.
Should be one of the following: tgz zip rar 7z
Default: 30
The amount of gigabytes that the backup script should respect before creating a new backup.
The backup script will estimate how much disk space the backup will require, and check whether the /backup directory can handle the backup without exceeding this limit. If the backup cannot be created without exceeding the limit, it will remove the oldest backup in the /backup directory to make space for the new backup.
Default: UTC
The timezone used for setting timestamps on the backups.
See Wikipedia for a comprehensive list of timezones (TZ database name).
Default: false
Set to true if you don't want the scripts to ask for your confirmation, e.g. when restoring a backup.
Useful for automation, e.g. if you want to restore something through a script and don't want to interact with the restore script.
Default: 0 5 * * * (at 5:00 am every day)
The cron schedule that triggers the backup script, which will create backups of all folders inside the /volumes directory.
Default: 0 9 * * * (at 9:00 am every day)
The cron schedule that triggers the store script, which will copy the latest backup of each folder in the /volumes directory to the /lts directory for long-term storage.
Default: 0 3 * * * (at 3:00 am every day)
The cron schedule that triggers the prune script, which will purge old backups (as determined by KEEP_BACKUPS_FOR_DAYS) and prune backups from the long-term storage, configured using the environment variables below.
To efficiently use your disk space, you might want to prune your older backups so that you don't keep one backup per hour for backups that are years old.
Use the environment variables below to tweak backup pruning to fit your needs.
Default: true
Enables the long-term storage functionality. If this is disabled (by setting it to any value other than true), no backups will be copied to the /lts folder, and thus they will only be kept as long as the KEEP_BACKUPS_FOR_DAYS variable dictates.
Default: true
Enables pruning of old backups. If this is disabled (by setting it to any value other than true), no backups will ever be removed by the prune script.
Default: 30
Determines for how many days you wish to keep backups in the /backup directory. Since the backup cron schedule can be set to any interval, this directory can become large quite quickly.
If this is set to e.g. 30, the prune script will remove any backups in the /backup folder that is older than 30 days. If you take backups often and/or your backups are large in size, you might want to reduce this number to save disk space.
Default: 24
Once a backup is this old (in hours), the prune script will start removing all backups except for the first backup of the day.
If this is set to 24, any backups copied to /lts (as determined by the CRON_LTS variable) will be kept for a minimum of 24 hours.
Default: 14
Once a backup is this old (in days), the prune script will start removing all backups except for the first backup of the week.
Note: The script counts Monday as the first day of the week.
Default: 4
Once a backup is this old (in weeks), the prune script will start removing all backups except for the first backup of the month.
Default: 6
The amount of months to keep long-term backups.
If this is set to e.g. 12, the long-term backups in /lts will be kept for a maximum of 12 months, and then they will be deleted.
If you're storing your backups on systems that you do not trust, you should definitely encrypt your backups.
Default: false
Set this to true if you want to have your backups encrypted after being compressed. If you want to restore your backups, you should use the restore script, and do not change the filename of your backup or the system might not automatically understand that your backup was encrypted during backup.
An encrypted backup will have an .enc file extension.
If you're using encryption (above), you need to set a password. Keep in mind that this password will currently be stored in clear text on your backup host. Encrypting backups is currently mainly a way of protecting them if you keep them stored in a different location (e.g. long-term storage in S3).
This variable needs to be at least 30 characters long if used. Turn this check off by setting SKIP_PASSWORD_LENGTH_CHECK to false.
Default: AES256
The encryption algorithm used to encrypt files.
Should be one of the following: IDEA CAST5 BLOWFISH AES256 TWOFISH CAMELLIA256
To make sure your backups have intact integrity, you should enable the creation and verification of checksums.
Default: true
Enables the creation of checksums (.sfv files) during backup. Will create an .sfv file for both your backup and your encrypted backup (if you use encrypted backups), and verify them both when restoring them.
Default: true
Enables the verification of checksums (when available). If a checksum is not valid, the backup will not be restored (to prevent it messing up your data). This is to ensure that the files haven't been damaged during transmission.
Default: false
Enables the creation of signatures (.sig files) during backup. Will create a .sig file for each of the .sfv checksum file that is generated.
Default: false
Enables the verification of signatures (when available). If a signature is not valid, the backup will not be restored, since the checksum file has likely been tampered with (and thus also your backup file).
If you're running a database or similar, you might want the backup script to stop the database container before performing a backup.
This functionality is only supported by the -docker tagged images (e.g. latest-docker).
This variable is used to help the backup script understand what the Docker containers running is named.
If the folder containing your docker-compose.yml file is named my_project, you should set the PROJECT_NAME variable to my_project.
It will then assume that all containers running in this project are called my_project_<service_name>_1.
A list of container names (comma-separated) that should be paused during backup.
If this is set to e.g. mysql, game-engine it will pause containers mysql and game-engine before making a backup.
The following variables adjust the amount of information that is sent to the standard output.
Default: 2
Set to a value between 0 and 5, 0 gives you the bare essentials and 5 is the most verbose. If you want to understand more of what is happening during the backup process, try increasing this number.
Default: false
Set to true to enable debug logging. This will only be useful if you are a developer. Otherwise it will just be cluttering your output with garbage.