odelrio

Understanding how Resilio Sync tracks file deletions in encrypted folders

Recommended Posts

Hello guys,

Consider the following scenario:

resilio_diagram.thumb.png.5a32bc5cf8303ae2c201a5db2ee1ce2b.png

  • Peer A creates an encrypted folder and shares an Encryption key with Peer B, so Peer A has the bare files and Peer B has the hashed files.
  • Peer B creates snapshots (backups) of the encrypted files and the application directory where Sync databases lie.
  • All this communication is limited to LAN; no tracker or relay servers.

Then imagine:

  1. The RW key from Peer A is written down.
  2. Peer A is disconnected.
  3. Peer C enters the RW key.

Would Peer B serve the files? Yes, it does.

But now, let's suppose:

  1. The RW key from Peer A is written down.
  2. A file is created in Peer A.
  3. Peer B takes a snapshot of the file and the storage directory.
  4. The file is removed from Peer A.
  5. Peer B tracks the change by moving the encrypted file to its .sync/Archive directory and updating the databases in the storage directory.
  6. Peer A is disconnected.
  7. Peer B restores the snapshot, so the removal never happened.
  8. Peer C enters the RW key.

Would Peer B serve the file that we removed in the step 4? No, it doesn't. Or, at least, Peer C is not receiving it.

I have tested it in many ways and I'm still wondering what I'm missing. Is Sync leaking the folder status somewhere outside the storage directory? Has it anything to do with timestamps? I need to find a way to recover the status of an encrypted folder, otherwise I would be making backups for no reason.

I will be updating the thread if I discover something else.

Thank you.

Share this post


Link to post
Share on other sites

Encrypted folders on backup machine (the one with F-key only) have Read-Only permissions, "Overwrite any changed files" option is always activated. It means that if you or someone else deletes files on this peer, Sync will download them again from other peers, of course provided they are online and have the files.

In general RO peers can only read data in a shared folder, therefore if you update (add, delete or modify) files on RO peers, these changes will not be synced to others. 

Share this post


Link to post
Share on other sites
On 5/30/2018 at 12:11 AM, odelrio said:

Peer B restores the snapshot, so the removal never happened. 

Just for clarity, is rslsync running when this snapshot is restored? I assume it's not.

 

7 hours ago, Gane O'dwyer said:

In general RO peers can only read data in a shared folder, therefore if you update (add, delete or modify) files on RO peers, these changes will not be synced to others. 

I suppose the question could also be phrased as which files would need to be part of a snapshot to be able to make a Read Only peer be exactly as it was before Peer A removed the file? In this case if Peer A stays offline Peer B should have no way to know that the file was removed and serve it to Peer C.

 

For what it may be worth, I recently moved the .sync folder on my "main" server into $HOME/.config/resilio-sync (for systemd sanity) and things were a bit wacky until I also moved `.SyncUser*` folders along with the various `.dat` and `.db*` files. If all of these are part of a snapshot I'm sure the time-travel will work.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now