Granite Data Protection and Recovery Guide

Transcription

1 SOLUTION GUIDE Granite Data Protection and Recovery Guide Solution Guide Version 1.5 Nov 2013

2 Table of Contents Introduction... 4 Audience... 4 Additional Resources... 4 Prerequisites... 4 Granite Overview... 5 Branch Office Data Backup Challenges... 6 Granite Solution... 6 The Time Lag Concept... 7 Data Consistency Explained... 8 Crash Consistent Snapshots and Backups... 8 Application Consistent Snapshots and Backups... 8 Crash consistent and application consistent backups example... 8 STRATEGY #1: Continue to use agents- based or host- based backups at the branch office Single file recovery Advantages and caveats Best practices Strategy #2: Perform LUN snapshots at the data center Single file recovery Single file recovery from VMFS file system Single file recovery from NTFS file system Advantages and caveats Strategy #3: Perform backups from LUN snapshots at the data center Single file recovery Entire VMDK file recovery Advantages and caveats Strategy #4: Branch snapshots plus backup from application consistent snapshots at the data center Single file recovery File recovery from Granite Blockstore snapshots at the branch Advantages and caveats Best practices STRATEGY 4b: Branch snapshots via Windows Volume Shadow Copies Advantages and caveats Best practices STRATEGY #5: Backup using the Granite snapshot scheduler at the data center Single file recovery Entire VMDK file recovery Riverbed Technology. All rights reserved. 2

3 Advantages and caveats Best practices Conclusion About Riverbed Riverbed Technology. All rights reserved. 3

4 Introduction One of the major concerns for organizations is the ability to backup and restore data, especially when the data resides at the branch office. By delivering consolidation and centralization of data from the branch office to the data center, Riverbed Granite appliances help organizations be more effective with branch data backup and restore. Granite technology preserves or enhances the existing data protection strategies. Customers can maintain, without modification, the existing branch office data protection processes even after migration to Granite technology or can make use of Granite technology to further enhance them. This solution guide goes over the different branch office data protection and file level recovery strategies analyzing how each strategy works within a Steelhead EX + Granite deployment. Audience This paper is written for storage, backup and network administrators familiar with administering and managing distributed office environments using common network and storage protocols such as iscsi, SCSI, TCP, CIFS, HTTP, FTP, and NFS. You must also be familiar with: Riverbed Steelhead appliance installation and configuration process Riverbed Steelhead management interface Additional Resources For a complete list and the most current version of Riverbed documentation log in to the Riverbed support website located at The Riverbed Knowledge Base is a database of known issues, how-to documents, system requirements, and common error messages. You can browse titles or search for key words and strings. To access the Riverbed Knowledge Base, log in to the Riverbed Support site located at Prerequisites This whitepaper assumes that the branch physical servers have been virtualized and are now running on ESXi as part of the Steelhead EX Virtual Service Platform (VSP) or an external stand-alone ESXi server Riverbed Technology. All rights reserved. 4

5 Granite Overview Granite products enable users and applications in branch office locations to write to and access centrally managed storage maintaining local disk performance. By accelerating branch access to data center deployed iscsi Storage Area Networks (SANs), IT organizations no longer need to provision and maintain dedicated storage resources in branch offices. The Granite solution is deployed in conjunction with Steelhead appliances and consists of two components: Granite Core a physical or virtual appliance that resides in the data center alongside a Steelhead appliance and the centralized SAN Granite Edge a software module that runs on a Steelhead EX appliance in the branch office Granite Core mounts the LUNs provisioned in the data center and shares the storage resources with branch offices running the Granite Edge module. Granite Edge virtually presents one or more iscsi targets in the branch which can be utilized by services and systems running both within the Virtual Service Platform (VSP) as well as externally to the Steelhead EX appliance. Granite Core inspects mounted file systems and proactively stream data to the branch locations utilizing innovative block-level prediction algorithms. This industry-first capability allows data from centralized storage to be available wherever and whenever it is needed. Through asynchronous block-based write acceleration, Granite Edge ensures that data created in branch office locations is securely stored in the data center. Figure 1 Granite Core and Granite Edge High Level Network Topologies 2012 Riverbed Technology. All rights reserved. 5

