Encryption and backup/copy to same storage

Support
,
#1

Continuing the discussion from Best Practice: copy from local server to remote and Duplicacy copy confusion/question:

I’d like to confirm something related to the posts above.

I currently have a local server (NAS) that has many directories split across several repositories, that are all encrypted with the same password and all backup to the same offsite storage (B2).

What I’d like to do is set up duplicacy on a local client, and have it backup to the NAS (set up as the storage), then have the NAS “copy” that backup set to B2. So the NAS acts as both a source for a large chunk of data, that goes to B2, and as a destination for a client computer (and I want that destination to also be saved into B2)

My questions are around encryption and deduplication.

  1. In order for any deduplication to take place in what’s saved at B2, does the repository on the local client need to be encrypted with the same password as the repositories on the NAS? (think answer is yes)
  2. Similarly, I would have to do a duplicacy copy from the NAS to B2 for the local client repository, correct? (in order for it to do deduplication) i.e. I could not just rsync that data to the offsite location into the same bucket, because it wouldn’t know about the other repositories that exist on the NAS (only as source data, not in an already-backed up format).
  3. If the answer the #2 is yes, and given that the repositories on the NAS are already initialized and backing up to B2, where and when do the copy and bit-identical parameters of duplicacy add come into play? I am just creating the repository on the client machine now so have flexibility there, but have several TB of data already on B2 from the NAS.

Thanks!

2 Likes
Setting up Local -> NAS-A -> NAS-B -> Cloud (B2)
#2

My home setup is exactly this scenario. PC backs up several repos to NAS. NAS backs up several of its own repos to GSuite, and also copies the Duplicacy storage on the NAS to the same GSuite storage.

Regarding your questions.

  1. The Duplicacy storage on the NAS and B2 can use a different master password, although I personal use the same password. The main criteria is that both storages are made to be copy-compatible, using the add -copy command.

  2. Pretty much yes. Your NAS’s local backup storage would be a partial fraction of the one on B2, a normal rsync would remove snapshots and chunks there. (I suppose you could tell rsync to --ignore-existing and --update only, but that seems incredibly hacky to me and I don’t think there’s a combination of switches that would work as expected, and not potentially screw up the B2 destination irrevocably.) Stick with duplicacy copy.

  3. You don’t really need bit-identical if not using rsync. Without it, the chunk filenames will be different on both storages so you can’t visually compare them, but that’s not really a big deal if you let Duplicacy do its thing.

Basically what you need to do is copy the existing B2 storage (settings) to somewhere on your NAS. Go to one of the NAS repos already being backed up:

cd /nas/repo1
duplicacy add -encrypt -copy default nas-storage dummy-repo1 /nas/storage
duplicacy set -no-backup -storage nas-storage

Where default is the name of the existing B2 storage, unless you changed it. nas-storage is the name of the new, local, storage. dummy-repo1 is a dummy name for the repos id, not actually important as you won’t be backing up repo1 to the NAS - you’ll be using repo1 to copy backups from NAS to B2.

Then, as part of your normal backup schedule / script, add:

cd /nas/repo1
duplicacy copy -from nas-storage -to default

(Again, where default is the name of your B2 storage.)

This sets up the new NAS storage for your local clients. All you should need to do on the local clients (unless you’re using the GUI - in which case, it’s the same idea anyway), is point it to the newly initialised storage:

cd /pc1/new-repo
duplicacy init -encrypt pc1-new-repo //nas/storage

(Assuming //nas/storage is the network share to the storage, you can of course use SFTP.)

Please use -dry-run as often as possible. :slight_smile:

Edit: Apparently it’s good practice to write-protect the dummy repo+storage if you’re not actually gonna backup to it, so I added the set -no-backup command above.

3 Likes
#3

Excellent answer, thanks!