Striping data onto tapes?

[Mike Fisher_5]

This one has got me flummoxed
I have an ozone-hole sized gap in my education :)

THE SITUATION:
A client backs up to a 4/40 library using all 4 drives at once
He then keeps his tapes safely off site ready to go to a remote DR site if necessary
He says that they would ideally like a second 4/40 for the remote site to do network restores should they ever be needed

The client emailed me with this...
"We would like to stripe data across multiple tapes but this makes restore virtually impossible when using local DLTs on multiple servers"

MY QUESTION:
I know a little about the concept of striping data across multiple disc drives...
- I/O performance is greatly improved by spreading the I/O load across across many channels & drives
- Best performance achieved when each drive has its own controller

However...

I did not know that to save restore time you could stripe the backup across say 4 tapes
[presumably a tape per disc in the array]

Is this normal practise?
Is it possible?
Is it advisable?

[Tim D Fulford · Accepted solution]

Hi Mike

There are a couple of things at play here.

Assuming the customer has the relavent software to allow striping (OmniBack/Data Protector etc...)

The data can only come off the disks at a given rate. If this is an online backup then this may seem quite slow (hence the reason for striping the data across multiple tapes)
o If you use striping across the tapes then make sure the read threads do not contend with each other else the backup/restore rate may well be similar to that of a single tape (as the process will effectively become disk bound contending for the same disk(s))
o Assuming that the process is not disk bound as described above, & that the backups/restores come from seperate disks or groups of disks, then the next bottle neck is the busses. Either between the disks & the server or the server & the tapes. Thus it is a good idea to have seperate paths to each of the tapes etc.

The general problem is that striping over many tapes can generate a throretical bandwidth that is far higher than the disk subsystem or busses can service. Most people (quite rightly) optimise there disk subsystems for the regular day-to-day processing, thus the backup/restore performance may seem limited. Thus you tend to start at a disadvantage as tyhe system is tuned for operation & not backups/restores.

As an example, VA74xx stripe their data across ALL the available disks. We use Ultriums to back-up this data and find that the LUNs will max out at 100% during the backups. We get something like 15-20MB/s and it is the DISKSUBSYSTEM that is the problem. Theoretically we could get 80+ MB/s from the ultrium & ultrium buss, but we will never see it as the disks are being thrashed. Adding a second Ultrium will NOT help & may well make things worse as now we have more threads requesting data and the disks may start to thrash!! Weirdly enough, adding more disks to the VA may help improve the bandwidth to the tapes.

In summary
o Check disk-subsytem & disk usage during single threaded backup. Data layout on disks etc.
o Check buss speeds.
o Figure out the best layout of tapes & tape busses given the above "limitations".

Much luck of the good variety.

Tim

[A. Clay Stephenson]

Tape RAIDS are certainly available (although I don't know that the 4/40 supports it). Its almost always done at the controller level so that to the OS, multiple tape drives appear as one unit. Some implementations simply allow for mirroring so that multiple copies of the data are created simultaneously but other do actual striping and mirroring.

The tricky part comes into play when when use a library. The software has to understand how to load perhaps four tapes to simulate one tape.

A Google search of perhaps "Data Striping" +tapes should produce useful results.

The far more typical (and manageable) method is to use software that dynamically allocates available drives to backup obects as they become available. Suppose that you are backing up 10 systems with 12 filesystems each with 6 tape drives. Each drive might support a concurrency of 5 simultaneous objects (filesystems, in this instance). You could then backup a maximum of 30 filesystems at the same time BUT as one filesystem finishes, another is then allocated to the drive with the least number of running objects. In this case, all drives are in use; and in fact, filesystems from the same hosts might be spread across all drives BUT only one tape drive handles any one filesystem (object) so the data are not truly striped.

[Mike Fisher_5]

Tim & Clay:

Thank you - useful stuff
No doubt I'll be back with more questions later in the week

Mike
Call me anything you like, as long as it's not late for dinner