Best way to migrate data

[Darren Gibbs]

We're migrating 2.5 TB from an XP256 to XP1024 and I'm wondering the best way to copy the data. Each new target LV will be the same size as the source LV and striped across 4 LUNs with a stripe size of 32Kb. We do not have MirrorDisk/UX, and the data is for an Oracle database that is housed in 80 GB filesystems with largefiles enabled.

On our test server, we ran several streams of cp -Rp to copy each filesytem but we could only utilize about 20% of the CPU resources and our copy rate averaged 40 MB/sec.

What other methods can we try for better performance?

[Vincent Fleming]

Here's my suggestion:

Get your Sales Rep to loan you a couple of ESCON CHIP pairs for the XPs. One pair for the XP256, and one for the XP1024. Have them installed, then download an eval copy of Continuous Access for each frame. (This is assuming you aren't using CA on either frame, and have no ESCON CHIPs.)

You can then have the disk arrays themselves migrate the data... seamlessly, and quickly.

You can set up the mirror pairs via Command View and/or Remote Control.

Good luck,

Vince

[Rita C Workman]

Oh, I can say without a doubt the best way is found in this thread !! I just started my data migration last weekend...and I was beyond happy with the results !

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb6e7e822e739d711abdc0090277a778c,00.html

I gave you the Thank You thread because it mentions a couple points...follow to the original...and relax !!

Regards,
Rita

[Chris Wong]

Hi,

If you have access to both 256 and 1024 at the same time, add the new LUNs from the 1024 to the existing volume group. Use pvmove to move each lvol from (256) one physical volume to another (1024) within the VG. After the move, vgreduce to remove the PVs that point to the 256. I haven't tried this with striped disks, but it should work.

- Chris

[James R. Ferguson]

Hi:

It's really a shame you don't have MirrorDisk/UX. Its worth every penny in situatons like this. In its absence, you can use 'fbackup/frecover' since it supports largefiles, 'uid' values greater than 65K, *and* it will handle sparse files. I suggest:

# cd /olddir || exit 1
# fbackup -i . -f - | (cd /newdir; frecover -Xsrf -)

Obviously, the database cannot be in use.

When the migration is complete, edit your '/etc/fstab' and change the 'newdir' to the 'olddir' mountpoint name while correctly reflecting the physical device of the new filesystem.

Regards!

...JRF...

[James R. Ferguson]

Hi:

With regard to 'pvmove', it is slow and if it is interrupted for any reason during its existence, the logical volume can be left as "toast".

Regards!

...JRF...

[Rita C Workman]

Chris,

pvmove is the one often mentioned in references, but if you decide not to use the fbackup/frecover then you might want to think about making a connection to the host and adding the disks as a mirror copy. This way the disks will 'sync' up (thus giving you a safer more solid copy) and then you could simply drop the original disk after.
Of course that precludes your vg can handle the increase load of additional disks.

But no matter which way you choose (pvmove, mirror, fbackup/frecover)...read what John Poff says...it will come in handy.

Rgrds,
Rita

[Rita C Workman]

Forget what I just said...missed the NO MirrorDisk/UX stmt.

Sorry....
Rita

[Jakes Louw_1]

Have you considered using DD:

dd if=Raw_source_lv of=Raw_target_lv bs=1024k

This implies a) that you pre-create the entire structure in duplicate on the target XP, and b) that the database/data user is not accessing the source LVOLs/filesystems.

You can then set up various files containing the calls to dd for various filesystems and run the copies in parallel.

[monasingh_1]

I think if you are changing the LUN or PE size on new XP you should stick to copy or fbackup/frecover.
Just remember, after the move you might want to export the VGs and re-import them with the same minor number group file, helps a lot if service guard and nfs is involved.

hope this helps...

[RAC_1]

how about dump and restore?