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: 

Optimizing Tape Restore

 
SOLVED
Go to solution
Jack Trachtman
Super Advisor

Optimizing Tape Restore

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
11 REPLIES
Ian Miller.
Honored Contributor

Re: Optimizing Tape Restore

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.
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

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.
A crucible of informative mistakes
Jack Trachtman
Super Advisor

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

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

Re: Optimizing Tape Restore

>> 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.
Tom O'Toole
Respected Contributor

Re: Optimizing Tape Restore

Do your disks have millions of little files? I haven't experienced the performance problem you speak backing up volumes with a few large database files, but I could see it getting worse with really a lot of files.

Have you done any analysis to find the bottleneck? How big is your destination disk group. What queue lengths etc are you seeing...

I am still having a hard time with how an IO limit of 8 is a good limit for backup. My experience with eva arrays are that total throughput increases with number of outstanding IOs well past 8, but admittedly that is with a different workload than backup
Can you imagine if we used PCs to manage our enterprise systems? ... oops.
Wim Van den Wyngaert
Honored Contributor
Solution

Re: Optimizing Tape Restore

Just did a test and found no overhead for high water marking.

You could mount the disk with /nocache to avoid overhead of putting the data in the cache. Also disable disk quotas. No test data because no test disks.

Wim
Wim