I bundle three things in here, hope it is ok
- A hint that Google Drive changed on March 16 which impacted Duplicati. I don’t know the reason
- Some surprise on error messages on recreating the database.
I’m aware of Repeated failure to repair , it has some very good explanations in there, thank you @kenkendk
- A question, maybe simplistic approach on DB restore
Apparently GoogleDrive (GD) changed some of their setting / app specific authentication around March 16 which made my backup fail. I tried a few ways to fix it, but as folders on GD are just labels with no success. (Duplicati and Google Drive paths) I was not able to adjust the backup settings – and latching on to the same folders that contained past backups.
Hence, I edited the backup setting, gave new foldernames in GD, retained all other settings (folders selected, frequency) and attempted to repair database.
Recreating database created an error, yet said “success” and “marking database as complete”
EndTime: 20.03.2018 18:46:51 BeginTime: 20.03.2018 18:46:34 Duration: 00:00:16.5321809 BackendStatistics:
RemoteCalls: 27 BytesUploaded: 0 BytesDownloaded: 859634 FilesUploaded: 0 FilesDownloaded: 26 FilesDeleted: 0 FoldersCreated: 0 RetryAttempts: 0 UnknownFileSize: 0 UnknownFileCount: 0 KnownFileCount: 0 KnownFileSize: 0 LastBackupDate: 01.01.0001 00:00:00 BackupListCount: 0 TotalQuotaSpace: 0 FreeQuotaSpace: 0 AssignedQuotaSpace: 0
ParsedResult: Error EndTime: 20.03.2018 18:46:51 BeginTime: 20.03.2018 18:46:34 Duration: 00:00:16.5597109
Rebuild database started, downloading 3 filelists, Filelists restored, downloading 23 index files, Recreate completed, verifying the database consistency, Recreate completed, and consistency checks completed, marking database as complete
Errors: [ Remote file referenced as duplicati-b27a62c1807344c1c8468f6c2a48663a5.dblock.zip.aes, but not found in list, registering a missing remote file,
What am I missing. what am I oversimplifying? I’d have expected
- Recreate database
if destination (GD folder) is empty, the database is empty as well
- Run a normal backup
as the destination and database empty, backup all files up again, tough luck
- From there on, business as usual.
There are a few comments in the forum about corrupt file and inability to restore database. I start to loose trust on the ground that duplicate apparently assumes some consistency between the backup destination and the local computer and that all destination file are flawless, else the entire backup might become useless. That lucky situation is definitely not guaranteed in case of a “disaster”.
The basic functionality, the way Duplicati operates, the way it blends in are great. Isn’t there a way to
- Straighten out the log, and say error if there are errors.
- Restore the database no matter what, even if backup folder are empty
- Display the files found on the backup (and in the database), creating transparency and trust that backup actually worked
- And do so against any GD folder, even those created on a different computer
(I tried a restore test once and it work only after I copied the GD files locally – and then restored against them