Somewhere in the server room near you lurks the sometimes ominous OS/400 system running on iSeries server hardware. Typically, company “lifeblood” accounting applications such as those from JDE (J.D. Edwards) are running on these systems.  Perhaps I am being a little biased here by my chosen profession but the words “lifeblood”, mission critical, and even accounting all put the brain on automatic with the following questions:

• If the system goes down what are the consequences?
• How will workflow be interrupted?
• What percentage of the company will be affected?
• Ultimately, what are the dollars associated with downtime?
• How do we address the above and ensure that the inevitable downtime has a minimal impact on the corporation and its customers?

Of course, as with any application or system we first turn to the corporate backup team.  In a modern implementation it is likely that the backup team is using BRMS (Backup Recovery and Media Services) to backup to physical tape.  Typically, the physical tape infrastructure consists of one or multiple IBM 3584 libraries with one or multiple IBM-Ultrium-TD tape drives (LTO-1, LTO-2, LTO-3, or LTO-4).  These technologies do provide some peace of mind but they are only a piece of the bigger picture.

1. The full picture for disaster recovery includes several items (examples below):
2. How long does the backup take to complete?
3. What type of backups are used and how often are they run?
4. When do tape(s) go off-site in relation to when the backup runs?
5. How fast is the disaster identified?
6. How fast can the tapes be retrieved to the DR location?
7. How long does it take to restore?
8. How long does it take to make the application accessible to the corporation?

Every step above directly or indirectly corresponds to one element in the disaster recovery equation and ultimately feed the two most important factors for validating (or invalidating) your current backup scheme RPO and RTO.

For our purposes we’ll define the recovery point objective (RPO) as the point in time to which data must (or can) be restored to successfully resume processing of business application data.  In other words, after the disaster, what is the age of the data available when business functions and applications are brought into operational state?

For our purposes we’ll define the recovery time objective (RTO) as the time within which business functions or applications must (or can) be restored including the time before a disaster is declared and the time it takes to perform tasks to restore business functions.  In other words, after the disaster, how long will it take to bring business functions and applications to an operational state?

If you’re looking for an RPO of 36 hours it could feasibly be addressed by a simple tape backup of one full backup per day.  Suppose that the backup takes 2 hours to complete and the tapes are taken off-site within 4 hours.  The ideal disaster (oxymoron?) would happen moments after the 2 hour backup and allow you to restore directly to the production system using the tapes (before they go offsite) or the local tape copy.  Worst case, the disaster is identified soon after the occurrence and for some reason your production system is not available for the restore. The disaster recovery process now kicks in and your backup team makes the appropriate phone calls to retrieve tapes to the off-site location. Having practiced the disaster recovery process many times (sarcasm) they bring the system online as it existed from 2 (ideal but dreaming) to 36 (desired) hours ago.  The time it takes from identifying the disaster to the application once again servicing the organization is the “RTA” (recovery time achieved) and hopefully that matches the business needs for RTO or better (RTA <= RTO).

Drumroll…

What if, soon after the backup completed (with a small delay for transfer) your backup data was already off-site at the same site where your DR iSeries hardware waits?

What if the backup replica is already sitting in a library pre-attached to the DR iSeries?

What if,  you could simply recover the iSeries LIC directly from the backup replica?  (“boot from SAN” or in this case “boot from tape” iSeries nomentclature is “IPL” “initial program load”)

To meet these “what if” scenarios you would need a virtual tape library (VTL) system that could emulate one or multiple IBM 3584 libraries with one or multiple IBM-Ultrium-TD tape drives (LTO-1, LTO-2, LTO-3, or LTO-4).  The VTL would need to provide a means to replicate virtual tapes to an off-site VTL.  Additionally, this VTL would need to allow the presentation of a tape set over fibre channel to the awaiting DR iSeries hardware and allow for LIC recovery directly from the replica backup.

Chi Corporation can make this VTL design a reality and allow you to drastically cut backup times, tape-handling logistics, human error, RPO and RTO for your company’s iSeries implementation.

Have more questions about OS/400 and iSeries Backup and Disaster Recovery? Feel free to email me or call me at 440-498-2300 x232.

-Rob Kinney

Related posts:

1. Think “Outside the DeDuplication Box” for Backup