mirror data from one lvol to another

[Mark Henry_1]

Hi All,

I want to make a replica/replacement of one lvol to another.

lvol mirroring is not an option as my VG will not support the required amount of new physical volumes needed based on PV & PE limits in the VG.

So, I've created a new VG and lvol with room to grow.
As far as copying the data, what is the best tool for the job? There's probably many ways to do it, and since this new lvol will assume the place of the old, I'd like to do as close to a byte for byte copy such that the replacing lvol should be transparent to the system (but don't we always..)

Thanks for your assistance,

Mark

[Pete Randall]

Mark,

What does the lvol contain? A file system? A raw database lvol?

Assuming it's a file system, I would probably lean toward the backup/restore method, though you could try find piped through cpio or even cp -r.

Pete

[Steven E. Protter]

Your best bet for a reliable transport is a process that includes vgexport

followed by vgimport.

I don't have a procedure here, but one of the big guys like Ferugeson or Stevenson probably has one handy.

There are reasonable proceures available with a keyword search on itrc.

Or maybe I'll do the search for you.

Take a look at this post. Procedure and everything.

http://search.hp.com/redirect.html?url=http%3A//forums.itrc.hp.com/cm/QuestionAnswer/1,,0xd8d7a135f587d5118ff00090279cd0f9,00.html&qt=vgexport+%2Bvgimport+%2Blvol&hit=3

STeve

[Martin Johnson · Accepted solution]

You can use fbackup and frecover. Just mount the newlvol to a new mount point:

moun /dev/vgxx/newlvol /newmountpoint
fbackup -i /oldmountpoint -f - | (cd /newmountpoint; frecover -Xrf -)

HTH
Marty

[James R. Ferguson]

Hi Mark:

Use 'cpio' like this:

# cd /olddir || exit 1
# find . -depth ???print | cpio -pudlmv /newdir

..where /olddir is your old mountpoint and /newdir is your new mountpoint (logical volume). When done, edit '/etc/fstab' to change the device file associated with the /olddir mountpoint and eliminate the /newdir mountpoint. In that way you will have exchanged the logical volumes while retaining your original mountpoint directory name.

BTW, it is very normal/expected for the size of the /newdir to be somewhat smaller than the old source /olddir. A filesystem's inode requirements grow as files are added but the space allocatated never shrinks if files are deleted. Rebuilding the filesystem's contents from scratch allocates only that needed.

Regards!

...JRF...

[Mark Henry_1]

All,

Thanks for the replies.

Steven, I'm not reusing the same lvol/disk, I'm moving the data to a completely new one so not only is the VG data different, but it contains PV's on a seperate raid altogether.. if I understood your reply.

Thanks for the other options - I guess I'll pick one and pray - seems like cpio is a common choice.

What about dd? Wouldn't this be lower-level - could cpio leave stuff out?

Thx,

Mark

[James Odak]

unless this has changed with 11i cpio might fail if you have files 2gb or larger

10.20 it definitely will, 11.00 as well i am pretty sure

if thats the case your kinda stuck using the backup to tape option

[Sean OB_1]

Here is what I have done in the past that has worked well for me.

Mount the new lvols in tmp:

ie:

mount /dev/vgnew/lvolnew /tmp/newmountpoint

Then I copy shutdown everything that would be accessing the old file system and copy it over:

cp -Rp /oldmountpoint/* /tmp/newmountpoint

Once done I verify data is correct using whatever method you like.

I then unmount the old filesystem and new filesystem and edit /etc/fstab to point the new filesystem to the old mount point and remount it.

You will then have the new filesystem mounted in place of the old filesystem and can bring up your apps for testing.

[Martin Johnson]

Be careful with Sean's method (using cp). If you have any sparse files, they will be expanded using cp (or tar). That is why I recommended fbackup/frecover.

HTH
Marty

[A. Clay Stephenson]

Dd can certainly be used (and will probably be faster) for this but to be reliable, the source lvol would need to have its filesystem unmounted.
It is also necessary that the destination lvol be at least as big as the source - if smaller diaster; if bigger space will be wasted as the filesystem will know nothing about it. If you are going to use dd, then choose a fairly large blocksize and specify only the bs paramter rather than an ibs= and obs= to avoid dd's internal copy from the input buffer to the output buffer.

Now, having said all this, my weapon of choice would tend to be cpio.

[Mark Henry_1]

A. Clay,

Critical point!

You say the space would be wasted on the destination fs if it's bigger than the source? Why so (technically)? The fs creation is independent of the copy operation right? (I've already made the fs - which can be blown away if necessary)
So, if the destination fs ultimately needs to be bigger, initially create the same size as the source and lvextend etc. later on?

-M

[A. Clay Stephenson]

Because dd don't know nothing about no filesystem. It's doing a block by block copy and thus is copying the original LVOL's filesystem - metadata and all. Any existing filesystem on the destination is simply overwritten.

If the destination were smaller then some of the filesystem blocks would be missing BUT the filesystem wouldn't know it; if the destination were larger the filesystem would know nothing about it because it's internal data still hold the original size. After dd is finished and if the destination LVOL were bigger, you could run extendfs or fsadm to grow the destination filesystem to fill the LVOL.

[Mark Henry_1]

Oh ok, but cpio doesn't have this prob...

That's really interesting. Off topic, but are there other super-low-level cmds like dd out there that need special consideration also?

Great, well looks like cpio is a consensus then.

Thanks to all!

Cheers,

Mark

[Mark Henry_1]

ok, one last question..

does cpio preserve owner group info?

thx,

M

[S.K. Chan]

Yes because the cpio command calls lchown() function so that it can preserve the attributes like ownership and permission.

[Bill Hassell]

All the classic Unix utilities (tar, cpio, pax, etc) will FAIL to copy largefiles (> 2Gb). The find|cpio -p... command is the fastest copy method in that files are read in large blocks. dd sort-of works as lng as the lvols are the same size but unless you specify bs=64k or similarly large value, dd will be much slower than cpio. dd will copy empty space on the source since it knows nothing about filesystems. Using mirroring is also very slow since extent copies are atomic (they suspend all activity until the mirror extent has been verified as accurate).

Sparse files (very common in databases) will always be expanded, even with frecover unless the -s option is specified.

[Mark Henry_1]

Guys, the cpio command worked great, thanks.

James, I'm curious though, you said to use the 'l' flag which apears to use links instead of copying the file.
This is not desirable in my case so I left it out.. or do I not understand..

Thanks,

Mark

p.s. would cpio preserver setuid & sticky bit modes?