VMware Backup and Recovery

Transcription

1 Data Center Management Customer Value openbench Labs PERFORMANCE Analysis: VMware Backup and Recovery Veeam Backup & Replication v5 vs. Symantec Backup Exec 2010 R2 Commissioned by

2 PERFORMANCE Analysis: VMware Backup and Recovery Veeam Backup & Replication v5 vs. Symantec Backup Exec 2010 R2 Author: Jack Fegreus, Ph.D. Managing Director openbench Labs April 21, 2011 Jack Fegreus is Managing Director of openbench Labs and consults through Ridgetop Research. He also contributes to InfoStor, Virtual Strategy Magazine, and Open Magazine, and serves as CTO of Strategic Communications. Previously he was Editor in Chief of Open Magazine, Data Storage, BackOffice CTO, Client/Server Today, and Digital Review. Jack also served as a consultant to Demax Software and was IT Director at Riley Stoker Corp. Jack holds a Ph.D. in Mathematics and worked on the application of computers to symbolic logic.

3 Table of Contents Table of Contents Test Brief 04 Real Issues With Virtual Machine Data Protection 04 Recovery-Centric Test Plan 05 Infrastructure Capabilities 08 Performance Foundation 08 Isolating I/O Bottlenecks 08 Backup Performance 10 Test 1: Agentless Backup 13 Test 2: Backup File Reduction 15 Test 3: Single Execution of All Options 17 Recovery Performance 21 Test 4: Direct VM Recovery From a Backup File 22 Test 5: Automated Recovery Verification 26 Test 6: Multi-OS File-Level Recovery 29 Test 7: Application-Independent Item-Level Recovery 30 Test 8: Point-in-Time VM Replication 32 Test Summary 34 03

4 Test Configuration Test Brief T he gulf between IT s expectations of the benefits that can be derived from a virtual infrastructure and the reality of the lagging data protection measures put into place highlights the fact that a highly flexible host infrastructure does not solve the knotty issues IT faces trying to protect the applications and data running on VMs. REAL ISSUES WITH VIRTUAL MACHINE DATA PROTECTION In a 2010 Symantec datacenter UNDER TEST: VM DATA-PROTECTION FEATURES Veeam Backup & Replication v5 Software Symantec Net Backup 2010 R2 1) Agent-less Backup Configuration: Test basic backup performance and functionality along with any dependencies on the need to license, manually deploy, or manage agents on either VMs or vsphere hosts. 2) Image File Reduction via Data Compression and Deduplication: Both data compression and data deduplication can be applied to image backups to reduce backup file requirements. 3) Single Execution for Multiple Backup and Recovery Options: Easyto-implement backup and recovery operations with all recovery options, including the whole VM, guest VM files and VM application items, available from a single backup. 4) Direct VM Recovery from a Backup File: Instantly start VM recovery from a backup file without rehydrating data, and complete the process with Storage vmotion, VM cloning, or Veeam s VM Copy wizard, which uses Veeam s FastSCP. 5) Automated Recovery Verification: Perform a test restore for every backup file as a standard backup validation test. 6) File-Level Recovery: VM image-level backups allow any VM to be recovered in full or as a collection of guest OS data files. 7) Application-Item-level Recovery: Quick recovery of individual objects from any virtualized application, such as an Oracle Database, Microsoft Exchange Server, or Microsoft SharePoint. survey, IT sites without a virtual infrastructure project planned or in progress represented just 18% of the 1,780 sites surveyed. On the other hand, roughly half of the sites with a virtual operating environment were planning to expand the use of virtual machines (VMs) by running missioncritical database-driven applications. Nonetheless, Symantec s 2010 Disaster Recovery (DR) Plan survey indicates that IT regularly backs up only 56% of the applications and data running on VMs. What s more, DR plans typically exclude 60% of virtual servers at a site. As for data and applications backed up under the umbrella of a DR plan, those backup files fail to comply with either Recovery Time Objectives (RTOs) or Recovery Point Objectives (RPOs) on 40% of IT s tests to recover critical data and applications. 8) Point-in-Time VM Replication: Replicate and fail over VMs using lowimpact synthetic backups for near continuous data protection (CDP) that Despite what seems to be a rather minimizes RPO for any VM. lax concern for VM data protection, CIOs and Line of Business Executives alike cite the strength of a virtual environment as a business continuity solution. When asked to cite key reasons for adoption of virtual infrastructure, IT decision makers list the ability to rapidly restart, non-disruptive move, and spawn new instances of VMs. With high availability, disaster recovery and data protection core components of any 04

