STM Scripting

[Paul Murray_1]

Hello All,

I am trying to write a tape check script which will be run prior to the backup to ensure the integrity of the tape. I want to use the stm "exercise" tool as this will provide the level of testing that is being requested by the business.

However, I do not know if you can trap errors within stm which can be passed back to my ksh script.

Can anyone help ?

TIA,
Paul.

[Robin Wakefield]

Hi Paul,

This is a script I use to get the infolog for the tape drive. You could adapt this to suit your needs perhaps:

#!/bin/ksh

cstm < /tmp/tape_status.log
selclass type tape
info
wait
infolog
saveas
/tmp/tape_status.txt
done
exit
ok
!

Rgds, Robin.

[Paula J Frazer-Campbell]

Paul

This would be is a waste of time in that after the test the tape head could get dirty or other fault occur.



Use verify and if the data does not verify then send out warning.

HTH

Paula

[Paul Murray_1]

Hi Robin,

Thanks for your code example - I am trying to modify this to see if it will work for me.


Hi Paula,

I totally agree, however, dump/vxdump is being used at this site for backups, and unlike frecover, there does not appear to be an option to verify a dump backup set.

(Sorry, I probably should've mentioned that in my initial post!)

I had thought about performing a test restore of a dummy file placed at the end of the backup, but this will not verify the entire backup set.


Thanks again,
Paul.

[Paula J Frazer-Campbell]

Hi Paul

Will this not do it as it works upon success?


u If the dump completes successfully, write on file
/var/adm/dumpdates the date when the dump started.
This file records a separate date for each file system
and each dump level. The format of /var/adm/dumpdates
is user-readable and consists of one free-format record
per line: file system name, increment level, and dump
date in ctime(3C) format. The file /var/adm/dumpdates
can be edited to change any of the fields if necessary.


Paula

[Paul Murray_1]

Hi Paula,

Although that will log the fact that the dump thinks it finished ok, it will not satisfy the business that the backup tape is readable.

I cannot think of any way to perform a verification of a dump/vxdump backup tape - hence the "over-the-top" tape check procedure. At least that will prove to the business that the drive and tape were ok immediately prior to starting the backup.



(Thanks again for helping).

Paul.

[Paula J Frazer-Campbell]

Paul

Just a thought - are all your file systems HFS ?

There are far better more modeern backup/recovery system than dump than can be monitored.

Ignite -

Omniback -

Fbackup has configurabkle params that will carry out multiple attemps on open files -


I get the impression that the business does not want to change.

Paula

[Bill Hassell]

I agree that dump or vxdump (and tar, cpio, pax) are not tools to be used in a production environment. Your need to pre-test the tape indicates that the backup is very important to your business so it is time to abandon tools that were never designed to handle modern multi-gigabyte disks. If the goal is to test the entire tape, you will have to write data on the entire length, then rewind and do a bit-by-bit comparison of the result. Then rewind again and start the backup. This will add between 2 to 6 hours to your backup time.

Commercial backup products have error recovery built-in while a tape read error for classic Unix tools like tar, cpio, dump/vxdump, means you've likely lost all the rest of the data. The easiest way to justify a commercial tape backup tool is to place a value on the data you are saving. Would it cost $10K or $100K or maybe even a million dollars to replace the data in case the backup was worthless?

Then like any insurance policy, you buy a policy (a backup tool) that will payoff when it is needed. Like cheap insurance, the worst scenario is when you need the backup and it won't work.

This also means operator errors too. There's nothing to prevent classic tools from destroying previous backup tapes, whereas commercial tools prohibit writing on a tape until it has been initialized or released for writing. Couple that with high speed data recovery (a few minutes to restore a single file), the ability to keep high speed tapes like Ultrium busy, and to seamlessly handle multi-tape backups, and you won't look at classic tools except for small data interchanges.

fbackup is the closest freeware that meets most of the commercial backup requirements. frecover has a checksum verify pass that can look at current and old tapes to make sure they are error free and 100% readable.

[A. Clay Stephenson]

Hi Paul:

I completely agree with Bill H. Doing a partial test of a tape before a backup is a 'Dr. Feelgood' approach at best and does very little to insure the integrity of the backup itself. It's obvious that a high emphasis is being placed upon backup and this really points to the need for a highend backup product. OmniBack and Veritas are two possible candidates. This is generally a fairly easy sell to a company when you add that this enables them to centralize their backup activites especially when coupled with some sort of automated archival system. You are then able to backup UNIX servers, NT Servers, PC's, and Novell Servers with one tool. If price is a concern then OB2 tends to win over Veritas because OB2 pricing is a function of the total number of active tape drives and not a function of the number of clients. In my case, each nightly backup is automatically copied to a duplicate set of media. This does two things:
1) I know that I have a valid backup because I could read the media in order to make the copy. 2) It allows me to keep a set of data onhand for immediate restores and a set of data to send offsite for disaster recovery.

Food for thought, Clay

[Paul Murray_1]

Hi All,

Firstly, many thanks (as always) for all your help and input re this thread.

I have put it to the business that they need to spend the money and effort to update their backup tools .... (as hinted by Paula, this will not be an easy task !!!!!).

Thanks again,
Paul.