Backup using mirroring

[Todd McDaniel_1]

Okay my DBA emails me asking about fast backups using mirroring... IE, split mirrors and use m1 for backup...

I guess to take a cold backup of the m1 and either keep the m0 running.

I can only guess at this point.

I guess to then resync later... not exactly sure...

Any advice on the trepidation of doing this? Is it a viable option? is it inherently dangerous...

I will post back when I know more if it is needed.

[Pete Randall]

Todd,

Yes, it's absolutely a valid method. It's even taught in HP's "Hands On With LVM and Mirror/UX" course.


Pete

[Todd McDaniel_1]

i think they are going to try and use it like pseudo BCV snapshot ... more to come.

[Todd McDaniel_1]

Pete,

I had that course but it has been a few years...

Would that be with lvsplit or simply lvreduce -m1? How would I go about it?

I am very knowledgeable about LVM, just not in this manner.

[Jeff Schussele · Accepted solution]

Hi Todd,

Yes it can be done this way. But it's much safer to use a 3-way (-m 2) for this because with a 2-way mirror, when you split one away you'll have an SPOF for the time that it's not in the mirror set.

So you would do a
lvreduce -m 1 /dev/vg_name/lv_name /dev/dsk/cXtYdZ
to split it off
And a
lvextend -m 2 /dev/vg_name/lv_name /dev/dsk/cXtYdZ
to bring it back & sync it.

We did this with OpenMail datastore disks all the time. It assures the data is completely inactive for a backup of the data on that disk.

Rgds,
Jeff

[Paula J Frazer-Campbell]

Hi
As said a very viable method, BUT

I would suggest using a tripple mirror on a live important database - spit one away and you still have a mirror safty net.

Basically
1. Split the mirror
2. Mount the mirror split
3. Back it up
4. Join the mirror.


Paula

[James A. Donovan]

Jeff is right, but he got the commands wrong. You must use lvsplit and lvmerge, and NOT lvreduce/lvextend!

[Todd McDaniel_1]

thanks jeff and paula...Great ideas, we use that with a BCV setup on my boxes for my application...

This however, is for an application unlike mine...they dont have BCVs.

heh my company is a big one and requires red tape/capacity planning/Project Creation, et al for disk purchases...long and drawn out..

they only have 2 mirrors m1 and m2... I fear they wont have time or $$ to get additional disks...

also, we are talking about 1TB of data here... across several fielsystems/LVOLS...

As I think about it more... I think they are going to be shooting themselves in the foot by trying to find a shortcut....

[Jeff Schussele]

lvsplit has the added benefit of not having to backup the data raw. It creates a new LV with the name
/dev/vg_name/lv_nameb
it suffixes b to the org lv_name.
You have to fsck the "b" LV before you can mount it for "cooked" access.
You then umount the b LV use lvmerge to rejoin them.
But the same rule applies - A 2-way mirror split any way will leave you exposed for the amount of time it's not in the mirror set.

Rgds,
Jeff

[Jeff Schussele]

Hi Jim,

No it's not wrong - it just depends on the backup method you intend to use.
You can lvreduce/lvextend if you are going to backup it up raw - like using dd or such.
There's more than one way to skin a cat my friend.

Rgds,
Jeff

[Paula J Frazer-Campbell]

Todd

The mirror is there as a safety net, but split it apart a you are then running on one set of data with no protection and as sure as eggs are eggs one day when the mirror is slip a disk will fail.

It will then be very deep DO0DO0 time.

How much is the data worth?
How much to have downtime - my last company £100000 / hour.

A terabyte of disks may be expensive, but in relationship to what could happen just how expensive are they.

[James A. Donovan]

Another alternative, if they have OnlineJFS installedand some extra disk space, would be to create some snapshot volumes.

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062951377

[Chris Watkins_1]

Is using OnlineJFS snapshot an option?
Not sure how much space you'd need for the snaplv, or
even if it's a valid consideration in your case.
Just throwing it out there.
It would certainly be safer than running without your mirror.

[James A. Donovan]

Hi Jeff,

Thought about it some over lunch, and I think that if you go the lvreduce/lvextend route, then you're likely to end up with a very messy, dead cat. What do you do if the disk you're backing up has multiple logical volumes defined on it? And if, the extents assigned to the lvol you want to backup weren't even contiguous? What would you do if the logical volume was built using extent-based mirrored striping, then you'd have to know the layout of each disk involved?

The only sane scenario I can think of where it would be OK to use lvreduce/lvextend would be where you know that the disk has only a single logical volume defined.

[Todd McDaniel_1]

Thanks guys for all your posts...

I will pass on your info to the other group for their perusal...

Hopefully they will go buy some disks...


Just an aside... other groups are looking at this as a backup solution for systems with much larger data...I just hope they decide to use BCVs... or at least a 3rd mirror of regular disks.

[John Palmer]

One important point to remember is the performance advantage of lvsplit/lvmerge.

Once split, HP-UX maintains an in-memory bitmap of the LV so that it can identify extents that are stale. lvmerge then only has to resync stale extents (those which have been updated since the split). See man lvmerge.

Regards,
John

[Jeff Schussele]

Good point JP.
I totally agree that lvplit/lvmerge is the preferred way to do this, I'm just pointing out that with a lot of 'NIX stuff - there are usually several ways to do it. Besides I just like to stir the pot from time to time =~))

Rgds,
Jeff

[Alzhy]

Todd,

This is the de-facto approach we are using in the enterprise we're in. And we've architected it in the fashion that does not use array based mirroring (ie, BCV or Business Copy) but just use a bunch of disks to mirror (for backup purposes) filesystems. We use both VxVM and LVM for our volume management.

I suppose you are using NetBackup (still) for which it already has some built in scripts for Oracle backups using split mirrors either with LVM or VxVM. Omniback and TSM also provides ready scripts fro this purpose... essentially what it does is :

1. put the DB Instance in hotbackup mode
2. Optionally suspend the database
3. split the mirrors
4. resume the database
5. get DB instance out of hotbackup mode

Steps 1-5 usually will happen in less than 1 minute so there is practically no noticeable impact. On some of our environments, the split mirror filesystems are "floated" to a different server where it is moved to tape. This is done by either using LVM/VxVM export and import... Once on the backup server, the backup software will at its lesisure move data to tape without affecting the source server or the LAN at all.. once movement to tape is done, the LUNs comprising the mirror filesystems are "floated" back to its original server and resynched for another round of backups...

HTH.

[Todd McDaniel_1]

Nelson,

I wasnt too clear initially, but it was for another application managed by a different SA, where they have no BCVs and their data is very large. They dont trust that their backup solution will be able to back it up within a required window.

They were just trying to bounce ideas off those of us who have existing solutions.

I believe they will be using a 3rd mirror for the snapshot but that will require them to purchase a boat-load of disks.