[GH-ISSUE #191] Backup reports success even when mailbox TGZ export is 0 bytes (silent data loss) #156

New issue

Open

opened 2026-02-27 08:14:38 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 08:14:38 +03:00

Owner

Originally created by @linuxgokan on GitHub (Jan 26, 2026).
Original GitHub issue: https://github.com/lucascbeyeler/zmbackup/issues/191

Hello,

We are using zmbackup from this repository in production and encountered a very dangerous silent failure scenario. The backup process reports success, sessions are marked as completed, no errors are thrown, but the actual mailbox backup file is 0 bytes and gets removed by the script.
This causes false-positive successful backups while no data is actually saved.

if [ -s "$TEMPDIR"/"$1".tgz ] then logger ... "finished." else logger ... "finished, but the file is empty. Removing..." rm -rf "$TEMPDIR"/"$1".tgz fi export ERRCODE=0

Even when the TGZ file is empty, the script:

Deletes the file
Sets ERRCODE=0
Continues as if the backup succeeded

Later in __backupFullInc():

if [ "$ERRCODE" == "0" ] then SessionAction.sh add_account ...
This marks the account as successfully backed up in the session.
(Os: U22.04 LTS, Version: Zimbra Foss 10.1.15)

Why this is critical

This results in:
Session shows SUCCESS
No errors in logs
No data backed up
Admin assumes backups are working
This is silent data loss and very hard to detect.

This is especially dangerous because administrators will trust the backup status without realizing no mailbox data was saved.

Originally created by @linuxgokan on GitHub (Jan 26, 2026). Original GitHub issue: https://github.com/lucascbeyeler/zmbackup/issues/191 Hello, We are using zmbackup from this repository in production and encountered a very dangerous silent failure scenario. The backup process reports success, sessions are marked as completed, no errors are thrown, but the actual mailbox backup file is 0 bytes and gets removed by the script. This causes false-positive successful backups while no data is actually saved. `if [ -s "$TEMPDIR"/"$1".tgz ] then logger ... "finished." else logger ... "finished, but the file is empty. Removing..." rm -rf "$TEMPDIR"/"$1".tgz fi export ERRCODE=0 ` **Even when the TGZ file is empty, the script:** - Deletes the file - Sets ERRCODE=0 - Continues as if the backup succeeded Later in __backupFullInc(): `if [ "$ERRCODE" == "0" ] then SessionAction.sh add_account ... ` This marks the account as successfully backed up in the session. (Os: U22.04 LTS, Version: Zimbra Foss 10.1.15) Why this is critical **This results in:** Session shows SUCCESS No errors in logs No data backed up Admin assumes backups are working This is silent data loss and very hard to detect. This is especially dangerous because administrators will trust the backup status without realizing no mailbox data was saved.

kerem commented

2026-02-27 08:14:38 +03:00

Author

Owner

@FlorianHeigl commented on GitHub (Feb 18, 2026):

Hi,

for investigation - does it happen with full backups also?
I was dumping backups to bacula and had the same issue, reason was that the zimbra api returns an empty blob if you ask for a time delta (incremental) backup if the account in question didn't receive a mail.
mathematically certainly correct, but mostly a proof that it's an unsuitable backup format being used by zimbra.

@FlorianHeigl commented on GitHub (Feb 18, 2026): Hi, for investigation - does it happen with full backups also? I was dumping backups to bacula and had the same issue, reason was that the zimbra api returns an empty blob if you ask for a time delta (incremental) backup if the account in question didn't receive a mail. mathematically certainly correct, but mostly a proof that it's an unsuitable backup format being used by zimbra.