Optimizing Tape Restore

[Jack Trachtman]

There was recently a discussion here (including a reference to the latest System Manager's Guide) on setting process parameters to optimize using BACKUP to copy files from disk to tape. Is there any optimization that can be done for tape to disk restores?

We have:
GS1280
EVA5000
LTO-2/NSR
2Gb HP SAN

In a recent test I saw that the the tape to disk restores ran 3 to 4 times as long as the original disk to tape backup. (From my past experience with locally attached SCSI DLT drives I got to expect restores to take 25-50% longer than saves.)

Our backups run about 6 hours with 2 LTO-2 drives in parallel. A test restore took 15+ hours. As with all of us, I need to plan for disaster recovery and need to reduce the restore time to the bare minimum.

Any suggestions/comments? Thanks all

[Ian Miller.]

Yes restores take longer and timing your restores for your DR test is a good idea.

Try increasing the default extend quantity
SET RMS/EXTEND.

[Uwe Zessin]

Jack,
I can't check it right now, but I _think_ that you can disable the virtual disk cache mirroring on recent VCS releases. It might be necessary to unpresent the vdisk before you can change that attribute.

[Steven Schweda]

Is BACKUP clever enough to avoid the extra
sloth often associated with writing to a
volume which has highwater marking enavled?
If not, SET VOLUME /NOHIGHWATER_MARKING on
the destination disk might help a litle.

No bets.

[comarow]

Assuming you are going to SANs there was a problem with SAN cache trashing.

Typically, DIOLM had to be significantly reduced, in many cases to below 10. However, reducing pql_mdiolm prevented a system from booting do to XWINDOW requirements. Some people booted, than changed the dynamic parameter. This improves things a lot.

If you are at 7.3-2, the new Backup-0500
will make a huge difference. It has a parameter, IO_LOAD which will default to a very workable value of 8. You will no longer have to work with DIOLM. It can be set from 1 to ASTLM.

In addition there are algorithms that will improve backup performance by up to 30%.

The SCSI parameters are no longer valid.

Please also see
http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/00/01/117-con.html

Have fun!

[Uwe Zessin]

> The SCSI parameters are no longer valid.

I don't understand this statement. Which parameters?
Oh, by the way: SCSI protocol is still run in SAN environments.

[John Gillings]

Jack,

As you probably noticed, I hate tapes...

One way to optimize your restore is to get rid of tapes altogether. You can reduce your restore time to ZERO! :-)

Take all your backups onto image copy disks, perhaps using shadowing. Removable drives can be taken offsite for safety, and restoring is as simple as plugging in the drive and booting.

With the cost of tape cartridges going up and disks coming down, the difference in price is getting much less significant. The payoff is in significantly shorter backup and restore times.

[Jack Trachtman]

Ian: "SET RMS/EXTEND"

I'm under the (overly optimistic?) presumption that BACKUP preallocates space for each file before restoring them. True?


Uwe: "disable the virtual disk cache "

I thought that the EVA5000 ECS code noticed when access to a disk changes from random to sequential and automatically compensates. True?


Steven,comarow:

The VMS manual referenced doesn't seem to differentiate between optimizing for saves versus restores. True?


John: "get rid of tapes"

Interesting idea. This would require a complete rethinking of how we do backups as now, to keep things simple (for saves and restores), we do IMAGE backups of all disks. This is about 2.5TB a night. The disk substitution approach is probably cost effective only if differential saves are used to reduce the amount of data saved, but we have two different database systems so we would still wind up copying most files or have to switch to just copying transaction logs. How have you set up your backups?

[Uwe Zessin]

Jack,
I was talking about "cache mirroring", not read-ahead optimizations. When receiving a write request, the controller sends a copy of the data to the other controller which stores it in its own cache.

[comarow]

>> The SCSI parameters are no longer valid.

>I don't understand this statement. Which >parameters?
>Oh, by the way: SCSI protocol is still run >in SAN environments.

I'm sorry I didn't make this clear.

By SCSI parameters I was referring to the UAF parameters that have been recommended for ages. An exampled was setting DIOLM to 4096, while with the SAN disks we need to reduce it.

Luckily, with BACKUP-0500 and /IO_LOAD
will default to 8 and solve these issues.

As I pointed out in the URL, the new recommended backup parameters have been changed considerably.