LiteSpeed for SQL Server
Nine Steps to Building a Business Oriented Disaster Recovery Plan
Data Protection Beta Programs
Protect petabytes of data across diverse IT environments. Built-in scalability enables you to manage resources for a diverse and growing collection of physical and virtual platforms. Back up data to disk and tape or maximize storage efficiency with optional deduplication capabilities. By combining advanced functionality with exceptional ease of use, you get robust enterprise backup and recovery — not to mention reduced complexity.
Ensure continuous and integrated data protection for your organization’s most relied-upon applications. Dell data protection solutions offer deep application-level support for critical applications such as VMware, Microsoft SQL Server, Exchange, SharePoint, Active Directory and Oracle.
And if the new SIM Community sounds intimidating, don't worry, here's "Everything you need to know to get started!" That's all there is to it! What are you waiting for? Dive on in and we'll see you in the all new SIM Community.
About Ryan McKinney
Ryan McKinney has been a Social Media and Communities Advisor for Dell Software since 2014.
View all posts by Ryan McKinney |
Failing disk drive.
Hard drive crash.
Server not responding.
Are you kidding me?...
Rebuild system from ground up.
Ever notice how language evolves when a server fails? The more you realize how much trouble you’re in and how much work it’s going to take to recover, the more colorful the language you use to describe the situation. You can be sure the fellow in the photo is reflecting in very colorful terms on the time he’s about to spend rebuilding his crashed server.
Sure, it’s good that your data protection strategy includes the staples of backup and restore. You can use them to recover individual files or entire directories that have been accidentally deleted. When your users shoot themselves in the foot, your backup and restore routine helps take the bullets back.
But if you have to swap out a dead hard drive in a server for a new one at 9:00 in the morning, you’ll probably still be restoring files from backup at dinnertime. Meanwhile, the machine, its applications and their data will be unavailable.
That’s a lot of downtime. And a lot of colorful language.
Enter bare metal recovery. BMR means restoring an entire server – OS, partitions, fixes, security patches, drivers, user accounts, applications, data files – straight to bare metal, without having to rebuild the server step by step and file by file. For that you need full, image-level backup as an extension of your data protection routines. If a server crashes, you replace the drive with a bare metal new one, boot it up with a CD or minimal OS, then start restoring the entire image of your system.
What does it take to include BMR in your data protection strategy? Not as much work as you think, especially for the huge upside of being able to rebuild your server correctly the first time.
Join Joe Leslie and me for our July 7 webcast titled What You Don’t Know (and Need to Know) about NetVault Backup for Bare Metal Recovery. You’ll learn how you can run a quick, reliable, painless image restore. In fact, you’ll see how the restore practically runs itself. We’ll show you how NetVault Backup for Bare Metal Recovery automates steps that usually add up to hours and hours of your time:
If you’re new to BMR, join us to learn how easily you can boost your data protection strategy. If you’re an old hand at it, tune in for new ways to apply it.
We promise we won’t use any colorful language during the webcast. And we’ll make sure you don’t have to use any the next time you’re faced with a crashed server.
In this blog post, I’ll approach some issues pertaining to Dell Data Protection | Rapid Recovery virtual standby machines. It is a subject that requires some groundwork to be properly approached. So, without further ado, let’s begin!
Rapid Recovery is a solution that backs up volumes at the block level, meaning the backup results are volume images. These images can be mounted as physical disks for file restore on the Core (backup server) or on any other computer when using the Local Mount Utility application for Rapid Recovery.
Recovering full volumes is more interesting. Data volumes can be restored on spare volumes or raw disks attached to any machine that has the Rapid Recovery agent installed. If the system drive of a crashed protected server needs to be recovered, a bare-metal recovery (BMR) operation is needed. This means the machine needs to first boot from a boot disk, which behaves like an already protected agent, and the system drive is restored the same as a collection of data volumes.
In order to allow the restored machine to boot from the newly created system drive, some changes need to be made at both the driver and partition levels. In most cases, the system drive contains several volumes needed for the boot-up process. For clarification, a modern Windows server system disk hosts at least three dedicated partitions: Unified Extensible Firmware Interface (UEFI), which is kind of a BIOS replacement; System Reserved, which contains essential boot information; and System Volume, aka the C: drive. Taking into consideration that any GUID partition table (GPT) contains a hidden partition (the Microsoft Reserved Partition), you can see that system drives are pretty complex, and restoring such a drive, especially on hardware different from the original one, may be a complex task as well.
Now, what happens if you need to have a server running, but it crashes due to faulty hardware and you don’t have a spare physical server ready for deployment (but you could squeeze in some storage and computing capacity)? That is simple: Export the desired recovery point to a virtual machine (VM). In practice, the process is similar to a BMR or even a data volume restore. The API for the hypervisor creates the VM, Rapid Recovery restores the system volume and any data volumes that may be needed, and then the process is finished by modifying the newly created virtual system drive to allow the VM to boot. Rapid Recovery makes the process simpler by supporting quite a few hypervisors: VMware ESX(i)/vCenter, VMware Workstation, Microsoft Hyper-V and Oracle VirtualBox.
The next logical step is to have a few critical protected servers exported in such a way that, if they fail, a VM (already created as shown above) is prepared to replace them. That is a virtual standby. To accomplish this, a new export is performed after each backup. If the newest backup snapshot was an incremental, meaning that only the data that differs from the previous backup was transferred over the wire, and this new backup is merged with the virtual standby, then the export process will not be resource intensive. If all goes well, the virtual standby is in sync with the newest backup.
It goes without saying that this is a generous, almost seductive concept. If paired with the fact that virtual standby machines can be spun up at the disaster recovery (DR) site (where data is replicated), it means that theoretically, in case of catastrophic failure, it’s possible to recreate the whole local area network at the DR site (or even in the cloud) and have users work remotely with minimal interruptions. Little wonder that virtual standbys are a cornerstone of each DR plan and — I say it based on facts — literally haunt the dreams of many backup administrators.
However, reality being what it is and making it work in our favor requires a lot of planning ahead and sound resource management.
The first statement I feel bound to make before crossing the separation between fact and fiction in the realm of data recovery is that, indeed, virtual standbys are essential to any DR plan. The second (and last) statement is that virtual standby priorities are different from backup priorities. What is critical from a backup standpoint may be irrelevant from a virtual standby standpoint.
To understand, let’s walk through some real-life situations.
The subject is an engineering company that hosts its essential data on an 8TB volume. This volume is hosted on a dedicated high-end storage area network (SAN) attached to a server running Windows Server 2012 R2. Losing that data means that the company would go out of business. There is no doubt that backing up this server and checking its recovery points is a mandatory operation — and that replicating this data either to a DR location or in the cloud should also be mandatory. Archiving the data at regular intervals is a good option, too. This would cost a lot of money, as storage and high-bandwidth WAN pipes do not come cheap, but there’s no way around it. Should this machine be paired with a virtual standby, too? Also consider there are 20–30 more servers of various sizes that need to be backed up, as well.
Let’s take a look at several scenarios:
The examples above have a common denominator. From a backup perspective, critical machines are the ones that contain valuable data. From a virtual standby perspective, the critical machines are those that assure the network infrastructure. Please imagine a more complex example: creating a virtual standby for an Exchange server. It’s evident that such a machine is useless without an operational domain controller and Active Directory DNS. Creating virtual standbys of large machines is counterproductive.
In the end, it’s the job of each organization to prepare the best DR strategy specific to its goals. Rapid Recovery offers a lot of flexibility in choosing the best combination of features that allow balancing both performance and costs. Among these, if used properly, virtual standbys have a place that cannot be underestimated.
For more information about the technical aspects of virtual standbys, read the Rapid Recovery User Guide.