mythconverg_backup.pl - account for zero length backups during rotation

[white-haired-uncle]

Is your feature request related to a problem? Please describe.

I had a failing database backup. It failed a couple times while I was troubleshooting it, leaving 0 length backups. Then, when my third time was successful and it rotated out the old backups, those 0 length files counted toward my max of five copies. If I'd had a few more unsuccessful attempts, I'd be left with only one good backup (or perhaps one "good" backup, and none from before the problem started).

Successfully compressed backup to file:
/mythdata/mythdbbackup/mythconverg-1384-20250922005352.sql.gz

Rotating backups.

Searching for files matching pattern:
/mythdata/mythdbbackup/mythconverg-????-??????????????.sql*
 - Found 8 matching files.

Deleting 3 and keeping (up to) 5 backup files.
 - Deleting old backup file: /mythdata/mythdbbackup/mythconverg-1384-20250917064505.sql.gz
 - Deleting old backup file: /mythdata/mythdbbackup/mythconverg-1384-20250918065527.sql.gz
 - Deleting old backup file: /mythdata/mythdbbackup/mythconverg-1384-20250919063632.sql.gz
 - Keeping backup file: /mythdata/mythdbbackup/mythconverg-1384-20250920064427.sql.gz
 - Keeping backup file: /mythdata/mythdbbackup/mythconverg-1384-20250921063940.sql.gz
 - Keeping backup file: /mythdata/mythdbbackup/mythconverg-1384-20250922005145.sql
 - Keeping backup file: /mythdata/mythdbbackup/mythconverg-1384-20250922005156.sql
 - Keeping backup file: /mythdata/mythdbbackup/mythconverg-1384-20250922005352.sql.gz

$ ls -l /mythdata/mythdbbackup/
total 408600
-rw-rw-r-- 1 mythtv mythtv 206353300 Sep 20 06:46 mythconverg-1384-20250920064427.sql.gz
-rw-rw-r-- 1 mythtv mythtv 205509947 Sep 21 06:41 mythconverg-1384-20250921063940.sql.gz
-rw-rw-r-- 1 mythtv mythtv         0 Sep 22 00:51 mythconverg-1384-20250922005145.sql
-rw-rw-r-- 1 mythtv mythtv         0 Sep 22 00:51 mythconverg-1384-20250922005156.sql
-rw-rw-r-- 1 mythtv mythtv   6533592 Sep 22 00:53 mythconverg-1384-20250922005352.sql.gz

Describe the solution you'd like

In the case where the backup is 0 length, either remove the empty file upon failure or do not count it toward the max copies (I suspect the former is the much better approach).

Not sure what to do about backups that fail in the middle. I think it'd be a mistake to remove them on failure, something could well be better than nothing.

Maybe write the backup to foo.sql.tmp, rename it to foo.sql only when you're about to exit with status 0, and do not count x.tmp files towards the max backup copies when rotating? Not sure how the gzip factors in here.

Describe alternatives you've considered

timeshift

It's kind of an odd sequence of events that's going to be pretty rare, and hopefully you never need to do a restore anyway. BUT, when your backups are failing (or have just been failing) there's something wrong - which is the wrong time to be getting rid of the previous good backups.