Hej,
Seafile stores data internally in a version control file system, similar to RCS/SVN.
Deleted data stays until seafchk is used to wipe the data.
Is there a way to utilise this structure as ransomware protection against a virus which has access through SeaDrive?
E.g. create a threshold of XXX files being changed to stop operations or pull back old versions of the same file?
Thanks, -MN
Yes, mostly. Like so many things it depends.
In the web interface you can set the library history setting so that a library keeps all versions of files for the last X days, or for all time. After you have cleaned up a client from a ransomware infection (presumably wiped and reinstalled), you can turn to seafile to restore the good versions of those files. From the seafile web interface you can view the change history of that library looking at older versions until you find that last good state, and then restore the library to that state.
This does assume that the ransomware has not infected the seafile server itself. Also this assumes that it was not one of those increasingly common varieties that comes with some human interaction, where the criminals will try to find what sort of backup/recovery systems you have, and break them to push you into paying. For those more sophisticated attacks the best defense is a completely offline backup (backups stored on a drive/drives that are then physically disconnected so they are completely out of reach for the criminals). But it is nice to have both so you can use the quicker and easier restore if the situation allows, and fall back on the more complicated recovery only if you really need to.
Each snapshot is incomplete, you’ll end up hunting each tiny file in the change log until you start decomposing.
Any idea how to get a full snapshot?
And if you restore that snapshot, does it save the latest version of the files as a snapshot as well? In other words, if you go back to that time and files are encrypted or what have you, can you keep restoring?
I’m sorry I wasn’t clear. There are 2 history views (that I know of at least). You can point at a file to make some buttons appear (a bad UI choice IMHO, but not too bad once you know to look for it), click the little arrow, and click history. This shows the history of the file you selected, and lets you revert that file to a previous state. This is mostly useful for reverting mistakes made to individual files.
The other one is a history button at the top of the web interface when viewing the top directory of the library. This one shows the history for the entire library, so it will be a long list of “Added file a”, “Renamed file A”, “Deleted file B”, etc.
If you then point at one of the lines here another invisible until mouse-over link “View Snapshot” appears letting you look at the library as it was at that time. In this view there is a “Restore” button at the top-right corner that will revert all files in the entire library to the state they were in at the time of that change. There is also a button (again in the hidden until mouse-over buttons) for restoring individual files from the snapshot.
These restore operations just add to the history without removing any old entries. So after you have done the restore, the history will have a new line “Reverted library to status at …”, or for the individual file restore “Reverted file “A” to status at…”. The library will still use all the extra space for the encrypted versions of the files until they age out of the history (based on the library’s history setting), and they are still accessible in the history.
So in the ransomware example, after you cleaned up (or at least took offline) the infected system, you can revert the library to the last good state before the ransomware started breaking files. Then if someone complains that they had added a file since then and the restore means the file is now missing, you can hunt that file down in the history, and restore it individually without breaking the other files.
I would suggest that you create a test library to simulate this situation with. Throw in some files, zip them, go to the web interface and revert the library to before they were zipped. If it ever comes up, you will be glad to have practiced the recovery.
I didn’t fully answer that one. The restore just adds to the history, it doesn’t undo any history. So if you revert to an old snapshot, you still have all the older and newer snapshots, and can do the revert again from them if you need to. You don’t have to get it right on the first try, it can take a few tries to find the one that is “last known good” state, no problem.
Yeah I tried this stuff but Seafile messed up the snapshots too after the first delete command when I selected “do not sync” on a directory within the library. So none of that was useful, blank files, duplicated directory structures and randomly placed files that actually have content - Meaning Parent and Parent 2 co-exist, but their children are not the same, sometimes it’s 0 bytes in Parent sometimes 0 bytes in Parent 2. Seafile created Parent 2, by the way, for whatever unknown reason after the “do not sync” command. And then it wasn’t limited to just that parent folder, it did it for 2 more folders that were siblings of the one I selected do not sync.
Once you select a snapshot you do not have file history anymore, so that’s also… great. Which means that if you now are trying to find the latest version of a file you have to keep switching snapshots and the clients go insane modifying files and so on. Doing that for a week’s worth of changes and additions to tiny powerpoints and word documents is an insane amount of manual labor.
Thanks for your help though, this got me on the right path at least, even though I have what I can only assume weeks of manual labor to get the right versions of each of my files.
Happy to help. Wish I could help with that problem with the “do not sync” but it sounds like quite a mess, and not one I’ve faced personally (I don’t even know where that option is). Hopefully you can automate some or most of the cleanup with some simple bash scripts or something.
