Last night I accidentally nuked a NAS drive while setting up a redundant local disk (not my finest moment). Luckily, I had been running Duplicati to backup to Backblaze B2.
When I first setup the disk (now wiped), I took a backup via my desktop machine earlier in 2020. After that I plugged it into my NAS (a Raspberry Pi 3B+) and it’s been backing up daily ever since.
When I login to the Duplicati web portal on my NAS, it says “Last successful backup: Yesterday at 6:01 PM”), but when I go to recover the files, the earliest entry I see under “Restore from” is February 26th, 2020.
Most of the data should be available by that time, but I’m pretty sure I’ve added more files since then.
Is there a way to get more insight into this? Why does it show a successful backup yesterday, but the latest available option to recover is from February?
Just finished the restore and my files are looking great. I’ll be making a donation cause Duplicati really saved me.
While I’m ecstatic to have my files, might I suggest that in the case you mentioned, the dropdown items could say “February 26th, 2020 to September 20th, 2020” or some similar indication? That’d make it clear that Duplicati successfully ran, but noticed that nothing changed and decided not to persist a duplicate backup. I think that’d definitely be comforting to see while restoring files (a potentially stressful operation) and make Duplicati feel a bit more reliable.
Is GitHub Issues the best place to report and discuss a feature like that?
upload-unchanged-backups can be used to make the backup visible. There’s not a great space cost, because all of the backup data itself is deduplicated, i.e. new backup just points to the existing data…
This would write a dlist file to the backup to list the files (and point to the data), allowing retention of knowledge that a backup was done, even for Direct restore from backup files, or database Recreate.
Features are done sparingly these days (too few developer volunteers) so it’s best to use what exists.
There’s nothing I can think of in the database currently that directly gives you what you’re asking for…
There are also oddball cases like partial interrupted backups and synthetic backups (on next backup).
It should work with any retention policy, and retention will have more work to do (cleaning up versions that are the same). I actually thought of suggesting some retention policy, so I’m glad you are already thinking about it.
The feature is stable AFAIK, but it still confuses people who think it’s calendar time. It’s not, just time intervals.