Closed rdxmb closed 3 years ago
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.
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:
/var/otrs/backups
and /tmp
is the directory passed to /opt/otrs/scripts/backup.pl
/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.
@juanluisbaptiste so this is not a container problem but a bug in OTRS? Then I will open an issue there ...
no, it is a container bug because of the way otrs_backup.sh handles compressed backups.
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?
@juanluisbaptiste Could you please have a look at the PR?
Image and OTRS versions
juanluisbaptiste/otrs:6.0.28
env vars in kubernetes statefulset
Describe the issue Backup-files are not rotated as expected:
Expected behavior Backup-files are rotated / deleted after 2 days.