Creating zipped backups leads to endless loops

Running a backup from the command line on an AWS EC2 instance with the -z option to zip the resulting backup file will consume all free space on the disk.

For example:

sudo /opt/magnolia/backups/magnolia-module-backup-2.1.2/bin/backup -c /opt/magnolia/release/jackrabbit-bundle-mysql-search.xml -r /opt/magnolia/repository/magnolia -t /tmp/magnolia-TEST -z

results in:

[ec2-user@ip-172-31-6-135 magnolia-TEST]$ ls -l
total 2016128
rw-rr- 1 root root 2064489347 Dec 1 15:11 magnolia-TEST.zip
drwxr-xr-x 7 root root 4096 Dec 1 15:09 repository
rw-rr- 1 root root 6132 Dec 1 15:09 repository.xml
drwxr-xr-x 3 root root 4096 Dec 1 15:09 version
drwxr-xr-x 31 root root 4096 Dec 1 15:09 workspaces
[ec2-user@ip-172-31-6-135 magnolia-TEST]$ ls -l
total 2042376
rw-rr- 1 root root 2091368222 Dec 1 15:11 magnolia-TEST.zip
drwxr-xr-x 7 root root 4096 Dec 1 15:09 repository
rw-rr- 1 root root 6132 Dec 1 15:09 repository.xml
drwxr-xr-x 3 root root 4096 Dec 1 15:09 version
drwxr-xr-x 31 root root 4096 Dec 1 15:09 workspaces
[ec2-user@ip-172-31-6-135 magnolia-TEST]$ ls -l
total 2071232
rw-rr- 1 root root 2120916992 Dec 1 15:11 magnolia-TEST.zip
drwxr-xr-x 7 root root 4096 Dec 1 15:09 repository
rw-rr- 1 root root 6132 Dec 1 15:09 repository.xml
drwxr-xr-x 3 root root 4096 Dec 1 15:09 version
drwxr-xr-x 31 root root 4096 Dec 1 15:09 workspaces
[ec2-user@ip-172-31-6-135 magnolia-TEST]$ ls -l
total 2097516
rw-rr- 1 root root 2147828273 Dec 1 15:11 magnolia-TEST.zip
drwxr-xr-x 7 root root 4096 Dec 1 15:09 repository
rw-rr- 1 root root 6132 Dec 1 15:09 repository.xml
drwxr-xr-x 3 root root 4096 Dec 1 15:09 version
drwxr-xr-x 31 root root 4096 Dec 1 15:09 workspaces
[ec2-user@ip-172-31-6-135 magnolia-TEST]$ ls -l
total 2133372
rw-rr- 1 root root 2184547830 Dec 1 15:11 magnolia-TEST.zip
drwxr-xr-x 7 root root 4096 Dec 1 15:09 repository
rw-rr- 1 root root 6132 Dec 1 15:09 repository.xml
drwxr-xr-x 3 root root 4096 Dec 1 15:09 version
drwxr-xr-x 31 root root 4096 Dec 1 15:09 workspaces

EC2 instance info:

uname -a:
Linux ip-172-31-16-246 4.9.62-21.56.amzn1.x86_64 #1 SMP Thu Nov 16 05:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Note: this works fine for me on Mac OS X.

Another note: the obvious workaround for this is to zip the backup directory after the backup is finished and unzip when restoring. However, this adds adds a couple of extra steps in orchestrating the startup of a Magnolia instance, but it would simplify the orchestration if one could directly create zipped backup files.