Package: autopostgresqlbackup Version: 1.1-1 Severity: critical Tags: upstream Justification: causes serious data loss
Due to a human error, today I had to resort to backups to recover data from a PostgreSQL database. In the worst possible moment, I realised that ALL of the backups we had of this database are useless. Turns out that when dumping the database to a huge text file, the system was running out of disk space, and so the file is truncated. Instead of detecting the problem, aborting the backup, and sending an email to the administrator, autopostgresqlbackup assumes the dump finished well, proceeded to compress the truncated dump, and continued as if nothing had happened. This had been going on for months without me realising, and so I have no useful backup. I am setting the severity as critical, because this bug has made me lose real world data today. The sad part is that the bug is pretty trivial to fix: all commands should be checked for non-zero return codes, probably by setting the '-e' flag at the beginning of the script. I can't believe this has gone this long without anybody noticing, and how many people might be trusting this tool for their backups. I'd say this deserves to be fixed in stable too. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages autopostgresqlbackup depends on: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii postgresql-client-common 200+deb10u3 Versions of packages autopostgresqlbackup recommends: pn heirloom-mailx | biabam | mutt <none> ii openssl 1.1.1d-0+deb10u2 Versions of packages autopostgresqlbackup suggests: ii bzip2 1.0.6-9.2~deb10u1 ii xz-utils 5.2.4-1 -- no debconf information
