I’m aware of the official guide for backing up docker-based installations (i.e docker exec mysqldump for databases and copying the data dir) but I was wondering if I can get away with just copying the two volume locations (data and database) on the host to somewhere? Why is it necessary to do the mysqldump?
Hello,
Well, I would say that it is not a Seafile related question, but more a MySQL/MariaDB issue. 
The database engine uses some caching mechanisms or can be working on the files (while re indexing the database for instance), which can lead the files on the disk to be inconsistent.
That means that if you force a copy of the files as they are, you may end up with a duplicated database impossible to restore.
This is why it is more than highly recommended to dump the databases before backing them up.
Some database engines work differently, like MS SQL which can deliver a consistent snapshot when using the VSS services, but it is not the case for MySQL and this is why you need to call mysqldump.
I hope this will answer your question.
Thanks Romain! That makes a lot of sense and I guess the challenge is doing the backup while the service remains up and running. If I’m happy to do a docker-compose down before backing up I should be good to to go?
You are welcome.
I cannot tell you what to do with docker because I am not using it 
However according to the Seafile manual it is best to backup the database before the data itself, that’s the only thing I would be able to recommend.
Assuming you are certain that all data you’re backing up is quiescent (in the default compose file, that should be the case), then backing up after a ‘compose down’ should be fine.
Out of curiosity, have you thought about why you’re backing up the seafile server? In my case, for example, I don’t. The seafile server is a versioned backup of the data. If a client loses data, I restore from seafile. If the seafile server dies, I rebuild it from one of the clients. If I’m uber-paranoid about the data, I’ll do backups of it from a client.
I agree that backing up from client makes more sense but the problem is I don’t have a client that has all my vaults syncd. Also My home server is the only that’s always on so it’s easier to set up a cron job for backing things up.
I used to consider my seafile as a backup too… and also as an archive. I moved parts to folders that don’t sync to any client anymore to keep the clients clean. That went really well until I accidentally killed my seafile storage with a bad deployment pipeline when I wanted to update my traefik on that server. 100GB+ vanished in seconds. That said you should always backup your seafile. Even if it is just a snapshot.
I just wrote a script that dumps the db and rsyncs it with all the seafile data to a remote server. I let this script run every 4h. This way I don’t version any data on the remote server but I always have a desaster recovery at hand.
2 Likes
Blockquote
I moved parts to folders that don’t sync to any client anymore to keep the clients clean.
Boom, suddenly it’s not a backup, now it’s an archive. By definition, a backup implies at least two copies. Your reasons for using seafile as an archive escape me, but yeah, if you’re using it as an archive for data you care about, definitely back it up 
1 Like
I know. That was my bad and there is no excuse. Thank god that the important stuff was still on one client at least. 
But as long as there is only one other user using the seafile instance you should always make sure there is a backup. There are more people like me out there.
2 Likes
We should all keep in mind that a file sharing service is not a backup…
I try to explain that everyday to Dropbox, OneDrive and Google drive users who think that it is a free backup service
1 Like
Everyone has their own strategies, I would strongly recommend backing up the entire OS/container with the database, ie a transparent backup process, no room for errors