Operating System - HP-UX
1752808 Members
6427 Online
108789 Solutions
New Discussion юеВ

Re: Backup using mirroring

 
SOLVED
Go to solution
Paula J Frazer-Campbell
Honored Contributor

Re: Backup using mirroring

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.
If you can spell SysAdmin then you is one - anon
James A. Donovan
Honored Contributor

Re: Backup using mirroring

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
Remember, wherever you go, there you are...
Chris Watkins_1
Respected Contributor

Re: Backup using mirroring

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.
Not without 2 backups and an Ignite image!
James A. Donovan
Honored Contributor

Re: Backup using mirroring

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.
Remember, wherever you go, there you are...
Todd McDaniel_1
Honored Contributor

Re: Backup using mirroring

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.
Unix, the other white meat.
John Palmer
Honored Contributor

Re: Backup using mirroring

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
Honored Contributor

Re: Backup using mirroring

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
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Alzhy
Honored Contributor

Re: Backup using mirroring

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.
Hakuna Matata.
Todd McDaniel_1
Honored Contributor

Re: Backup using mirroring

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.
Unix, the other white meat.