setting OTRS_BACKUP_ROTATION has no effect

[rdxmb]

Image and OTRS versions

juanluisbaptiste/otrs:6.0.28

env vars in kubernetes statefulset

          env:
           - name: OTRS_DB_NAME
             value: otrs
           - name: OTRS_DB_HOST
             value: mariadb
           - name: OTRS_DB_USER
             value: otrs
           - name: OTRS_DB_PASSWORD
             value: XXXXXXXXXXXXXXXXXXX
           - name: MYSQL_ROOT_USER
             value: root
           - name: MYSQL_ROOT_PASSWORD
             value: XXXXXXXXXXXXXXXXXXXXXX
           - name: OTRS_ARTICLE_STORAGE_TYPE
             value: ArticleStorageFS
           - name: OTRS_SET_PERMISSIONS
             value: "skip-article-dir"
           - name: OTRS_NUMBER_GENERATOR
             value: "AutoIncrement"
           - name: OTRS_SENDMAIL_MODULE
             value: "SMTP"
           - name: OTRS_SMTP_SERVER
             value: 10.XX.0.XX
           - name: OTRS_SMTP_PORT
             value: "25"
           - name: OTRS_BACKUP_ROTATION
             value: "2"
           - name: OTRS_BACKUP_TYPE
             value: "fullbackup"
           - name: OTRS_BACKUP_TIME
             value: "18 19 * * *"
           - name: OTRS_DEBUG
             value: "yes"
           - name: TZ
             value: Etc/UTC

Describe the issue Backup-files are not rotated as expected:

-rwxr-xr-x 1 root root 23G May 14 07:58 otrs-2020-05-14_04-00-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul  8 00:18 otrs-2020-07-07_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul  9 00:13 otrs-2020-07-08_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 10 00:04 otrs-2020-07-09_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 11 00:09 otrs-2020-07-10_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 12 00:11 otrs-2020-07-11_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 13 00:09 otrs-2020-07-12_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 14 00:10 otrs-2020-07-13_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 15 00:15 otrs-2020-07-14_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 16 00:10 otrs-2020-07-15_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 17 00:14 otrs-2020-07-16_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 18 00:21 otrs-2020-07-17_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 19 00:21 otrs-2020-07-18_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 20 00:15 otrs-2020-07-19_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 21 00:24 otrs-2020-07-20_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 22 00:21 otrs-2020-07-21_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 23 00:28 otrs-2020-07-22_19-18-fullbackup.tar.gz
-rwxr-xr-x 1 root root 23G Jul 24 00:18 otrs-2020-07-23_19-18-fullbackup.tar.gz

Expected behavior Backup-files are rotated / deleted after 2 days.

[juanluisbaptiste]

Hi,

Could you please connect to the running container and run printenv ? env variables should be passed to the otrs_backup.sh script, on setup_backup_cron function there's:

    # Store in a file env vars so they can be sourced from the backup cronjob
    printenv | sed 's/^\(.*\)$/export \1/g' | grep -E "^export OTRS_" > /.backup.env
    # Remove string quotes

Which writes to a file all OTRS_* variables and then that file is sourced when invoking otrs_backup.sh:

echo "${OTRS_BACKUP_TIME} root . /.backup.env; ${OTRS_BACKUP_SCRIPT}" > ${OTRS_CRON_BACKUP_SCRIPT}

So if you specified that or any other OTRS_BACKUP_* variable they should be available on the backup script.

I will take a deeper look at the code.

[juanluisbaptiste]

Now I understand the issue. OTRS backup script /opt/otrs/scripts/backup.pl has these two parameters: -d to set the directory were backups are going to be stored, and -r to remove backups older than $OTRS_BACKUP_ROTATION days on the directory specified by -d. The otrs_backup.sh scripts sets -d to a temp directory and then tars and gzips the backup directory created by /opt/otrs/scripts/backup.pl, and moves it to /var/otrs/backups. So rotation will not work as it is because of two reasons:

1. Backups are stored in /var/otrs/backups and /tmp is the directory passed to /opt/otrs/scripts/backup.pl
2. I'm not a perl expert, but AFAIC /opt/otrs/scripts/backup.pl will only rotate directories and not files.

The only way I see it to get this feature working is by a) checking if /opt/otrs/scripts/backup.pl can rotate files in the directory specified with -d or, b) implement a separate rotation mechanism, but on this case it would be better to do rotation external to the container, for example using rotate-backups.

[rdxmb]

@juanluisbaptiste so this is not a container problem but a bug in OTRS? Then I will open an issue there ...

[juanluisbaptiste]

no, it is a container bug because of the way otrs_backup.sh handles compressed backups.

[rdxmb]

I see.

As the backup.pl does rotation for itselt, I would prefer to have the script "as-it-is" and leave the three backup parts as they are. As they are compressed by default with

BACKUP_COMPRESSION_METHOD="${OTRS_BACKUP_COMPRESSION:-gzip}"

I do not see a big benefit to tar them again, just to have only one file.

I think, this would be the easiest way to fix this. :) This also would have another benefit: As /var/otrs/backups is a mountpoint on a backup storage (the best way it is another mountpoint than /var/otrs/), actually the container has to copy (mv) the backup-files between the two file systems. In my simple case this is about 25 GB. In greater setups, it could be possible that /tmp in the container is not big enough to create the backup, even though there is enough space within the backup mountpoint.

What do you think?

[rdxmb]

@juanluisbaptiste Could you please have a look at the PR?