DLT-7000 tape to tape copy ?

[Lothar Krueler]

Hi,
has anyone a good idea how to copy DLT-7000 tapes for storing them in a safe place ?
I tried omnicopy, but in our environment it is to slow and it makes to much net-traffic. Doing the backups twice is not possible, because even one backup takes more time I want. We 've got two DLT-7000 drives (each connected to one L-2000) in a robot-library. The library itself is connected to a D-270. It could hold more than the 2 drives.

I would like successful backups being copied to other tapes for redundant backups. One should be left in the library and the other should be stored in a safe place in an other building.
Does anyone know a good solution? Or does anyone know compact standalone-devices simply for copying DLT-Drives 1:1 (Perhaps this should be better than an omnicopy with database overhead)
Thanks in advance
Lothar

[A. Clay Stephenson]

Hi Lothar:

I use omnimcopy as part of my normal backup. The idea is that at the end of each backup session, I queue the sessions for media copy and then have a script which reads the queue directory and figures out which media it needs to copy. I use a number of dedicated slots in my library to receive the copied media. The operator merely has to swap the copied media out everyday. The script even prints form for offsite storage. I could give you those scripts if you like.

Your real problem is the speed of the omnimcopy operation and the network traffic. Here is how you whip that puppy: Attach each drive in your library to two hosts:

Host A (SCSI ID 7) ---- Drive ----- Host B (SCSI ID 6).

You then configure each physical drive as two OB2 logical drives and give them the same Lock Device Name so that OB2 will not be able to use both of them simultaneously. Use one logical drive for the normal backup so that most of the data is local to that host; use the other logical drive for your media copies so that nothing needs to go over the network.

If I haven't totally confused you, that should fix your speed problem - it fixed mine.

Regards, Clay

[Lothar Krueler]

Hi Clay,
thanks for your response. You didn't confuse me so much as in your answer to my question concerning speedup our backup and autoraid (striped LUNs) - I still have to do this tuneup .
Of course I'm interested in your scripts. I think there's a lot you can teach me. Your idea is clear to me, but I have some questions:

1) Can I make the secondary Connection of the first DLT to the same controller the other drive is connected to or do I have to buy extra controllers?
2) Can I run omnicopy as part of the backup's postexec-script ? I use the OB II GUI and scheduler for creating and scheduling backupsessions.

Regards,
Lothar

[A. Clay Stephenson]

Hi again Lothar:

If I understand your question, you will need a second controller. There can be only 1 DLT7000 or DLT8000 per SCSI bus or no more than 2 DLT4000 drives per SCSI bus.

My suggestion for connection is as follows:

L1000 A (SCSI 7) --- Drive1 -- Robot --- D Box (SCSI 6)

L1000 B (SCSI 7) ---- Drive2 ---- D Box (SCSI 6).

The logical drives that are connected to the L-boxes are for your actual backup at night; the logical drives connected to the D-box are used during the day for media copy so that no extra load is added to your L-boxes during normal hours.

Omnimcopy can certainly be scripted. I'll have to do this as three separate responses so you can get all the pieces.

What follows is the postexec which simply queues the session for media copy. The idea is that at the end of each backup session, you add
/opt/omni/lbin/queue_copy.sh

All this really does is to create a file in /var/opt/omni/CopyQueue with this backup session's ${SESSION}, ${MODE}, and ${DATALIST} written to a small textfile. If you add -f the only Full Backups rather than Incrementals are actually queued for copy. If you add -d day (where day is 0 (Sun) through 6 (Sat), then only the sessions on that day of the week are queued for copy. You can add multiple -d day arguments. -d 1 -d 5 would only queue Mondays and Fridays for media copy. You would make
a call to queue_copy.sh from the postexec of every session for which you wish to make an offsite copy.



You will also notice a section whicj calls copymedia.sh. This is the script which actually
reads every file written by queue_copy.sh. It determines which media the session used and starts the copy. It then writes a small file
to /var/opt/omni/ExportQueue. This directory is used to record the media which has been copied and is not ready for export from the library for offsite storage. The copymedia.sh is actually called as an at job and this code should only be inserted in the postexec of the last scheduled backup to be run for that day.

