In case of a crash - what to do?

I am running SyncThing on a Synology NAS, to which 5 devices are syncing, each to their separate folders. Everything works just fine, and I am quite satisfied. But as the external devices are running (very) remotely, I would be very sad, if for some reason I would have to get a hold of them to get data out. The made-up scenario is this: The NAS crashes, burns, gets stolen or something. Then what? I am aware that it is of course possible to back up the already synced data regularly, so this is not lost, but what if the crashed/lost NAS is replaced with an identical NAS, perhaps even with the config file from the old NAS?

Main questions:

  1. Will the remote units be able to sync to the new NAS with the restored config file?
  2. What happens to the (old and perhaps new, as in generated since the crash) data on the remote devices? Do they see the server as now having been emptied, and delete their local files (=new data is lost)?

I read this post: https://forum.syncthing.net/t/epic-mixup-of-files-after-disk-restoration/13492 and found it to be almost the same issue, although not as such resolved and not concerning the exact same matter.

Easiest way to prepare for this is backup the keys only. When keys are added to replacement machine everything will try to share folders with the “new” machine, because it will be seen as the same Syncthing instance as before.

Will just have to manually accept folders on the replacement machine.

Advocate this method because backing up config file and database just complicates things. This way get a new config file and database file with very little work.

Backing up the config file is fine. Restoring it will result in not having to accept the device connects and folder shares. With an empty index and an empty folder, you will get all data from the remotes. Though you might need to reset delta indexes on the remotes, as they might not get over the fact that they think you have the current index :wink: .

But you should only ever backup the index db together with the data which was last scanned (which implies that you don’t need the remote device to get your data back).

1 Like

This shouldn’t happen any more, the index ID is random and stored in the database, so losing the database means full index transmission.

(:+1: on all the rest)

While reading the others answers and reading your main questions again, I think, you forgot an important question (well, its my question, so forgive to asking this in your thread):

What if the NAS is stolen and not crashed,

how can you be sure, the other 5 external devices won’t sync to it anymore? Or vice versa.

Maybe, the theft just deletes randomly files and folders (but not the hidden ones, like .st* and you want to prevent that those deleted files/folders will be deleted on the send&receive folders of the 5 external devices too. Or you don’t want any traffic from the stolen nas to the 5 external devices.

What has to be done?

Full-disk encryption. When the stolen NAS is powered on nothing proceeds further.

So, to be clear: Should I back up+restore the keys, the database, the files or all of the above? And what about having another file sync service (Dropbox, OneDrive, etc.) monitoring the Syncthing config (and file) folders, so that everything is backed up here as well? I am aware that this is not in the spirit of Syncthing, but also that in case of an emergency, I would rather have two copies than none. With this in place, I assume that I would be able to just install Syncthing and the other sync service on the replacement NAS and then be good to go. And @sisa: Good point! However, I think that the most probable cause of problems is a disk crash.

Ideally I’d just backup the keys, and the config (and your data I guess). It’s always safer to rebuild the database than to restore it from backup.

2 Likes

Backing up the config file assumes the same disk structure. That is why advocate solely restoring keys.

Just backup keys and config file. Can decide how want to restore if reach this point. Keys never change (so only need to be backed up once) and config file won’t change often after cluster is setup.