Looking for best practices for backup ID naming and encryption

Support
#1

I could use some help trying to refine how I have Duplicacy configured based on best practices people have found for the subjects in the title. Posting here after not finding the feedback I need after searching; apologies in advance if I missed this somewhere else.

  1. I have several shares on my Unraid server I’m backing up to a cloud service. Are there any recommendation (or examples) people can share on naming backup IDs?

  2. I learned that it’s possible to backup under the same ID but without some naming examples I don’t understand when that would be relevant or what’s happening behind the scenes.

  3. I’m finding a difference in opinion on encrypting backup data. Other backup applications I’ve read about is clearer on the reasons in doing so because the data being backed up is a 1-to-1 backup. What is the consensus or best practices on the need for encryption?

When originally configuring it seemed like some people aligned to the below and opted to not encrypt as there is some level of password protection on the files.

Summary of what I’ve read

When you configure a storage in Duplicacy, you supply a unique storage name along with a password. This storage password is not necessarily the same as the backup encryption password (used to encrypt the actual data chunks), though it can interact with encryption setups. Here’s what the storage password is used for:

  • Securing Repository Metadata:
    The storage password is used to protect the backup repository’s metadata (such as indexes and manifest files). This ensures that only someone who knows the password can perform operations on that repository—like running backups, restores, or prunes.
  • Access Control:
    It acts as an access control mechanism. By requiring a password, Duplicacy prevents unauthorized users or processes from modifying or accessing the storage. Without the password, you cannot manipulate or view the repository details.
  • Consistency Across Operations:
    The storage password ensures that all operations performed (backup, copy, check, or prune) are consistent and secure. It’s used internally to verify that you’re working with the correct repository and to maintain the integrity of the backup history.
  • Not Directly Encrypting the Backup Data (Unless Combined with Encryption):
    While Duplicacy offers backup encryption (which encrypts the actual data stored on the repository), the storage password itself secures the repository’s management and metadata. If you’re not encrypting your backup data, the storage password still protects the backup configuration and operations. However, in setups where backup encryption is used, you will specify an encryption password separately during the backup process.
#2

It’s up to you entirely, whether you want to logically separate data into distinct backup sets – for example, if you want to implement different backup cadence, or retention settings, for different data sets. Personally, I backup everything under a single name (“snapshot id”).

If you have separate volumes, you can still backup them at once: create a repository in some folder, and symlink the volumes you want backed up into there. Duplicacy follows first level symlinks.

No, you cannot (as in “must not”) have multiple backups targeting the same under the same snapshot id.

I don’ know what that means. Duplicacy creates versioned history of your data in time. Each revision represents 1:1 state of your data at the time of backup. Backup solution that does not do 1:1 backup is an oxymoron.

Encryption has nothing to do with this. Use encryption if you want to prevent anyone who has access to storage to read your data. Don’t use encryption if you don’t. I

But you won’t save any performance, see below.

“some people” is a very bad reason to do anything, without the underlying "why"s.

Duplicacy always encrypts data with generated symmetric keys. Those keys are in the config file. When you enable encryption, that config file itself gets encrypted with your password.

No. Everything is encrypted. Both data, and metadata.

Right. There is also support for asymmetric encryption, if this works better for your usecase: one key to backup, and another to restore. Useful to allow multiple users to backup and only admin to restore.

Duplicacy verifies that regardless of whether storage encryption is enabled.

Data is always encrypted. Encryption keys are in the config file. Config file is encrypted with user passphrase, if user choses to.

I recommend reading the source: Duplicacy paper accepted by IEEE Transactions on Cloud Computing

1 Like