You will need to create the two directories /var/opt/omni/CopyQueue and /var/opt/omni/ExportQueue.

Here's the postexec:


#!/usr/bin/sh
# Post-exec to queue media copy and to copy the media
# after a delay

PROG=${0}
TDIR=${TMPDIR:-/var/tmp}
PID=${$}
T1=${TDIR}/BP${PID}_1.txt

PATH=${PATH}:/opt/omni/lbin:/opt/omni/bin:/usr/bin:/usr/sbin
PATH=${PATH}:/usr/local/bin:/bin:/etc
export PATH

COPY_DELAY=180
DELAY_UNITS="minutes"

HOST=`hostname`
STAT=0


echo "${HOST}: Queueing session media copy\c"
# only queue full backups (-f) and only on
# Mon (-d 1 ) and Fri (-d 5)
#
/opt/omni/lbin/queue_copy.sh -f -d 1 -d 5
echo "."
delay 2


# Add this section ONLY to the last scheduled backup of the day
# It will actually do the media copy
#
echo "${HOST}: Media copy to start in ${COPY_DELAY} ${DELAY_UNITS}\c"
if [ -z "${TMODE}" ]
then
exec 1>${T1}
exec 2>&1
at -f /opt/omni/lbin/copymedia.sh now + ${COPY_DELAY} ${DELAY_UNITS}
rm -f ${T1}
fi
delay 10
echo "."

exit ${STAT}

--------------------------

queue_copy.sh is attached.


End of Part 1, Clay

[A. Clay Stephenson]

Okay Lothar,here is part two - copymedia.sh

You will need to change the devices used. I use the first 10 slots in my STK-9714 Library as the copy slots. I actually have two librarys but all the copys are done to a destination drive in the STK-9714.
The daily backups are copied to media in those slots. I should mention that each of your backup clients will need a copy on queue_copy.sh in /opt/omni/lbin. It also assumes that remsh and rcp are setup between the cell manager and each client.

This is the code which contains the scripting for omnimcopy and the built-in awk scripts to figure out which media to copy given a SESSION.

[A. Clay Stephenson]

Okay Lothar, Final Piece.

This is offsitemedia.sh; this simply does the commands so that the operator can remove the copied media from the library, insert fresh media for next day's copy; and prints some reports and forms for the offsite storage company. It makes an optional call to a little c program 'flushinput'. This just keeps the operator from pressing the RETURN key too often. This script will certainly have to be modified for your use but it is a very good starting point.

Clay

[A. Clay Stephenson]

Oops, I forgot one piece which should also be installed in /opt/omni/lbin. This is session_media.sh and it actually figures out which media is to be copied. This script is called from within copymedia.sh.


Have Fun, Clay

[Lothar Krueler]

Hi Clay,
XXL-thanks for your work!
One more (silly?) question concerning DLT's connections to the D-Box: Are both DLTs connected to the same D-Box controller or is drive2 connected to one D-Box controller and drive1 together with the robot are connected to an other D-Box controller ?
The scripts are downloaded - think I?ll learn a lot of using awk.
Thanks again,
Lothar

[A. Clay Stephenson · Accepted solution]

Hi Lothar,

A little awk never hurt nobody though I would probably do everything in perl if I needed to rewrite the scripts - but since they ain't broke why fix 'em?

You would actually need at least two SCSI controllers (A4107A) in your D-box; in case you are unsure, one can be put in the Turbo slot if need be. Any other configuration violates the rule of more than one DLT7000 or DLT8000 per bus. A Drive + robot(s) on the same SCSI bus is ok; the bandwidth requirements of the robot device are very, very small. The main thing to be aware of is that you MUST move the SCSI ID jumpers on one of the controllers from 7 (traditional normal for a SCSI controller) to 6 or 5 to avoid duplicate SCSI ID's on the same bus. In this configuration, the controllers also serve as terminators for each bus; so make sure that the terminators are enabled on both controllers. This type of configuration with multiple controllers is very common in a ServiceGuard environment (though in that case in-line SCSI terminators are often used so that a controller can be replaced without bringing down the bus).

Regards, Clay