|only for RuBoard - do not distribute or recompile|
Implementation of a SAN can be a real help to an enterprise. However, the more a SAN gives the enterprise in terms of capacity and flexibility, the greater the problem it imposes on backup.
Backing up data from a SAN is like backing up data in conventional storage. However, the SAN typically has a lot more data. Like conventional backup, SAN backup emphasizes completeness, accuracy, speed, and reliability.
It s nearly impossible to keep up. The volume of data to be backed up is driven by the volume of data stored on disks, and the general rule is that if it can be stored, it will be stored. The best example is the data warehouse, a database essentially dedicated to storing all the company information it can.
Increases in disk capacity occur at every level in the enterprise and you should expect that you ll be called on someday to back it all up.
A 20 GB disk drive is not uncommon on PCs, and there s no reason to believe capacity points in PC disk drives will remain static at a mere 20 GB. A business may have thousands of PCs in desktop and laptop form, and if the enterprise has users working at home, the number rises. So if your IT department offers users connected PC backup, then even the PCs alone could pose a terabyte burden on the backup strategy.
Enterprise servers contain multiple, high-capacity disk drives, and whether or not you implement a SAN, embedded storage in the servers will still exist and the servers will still need to be backed up. Like PC disk drives, capacity will continue to be a selling point for server disk drives, and if there is capacity, users will fill it.
This is evident already in mail servers. Most users seem to collect e-mail faster than they can remove it from their in-boxes. Some users think they should save every e-mail message. And it seems that no matter how often you increase mail server storage capacity, the disks fill up again.
The Storage Area Network is scalable without limit. Whether you have a large number of JBODs or a small number of very large disk arrays attached to your SAN, it remains that you are offering your users tremendous capacity for growth, and the users will take you up on the offer.
At this point, Hewlett-Packard s largest mass storage device, the HP SureStore E XP256, can contain up to 256 disk drives with up to 1024 LUNs. The capacity points for this device have increased several times since the product was announced. They are changing so fast that the user documentation cannot keep up with them. At the time of this writing, you can populate an XP256 with 47GB drives, yielding about 12 TB of storage.
There s no theoretical limit to how many XP256 s you can add to the SAN. Further, there are sure to be larger XP offerings in the future.
There s a big challenge in creating a backup strategy in an environment of rapidly increasing storage. Those who have lived in urban centers know that adding a new lane to a freeway never keeps pace with increased traffic. By the time the new lane opens, there s already too much traffic. And the new lane encourages more people to use that freeway . The same is true with a SAN, so this should be kept in mind when planning for SAN backup and restore.
Everyone despairs of the time required for backup ”users, IT personnel, and management. Therefore, reducing the time required for backup is essential.
The goal is zero downtime backup, a backup that takes place without interrupting processing. This can happen on a SAN with devices and software that permit disk-to-disk copies. Backup takes relatively less time, so more frequent and up-to-date snapshots of company data are possible.
Another concern about backup speed is its effect on the speed of other processing. Backup methods that move data from servers and attached storage to the tape library over the LAN slow down LAN performance for users. Therefore a LAN-less backup is desired. Backups burden servers. It would be ideal to minimize that burden, and this can happen on a SAN, using serverless backup.
The perception that tape runs slow is born out by performance statistics for even the most modern tape libraries. A tape can move through the tape transport only so fast. Again, disk-to-disk copies will minimize a tape library s contribution to slowing down backup.
Another perception of speed is that backup is slow and tedious for human operators. And that s true, too, especially in enterprises where the operators must change out tape. Fortunately, backup hardware like tape libraries can dramatically reduce human intervention time in the backup equation. Also, complex backups can be managed with less effort, using management software.
In addition to increased volume of data to be backed up and decreased time in which to back up, reliability of the backup must stay at current levels ”or increase.
Reliability means two things: 1) all the data requested to be backed up will be backed up, and 2) write operations to backup media must occur with a minimum of errors.
The first concern is addressed by smart backup software. As the SAN grows, new storage must be worked into the backup strategy. Products like HP s OmniBack II go a long way toward easing the management headaches that come with expanding storage capacity.
The second concern is addressed first by reliable media. An error rate of 1 error in 10 12 bits is currently acceptable for DLT tapes, commonly used in backup operations.
However, tape write operations in some SAN configurations are not reliable. In particular, when backup hardware (a tape library) is directly attached to a hub, the FC-AL protocol ( streaming LIPs ) can inherently damage the backup process. Switch technology eliminates this concern, and also provides a full bandwidth connection.
One promise of the Storage Area Network is that various processors (for example HP-UX servers, Windows 2000 servers, Sun Solaris servers) will be able to access storage devices on the SAN.
Of course that doesn t mean they know or understand each other s file systems, and there s no reason to believe any one OS can effectively manage the backups for LUNs used by other OSs. This is one of the challenges facing SAN development.
Unless your site is committed to a one-vendor solution, or you have hired an integrator who promised thorough testing of all SAN elements, you will build and expand your SAN with heterogeneous storage devices. The integrator may use storage devices from different manufacturers, but the implied promise is that they all work together as if they were a one-vendor solution.
The promise of the SAN, too, is that all components , including heterogeneous storage devices, will work together. While a site may use disk storage supplied primarily by one vendor, the backup hardware (tape drives or tape library) and software might come from a different vendor. Hewlett-Packard has made an announcement of its commitment to an open SAN architecture, and we would hope every manufacturer of SAN equipment would agree with and commit to the concept.
|only for RuBoard - do not distribute or recompile|