I have just tried my first backup with Duplicati on Ubuntu 20.04. The backup was to Google Drive and took several hours. I got two warnings on the backup and my test restore failed, again with another warning.
The backup appeared to complete normally, but the log had two warnings, both “Expected there to be a temporary fileset for synthetic filelist, but none was found”. When I chose a random file for a test restore I got another warning “Restore completed without errors but no files were restored”. I had chosen to keep the original file and rename the restored file with a timestamp.
I have been investigating the Warning " Restore completed without errors but no files were restored" when restoring from a backup created on Google Drive and it appears to be a bug. If the file to be restored exists in the target restore location then the warning appears irrespective of the setting of ’ How do you want to handle existing files?’ Restore works if the target file is deleted, renamed or moved to another location, or if a different restore location is selected.
I have set log-file-level to verbose, but this does not appear to effect the logging on Restore and the log file does not reveal the reason for the failure.
I am using Duplicati - 2.0.5.1_beta_2020-01-18 on Ubuntu 20.04.
The synthetic filelist is intended to be made at start of backup when previous backup was interrupted, meaning possibly you began and stopped one earlier before launching the first real backup. Possible?
The filelist, as its name implies, is the list of files in a backup. After an interrupted backup, you can get whatever was in the previous backup plus whatever was backed up before interruption. This is the list.
Above is how it should work, however it’s possible initial backup is different. There was also a bug that
manages to do one lookup incorrectly, thereby preventing the synthetic filelist. This got fixed in Canary.
This happens if you use “Original location”, and the file is already there, and everything is as requested.
The file is examined as it sits. If no action is needed to restore it to desired version, then none are done.
If restored file is different, it gets timestamped in your case. For Overwrite, original is patched in place.
“How do you want to handle existing files?” is irrelevant if file is already fine, but language is misleading. Overwrite has nothing to do if file is OK already. I’m pretty sure Duplicati optimizes out needless work.
One that can interfere with optimal restore testing is that restored file blocks are gotten locally if present unless –no-local-blocks is set true to force it to actually download from remote instead of using locals…
Thank you for taking the time to reply to my post.
I have attempted to recreate the “Expected there to be a temporary fileset for synthetic filelist, but none was found” error but it has not recurred in subsequent test backups, even when I attempted to completely remove Duplicati and its data using ‘sudo apt-get purge duplicati’ and then reinstalled. If it is fixed in the latest build I will not pursue it further.
The behaviour of Duplicati when one or more files to be restored already exist still appears to me to be a bug. In a real situation when a restore is needed it is quite likely that some, maybe even the majority of, the files selected to be restored will already exist on the target. Rather than generating, perhaps thousands, of warning messages regarding a situation that is in fact desired behaviour Duplicati should either generate Information messages (only displayed when log -level is set to verbose), or suppress them altogether.
I have just completed a test in which I used Duplicati to backup 50 GB to Google Drive and I verified every file. There were some discrepancies, but all were readily explainable, so I am confident to use Duplicati for my own backups.
The improper error is fixed in Canary and should eventually get to Beta, however if synthetic filelist is being attempted at all without some sort of prior interrupted backup (is it possible?) that may be a different issue.
I’m not sure how effectively purge will purge. For a fresh start on a backup, usually you use the UI to delete the database, and you manually delete the destination files. There’s more possible, but that’s usually good.
Duplicati configurations usually are in ~/.config/Duplicati if you ever need to do very serious Duplicati wipe.
Regardless, it sounds like it’s working for you. I’m not hearing other reports, so that may be good enough…
Where did this come from? You showed one at end of restore, right? Don’t assume it’s one for every file.
Messages at end of restore look like they’re as follows:
I’d agree with your questioning whether a somewhat normal outcome deserves Warning, not Information.
Feel free to file a GitHub issue on it, if you like, and maybe development will give it thought and/or change.
Original decisions are frequently difficult to understand fully, but more people pondering the plan is best…
