Reconnecting backup to data on new PC

Support
#1

We recently moved to New Zealand and just before shipped some of our things, I realised that the old PC (which had a lot of data backed up to B2 storage with duplicati) wouldn’t fit in the moving boxes. So I grabbed the hard drive and packed that and gave away the (rest of) the old PC. Now we’ve received our shipped stuff, and I’ve installed the harddrive in the new PC. All the data is still there, but I haven’t installed duplicati on this PC yet. I don’t remember copying over any duplicati related files, and I can’t find anything other than a “duplicati-service-files” folder that only contains an empty “control_dir_v2” folder and a 56 KB “Duplicati-server.sqlite” that hasn’t been modified since February 2018 (might have been from the original “tray” installation, before I converted to the “service” installation?).

What I’d like to do it “continue backing up the same locations to duplicati” :smiley: … that is, I’d like any new or modified files to be backed up, without restoring any data that might have been deleted on the hard drive (though I’d still want that data to remain in the backup, according to the retention policies) … does that make sense? Is that feasible?

I’m not sure what exactly my other options might be :slight_smile:

Kind regards,
Svend

#2

I am by no means an expert, but if I understand everything correctly, you should be able to manually recreate the config and have everything link up:

  1. Make a new config that backs up all the same locations, with all the same settings, to the best of your memory.
  2. If you used an encryption key, make sure you use the same key in your new config.
  3. Point the destination to the existing backup.
  4. Don’t run or schedule the new backup yet; instead go to Database and tell it to Recreate.
  5. The database will be reconstructed from the remote backup. At this point everything should be set up.
  6. Verify by attempting a restore from the new config. It should list all your retained versions. Actually restore at least one file to test. If you forgot a source folder, it should still show up in the restore options so make a note of it and add it to the new config if needed.

If the restore looks good you should be ready to schedule the backup again and let it run. I think. I haven’t actually tried this, and this procedure is just an educated guess.

Once it’s working, consider exporting your config and storing it somewhere within the folders being backed up; you can always retrieve it later via a direct restore from backup files.

2 Likes
#3

Thanks for @kaufman-bryce for those steps. They look good to me, though I haven’t tested either.

Did the drive letter change? If so, older backups probably couldn’t restore to the drive they once had, however frequently you want to give a different path anyway, and the GUI will easily allow that option.

Is the concern remembering the old config in terms of folders? You’d see that browsing test restore.

If you used a lot of special setup, it would be more worthwhile to make sure you search the old drive, including profile for the SYSTEM user if you migrated with defaults and let it keep its databases there.
Getting permissions is sometimes tricky, but a Command Prompt (Admin) should be able to access.

1 Like
#4

Thank you @kaufman-bryce and @ts678 for your replies! :slight_smile:

Good thing you mention the drive letter. I’ve now changed it from the default ‘D’ (second drive) to ‘S’ which it was before. Will give the steps a go and see what happens :slight_smile:

Cheers,
Svend

#5

Oh, and I don’t have the system user folders (it seems). The old PC system (Windows) was installed on the SSD that we left behind… so I’ll just have to try to get it right. I did have some different retention policies setup for the different backups, but presumably that’s all “duplicati side” and if I set it up differently now, the only effect would that some old versions might get culled when it next does a clean, or similar?

#6

Yes, that’s all retention does. You could again sort of guess at what you had from seeing the dates in the Restore view after DB recreate (technically probably via Repair button because old database isn’t there).

is an excellent idea, and when/if you setup the service, I’d suggest not using SYSTEM profile because a
Windows version update will impolitely send Duplicati folder to Windows.old. More at prior migration link.

1 Like
#7

I’ve managed to setup the first couple of backups, and they seem to be working :slight_smile: The last one is the trickiest, because it’s the “everything else” one, and contained lots of different things, with some exclusions as well, but I guess I can use the restore folder to check what’s missing.

I was thinking: When I have run a backup, I can run the compare command with

1
0
--full-result

arguments to see what files were added, updated and deleted. Is there a command that would tell me what files would be added, updated and deleted if I run an update now? :slight_smile:

#8

Another question: I’ve now setup the last backup, and when I open the restore view, I can see some files in the user’s home folder on the old PC (c:\Users\Svend…). The user has a different username on my new PC, and the files aren’t any I currently have a need for, but if I don’t restore them, would they then get deleted next time I run the backup, because they’re not in the new configuration? Is there a way to add them to the configuration without restoring them? I could for instance restore them, add them to the config, and then delete them locally, if that would help avoid them disappearing :slight_smile:

#9

They aren’t deleted as long as some old backup version has them. Check the Options retention setting.

That winds up the same place. The backup of a given moment can only backup what’s there at the time.

Unlike some backup programs that purge when configuration changes, Duplicati leaves old stuff alone…
The PURGE command is there to use, e.g. in Commandline, if you ever want to wipe out unwanted files.

1 Like