Hello,
I have a syncthing-server v1.27.12, Linux (64-bit Intel/AMD Container) that is connected to several local systems.
Now I want to set up the container on another system without having to change anything on my local systems.
How can I save the current configuration and foist it on the new syncthing so that the move goes unnoticed? Ideally including the UI access.
If I set the folder type to Receive for all folders beforehand, I should get all the data from the other systems after the move. It shouldn’t be necessary to save the data itself and the new container should rebuild the database. Is this consideration correct?
I can’t find an export/import function on the server, but it is available on the Android app. What needs to be done to achieve export/import?
The easiest way would seem to be to stop Syncthing, and then move all of Syncthing to the other system. If you’re using local Discovery or anything other than hard-coded Remote Device IP addresses, I’d expect this to be easy. When the moved Syncthing instance is started, if it sees config.xml, its database, certificate files, and shared Folders where expected, it should just work.
Yes, but if the other local systems are all set to “Send & Receive”, relocating the container to another system that doesn’t already have the files is going to make it appear as if the files have been deleted. So…
Make backups.
At least temporarily switch the other local systems to “Send Only” (if they aren’t already).
On Android the configuration file is in protected storage, so the export/import makes it easier to transfer settings between devices.
Desktop OSes don’t have those protections, so see Syncthing’s official docs page about it: Syncthing Configuration
Thanks, that will certainly work with the current action because the changes to the container will not affect syncthing.
Since I always back up my user data, I generally also want to back up the configuration so that I don’t have to re-create everything in the event of a hardware failure.
An unprivileged Linux container on a proxmox system.
That’s exactly what I wanted to avoid.
As I understand it, as long as the server is off, nothing will happen to the other systems. If I start the server with the created folders and folder type set to receive, then I actually expect that new files will not be distributed by the server, but also that the information that files are missing will not be distributed – regardless of the folder type on the other side.
So in that case, you had the option of either storing Syncthing’s config inside the container or on the host via a bind mount (you didn’t mention where any data is being stored).
If it’s the former, a backup and restore of the container is all that’s needed (assuming that any external storage is also appropriately configured).
Setting the other devices to “Send Only” and having recent backups is insurance in case something goes wrong.
But as long as you’re absolutely certain that the new server starts with the Syncthing folder(s) in “Receive Only” mode, then the other devices can be left unchanged “Send & Receive”.
lxc a my current syncthing server, all folders set to receive
lxc b my new syncthing server
lxc a, name an, ip-addr ai, home-store ah, folder-store af
lxc b, name bn, ip-addr bi, home-store bh, folder-store bf
bh and bf are present but empty
Test procedure:
Stop lxc a
Create lxc b, start, set password, start web-ui → syncthing on bh present, no folders are displayed
Stop lxc b, copy ah over bh, start lxc b → all folders are displayed as stopped, error messages indicate that the folders are missing.
stop lxc b, copy af over bf, start lxc b → all folders are up to date, all external devices are up. Files that have since been deleted on the external devices are deleted and displayed as the last action.
on lxc b set the folders to receive and send again.
I did not test the filling of the folders because I would have had to create the folders to do so.
I am satisfied with the result, because it helps me if I want to change the memory configuration on the proxmox.
With the copy of the home folder containing the configuration and a data backup, a new lxc can also be set up at a later point in time, but then the folders cannot be set to receive beforehand. Taking the server offline is also sufficient, as the primary aim is to prevent all folders from being created and having to be connected to the external systems for new IDs.