Mirroring strategies: a complementary approach to backup. (Storage Networking).

Replication strategies such as mirroring do not replace backup, but it does complement it by providing a different level of protection. Data mirroring instantaneously captures changed data (whether created or modified) and mirrors it to a secondary server. The secondary server may be a single server, cluster, RAID array, or other configuration; and it may be local or remote to the primary server or cluster. Mirroring differs from backup operations because it keeps no record of the original block or file: it simply replaces it, just as the primary server has done. It also differs from snapshot technology, which is more closely related to backups. Snapshot technologies do not replace changed data, but create point-in-time copies. Since snapshot applications set and retain pointers from various time periods, an organization can backup from snapshots, recovering from it very quickly without mirroring everything to another site.

Different Angles of Attack

There are three broad threat categories. Mirroring is very useful with local component failure and site failure, though not so much in the logical threats category.

Local component failure: If a primary server goes down, the organization can restore the data. Depending on the application's importance, the organization might mirror to a secondary, backup to tape, RAID, or a cluster, or all of the above.

Logical threats: This includes problems like data corruption, where the hardware is performing perfectly but something logically goes wrong with the data. Since mirroring in this case only mirrors the corrupted data, the best solution is point-in-time recovery like high-end snapshot technologies or tape backups. (The choice would depend on how soon the organization needs to restore the application and data.)

Site failure: In cases such as a natural disaster or terrorist attacks, the data center itself becomes the single point of failure. It's important to protect it with geographic redundancy, whether that means replication technologies like mirroring, or backup or both.

Nick Tabellion, Fujitsu Softek's CTO, said, "I look at mirroring as playing a part in two areas. Disaster recovery is one of them and data availability is another. Mirroring does not take the place of the backup process or a formal recovery process. The easiest way to explain that is, what if your disaster is a disgruntled employee who erased your most critical file? If you have that file mirrored, that means both copies are gone. This is not a disaster recovery situation. You have to have backup, you have to have offset data, you have to have data in a state that's recoverable." The beauty of mirroring is that it allows the organization to maintain two identical sets of dynamic data at the primary and secondary sites. This allows a smooth failover in case of primary server failure, or makes it possible for a company to seamlessly switch operations to the secondary site--say in the event of a looming natural disaster, or for a planned data center migration.

Mirroring can be expensive. For example, using EMC's SDRF technology to mirror between sites requires placing Symmetrix controllers at both ends, and making connections via expensive proprietary equipment. For all its expense, EMC's technology is extremely secure, and many enterprises do make that economic choice for their most critical data. Many other organizations prefer to use less expensive equipment for their secondary site, and use mirroring applications made for open systems. In these scenarios, the secondary server or cluster could be a different brand than the primary. Low-cost ATA disk clusters and in-band storage appliances are common products that significantly lower mirroring price points.

Marty Ward, Veritas' director of storage management products, believes that companies must look at mirroring in terms of application priority and ask "Which applications are most mission critical in their environment? Which applications could impact the business most significantly when they're not available?" Once they've prioritized their applications in terms of availability and data protection, companies can assign varying degrees of mirroring strategies (and expense). Beginning with the most critical applications, organizations can plan for the highest levels of protection for the most critical applications, and can scale down protection schemes for less critical applications.

This saves the high protection levels--synchronous mirroring, high-end clustering, snapshots--for the most critical applications, the ones that must be up within minutes or hours and that cannot lose data. Other applications may need to come up quickly, but could withstand some data loss--this type could be brought up immediately following the most critical applications, and restored from disk-based backup. There are other applications that cannot stand data loss but needn't come up right away, and those that can withstand data loss and be up in a week or so without a serious impact. This does not mean that a non-critical application shouldn't be protected, but it does mean that such an application would do fine with tape backup and off-site vaulting. Mirroring may not be necessary in this instance.

Organizations can use Recovery Time Objective (RTO) and Recovery Point Objective (RPO) as matrix points to prioritize availability and data protection levels. RTO asks, "How long can you take to come up?" RPO asks, "How much data are you willing to lose?" Some organizations take the easy way out with the knee-jerk responses of "We must bring all applications up immediately with no data loss." But no organization can bring up all its applications concurrently within minutes, nor do they need to. And some applications could lose a day's worth of data and not suffer. The key is to identify which is which and place them in a quadrant (see Figure 1).

Bob Miano, president and CEO of Agility Recovery Solutions, said, "What is important for organizations to understand are the different profiles of their various applications. In looking at an organization's portfolio of applications, each application must be evaluated separately, with appropriate RPO/RTO metrics identified. One can not generalize application criteria based upon analysis on one or two of what are perceived to be the 'key' applications."

Even when RPO and RTO point to mirroring strategies, the organization must still decide between synchronous and asynchronous mirroring. Synchronous mirroring means that both copies of the data are updated before confirming the write to the originating application. This keeps the data perfectly synchronized but tends to be expensive and can have some serious latency issues. Asynchronous mirroring caches the second data set, writing it to the secondary server without waiting to confirm with the primary. This saves on network costs and has minimal latency issues, so can be done over greater distances. But it is not as error-free as synchronous mirroring. Organizations must weigh costs and performance issues by an application's importance and needs. For example, delays within a synchronous mirroring setup may not affect a critical batch-oriented application at all, but the same procedure might play havoc with a high-transaction system. (This is not black and white: for example, organizations can distribute intell igence between servers in remotely mirrored sites, which can increase the integrity of asynchronously mirrored data.) A related issue with remote mirroring is how remote should the facilities be? If natural disasters loom, the remote facility should be placed out of the affected region. Veritas, for example, mirrors its clustered sites between California and Minnesota--two states that are unlikely to experience natural disasters at the same time. Other replication processes are safe enough in metro areas or even on campuses where systems can failover to each other.

Organizations can also cut their mirroring costs by using open systems replication applications--this allows them to use non-identical equipment at their primary and secondary sites. In this case, a company would use high-end equipment for the primary server/cluster and less expensive equipment for the secondary--for example, one busy enterprise uses high-end HDS arrays in their Phoenix data center, but backs up to a less-expensive ATA cluster in Dallas.

Figure 1

Priority  RTO             RPO             Example

Level 1   Must come up    Data loss       Active customer
          within hours    not acceptable  order database



Level 2   Must come up    Some data loss  Corporate e-mail
          within hours    acceptable


Level 3   Must come up    Data loss       SEC-mandated financial
          within days     not acceptable  records database



Level 4   Should come up  Some data loss  Historical data
          within days     acceptable      warehouse

Priority  Strategies

Level 1   Disk backup at hotsite
          or online vault, local
          and remote mirroring,
          snapshots

Level 2   Disk backup at hotsite
          or online vault, local
          mirroring

Level 3   Tape backup at
          off-site location,
          remote mirroring,
          snapshots

Level 4   Tape backup at
          off-site location

www.agilityrecovery.com

www.fujitsusoftek.com

www.veritas.com