make_recovery and Omniback II

[Janet Lee]

I'm trying to come up with a disaster recovery plan using make_recovery and Omniback II for our cell manager. If you look in /var/opt/ignite/recovery/makrec.append files it talks about adding the Omniback II fileset to the make_recovery tape. I tried this method in a test, and got hung up because I didn't have X and I didn't know the Omniback command line well enough to restore the database from a tape without the GUI. I talked to Omniback and they told me that they don't support restoring Omniback with make_recovery and suggested that I restore Omniback from the CD. A couple of questions:

1) Why didn't I have X? I didn't use make_recovery -A. Would that have fixed my problem? I checked the manpage and it said /usr/bin is included, but perhaps I need more...?

2) Does anyone have detailed instructions/gotchas for disaster recovery with make_recovery and Omniback II? The natives get restless everytime I bring down the system.

3) Why in the world does the makrec.append files talk about address Omniback to the tape if this is not kosher???

TIA,
Janet

[Patrick Wallek]

When doing your make_recovery I would definitely use the -A option so that it does include your WHOLE vg00 volume group, and if it is in a different VG, the VG that has /usr/ in it as well.

As far as Omniback goes, I don't use it. But I think it should work. One thing I would do is have Omniback installed in VG00 so that your database files are there and get restored when you do your recovery from tape. Something to consider as well is to have the Omniback daemons stopped when you do your make_recovery so that there is not any chance of any of the Omniback DB files getting modified in the middle of your make_recovery.

Anyone with more Omniback experience have any more suggestions?

[Matt Livingston · Accepted solution]

G'day Janet.

Having just undertaken a disaster recovery test this weekend (using both omni and ignite), your question could not be better timed.

1) What make_recovery options did you use? 'make_recovery' with no options will not put anything from /usr/vue/ or /usr/dt/ onto the recovery tape. This will make it pretty hard to run X apps. 'make_recovery -A' will help if your /usr/dt/ or /usr/vue/ are somewhere in vg00 (and almost invariably, they are) The same applies for /opt/omni/ and /var/opt/omni/, except that it would not be terribly unusual for them to reside in a different volume group (if they do, you need to explicitly include them via the makerec.append file)


2) As Patrick suspects, if you want Omniback on your recovery tape, you really *do* need to shut down the OmniBack daemons prior to creating it. If you do not do so, Omniback's database is almost certain to be inconsistent, if not corrupt, upon restoration.

There is one quite significant gotcha to using 'make_recovery -A' The actual ignite recovery can take a surprisingly long time no matter what 'make_recovery' options you used. This slow recovery would be significantly compounded if you were restoring all lvols from within a very large VG00. Try to keep the number of filesystems in vg00 at an absolute minimum if you intend to use ignite.

3) Is that a rhetorical question, or is there a punchline?

[MARTINACHE]

Hi,

Here is my plan for Diasater recoverery :

1) Night backup. The last backup is an omniback database backup (we never used it)

2) Ignite tape (make_recovery -ACi) (one per week or more if needed)

3) Offline omniback database backup (via crontab):
- omnisv.sh stop
- fbackup of /var/opt/omni (assuming that's your omniback database directory)
- omnisv.sh start

This runs very fine. You are able to restore your omniback directory in any server with frestore (this is a little bit difficult with ignite).

regards,

Patrice.

[Janet Lee]

Thanks for everyone's help. Here was my final solution:

_Backup_
1. shutdown Omniback daemons
2. make_recovery -A
3. restart daemons

_Recovery_
1. boot off of make_recovery tape
2. restore Omniback DB (/var/opt/omni/db) and /etc/opt/omni to /tmp
3. shutdown Omniback daemons
4. replace make_recovery versions with new ones
5. restart daemons
6. restore rest of cell manager

I had some problems with getting make_recovery to work because I was restoring to a drive of a different size, but a little adjusting of the LVM config fixed that.

Thanks again,
Janet