Sanity check needed: Migrating Duplicacy-web to a new host

Support
#1

I want to re-host my existing Duplicacy-web set-up onto a new system (both new and old are Linux). I assume I’ll need to re-enter encryption keys, create links to external data sources, etc. However, I haven’t found comprehensive guidance for the following:

  1. Will copying the existing .duplicacy-web directory to the new host provide all my settings, backup definitions, repositories, schedules, etc., to allow backups and restoration to continue as if nothing had changed?

  2. Assuming #1, above, is correct, would that still work if the existing instance is version 1.8.0, but I created the new instance using version is 1.8.3 (i.e., will a V1.8.0 .duplicacy-web directory work under V1.8.3)?
    EDIT: I forgot to add that the executable in .duplicacy-web/bin would need to be changed to reflect the version being used. My question concerns all other contents of .duplicacy-web.

  3. How do I transfer the Duplicacy-web license to the new instance?

  4. In the event I find the new instance needs further work during the transition, can I ‘gracefully’ (i.e., without affecting the integrity of the backups) switch between the (identical) new and existing instances? Another way of looking at this is, will using multiple identical instances of Duplicacy-web still produce viable backups, assuming you don’t have backup tasks running concurrently?

Are there any other helpful hints, gotchas, etc., I should be aware of?

Many thanks in advance.

#2

Not quite. While it will allow you to transfer settings, you source path locations will likely need amending and you can’t do that in the GUI directly.

One thing you could do is manually update the duplicacy.json config file (while the process isn’t running). You may also have to relocate things like key/token file locations if you use that kinda backend, and I think those path might be encrypted. So you might have to re-add a job in the GUI anyway.

So depending on your setup, it may or may not be easier to just start from scratch, but you can always start with .duplicacy-web as a reference. If you need to re-add a storage, just use the same name.

Versions shouldn’t matter here.

Don’t bother. There is a licences.json file in the directory, but this will instantly be invalidated because it’s different hardware.

Instead, simply log into your Duplicacy account and update the host name to the new machine name. Then, in the Web UI Backup tab, click the link next to the hostname at the top (probably says ‘Trial’ or something) and paste in your Activation Code from the site. At this stage, you probably don’t want to be running Duplicacy on the old machine.

Mostly, yea. The only thing you have to be aware of is having two computers backup to the same ID isn’t advised - you won’t lose historic data, but ideally you want to maintain a clean incremental set of snapshots.

So for example, if you accidentally backup the wrong location to the old ID, it’ll be fine but then you’ll have unwanted chunks and a snapshot file that, on the next backup with a correct location will cause everything to be re-hashed and take much longer.

You can correct the mistake by manually deleting that revision on the storage and start again (and clean up with prune -exhaustive). It’s not the end of the world but you just want to avoid switching between computers (a source of data) on the same ID - especially on a permanent basis.

HTH.

#3

Great information - many thanks! A couple of follow-ups:

Transferring configurations:
Sounds like it’s more straightforward to simply re-create everything in the new instance, using the existing definitions, IDs, keys, etc. If I do that, is it correct to assume there are no instance-specific files, keys, identifiers, etc., I need to copy over?

Backups created by the new instance:
To help me fully understand, let me clarify my situation: ALL of the data being backed up resides on other systems; I have Duplicacy running in a VM in my VM farm, and it accesses data via file shares (not optimal, but it’s a home situation so performance isn’t a big issue).

Assuming the new instance is configured identically to the existing instance (same mount points, IDs, storage [Backblaze B2 buckets], etc.), shouldn’t the backups created by the new instance be a seamless continuation of the existing backups?

Again, many thanks for the information and assistance.

#4

I found this post (Reinstall duplicacy web, how to restore jobs), which appears to address many of my questions.

I’m assuming these steps for reinstalling Duplicacy would also apply for migrating Duplicacy to a new host:

Bottom Line, it sounds like, as long as all the definitions, IDs, etc., are the same, the new instance of Duplicacy will seamlessly continue the existing backup regime.

Have I misinterpreted anything?

#5

Correct. No special files tied to the instance are needed. Doing it this way is probably a good opportunity as well, to test your recovery procedure, as technically all you need is the storage password and any keys to access it.

Seemless. The way to check after the next backup is see how many chunks were uploaded out of the total. Or run a check and match the file/chunk count.

You’ll be fine. :slight_smile:

#6

Excellent. Many thanks for your assistance!