Image backup on DDS3

[Rahul Khare]

Hi All,

We have OpenVMS 6.2 version running on Alpha Server 1000A 5/400. We have four DDS1 tape libraries where the image backup of several hard drives is taken.

The command for backup is:-

BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL)/BLOCK=65534/NOCRC-
/GROUP=0/RECORD/NOASSIST 'drive': 'tapedrive':w'drive'.bak/save-
/MEDIA_FORMAT=COMPACT


These commands are run in loop for several hard disks.

I also have a DDS3 tape library, and hence I would like to combine all four scripts to backup the data on a 24GB drive.

Currently 4X4GB=16GB data is being backed up in four DDS1 drives.

Now the question is, considering the amount of time spent in taking the image backup per hard drive, what would be the best possible way to reduce the time consumption.

Currently,

1 Backup tape finishes in around 4-5 hours (4-5 hard drives image backup)

concurrently, other three also take similar time... which means that the backup finishes in 4-5 hours.

After converting all the scripts to DDS3 it would take around 16 hours, since backup happens sequentially (correct me if I am wrong).


Hence please put in your thoughts on how can I reduce the time consumption to somewhat equal hours, compare to current.

Thanks,
Rahul Khare.

[Steven Schweda]

> After converting all the scripts to DDS3 it
> would take around 16 hours, since backup
> happens sequentially (correct me if I am
> wrong).

Certainly, _if_ the DDS3 drive writes to tape
at the same speed as the DDS1 drives, and
_if_ nothing else is different.

Knowing nothing, I'd expect a tape drive two
generations newer to be at least a _little_
faster. Of course, it depends on what the
limiting link in the chain is now. Reading
four disks at the same time may be slower
than reading one disk at a time, too.

Why not run a medium-sized test on both type
drives? I'd expect reality to be more
accurate that any guesses you get here from
people who don't know how your disk drives
and tape drives are connected, or where your
current bottleneck is.

[Hoff]

Get rid of DDS, and replace it with something faster and more reliable. With DLT or SDLT, for instance -- used DLT gear is available. (No, I'm definitely not a particular fan of DDS/DAT storage. It's cheap for a reason.)

Off-load your disk I/O and your tape I/O onto different SCSI buses. Avoid bus-level contention.

Defragment the input disks.

Reduce application-level I/O contention.

Set up the quotas on your BACKUP account.

http://64.223.189.234/node/49

Replace the Alpha system here with something faster. The AlphaServer 1000A is an ancient and very slow Alpha box. A used AlphaServer DS- or ES-class box will run rings around this box, and these boxes are readily available on the used-equipment market.

Consider acquiring a shelf or three of StorageWorks disks, and run your BACKUP operations disk-to-disk 24 GB is a very small and very old disk by current standards, so disks in this range and larger will be available for little cash.

http://64.223.189.234/node/54

Remember that /IGNORE=INTERLOCK allows for silent application data corruptions within the output saveset.

Look at upgrading to a newer version of OpenVMS. Newer OpenVMS releases tend to have far faster I/O subsystems.

Stephen Hoffman
HoffmanLabs LLC

[Guenther Froehlin]

And as always test how fast BACKUP can read the data off the disk:

$ BACKUP input/your_qualifiers NLA0:a.a/SAVE

If that time is close to what you see with writing the save set to your tape drive then the disk access is most likely the bottleneck.

Try it with the four disk drives you have.

/Guenther

[Guenther Froehlin]

And I forgot...

Make sure the DIOLM of the process doing the backups is less than 50. Make sure that PQL_MDIOLM is also less than 50.

With a large DIOLM and multiple backups going to disk at the same time I would expect a long I/O queue building up basically making the four operations sequential. Depends on how the disks are connected.

Watch MONITOR DISK/ITEM=QUEUE_LENGTH while your backups run.

/Guenther

[Jon Pinkley]

Adding to what Guenther Froehlin said:

I would add /GROUP=0/NOCRC if you want to minimize the processing done by backup.

It will still read the same amount from the drives, but won't create the XOR redundancy groups or calculate the CRC.

$ BACKUP input/your_qualifiers NLA0:a.a/SAVE/GROUP=0/NOCRC