The SimpliVity Data Virtualization Platform (DVP) provides native data protection including policy based backup, replication, and recovery. The backup policy engine and the backup catalog are part of the SimpliVity DVP. We are able to easily provide a data protection solution which aligns with a traditional and proven 3-2-1 Backup Strategy: 3 copies, 2 independent media sets, and 1 off-site copy.
Here is an example of a simple SimpliVity backup policy:
In this policy there are two rules: the first rule creates a backup every 4 hours, retains the backup for 7 days, and stores the backup in the Raleigh Datacenter; the second rule creates a backup every 4 hours, retains the backup for 14 days, and stores the backup in the Tampa Datacenter. Each SimpliVity backup policy can be configured with up to 16 rules. So if we also wanted to take a backup every Sunday which we retain for 1 year, we can simply create another rule. If we want to replicate a monthly backup to another datacenter which we retain for 7 years, just create another rule. Backup policies are VM-centric, this allows for a policy to be applied directly to a VM based on that VM’s RPO.
So what happens when we take a SimpliVity backup and how can we claim to follow the 3-2-1 strategy?
The SimpliVity Data Virtualization Platform (DVP) which is comprised of the SimpliVity File System and Object Store (SVTFS) enables the efficient storage and protection of data by deduplicating, compressing, and optimizing all data, at inception, once and forever, across all tiers, and across all sites. A deeper dive into the SVTFS and how it deduplicates and protects data can be found in Ron Singler’s (@rsingler_) post Deduplication, You Must Unlearn What you Have Learned (Definitely worth a read).
First things first, SimpliVity backups are NOT snapshots. A snapshot has some dependency on the original. Snapshots are deltas of the original and maintain a dependency on the original, when the original VM is deleted the snapshots are useless for recovery. A SimpliVity backup of a VM is a full, completely independent (independent is the keyword here and one which will be repeated often throughout this post), copy of the references to data stored on disk (the VM’s metadata – this metadata is an abstraction of the physical dataset – again unlearn what you have learned). The physical data set is protected within the node and across nodes within the same logical datacenter. Data which is needed for a virtual machine is not removed from a datacenter until all references to the data are removed, this includes the primary and any backups.
A properly designed SimpliVity Federation can easily have 3 or more independent copies of data across independent sets of media. A backup can be stored on 2 or more separate standalone independent disk subsystems, managed by separate independent controllers, with separate independent metadata indexes, across multiple sites.
Here is a simple example of a SimpliVity Federation comprised of two datacenters:
When we take a local backup (manual or policy based) of VM2 in the Primary Datacenter we create a full independent copy of the object across two independent nodes in the datacenter. The data for the VM already exist in the physical dataset so we do not need to recreate any of the data for the point-in-time in which we take the backup. No IO or capacity is consumed but we do have 2 independent, point-in-time copies, of the data across two nodes in the Primary Datacenter.
When we backup VM2 and replicate the backup to the Remote Datacenter, the same process happens. A point-in-time independent copy of the VM’s metadata is transferred to the Remote Datacenter. The SimpliVity DVP is globally aware of all data in the environment and only the unique data required for the backup is transferred between the sites (In this case VM2 requires blocks B and C, the remote site already has block C so only block B is transferred). That data is protected within the node at the Remote Datacenter and if the Remote Datacenter has multiple SimpliVity nodes the data is protected across nodes.
We now have two copies of the backup in the Production Datacenter and one copy of the backup in the Remote Datacenter. The VM is independently protected across two nodes in the Primary Datacenter with an independent offsite backup in the Remote Datacenter.
So what happens when we have to restore a VM?
The process is very similar to a backup, we create an independent copy from the backup and present it up through the DVP, to the datastore, and into the hypervisor inventory as a virtual machine. Since the restore is also an independent copy the original point-in-time independent backup is not modified.
Delete the source VM and we can quickly restore it from a local backup. Delete the source VM and have a node failure at the same time, we can still quickly restore the VM from a local backup. Delete the source VM and have the entire site fail, we can quickly restore the VM to the remote site.
Three independent copies of the virtual machine, across more than 2 independent media sets, with one independent copy stored off-site.
You can use traditional backup Software to Backup VMs to Disk or Tape.
The throughput on non Flull Flash Systems ( e.g. the original 300 or 5000 series ) is slow, so you can’t stream directly to LTO, but need to to a Backup to Disk first.
As I understand/interpret the 3-2-1 strategy, the 2 represents media TYPES not media sets. In the example above, I see a 3-1-1 strategy because you are using DVP for all your media. If there was a bug or malware that impacted DVP you lack a recovery option. You would need to incorporate a copy to tape or cloud to protect your data with a 2nd media type.
is there a way to give some one access to backups (kind of like a backup admin) but not give access to other Simplivity functions. For example, we create a sudo admin account that can create VMs and do basic VMWare functions but we locked down permissions so they couldn’t touch the smoke and mirrors Simplivity is doing (for example keeping them from messing with the omicubes). But we want them to be able to see backups and restore them. Anyway to unlock that function without giving away the farm?
Hello! What about offsite / offline backups, for example can I target a traditional NAS or something like S3, Glacier, etc.?
You can use traditional backup Software to Backup VMs to Disk or Tape.
The throughput on non Flull Flash Systems ( e.g. the original 300 or 5000 series ) is slow, so you can’t stream directly to LTO, but need to to a Backup to Disk first.
As I understand/interpret the 3-2-1 strategy, the 2 represents media TYPES not media sets. In the example above, I see a 3-1-1 strategy because you are using DVP for all your media. If there was a bug or malware that impacted DVP you lack a recovery option. You would need to incorporate a copy to tape or cloud to protect your data with a 2nd media type.
is there a way to give some one access to backups (kind of like a backup admin) but not give access to other Simplivity functions. For example, we create a sudo admin account that can create VMs and do basic VMWare functions but we locked down permissions so they couldn’t touch the smoke and mirrors Simplivity is doing (for example keeping them from messing with the omicubes). But we want them to be able to see backups and restore them. Anyway to unlock that function without giving away the farm?