I will be swapping out my main Duplicati server in the near future. In the process, the server will have 100% new hardware except for some mass storage, along with a new hostname and OS (Mac OS X moving to Linux). I do an SSH remote backup currently with duplicati on many clients to the existing server.
When I move the duplicati data drive over to the new server and make it available, will I need to do anything beyond update the location (hostname//path) and ssh keys on each client for them to continue and know all the data is there, or will that be enough?
Quote form another thread, which discussed using same external hard drive for Windows and Linux:
This I take to mean that Duplicati is not desgined so that the local databases can be used across different types of operating systems. You can use databases created on Linux on other Linux distros, you can use databases created on Windows on other versions of Windows, but you cannot mix.
I am not sure if the same principle also pertains to the backup files on the target file system, though. You can try, but be extra careful to use test data, so you do not destroy any valuable data.
EDIT: Note that if your test succeeds, you can recreate the local databases beforehand, before the hostwap. You just initiate a restore operation that does it for you. I cannot remember how to do it without actually restoring any files, but I’m sure it is possible.
But then, again, in order to test your scenario (restoring to another platform), you do have to attempt an actual restore from your live target to Linux. Whether the database that results from your test run can be used in the actual hotswap depends on timing.
I forgot to warn about something that won’t happen in a hotswap situation, but I want to warn anyway, in case someone stumbles upon this thread and gets something mixed up: when you run the restore, do not then run an actual backup with the data on the new machine as long as you are still running backups on the old machine. Running backups from both in turn or in parallel will cause you to lose data, big time.
When I do a machine swap, I deactivate the schedule on the old machine - then transfer the sqlite databases - then activate the schedule on the new machine.
Does the existing server also back itslf up to the duplicati data drive? If so, what’s the wish for that backup? For example, would you want to restore from it, or continue it, or does it become irrelevant due to new OS?
Copy ssh keys from one server to another server explains how you might not need the key change, and the hostname change seems like it would be your choice. Just thinking it might be possible to not fix up clients.
This would apply to moving a drive on a client that is backing up, where the database would exist, but not for moving the drive on the remote server end. Good warning to folks that are swapping drives in clients though.
The existing server doesn’t back up anywhere. It used to back up to another location, but has since stopped serving anything other than backups, with those services data moved elsewhere, so has nothing to back up. The new server will get a new duplicati instance set up on the new server, as it will get used for other things again as well. Oh the joys of kicking off database freezes/dumps and then backups, so as to not back up corrupt partial data or corrupt live data. Thankfully I’ve done that for other stuff in the past, so all should turn out well there once I’m done.
If I understand that right, there’s nothing but SSH client backups to maintain forwards, so should be easy. Backup files themselves aren’t particular about what they live on. They’re just files for the Duplicati client, however when the server becomes a client of its own Duplicati, you’ll need to worry some about a future migration if (for example) the server turns to Windows. I’m pretty sure backup will complain per the code:
however experience has shown that the move is not quite as easy as the message would have one think. Theory sounds plausible though – goal is to have new file list reference all the old blocks from actual files.
Server won’t ever be a client of itself, it would become a client for it’s other non-backup data (web, calendar, etc, as eventually become enabled) to a different remote location. So, we’re good there.
