Information Technology Reference
In-Depth Information
a “fi rst line of defense” in data protection. Here's an example. Let's say a VM was deleted by acci-
dent. With point-in-time restore, you can dial back in time to right before the VM was deleted.
Mount the LUN from that specifi c moment in time, and restore your VM. While not traditionally
thought of as a suitable replacement for other backup solutions, array-based snapshots and even
array replication are starting to make a lot more sense. As data footprints continue to grow and
businesses demand more ag gressive recover y point objectives (RPOs) and recover y time objectives
(RTOs), traditional backup solutions can struggle to meet business needs. Array capabilities have
continued to mature and now off er a number of diff erent business continuity and disaster recovery
options such as off site replication and o oading to lower storage tiers.
Recovering from Disasters
High availability makes up only half of the ability to keep your application/systems up in day-
to-day operation. The other half is disaster recovery, which is the ability to recover from a cata-
strophic failure. The risks posed by hurricanes, earthquakes and other natural (and man-made)
disasters underscore how important it is to establish a thoughtfully designed plan that you can
execute with certainty. Entire datacenters can be destroyed by one of these events, and even the
datacenters that survive and keep functioning do not stay operational for long when generators
run out of gas. When real events like Hurricane Katrina occur, the aftermath drives the point
home that businesses need to be prepared.
Before virtualization, the disaster recovery (DR) team showed up, and the remote recovery
site was slated with the task of recovering the enterprise in a timely manner. A timely manner
back then was at least a few days to build and install the recovery servers and then restore the
enterprise from the backup media.
Sounds simple, right? Well, in theory, it is supposed to be, but problems always occur dur-
ing the process. First, during the recovery process, you can rarely restore your environment
at the remote datacenter location to the same make and model that you run in your current
environment. Thus, after you restore your data from your backup media, you are greeted with
the pretty blue screen that announces that the drivers are different. For the most part, after the
restore completes, you can rerun the installation of the drivers for the recovery servers, but
Murphy tends to show up and lay down his law.
Second, the restore process itself is another form of literal contention. If your backup strategy
does not consider which servers you want to recover i rst, then during a disaster, when you try
to restore and bring up systems based on importance, you waste a lot of time waiting for tape
machines to become available. This contention becomes even worse if your backups span more
than one tape. Speaking of tapes, it is not uncommon for tapes to become corrupt and unread-
able. Backups are completed and the tapes are sent off site but not tested until they are needed.
If all goes well, you might i nish your backup in a few days, but success can be elusive.
Today, a majority of data is kept on the SAN, and the data is replicated to another SAN at
your remote disaster recovery co-location site. So, your data is waiting for you when you need to
perform a recovery, which really speeds up the process. At i rst this remote replication was an
expensive undertaking because only the high-dollar enterprise SANs had this capability. Over
the years, though, this approach has become the standard, and software solutions have started
enabling similar functionality without the need for matching hardware at each endpoint.
