rsync question

[brian_31]

I am doing SAN migration for 2 volumes and i find my old data different from new data (slightly less). Can i rsync these data? the old data is in /m01 and new in /mo1_temp..what would be the best way to sync this?

Thanks

Brian

[James R. Ferguson]

Hi Brian:

If you are simply comparing the total size of your mountpoints, or comparing each old directory's size to each new directory's size, you are going to mislead yourself.

The space required for a directory will expand as files are added to it. This space is never freed, however, when files are removed. Hence, when recreating the directory and only adding files to it, the newly created directory will often be smaller than the old one.

On the other hand, if the total size of your *new* directory and its files is *larger* than the toal size of your *old* directory and files, it is likely that you had sparse files in the old directory which were expanded when you copied them to the new directory.

In either case above, the correct way to compare the contents of two directories is to 'cksum' each file therein. An equality in the file's checksums assures you that the copy was correct. This works even when you have a sparse file and are comparing it to an expanded version. Sparse files are commonly seen in with databases.

You don't offer how you performed your copy ('rcp', 'tar', 'cpio', 'fbackup'). My first choice would be to leverage LVM MirrorDisk/UX to perform the copy at the logical volume level. My second choice would probably be to use 'fbackup' and 'frecover' since this handles largefiles (whereas 'tar' and 'cpio' do not) *and* since 'fbackup'/'frecover' can copy sparse files without expanding them.

Regards!

...JRF...

[brian_31]

JRF:

Thanks.

i create a temp mount point and mount it

cd /origmount point

tar cf - .|(cd /temp_mount;tar xpf -) &

This is how i migrated data.

is this a good way?

Thanks

Brian

[James R. Ferguson]

Hi (again) Brian:

Your 'tar' is fine. Apparently you don't have any largefiles (files larger than 2GB to deal with) so this will work.

Regards!

...JRF...

[Don Mallory · Accepted solution]

If you create LUNs of exactly the same size, you can add the new disk to your existing volume group and use pvmove instead.

Speed is about 2GB / hour, but it's online with no user disruption.

ioscan -fnC disk , find disk.
pvcreate disk..
vgextend vgXX disk
vgdisplay -v vgXX

Find the lvol you want to move, source pv and dest pv. T

pvmove -n /dev/vgXX/lvolname /dev/dsk/srcdisk /dev/dsk/destdisk

Rsync will work, but you will find it's actually really slow as it spawns 3 separate processes to do the copy (source, dest, admin). Honestly, the fastest way is to:

cd /m01
find . -depth -print | cpio -pdumv /m01_temp

You could use rsync to check that it's all the same afterwards if you want. Or check using:

find /m01 -depth -print | wc -l
find /m01_temp -depth -print | wc -l
du -sk /m01 /m01_temp

Compare the numbers for the first two (number of files copied), the du values should be fairly close. rsync is more accurate for checking, but slow. All depends on how many files there are.