5 Test Configuration business continuity strategy, CIOs view virtual infrastructure as the best way to assuage down-time fears of corporate executives within budget constraints that preclude implementing costly (DR) components, such as fault-tolerant servers, redundant hardware resources, and additional software licenses. The gulf between IT s expectations of the benefits that can be derived from a PRINCIPAL VM DATA PROTECTION CHALLENGES virtual infrastructure and the reality of 1) Faster Data Recovery: In surveys of IT sites by both Symantec and the lagging data protection measures put Veeam, the top data protection challenge was the time necessary for into place highlights the fact that a restoration, which was cited with roughly 10% greater frequency than highly flexible host infrastructure does the time to run a backup process. not solve the knotty issues IT faces 2) IT Budget Resources Required to Test DR VM Restoration: When trying to protect the applications and asked about more frequent testing of restore operations, 60% of the data running on VMs. More sites in the Symantec DR survey listed budgetary constraints on importantly, when surveyed about the resource provisioning as the biggest impediment. problems related to protecting VM data, 3) Employee Disruption Staging DR VM Tests: In a virtual dead heat a plurality of the top issues cited by IT with resource provisioning issues, 59% of datacenters reported the disruption to employees as limiting their ability to test DR restoration of were related to the recovery of data backup files. rather than the backing up of data. In 4) Fine Grained Restoration of VM Data: Entwined with the need for particular the two reasons most often restore processes in the Symantec survey was the need for more cited to explain why IT organizations granular data restoration in the forms of VM data files and application infrequently test DR plans centered on items, such as individual databases. the costs associated with provisioning the resources necessary to stage a recovery test, and the disruption that staging such a test would cause for staff. RECOVERY-CENTRIC TEST PLAN To reflect growing concerns for data recovery within the overall data protection process, openbench Labs set up an eight point test plan with five key tests focused on data recovery issues. We applied this test plan to five VM workflows. These workflows represented: 1) A corporate scenario, with Exchange Server 2010 and a Domain Controller, 2) A 64-bit database-driven business process, with SQL Server 2008 R2, and a Windows level 2008 Domain Controller, 3) A 32-bit database-driven business process, with SQL Server 2005, and a Windows level 2003 Domain Controller, and a Windows 7 workstation, 4) A standalone Linux server, 5) A standalone Windows workstation running Windows 7 Enterprise. We tested the ability to validate backup files, including the ability to verify that a backup file is recoverable. We then extended this line of testing to assess the time and resources required to fully restore a VM from any backup file. In addition, we focused on the ability to quickly perform fine-grained restore processes from a single backup file of a VM. In these tests, we examined the ability to easily recover guest files and applicationlevel items from VMs running multiple versions of Windows- and Linux-based guest operating systems. 05

6 Test Configuration BACKUP SERVER: Dell PowerEdge 1900 Quad core CPU 4GB RAM QLogic QLE2462 4Gbps HBA Quantum DLT-S4 Tape Drive Windows 2008 Server R2 Veeam Backup & Replication v5 Symantec Backup Exec 2010 R2 vcenter Server 4.1 up.time 5 Iometer Benchmark VSPHERE 4.1 HOSTS: Dell PowerEdge 1900 Quad core CPU 8GB RAM QLogic QLE2462 4Gbps HBA VMware ESX 4.1 HP ProLiant DL580 Quad processor CPU 8GB RAM QLogic Gbps HBA VMware ESX 4.1 SAN INFRASTRUCTURER: QLogic SANbox 9002 FC Switch Xiotech Emprise 5000 ISE (2) Balanced 4.2TB DataPacs VM WORKFLOWS: Windows Server 2008 R2 VM Active Directory, DNS, DHCP Windows Server 2008 R2 VM Exchange Server mailboxes (400MB per mailbox) Windows Server 2003 R2 VM Active Directory, DNS, DHCP Windows Server 2003 R2 VM SQL Server 2005 Windows Server 2008 R2 VM SQL Server SUSE Linux Enterprise Server 11 obldisk Benchmark Windows 7 VM MS Office 2010 Iometer Benchmark HOW WE TESTED KEY VM DATA PROTECTION FEATURES 06

7 Test Configuration On front-end backup processes, we concentrated our tests on functions to reduce the time needed to backup a workflow and the volume of storage that a workflow would consume. To minimize storage requirements, we tested the ability to invoke data compression and data deduplication. To minimize backup window time, we tested support for incremental backups and the ability to generate full-featured synthetic backups for use in any restore process. We concluded our tests with an examination of VM replication. In particular, we tested the ability to apply backup optimization techniques to achieve near continuous data protection (near-cdp) for VMs that can meet aggressive RTO and RPO demands. 07

8 Infrastructure Capabilities Infrastructure Capabilities U sing Iometer to benchmark I/O throughput for our backup server, we supported two simultaneous I/O streams: one read and one write that ranged from 450MB to 475MB per second each using large 128KB blocks similar to backup applications. PERFORMANCE FOUNDATION Before starting our evaluation of Veeam Backup & Replication v5 with Backup Exec 2010 R2, we first ran hardware benchmarks on our test configuration to determine all hardware limitations that could affect our data protection testing. We used two servers running the VMware vsphere ESX hypervisor to host our vsphere 4.1 test scenarios. All backup and restore tests using Veeam Backup & Replication v5 and Symantec Backup Exec 2010 R2 were performed from a Dell PowerEdge 1900 Server with a Quad-core, 4GB RAM, and a dual-port 4Gbps QLogic QLE 2462 FC HBA. SIMULATED BACKUP THROUGHPUT Using Iometer, two simultaneous I/O streams, one reading and one writing data, each sustained 450MB to 475MB per second using 128KB data blocks, similar to backup applications. We provisioned logical disks on our backup server, to provide storage for both Veeam Backup & Replication and Backup Exec image files, as well as datastores for our vsphere hosts on a Xiotech Emprise 5000 ISE. To facilitate server and storage monitoring during our backup and restore testing, we installed up.time 5 service level monitoring on our backup server. The up.time 5 software is able to monitor and report on all virtual and physical servers, and any other resources with an SNMP interface. As a result, we would be able to compare process loads on all systems during a backup, which is a growing concern at IT sites. To frame the maximum disk throughput that our infrastructure was capable of delivering in a backup process, we ran Iometer on our Dell PowerEdge 1900 backup server. To simulate a backup process, we streamed large-block (128KB) reads and writes simultaneously to two logical drives from the Emprise We measured total read and write throughput at 950 MB per second. These results pegged our ability to support a straight-through end-to-end backup process without data compression or data deduplication at around 450MB per second. ISOLATING I/O BOTTLENECKS As part of our virtual infrastructure configuration, we set up a test domain that included two VMs. One VM took on the role of the domain controller and ran Windows Server 2008 R2 with Active Directory (AD), DNS, and DHCP. The other VM played the 08

