Transcript Backups

George Hewitt
BCS Teesside - 8th Feb 2012
Where we’re going
Why backup?
Key ideas
Backup/restore methods
Example architecture
Backup media
• Survey of European firms:
– 54% had lost data or suffered systems
downtime in past 12 months
– 74% were ‘not very confident’ they could fully
restore their networks
– Most common cause of data loss/downtime
was hardware failure
Why backup?
• Mitigate risk of downtime
– Hardware failure, natural disasters etc
• Mitigate risk of data loss
– User/software error (including malice!) or
• How expensive is downtime/data loss to you?
• A backup infrastructure will form part (or all)
of a DR/BC architecture
Key Metrics
Recovery Time Objective (desired)
Recovery Time Capability (current)
Recovery Point Objective
Retention period (D/W/M)
• An idea of what you consider unacceptable
downtime will guide you towards what sort of
DR/BC architecture you need
What are not backups?
Clustering / NLB / other HA
VM snapshots
System restore
Outlook PST on local machine
Shadow copies?
Types of backup
Full backup
Incremental – changes since last backup
Differential – changes since last full
Synthetic full
Continuous data protection
Types of Restore
• Granular Restore Technology
– Aka File/Object Level Restore
• Bare-metal restore
Traditional backup architecture
Semi-virtualised architecture
Traditional Backups
• Benefits
– Single management interface
– Direct control over backup selection lists
• Downsides
– No reduced costs (backup agent on each VM)
– Slow to backup (all traffic over LAN)
– Slow to restore (especially baremetal!)
VM Snapshots
VM Disk-level backup
VM Host & Storage
Backup staging storage
LAN or Storage Network
• LAN-free
• Over storage (FC / iSCSI etc)
• eg VCB / vStorage API
• BackupExec VCB, Quest vRanger, Veeam
Interesting Extras!
• Changed Block Tracking
– Improve incremental VMware backups
– Backup software requests changed blocks since last backup
– eg. 500GB server taking 2hrs, now only 40mins!
• Active Block Mapping
– Only blocks in use by the VM are backed up
– Software interrogates filesystem (eg NTFS)
– eg. Deleted data is ignored
VM Quiescing
• To enable application-consistent backups
(eg for SQL, Exchange)
– Tells the OS/Application to ‘get ready’ for a
• Off = crash consistent backup!
• However – may require additional scripting
depending on application
File-level Restore of VM
Restore Demo
Example Architecture
• Medium-size business – 200 users.
– 10 servers
– Active Directory, Exchange, SQL, File & Print,
line of business application
– Single VM host with local storage (all servers)
– BackupExec installed on VM but selection
lists have been restricted to data only
– Backups completed to tape
– RTO is 1hr. Current RTC is 2 days
Example Architecture
• Provision new physical backup server with
disk staging
• Use appropriate software to perform VM-level
backups for most servers
• BackupExec to duplicate VM backups to tape
• Use BackupExec agents for Exchange
Mailboxes and SQL server
• Invest in HA SAN or host replication
A note on SQL
• Precise method used to backup depends
on your RTO/RPO (and size/number of databases)
• SQL Agent Backup Jobs can be an option
(backup to flat-file) for small number of
Backup Media
• NAS / Disk shelves
• Advantages
– fast!
• Disadvantages
– expensive (consider retention period)
– physical protection (onsite/offsite?)
• eg LTO Ultrium 3/4/5
– LTO5 native capacity 1.5TB
(2:1 compression ‘possible’)
• Advantages
– High-capacity, long life (15-30 years archival)
• Disadvantages
– slow (sequential access)
• ie. Backup to a 3rd party over the Internet
• Costs can be attractive
• But… consider
– Size of dataset (and/or, speed of link)
– Replication vs retention
– Speed of recovery (and/or, speed of link!)
– Bare metal restores
• Disk to Disk (backup)
– Fast – during backup window
– Might keep <= 2wks on disk for quick restores
• Disk to tape (duplication)
– Slow – during working hours
– Tapes can then be exported and safely
archived offsite
Scaling it up..
• BackupExec – does not scale as well
• Enterprise solutions
– Eg Netbackup / CommVault
– Better multi-platform support
– Better management of large server numbers
– Additional features (archiving, de-duplication)
– Integration with other products (eg vRanger)
still possible
Other things to consider…
• Large static datasets
– candidate for archiving first?
• Storage of backup data
– Retention periods
– Offsite
– ‘Critical spares’
Other things to consider…
• Remember – a backup is only as good as
the restore
• Backups may sit alongside other
processes such as replication
• Have a DR strategy and test it!