6 Branch Office Data Backup Challenges Geographically distributed organizations face major challenges managing their remote office and branch office storage needs, whether they decide to store the data locally or at the data center. Today more than ever they are experiencing an explosion in data growth, together with a request to improve their backup and recovery processes while containing storage costs and keeping the data secure. On top of that, growing concerns include having adequate lab space for all the storage and IT gear and finding qualified IT personnel with the appropriate storage skills to manage and configure it. Today s solutions to these challenges vary depending on the size, the distance, and the geographical location of these remote branch offices leaving IT storage administrators to implement a variety of different approaches. One approach, for example, is to back up the data locally. This approach provides fast recovery but requires deploying expensive and complicated to manage storage arrays and/or backup tapes at the branch and does not provide geographical disaster recovery protection. Moreover, maintaining tapes and running backup agents is fragile and error prone. Another approach is to centrally back up branch data to the data center. While this approach provides geographical disaster recovery protection, it requires expensive data replication software and/or licenses and will slow down the data recovery process in the event of a disaster it requires a restore of all the data back to the branch office before you can resume operations. Granite Solution With the Granite solution, since data is consolidated into the data center and at the same time is projected to the branch office, the benefits of both approaches can be achieved. The backup can be done centrally at the secure data center where skilled IT storage personnel resides and can manage and configure storage arrays, backup systems and deal with any unforeseen issues, without requiring expensive data replication software and/or licenses, and still providing geographical disaster recovery protection. In case of a disaster, since the data is available at the data center and the Granite appliances can stream it, as needed, to the newly deployed hardware at the branch office, the restore can be done without performing full data restores, providing fast recovery, without deploying expensive and complicated to manage storage arrays and/or backup tapes at the branch. Moreover, in case of data loss (mistakenly deleted files, deleted directories, virus), Granite products work with array-based snapshots, mirroring methodologies and with traditional backup software, allowing both data protection and recovery to be performed from the data center Riverbed Technology. All rights reserved. 6

7 The Time Lag Concept As indicated in Figure 2, there is a time lag between the time data is written locally by the branch application servers and the time data arrives at the data center. The Granite Edge module locally acknowledges all the write requests from the branch application servers and in the background continuously syncs new data to the data center storage LUN. This is to avoid the round trip delay for every write operation and provide at the same time local performance to the branch s application servers and continuous data protection. This also means that someone looking at the LUN at the data center vs. at the branch will see slightly older data, because the new data written at the branch has not yet made it to the data center. The Time Lag depends on these factors: WAN Bandwidth WAN Latency Data Compression Ratio Data Change Rate Branch Server I/O Figure 2 Time Lag Time lag fluctuates throughout the course of the branch servers operations. The Granite product offers realtime graphs and statistics that measure average, max and min time lag. Use this information to appropriately design your backup strategy. Figure 3 Average Commit Delay 2012 Riverbed Technology. All rights reserved. 7

8 Data Consistency Explained In the context of data protection it is important to clearly understand the concept of data consistency. Data consistency comes into play every time an application or service needs to be recovered and a backup copy of the data is used instead of the original. A backup copy can be in different status of consistency, the 2 major consistency types are: Crash Consistency and Application Consistency Crash Consistent Snapshots and Backups A backup or snapshot is crash consistent if all of the interrelated data components are as they were at that particular instant in time of the crash. To better understand this type of consistency, imagine the status of the data on your PC s hard drive after a power outage or similar event. A crash consistent backup is usually good for non-database operating systems and applications like File Servers, DHCP Servers and Print Servers. Application Consistent Snapshots and Backups A backup or snapshot is application consistent if not only it is write order consistent at that point in time but if the applications have also had the chance to complete all their operations and flush their buffers to disk. Imagine the status of the data on your PC s hard drive after a clean shutdown. An application consistent backup is recommended for applications like SQL, Oracle and Exchange. Application consistency is also required for incremental backups; full backups on the other hand only require crash consistency. Granite Triggered Snapshots and Data Consistency In a Granite deployment, you can trigger snapshots of the projected LUNs by using the storage system snapshot commands on the storage system itself or by using the Granite Core snapshot scheduler. Snapshots created using the storage system snapshot commands are crash consistent. Snapshots created using the Granite Core snapshot scheduler are application consistent. Granite provides application consistency through integration and coordination between the servers running at the branch and the storage systems at the data center. At the branch: for LUNs formatted with VMFS file system, Granite interacts with the operating system via the ESXi server that is hosting the virtual machine and using VMware Tools to quiesce and flush the server buffers for LUNs formatted with NTFS file systems, Granite interacts directly with the operating system via the Riverbed Host Tools plugin to quiesce and flush the server buffers. At the data center: Granite integrates with the storage system APIs to trigger the snapshot on the storage system. Crash consistent and application consistent backups example When a backup application uses application consistent snapshots as its data source, all the data in the application logs, buffers etc. is completely flushed out to the data files on disk, and the restore process will be faster. However the application consistent backup might not have all the latest changes. A crash Riverbed Technology. All rights reserved. 8

