Transcription
Implementing Effective BackupStrategies For Disaster RecoveryKurt LamoreauxConsultant, ComputerNetworking
OverviewVMware backup options3rd party backup optionsDisaster recovery – which backup options work bestCase StudyVI3 Disaster Recovery options
VMware Backup OptionsESX 2 Backup OptionsInternal virtual machine backupsService Console backups to local deviceService Console backups to network deviceSAN Imagingvmsnap/vmresESX 3 Additional Backup OptionConsolidated Backup Proxy based backup from SAN Preconfigured scripts for major 3rd party backup products
3rd Party Options – Supported Backup ToolsSymantec Backup ExecVersions 10.0, 10dVERITAS NetbackupVersions 5.0, 5.0 MP4, 5.1, 5.1 MP2 MP3, 6.0IBM Tivoli Storage ManagerVersions 5.2.1, 5.2.3, 5.3EMC NetworkerVersions 7.0, 7.1.x, 7.2, 7.3CA, BrightStor ARCServeVersions r11, r11.1, r11.5CommVault GalaxyVersion 5.9, 6.1
3rd Party Options – VMware Oriented SolutionsVizioncore esxRangeresXpressVmts.net – vmbk.plImage based backups – vms are treated as a set of filesTools are vm aware – support features such as REDO logs,suspend/resume of vms, export of vmdk files
Disaster Recovery – Which Strategy Works Best?What is the disaster?A file in the virtual machine needs to be restoredA virtual machine is not functioningAn ESX server has gone downThe SAN has gone downCatastrophic outage (entire site/region down)Disaster recovery is more than backups and restoresIt is important to develop a strategy for using backups and restoresA combination of solutions will often produce the best results
Disaster Recovery – Internal BackupsInternal virtual machine backups considerationsSame strategy for virtual machines and physical servers‘Bare metal restore’ features have become easier to useCan use disk imaging based tools for backupsSome servers do not restore well from this type of backupCan allow for a V2P restore strategy
Disaster Recovery – External BackupsExternal virtual machine backups are simpleFile level backupsSimple restore processRequire down time for virtual machine or REDO filesRequire VMware based host for restore
Disaster Recovery – Best of Both WorldsCombination of internal and external backups of virtual machinesprovides maximum flexibilityExampleMonday – external based backup of virtual machineDaily – internal based backup using 3rd party softwareCan perform simple file restore inside virtual machine for restoration ofcorrupt or deleted fileCan perform complete server restore by restoring virtual machine fromlast external backup, with the ability to restore any internal backups thatoccurred on subsequent days
Disaster Recovery – Other ConsiderationsBackup Storage – Onsite and OffsiteHardware for recoverySoftware for recoveryLocation for recoveryInstructions for recoveryHow does the virtual machine strategy tie in to the rest of theenvironment?
Case Study – Disaster Recovery StrategyUtility in AlaskaMultiple ESX server (2.5.x) on SANSingle SiteMajority of servers running as virtual machinesNetwork based backup solution already in place (IBM Tivoli)Goal – one solution that works for all backups, including virtualmachines
Case Study – Disaster Recovery LevelsMissing or corrupt files on a serverService failure on a serverSingle server failureSite level failureAll recoveries must work for both physical and virtual machines
Case Study – Site Level Disaster RecoveryIdentify critical services that must be restoredIdentify and collect necessary software and store securelyIdentify critical contacts and store securely offsiteStore all critical data offsiteArrange offsite hardwareDevelop documentation for recovery process and store securely offsiteTest recovery process
Case Study – VMware backup strategyCentralized backup strategy using IBM TivoliCombination of internal and external virtual machine backupsSchedule outage of virtual machines for external backupUse different namespace in Tivoli for hosts than for external virtualmachine backupsUse same namespace in Tivoli for all external virtual machine backups
Case Study – Tivoli ConfigurationEach ESX server backed up separatelyTivoli client installedNo vmfs partitions includedAll virtual machines run Tivoli client internallyInternal backup performed nightlyAll virtual machines backed up as files through scriptsSeparate dsm.opt fileSeparate section in dsm.sysSeparate node name
Case Study – dsm.sys fileServername esxserverxCommMethod tcpipTcpPort 1500TcpServerAddress tivoli.server.addressServername virtualmachinesCommMethod tcpipTcpPort 1500TcpServerAddress tivoli.server.addressMAKESPARSEFILE NONODENAME virtualmachinesVIRTUALMOUNTPOINT /vmfs/sanVIRTUALMOUNTPOINT /vmfs/local
Case Study – Why Use Tivoli Nodenames?Nodename used to track filesRegardless of number of ESX servers, same nodename can be used forbacking up virtual machinesIf virtual machine is moved to another ESX server, manually or usingVMotion, file will be consistently tracked.Restores of virtual machines can include prior versions using Tivolistorage features.
Case Study – When To Back Up Virtual MachinesSuspends for backups were acceptable for all virtual machinesIt was simply a matter of timingDid not impact the view in the organization of server downtimeMonitoring software modified to allow server to be down withouttriggering eventsBackups were scheduled based on size and when services could bedownTried to keep total amount of data backup up each day steadyGigabit connection – able to backup 1GB/min
Case Study – Scheduling BackupsPerl script used to perform backupsScheduled to run hourlyMaster file of all vms was created and used to control backupsDay of week and time of day controlled in fileMultiple days could be selectedIf virtual machine was moved from one host to another, backupschedule not affectedScript could also be used for manual backupsTivoli logs parsed and used to create web based report of results
Case Study – Backup Script OverviewList of registered virtual machines on host createdList compared to master file to flag any not in fileFor each virtual machine, identify if time to backupRead vmx file to determine vmdk files to backup and suspend locationSuspend virtual machineUse Tivoli to backup vmdk files, REDO files (if any), suspend file, andcorresponding home directoryResume virtual machineCollect log files for reportingCopy of script available – kurt@cncsinc.com
Case Study – Disaster Recovery PlanCreate Tivoli serverRestore Tivoli databaseLoad tapes into systemCreate ESX serverInstall Tivoli clientRestore virtual machine drives (and home dirs if needed)Register or create virtual machines using restored drivesRestore physical servers using Tivoli bare metal restore functionsPrior to VMware - success rate was very low – over 5 days with noaccess to data actually availableUsing VMware in DR strategy, in 3 days they can have most criticalsystems up and completely functional
Case Study – Benefits of ApproachSimple approachEliminates the use of redo files for backupsPerl script approach could be adapted for other uses, such as databaseand other file backupsDisaster Recovery plan kept simpleSolution works well for site disaster, SAN disaster, and server or servicedisaster
Virtual Infrastructure 3 – Disaster RecoveryConsolidated BackupControlled using /etc/vmware/backuptools.confAdditional Information at VMworld 2006LAB3801 - VCB for Disaster RecoveryBCT9552 - VI3 Capabilities for Improving Disaster RecoveryBCT4540 - Integrating VCB into Your Backup Infrastructure: BestPractices for Implementation and CustomizationBCT5070 - Leveraging VMware ESX Server in Disaster RecoverySolutionsTAC4016 - Integrating ESX Server 3 with Data Protection SoftwareTAC9816 - Hot Backups and Restores for VMware ESX Server: A '12' Punch Backup MethodologyTAC9912 - Nondisruptive Backup of VMware Environments UsingVERITAS NetBackupMDC9870 - Backup and Recovery of Virtual Machines
ConclusionFor an effective disaster recovery planIdentify scope of disasterDetermine acceptable down time for virtual machinesImplement a strategy that is simple and flexibleDocument processHave 3rd party test process
Presentation DownloadPlease remember to complete yoursession evaluation formand return it to the room monitorsas you exit the sessionThe presentation for this session can be downloaded r the following to download (case-sensitive):Username: cbv repPassword: cbvfor9v9r
Some or all of the features in this document may be representative offeature areas under development. Feature commitments must not beincluded in contracts, purchase orders, or sales agreements of any kind.Technical feasibility and market demand will affect final delivery.
IBM Tivoli Storage Manager Versions 5.2.1, 5.2.3, 5.3 EMC Networker Versions 7.0, 7.1.x, 7.2, 7.3 CA, BrightStor ARCServe Versions r11, r11.1, r11.5 . Disaster Recovery plan kept simple Solution works well for site disaster, SAN disaster, and server or service disaster. Virtual Infrastructure 3 - Disaster Recovery
