Initial setup:
- Choose a working directory where you want the code and log files
to reside.
- Copy BACK.COM (the bootstrap routine) and BACKUP_DISKS.COM
(the actual backup code) to this directory.
- Create a subdirectory called [.logs]
- Copy SB.TXT and FAIL.TXT into the [.logs] directory
- edit BACK.COM as follows:
o change disk logicals 'COM_DIR' and 'LIST_DIR' to your
[.working-directory] and [.working-directory.logs]
o Change the tape logicals to match the names of
the tapes you have vaulted at the Feynman Center.
o Change the /PARAMETERS in each SUBMIT statement
to match the drive name, top directory, and the
files to exclude from the the disks you want to
backup. (For only one drive, the second set of
parameters should be empty sets..."","","")
My versions of these files are a good example from which to work.
Thats it, you're ready to go! The code works reliably on both
FNALD0 and the Alphas. If this isn't clear, just look at
BACK.COM and start substituting. This is easier to do than
to explain.
Here's what you do to backup disks of your choice:
On FNALD0:
>set def 'working directory'
>@back
Choose backup tape set [1, 2]:
>1
that's it. I did backups every week, so on the second and fourth
weeks of the month, I typed '2' instead of '1'. Some folks do this
every other week instead of every week, but after my drive failed
I became a little more anal. I would prefer if everyone would do
them each week.
The code submits several batch jobs, one for each backup tape.
I have two sets of tapes vaulted at Feynman so I can rotate my
save sets each week. The jobs wait until later in the day
before they run. Since I had so many disks to backup (the entire
QCD arsenal of drives!) I wrote the code to automatically delay
some of the jobs by a day or more.
The jobs ask the Feynman people to mount the proper tape in the proper
drive. When this happens, the backup process begins. Some of the
jobs will back up two disk drives, one after the other onto the same
tape. Some disks have files that are excluded, either to save space
on the tape (official x_dsts won't change week to week and I have
a copy if the drive dies...), or because the files are typically
locked by a user that went home for the night (paw.metafile) and don't
mean much anyway.
You will find that back.com is easy to change if drive logicals change
or if your tape ID numbers change.
The file that actually gets submitted (backup_disks.com) is very
general and gets all its information as parameters from back.com.
If something goes wrong with the backup, it sends mail to the user
that submitted the job (you) with its best guess as to the problem.
It also sends a success message if it works. (I am not responsible
for the happy bear...but I am responsible for the ripped-in-half bear.)
The code generates two log files. The first one is
PRJ$ROOT281:[QCD_4.QCD_DISKS.PHOTON_BACKUP]'tapename'.log
It has the info about what disks were backed up on that tape, what
time the tape was mounted at the Feynman center, what files
were excluded from the save set. It also has the actual error
messages if any. If you get mail that complains about a problem,
check the log for that tape.
The second file is kept in [.LOGS]. These are the save-set listings
for each drive. (They should probably have been named .bck, but
what the hey...) They show what files actually made it to tape.
They will come in handy if things hit the fan, but they are not too
important from week to week. You will want to check to make sure the
file size for this weeks backup is about the same as last week's; if
it is much smaller, something happened. I only did this if the
code sent me a failure message.
The code performs a purge/keep=3 so that this weeks backup can be
compared to previous ones without the disk filling up too much.
There are also some .coms in the directory in case a job crashed and
you don't want to resubmit all five jobs. BACK_1.com will submit one
or more backup jobs by asking you one by one if you want that tape.
INIT_1 will reinitialize a single tape that gets messed up somehow.
RECOVER.com will bring back selected files. If you want the restore
the entire tape, we'll can whip something up...I haven't had
to do that. These files are either on the alpha or on fnald0,
depending on where I needed them.
--------------------------------------------------------------
Trouble Shooting
The only occasional problem is when files are locked: paw.metafile,
for003.dat, ntuples in progress, etc. These give an error message
in the same place as a parity error would occur. Also, if the
tape gets backups from two disks and the first one hits a locked file,
the code never gets to the second disk (it does finish the first one
at least). In most cases, I put the more heavily used drives second
on a tape. This way, when you get the inevitable 'possible parity error
on tape prq089' or whatever, you can check the .log and make
sure the error was on the second drive. This should be OK. Then,
just to make sure I'm not blowing sunshine up your skirt, go check
[.logs]prq089_qcd_xx.log to see that it is the same size as the last
two weeks. If you feel suspicious, look in the listing to see about
where the locked file was. Is it right at the end? Maybe the job
crashed then. I think you'll find the job continues with the rest
of the disk, though.
Final notes: If your job crashes just right, your tape will have
to be reinitialized (tape has no interal label). You can easily
do this with
init_1.com and
initialize_tape.com.
After that, I made a little com file that you can use to backup one
and only one tape instead of the same set (back_1.com).
These are overly fancy, but they are safer
than trying to write simple code that could overwrite somebody
else's tapes.
Barring little complications, I'm sure you'll find it takes
no work on your part other than a few keystrokes each week or two
to backup all your drives. Let me know if you have any
questions/problems or if you decide to modify the code (for
my own education).
- J