Recover from interrupted backup (disk full) with db backup?

Support
1

I have run into the problem documented previously in depth here:

I have reviewed the thread here which offers some potential ways to recover:

After having to redo a large week+ backup in the past due to db corruption issues I separately backup the database.

My question is if I restore the database to the last successful backup and remove the modified files from the interrupted backup will this work (there is only a single triplet of dlist/dindex/dblock)? I obviously could try this out and see without asking but just wanted to double check that I would not do anything destructive when doing this (will keep the current database/removed files of course).

Thanks in advance.

2

Welcome to the forum @DingoDaddy

On first reads, I thought you meant modified source files in backup, but now I think you mean new destination files. Duplicati doesn’t modify files generally – it uploads new ones with new filenames.

The single triplet is presumably the new files, so you’re considering plan of rolling back both sides which have to track – database and destination. This usually works, unless a compact rearranged destination files by repacking in new fuller ones and deleting old ones with too much space waste.

Typically, backup finds some change, uploads, version deletion may occur, then compact may run. Job logs show all this, but as yours ended mid-run, I suspect there’s no log file at its end to look at.

If what you have is a backup after the previous successful backup had ended, removing the three destination files uploaded since that end should work, but might not even be necessary. Restoring old database has a pitfall with what’s usually a feature of making database and destination match.

Destination file deletions of unknown-to-database files are done, which can produce quite a mess.

If my assumptions on your situation are right, you could either do manual delete or let Repair do it.

BUT (and it’s a big one), if that error just popped up last run, why might it not pop up on next run?

Here it gets deep, and may need expertise from developer or the first person you quoted, as it’s a reminder of a problem in the blocklist area that was only recently fixed. Here’s another post to see where the messages were a little different, but so was the sequence of operations that got done…

Which Duplicati are you using anyway? 2.0.8.1 Beta lacks the fix I’m pointing at, but 2.1.0.2 has it.

3

After studying the post to see why I had a feeling a disk had filled, now I find that in the title.

There should be plenty of warnings about that, unless disk is not accessed as a local folder.

Your original post cites a post that I didn’t read well, but did you see the disk filled up there?

Basically, I’m confused about the details of this.

EDIT:

Second citation supports interrupted backup too. First citation was not. It was self-check fail.

Maybe you can explain things in your own words, as the situations don’t seem to match well.

4

To be clearer, the disk on which the duplicati database resides became full, the destination where I am backing up to has never been full.

If my assumptions on your situation are right, you could either do manual delete or let Repair do it.

I have the dreaded update count = 0 error when attempting to do a repair.

as it’s a reminder of a problem in the blocklist area that was only recently fixed.

After the interrupted backup all new backup attempts result in “Failed: Found 1 file(s) with missing blocklist hashes”

if that error just popped up last run, why might it not pop up on next run?

The error above occurs on every execution after the backup was interrupted by the disk full issue.

Which Duplicati are you using anyway?

2.0.8.1

Unless a compact rearranged destination files by repacking in new fuller ones and deleting old ones with too much space waste.

This is unlikely as the source is fairly stable (mostly large collection of photos + key operating system/user data)

It’s very kind of of you to offer assistance so promptly!

Based on what I’ve laid out above do you continue to recommend 2.1.0.2? Just attempt a repair with it installed? Is there any chance this will render me unable to attempt the sync of the db and the backend should I need to fall back to that?

5

Is it possible to create a bug-report database and send it?
The bug-report should remove all path information and only contains hashes.
If it is too big or you are not comfortable with it, let’s see if we can figure out something else.

Yes, it does the same check, so that makes sense.

It should work. The previous database would only know the remote destination before the triplet was uploaded, so if you remove them and restore the database, it should be a perfect “roll back”.

There were a few of the issues fixed in 2.1.0.2, but I am not sure if the “Unexpected update count: 0” is fixed. I was looking through the old issues, but I am not sure if this is the same as what you experience?

Beware that upgrading to 2.1.0.2 requires some manual steps to go back to 2.0.8.1, but backup copies of the databases are created.