This article can also be found in the Premium Editorial Download "Storage magazine: Backup overhaul: From a mainframe to an open-systems environment."
Download it now to read this article plus other related content.
|Decision matrix: Virtual tape library vs. SATA tapeless backup|
Phase 2: Policies and recommendations
The assessment indicated new data retention policies were needed. "We realized we had to have separate policies for production and development," says Rideout. The team reviewed a year's worth of restore history to create its new retention and recovery time policies.
For example, they recommended an onsite RTO of two hours to eight hours for individual files, eight hours for a file server OS, 12 hours for a database server and 24 hours for an email server. They set data retention policies of 14 days for a database server (because the data changes so frequently), 30 days for development systems, and 90 days for email and production systems.
To establish a consistent backup and recovery process, the team recommended such things as consistent configuration of all TSM clients, use of an enterprise job scheduler, and dedicated staff resources to manage and maintain the backup and recovery environment.
The team also decided to stay with TSM. "At the beginning, we talked about other backup utilities. TSM had worked well. Our problems weren't due to TSM," says Rideout. "Also, we had a lot of knowledge of TSM in-house." L.L.Bean will use TSM for open-systems backup and recovery; it handles mainframe backup through IBM's hierarchical storage management (HSM) utility.
Two major decisions revolved around disk backup and the choice of SATA or a virtual tape library (VTL). If they opted for disk backup over tape, they'd have to use a low-cost SATA array in conjunction with a tapeless TSM environment or a VTL product.
Previously, L.L.Bean had always done backup to tape using an IBM 3494 ATL connected via ESCON to the mainframe. The ATL used Magstar tape drives and the company had eight ATL frames holding a few thousand tapes, some dedicated to HSM data and others to TSM data. "We were already running out of room," says Rideout. "We had gotten to the point where we would have to eject tapes to make room for new tapes." If they expanded the ATL, however, they would have to add frames and upgrade the connection to FICON.
The tape space crunch simplified the choice. "We could take TSM off the mainframe and gain all the ATL space for HSM. It would extend the life of the ATL," says Rideout. The team recommended moving the TSM open-systems backup to disk. But the question remained: Which disk backup format should they choose: VTL or SATA disk array? The difference came down to VTL, which spills over to tape automatically, or a totally tapeless approach that relies solely on SATA disk (see "Fixing mainframe Tivoli Storage Manager backup problems").
"This was a very tough decision, but we had to be able to grow," says Rideout. To make the choice, the team put together a decision matrix identifying the advantages and disadvantage of VTL and SATA disk. For example, VTL could be used for development if recovery wasn't going to be a high priority. When you run out of capacity with VTL, however, "you need to bring in a new frame," says Rideout. That brought the team back to its desire to avoid adding frames.
SATA arrays required more monitoring and active management to make sure file spaces didn't fill up or to identify hot spots. They're more flexible than a VTL in terms of adding disk and increasing capacity, support recovery at the volume level and provide a faster restore time (see "Decision matrix: Virtual tape library vs. SATA tapeless backup," this page).
This was first published in April 2007