Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Comparing the top data backup packages."

Download it now to read this article plus other related content.

Ten years ago, the Hobart Corporation, a commercial food equipment and service provider in Troy, OH, started to move applications off its mainframes to open systems platforms. We also needed to be able to backup and recover those systems. In 1993, the reliability and well-established procedures of the mainframe operations made it the obvious choice for open systems backup.

    Requires Free Membership to View

    Login

Advantages of Cron scripting
The Unix environment permits more flexibility in scheduling than Windows or the mainframe, so you can use Cron scripts to schedule jobs.

That way, you can check logs to be sure that a scheduled procedure has ended before running. Each script also writes its own log to record the start and end of the process, which helps to fine-tune the process. Errors are also logged, including any process that takes longer than expected. By using loops, the script can stop waiting after specified time, then kick off critical tasks.

A Cron script can also automatically respond to replies that would normally require an operator. With the tape robot, this permits TSM to automatically recycle old off-site tapes that the operator has placed in the I/O station. Onsite or offsite, tapes are recycled when more than half of the data on them is obsolete.

Our overnight backups end by 4 a.m. Using two scripts, by 6 a.m., all of the disk pools have been migrated, off-site copies have been made, the TSM database backed up, a recovery plan created, the RS6000-S7A's operating system backed up and the off-site vault retrieve and inventory lists are queued to the printer. At 9 a.m., the operator:
Removes the operating system backup tape (labeled by day of the week) from the S7A's 8mm drive
Inserts in the next day's operating system backup tape from a storage box on the S7A
Removes any LTO tapes from the library I/O station
Prints a single page with the vault retrieve and inventory lists
Takes all the removed tapes to the vault
Pulls the LTO tapes to be retrieved, as well as the oldest operating system backup tape
Checks the resulting inventory of the vault
Puts the retrieved LTO tapes in the library I/O station
Puts the old operating system tape in the box on the S7A

At 3 p.m., a Cron-activated script checks in the tapes from the library I/O station and loads them back into the library for reuse. Operators don't need to log into Unix. The operators report any discrepancies in the inventory. There is a script to search the logs for errors each morning. Problems are becoming rare.

Like many businesses at that time, IT consolidated numerous departmental LANs into an enterprise network, and took responsibility for its file and print servers. With that responsibility increasing, backup and recovery responsibilities grew.

Fast forward to 2000: The open system backups now occupied 1,660 mainframe tapes and kept eight tape drives spinning full time. The backup tape contained a total of 2TB of data. Just recycling the obsolete onsite tapes required dozens of operator mounts every day. The large tape inventory and high volume of mounts ate up a significant amount of operator time. The constant filing and retrieval also made lost tapes inevitable. We had a growing problem.

On the mainframe, the eight drives occupied two refrigerator-sized IBM tape drive units and an equally large controller unit. The seven-year-old drives weren't aging gracefully: Tape errors were becoming the norm rather than the exception, which interfered with the backup processing.

In addition, our management wanted us to install off-site disaster recovery, which under the present system was impossible. Why? On the mainframe, the group of backup tapes that should have been copied for storage off-site was larger than the number of available scratch tapes. This kept us from making use of the ADSTAR Distributed Storage Manager's (ADSM) Disaster Recovery Manager feature, which inventories tapes off site and in transit.

Searching for a better way
We began investigating the costs of moving backups from the mainframe to a Unix platform with newer tape technologies. Our first proposal recommended that a new robotic tape library be purchased for the existing IBM's RS/6000-S7A server to support all of the open systems servers. In round numbers, this proposal included an additional expenditure of $16,600 for the current year and savings of $28,000 every year thereafter.

Because the RS/6000-S7A was only lightly accessed by a handful of people, it was definitely underutilized. The server almost never used more than two of its eight processors, and its 8GB of memory would be more than adequate to handle additional processing. Most open system backup processing is done at night, so the existing interactive Oracle users wouldn't be affected. And moving the backups to the RS/6000-S7A would free mainframe cycles for crucial batch work.

The eight mainframe drives had a total throughput capacity of 192GB/hour. The proprietary tape library--which was initially proposed--would have just two drives for throughput of 216GB/hour. Management requested a full review of all open system backup hardware, software and procedures to ensure the best long-term solution.

The review starts
When the review started--in addition to the mainframe backups--we also used Veritas' Backup Exec, Computer Associates' ARCserve software and an Exabyte 8mm tape autoloader to back up the operating systems on Netware and Microsoft Windows servers. By contrast, most enterprise backup solutions are designed to protect only user data and assume that the client machines have a working operating system and backup agent installed. While our current configuration was taken into account, all tape technologies and backup software products were to be considered fair game.

It was imperative that the project save money. Any change had to ensure that the technology chosen would continue to be enhanced in the future to accommodate expansion of our open systems environment and would have continued vendor support. Potential vendors' financial stability and their ability to provide local/timely service were also weighed as a factor in both the hardware and software evaluations.

The platform used for the backup server had to be robust enough to handle a 25GB nightly load from 40 clients. The backup software had to support NetWare, AIX, Windows NT and Windows 2000. We also required clients for any operating system that we may support in the near future, such as Linux or AS/400. Also a requirement was support for agents--which greatly reduce the nightly load by only backing up changes--for DB2, Oracle, MS-SQL, and Lotus Domino.

This was first published in March 2003

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top