On Monday I updated five Win10 Pro hosts to Version 2004. A day later, I got a notification from all of them indicating that I needed to run repair. Below is sample output from one of those hosts:
Failed: Found 420 remote files that are not recorded in local storage, please run repair
Details: Duplicati.Library.Interface.UserInformationException: Found 420 remote files that are not recorded in local storage, please run repair
at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.d__20.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at CoCoL.ChannelExtensions.WaitForTaskOrThrow(Task task)
at Duplicati.Library.Main.Controller.<>c__DisplayClass14_0.b__0(BackupResults result)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Action`1 method)
The repair appeared to run without a hitch and exited normally. However, today I am greeted with the same backup error reports as before. The only thing I can think to do at this point is to blow away the existing backups for each failing host up on Google Drive and just rebuild it, but I’d like to know if perhaps my repair command just needs to be amended (?).
I upgraded two Win10 machines from 1909 to 2004 the other week and it caused no issue with Duplicati.
Where are your Duplicati job databases located? They are outside the C:\Windows folder, correct? They may be in the C:\Windows folder if you are running Duplicati as a service using LocalSystem, and major Win10 upgrades are known to break things in that case.
09/15/2020 12:42 PM 309,714,944 DGBAZSKVWS.sqlite
09/15/2020 11:40 AM 114,688 Duplicati-server.sqlite
09/15/2020 11:01 AM 135,168 ONMPKZWJMO.sqlite
09/15/2020 12:25 PM 309,792,768 PXBFRHZHOO.sqlite
are located at c:\Users[USER]\AppData\Local\Duplicati. Are these
the databases to which you’re referring? FWIW I did a search for
*.sqlite in c:\windows and nothing came up.
Ok well that’s the normal location for Duplicati running under a user context, and it should be safe during major Windows upgrades. So I’m at a loss to explain at this point.
Some other questions are what user Duplicati has been run as, and if it runs at boot or at user login.
If installed as a service (check Task Manager Services for Duplicati), it runs as SYSTEM, not user. Database would be in the permissions-protected (so maybe not searchable) SYSTEM profile which Windows upgrade puts in C:\Windows.old\system32\config\systemprofile\AppData\Local\Duplicati. Confirming that did not happen is important, because Windows will delete that 7 days after creation.
I’m also curious how many backups per computer were expected. The database list suggests three, having Database local path ending in the seemingly-random filenames that you see. Check backups.
Extra unknown file: duplicati-20200625T074004Z.dlist.zip.aes
was reported from some host, and if it was the one whose .sqlite files were listed, how do the backup versions as seen by Restore selector look for a backup from around 20200625? Note file date is UTC. Whatever backup job you are seeing seems to think it has no backup from then. Does that seem OK?
Another confusing thing about three backups is the repair “googledrive://Duplicati/$env:computername” shown earlier suggests one backup per computer, so again some figuring out what’s where is needed. Running repair on a stale database (if you got that somehow) can also repair destination to match DB, which in this case might mean deleting the “not recorded” files which I’m trying to get some history on.
The resulting backups are stored encrypted in Google Drive under “My Drive/DuplicatiBackups/[HOSTNAME]”. FWIW I have been running it this way w/o any issues for a little more than four months for about 20 Win10 Pro machines.
Fully blowing away the existing backup on Google Drive then re-running the backup fixed this. Throwing out the baby with the bath water, but I’m not sure I have the chops/patience to debug this any further.