how can i know the free space in tape after 'make_tape_recovery'?

[yyghp]

how can i know the free space in tape after 'make_tape_recovery'?
because i worry about whether the vg00 backup was successful or not..., and i'd like to add more stuff if there is free space left in the tape...
thanks!

[G. Vrijhoeven]

Hi,

To see if the ignitat tape was created succesfully view the log files:

On an Ignite-UX server, progress and errors are logged to:/var/opt/ignite/clients//recovery//recovery.logOn a local system, progress and errors are logged to:/var/opt/ignite/recovery//recovery.logTask: Recover a minimal operating system


I would use a second tape for extra backups. It can be done on the ignite tape if there is space left but wy bother. If you need to restore it would take to long.

HTH,

Gideon

[Patrick Wallek]

There really is no way to know how much space is left on a tape.

In my opinion it is not worth the risk to try to write something at the end of a backup tape. If you mess up and overwrite part of your Ignite backup, then you have just rendered that tape useless.

[Sridhar Bhaskarla]

You can probably get an idea of how much was being backed up before the compression by looking at /var/opt/ignite/recovery/latest/flist. The 5th field is the size of the file. You can probably do something like

awk '{sum += $5} END {printf "%d", sum/1000000}' flist

to get the total archive size before it got compressed. It also includes the size of the base directories but that will help you get a safe picture. But on the tape, it doesn't take that much as it will be stored in compressed format.

We could ask HP to include the archive size in the logs just like make_net_recovery.

However, I would not suggest to write anything in the free space as it may mess up your recovery tape.

-Sri

[Steven E. Protter]

You can not use the free space on the tape for anything else. Our ignite backups run around 15 G on 200 GB tapes. That space is wasted. That's life.

Ignite is an important DR backup. Do you really want to risk it so increase your tape utilization percentage?

SEP

[Bill Hassell]

One of the worst mistake in backups is to try to put multiple backups on a single tape. It is a nightmare to administer. Someone will always use the wrong command, or forget to write that there are 5 appended backups instead of 4. There is NOTHING in tar, cpio,pax,dump,etc to prevent destroying good backups. At least fbackup makes it very easy: no appending can every be done because the tape is always rewound before writing.

How much is your data worth? Don't ever try to conserve tapes until you know the risk. If complete loss of your data would cost your company $10 million US dollars, then why would you even think about trying to save $50 dollars on a tape when a simple command can totally destroy everything? Backups are like insurance. It can be expensive to pay for it when there is no benefit--until it is needed.

[yyghp]

thanks!
i am going to backup vg00 about 100GB, but the DLT tape only 40GB(80GB in compress mode), how can i make sure i can do that before the backup ? or after the backup, how can i confirm success without restore ?
Thanks again !

[Patrick Wallek · Accepted solution]

You can never truly confirm the validity of a backup without restoring it. That being said, Ignite/UX will let you whether or not the backup was truly successful or not.

Now 100GB seems like quite a lot for a VG00. But Ignite/UX will handle multiple tapes quite well. As long as your are running your make_tape_recovery interactively from the command line, it will prompt you if / when it is necessary to insert a second tape.

If you are running the backup from cron, or something non-interactive, then there is no way for make_tape_recovery, actually pax, to prompt you for a 2nd tape and your backup will fail.

[Sridhar Bhaskarla]

Hi,

There is no 100% guaranteed method to verify your tape as mentioned by Patrick. You could probably test the boot area and contents of the archive using the following commands

Boot area:

dd if=/dev/rmt/0mn of=/somewhere/bootarea bs=2k
lifls /somewhere/bootarea
lifcp /somewhere/bootarea:AUTO -

Make sure the above will give you proper boot information.

Contents:

mt -t /dev/rmt/0mn rew
mt -t /dev/rmt/0mn fsf 1
tar tvf /dev/rmt/0mn

It's going to take a long time to verify 100GB.

The basic thing is that I wonder why you would want to keep your vg00 so big. Maintenance will be a nightmare for you. It is going to take a long time to recover the OS. There is no guarantee that the tapes will not be worn out.

-Sri

[yyghp]

thanks everyone!
Because someone else setup all these boxes before, he used all the local harddrives(73x2GB) to VG00... :(
I wonder whether it's good to slim VG00 or not, is there any risk ? and what's the process to slim VG00, like moving some files to another disk array, reducing the size of VG00...
And as I know, i can use some parameters when i use 'make_tape_recovery' to limit the contents, like '-x exclude=file|dir', is there any risk during restore if i use this? or it's better to backup whole VG ?
Thanks!

[Patrick Wallek]

I prefer to use VG00 for the OS *ONLY*. That way if you do have to reload from an Ignite tape, you just have the OS to worry about and can then (re-)import your other Data VGs from whatever external disk storage you have.

You could potentially slim down your VG00, but that would require some careful planning an coordination on your part if you happen to have production data on VG00. You would have to be sure that your applications are down and not being used while you are migrating data. If you have some sort of disk array then migrating non-OS data to the array would be a good idea (at least in my opinion). As to the risk is slimming down you VG00 -- if this is a production server with production data there, there will definitely be some risk involved.

Now as far as limiting what make_tape_recovery backs up, that is entirely up to you. You can exclude some files / dirs, BUT you *MUST* make sure that those are backed up elsewhere. If you do happen to have something like database data files in VG00, then your make_tape_recovery tapes will not have a good database backup, UNLESS you shut the DB down before you start the make_tape_recovery. If your VG00 disks die and you have to restore you must make sure that *ALL* data is restorable somehow. Again, this goes back to why I like to keep VG00 as OS ONLY.

[Sridhar Bhaskarla]

Hi,

It is good to slim your vg00. As long as the systems are up and running (usually HP systems do) you are fine with this setup. But once you get into trouble, then you would realize.

It's easy to migrate from vg00 to someother volume group. Since you have all 2GB disks, it may not be difficult. However it requires good planning and downtime.

I hope your old sysadmin didn't create huge logical volumes.

You will have to free up disks and use them to create a new volume group.

To look at the PV usage, do a "pvdisplay -v /dev/dsk/cxtydz". You should see the free space (Free PE * PE Size) and the distribution logical volumes in it. You can use 'pvmove' to move the disks around. Once you freed up enough disks to fit atleast one logical volume, then you can take them out of vg00 and create a new volume group, vg01 and a new logical volume and mount it on a temporary mount point. Copy the data from the logical volume from vg00 to vg01. Once the data is copied, unmount the lvol from vg00 and mount the one from vg01 on the same mount point. Test the data. Once you are satisfied, you can remove the lvol in vg00 which will free up more disks. Again follow the same process until you move other lvols out of vg00.

However the above process may not work if you have fewer but big logical volumes.

In this case, you can reinstall OS on few disks and mount the old vg00 as vg01. Use -x exclude options to remove everything other than vg00 filesystems. Install it on those disks and import the old vg00 as vg01. This is a much better and faster approach.

-Sri