Disk Backup v Tape Backup

[Robert Atkinson]

Having just received my copy of Ping which contains an article about Disk-To-Disk Backups, I would like to revisit a question I thought I knew the answer to.

Which is faster, Disk-to-Disk or Disk-to-Tape?

I'm basing my questions on the following systems :-

HSG80 SAN with 18GB 15k drives (source) + Alpha ES40 booted minimum.

SDLT 160/320 drives using compaction (destination 1)
Internal SCSI 72GB 10k drives (destination 2)

The reason I ask is that I've got to backup the data in our 500GB SAN, replace all the disks and then restore it.

Would it be faster to use tape - I've been told SDLT's are faster than disk!

The optimum option, of course, is to use both concurrently (which I will be doing), but it still leaves doubts as to which is faster.

Rob.

[Wim Van den Wyngaert]

Robert,

My bet is on the tape : it could do 32 MB/sec and on my dual HSG80 I hardly see thruput of 14 MB/sec for disks (but maybe it is written too slowly).

But if the tape is served by the HSG80 this may slow down the reading process.

Wim

[Uwe Zessin]

I assume that a disk-to-disk backup and a disk-to-tape backup reads from different sources - otherwise you have two different streams that compete for I/O.

Using a tape drive on the HSG is not supported.

[Zahid Ghani]

Rob,
My money would Tape-to-disk. Actually a while ago i did carryout a similar excercise but on different h/w,(HSZ and DLT). The backup to tape was faster if you specify a large enough block size. The expalantion (i think) is that writing to disk the system has to maintain indexes etc so extra work is involved whereas writing to tape is really dumping the data.
Uwe,
You can attach tape drives to HSG80 but need SCSI fabric bridge eg NSR/MDR.

[Uwe Zessin]

Zahid,
that is not called 'attaching tape drive to the HSG'. Using an MDR/NSR is making tape drives available in the fabric. A server accesses them without any help from the HSG.

I would even put them into separate zones, because the NSR by default acts as a SCSI initiator on the Fibre Channel side, too, and thus causes connections created on the HSG.

[Amit Levin_2]

Hi Rob, It seems to me that if this is your current disk migration plan you better use tape.
Have you considered cloning of disks by the HSG?

[Martin P.J. Zinser]

Hi Rob,

tapes can be amazingly fast. The SDLT 160 is rated with a raw transfer rate of 57.5 GB per hour (obviously keeping the tape streaming etc). What type of SCSI would we talk for the disks? Several backup streams to independent disks? Any sort of striping? Obviously doing both disk and tape is the ideal solution if you can afford it.

Greetings, Martin

[John Gillings]

Rob,

If your objective is to upgrade disks, why not use, volume expansion and shadowing of dissimilar volumes to do it "live"?

Assuming you're V7.3-2 with latest ECOs, set all your volumes to be shadowed and expandable. Now depending on your level of paranoia, here's the sequence (I'm assuming we're going from "small" to "large" disks, with 2 member shadow sets and we don't want to go below 2 members).

1) Use SET VOLUME/LIMIT to enable volume expansion (requires volume be privately mounted)

2) Add a "large" disk to an existing 2 member set and let it copy. You're now small+small+large

3) When complete, remove one of the small volumes. You now have one large and one small.

4) Add a second "large" disk, let it copy.

5) When complete, remove the other small volume. You're now large+large.

6) Use SET VOLUME/SIZE to expand to the new physical size. Done!

Assuming you have sufficient storage slots, all this can be done online with no interruption of service (except for the initial enabling of expansion with SET VOLUME/LIMIT). So, you really don't CARE if disk is faster than tape, and the task can be done "at leisure" rather than under the pressure of outage windows.

Have as many concurrent streams running as your systems can cope with. Pop disks out and in as they complete. Since you never go below 2 members in your shadow sets, you don't risk data.

If you're not as paranoid, you can do this faster, and with less spare slots by allowing your shadow sets to be reduced to single members.

S+S -> S -> S+L -> L -> L+L

A similar procedure can be used to move entire data centres from site to site, without any down time.

[Robert Atkinson]

Cheers guys.

John - due to various reasons, mainly the amount of change we're implementing, doing this on-line isn't an option.

I'd missed the obvious point about concurrent backups to disk.

What I'll probably do is give the bulk of the time to tape backups, but then kick off the disk backup towards the end, running all disks simultaneously.

I should be able to do the disk backup in 1 hour as opposed to 3.5, this way.

Cheers for your input, Rob.

BTW - if anyone's interested in seeing the full plan, let me know.

[Wim Van den Wyngaert]

Rob,

I think you already now this but :
1) make sure your tapes are initialized with the highest density. Per default, init will re-init the tape with the density used during the last init.
2) /blocksize 65535
3) high quotas

Wim