Backup and Recovery of Virtual Servers
There are several different backup/recovery options depending on several aspects of the virtual server (VM):
- virtual server type
- guest operating system (OS)
- storage placement
- application/workload
- specific customer requirements
Important Notes
You may need to contact your SST primary/secondary server admins or the Virtualization Team to confirm which methods apply to a specific VM.
Restores must be performed by SST (for Co-Location VMs, see below).
Backup/Recovery Methods
Depending on the factors above, the following backup/recovery options may be available. Restrictions on each option are detailed in subsequent sections.
- NetApp NAS volume snapshots (NetApp)
- array-level point-in-time snapshot of volumes containing virtual disk images
- crash-consistent (server apps or I/O are not suspended)
- recovery is replacement of the current VM disk(s) with the copy from the snapshot
- snapshots are replicated to another data center for additional protection
- standard schedule/retention
- daily at noon - retained for 6 days
- daily at midnight - retained for 14 days
- Sunday at midnight - retained for 5 weeks
- IBM Tivoli Storage Manager (TSM)
- file-level backup using agent installed in the VM
- active content (e.g. database files) may not be usefully recoverable without additional steps
- file-level recovery (some file systems may be excluded - see SST admin for details)
- backups are replicated to another data center for additional protection
- standard schedule/retention
- nightly between 8 PM and 4 AM (randomized start times)
- file version existing on system at backup time ("active") kept indefinitely
- previous version marked "inactive" when file on system is changed and backed up again
- files deleted from system marked "inactive" (with no new "active" version)
- "inactive" file versions retained based on number of versions and length of time inactive
- Windows default: 7 "inactive" versions for up to 30 days (180 days for last "inactive" version)
- Linux default: 2 "inactive" versions for up to 30 days (60 days for last "inactive" version)
- Microsoft DPM
- For Windows System State backup and recovery (typical on SCCM or Domain Controllers only)
- backups are replicated to Azure Storage for additional protection
- standard schedule/retention
- Daily backups between 4 PM and 9AM
- 7 days on-prem backups
- 30 days of off-prem Azure backups
- VM snapshot/checkpoint
- not a traditional backup -- useful for rollback in case of problems with planned/scheduled work on the VM
- Not crash-consistent unless VM is shut down first
- manually created by SST staff on customer request
- limited retention (recommend <2 weeks)
Availability of Methods
Virtual Server Type
The type of virtual server can limit which backup/recovery options are available.
- ITS-Managed
- no restrictions based on type
- ITS-Secure
- no NetApp snapshots available
- Co-Managed
- no restrictions based on type
- Co-Location
- only NetApp snapshots available from ITS
- customer is otherwise responsible for any backups and restores
Guest Operating System & Application/Workload
The OS and application or workload in the VM can impact which options are available.
- Any OS
- work with your SST primary/secondary server admins or the Virtualization Team to plan for particular backup/recovery needs (e.g. database or other active content, very large disks or file counts, data to be excluded, etc.)
- Microsoft Windows
- OS drive (C:, sometimes E:) typically only use NetApp snapshots unless they are unavailable due to other factors
- large data drives (excluding SQL Server) typically use TSM backups, but may also use NetApp snapshots if available
- DPM typically only used if NetApp snapshots are unavailable
- NetApp snapshots and TSM file backups should not be relied on for SQL Server -- work with SST and the ITS-AIS Data Platforms and Architecture (DBA) group for reliable SQL Server backups
- Linux (RHEL/CentOS)
- NetApp snapshots and TSM file backups should not be directly relied on for active content backups, e.g. MySQL/MariaDB, PostgreSQL, etc. -- work with SST to accommodate these needs
- DPM backups do not apply
- Linux (Other)
- work with SST to identify options and limitations
- Other (e.g. virtual appliances)
- work with SST to identify options and limitations
Storage Placement
The underlying storage where the VM and its disks are placed affect which backup/recovery options are available. A VM might consume multiple types of underlying storage. Contact your SST primary/secondary server admins or the Virtualization Team for storage details of a particular VM.
- NetApp NAS
- not available on ITS-Secure VMs
- certain NetApp volumes are configured without snapshots
- Dell EMC SAN
- not available on Co-Managed or Co-Location VM types
- TSM and/or DPM must be used if backups are needed
- VM snapshots are not available for VMware RDM disks
- Dell EqualLogic iSCSI (connected in-guest)
- TSM and/or DPM must be used if backups are needed