Documentation for Migrating to a New Server

Development UX
#1

Longer time syncer, first-time poster. I was chatting in the IRC syncthing channel regarding best practices to migrate an existing server. We discussed a few options, but one thing we agreed on was that this isn’t sufficiently covered in the official documentation, and I’d like to propose it be added.

For example, I just recently migrated a server from Fedora to Void (worth checking out, btw) and wasn’t sure if I should:

  1. Install syncthing fresh and re-sync folders one by one
  2. Same as 1, but start in “receive only” mode to ensure I didn’t revert anything deleted on other nodes
  3. Copy something (or everything) from .config/syncthing (and if I did, what gotchas might exist, e.g., forget to mount /mnt/whatever and started a sync? whoops, all remote nodes deleted!)
  4. Something else

I ended up doing 1, which was painful with ~20 folders. It’d be good if there was a detailed walk-through of how to migrate configs and databases, along with any caveats.

I’m happy to help with this. I can’t provide the expertise, but I can certainly help ensure the docs make sense to the average user.

2 Likes
Re-establish syncing with new syncthing, but old synced directory
#2

Ensure everything is in sync on the old machine. Shutdown Syncthing and grab those files according to How to save configuration of Syncthing Move files and folders (your data) to the target machine without modifying anything. Insert your config and modify the folder root path in there if it has changed. Insert your key files. Start the new Syncthing instance on the new machine.

#3

I think your options 1-3 are all valid (and correct about the gotcha on #3 – if you’re going to copy the existing database, do make sure the files are also correctly in place).

An alternative to #2/#3 is to copy everything but set the other side in send-only mode. Any inadvertent differences detected after the copy will be rejected and can then be safely overridden from the other side. I prefer that to the receive-only variant because there’s somewhat less potential for screwup (the barrier is on the other side, which you are not screwing around with, as long as you set it to send-only before starting the maneuver).

1 Like
#4

Thanks for the insights. Any thoughts on whether this should be in the official documents?

#5

I think it would be great, the question has come up often enough. Some data mining here on the forum should reveal several discussions and approaches.