Use Case

Users wish to be able to back up their guest instances for recovery purposes should they suffer a hardware or software issue.

The current mechanism which users leverage is the volume snapshot feature as this has the feature set closest to that of a backup regime. i.e. images are stored on alternate location (although this may actually be the same physical array) it can be scheduled and users can set how many backups can be kept.

The volume snapshot mechanism causes a VM snapshot to be taken, then the required volume transferred to secondary storage from a hypervisor host in the cluster within which the VM resides. In the case of VMware, the image is compressed into an OVA by the SSVM.

 

Problems

This transfer can be slow and at times unreliable. Also the user cannot snapshot other volumes attached to the VM during this time, nor perform a number of other BAU operations. Large transfers and concurrency issues can saturate available bandwidth on network or storage.

The requirements for the a feature to fix this problem are:

Must Have

  • Users able to backup whole VM or individual volumes
  • Users able to schedule their backups and keep n versions
  • Users able to restore VM in-place (overwrite existing VM)
  •  Ability for Cloud Operators to leverage hardware capabilities of their respective storage solutions.
  •  Seamless operation of SAN assisted backup vs non-assisted backups

Highly Desirable

  • Users able to restore to alternate location
  • Users able to restore to original location when original VM has been deleted
  • Support for commercial backup software; Rubrik, Veeam, CommVault
  • Support for 3rd Party Backup Solutions (e.g. Amanda)
  • Support for in-guest (client based) backup solutions.

Nice to Have

  • Support for Grandfather, Father, Child backup.
  • User option for storage location
  • Multi-tier archiving of volumes

 

 

  • No labels