9 consistent backup, on the other hand, will most likely have all the latest changes, but the application will have to recover at least part of data from its transaction logs. Since not all applications can perform roll forward transactional recovery from crashes, this can make this type of recovery process impossible. A common approach for applications that support both application and crash consistent backups is to recover from the most recent application-consistent point in time first to get an application service back up and running as quickly as possible and then recover the missing data later from a crash-consistent snapshot. In the Exchange world, for example, this would allow users to start sending and receiving again very quickly, but they may not have access to all their most recent s until the administrator has completed recovery operations for all the Exchange updates since the last application consistent snapshot Riverbed Technology. All rights reserved. 9

10 STRATEGY #1: Continue to use agents-based or host-based backups at the branch office Since Granite does not impose any change to the existing branch office agents-based and host-based backups procedures, the first strategy and the simplest to implement is to just continue to backup the branch data as you were backing it up before implementing the Granite solution. You just don t benefit from the fact that the data is already at the data center. Figure 4 shows the high level diagram of an agent-based backup design implemented on a branch office where the Granite solution has been deployed. In this scenario, when the backup server initiate the backup process, the backup agent at the branch, running on the virtual server, quiesces applications IOs and flushes the server buffers before triggering the LUN snapshot. The LUN snapshot is an applicationconsistent point in time view of the data to be sent to the backup server at the data center. Backups obtained in this way are application consistent, but the data might in some cases unnecessarily traverse the WAN. Steelhead WAN optimization is designed to recognize the data that already exists at the data center from previous Granite synchronizations and to only send data references instead of data segments reducing the amount of data that actually crosses the WAN. In this case, while both the remote backup agent and the data center backup server believe that the data is being sent across the WAN, only truly unique data segments actually are sent across. Figure 4 Host-based backup agents at the branch office To better understand how the data flows during incremental and full backups here the high level list of steps involved. Steps for incremental backups: 1. Backup server initiates the backup job and communicates to the backup agent running on the virtual server at the branch office. 2. Backup agent receives the request, takes a snapshot and prepares the changed data Riverbed Technology. All rights reserved. 10

11 3. Changed data is sent to the backup server, and the data transfer is optimized via Steelhead appliances. Note: Since the Granite Edge appliance has just transferred the same changed data across the WAN, the Steelhead appliances Datastore will already contain the backup data segments, and the backup across the WAN will result in having LAN-like performance. Steps for full backups: 1. Backup server initiates the backup job and communicates to the backup agent running on the virtual server at the branch office. 2. Backup agent receives the request, takes a snapshot and prepares all the data contained in the LUN. Note: During this process, if the data contained in the LUN is not all contained in the Granite Edge Blockstore cache, the data will have to be fetched from the data center LUN, causing unnecessary data transfers from the data center to the branch. 4. Data is sent to the backup server, and the data transfer is optimized via Steelhead appliances. Note: Also in this case the Steelhead appliances Datastore will already contain most of the data segments, and the backup across the WAN will result in having LAN-like performance. Datastore needs to be properly sized so that full backups don t cause the Datastore to wrap too frequently. Alternatively the Steelhead appliance can be configured to perform compression-only for backup traffic. Single file recovery Single file recovery also remains unchanged from the existing workflow. Use the backup application to restore the file to its original location. The in-path Steelhead appliances will optimized the data transfer. Alternatively for very big files or entire servers restores, take the LUN offline from the branch office, bring the LUN online at the data center, restore the file at the data center and re project the LUN to the branch office using the Granite. Granite prediction and prefetching algorithms combined with Steelhead appliance WAN optimization techniques will ensure LAN-like user experience for data-read and LAN performance for datawrite at the branch office. Note: This procedure is not recommended for small files or when multiple servers share the same LUN since it requires a short downtime of the entire LUN. Advantages and caveats The following table lists the advantages and caveats of deploying this strategy: Advantages The Granite solution does not require changes to the existing branch backup and restore procedures 2012 Riverbed Technology. All rights reserved. 11

