I have been asked by a number of people since joining Veeam about the NetApp Storage Snapshot Support in version 8 of the software. This is the reason for this post to try and outline the Why and the How use cases for the Veeam & NetApp Storage integration.
Firstly I want to go over the process of Veeam and any non storage snapshot enabled array (not supported with Veeam today)
Veeam uses the VMware snapshot technology, when taking a backup we need to ensure that everything is consistent this is either done by using Veeam Application Aware Image Processing which will talk to the VSS directly through a runtime component this then ensures the application is in a quiesced state, at this stage the Veeam backup job can also truncate the application logs, this can also be done after a backup to ensure a successful backup is taken first.
The second option is by using VMware tools for Windows machines, this will perform a file level integration with VSS, there is also an option within Veeam to use pre and post snapshot scripts.
When the above has taken place and the virtual machine is in a consistent state Veeam triggers the VMware snapshot. At this point we have a capture of the virtual machine at that point in time.
To understand the benefits we need to dive a little deeper first. Before the snapshot is created the virtual machine is reading and writing to and from the *.VMDK file of the virtual machine. After the snapshot is taken VMware will create a delta disk. This disk will be tiny in comparison to the VMDK disk to begin with… however for the duration of the snapshot lifetime all virtual machine writes are re directed to this delta disk. Reads will continue to come from the *.VMDK file if the blocks have not been written to since the snapshot.
Very important to note is that VMware snapshots are not transactional, if a block is updated more than once the block in the sparse delta disk will be updated and not taking additional space, this means that the delta can grow to the size of the *.VMDK file.
<ol “margin-left:.375in;direction:ltr;unicode-bidi:embed;=”” margin-top:0in;margin-bottom:0in;font-family:calibri;font-size:11.0pt;=”” font-weight:normal;font-style:normal”=””>
- Ensure via VSS that application and OS is consistent
- Trigger VMware Snapshot
- VMware snapshot created
- Creates delta disk for new writes
For the most part this doesn’t offer too much concern, the window of opportunity for the backup application is to take a copy of that *.VMDK as fast as possible avoiding too many writes to the delta disk because in turn these writes to the data disks need to be committed back to the *.VMDK file. The good thing in the most part is Veeam is also able to make use of the VMware CBT feature (Change Block Tracking) which only changed blocks will need to be backed up since the last backup.
If however you have a Heavy I/O virtual machine, there are potentially two issues you will have to face,
1, snapshots will grow in 16MB extents and every time it does grow it needs to pause IO to the VMFS file system to allocate more space for the *.VMDK file (meta updates.)
2, if you are using thin provisioned VMFS volume, the space will be taken from the containing SAN LUN, however when a snapshot is deleted it doesn’t automatically reclaim the space on the SAN, leaving lots of possible white space on the Storage.
As well as the above because this virtual machine is IO intensive, it probably has changed a lot of blocks, the fact blocks have been changed means the backups could take longer.
How does the Veeam feature of Backup From Storage Snapshots assist in the above instances where you have high IO virtual machines that are transacting a large amount of changes.
Firstly we have to create the storage snapshot first, this is done in the same way but from the storage API and not the VMware console or Veeam console. But because the storage is taking the snapshot this allows us to keep that sparse delta disk for a very short period of time meaning less space taken by new writes and also less time to commit/consolidate back to the *.VMDK file.
The beauty of the Veeam Backup from Storage Snapshots is that Veeam can directly connect to the storage system and read the data. Veeam will still create the sparse delta file but only for 2 mins meaning the benefits I just mentioned.
This generally poses another question are we shifting the workload from the VMware layer down to the storage? No not in the case of NetApp and most other storage vendors for that matter, simply because of the way the storage snapshot technology has been written, NetApp snapshots only point to blocks if the snapshot is deleted there is no need to commit anything back into the volume, the snapshot (pointers) are just removed.
The key to this feature is the taking the time away from lengthy IO virtual machine backups but also taking the load away from your live VMware environment, by using the DirectSAN feature from Veeam you are able to connect to the storage snapshots and utilise the storage snapshots to perform backups rather than hitting the ESXi host.
The above touches on the speed of which we can take our backups and reduce a workload in leveraging the NetApp storage system snapshots. But also we have a number of benefits when it comes to restoring.
Easily recover individual items from NetApp Snapshot, SnapMirror and SnapVault all of these NetApp features are based on the snapshot technology.
With this also in mind we are able to take a second backup and archive off to a second site and leverage NetApp Snapvault. This solution allows you to reach the 3-2-1 rule (3 backups on 2 media types with 1 off site backup) so 3 copies of your data.
