How robust is Duplicate under these (common) scenarios?

Features
1

I am looking for information about Duplicati’s robustness under the following scenarios:

  • System is rebooted while Duplicate is in the middle of a backup, both backup to remote storage (e.g. B2) or backup to local storage
  • Disk where Duplicati is writing to (local storage) is unmounted while a backup is running
  • Remote service (e.g. Amazon S3) becomes unavailable when a backup is running

And I’m looking for information about recovery of broken backups: assuming the storage is OK, but the local database of the backup is corrupted: what does Duplicate need to download to rebuild the database?

2

Please see How does Duplicati Resume After Interruption? for a comment from the main author on the design. Whether or not everything always works out well is not known to me, and might need some more investigation.

Making immutable mount points with chattr is something you might try if you think such unmounts may happen.

Database management covers repairing or recreating the local database. For a big backup, recreate can get slow, and this would be one reason why breaking a large backup into several smaller ones is sometimes good.

Docs » Manual » Disaster Recovery covers some of the things that can be tried if the normal recoveries fail…

1 Like
3

Ideally only the small dindex (and maybe dlist) files would need to be downloaded.

However, if any of them are missing or corrupt then the larger dblock files will have to be downloaded until all missing dindex/dlist content is accounted for.

The slowness in rebuilds is usually attributed to the local database side and often seems to get non-linearly worse as size (file count) increases. This is partly why breaking large sources into multiple backups often helps with speed.