Failed while executing Backup with id: 1

Here I am again :slight_smile:

So Duplicati seems to have been running fine now for a month or two on several Macs and a CentOS machine, all backing up to a Synology NAS over SSH.

However, I was just checking files on the Synology and noticed that my CentOS machine had no backups since December 27th. Looking at the logs on Duplicati, I’m seeing the error message (topic subject). Up until then backups from CentOS were happening fine every 6 hours (that CentOS is running my mail server)

Google searching would suggest that this problem was fixed last February or so.

Any one know how to fix this?

By the way, I was prompted for a new Duplicati update which, as far as I can tell, was installed fine.

Can you get any detail on the error by clicking on the line in the log? That might help narrow down where the error is coming from.

Alternatively, if you use the main “Show log” -> Live -> Profiling while the job is running can you post what the last few messages shown are?

And lastly, when you manually run the job does it fail immediately or after a certain (always the same?) amount of time?

The errors were of the form: Found 7 remote files that are not recorded in local storage, please run repair

When I ran repair, I got (among others] the message: Failed to accept new index

See complete error message below

MainOperation: Repair 
RecreateDatabaseResults: null 
ParsedResult: Error 
EndTime: 1/4/2018 10:14:37 AM (1515078877) 
BeginTime: 1/4/2018 10:13:16 AM (1515078796) 
Duration: 00:01:21.6308360 
Messages: [] 
Warnings: [] 
Errors: [ Failed to accept new index 
file: duplicati-i9c3195fe300e49849721ed9a4d5e3aa0.dindex.zip.aes, 
message: Volume duplicati-b6fdab1c7e222429aaff9c8fc2521f7ca.dblock.zip.aes has local state Deleting => Volume duplicati-b6fdab1c7e222429aaff9c8fc2521f7ca.dblock.zip.aes has local state Deleting, Failed to accept new index 
file: duplicati-i900ba02a459b467b98a1f1c967dd4eee.dindex.zip.aes, 
message: Volume duplicati-baa33044b27284533ac40b723251d95cd.dblock.zip.aes has local state Deleting => Volume duplicati-baa33044b27284533ac40b723251d95cd.dblock.zip.aes has local state Deleting, Failed to accept new index 
file: duplicati-i97cc3d304e044e81bf46d1aab15b07fb.dindex.zip.aes, 
message: Volume duplicati-b780a82d839d44776b519c6b552d40d6c.dblock.zip.aes has local state Deleting => Volume duplicati-b780a82d839d44776b519c6b552d40d6c.dblock.zip.aes has local state Deleting ] 
BackendStatistics: 
RemoteCalls: 11 
BytesUploaded: 0 
BytesDownloaded: 1237351 
FilesUploaded: 0 
FilesDownloaded: 3 
FilesDeleted: 7 
FoldersCreated: 0 
RetryAttempts: 0 
UnknownFileSize: 0 
UnknownFileCount: 0 
KnownFileCount: 1349 
KnownFileSize: 23102611601 
LastBackupDate: 12/27/2017 1:35:51 PM (1514399751) 
BackupListCount: 271 
TotalQuotaSpace: 0 
FreeQuotaSpace: 0 
AssignedQuotaSpace: -1 
ParsedResult: Success

OK - that’s a new one for me. I see where in the code the error is coming from but am not sure exactly what part is failing.


The “Found n remote files that are not record in local storage” is just saying that there are files in the destination that Duplicati wasn’t expecting. This could be due to things like:

  • somebody manually put a file in the destination folder (common)
  • there are more than one backup jobs pointing to the same destination folder (common)
  • Duplicati thought a destination file had been deleted (so deleted it’s local record of it) but the file didn’t actually get deleted (possible but unlikely)
  • Duplicati uploaded a file but failed to record that fact locally (possible but unlikely)

Do any of those sound likely in your case?

None of these — basically that particular instance of Duplicati is running on a CentOS7 virtual machine that is backing up my mail (I’m running Zimbra Mail server on that machine). That is all it does. Nobody ever logs on to that machine except me to check backups!

On the backup machine, a Synology NAS, I have a folder structure that looks like this:

~/Backups/R1/Zimbra
~/Backups/R1/OfficeMac

Duplicati on Centos is writing to the Zimbra location while my local mac is writing to the OfficeMac location

OK - after running that repair, in spite of the errors that repair process produced, I was able to manually run a backup and it worked.

So what to do to make this reliable?

One obvious thing of course is that if duplicati sees an error and recommends repairing the database, then why can’t it try (at least once) to repair the database itself and try rerunning the backup?

I’m glad to hear the repair was enough to get your backup working again. I assume you’re no longer getting the “found n remote files that are not recorded in local storage” error?

My guess as to why it doesn’t automatically try a repair is that depending on what went wrong a repair could take a while (potentially blocking other scheduled jobs from running) as well as require downloads from the destination (which could incur provider costs if not expected).

The problem is that essentially I have to “nurse” Duplicati - I can’t just set it up and, say, check it every month to make sure it’s working.

I have been getting this error message as well. For example, 12th Jan I see this:

~~Jan 12, 2018 5:37 PM: Failed while executing “Backup” with id: 1
System.Exception: Unexpected number of remote volumes detected: 0!

at Duplicati.Library.Main.Database.LocalDatabase.UpdateRemoteVolume(String name, RemoteVolumeState state, Int64 size, String hash, Boolean suppressCleanup, TimeSpan deleteGraceTime, IDbTransaction transaction)

at Duplicati.Library.Main.Database.LocalDatabase.UpdateRemoteVolume(String name, RemoteVolumeState state, Int64 size, String hash, Boolean suppressCleanup, IDbTransaction transaction)

at Duplicati.Library.Main.Operation.BackupHandler.FinalizeRemoteVolumes(BackendManager backend)

at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)

at Duplicati.Library.Main.Controller.<>c__DisplayClass16_0.b__0(BackupResults result)

at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)

at Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)

at Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)~~

I have it for 6th and 7th of January too.
Today’s errors were different.

Unfortunately, that exact error message is used twice in the code so I’m not sure precisely which issue is causing the error. I’ll try to get an update to one of the messages out there so we can which is which.