About the speaker

Eric Siebert is an IT industry veteran, author and blogger with more than 25 years of experience, most recently specializing in server administration and virtualization.
Restore capabilities of VMware backups

Short overview
In this session you will learn:
- Data restore levels
- Bare-metal restores
- File-level restores
- Application-level restores
More sessions Eric Siebert
Transcription
Hi, my name is Eric Siebert, and I'll be your instructor for this part of Backup Academy. In this lesson, we'll be covering restore capabilities of VMware backups.
Before we begin, a little bit about me. I'm a 25 year IT industry veteran. I've been focusing on virtualization for the last five years. I'm the author of two books on virtualization, "Maximum vSphere", and the "VMware VI3 Implementation and Administration." I'm the proprietor of vSphere-land.com and the VMware information website. I'm a regular contributor on many tech target websites, including SearchServerVirtualization.com and SearchVMmware.com. I've presented at VMworld twice, in 2008 and 2010, and I've been recognized as a vExpert by VMware in 2009 and 2010.
Here's our agenda for this lesson. First we're going to cover data restore levels, all the different levels that you can restore data at. This includes bare metal restores where you're restoring a whole VM, file level restores where you're restoring individual files, and application level restores where you're actually restoring individual objects located inside of an application.
Next we'll be covering some of the capabilities of Veeam that kind of relate to all these different restore levels. We'll be covering instant VM recovery, universal application item recovery, and instant file level recovery. So each backup level and restore level has different advantages from doing each one.
At the image level, or the bare metal level, the advantage of that level is where you can actually restore a whole server as a whole unit with the operating system and everything all in one image. So that's the highest level, and that's commonly used for disaster recovery purposes where you have to recover a whole server.
The file level, that's probably the most common level where users delete files and you have to restore individual files for them. So restoring data at that level is probably one of the most common ways of doing data restores.
And finally the app level. This level is different where you're actually having to go inside of the files and restore individual objects. So let's say a person deletes a number of critical records in a database. You don't want to restore the whole database, because that might wipe out some of the other data that's been updated since then. All you need to do is restore just those specific rows that were deleted. This level would give you the advantage where you can actually go through and select just those rows that need to be restored and restore those and not affect the rest of the data in that database.
So it's common to backup data at multiple levels based on different restore requirements. If you have a DR requirement, then the image level backups can help you do bare metal restores. If you do a lot of database restores, it's common to back up at that level where you have a special agent running, where you can actually backup the individual objects located inside the file. Then of course for the file level, the advantage there is just being able to restore any deleted files or files that you need to recover for whatever reason.
So data restored at one level can be used to restore data at a higher level, but not vice versa. So if you backup at the app level, where you actually backup application objects, you can't restore data at the file level, because you don't have everything there to be able to recreate that file. Same if you backup at the file level. You can't really do a bare metal restore, because you're lacking some of the stuff that doesn't exist in that bare metal image. But the other way, if you do a bare metal restore, then you can back up at every level, because you have all the basic recovery. You have all the files contained within that bare metal image, and you have the applications in there as well. So if you have, at the highest level, a bare metal restore, you have a lot more restore options from that backup, where you can restore files, applications objects, and everything in the whole server all from that one backup.
So let's talk a little bit now about how things are traditionally done in physical server environments. So when you're backing up traditional physical servers, restoring data from one level to a higher level can be complicated and also require extra resources. So if you're backing up at the image level and you want to be able to restore individual files, you have to restore that image on an unused physical server. So you actually need to find a physical server to restore individual files. So if you solely backup the image level, restoring individual files can be difficult in a traditional server environment.
If you backup at the file level, you typically need to, if you want to restore application objects, you need to set up another copy of an application so you can access that individual object. So you have that file. Let's say you have a SQL database, and I need to copy records back into an existing SQL database. Typically, you have to set up a SQL application somewhere so you can go in there and copy those records out and paste them in there. Same with active directories, things like that. Actually, it's not as easy to actually go there and take data out of it, because you have to set up another environment to be able to get that data out of it to move it back to wherever you want to restore it to.
So virtualization provides much greater flexibility and makes restoring at any level much simpler and easier. We'll cover all the different ways how virtualization can really benefit doing these different level restores where you can actually go through and easily take data out of one level and put it into another level.
Let's start with traditional file level restores. When you're doing traditional backups, they work inside the OS. They have an agent that is running inside the OS, and that agent can access the file system and can see all the files that exist on that file system. So consequently, it can actually go through and catalog them for reference. Since it's aware of all the files, to restore a file in a traditional environment, you basically just select the files that you need to restore from the backup catalog. Next you just go find the files or the backup media that they're located on. You find that media. Next, you find the backup server connects to the agent on that target server, and once it connects to that target server, it just simply copies those files back to the original source.
So most backup applications in virtual environments, they back up at the virtualization layer using the image level backups. They don't backup at the file level. So that means if you're backing up an image, how do you restore the individual files from it, since you actually can't see the files that are located on that image?
So with virtualization, file level restores are done a bit differently. Because we're doing an image level backup, where we're actually backing up that entire image of the VMDK file, and we're not actually going inside the guest OS. We're not even seeing the file system that's located inside that virtual disk. The way we do restores is a little bit different. What we do to restore individual files in virtualization is we're actually going to mount that virtual disk that is backed up and take a look inside the guest operating system. So, the backup server can actually just mount that virtual disk as like another disk on the backup server, and it can read all the files that are located on that partition.
So no agent is really needed on the target server, so the process is a little bit different. We don't have an agent running there. So how we restore individual files in virtualization is we basically just select the backup for the appropriate server and date. Next, the virtual disk from the backup repository, the backup server is actually going to go out, find the appropriate VM and virtual disk for whatever date we selected. It's going to take that disk and mount it so the file system can be accessed. Now that we have that mounted, the backup server can access any of the files on that disk. So the files that we've selected will then be copied off of that virtual disk and then either back to a local disk or back to the original server, wherever we want the destination to be. Once that's done, the virtual disk is just unmounted, and it's not attached to that backup server anymore.
So, we don't really need to restore the entire VM image to restore a single file. We can simply just mount that image and access the files on there without actually having to restore the whole VM, power it up, and copy files off of it. We can just mount the image and get the files that way. So the process for doing individual file restores with virtualization, it's different than traditional server environments, but the end result is really the same.
So now we're going to cover how traditional bare metal restores work in a physical server environment. As the name implies, a bare metal restore doesn't require an operating system running on the server to restore data to it, because the bare metal restore itself is an image, so it includes the fully functioning operating system on the image that's going to be restored onto the server itself. So we don't require a full operating system running on that server to be able to restore data to it. These types of restores are commonly used in disaster recovery and business continuity solutions, where you might have a cold site, and to bring that cold site up - you just have hardware there - you have to take these full image level backups of servers and do a bare metal restore of them onto those servers.
So typically, these type of backup and restores require a special backup, so you actually have to go in at the image level to back up the server and not at the file level, because you want to capture everything about that server, all the operating system, the state of that server. You pretty much want to capture the server as a whole when you're backing it up. So bare metal restores can be complicated and tricky because you need to do some steps both before and afterwards to prepare them for the restore.
So typically, you need to first install some type of simple operating system on a server before you can actually do a restore to it. Then you can either install an operating system or there are other options, like using boot media, like a boot CD or a floppy or using a PXE boot, where you're actually booting off a network card. So once you have some type of boot device on that server, you next install a backup agent on that server. So the backup agent is needed to be able to receive all that data, that full image that the backup server is going to send to that server. You need that agent to be able to receive it. So once that all happens and you restore the data, you essentially reboot the server, and then it should be functional at that point.
There are many pre and post restore steps to really prepare that server in traditional environments to do a bare metal restore. Things like hardware drivers, dispartitions, and system configurations all need to be correct for the new hardware. In a lot of cases, you're not using the same type of hardware. It might be different. It might be the initial server was an Intel server running an Intel processor. The one you're restoring to might be an ANB server.
It's rare when you have the sever that you're restoring to is an exact physical duplicate of the server that you did the backup with. So if things like you had drivers installed on your source server, your original one, that no longer exist on the server that you actually did the restore to, you have to go through and redo all the drivers, remove the old drivers, install new drivers. In a lot of cases, some of the drivers may not work on the new hardware. You may get blue screens and things like that. Dispartition, if the disk size is not exactly the same, the dispartitions will be out of whack. So essentially, there are a lot of steps that you have to do in a traditional environment to do a bare metal restore.
Now in a virtual environment, the bare metal restores are a lot simpler. VM is basically encapsulated into a single file. So when you do an image level backup of a server, that whole image is a container of the VM, all the operating systems inside there, and it's a whole package. So, to do a restore in a virtual environment, it's a lot simpler, where you basically just select the VM that you need to restore, and then the virtual disk, that VMDK file is copied back to the target host that you select. From that point, you simply just register that VM on the target host and power it on and you're good to go.
There are really no issues caused by hardware compatibility, because VMs all have the same type of virtual hardware regardless of the hardware that's running on the host. So VMs always see emulated hardware that the hypervisor emulates to that virtual machine. So that virtual hardware is going to be the same on any server regardless of what the physical underlying hardware is. The VM will always see exactly the same thing, so you don't have to worry about things like compatibilities with hardwares and drivers and things like that, because the VM really isn’t going to know that it's on a new physical server at all. It's going to see the same exact hardware regardless of where it's at.
So you can also restore VMs to alternate locations. So if you don't actually want to restore that VM to a source, there are a lot of creative thing you can do here. If you want to put it on a workstation and power it up there, you can do that running some type of desktop virtualization product or any other type of tool, like the VMware Player. You can fire up a VM that way, too. Virtualization gives you a lot of flexibility on what you can do with bare metal restores compared to traditional physical server environments. You can easily isolate those restored VMs as well. In a physical environment, typically it's plugged into the network, that physical server. A VM, you can isolate it on a vSwitch that has no network connectivity, so you can power it up without affecting your production environments.
So now for doing traditional physical server environment application level restores. So typically you're restoring data objects from an application back to its original location, whether it's in a database or active directory or any type of application that stores specific objects in a file or container. So when you're doing that, those types of restores, those objects, those records, they're not stored as individual files. They're stored in one large file, typically a database or whatever it is, along with many other objects, records inside of that file. So, only the application is aware of the file structure and how to read and write to it. The operating system basically just sees it as a file. It doesn't know how to go into that file and manipulate the data inside of that file.
From a traditional environment, there are basically two ways to restore data at the application level. You can use a special backup agent running on that server that understand s the application and can back it up and restore individual application objects. So that backup agent will take care of taking the data from the backup server and putting it back in the right place inside that database. A traditional type of backup recovery or restore agent would only be able to do the file level, be able to restore the whole file, not the individual objects in there.
You can also use a native application to copy the objects from the restored file back to the original file. To do that, you would do something like, if you had a SQL manager or something like that, where you could actually go to an environment that you restored the data to and use the SQL manager to select the certain rows that you want out of your backup data. Then insert those rows into the object that you want to restore them to. Those are basically the ways that you can restore individual application object data in a traditional server environment.
Copying objects from the backup back to the original source, it traditionally can be pretty complicated. Virtualization can simplify that a lot and make it a lot easier, because you need to application running to access those objects and then basically select them and write them back to the original source container where those objects need to go to. So with virtualization, it becomes a lot easier, because you restore a backup of the whole VM to an alternate location. So essentially, you're installing that whole environment to another location where it can run. You can boot it up, you can bring up the database, you can select the records all in that alternate location without affecting the original production VM.
So, essentially, then you would isolate that VM in the network, because you don't want it to interfere with the production copy of the VM that's running. Then you'd power on that VM. Then you just copy the data using the native application, whether it be a SQL manager or an active directory browser or whatever to copy the objects that you need out of it and then paste them into the location where they need to be restored to. So you don't need any extra hardware with this, where you do in a physical environment, because a physical environment typically you have to restore everything to something to be able to copy the data off of it. So in virtualization, you don't need that extra hardware, and the original application is unaffected. It would be running fine while you're selecting all the data that you need to restore in a separate environment, and it just becomes a lot simpler doing those types of application level restores in a virtual environment.
Now let's review what we've covered in this lesson. When we identify the different restore capabilities for virtual machine backups, we need to first identify the three types that are available. A bare metal backup, or an image backup, is the fundamental way of doing a full recovery for a physical machine. For a virtual machine, an image level backup is a way to quickly recover the entire workload. A file level backup is good for individual data, such as documents or any unstructured data that's saved on a virtual machine or a physical machine. And then an application item recovery technology really helps to restore specific items within applications.
All these different restore levels are very important when we go about selecting the right backup and recovery solutions for virtual machines.
Related terms (click to view definition)
Agent level backups, Application level backups, Application level restores, Backup, Bare-metal restore, File level backups, Image - based backup , Image level backups, Instant File-Level Recovery (IFLR), U-AIR™(Universal Application-Item Recovery), Virtual machineMore expert videos
Browse all videos
Join your peers!900+ Backup Academy
Certified Professionals Ready? Take exam!
Still not sure? Get a sneak peek to exam!
