19 Comments
- ricksite, on 10/12/2007, -0/+3Rsync is nice for transferring files locally or across a network. For instance, if you are moving 40GB of data to a new server, you can use rsync to transfer the data to the new server ahead of time to make sure everything is working. Then, when you are ready to make the final switchover, you can run rsync again and it will only move the changed files over (which is presumably a small amount of data).
- scummins, on 10/12/2007, -0/+2This is an absolutely awful guide for migrating a live filesystem. tar or cp are just about the worst choice for a data migration, and should really only be used if alternatives are not available. Assuming the migration is being done at the host level, preferred tools would be:
Volume-level mirroring using the host's logical volume manager, which can do a migration entirely in the background without having to take applications offline.
Rsync, which has incremental copy ability, so the initial full copy can be done offline.. only the last incremental needs to be done offline.
A 3rd party tool that can intercept writes at the driver level and mirror them to the target filesystem -- EMC's Open Migrator/LM for UNIX, for example, can do a live migration.. the only application outage required is to unmount the old volume and remount the target volume to the old mountpoint.
tar and cp can't do incremental copies, and can't do block-based mirroring, so the entire migration has to be done during an outage window.. or you run a very high risk of losing writes that are made while the migration is in progress. For example, if you attempt to do a live tar/cp migration of file1, file2, and file3 -- say tar/cp is in progress, has already copied file1 & file2, and is currently copying file3. If a user/application changes file1 or file2, the changes to those files will not be propagated to the target filesystem.. so when you cut over, the new volume will be missing the changes. Depending on the type of data being migrated, this could be a Very Bad Thing. - marnaq, on 10/12/2007, -0/+2Great. Now I only need a Linux System and a File System - after that, I can start moving away.
- felderado, on 10/12/2007, -0/+1I'd have gone with rsync too. This is silly. no digg! :P
- geniusj, on 10/12/2007, -0/+1Why does this not mention filesystem level snapshots anywhere? That'd be a safe thing to do before you start your copy, I'd think.
Make a snapshot and then copy the files from the snapshot. - DontSayFanboy, on 10/12/2007, -0/+1
When I need to migrate live data on Solaris, I use ufsdump. You can do a level 0 dump at first to copy everything over, then when you are ready for the final switch, you can do a level 1 to only copy over the changes that happened since the last level 0 in case there were many open files that were actively being written to.
ufsdump does not incurr the overhead of rsync's checksumming algorithim and instead uses native filesystem structures. It also has the benefit of being on every Solarirs system in the enterprise, whereas rsync would have to be installed seperately. - inactive, on 10/12/2007, -0/+1I agree. This is silly. It really doesn't take into consideration live services at all, nor ensuring exact copies of files to the point that the filesystem is remounted.
- bdp1, on 10/12/2007, -0/+1Agreed. If IBM Developerworks were a new resource I could see linking to its entrypoint to generate some publicity. But in reality it has been around for years and the featured article (which details using cp and tar) discusses some of the most unsophisticated activities to be had with a Linux filesystem. If anything, this article has told me more about the experience of the people 'Digging' it than anything about Linux.
- sholdowa, on 10/12/2007, -0/+1What's this 'reboot asap' windowsism doing in the article???? Bah!
- doolittle, on 10/12/2007, -0/+1Unfortuantely linux does not have mirroring bundled in lvm like HPUX had with mirrordiskUX and solaris under SVM/disksuite or veritas, we are stuck with /dev/md devices. Set up with lvm then it get's as good as HP/solaris as far as resiliance, with the price of a headache ;)
There is a pretty good md guide here, except they forgot to create a mirror swap device.
http://www.debian-administration.org/articles/238 - Drakazz, on 10/12/2007, -1/+2Very nice :)
- unklematt, on 10/12/2007, -0/+0Hey.. quit beating up on tar. For systems you CAN take an outage on, it's great for dumping a FS to new disc. I do prefer ufsdump or Veritas VM (yeah... I do Solaris), but they aren't as portable and cheap as good ol' tar. cp can burn in hell.
- inactive, on 10/12/2007, -0/+0Rsync for nix based systems and securecopy for windows here. Never had a problem with either, and they are both tried and true. If it ain't broke, don't fix it.
- werunit, on 10/12/2007, -0/+0http://www.websearchinfo.com/unix-systems
Check it out, it proves this. - scummins, on 10/12/2007, -0/+0Not really an option for a live migration.. If you migrate from a point-in-time snapshot while there is live IO still on the production volume, then you miss any writes that come in after the snapshot creation and before the migration cutover.
- billmcgonigle, on 10/11/2007, -0/+0Since this page is a #1 hit on Google and gives a poor example for moving filesystems, I'll add a link here to summary I did a couple years ago on this, using rsync with the proper options for actually preserving filesystem semantics:
http://blog.bfccomputing.com/articles/2005/08/13/copying-a-unix-filesystem
I've done it the way the article described... and got burned. - i440, on 10/12/2007, -1/+0Why doesn't Windows let your resize the system partition? It should be safe enough. I always need to use a Debian CD.
Actually, it only worked with NTFS. After I tried resizing a FAT32 partition, I really did get BSODs. ): - wufenshu, on 10/12/2007, -4/+0http://ddsx.info/sitemap.htm


What is Digg?
Browsing Digg on your phone just got easier with our enhancements to the