12 Caveats Backup and recovery is done at the data center when administrators reside User friendly backup application can be used Data might be sent over the WAN multiple times, despite the fact that data already exists in the data center. In the case of a full backup, for example, data contained in the LUN may have to be retrieved from the data center, in order to backed up and sent to the data center again. Best practices The following table summarizes the best practices for this strategy: Best Practices Avoid the use of full backups, since they might cause the data to unnecessary be fetched from the data center in order to be backed up. Use synthetic full, incremental or differential backups instead. Disable backup software compression and/or encryption features on the backup application and offload those tasks to the Steelhead appliance Riverbed Technology. All rights reserved. 12

13 Strategy #2: Perform LUN snapshots at the data center Since the Granite appliances continuously sync the data created at the branch to the data center LUN, you can use the storage array at the data center to schedule periodic snapshots on the LUN. It is important to note that the storage array (at the data center) does not instruct the applications running on the virtual servers (at the branch) to quiesce their IOs and flush their buffers before taking the snapshots, causing the snapshots to be crash-consistent instead of application-consistent.. Crash consistent snapshots are usually good for non-database operating systems and applications like File Servers, DHCP Servers and Print Servers. Furthermore, due to time lag in the data transfer over the WAN, a snapshot might not contain all the data written to the branch at the time of the snapshot. Put differently, if a snapshot is taken at 6:00 pm, it might contain branch data that was written up to 5:59 pm, because the remaining data has not yet been transferred over the WAN at that point. Figure 6 shows the high level diagram of this strategy. Figure 5 Data center backups from snapshot 2012 Riverbed Technology. All rights reserved. 13

14 In addition, you can replicate the data in the snapshots to a secondary storage array using the storage array replication software, as shown in Figure 7 Figure 6 Replication to secondary data center Single file recovery Single file recovery procedures vary based on the file system type. Single file recovery from VMFS file system To recover individual files from a storage array snapshot of a LUN formatted with VMFS, hence containing virtual disk (VMDK) files, present the snapshot to a VMware ESX Server, attach the VMDK to an existing VM running the same operating system (or an operating system that will read the file system used inside the VMDKs in question) and then browse the file system to retrieve the files stored inside the VM. Figure 7 Recovery from VMFS file system 2012 Riverbed Technology. All rights reserved. 14

15 Single file recovery from NTFS file system To recover individual files from a storage array snapshot of a LUN formatted with NTFS, hence containing directly the single files (not encapsulated on virtual disks VMDKs), present the snapshot directly to a server running Microsoft Windows operating system (or an operating system that will read the file system used on the LUN) and then browse the file system to retrieve the files. Figure 8 Recovery from NTFS file system Note: In order to present the snapshot to an external server you may need to take advantage of the LUN cloning feature of the storage array. The LUN cloning feature allows you to create a clone from a snapshot, which is a read-write point-in-time copy of the file system. This clone takes only seconds to create, like the snapshot on which it is based. Advantages and caveats The following table summarizes the advantages and caveats of this strategy: Advantages Snapshots are performed entirely at the data center Does not require additional data transfer across the WAN Integrates into existing strategies of using array snapshots and data center replication Microsoft Windows servers at the branch are offloaded from backup activities Backup and recovery is done at the data center when administrators reside Caveats Will not work for applications requiring application-consistent backups (e.g. databases ) Time of snapshot may not reflect the time of last data written at the branch, due to Time Lag in data transfer over the WAN LUN must be mounted to an a staging server to retrieve the file 2012 Riverbed Technology. All rights reserved. 15

