So what to do in case of disaster?

[Tortuosit]

Hi guys,

please maybe just point me to the required info. Let’s say I lose all my computers, but there’s e.g. a hard disk or web hosting or BD-R disk with my backups left. Hard disk here has “chunks”, “snapshots” folders and a config file.

So in order to recover stuff, I will reinstall Duplicacy on a new computer. Probably it’s also better to have a backup of the duplicacy executable which has been used for backup.

What next? Will it be easy? I’m asking because a) Restore typically fails because $whatever_reason (with probability of $whatever_reason >90%) and b) e.g. Duplicati was veeeeeeery database dependent. I.e., in Duplicati it is likely that it first has to recreate a database, which then takes 42 Million years.

Thx guys.

[Droolio]

Duplicacy is effectively database-less but you do need access to an in-tact storage with all chunks, snapshots (well, the last snapshot of each repository) and the config file.

Plus whatever password you used to encrypt the config, so don’t lose access to your password manager if that’s the only place - other than your backups(!) - where that might be kept.

Yes, the executable would also be handy to backup - especially the CLI version - but that’s already hosted on GitHub and isn’t going away.

It really only is 1) backup storage + 2) password, but the proof is in the pudding… test it!..

Install e.g. VMware Workstation Player, install OS+Duplicacy and test a restore procedure. My advice would be to always run restores as administrator, to bypass any issues with permissions. You should always be able to restore 100% of your files, excluding stuff that you filtered out. If you’re super-paranoid, compare this restore and the live copy with a tool like Beyond Compare; it really is quite reassuring to see binary-identical files with datestamps all aligned up and all there.

[Christoph]

e.g. Duplicati was veeeeeeery database dependent. I.e., in Duplicati it is likely that it first has to recreate a database, which then takes 42 Million years.

Yes:

Duplicacy demolishes duplicati and rclone for large backups

The problem is that the software relies on having local index files (gigantic sqlite files) available on the machine. In case of a disk failure, one needs to download the entire friggin backup and store it somewhere locally. Then use a out-of-band (separate) program to re-create those index databases. This process would take days to weeks with a 1TB backup set. Only then would the user be able to start restoring data. A downtime stretching weeks for a rather small data set isn’t really viable.

But:

Duplicacy demolishes duplicati and rclone for large backups

• [in duplicacy] Restoring is a snappy process. The Web UI directory browser doesn’t have any of the design faults that Duplicati has, and allows me to interactively navigate through my directory tree as I would expect in a file browser.
• Restoring through CLI worked perfectly, and is the option most likely to be the option during disaster recovery

But trying it out is of course the best way to find out.