9 Infrastructure Capabilities role of an server running Exchange Server 2010 on Windows Server 2008 R2. VM TRANSACTION LOAD TEST We configured this server with three additional logical disk volumes to support 500 accounts. To balance transactions, we used two 125GB logical volumes to distribute our 500 mailboxes across two mailbox databases. Each database contained 250 mail boxes, each of which held an average of 400MB of message data. The third volume was used to store Exchange log files associated with mailbox database transactions. With 500 active mailboxes, our configuration was typical of a single Exchange server at a small to medium enterprise (SME) site or a distributed Exchange server used to scale up a large enterprise site by distributing the load and improving resiliency. Next, we configured the Jetstress benchmark to place a transaction load on our Exchange Server to keep approximately 100% of our mailboxes busy processing 1 transaction per second. When we measured actual performance with up.time 5, Jetstress transactions were engaging all of our mailboxes at a rate of 1.6 transactions per second. We set up Jetstress to generate an To put that level of performance in perspective, over an transaction load that would keep all mailboxes 8-hour business day, each mailbox would process over, 46,000 busy. With up.time 5, we measured the transactions. The value of being able to support such a Jetstress load as actually averaging 800 and 340 log transactions per second. performance level rests in the ability to easily measure the overhead placed on a VM with direct recovery from a backup file and the transition to a SAN-based datastore via vmotion. 09

10 Backup Performance Backup Performance T he ability of Veeam Backup & Replication to implement data deduplication and compression with both full and incremental backup files opens the door for IT to support extremely aggressive RTO and RPO goals in an SLA for business continuity. BACKUP SOFTWARE ARCHITECTURE DIFFERENCES We installed both Veeam Backup & Replication 5 and Symantec Backup Exec 2010 R2 on the same Dell PowerEdge server. A central issue in comparing the use of Backup Exec 2010 R2 with Veeam Backup & Replication v5 in a vsphere environment is the scope of the two products. Veeam Backup & Replication is designed explicitly for a VMware environment. Symantec Backup Exec, on the other hand, is designed to support an entire site, with both physical and virtual servers. As a result, most Backup Exec 2010 R2 modules apply to both physical and virtual servers, which complicate a comparison of Symantec s Backup Exec 2010 Agent for VMware Virtual Infrastructure with Veeam Backup & replication v5. VM BACKUP PERFORMANCE TESTS: 1) Agentless VM Backup: Test basic backup performance and functionality along with any dependencies on the need to license, manually deploy, or manage agents on either VMs or vsphere hosts. 2) Image File Reduction via Data Compression and Deduplication: Both data compression and data deduplication can be applied to image backups to reduce backup file requirements. 3) Single Execution for Multiple Backup and Recovery Options: Easy-toimplement backup operations for both full and incremental backups with all recovery options, including the whole VM, guest VM files and VM application items, available for any backup. provided by Veeam Backup & Replication v5. Comparing the functionality of Veeam Backup & Replication v5 with Backup Exec 2010 R2 s Agent for VMware Virtual Infrastructure is dependent on the modules that are installed in the base Backup Exec 2010 R2 package. Many cross-architecture modules, including a Shared Storage Option for a SAN and a Deduplication Option, played important roles in our vsphere environment and are required to match the functionality These cross-architecture modules, however, significantly drive up the total cost of a Backup Exec 2010 R2 installation. What s more, the need for all Backup Exec 2010 R2 modules to work in a physical server environment frequently adds overhead to a vsphere environment. For example, Backup Exec 2010 R2 optimizes integration with multiple physical and virtual tape libraries. As a result, Backup Exec 2010 R2 implements an ersatz tape library structure to perform disk-to-disk (D2D) backups. Implementation of an enterprise-class data deduplication solution complicates Backup Exec 2010 R2 s use of a simulated tape library structure for D2D backups. In a generic enterprise-class deduplication scheme, backup files that feature deduplicateed, 10

11 Backup Performance single-instance data are not self-contained. These files contain pointers to a repository of single-instance data representations. In turn, that necessitates the creation of a special library within Backup Exec 2010 R2 to handle the media used in D2D backups with data deduplication. For our tests, creating two distinct D2D devices for backups with and without data deduplication meant that we had to create two distinct devices: a Backup-to-Disk folder and a Deduplication Storage folder. To simplify device management, we assigned a distinct virtual volume to each of these folders. Backup Exec then created media files in both of these directories and wrote backup data into the respective media files. ALONG THE DATA DEDUPLICATION DIVIDE For D2D backups, the dual-device structure of Backup Exec 2010 R2 aligned with a major backup distinction between Veeam Backup & Replication v5 and Backup Exec 2010 R2 with respect to compression and deduplication. While Veeam Backup & Replication v5 allows all data reduction techniques, including data deduplication, data compression, and incremental backup, to be used in a single job, Backup Exec 2010 R2, must apply data deduplication exclusively and only to a full backup. I f a company has standardized on Symantec Backup Exec for physical servers, it can leverage this capability to compound the benefits from using Veeam for VMware virtualized servers. Veeam Backup & Replication v5 implements a simple data deduplication scheme that compares only the data contained within an active job stream and makes each deduplicateed backup file completely self-contained. Since a Veeam backup file contains all of the information needed for rehydration, any backup file can be restored from any server running Veeam Backup & Replication v5. For a VM containing multiple versions of data files and multiple structures such as database tables, Veeam s active stream deduplication often provided data reduction on the order of 40% to 50%. Moreover, with self-contained backup files, Veeam allows IT administrators to combine data deduplication with other data reduction techniques, including data compression. With both techniques in play, we typically experienced total data reduction rates between 15-to-1 and 20-to-1. What s more, if a company has standardized on Symantec Backup Exec for physical servers, it can leverage this capability to compound the benefits of using Veeam for VMware virtualized servers. The self-contained structure of Veeam s backup files provides IT with an option to add tape archiving to Veeam Backup & Replication v5 via the backup of its host server. In this way, Backup Exec can be used to meet any off site requirements for backups of VMs. On the other hand, the PureDisk service, which handles all data deduplication for Backup Exec 2010 R2, takes a holistic time-centric perspective to VM data, which is typical of most enterprise-level data-deduplication schemes designed to deduplicate data 11