16 Strategy #3: Perform backups from LUN snapshots at the data center In strategy #2 you used the storage array at the data center to schedule periodic snapshots on the LUN. In strategy #3 you will backup the data by mounting these snapshots to a proxy backup server using your backup software. Figure 10 shows the high level diagram of strategy #3. Figure 9 Data center backups from snapshot Note: A proxy backup ESX server is needed only if the data is stored on a virtual machine disk (VDMK) formatted with VMFS file system. If the LUN is formatted with the NTFS file system, and it is access directly via iscsi by the virtual server, the LUN snapshot can be directly mounted to the backup server (usually backup software runs on Microsoft Windows operating system). To better understand how the data flows during a backup from a LUN snapshot, here the high level list of steps involved. Steps for VMFS LUN backup: 1. Storage array takes a snapshot of LUN. 2. The snapshot is mounted to a proxy ESX backup server. 3. The backup server interacts via VMware VADP APIs with the proxy backup server to retrieve the data and perform full or incremental backups Riverbed Technology. All rights reserved. 16

17 Steps for NTFS LUN backup: 1. Storage array takes a snapshot of LUN 2. The snapshot is mounted to the Microsoft Windows backup server 3. The backup server directly retrieves the data and performs full or incremental backups. Note: The storage array (at the data center) did not instruct the applications (running at the branch) to quiesce their IOs and flush their buffers before taking the snapshots, causing the snapshots to be crash consistent. Incremental backups usually require application consistent snapshots and might not be supported from crash consistent snapshots. Single file recovery With this strategy, file recovery remains unchanged from the existing backup applications workflow. To restore lost files simply login to the backup application server, select the files you want to restore, select the branch virtual server as the restore location, and start the restore operation. Note: Requires backup agent running on the virtual server at the branch to perform the restore operation. To eliminate the requirement of running the backup agent on the branch virtual server, files can be restored on a shared folder at the data center and then sent to the branch office location. Alternatively the LUN can be taken offline from the branch office, and the file can be directly injected into the LUN at the data center. This procedure is not recommended when multiple virtual machines share the same LUN since it will require all the virtual machines to be taken offline. Entire VMDK file recovery Also for virtual server recovery the procedure remains unchanged from the existing workflow. To restore an entire virtual server login to the backup application server, select the VMDK file you want to restore and start the restore operation. To restore directly at the branch select the restore to a different location option and enter the IP address or hostname of the branch ESX server, otherwise the backup application will restore the virtual machine to the data center proxy ESX server. (Remember the proxy ESX server is where you executed the backup, hence the original location from the point of view of the backup software) To avoid restoring a full virtual machine (VMDK file) over the WAN, take the LUN offline and remove it from the Granite Core appliance. From the storage system, expose the LUN to a temporary ESX(i) server located at the data center. The backup server can now directly restore the virtual server to this LUN. In this way, the restore is done locally at the data center without having the full VMDK file to be transferred across the WAN. Mount back the LUN to the Granite Core appliance and re project it to the branch office. The server will be immediately ready to boot at the branch and the prediction and prefetching algorithms built in the Granite Core will allow the virtual server to boot in just few minutes. If multiple virtual machines share the same LUN, this procedure is not recommended since it will require all the virtual machines sharing the same LUN to be momentarily taken offline. In this case provision a new LUN with the recovered VMDK file, and project this new LUN to the branch office Riverbed Technology. All rights reserved. 17

18 VMDK files can also be restored on a shared folder and then be sent to the branch office location. Advantages and caveats The following table lists the advantages and caveats of deploying this strategy: Advantages Backup is performed entirely at the data center Backups do not require additional data transfer across the WAN Integrates into existing strategies of using array snapshots and data center replication Caveats Will not work for applications requiring application consistent backups (e.g. databases ) Incremental backups are not supported since the snapshots are crash consistent Time of snapshot may not reflect the time of last data written at the branch, due to Time Lag in data transfer over the WAN Needs scripting orchestration to integrate with traditional backup applications 2012 Riverbed Technology. All rights reserved. 18

