In the good old days, we’d have a Windows Server offering shared folders. This would be backed up every night (or more often) with something like Backup Exec. The most common request you’d have to handle (outside of disaster recovery) would be restoring an accidentally deleted file/folder or accidentally corrupt/changed file. You’d ask them when to restore from, jump into Backup Exec, complain about the user interface but you could restore that one folder/file in a short period of time.
How do you do something similar with Seafile? At the moment, we’re using Veeam to backup the entire VM every hour so we do have a frequent backup. But to restore that we’d have to restore the entire VM to some sandbox and somehow bring it back online, connect to it to get at the file.
I’m hoping somebody will say “Ohh easy, Seafile exposes a CIFS file share (or whatever) of the entire folder structure and you can back that up”…
Seafile’s snapshots are the first (and super solid) line of defence. Unless you limit your history to an unreasonably short period, Seafile saves all files and prior version of the files your user can remember of. You as the admin do not even have to get involved when it comes to recovering an unintentionally deleted file: Just point your user to the history function and let him/her recover the data from the snapshot. The user cannot break anything. If he/she restores the wrong snapshot, a new snapshot is created in the process.
I would only restore the entire system in the event of a major disaster: Backend corrupted/dead, hard drives went up in flames, …
If you want to directly access data in the backend, you can use FUSE.
You can also backup every individual library (using rsync for instance) and database dumps. If you need to restore for a particular library, import the database dumps in a fresh Seafile Server instance, copy the library data in the seafile-data folder and recover the data you need to recover. (In this Seafile Server instance, you will see all libraries because the database dump contains information on all. But you’ll only be able to access the library whose data you have copied in the seafile-data folder.)
I appreciate that this may be the “old” way of doing it and snapshots are a great way to protect yourself from ransomware but disaster recovery isn’t the requirement here. The Veeam backup of the Seafile server is the fastest way to recover instantly the entire system (and it really is pretty instant) to a point in time so combined with snapshots we’re covered.
But this isn’t about disaster recovery - it’s about ad hoc restoring of files/folders. The request is often “Can you please restore XYZ folder from last Monday night”. We’d typically restore just that folder to another location so the user can sort it out themselves because they don’t want to restore to the original location - often newer files might have been added.
Version history and trash do help a lot here but still not quite the same.
One client is even more paranoid after their QNAP NAS was attacked - they want a file system copy on an external hard disk! The only current solution is to have a seafile client running somewhere that has access to all libraries and use robocopy on a synchronised task. Real sketchy solution and has the downside that you need double the storage for the synchronised copy.
It’s maybe one for the wish list - somehow expose the entire file system as a SMB share (or whatever) so that even simple tools like robocopy can be used. The seafile-data folder isn’t usable for this.
I’m just doing a restore of my own Seafile Linux server on Hyper-V so check it’s possible. However, I’ve just eaten up another 100GB on my server for the temporary restored VM. And I’m not even sure I can bring them both up at once as they’ve got the same name/IP as the live version.
“Each library in Seafile tracks your file deletion operations automatically. Sometimes you find files are deleted mistakenly. You can find back your delete files in the trash bin of each library.”…
Turned out to be moot. Client went with Nextcloud instead because the community edition offered more granular security controls, i.e. can disable the share link externally option. Don’t ask! Take a great feature and make it useless because of security concern.
Same requirement of Nextcloud but was easy to sort there as everything is stored in data/username/files so a quick rsync sorted out the requirement to copy elsewhere.