Backup docs using wrong env variable name

Friend_LGA

Well…. making an issue for the mailcow is a nightmare, so I am posting here.

While reading the docs in the Backup strategy with rsync and mailcow backup script section I noticed that in the cronjob code snipped BACKUP_LOCATION instead of MAILCOW_BACKUP_LOCATION is used.

Is it intentional?

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
25 1 * * * rsync -aH --delete /opt/mailcow-dockerized /external_share/backups/mailcow-dockerized
40 2 * * * rsync -aH --delete /var/lib/docker/volumes /external_share/backups/var_lib_docker_volumes
5 4 * * * cd /opt/mailcow-dockerized/; BACKUP_LOCATION=/external_share/backups/backup_script /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup mysql crypt redis --delete-days 3
# If you want to, use the acl util to backup permissions of some/all folders/files: getfacl -Rn /path

Exactly this line

5 4 * * * cd /opt/mailcow-dockerized/; BACKUP_LOCATION=/external_share/backups/backup_script

accolon

The backup script uses BACKUP_LOCATION internally, MAILCOW_BACKUP_LOCATION just seems to be a more meaningful alternative. I guess it can be used for cases where BACKUP_LOCATION could cause problems (e.g. as system-wide variable) which is not the case for the cronjob.

If the longer variable is set, the script simply assigns its value to BACKUP_LOCATION:
https://github.com/mailcow/mailcow-dockerized/blob/d20df7d73eccfb13fc8c71bf74552eda27a9c6c1/helper-scripts/backup_and_restore.sh#L6

Friend_LGA

I see, thanks!