i-Series Tape Backup vs. SAVF backup

370 pts.
Tags:
iSeries 820
SAVF
Tape drives
My immediate superior instructed me to compare which is faster, tape backup or Disk-to-Disk backup(SAVF) so I tested this just recently and as per outcome of my test, the tape backup was faster compared to the SAVF backup. Previously, i have the impression that the disk-to-disk backup suppose to be, should be faster. For the setup of the Test, there were 2 libraries that were backup. LIB_A is roughly 33GB(33,453,358,112) and LIB_B is 10GB(10,174,039,039). There were 2 i-series involved, one using tape drive device(LTO2 tape drive) while the other uses the SAVF device. 1. For the tape media device, the command used is:
- "SAVLIB LIB(LIB_A LIB_B) DEV(TAP02) ENDOPT(*LEAVE) OUTPUT(NONE)".
2.For the other i-series,the SAVF command used are as follows :
-"SBMJOB CMD(SAVOBJ OBJ(*ALL) LIB(LIB_A) DEV(*SAVF) SAVF(ABC/LIB_A) CLEAR(*ALL) OUTPUT(*PRINT)) JOB(LIB_A) JOBQ(QSPL)"
-"SBMJOB CMD(SAVOBJ OBJ(*ALL) LIB(LIB_B) DEV(*SAVF) SAVF(ABC/LIB_B) CLEAR(*ALL) OUTPUT(*PRINT)) JOB(LIB_B) JOBQ(QSPL)".
The SAVF way of backup was simultaneously submitted and monitored this to QSPL subsystem. As I mentioned above, the tape backup was faster in copying LIB_A and LIB_B. When I reported this to my immediate superior, he was not convinced and was telling me to do more research on how to improve the SAVF way of doing backup. Is there a way of speeding up the SAVF way of backup? My immediate superior favors the disk-to-disk because he has the impression that this will shorted the backup downtime but as per result of my test, this is not the case. Can i do something on this dilemma? Thanks in advance.

Software/Hardware used:
i-Series Model 820; OS V5R3MO;LTO 2 Tape drive

Answer Wiki

Thanks. We'll let you know when a new response is added.

The speed of your SAVF test will depend greatly on the type of storage you have on your server. I ran a test a few years ago to see if a virtual tape drive solution would perform well against my LTO3 library.

If I recall I got about 80 Mb/s on both devices. I had expected faster times for my virtual tape drive until I looked at my system’s hard drive performance. Once I reviewed my disk performance I realized that I wasn’t going to get better times without some upgrades.

I’d would recommend you and your boss to sit down and clearly define what it is you want to accomplish. If the goal is to implement a disk-disk backup solution you will need to look at your hardware. Do you have ample storage to make this work? Do you have fast drives? Do you have enough IO capacity to make this work? There are many third party products in the market place that may be cheaper alternatives than a huge hardware upgrade on you power system.

Virtual Tape Drive

My testing found that I could setup 2-5 virtual tape drives to run simultaneous backups and that would definitely outperform my tape drive… But the tradeoffs were big for any users expecting to get work done during the backup window.

Dantes,

My first observation is that it appears you are doing the SAVLIB to tape interactively, while you are doing a submit job to the QSPL subsystem. Would not a better test be if you either ran both sets of jobs interactively or by submitting them to the same subsystem ?

Just my 2 cents,
Hope that helps,
Bill Poulin

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Many modern tape drives can record faster than disk will for saves. The 'streaming' technologies are examples of how tape drives have improved in the past couple decades. Where SAVFs can help is with multiple concurrent saves. JOBQ(QSPL) Using the QSPL job queue is possibly a bad choice. Consider using a job queue that routes to a work management configuration that much better suited for save operations. Tom
    125,585 pointsBadges:
    report
  • EvilNCarnate
    IBM offers virtual tape systems, the big thing you would notice about theirs is the sheer horsepower or disk power behind them. Many are using dasd that will rival your own main systems disk storage and as well typically have as much processing power. The speed of saving to disk is going to have to have all parts either matched or the system you are saving to will have to be faster to see any improvement over tape. To save start at AS400( disk read speed --> seek time --> cache --> throughput to controller --> throughput to enclosure --> throughput to dasd or san ---> throughput from san controller to cache --> size of cache and overflow to disk ) whichever piece is slowest thats where your savf will slow down. Explain to your boss, tape costs so much money because the tech that makes it fast doesnt come cheap. You cant just throw in a small san and expect it to move faster than tech that was developed to back up tons of data as quickly and reliably as tape and expect it to easily outperform it.
    145 pointsBadges:
    report
  • ToddN2000
    I know this is an old post but when trying the to save the libraries to a *SAVF why not use the  SAVLIB command instead of the SAVOBJ ?
    WOuld that not perform better ?
    15,605 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following