Your backup job exited 0 last night. How many files does the newest archive actually list?
Different question from the usual backup thread. Not whether you have them, but when you last opened one.
I built three tarballs on purpose a few days ago. One good, one zero bytes, one deliberately corrupt. Then ran the same line against each:
d=/your/backup/dir; f=$(ls -t "$d"/* | head -1); ls -lh "$f"; tar -tf "$f" 2>/dev/null | wc -l
The second number is the answer. Size tells you almost nothing on its own.
Zero bytes with zero entries means the job has been running every night and storing nothing. The one that worries me is 400MB with zero entries. That looks fine in ls, it looks fine in whatever is watching the job, and you find out on the day you need it.
Two things I had wrong before. I used tar -tzf out of habit, which fails quietly on zstd, and I read the empty output as me pointing at the wrong folder. Also, listing an archive only proves the container opens. Whether the database inside still reads is a separate question, and a separate command.
Curious how many of you actually open one, as opposed to checking the job exited 0.
Comments
I usually run my backups with Virtualmin scheduled backup as well as my own backup script. Both of these scripts do not list the backup size or number of files. So every month or so I'll go in and check manually on this. Instead of depending on scripts to report things, a little due diligence helps a lot.
More important question is, does your backup restore properly? Any custom nginx configurations or mail server settings (or even mail aliases) do not get backed up so when trying to restore, these will not get restored. How are you handling these?
Fair. wc -l only proves the archive opens, it says nothing about a restore. What I do next is pull one sqlite file out of the newest archive into /tmp and run PRAGMA integrity_check on it. That caught something I had wrong: I used to check whether the first 16 bytes read SQLite format 3, and a complete 8192 byte db and one truncated to 200 bytes both print exactly that, so it never fired on the broken case. On nginx configs and mail aliases I've got nothing useful, I don't run Virtualmin. The archive can list a thousand files and still be short the ones you actually need.
And those are just the ones I ran into when trying to restore. Dunno how many more configs I might miss until I try my next restore
Best would be to clone the VM image and restore it, but then since the IPs are no longer the same, it still causes issues with routing and certificates... Well, I guess what I am trying to say is no solution is perfect when running on low budget!