12 Backup Performance from all sorts of generic sources. The goal of these deduplication schemes is to discover data segments that are backed up repeatedly over time and replace them with pointers to a single-instance of the data. To achieve this goal each enterprise-class data deduplication scheme develops arcane algorithms to scan and break a data stream it into multiple segments in a way that improves the likelihood of making as many matches as possible in a way that is as efficient as possible. In addition to the algorithms used to identify redundant data, a fundamental construct of any deduplication scheme is how the pointers work. Inline data deduplication schemes, such as PureDisk, use backwards referencing which to replace redundant data in the current backup with a pointer to a previous instance of that data while the backup process is running. Comparing data blocks and substituting matching blocks with pointers adds very significant overhead to the backup process and even changes the characteristics of I/O operations. In the PureDisk scheme, a Backup Exec 2010 R2 media server maintains a catalog of hash-coded data fingerprints that belong to unique segments of data discovered during full backups over time. This makes storage reduction for a current backup job dependent on the rate of cache hits for the job s data segments with respect to fingerprints in the media server s catalog. What s more, the caching of backup segment fingerprints creates an affinity between a VM backup processes and a physical media server. The segment catalog belonging to the media server that last backed up a VM is very likely to provide the highest number of cache hits on the next backup of that VM. As a media server s segment fingerprint catalog grows over time, cache hits increase and the sizes of backup files decrease; however, growing the amount of data in the segment fingerprint catalog also increases the number of potential comparisons that can be made during a backup and the time needed to complete the process. That makes it important for PureDisk to grow segment catalogs in a way that increases cache hits without burdening search time. As a result, Backup Exec 2010 R2 prohibits the use of software compression, which alters the structure of data segments, with deduplication, and data deduplication cannot be used with either incremental or differential backups, which by definition copy only new data segments. On the other hand, the ability of Veeam Backup & Replication to implement data deduplication and compression with both full and incremental backup files opens the door for IT to support extremely aggressive RTO and RPO goals in an SLA for business continuity. 12

13 Test 1: Agentless Backup Test 1: Agentless VM Backup e needed to install and maintain a Backup Exec 2010 R2 W Remote Agent on any Windows-based system virtual or physical for which we intended to restore individual files or item-level data. AGENT SYNCHRONIZATION We began our assessment by examining functionality with respect to dependencies on licensing, deploying, or managing agents on either individual VMs or vsphere hosts. In addition, we also tested basic backup performance as a baseline for all testing. BACKUP EXEC AGENT With Veeam Backup & Replication v5, we were able to perform all backup operations on any VM whether Linuxor Windows-based without first installing an agent. We needed to install and maintain a Backup Exec 2010 R2 Remote Agent on any Windows-based system virtual or physical for which we intended to restore individual files or itemlevel data. Using Backup Exec 2010 R2, remote agent software available only for Windows-based clients was required to restore file-level data from a VM backup. We were also able to restore item-level data from a VM running either Active Directory, Exchange Server, or SQL Server with Granular Recovery Technology enabled. While a wizard on the media server made it possible to update multiple clients with a single push process, we often found it necessary to reboot clients individually after some updates. For IT, the installation of multiple Remote Backup Exec 2010 R2 Agents on backupclients can be easily pushed down from a media server using a wizard. Nonetheless, updating clients is typically necessary after every update of a media server t. Client software must be updated to leverage fixes and functionality changes to the media server. What s more, with no agent software available for a client running a Linux OS, we could not perform file-based restores directly from a backup of our VM running SUSE Linux Enterprise v11. In order to restore user files using Backup Exec 2010 R2, we needed to run a separate Windows-network-based backup of directories exposed using Samba on our Linux-based VM. 13

