In this article, by Chuck Mills and Ryan Cartwright, authors of the book VMware Horizon 6 Desktop Virtualization Solutions, we will study about the back up options available in VMware. It also provides guidance on scheduling appropriate backups of a Horizon View environment.
(For more resources related to this topic, see here.)
While a single point of failure should not exist in the VMware View environment, it is still important to ensure regular backups are taken for a quick recovery when failures occur. Also, if a setting becomes corrupted or is changed, a backup could be used to restore to a previous point in time. The backup of the VMware View environment should be performed on a regular basis in line with an organization’s existing backup methodology. A VMware View environment contains both files and databases.
The main backup points of a VMware View environment are as follows:
- VMware View Connection Server—ADAM database
- VMware View Security Server
- VMware View Composer Database
- Remote Desktop Service host servers
- Remote Desktop Service host templates and virtual machines
- Virtual desktop templates and parent VMs
- Virtual desktops
- Linked clones (stateless)
- Full clones (stateful)
- ThinApp repository
- Persona Management
- VMware vCenter
- Restoring the VMware View environment
- Business Continuity and Disaster Recovery
With a backup of all of the preceding components, the VMware View Server infrastructure can be recovered during a time of failure.
To maximize the chances of success in a recovery environment, it is advised to take backups of the View ADAM database, View Composer, and vCenter database at the same time to avoid discrepancies. Backups can be scheduled and automated or can be manually executed; ideally, scheduled backups will be used to ensure that they are performed and completed regularly.
Proper design dictates that there should always be two or more View Connection Servers. As all View Connection Servers in the same replica pool contain the same configuration data, it is only necessary to back up one View Connection Server. This backup is typically configured for the first View Connection Server installed in standard mode in an environment.
VMware View Connection Server – ADAM Database backup
View Connection Server stores the View Connection Server configuration data in the View LDAP repository. View Composer stores the configuration data for linked clone desktops in the View Composer database.
When you use View Administrator to perform backups, the Connection Server backs up the View LDAP configuration data and the View Composer database. Both sets of backup files will be stored in the same location. The LDAP data is exported in LDAP data interchange format (LDIF).
If you have multiple View Connection Server(s) in a replicated group, you only need to export data from one of the instances. All replicated instances contain the same configuration data. It is a not good practice to rely on replicated instances of View Connection Server as your backup mechanism. When the Connection Server synchronizes data across the instances of Connection Server, any data lost on one instance might be lost in all the members of the group. If the View Connection Server uses multiple vCenter Server instances and multiple View Composer services, then the View Connection Server will back up all the View Composer databases associated with the vCenter Server instances.
View Connection Server backups are configured from the VMware View Admin console. The backups dump the configuration files and the database information to a location on the View Connection Server. Then, the data must be backed up through normal mechanisms, like a backup agent and scheduled job. The procedure for a View Connection Server backup is as follows:
- Schedule VMware View backup runs and exports to C:View_Backup.
- Use your third-party backup solution on the View Connection Server and have it back up the System State, Program Files, and C:View_Backup folders that were created in step 1.
From within the View Admin console, there are three primary options that must be configured to back up the View Connection Server settings:
- Automatic backup frequency: This is the frequency at which backups are automatically taken. The recommendation is as follows:
- Recommendation (every day): As most server backups are performed daily, if the automatic View Connection Server backup is taken before the full backup of the Windows server, it will be included in the nightly backup. This is adjusted as necessary.
- Backup time: This displays the time based on the automatic backup frequency. (Every day produces the 12 midnight time.)
- Maximum number of backups: This is the maximum number of backups that can be stored on the View Connection Server; once the maximum number has been reached, backups will be rotated out based on age, with the oldest backup being replaced by the newest backup. The recommendation is as follows:
- Recommendation—30 days: This will ensure that approximately one month of backups are retained on the server. This is adjusted as necessary.
- Folder location: This is the location on the View Connection Server, where the backups will be stored. Ensure that the third-party backup solution is backing up this location.
The following screenshot shows the Backup tab:
Performing a manual backup of the View database
Use the following steps to perform a manual backup of your View database:
- Log in to the View Administrator console.
- Expand the Catalog option under Inventory (on the left-hand side of the console).
- Select the first pool and right-click on it.
- Select Disable Provisioning, as shown in the following screenshot:
- Continue to disable provisioning for each of the pools. This will assure that no new information will be added to the ADAM database.
After you disable provisioning for all the pools, there are two ways to perform the backup:
- The View Administrator console
- Running a command using the command prompt
The View Administrator console
Follow these steps to perform a backup:
- Log in to the View Administrator console.
- Expand View Configuration found under Inventory.
- Select Servers, which displays all the servers found in your environment.
- Select the Connection Servers tab.
- Right-click on one of the Connection Servers and choose Backup Now, as shown in the following screenshot
- After the backup process is complete, enable provisioning to the pools.
Using the command prompt
You can export the ADAM database by executing a built-in export tool in the command prompt. Perform the following steps:
- Connect directly to the View Connection Server with a remote desktop utility such as RDP.
- Open a command prompt and use the cd command to navigate to C:Program FilesVMwareVMware ViewServertoolsbin.
- Execute the vdmexport.exe command and use the –f option to specify a location and filename, as shown in the following screenshot (for this example, C:View_Backup is the location and vdmBackup.ldf is the filename):
Once a backup has been either automatically run or manually executed, there will be two types of files saved in the backup location:
- LDF files: These are the LDIF exports from the VMware View Connection Server ADAM database and store the configuration settings of the VMware View environment
- SVI files: These are the backups of the VMware View Composer database
The backup process of the View Connection Server is fairly straightforward. While the process is easy, it should not be overlooked.
Security Server considerations
Surprisingly, there is no option to back up the VMware View Security Server via the VMware View Admin console. For View Connection Servers, backup is configured by selecting the server, selecting Edit, and then clicking on Backup. Highlighting the View Security Server provides no such functionality.
Instead, the security server should be backed up via normal third-party mechanisms. The installation directory is of primary concern, which is C:Program FilesVMwareVMware ViewServer by default.
The .config file is in the …sslgatewayconf directory, and it includes the following settings:
- pcoipClientIPAddress: This is the public address used by the Security Server
- pcoipClientUDPPort: This is the port used for UDP traffic (the default is 4172)
In addition, the settings file is located in this directory, which includes settings such as the following:
- maxConnections: This is the maximum number of concurrent connections the View Security Server can have at one time (the default is 2000)
- serverID: This is the hostname used by the security server
In addition, custom certificates and logfiles are stored within the installation directory of the VMware View Security Server. Therefore, it is important to back up the data regularly if the logfile data is to be maintained (and is not being ingested into a larger enterprise logfile solution).
The View Composer database
The View Composer database used for linked clones is backed up using the following steps:
- Log in to the View Administrator console.
- Expand the Catalog option under Inventory (left-hand side of the console).
- Select the first pool and right-click on it.
- Select Disable Provisioning.
- Connect directly to the server where the View Composer was installed, using a remote desktop utility such as RDP.
- Stop the View Composer service, as shown in the following screenshot. This will prevent provisioning request that would change the composer database.
- After the service is stopped, use the standard practice for backed up databases in the current environment. Restart the Composer service after the backup completes.
Remote Desktop Service host servers
VMware View 6 uses virtual machines to deliver hosted applications and desktops. In some cases, tuning and optimization, or other customer specific configurations to the environment or applications may be built on the Remote Desktop Service (RDS) host. Use the Windows Server Backup tool or the current backup software deployed in your environment.
RDS Server host templates and virtual machines
The virtual machine templates and virtual machines are an important part of the Horizon View infrastructure and need protection in the event that the system needs to be recovered.
Back up the RDS host templates when changes are made and the testing/validation is completed. The production RDS host machines should be backed up if they contains user data or any other elements that require protection at frequent intervals. Third-party backup solutions are used in this case.
Virtual desktop templates and parent VMs
Horizon View uses virtual machine templates to create the desktops in pools for full virtual machines and uses parent VMs to create the desktops in a linked clone desktop pool. These virtual machine templates and the parent VMs are another important part of the View infrastructure that needs protection. These backups are a crucial part of being able to quickly restore the desktop pools and the RDS hosts in the event of data loss.
While frequent changes occur for standard virtual machines, the virtual machine templates and parent VMs only need backing up after new changes have been made to the template and parent VM images. These backups should be readily available for rapid redeployment when required.
For environments that use full cloning as the provisioning technique for the vDesktops, the gold template should be backed up regularly. The gold template is the master vDesktop that all other vDesktops are cloned from. The VMware KB article, Backing up and restoring virtual machine templates using VMware APIs, covers the steps to both back up and restore a template. In short, most backup solutions will require that the gold template is converted from a template to a regular virtual machine and it can then be backed up. You can find more information at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009395.
Backing up the parent VM can be tricky as it is a virtual machine, often with many different point-in-time snapshots. The most common technique is to collapse the virtual machine snapshot tree at a given point-in-time snapshot, and then back up or copy the newly created virtual machine to a second datastore. By storing the parent VM on a redundant storage solution, it is quite unlikely that the parent VM will be lost. What’s more likely is that a point-in-time snapshot of the parent VM may be created while it’s in a nonfunctional or less-than-ideal state.
Virtual desktops
There are three types of virtual desktops in a Horizon View environment, which are as follows:
- Linked clone desktops
- Stateful desktops
- Stateless desktops
Linked clone desktops
Virtual desktops that are created by View Composer using the linked clone technology present special challenges with backup and restoration. In many cases, a linked clone desktop will also be considered as a stateless desktop. The dynamic nature of a linked clone desktop and the underlying structure of the virtual machine itself means the linked clone desktops are not a good candidate for backup and restoration. However, the same qualities that impede the use of a standard backup solution provide an advantage for rapid reprovisioning of virtual desktops. When the underlying infrastructure for things such as the delivery of applications and user data, along with the parent VMs, are restored, then linked clone desktop pools can be recreated and made available within a short amount of time, and therefore lessening the impact of an outage or data loss.
Stateful desktops
In the stateful desktop pool scenario, all of the virtual desktops retain user data when the user logs back in to the virtual desktop. So, in this case, backing up the virtual machines with third-party tools like any other virtual machine in vSphere is considered the optimal method for protection and recovery.
Stateless desktops
With the stateless desktop architecture, the virtual desktops do not retain the desktop state when the user logs back in to the virtual desktop. The nature of the stateless desktops does not require and nor do they directly contain any data that requires a backup. All the user data in a stateless desktop is stored on a file share. The user data includes any files the user creates, changes, or copies within the virtual infrastructure, along with the user persona data. Therefore, because no user data is stored within the virtual desktop, there will be no need to back up the desktop. File shares should be included in the standard backup strategy and all user data and persona information will be included in the existing daily backups.
The ThinApp repository
The ThinApp repository is similar in nature to the user data on the stateless desktops in that it should reside on a redundant file share that is backed up regularly. If the ThinApp packages are configured to preserve each user’s sandbox, the ThinApp repository should likely be backed up nightly.
Persona Management
With the View Persona Management feature, the user’s remote profile is dynamically downloaded after the user logs in to a virtual desktop. The secure, centralized repository can be configured in which Horizon View will store user profiles. The standard practice is to back up network shares on which View Persona Management stores the profile repository.
View Persona Management will ensure that user profiles are backed up to the remote profile share, eliminating the need for additional tools to back up user data on the desktops. Therefore, backup software to protect the user profile on the View desktop is unnecessary.
VMware vCenter
Most established IT departments are using backup tools from the storage or backup vendor to protect the datastores where the VM’s are stored. This will make the recovery of the base vSphere environment faster and easier. The central piece of vCenter is the vCenter database. If there is a total loss of database you will lose all your configuration information of vSphere, including the configuration specific to View (for examples, users, folders, and many more). Another important item to understand is that even if you rebuild your vCenter using the same folder and resource pool names, your View environment will not reconnect and use the new vCenter. The reason is that each object in vSphere has what is called a Managed object Reference (MoRef) and they are stored in the vSphere database. View uses the MoRef information to talk to vCenter. As View and vSphere rely on each other, making a backup of your View environment without backing up your vSphere environment doesn’t make sense.
Restoring the VMware View environment
If your environment has multiple Connection Servers, the best thing to do would be delete all the servers but one, and then use the following steps to restore the ADAM database:
- Connect directly to the server where the View Connection Server is located using a remote desktop utility such as RDP.
- Stop the View Connection service, as shown in the following screenshot:
- Locate the backup (or exported) ADAM database file that has the .ldf extension.
- The first step of the import is to decrypt the file by opening a command prompt and use the cd command to navigate to C:Program FilesVMwareVMware ViewServertoolsbin.
- Use the following command:
vdmimport –f View_BackupvdmBackup.ldf –d >View_BackupvmdDecrypt.ldf
- You will be prompted to enter the password from the account you used to create the backup file.
- Now use the vdmimport –f [decrypted file name] command (from the preceding example, the filename will be vmdDecrypt.ldf).
- After the ADAM database is updated, you can restart the View Connection Server service.
- Replace the delete Connection Servers by running the Connection Server installation and using the Replica option.
To reinstall the View Composer database, you can connect to the server where Composer is installed. Stop the View Composer service and use your standard procedure for restoring a database. After the restore, start the View Composer service.
While this provides the steps to restore the main components of the Connection server, the steps to perform a complete View Connection Server restore can be found in the VMware KB article, Performing an end-to-end backup and restore for VMware View Manager, at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1008046.
Reconciliation after recovery
One of the main factors to consider when performing a restore in a Horizon View infrastructure is the possibility that the Connection Server environment could be out of sync with the current View state and a reconciliation is required.
After restoring the Connection Server ADAM database, there may be missing desktops that are shown in the Connection Server Admin user interface if the following actions are executed after the backup but before a restore:
- The administrator deleted pools or desktops
- The desktop pool was recomposed, which resulted in the removal of the unassigned desktops
Missing desktops or pools can be manually removed from the Connection Server Admin UI.
Some of the automated desktops may become disassociated with their pools due to the creation of a pool between the time of the backup and the restore time. View administrators may be able to make them usable by cloning the linked clone desktop to a full clone desktop using vCenter Server. They would be created as an individual desktop in the Connection Server and then assign those desktops to a specific user.
Business Continuity and Disaster Recovery
It’s important to ensure that the virtual desktops along with the application delivery infrastructure is included and prioritized as a Business Continuity and Disaster Recovery plan. Also, it’s important to ensure that the recovery procedures are tested and validated on a regular cycle, as well as having the procedures and mechanisms in place that ensure critical data (images, software media, data backup, and so on) is always stored and ready in an alternate location. This will ensure an efficient and timely recovery.
It would be ideal to have a disaster recovery plan and business continuity plan that recovers the essential services to an alternate “standby” data center. This will allow the data to be backed up and available offsite to the alternate facility for an additional measure of protection. The alternate data center could have “hot” standby capacity for the virtual desktops and application delivery infrastructure. This site would then address 50 percent capacity in the event of a disaster and also 50 percent additional capacity in the event of a business continuity event that prevents users from accessing the main facility. The additional capacity will also provide a rollback option if there were failed updates to the main data center.
Operational procedures should ensure the desktop and server images are available to the alternate facility when changes are made to the main VMware View system. Desktop and application pools should also be updated in the alternate data center whenever maintenance procedures are executed and validated in the main data center.
Summary
As expected, it is important to back up the fundamental components of a VMware View solution. While a resilient design should mitigate most types of failure, there are still occasions when a backup may be needed to bring an environment back up to an operational level. This article covered the major components of View and provided some of the basic options for creating backups of those components. The Connection Server and Composer database along with vCenter were explained. There was a good overview of the options used to protect the different types of virtual desktops. The ThinApp repository and Persona Management was also explained. The article also covered the basic recovery options and where to find information on the complete View recovery procedures.
Resources for Article:
Further resources on this subject:
- Introduction to Veeam® Backup & Replication for VMware [article]
- Design, Install, and Configure [article]
- VMware vCenter Operations Manager Essentials – Introduction to vCenter Operations Manager [article]