Hello,
due to a misbehaving nfs-serving NAS, I need to migrate the seafile-data directory to another NFS-Server. There are about 6 TB in files and it takes a few days via gigabit Ethernet to copy with rsync.
I am lacking the ability to take snapshots of the filesystem to first copy everything from the snapshot and then in a second step copy the rest incrementally, which should be a lot faster and I could limit the downtime. But I was wondering, if this is even necessary, because of the way seafile stores its data. Once stored block-, commit- and fs-objects should not be changed as long as garbage collection is not run, right? So I can just rsync for days again and again without breaking anything?
I wonder what would happen if after the switch some file was missing. Probably the Library would be inaccessible until I synched the missing files from the old storage…
I would be interested in your opinions.
Hi,
yes: all files are immutable. As long as you don’t run the garbage collector during the migration there shouldn’t be issues.
Regarding missing files on the new server I’m not sure what exactly happens when a library is synchronized and objects are missing. Most probably it’ll only lead to a temporary outage, but take that with a grain of salt. For a better understanding you could create a test library, sync it with some client(s) and mess it up on the server (e.g. move head commit, move older commits, move the most recent block) and see what happens on adding new files or when another clients comes up not having the most recent data.
I think the biggest issue with a rerun of the copy process will be the large amount of files. If possible a program capturing inotify events of your fs which immediately copies over new files could improve the process significantly. You could start it first and then start the copy process. When the copy process finishes all files should be on the remote server without having to run the whole process, again. I’m not sure on the feasibility and capabilities of your fs, though.
Hi, shoeper,
thanks for your insights! This really helps me with the migration process. I didn’t try out inotify to track filesystem changes, yet. But I used rsync --ignore-existing, which sped up the process to only 2.5 hours. I can live with that downtime for now 
1 Like