HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Disk Backup v Tape Backup

 
Robert Atkinson
Respected Contributor

Disk Backup v Tape Backup

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.
11 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: Disk Backup v Tape Backup

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
Wim
Uwe Zessin
Honored Contributor

Re: Disk Backup v Tape Backup

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
Frequent Advisor

Re: Disk Backup v Tape Backup

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
Honored Contributor

Re: Disk Backup v Tape Backup

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
Occasional Advisor

Re: Disk Backup v Tape Backup

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
Honored Contributor

Re: Disk Backup v Tape Backup

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
Honored Contributor

Re: Disk Backup v Tape Backup

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.
A crucible of informative mistakes
Robert Atkinson
Respected Contributor

Re: Disk Backup v Tape Backup

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
Honored Contributor

Re: Disk Backup v Tape Backup

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
Wim
Robert Atkinson
Respected Contributor

Re: Disk Backup v Tape Backup

For those of you interested, we completed the SAN disk upgrade, and thanks to lots of pre-planning, almost everything went perfectly.

The one thing that did amaze me was the disk-to-disk copy speed. We managed to backup the system disk in around 20 minutes to SDLT, but to a 36GB 10k SCSI attached disk, it took 2 hours!

I was expecting it to be slower, but not 6 times slower!

A word of warning to anyone attempting anything similar.....always go for tape if speed is an issue.

Rob.
Uwe Zessin
Honored Contributor

Re: Disk Backup v Tape Backup

Well, a tape just moves forward - a disk's head has to move all over the disk to write data, update meta-data and so on. A tape drive can compress data - a disk drive does not (at least I have never seen it).
.