Backup/restore bugs?

Support
1

I’m doing some experiments with Duplicati before commiting to it, and I have to say I like it a lot, but there are a couple issues I found.

  1. During testing, I backed up a remote directory using FTP. then I manualy deleted the backup files and made a new backup definition using a \server\filepath\ to backup them up again. Then, I deleted the first backup definition, and told it to delete the files along with the DB. It did, even though those files were not from that saveset. Granted, this is not something you would expect to occur often, but it seems like it should be confirming that the files actually belong to the backup being removed.

  2. I then attempted to restore the files from the second backup, knowing that the files no longer existed. The restore produced the error you’d expect, but then ended by telling me the restore was successful.

Not terminal issues, but I thought I’d bring them up.

Thanks!

2

Hello @mtsgsd, welcome to the forum - and thanks for trying out Duplicati!

Regarding your first issue I’m gong to guess you’re using the 2.0.2.1 beta (or early canary) version, yes? If so, that’s a known and fixed issue in later versions.

Your second issue is actually a feature. Since Duplicati keeps a local database record of what’s been backed up, during a restore it will compare what has most recently been backed up against the current live files.

If the local file hasn’t changed since it was last backed up then the restore is done from the local file as that will almost surely be faster than a restore from a remote location.

To tell Duplicati to ONLY use the remote files during a restore (useful for testing like you’re doing) you should enable the --no-local-blocks parameter.

3

Thanks for the quick reply! Yes, I’m using 2.02.1

I didn’t explain myself well enough for the second point I think. The savesets were from a remote location (file server), and were deleted in step 1. I then attempted to restore the files to a new (local) location (original files haven’t been touched, I wanted to see how Duplicati would respond to missing savesets).

It produced an error that the saveset was missing (correct) and that the restore completed successfully (incorrect, no files were created at the new location).

So when you say that it would use the local file, in my case the only local file would be the saveset which does not exist. Only the original files on the remote server exist.

If what I’m doing sounds strange, I am using Duplicati on my windows PC to backup filesets to a linux server using Minio S3 emulation, and also backing up files that only exist on the linux server to my windows PC using the same copy of Duplicati on my PC. Unless this is a bad practice?

Thanks for the help!

4

I agree, some of the verbiage / output messages need a bit of work. I think I noticed something like this before.

5

Ok. That does not match with my understanding of hotter it should work. If I wanted to replicate your test would this make sense?

  1. Create test backup of local files to a local destination (for testing ease & speed)
  2. Delete all the “duplicati-*” files from the dedication
  3. Try a restore to somewhere other than the original location
6

I tried it again just manually deleting the files and restoring back to the original location. Same result as shown here.

Capture
Capture.PNG1304×961 30.8 KB

It’s a minor thing since there’s no doubt there was an error. I just picked up some persnickety habits from an old QA job. :slight_smile:

7

Ahhh, I think I get it now. You’re saying there’s conflicting responses - one that “Your folders have been restored successfully” (which they haven’t been) and an error message that “Found 3 files that are missing from the remote storage” (which they are).

Assuming I’ve got that right, I suppose you would prefer a message like “There was a problem restoring your files” or something similar? :wink:

Oh, and I was able to replicate the problem - thanks for pointing it out! :slight_smile: