As part of my Linux backup scheme (which I need to write up someday) I've recently been swapping and upgrading/replacing some USB hard disks at home. There's a Linux box at home (a Thinkpad T43p running Ubuntu if you must know) that has a 320GB disk attached and mounted as /mnt/backup and was running fairly low on space.
jzawodn@wasp:/mnt$ df -h /mnt/backup Filesystem Size Used Avail Use% Mounted on /dev/sdb1 276G 211G 51G 81% /mnt/backup
That was after I moved about 50GB of stuff off it last night.
I want to replace it with a newly attached 750GB disk and need to move all the data over to the new disk. But since much of the data consists of remote filesystem snapshots produced using rsnapshot, which makes copious use of hard links, it's rather important that I do this correctly. If I don't, the data won't even fit on the 750GB disk!
(If that seems impossible, you don't quite grok hard links on a filesystem yet.)
Digging deep into my Unix past, I remember needing to do this once before. The trick was not to use any of the usual suspects: cp, tar, rsync, or mv. Instead, you use either dump (yuck) or a combination of find and cpio.
It looks something like this:
mkdir /mnt/backup2/snaps cd /mnt/backup/snaps find . -print | cpio -Bpdumv /mnt/backup2/snaps
cd /mnt/backup2 mkdir snaps ( dump -0 -f - /mnt/backup/snaps | restore -v -x -y -f - ) >& ~jzawodn/dump.log
And then I waited about half a day for the copy to complete.
root@wasp:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 276G 212G 50G 82% /mnt/backup /dev/sdc1 688G 284G 370G 44% /mnt/backup2
Not bad. A quick edit to /etc/rsnapshot.conf to change my snapshot_root from /mnt/backup to /mnt/backup2 and that's all it took.
Next time I have to go through this, it won't take me nearly as long to devise a scheme to get it done.
Now, does anyone have alternative methods? Or do you know why cpio didn't preserve timestamps correctly?
Posted by jzawodn at February 28, 2008 08:40 AM