I made a mistake to use “Smart backup retention” instead of using “Keep all backups”. Is there any chance to get files restored from deleted days?
The last day available to restore from daily backups is 18th of November, but on the disk I can see those blocks and 14th in particular, which I really would like to get back.
Thanks for spending time to read and appreciate your possible answers. Thank you.
UPDATE: I managed to restore (with Testdisk) file *.dlist of 14th of November, unfortunately zipped file is corrupted.
Not by normal means, but by doing filesystem-level undelete you show you’re willing to go beyond that.
Unfortunately if you need Nov 14, the corrupted dindex is the only record of what files were at that date.
So doing the same thing for Nov 13 or Nov 15 wouldn’t help? Duplicati should also have older versions.
I’ll assume “last” means looking backwards through still-retained dailies. There should be a daily in the
Nov 11 to Nov 17 range though. About how many files would you prefer? Would you have room for all?
I afraid so, because the lost file was created on 13th and deleted before 15th. Daily backup ran 14th 5 AM like every day. So the only copy of the missing file should be in the 14th day backup.
There seems to be daily dblock/dindexes with those dates like the picture shows, but how can I get the file using those? Space is definitely not a problem, but my bad was to play around with “Keep all” and “Smart” settings. Totally my fault.
How the restore process works talks about how you start with the dlist (oops) and use its information.
The dlist knows that file and what blocks it needs. There is a small chance the dindex could also help.
If the file had more than 1 block (default 100 KB), the dlist would reference a blocklist which lives is in
a dblock file, but is by default redundantly stored in the dindex file so as to avoid blocklist downloading.
I think blocklists are in the “list” subfolder of the dindex. The question is which one is your desired file?
In theory one could look at adjacent dlist files to rule out a bunch of blocklists, and consider what’s left.
Are you so lucky that the file is either very short or very recognizable? You could search dblock blocks.
Compacting files at the backend is a risk, as the blocks of the file have became wasted space so may eventually get what’s still relevant in its dblock repacked (along with other partial ones) in a new dblock.
Your job logs will probably show if you’ve compacted. Consider turning on no-auto-compact, and also consider doing little on the system to prevent further data-losses-from-recycling at the filesystem level.
DB Browser for SQLite can look at a copy of your job database. In RemoteOperation table is file work.
While a job log shows how many files got deleted, it doesn’t name them. You may need more undelete.
Basically if you can find file blocklist and file blocks, in theory that’s how you get a file BUT it’s not easy.
EDIT:
If you’d rather not go right to the database, <job> → Show log → Remote shows a similar view if you’d
prefer to flip screens. Generally a backup is a set of dblock and dindex going out, with a dlist at the end.
Retention policy controls dlist deletions. A compact is dblock downloads, a dblock upload, and deletes, meaning you don’t know for sure from file dates what uploaded on the 14th, because compact can put remaining blocks in a new dblock. Image lacks any daily double dblocks, so maybe you’re in luck there.