14 Test 1: Agentless Backup BACKUP SERVER CPU &DISK LOAD VM Parameters Applications: Active Directory, DNS Server, DHCPServer OS: Windows Server 2008 R2 Application: SQL Server 2008 R2 OS: Windows Server 2008 R2 Applications: Jetstress, Exchange Server 2010 OS: Windows Server 2008 R2 VM Server Backup Performance Full backup, No Data Deduplication or Compression Backup Software Active Data Backup File Backup Window (hh:mm:ss) Veeam 11.9GB 11.5GB 0:02:09 Backup Exec 11.9GB 12.1GB 0:05:09 0:07:07 0:07:07 with verify Veeam 20.8GB 19.3GB 0:03:29 Backup Exec 20.8GB 20.3GB 0:04:36 0:07:00 0:07:00 with verify Veeam 228.8GB 229.0GB 0:20:41 Backup Exec 228.8GB 234.7GB 0:49:05 1:06:38 with verify In our initial tests, all backups were performed without data deduplication or data compression. We measured the elapsed process time of the backup window and the size of the resulting backup file. In addition we examined the CPU process load and the disk throughput load imposed on the backup server during the backup window via up.time 5. Not only were results similar across VMs, the pattern established continued with more sophisticated processing options. Veeam consistently leveraged the highest level of available CPU resources to complete backup processes as quickly as possible. As a result, Veeam Backup & Replication v5 wrote data faster and completed jobs faster than Backup Exec 2010 R2. Backing up a primary domain controller VM, Veeam Backup & Replication v5 used up to 85% of a processor on a quad-core server, while Backup Exec 2010 R2 peaked at 75%. Writing the backup files, Veeam reached 215MB per second, while Backup Exec peaked at 185MB per second. Backup Exec also kept the backup window open to verify backup data by reading the backup file (265MB per second) and calculating a checksum. More importantly, Veeam Backup & Replication v5 removes backup verification from the backup window. By focusing only on data protection for VMs, Veeam has been able to introduce new technologies that redefine all traditional IT notions of system recovery. For our VM acting as a primary domain controller with 11.9 GB of active data, the backup process took just over 2 minutes with Veeam Backup & Replication and 5 minutes Backup Exec 2010 R2. To verify the backup data, the full backup window took just over 7 minutes. Similarly, backing up our VM running Exchange Server 2010 took nearly 21 minutes with Veeam Backup & Replication v5 and just over 49 minutes with Backup Exec 2010 R2, which required over an hour and 6 minutes in completing the entire process. 14

15 Test 2: Backup File Reduction Test 2: Backup File Reduction ull backups configured for data reduction took up to F nine times longer to complete with Backup Exec 2010 R2, compared to Veeam Backup & Replication v5. THE DATA DEDUPLICATION DIVIDE With backup files for our VM running Exchange Server consuming approximately 230GB with either Veeam Backup & Replication or Backup Exec 2010 R2, the need to reduce backup-file size is undisputable. In our second set of backup tests, we examined the ability to apply multiple data reduction techniques to backup files. BACKUP FILE REDUCTION While there is a strong consensus that the technologies needed for backup file reduction are data deduplication and compression, there are wide differences in the application of these technologies. In fact, some of the biggest performance differences between Veeam Backup & Replication v5 and Backup Exec 2010 R2 arise from differences in the way that each package approaches data deduplication. While backing up a 20.8GB VM running Windows Server 2008 R2 and SQL Server 2008 R2, we applied both data compression and data deduplication with Veeam Backup & Replication v5. Veeam completed the backup in less than 6 minutes and reduced the backup file to 8.5 GB. Using Backup Express 2010 R2, a backup with software compression took nearly 21 minutes and created an 11.4GB backup file. On the other hand, a backup with data deduplication, took close to 18 minutes and created a backup file with just a 4.2GB footprint. Veeam Backup & Replication v5 does not store or compare data beyond the context of a running job. As a result, a VM backup can utilize both data deduplication and compression. Moreover, since a Veeam backup file is self-contained, the file has no dependencies on physical servers or support files. That means a Veeam backup file can be backed up to tape as a Windows Server file, trasnported to any Windows Server running Veeam Backup & Replication v5 to recover the VM. On the other hand, Backup Exec 2010 R2 uses an inline enterprise-class data deduplication scheme that employs a catalog of hash-codes often dubbed fingerprints of single instance data segments. The catalog is used to simplify the use of backwards-referencing pointers to unique instances of previously encountered data segments. When a data segment in the current backup is discovered to match an existing data segment, the segment in the backup file is replaced by a copy of the pointer in the catalog. This method creates interesting dependencies on time and place. Frequent backups of a VM on a server will populate that server s catalog with the most accurate up-to-date collection of data segment fingerprints to boost the dtat deduplication cache hit rate. When we repeated a backup of a VM on a media server without changing any user data, the data deduplication rate jumped from 76% to 90%. Nonetheless, when we repeated that backup process a third 15

16 Test 2: Backup File Reduction time after defragmenting the VM s logical disk, the deduplication rate fell back to 81%.percent. Inline data deduplication requires significant CPU and memeory resources, especially if data reduction rates of around 90% or higher are to be reached. In terms of leveraging available CPU resources, Veeam Backup & Replication v5, which implements a relatively simple data depuplication scheme, typically utilized all available CPU cycles on our quad-core server to minimize backup widows. VM Server Backup Performance Full backup: Data Deduplication/Compression and Verification VM Parameters Applications: Active Directory, DNS Server, DHCPServer OS: Windows Server 2008 R2 Application: SQL Server 2008 R2 OS: Windows Server 2008 R2 Applications: Active Directory, DNS Server, DHCPServer SQL Server 2008 R2 OS: (2)Windows Server 2008 R2 Applications: Jetstress, Exchange Server 2010 OS: Windows Server 2008 R2 Backup Software Active Data Backup File Veeam 11.9GB 4.5GB 0:03:07 Backup Exec 11.9GB 6.3GB 1.2GB Backup Window (hh:mm:ss) 0:16:30 Compression 0:14:05 Deduplication 0:16:30 0:14:05 Veeam 20.8GB 8.5GB 0:05:40 Backup Exec 20.8GB 12.2GB 4.0GB 0:20:45 Compression 0:17:58 Deduplication 0:20:45 0:17:58 Veeam 32.7GB 10.2GB 0:09:23 Backup Exec 32.7GB 19.2GB 2.6GB 0:38:14 Compression 0:32:06 Deduplication 0:38:14 0:32:06 Veeam 228.8GB 13.5GB 0:19:59 Backup Exec 228.8GB 21.0GB 8.4GB 1:53:57 Compression 3:02:17 Deduplication 1:53:57 3:02:17 In contrast, Backup Exec 2010 R2, which runs a far more sophisticated deduplication service, typically utilized only two processor cores. As a result, backups configured for data reduction took up to nine times longer to complete using Backup Exec 2010 R2, when compared to Veeam Backup & Replication v5. Even with data deduplication combined with data compression, Veeam Backup & Replication v5 often provided around a 5-to-1 advantage in wall clock time for a backup with respect to Backup Exec 2010 R2. What s more, Veeam also created consistently smaller back files compared to using software compression with Backup Exec 2010 R2. These advantages were increased by packaging multiple servers in a single backup, which increased the ability for Veeam to apply data deduplication. In particular, by backing up our SQL Server 2008 R2 and a domain controller VMs as a workflow with Veeam, we cut the backup file foot print by approximately 30% and still retained all recovery options for each server. 16

