Using Duplicacy for a local copy, replacing rsync

[robdejonge]

My fileserver has a number of shares that contain different kinds of data. For each of the shares, say Media as an example, I keep a Media-Backup volume as well. All my -Backup volumes get backed up to Backblaze by Duplicacy.

The sync from Media to Media-Backup is a one-way (I do not touch the -Backup volumes in daily use) rsync job that runs every night. I dont run them constantly, because people make mistakes and the fact that it’s daily has saved me more than once.

The benefit of it just being an rsync job is that it’s a normal filesystem I can access for convenience. I don’t have to go look up how to restore something, etc.

But I’m wondering what arguments exist to replace this sync with Duplicacy. What I can come up myself is:

• Versioning
• No need for lots of unused space in -Backup partitions, dump it all into a single partition and thus save space.

What other benefits would this have?

[saspus]

@robdejonge

For each of the shares, say Media as an example, I keep a Media-Backup volume as well.

@robdejonge

The sync from Media to Media-Backup is a one-way (I do not touch the -Backup volumes in daily use) rsync job that runs every night

What filesystem is on your file server? If it does not support snapshots, this approach simply duplicates data, wastes space, and does not protect against anything – if your source data is corrupted the next day your backup version will be too.

You want a filesystem that supports snapshots. Then you can schedule e.g. hourly snapshots that are kept for say 30 days, and always have a history to revert to, without wasting extra space.

@robdejonge

because people make mistakes and the fact that it’s daily has saved me more than once.

You were just lucky to have noticed the problem the same day. If anything, this is an indication of fragility of this approach

@robdejonge

The benefit of it just being an rsync job is that it’s a normal filesystem I can access for convenience. I don’t have to go look up how to restore something, etc.

Local snapshots will have exact same behaviour. Last version is visible in the filesystem and you can have snapshots mounted readonly as well.

@robdejonge

But I’m wondering what arguments exist to replace this sync with Duplicacy

For Media – none. Media is immutable, and non-de duplicatable.

@robdejonge

No need for lots of unused space in -Backup partitions, dump it all into a single partition and thus save space.

You are not saving any space – you still have data duplicated in the duplciacy repository, if it resides on the same server.

@robdejonge

Versioning

Or, more specifically, longer version history, compared to 1 version for 1 day only you have right now., allowing you to recover from issues and corruption that you discover later than within one day.

My recommendation would be to use local filesystem snapshots to keep local version history (and if your fileserver does not support it – it’s obsolete, replace it) and use duplciacy for off-site disaster recovery backup, on some low cost cloud storage (such as Storj, or Amazon or Google cold storage tiers)

[robdejonge]

Thanks for the comments.

The filesystem is ext4, but I am using it as a flat filesystem. So far (and I’ve had this in place for 15 years now?), this setup has worked well for me. Every once in a while I delete a bunch of stuff, realize my mistake and then copy it back from the -Backup the day before. But I take your point … perhaps time for a review.