19 Strategy #4: Branch snapshots plus backup from application consistent snapshots at the data center This strategy builds on top of the previous and uses the Granite integration with Microsoft Windows Volume Shadow Copy Service (VSS). It requires the installation of the Riverbed Host Tools plugin on the branch Windows server, and it can only be used on Granite LUNs mounted to the Windows server via Microsoft iscsi initiator. Figure 11 shows the high level diagram of strategy #4. Figure 10 Data Center VSS Trigger Backups from Snapshots To understand how this strategy works, here the high level list of steps involved: 1. The Granite Core snapshot scheduler triggers a snapshot on the projected LUN. 2. The Granite Edge module inside the Steelhead EX appliance interacts with the Riverbed Host Tools plugin installed on the server to quiesce the applications, flush the data and create an application consistent state. 3. The Granite Edge module takes a snapshot on the Blockstore cache storage space and inserts a marker on the stream of data flowing to the data center, to denote the point in time in which the data is in an application consistent state. 4. The Granite Core appliance passes through the data stream to the data center LUN. 5. Upon detection of the snapshot marker the Granite Core appliance instructs the storage array to take a snapshot. The storage array snapshot is also application consistent because Granite has flushed application consistent data before instructing the storage array to take a snapshot. Due to the latency introduced by the WAN it might take some time for the snapshot to get created in the storage array; however, the snapshot will not be created until all data (pertinent to that snapshot) 2012 Riverbed Technology. All rights reserved. 19

20 has been committed, assuring that the backup will contain all the data written to the branch up to the time of the snapshot. 6. After the snapshot is taken on the storage array at the data center, the backup server mounts the snapshot and performs the backup. Single file recovery With this strategy, since the snapshot is created both at the branch, on the Granite Blockstore cache, and at the data center, on the storage array, file recovery can be performed in both places. File recovery from Granite Blockstore snapshots at the branch. When snapshots are taken at the branch using Windows VSS in conjunction with the Riverbed Host Tools plugin, then each snapshot will appear to the Windows server as a separate drive. To recover a file, browse to the drive associated to the desired snapshot, locate the file and restore it. Figure 11 Recovery from branch snapshots File recovery from storage array snapshots or backup catalog at the data center. When snapshots are taken at the branch using Windows VSS in conjunction with the Riverbed Host Tools plugin, then a LUN clone is also available at the data center. To recover a file, mount the LUN clone to a Windows server at the data center, locate the file and restore it. Figure 12 Data center recovery from Catalog File 2012 Riverbed Technology. All rights reserved. 20

21 If the snapshot was backed up via backup server, the file recovery remains unchanged from the existing backup applications workflow. To restore the lost file login to the backup application server, select the file you want to restore and start the restore operation. To restore files directly to the virtual machine running at the branch select the branch virtual server as the restore location. Note: Direct branch restore requires backup application agent running on the virtual server at the branch. To eliminate the requirement of running the backup application agent on the branch virtual server, files can be restored on a shared folder at the data center and then be sent to the branch office location. Advantages and caveats The following table lists the advantages and caveats of deploying this strategy: Advantages Caveats Application consistent snapshots and backups No additional data transfers over the WAN Branch Windows servers are offloaded from snapshot creation Snapshots on the Blockstore cache don t use any space Works on LUNs mounted on Windows Servers via Microsoft iscsi initiator (LUN needs to be formatted with NTFS). Does not work on LUNs mounted on ESX Servers via VMware iscsi initiator (does not work on VMFS Datastores). Works with Windows 2008, 2008R2, 2012 deployments Snapshot Scheduler on the Granite Core is currently available for EMC, NetApp and EqualLogic storage arrays. It is not supported on Granite LUNs exposed via ESXi Raw Device Mapping (RDM). Best practices The following table summarizes the best practices for this strategy: Best Practices To guarantee application consistent snapshots keep database s control files, data files, online redo logs, and archived logs in the same LUN 2012 Riverbed Technology. All rights reserved. 21