17 Test 3: Single Execution for All Options ith the ability to apply any backup or restore Woption to an incremental backup, even IT at a small SMB shop can leverage just the local backup capabilities of Veeam Backup and Replication v5 to support a business continuity SLA with RPO and RTO requirements of less than two minutes. Test 3: Single Execution for All Options INCREMENTAL EQUALITY INCREMENTAL BACKUP: VEEAM BACKUP & REPLICATION V5 We set the default backup mode for our PDC VM running Active Directory to run reversed incremental backups continuously. To reduce the size of backup files we applied both data deduplication and compression. As a result, an incremental backup of our VM with 12GB of active data took about 90 seconds and generated a 25MB rollback file. More importantly, we were able to leverage all backup and recovery features: In our third series of tests, we examined the ability of each package to simplify operations for IT administrators. In particular, we focused on the ability to implement all backup options, including full and incremental, from a single GUI command. We also examined the ability to apply all recovery options, including VM guest OS files and data items, to each backup file. While virtualization s reason d être is simplification of resource management, data center managers continue struggling with the complexity of meeting RTO and RPO data protection targets in a virtual environment. We were able to run incremental and full backups interchangeably using Veeam Backup & Replication v5, which by default uses an initial full backup followed by incremental backups. To make the most recent backup the fastest to restore, we used reversed 17

18 Test 3: Single Execution for All Options incremental backups: The incremental backup file is used to create a new synthetic full backup from the previous full backup and a rollback file generated to recreate the previous full backup to maintain that restore point. What s more, we leveraged the short time to run an incremental backup and the small size of the rollback file to schedule continuous incremental backups as a backup completed, a new backup started and thereby maintain an RPO of less than two minutes. INCREMENTAL BACKUP: BACKUP EXEC 2010 R2 In addition to applying all of the options available for a full backup, while running an incremental backup, we were able to run every restore option with each incremental backup file, whether the backup file was a rollup or rollback file. Using a wizard, we were able to pick any recovery point associated with either a full or incremental backup and run all of the restore options. In particular, we were able to utilize our incremental backup file as a restore point with the Veeam Instant Restore feature, which allows a VM to run directly from a backup file and enables IT to comply with an RTO of less than two minutes. Using Backup Exec 2010 R2, we had to create a special policy to run an incremental backup. In With the ability to addition, we were not able to implement data deduplication or Granular Recovery Technology with an apply any backup or incremental backup. As a result, restore wizard allowed us to recover the vsphere vmdk files restore option to an associated with a VM backed up with an incremental backup; however, the wizard did not make any of incremental backup, the local Exchange Server 2010 files on our VM available from an incremental backup. even IT at a small SMB shop can leverage just the local backup capabilities of Veeam Backup and Replication v5 to support a business continuity SLA with RPO and RTO requirements of 18

19 Test 3: Single Execution for All Options less than two minutes. For an IT administrator, the difference between an incremental and a full backup are measured in time and storage volume. On the other hand, Backup Exec 2010 R2, with its reliance on agents, the incompatibilities of differing D2D backups, and the overhead of an inline deduplication scheme that uses a disk segment cache, is not able to provide all restore options to every standard backup of a VM. In particular, IT administrators can perform a file-level restore only on a full backup of a VM that runs Windows and has a Backup Exec agent installed. Moreover, incremental and differential backups for VMs require a special backup policy in order to execute and cannot utilize data deduplication. INLINE BLOCK POINTING GAMBIT In a vsphere environment, there is a bigger question concerning the need for an inline enterprise-class data deduplication scheme. Can data segments repeated over time be discovered and removed from a VM backup file with significantly less overhead? The answer can be found in the vstorage APIs for Data Protection (VADP) and Changed Block Tracking (CBT). When scanning image backup data, an enterprise-class data deduplication scheme targets the discovery of ordered sequences of physical data blocks that have been found in a previous backups. In essence, the software looks for sequences of blocks that have not changed over time. That s why defragmentation of a logical volume absent explicit changes to data will degrade the cache hit rate of a backup that uses backwards referencing pointers. On the other hand, excluding data blocks that have not changed from the last backup of a vsphere VM is a trivial process using CBT in conjunction with an incremental backup. To test our ability to maximize segment caching, we ran two successive full backups of our VM running Exchange Server 2010 using Backup Exec 2010 R2 with the PureDisk deduplication service. On the second run, the deduplication rate was 98%, which was manifested in an 8.4GB backup file. Nonetheless, the backup window required a full 3 hours and 2 minutes. Next we applied an incremental backup with Veeam Backup & Replication v5. With both data deduplication and compression turned on, the incremental backup file generated with vstorage and CBT started at 926.4MB. Modest internal deduplication and a great deal of compression reduced the size of that backup file to 260.6MB. More importantly the entire process took just 1minute and 52 seconds. 19

