0

We have a NFS server (Linux) who stores files in a iSCSI disk array. This server is in production. The server and the array are very old and have to be replaced soon (the array is already in serious problems).

I have the replacement server and array ready in a different network.

I've been thinking about rsyncing the shares and then doing it again so I synchronize the data. I don't know if that could cause data inconsistencies... Since the shares are mounted over an lvm, maybe I could make a snapshot first?

QUESTION:

What is the best approach to migrate all the data? Do you have any advice?

Improve this question

2 Answers 2

Reset to default
0

Your approach is fine, if you plan to disable writing to the array before second rsync. That will (should) lead to a clean copy.

Depending on circumstances, to minimize downtime do a triple rsync:

  1. rsync the filesystems while the source server is running as-is. This will take some time and get you rough copy, possibly witha lot of inconsistencies.
  2. (optional) If #1 takes a long time and you have a lot of writes in mean time, rsync it again with the source server still running as-is. This step will take less time and so you get much better copy (less writes happened while it was running).
  3. Stop writing to source node. Best way is to mount it read-only, as stoned suggest. But shutting down services, or using single user mode could do as well.
  4. rsync it for the last time. This time it should be rather quick. There should not be a lot of inconsistencies (step #2 much shorter than #1), so there is not a lot to sync.
  5. Do your checks and start the new server in place of the old one.

There are several things to note though:

  • If you have a lot of small files (millions), every rsync will take some time anyway. (the same goes for slow lines, slow/degraded storages, etc.)
  • If your source storage is having issues already (failed drives, or something else that could cause the volume to become unreadable), just start at #3. You will get a long downtime, but you minimize the risk of it failing midtransfer.
  • I just got the crazy idea of rsyncing the whole device, the filesystem resides on. Which could work if target is bigger than source. But I do not recommend that, as I have not tried myself.
Improve this answer
1

Rsync+rsync or snapshot+rsync won't really make much difference - with rsync maybe being more handy, since you're able to eventuall compress/encrypt data during the transfer without the hassle of having to use extra commands. In both cases you're going to forever try to catch up with what your users might have copied on the share since the last rsync, including partial file still in transit. Honestly what I would recommend to you is to do a first copy with rsync in a period of low usage. Then, warn your users that there will be a small outage due to needed maintenance. Stop the services writing on the disk. Remount the old share in read only mode, do a final rsync and then completely replace the old nfs share with the new one. If you want/can, you can give customers read only access during that period. 100% availability is a pure dream, and it's better to stop your customers for 1 hour than to chase after possible endless complaints of lost/corrupt data and application crashes.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .