Export (0) Print
Expand All
4 out of 4 rated this helpful - Rate this topic

Backing Up Virtual Machine Manager

It is important to develop and implement a comprehensive backup plan for protecting all of your Virtual Machine Manager (VMM) data, including data on the VMM server, hosts, virtual machines, and library servers. This section describes the various backup processes and the data recovery process.

Important
Do not use checkpoints for disaster recovery. Checkpoints do not create full duplicates of the hard disk contents nor do they copy data to a separate volume. A checkpoint can serve as temporary backup before updating an operating system on a virtual machine so that you can roll back if the update has any adverse effects. You should use a backup application to back up and recover your data in case of catastrophic data loss. For more information about checkpoints, see the "About Virtual Machine Checkpoints" help topic (http://go.microsoft.com/fwlink/?LinkId=98845).

Creating a Backup Plan

The principal factor to consider when planning data backup is your ability to quickly recover your environment if data is lost or corrupted. Key candidates for protection are files that change frequently or are frequently accessed. You will need to plan backups of:

  • Virtual Machine Manager server
    • SQL database (user accounts, configuration data)
  • Hosts
    • Virtual machines
    • Host configuration data (virtual networks)
  • Library server data
    • Virtual hard disks (VHDs)
    • ISO images

How to Backup Virtual Machine Manager

The following section describes how to back up your Virtual Machine Manager environment.

Backing Up Virtual Machine Manager Servers

The Virtual Machine Manager database can be stored on the VMM server or on a separate server running Microsoft SQL Server 2005. You can back up the SQL Server database through the VMM Administrator Console or from Windows PowerShell. In addition to backing up the database, we recommend that you create a system state backup of the Virtual Machine Manager server so that you can recreate the server with the same security identifier (SID) in case of a catastrophic data loss. The SID is an integral part on how VMM is authorized on the virtual machine hosts.

  1. Back up the SQL database from the administrator console, from the command line, or from the SQL Server-based computer.
  2. Perform a system state backup of the VMM server.

How to Back Up the SQL Database

Use the following procedure to back up Virtual Machine Manager data.

To back up the Virtual Machine Manager database from the Administrator Console:

  1. In Administration view, click Back up Virtual Machine Manager in the Actions pane.
  2. Select a backup destination folder that is not a root directory and that SQL Server can access.

To back up the Virtual Machine Manager database from Windows PowerShell, use the following command:


                get-vmmserver <VMM Server name> | backup-vmmserver -Path <BackupFileDir>
              

For more information, see the "Backing Up the Virtual Machine Manager Database" topic in the Virtual Machine Manager Help (http://go.microsoft.com/fwlink/?LinkId=98986).

Backing Up Hosts and Library Servers

Use System Center Data Protection Manager (DPM) or another backup application that takes advantage of Volume Shadow Copy Service (VSS) to copy host and library server data to a remote file server share.

Important
We recommend that you back up virtual machine configuration files (.vmc) daily.

How to Back Up Hosts and Virtual Machines

Inventory your hosts and then back up all of the hosted virtual machines. To get the list of hosts being managed by VMM, run the following cmdlet from the Windows PowerShell command line:

$vmhost = get-vmmserver <VMM Server name> | get-vmhost

Back up all of the configuration and resource files on each VMM host by using backup software that supports the Virtual Server VSS writer. Backup software that supports Virtual Server minimizes the number of steps required to archive and restore virtual servers, minimizes downtime, and ensures consistency of the data being archived or restored. For more information, see "Backing up and Restoring Virtual Server" (http://go.microsoft.com/fwlink/?LinkID=103098) and "Planning to Back Up and Restore Data" (http://go.microsoft.com/fwlink/?LinkID=103099) in the Virtual Server Operations Guide.

How to Back Up Library Servers

As with VMM hosts, begin by inventorying your library servers. To get the list of libraries managed by VMM, run the following cmdlet from the Windows PowerShell command line:

$libraryservers = get-vmmserver <VMM Server name> | get-libraryserver

Much of the library data is located in the VMM database; for example, templates, hardware profiles, and operating system profiles are not represented on the library server. Back up all files on library shares to a shared folder on a remote file server, including .vhd, .vfd, .iso, .inf, .vmx, .ps1, .vmc, and .vsv files.

Restoring Virtual Machine Manager

The following section describes the procedures for performing data recovery and reassociating servers in your Virtual Machine Manager environment.

How to Restore a Virtual Machine Manager Server

The high-level steps for restoring your VMM environment after a disaster include:

  1. Setting up the hardware
  2. Performing a system state restore
  3. Reinstalling Virtual Machine Manager
  4. Running scvmmrecover.exe

Your strategy for restoring a Virtual Machine Manager server depends on whether you are restoring to the same physical computer or to a different computer.

To restore the SQL database on a Virtual Machine Manager server, run the scvmmrecover.exe utility from the command line.

The scvmmrecover.exe utility uses the following format:


                    SCVMMRecover [-Path <location>] [-Confirm]
        [-Path <location>]      Location where VMM DB backup resides.
        [-Confirm]              VMM database recovery confirmation.

Data Recovery on the Same Computer

  • If you restore a VMM server onto the same physical computer with the same SID as before the data loss, you must perform the following manual steps:
  1. Remove any hosts or virtual machines from the VMM Administrator Console that were removed since the last backup. If a host has been removed since the last backup, then it will appear as "Not Responding" and all virtual machines on the host will appear as "Host Not Responding". If the host is present but a virtual machine has been removed since the last backup, then the virtual machine will appear as "Missing."
  2. Add any hosts or virtual machines that were added since the last backup.

Data Recovery on a Different Computer

If you restore a VMM server onto a different physical computer with a different SID, you must perform the previous manual steps for data recovery on the same computer. Also, you must reassociate each of the hosts to the new Virtual Machine Manager server. Until you perform this step, the hosts will remain mapped to the original computer's machine account. Complete the following steps:

  1. Open the VMM Administrator Console.
  2. Click Administration, and then click Managed Computers to identify all of the managed computers that are marked as "Access Denied."
  3. Right-click each managed computer, click Reassociate, and then provide the administrator credentials.
  4. If you are restoring a VMM server that was also a library server, the new computer will list the original VMM server as the default library server. From the Library view, remove the original library server and add the new computer as a library server.
  5. If necessary, reassociate servers in the perimeter network.
Note
If you have a system state backup of the original VMM server and are using identical hardware, you can perform a system state restore and the SID of the VMM server will remain the same. In this case, using the steps in this section is unnecessary.

If you are restoring a VMM server that was also a library server, the new computer will list the original VMM server as the default library server. From the Library view, remove the original library server and add the new computer as a library server.

How to Reassociate Servers in a Perimeter Network

Hosts in a perimeter network require additional recovery steps. Initially, servers in a perimeter network will appear as "Not Responding." To reassociate servers in a perimeter network, you must perform the following steps:

  1. Log on to each server in the perimeter network, and then locate the VMM account. The VMM account will be a local administrator account with a 10-character username of scvmm plus 5 random characters.
  2. Change the password of the VMM account on each server.
  3. On the VMM server, in Host Properties dialog box, click the Options tab, and then assign each server the same password that you created in step 2.

Restoring Hosts and Library Servers

To restore a host server after data loss, use the VSS Writer for Virtual Server to perform the recovery of the server and of all the virtual machines. To restore a library server after data loss, restore the file server shares and then restore the data back into the shares. For more information, see "Planning to Back Up and Restore Data" in the Virtual Server operations guide (http://go.microsoft.com/fwlink/?LinkID=103099).

After you restore the operating system and system state to either type of server, you must reassociate the computer through the Administrator Console.

  • If the newly restored computer has the same name as the original computer, install the VMM agent locally on that machine and then reassociate that machine to the VMM server.
  • If the newly restored computer has a different name than the original computer, use the VMM Administrator Console to remove the original computer from the list of Hosts managed by VMM, and then add the new computer as a host.

For more information, see the "How to Reassociate a Managed Computer with Another Virtual Machine Manager Server" Help topic (http://go.microsoft.com/fwlink/?LinkId=102863).

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.