22 STRATEGY 4b: Branch snapshots via Windows Volume Shadow Copies. Windows Volume Shadow Copies and Previous Versions can also be enabled at the branch on a Granite LUN despite which of the backup strategies you decide to implement. When using Windows Volume Shadow Copies users can right click on the drive, navigate to the previous version tab and recover deleted, damaged or overwritten files. Windows uses its default VSS software provider, instead of the Riverbed Snapshot Host Tools plugin and backups the previous 64 versions of each file. Figure 13 Recovery from Windows VSS snapshots Note: For more information on Microsoft Volume Shadow Copy Service please refer to this article Advantages and caveats The following table lists the advantages and caveats of deploying this strategy: Advantages Caveats User friendly Windows Previous Version graphical user interface can be used Administrator is not required for file recovery Windows is not offloaded from snapshot creation Extra storage in the Blockstore cache is required Unnecessary shadow copies data will traverse the WAN if not redirected to a local LUN Best practices The following table summarizes the best practices for this strategy: Best Practices The shadow copy system uses an extra 300MB of storage space in the Granite Blockstore; however the total amount of space required will depend on the size of the LUN which is to be shadowed and the frequency and the extent to which the files are likely to change. To reduce the storage space utilization, limit the size of the shadow copies drive. It is also recommended setting the shadow copies drive to a Granite Local LUN to avoid that the shadow copies data will unnecessary traverse the WAN. Data on Granite local LUNs does not get synched to the data center Riverbed Technology. All rights reserved. 22

23 STRATEGY #5: Backup using the Granite snapshot scheduler at the data center. This strategy uses the new data protection and snapshot integration features available in Granite software 2.5. With this strategy, you can alleviate branch virtual servers from backup load, backup multiple virtual servers at once, produce application consistent backups, and avoid backup data to traverse the WAN Granite 2.5 software integrates both with VMware ESX/ESXi and Microsoft Windows servers, allowing backup of both VMFS and NTFS data drives. Granite software also integrates with the snapshot capabilities of the storage systems, enabling the end-to-end configuration of application-consistent snapshots through the Granite Core Management Console. The new user interface option on Granite Core in the data center enables administrators to quickly set and assign hourly, daily, or weekly storage snapshot policies to ensure application consistent data protection in conjunction with the supported storage arrays. Once storage snapshots are created in the data center, in addition to leveraging the disk snapshot for fast recovery, many organizations use snapshots as a source for backup to secondary media such as tape or cloud storage to ensure data is located offsite. Granite 2.5 adds a new simplified snapshot handling process that simplifies backup of consolidated branch data with enterprise backup software in the data center. Figure 15 shows the high level diagram of strategy #5. Figure 14 Backup using Granite snapshot scheduler at the Data Center To better understand how this strategy works, here the high level list of steps involved: 1. At the data center, the administrator sets up a snapshot schedule on the Granite Core appliance. 2. At the branch, based on the configured schedule, the Granite Edge appliance instructs the ESXi server to take a snapshot of the running virtual machines. This causes the ESXi server to request the virtual machines to quiesce and flush their file systems to disk via VMware Tools. In this 2012 Riverbed Technology. All rights reserved. 23

24 particular case, this process causes the data inside the Virtual Machine Disk (VMDK) files, and its corresponding SCSI data blocks on the Granite Edge Blockstore to be in an application consistent state. 3. The Granite Edge appliance takes a snapshot of the entire LUN and sync the data through the Granite Core to the data center LUN on the storage system. 4. Once all the data is committed to data center LUN, the Granite Core appliance instructs the storage array to take a snapshot that will also be application consistent. 5. The Granite Core appliance mounts the snapshot to a proxy backup ESX server and add the virtual machines present in the Datastore to the ESXi inventory. Note: The proxy backup server is required because backup software was not designed to backup ESXi servers running at the branch office which have their Datastores residing on data center LUNs projected to the branch via Granite appliances, or backup directly from the storage array LUNs. Hence the backup applications will interact with a proxy ESX server located at the data center mounting a snapshot of the LUNs assigned to Granite, instead of interacting directly with the ESX server running at the branch. 6. The backup software communicates with the proxy server to perform the virtual machines backup (point in time copy of the virtual machines that are running at the branch) using the VMware vsphere Storage APIs for Data Protection (VADP). Note: VADP backups are the evolution of the VCB (vsphere Consolidated Backup) backups. Like VCB, VADP backups are designed to backup virtual machines running on ESX servers, however, VADP provides significant improvements over VCB that allows for simple and efficient backup of Granite LUNs. In particular the support of vsphere Change-Block-Tracking (CBT) capability that allows taking incremental backups without losing the file level recovery capability. If the LUN is formatted directly using NTFS, which means that the Windows server has mounted the LUN using Microsoft iscsi initiator, the process is very similar: 1. At the data center, the administrator sets up a snapshot schedule on the Granite Core appliance. 2. At the branch, based on the configured schedule, the Granite Edge appliance instructs the Windows server via Riverbed Host Tool plugin (not the ESX server) to take a snapshot of the NTFS data drive. 3. The Granite Edge appliance takes a snapshot of the entire LUN and sync the data through the Granite Core to the data center LUN on the storage system. 4. Once all the data is committed to data center LUN, the Granite Core appliance instructs the storage array to take a snapshot that will also be application consistent. 5. Granite Core appliance mounts the snapshot to a proxy backup Windows server (instead of an ESXi server) Riverbed Technology. All rights reserved. 24