20 Recovery Performance Recovery Performance A key vpower technology is the ability to launch a VM directly from a backup file: This capability entirely changes the construct of VM recovery for IT operations. VPOWER TO MEET RECOVERY-CENTRIC SLAS For IT, backup has long been a necessary daily activity centered on backing up data, applications, and OS files in a minimal amount of time, which is dubbed the backup window. From the perspective of a Line of Business (LoB) executive, however, the value of IT data-protection operations rests entirely in recovery processes. That s why dataprotection Service Level Agreements (SLAs) between IT and LoB units focus on RPO and RTO targets: Backup is simply a means to provide a recovery point. VM RECOVERY PERFORMANCE TESTS: 4) Direct VM Recovery from a Backup File: Instantly start VM recovery from a backup file without rehydrating data, and complete the process with Storage vmotion, VM cloning, or Veeam s VM Copy wizard, which uses Veeam s FastSCP. 5) Automated Recovery Verification: Perform a test restore for every backup file as a standard backup validation test. 6) Multi-OS VM File-Level Recovery: VM image-level backups allow any VM to be recovered in full or as as a collection of logical guest OS data files. 7) Application-Independent Item-level Recovery: Quick recovery of individual objects from any virtualized application, such as an Oracle Database, Microsoft Exchange Server, or Microsoft Sharepoint. With the introduction of new vpower technology, Veeam Backup & Replication v5 revolutionizes IT s ability to perform fast VM backup operations, test the recoverability of 100% of backups outside of the backup window, and meet strict RPO and RTO requirements. With traditional backup software, backup validation consists of checking that the bits in the backup file match the bits in the original VM. This amounts to rereading all of the data and calculating a checksum. 8) Point-in-Time VM Replication: Replicate and fail over VMs using Traditional checksum validation low-impact synthetic backups for near continuous data protection extends the time needed for a backup (CDP) that minimizes RPO for any VM. and only ensures that the VM and the VM backup are duplicates. This validation method cannot check if the original VM has not been corrupted to the point that it is no longer capable of being rebooted. To verify that a backed system will actually run, Veeam Backup & Replication v5 has introduces a number of key technologies under the banner of vpower. A key vpower technology is the ability to launch a VM directly from a backup file: This capability entirely changes the construct of VM recovery for IT operations. From a process perspective, booting a VM directly from a backup file begins with placing pointers to the files contained within the backup file inside a special directory on the Veeam Backup & Replication v5 server. That directory is exported to the vsphere host via NFS as a network attached datastore with read-only files. 20

21 Recovery Performance With all of the VM virtual disks represented as read-only files via pointers, writing new data is handled through cache files that Veeam adds to the vpower NFS datastore by default. To improve write performance, new data can be redirected to a different datastore. If this option is implemented, Veeam Instant Recovery triggers a snapshot of the VM and redirects the snapshot and CBT files to a VeeamIR directory in the designated datastore. In this case the vsphere snapshot handles the new data and cache files are not created. eeam Backup & Replication v5 V extends the construct of file-level data restore for any guest OS to object-level data for any application on any guest OS. While a VM running from a backup file can sustain a distinctly higher IOPS load with data redirection, there is an operational drawback when consolidating the original and new data on a production datastore. If data redirection has not been utilized, vmotion can be used to consolidate that data on a production datastore while the VM remains running online. On the other hand, if data redirection has been used to put new data in a snapshot on a second datastore, vmotion cannot be utilized. An IT administrator will need to hot-clone the VM, power down the VM, and power on the cloned copy. Another vpower construct is a Virtual Lab, which creates an isolated environment, into which administrators can boot and test backed-up VMs. In addition to providing a wizard to easily configure a virtual lab, Veeam provides test scripts to run on VMs to ensure service roles on domain controllers, database servers, and servers are running properly. In a matter of minutes, test scripts can verify that a VM as backed up with no configuration changes boots properly and its key applications run correctly. What s more these tests are run outside of the backup window while the original VM continues to run in the production environment. Nonetheless, the lion s share of restore operations for IT remain focused on retrieving individual files inadvertently lost or corrupted in day-to-day use. In a virtual infrastructure, this translates into the need to easily restore user files under the VM s guest OS. To this end, Veeam Backup & Replication v5 provides a wizard that works directly with depuplicated and compressed backup files to restore any file associated with any guest OS. What s more, Veeam Backup & Replication v5 extends the construct of file-level data restore for any guest OS to object-level data for any application on any guest OS. 21

