Context: I have lost recently more than 400Gb uploaded to Backblaze B2. I unfortunately and stupidly configured two backup jobs pointing to the same bucket in B2 (I didn’t create subfolders at that time within the bucket). When the latest job finished, it verified the data and destroyed everything. I had to cancel the job when I realized I went from 400Gb to 3Gb…
Suggestion: warn user when he is creating a job which use destination which is already existing in another job. If not possible to do this check, then highlight a warning in red so that people understand the risks.
Another alternative could be to force the option of appending a name to the backup files, so that at least these files are different and there is less risk of messing up.
Does B2 have any “history” or “restore” that you could use to restore the files into a different folder? You could then run the other job on the restored folder and it should “clean up” the unrecognized 3G from the other job…
As for the warning, I know that in the past (and presently with version 2.0.3.9) when going to save a job (on step 5 "Options) that points to a destination folder that already has files produces a not-quite-what-you-want confirmation message like this:
Do you recall getting a message like that at some point?
I’m using 2.0.3.3, and I don’t think I had this message - from memory - but it seems exactly what I was suggesting. I would, however, add in the text above that “configuring a second backup job in the same folder can mess up with the data of the two jobs”, so that it is perfectly clear.
Would be happy to use more recent version but fearing from loosing data as I recall only 2.0.3.3 has been marked as ‘official beta’ and not only Canary.
Ordinarily one gets at least this sort of error when the backend files are compared to the local database info:
Above is from using Windows File Explorer to make a duplicate copy of a dlist. Similar messages happen with other problems such as a new backup made from scratch, storing into the same folder. Because the file list is stored in a local database, that’s probably why questions are being asked about how new backup was set up. Duplicati has lots of buttons to hit, and perhaps this would be an opportunity to understand dangerous paths.
I haven’t tested, but the blue error box above makes me think that using an existing database suppresses the comparison error (because everything still compares), then changing the source selections to remove folders would keep future backups from backing them up. Unlike some other backup software though, this won’t chop the folder out of prior backups unless the retention setting drops them. Have you looked at Restore’s versions to see if there’s a trace of the previous files? Also look at the B2 bucket size, files, and maybe billing estimate.
I’m sorry this happened, but maybe we can learn. Logs might also help, but others read them better than I do.
For the moment I’d recommend staying at 2.0.3.3 beta (2.0.3.5 canary at most). The 2.0.3.6 version included a lot of multi-threading enhancements that we are still “recovering” from.
That would make sense - though your sample “Found 1 remote files…” message happens during the pre-backup destination verification step. Since that step can be disabled, hopefully we can better warn people about two backups in one folder during the setup process rather than at time of backup.