25 6. The backup software communicates with the Backup Windows server to perform the backup of the data Single file recovery With this strategy, file recovery remains unchanged from the existing backup applications workflow. To restore lost files simply login to the backup application server, select the files you want to restore, select the branch virtual server as the restore location, and start the restore operation. Note: Single file recovery requires backup agent running on the virtual server at the branch to perform the restore operation. To eliminate the requirement of running the backup agent on the branch virtual server, files can be restored on a shared folder at the data center and then sent to the branch office location. Alternatively the LUN can be taken offline from the branch office, and the file can be directly injected into the LUN at the data center. This procedure is not recommended when multiple virtual machines share the same LUN since it will require all the virtual machines to be taken offline. Entire VMDK file recovery Also for virtual server recovery the procedure remains unchanged from the existing workflow. To restore an entire virtual server login to the backup application server, select the VMDK file you want to restore and start the restore operation. To restore directly at the branch select the restore to a different location option and enter the IP address or hostname of the branch ESX server; otherwise the backup application will restore the virtual machine to the data center proxy ESX server. (Remember the proxy ESX server is where you executed the backup, hence the original location from the point of view of the backup software) To avoid restoring a full virtual machine (VMDK file) over the WAN, take the LUN offline and remove it from the Granite Core appliance. From the storage system, expose the LUN to a temporary ESX(i) server located at the data center. The backup server can now directly restore the virtual server to this LUN. In this way, the restore is done locally at the data center without having the full VMDK file to be transferred across the WAN. Mount back the LUN to the Granite Core appliance and re project it to the branch office. The server will be immediately ready to boot at the branch and the prediction and prefetching algorithms built in the Granite Core will allow the virtual server to boot in just few minutes. If multiple virtual machines share the same LUN, this procedure is not recommended since it will require all the virtual machines sharing the same LUN to be momentarily taken offline. In this case provision a new LUN with the recovered VMDK file, and project this new LUN to the branch office. Advantages and caveats The following table lists the advantages and caveats of deploying this strategy: Advantages Application consistent snapshots No additional data transfers to data center Multiple virtual machines can be protected at the same time Backup and restore procedures centralized at the data center Works on LUNs mounted on via Microsoft iscsi initiator or VMware iscsi initiator 2012 Riverbed Technology. All rights reserved. 25

26 Caveats Works on LUN formatted with NTFS and VMFS Both full and incremental backups are supported Snapshot integration to achieve application consistent backups is currently available only for EMC, EqualLogic and NetApp storage systems Best practices The following table summarizes the best practices for this strategy: Best Practices To ensure data consistency install VMware Tools and the Riverbed Host Tool in each virtual Windows server to be backup up. To guarantee application consistent snapshots keep database s control files, data files, online redo logs, and archived logs in the same LUN Conclusion Riverbed continues to help organizations gain better control over their IT infrastructure and consolidate more to lower costs and risks without impacting the performance required to ensure user productivity in branch offices. With the Granite solution, Riverbed enables a global storage infrastructure by intelligently accelerating storage across the WAN, enabling new efficiency with data management, protection, and recovery while ensuring performance a the edge. By consolidating data out of the branch and into the data center, Granite enables organizations to decommission branch backup and recovery systems, shifting data protection operations to the secure data center. Enterprises are able to utilize their well-honed data center backup and recovery systems and procedures and skilled personnel to protect branch data. Granite 2.5 provides key enhancements that simplify data protection and provide streamlined management in the consolidated environment. About Riverbed Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA Tel: (415) Riverbed Technology Ltd. One Thames Valley Wokingham Road, Level 2 Bracknell. RG42 1NG United Kingdom Tel: Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore Tel: Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan Tel: Riverbed Technology. All rights reserved. 26