22 Test 4: Direct VM Recovery from a Backup File Test 4: Direct VM Recovery from a Backup File eeam takes VM backup verification from Vsimple byte comparisons to validating VM backup files boot, internal VM applications work, and external function correctly. RECONCILING RTO WITH REALITY For LoB executives, RTO represents the maximum amount of time before an organization is negatively impacted by the interruption of a core business process. As a result, an SLA that targets business continuity must be driven by the needs of the business unit. As such, a business continuity SLA needs to satisfy a worst possible time for an interruption to occur. More importantly, the SLA should not degenerate into a reflection of IT capabilities. Traditional VM Restore Performance Full Restoration with Rehydration of Deduplicated/Compressed Data VM Parameters Applications: Jetstress, Exchange Server 2010 OS: Windows Server 2008 R2 Backup Software Restored Data Backup File Veeam 235.4GB 13.0GB 1:28:35 Backup Exec 235.4GB 22.1GB 8.8GB Restore Window (hh:mm:ss) 2:26:00 Compression 2:43:35 Deduplication 2:26:00 2:43:35 For IT administrators, recovering a VM to a working state that corresponds to a previous point in time often requires several hours of work. Symantec s 2010 DR survey pegs the total amount of time spent in recovering a system to average about five hours. We began recovery testing by assessing the time to do a traditional restore or our VM running Exchange Server. In particular, we measured the time period needed to extract and rehydrate VM data files from a backup file and then write the data to a vsphere host and register the VM. This time period did not include any storage provisioning activities before instituting the restore process or any post-process testing of VM functionality. Just the restore process for our VM running Exchange Server 2010 took 2hours, 43 minutes, and 35 seconds, when we used Backup Exec 2010 R2 with its data deduplication option. Even our best traditional restore time ran 1 hour, 28 minutes, and 35 seconds with Veeam Backup & Replication v5. With traditional system restore techniques measured in hours, RTO issues have become serious problems for CIOs as more LoB executives link computer downtime to more than lost sales revenue. Many LoB executives have upped the ante by equating computer outages with potential losses in customer confidence and market share. As a result, senior LoB executives expect IT to meet a recovery time objective (RTO) that is measured in hours and in some cases even minutes. The challenge for many IT decision makers is how to assuage the business continuity fears of corporate executives within budget constraints that exclude costly components, such as fault-tolerant servers, redundant hardware and software, and standby network bandwidth. 22

23 Test 4: Direct VM Recovery from a Backup File Unique to Veeam Backup & Replication v5 is the ability to start and run a VM directly from a backup file without first going through provisioning and full restore processes. In just 22 seconds we were able to boot and publish a VM running Exchange Server into our vsphere production environment. The tradeoff for blazing recovery speed comes with lower sustained IOPS rates. Nonetheless, it is possible to bring a VM running from a backup file back to full performance levels with less than 30 seconds of total server down time. INSTANT RECOVERY START UP We used the Instant Recovery wizard to start our VM running Exchange Server 2010 directly from a backup file. Within 5 seconds, a Veeam server directory was populated with pointers to the contents of the VM backup file and exported to the vsphere server as a vpower NFS datastore. By default, Veeam added cache files to handle new data written to each of the VM s logical disks. When we chose to redirect new data updates for Instant Recovery, Veeam triggered a VM snapshot and redirected the snapshot and CBT files to a directory dubbed VeeamIR on the datastore of our choice. With the snapshot now handling data updates, there was no need for special cache files. 23

24 Test 4: Direct VM Recovery from a Backup File We ran a number of tests with the Veeam Instant Restore feature. In these tests we concentrated on RTO and performance requirements for SLAs. In particular, we ran Jetstress with all data directed to the vpower NFS datastore and with updates redirected to another datastore using a redirected snapshot. In addition we tested IOPS rates while consolidating data for both cases. In our initial test, we did not redirect data updates from the vpower NFS datastore. As a result, writes were captured in local cache files and we were able to leverage vmotion. INSTANT RECOVERY WITH VMOTION Using Veeam Instant Recovery, our VM running Exchange Server was published in vsphere within 22 seconds from an incremental backup file. Within another 67 seconds we were able to log into the VM and launch Jetstress. At the same time, we started a vmotion migration of the VM from the vpower NFS database to a SAN-based datastore. The vmotion process took 2 hours and 50 minutes. The incremental Veeam backup and the Veeam Instant Recovery process took a total of just 2 minutes. That put the total time to backup and fully recover our VM at 2 hours and 52 minutes with VM downtime less than 30 seconds. 24

25 Test 4: Direct VM Recovery from a Backup File INSTANT RECOVERY IOPS PERFORMANCE By redirecting update data for the logical disks to another datastore, we were able to double the level of Jetstress transactions that we could sustain. What s more, this relative difference was carried over to the consolidation processes for these Instant Recovery scenarios. During the hot-clone process with the backup VM running with data redirection, we sustained an IOPS load very similar to the IOPS load that we had sustained by the default Instant Recovery configuration, which did not use data redirection. With the Exchange Server running from a backup file with data redirection, we sustained significantly more transactions running the Jetstress benchmark. With data updates redirected via a snapshot, we averaged 290 and 105 log transactions per second. Without redirection, we averaged 140 and 38 log transactions per second. In particular, we sustained approximately 150 and 50 log transactions per second while consolidating data by hot-cloning the backup VM with data redirection. In comparison, without data redirection we were able to sustain roughly 60 transactions and 25 log transactions per second while implementing vmotion to consolidate data for our backup VM. That IOPS level represents a fairly typical transaction processing load for many mission critical applications. In particular, it equates to 3,456 transactions reads, writes, and deletes per user mailbox over an 8-hour work period, Consolidation with hot cloning took roughly 12% more wall clock time. While the vmotion process completed in 2 hours and 50 minutes, hot cloning took 3 hours and 10 minutes to complete. We then needed to shut down the backup VM and start the cloned VM manually. In addition, the consolidation process can be performed by invoking the VM Copy wizard, whch uses Veeam FastSCP. In both cases we had the option to start consolidating the recovered VM at any point in time. We could easily wait to run vmotion or hot-cloning during an off-peak processing period. More importantly, using Veeam Backup & Replication v5, we were able to perform an incremental backup and then recover our VM running Exchange Server 2010 with Veeam Backup & Replication v5 in less time than it took just to run a backup using data deduplication with Backup Exec 2010 R2. 25