Best Practise for reaplcing failed drive & with initial enourmous folders

I have 5 devices syncing folders. Not all folders is synced to all devices.

One device’s drive failed and it was replaced.

As to restore the sync process, I

  1. Removed a folder on the failed machine via the GUI and accepting the share request thereafter, yet it results in the warning that the folder marker is missing and the potential for data loss.

2022-05-19 17:12:33: Error on folder "Data" (cxscf-vdc2w): folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)

  1. Removed a folder on the failed machine and also unshared the failed machine at all other nodes, followed by only re-enabling sharing from 1 device, yet still results in the same warning.

WARNING: Rule Nr 1 - DON’T EVER touch the .stfolder. I’ve learned this the hard way, way back when I copied enourmous folders between two drives before placing them in their respective machines as to prevent syncing as mush as possible over the network which ended up causing considerable data loss.

  1. Remove the folder from every node. Reshare the folder (with a new Folder ID) across all nodes.

However … some folders are 300 - 500GB which I’d prefer not “copy/syncing” over the 1Gbps network.

Can someone thus please shine some light on the best practise and caveats in these situatons:

  1. Resync when a drive was replaced
  2. Sync enourmous folders which was first copied directly between drives, thereafter being placed in their respective nodes as to sync over the network.

Thanks.

I’m not entirely sure what happened in your case.

Generally, if a disk with a Syncthing folder on it fails and you replace it with a blank, you remove the folder in Syncthing add add it back again at the same path. This clears out the metadata and tells Syncthing to expect nothing on disk – it will fill it with data from its peers.

If you pre-populate the data in some other way from another peer (rsync, disk copy, restore a backup, whatnot) then you can just not tell Syncthing anything at all – it will continue where it left off, and any changes between then and now will be interpreted as having been made by you on the device in question.

Once you start removing and re-adding the folder everywhere you end up with all devices having to scan all the data and the end result being something merged from whatever it finds in all the places…

What you don’t do, as the warnings indicate, is fiddle with .stfolder in isolation. The only exception to that would be if you did restore all the data from some non-Syncthing source, but it didn’t restore the .stfolder – then you can create it manually, in effect vouching for the data being complete and in order.

No data was re-populated in this scenario, specifically due to the previous experience.

… and I’ve already entered the “remove and re-add everywhere” stage …

… only cause I also got the folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed) message even after re-sharing a folder with a new Folder-ID, yet to the same destination on the old node.

If it may be of interest, Syncthing is running in docker on all nodes with the actual data storage areas being mount points.

There have been similar reports on the forum recently. I think this is some kind of a bug. I was going to try reproducing it myself, but I haven’t managed to do it yet. The error itself seems to go away after restarting Syncthing.

For the record, this only happens when removing and then re-adding a folder under the same path, but I don’t think it’s always the case though.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.