Test Bench
Interoperability
Will the software be able to backup a variety of operating systems, databases, and other applications?
Futureproofing
Will the software be able to scale and extend its capabilities to grow with your business?
ROI
Does the price justify the the productivity you may gain by using the software?
Service
What options are available for service and support, and how much do they cost?
Disaster recovery techniques
Replication
- Synchronous Replication
Pros- Data is current at all sites.
- Should a failure occur, data is available immediately.
- Generally impacts on application performance.
- Data writes can lag by the network latency between the remote sites, this also results in write commit latencies across nodes.
- Asynchronous Replication
Pros- Should have less impact on application performance than synchronous so maximises performance.
- Data is available immediately at the secondary replication site.
- Secondary replication site data may lag primary site.
- Potential for data corruption with some databases.
- Periodic Replication
Pros- Data is available immediately at the secondary replication site.
- Data is old and possibly inconsistent.
- Requires more storage to maintain overall consistency.
- Reconciling data sets may be very difficult.
Remote Mirroring
Remote mirroring--where your primary and secondary sites are connected by SAN fabric--is certainly a good way to go. With volume management software, the physical disks on both sites are transparently (to the application and users) organised into logical volumes, and with some management software, this can be hardware independent. With the right management software, the administration is quite simple.
Both replication and remote mirroring have their pros and cons, mirroring over the SAN is generally restricted to distances of less than 100km but it can occur synchronously while replication can take place at distances greater than 100km using IP, for example, but unless you can live with application performance degradation, it is generally asynchronous.
Clustering
Clustering is a seamless way of improving the chances of business continuation during a disaster. A simple definition of clustering is the use of multiple servers, storage devices, and redundant connections, which appear to the outside world as a single system.
A cluster can exist over a SAN so the primary site can be relatively remote to the other failover sites, if your organisation is large enough and geographically dispersed. Global clustering can be linked by a public carrier WAN and still employ a single point of monitoring and administration.
A typical architecture may be to have the main cluster at the primary site so if a single server fails switching to a failover server, it will not result in any performance hit and the remote site may not be used at all unless a major accident takes out your primary cluster.
Disaster recovery precautions
Don't put all your eggs in one basket!
Where is your failover server or tape repository located? The building next door maybe?
It does not take a genius to see that this is not terribly bright: a fire or some other local disaster could very easily take out the building next door as well. If you want to be really sure about your DR security then you must think of more than simply locating your backups further away than the next building.
If you do happen to locate your DR recovery in a relatively distant remote site, is it on the same power grid or does it use the same telco? A power blackout or the telco going down may knock out your primary site but you still want customers to be able to carry out transactions on your secondary site.
What about other geographic location considerations?
Do your primary and secondary sites sit on the same fault line? Of course in Australia this is not as important say a Californian company, but it is worth considering?
What about flood plains? If both sites are located in relatively low-lying areas, a freak downpour--and let's face it the weather is quite unpredictable of late--could result in both sites being inundated.
And both vendors and governments never tire of telling us about the grimmer possibilities. Locating one site in Sydney and the other in Melbourne might be all well and good, but if both sites are located next to "strategic" sites such airports or in the CBD, it may not be such a great idea.
Tape vaulting
Always locate the vault offsite--a fireproof safe is simply not good enough.
To speed up DR in the event of a problem, it can help to have two copies of each backup, one for the offsite vault and the second retained in a safe place either onsite or preferably a couple of minutes away. This way, should your normal garden-variety failure occur--such as an array going west, not a catastrophic failure such as your office burning down--the second set can be located and installed in a matter of minutes without bothering to source, and pay the fee, for the copy from the vault.
A typical offsite vaulting process may involve the following steps:
- Carry out the backups (ensure two copies of each)
- Catalogue tapes and prepare for pickup by vaulting supplier.
- Tapes are transported to the offsite vault.
- Tapes are stored in the vault and the location of each tape recorded.
- When the tapes expire, based on your backup policies, they are transported back onsite for reuse.
Creating your two copies of data may be a problem for example if you create a single backup tape and then copy the data from one tape to another. The delay getting one copy offsite and into a vault offers a window of opportunity for a disaster to occur that potentially takes out both copies while they are at the primary site.
It would of course be wise to create both tapes at the same time during a backup, however many of the backup agents are not very smart and try and drag two copies of the data and push them over the network creating undue work for the server, storage array, and network. The smarter backup agents will actually grab the data once and create a buffer on the backup server to cater for the potentially different backup speeds of the two tapes.
It would of course be nice if the server could be kept out of the equation so it can devote all its time to serving the users. A true serverless backup is possible. As an example, your storage array can be connected to a smart fabric switch that includes an intelligent backup agent API. In this case, the backup data is streamed straight from the storage array to the fabric switch and then directly to the tape backup.
Tape quality
So you purchased some backup tapes and got a great deal, they are not your usual brand but hey, a tape cartridge is a tape cartridge right?
Wrong!
The industry scuttlebutt goes like this: when the tape media is manufactured it is wound onto large drums, the outside portion of the winding actually stretches, degrading the tape quality. Typically the outside winding is sold relatively cheaply to the bargain- price cartridge manufacturers and the inner windings are sold at a higher price to the "premium" tape manufacturers.
Like most things in life, you get what you pay for. Unless of course this is just a rumour spread by the more expensive cartridge manufacturers to justify their inflated prices.
Subscribe now to Australian Technology & Business magazine.
You should really b looking at the Proware range from Datastor Australia if you want to really lower your total cost of investment.
www.datastor.com.au