- Integrated Systems
- About Us
- Integrated Systems
- About Us
01-31-2003 02:26 PM
Thanks in advance.
Solved! Go to Solution.
01-31-2003 02:32 PM
make_tape_recovery is the tool to use and it can include other volume groups.
make_tape_recovery still uses pax which can't archive files bigger than 2G so you still have issues there.
Here is a make_tape_recovery script.
/opt/ignite/bin/make_tape_recovery -Av -x inc_entire=vg00
You can obviously include multiple volume groups.
Owner of ISN Corporation
01-31-2003 02:42 PMSolution
Take regular backup of all the file systems. This is planB.
You will need to upgrade your ignite to the latest version. make_recovery is completely obsolete and has been replaced by make_tape_recovery.
When you recover the system with the cables connected, it will import the volume groups and get the system back to the state when the make_tape_recovery tape was created.
However, my practice is to disconnect all the cables and let make_tape_recovery restore vg00. Then I import the other volume groups using vgimport command. I generate maps on the server regularly and store them on a different server.
For ex., regularly do the following.
vgexport -p -v -s -m /tmp/vg01.s.map vg01
vgexport -p -v -f /tmp/vg01.disk -m /tmp/vg01.map vg01
Copy vg01.s.map, vg01.map and vg01.disks to another system. Repeat the same for the other volume groups.
In case of disaster, remove the cables and restore the OS using the tape. Copy the above map files and import the volume groups.
#mknod /dev/vg01/group c 64 0x010000
#vgimport -v -m /tmp/vg01.map -f /tmp/vg01.disks vg01
(if this fails, use the following command)
#vgimport -v -s -m /tmp/vg01.s.map vg01
#vgchange -a y
This should get the file systems back.
PS: We are only trying to be careful with the data. Ignite does have the capability to import the other volume groups.
01-31-2003 03:39 PM
if you will do a make_tape_recovery -A x inc_entire=vg00 it will backup all the vg00 .
the ignite is for only backup the system and he is not for backing data .
if you will restore the system with the tape that you make it will restore all the vg00 that you have .
after that you have 2 option .
1. to recreate the vg's that you have , logicals volume and file system and restore all the data , the method is prefer if you had a fail disk with data .
2. it is highly recommend to do a vgexport of the vg's that you have to a map file with the command :
vgexport -p -v -s -m /tmp/vgXX.map vgXX
that you can vgimport the voule data that you had .
you will need to recreate the voule group but after that you can export the lvm data with the command vgimport :
vgimport -s -m /tmp/vgXX.map vgXX .
remember to active the voule group with vgchange -a y vgXX .
01-31-2003 03:53 PM
1 - During make_recovery, vgexport (s) are done. Why do you need to do this again after rebooting?
2 - We use omniback to backup the contents of the other vg. Is it Ok ?
Thank you Steven for the advice but we need these backups now and let???s go with make_recovery this time. What I had asked is the procedure to follow after booting with the bootable tape : I mean what to do for volume groups, logicals volumes and file systems others than vg00???
I will not forget points.
01-31-2003 04:19 PM
OmniBack is and can be used to backup larger filesystems utilising tape libraries etc. and large databases, where you have the extra tools of doing hot and cold backups. The standard tools for backup do not incorporate any such features for taking care of databases. It is quite easy to recover the information for other volume groups, providing the filesystem structure is there.
If your choosing the make_tape_recovery method for vg00, you will have the LVM information built in. This will only be useful if the same disk array is being used.
As a matter of course, we generate on a regular basis, mapfiles (vgexport) and are kept separately to everything else. Never run the vgexport command without the -p (preview) option, unless you plan to remove your data.....
I would generate a make_tape_recovery tape like this, just so if you need to make any changes whatsover, it creates an interactive image, and not just a image that cannot be changed.
# make_tape_recovery -x inc_entire=vg00 -I -v -a /dev/rmt/0mn
To create your filesystem images, recover the information using the /vgimport/vgchange commands. From there, mount your filesystems.
To get your data back from omniback, assuming that the same host name and IP are used, it is simply a matter from your cell manager of selecting the filesystems to be restored.
01-31-2003 05:42 PM
You were right. make_tape_recovery does vgexports so that it could vgimport the vgs during the restore process. However, most of the System Administrators prefer to disconnect the disk cables to be on safe side during the recovery process. In this situation ignite will not be able to import the VGs.
After OS recovery is done, you will need to copy the map files (if you took ignite recovery after the vgexports were done, then they will also be restored after recovery) so that you can manually import the volume groups.
You can use omniback to take backups. You can even use fbackup. However, if you successfully imported the volume groups means you have the data. Still it is a good idea to take backups in case soemthing unwanted happens.
Please note, unless you have latest ignite installed, you will not be able to restore an image of N4000 on an RP7400 (a later generation N-server)
01-31-2003 08:31 PM
If it's a corruption or something that has rendered just the boot volume group suspect or unusable, and you use one of these tools to restore just the root volume group back onto the same machine it came from and the rest of your data is intact, then that's good.
If you're restoring, say, at at offsite disaster site because your data center was flooded, then you have a different case, clearly. Others have said you can use make_tape_recovery to include the other volume groups, so you could evaluate that.
However, ignite really takes care of the special circumstances that are required to make the machine bootable. You may find that backing up the entire machine using another mechanism, such as fbackup, omniback, netbackup, etc. is a good idea. It gives you the option of using a more robust solution for what may be a much larger amount of data, and in fact may be split up across multiple tape drives, etc., while keeping the ignite to just the bootable volume group. This may allow you to speed your recovery by firing off multiple restores of external volume groups once the single-threaded ignite process has handed you back a booted machine.
One technique, of using an ignite followed by a full fbackup on a weekend, and incremental fbackups during the week, will even let you use the ignite to get back the root volume group, and then apply the incremental fbackup to get back changes to the root volume group that happened during the week, such as that user who changed their password on a Tuesday without having to do a complete ignite every day.
Plus, the fbackup-style backup gives you a 'backup' plan in case your ignite tape is no good, although it's much more involved -- better than having no option at all.
Just some things to think about...
02-01-2003 09:50 AM
??? ??? In this situation, since you are restoring the OS to the same disk, on the same machine, all of your other data is still on the other disks and SHOULD be available once you are done restoring from tape.
All of your VG information (/dev/vg*) was backed up and since the disks are the same, everything is back once your machine reboot. " as found in the forum.
Thanks to all for your answers.
Some Interesting links for more information.