shoeper
commented
6 years ago With the backup server it should be possible to do an online migration (I have not tested the feature myself, though). It synchronizes the libraries incrementally. You would need to test how long one sychroniation takes, though. That would be the downtime to do a safe switchover from the old to the new server.
Also with the new storage mapping feature a migration could happen library by library in the background.
But so far there is no existing tool I know of to migrate such setups. One possible solution could be writing one that copies over a library, temporarily blocks access, makes sure all data has been copied over (best would be to have a look at the commits - if it matches no new data was added, if not all commits until we reach the one already on the new server and the contents changed within them need to be copied over), switches over the mapping to the new storage and restores access. I'd expect the downtime per library to be very low and the program could also do two iterations of the commit comparison (one before blocking access, one after blocking access this should reduce the library downtime to almost 0).
I would recommend to store commits and fs on an SSD array in the future. Those do not need very much storage but contain a very large amount of files.
Seafiles way to store data on disk poses a major problem for any kind of data migration or disaster recovery.
We currently use a ZFS-Filesystem with about 20 TB of data. Because the storage server used is getting old, we are trying to migrate the data to a new server, preferably to a filesystem that is not ZFS. This is a major problem.
An initial rsync of the data takes about four weeks. A followup rsync takes about 2 weeks, no matter of how much data needs to be actually copied, because rsync needs to take a look at the modification time of each of the hundreds of millions of files. We tried other ways to copy/sync the data (for example lsyncd), but those run into various problems too because of the large number of files and directories - lsyncd needs about a week to setup the inotify watches alone for example. Cause we can't take a production system offline for two weeks, we are probably stuck with ZFS and using send/receive to transfer the data, which takes about a week for the initial sync and an hour for the final synchronization.
It would probably be a good idea to rethink the on-disc format of the data. The central problem is the insane number of very small files that need to be handled. Another, probably more practical option with the new support for multiple storage backends would be to implement an easy way to online-migrate libraries from one storage to another, either all libraries at once or library by library.