I’ve tried it for a couple of days and it works surprisingly well! This is what I did to configure the backup:
- Created 3 virtual harddisks (VHDX) to simulate 3 external disks as backup target.
- On each disk, configured the same driveletter in Disk Management (F:) and created the folders
F:\Duplicati\BackupandF:\Duplicati\Database. - With 1 of the 3 disks attached, created a new backup job. Destination type: “Local folder or drive” and path for backup files:
F:\Duplicati\Backup. - In the main view, clicked to expand the backup job and clicked Database… Moved the Local database path to
F:\Duplicati\Database\xxxxxxxxxxxxxxxxxxxx.sqlite.
After the backup had been set up, this is what I did to test it:
- Started the initial backup (about 20 GB) which worked fine. The local DB was automatically created in
F:\Duplicati\Databaseafter the first backup was started. - After the first backup completed, swapped backup disk 1 with backup disk 2 and started a new backup. This worked without problems too. Local DB created automatically on the second disk and initial backup completed successfully. Same for backup disk 3.
- Made lots of changes to the source files (additions, deletions of files from different sizes) and started backups using random backup drives. None of them had an issue.
- Deleted the local DB from one of the backup drives and started a new backup. DB was recreated automatically and backup completed successfully.
- Executed come commands, like COMPARE and DELETE. All operations worked as expected.
- Restored some files from different drives. No issues.
I expected that backup/restore operations would be significantly slower (source files and VHDX containing local DB and backup data are on the same spinning HDD), but I didn’t notice a performance drop.
Synchronizing backup files and creating multiple backup jobs have a few disadvantages:
- Synchronizing backup files is an additional (manual?) task that must be maintained outside the Duplicati environment. You also need 2 backup targets to be available at the same time.
- If Synchronizing backup files is scheduled somehow, there is a risk that the sync process starts before the Duplicati backup completes, resulting in inconsistent backup data at the “backup-of-the-backup” location.
- If Synchronizing backup files is configured incorrectly, or aborted, data at the “backup-of-the-backup” location could become unusable.
- In case of a system crash, the local DB has to be recreated.
- When using Multiple backup jobs, the job list could become confusing if there is more than 1 backup job that is replicated for every backup target.
- When using Multiple backup jobs, a local DB for every backup job to every backup disk is stored on the Duplicati host. Host drive could be filled up with a bunch of local DB files.
There are a couple of benefits for this strategy, compared with using multiple backup jobs or synchronizing backup files to another location:
- There are (in my scenario) 3 sets of remote filesets. If one of them becomes corrupt (deleted/corrupted DBLOCK files), I still have 2 fully working backup sets.
- If a database becomes corrupt, recreating the local DB is not required to restore files, just us another backup disk.
- No need for configuring/maintaining additional/manual tasks for replicating backup files.
- Just one backup job for every source fileset.
DISCLAIMER: I tested this just for a few days, so use this strategy at your own risk! However, I did not have any issue.