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
Article number: 
116066
Last updated: 
September 17, 2019
Service: