{"id":6825,"date":"2021-05-17T22:09:11","date_gmt":"2021-05-17T20:09:11","guid":{"rendered":"https:\/\/tekmart.co.za\/t-blog\/?p=6825"},"modified":"2021-05-17T22:09:13","modified_gmt":"2021-05-17T20:09:13","slug":"vmware-backup-and-the-vmware-snapshot","status":"publish","type":"post","link":"https:\/\/tekmart.co.za\/t-blog\/vmware-backup-and-the-vmware-snapshot\/","title":{"rendered":"VMware backup and the VMware snapshot"},"content":{"rendered":"Reading Time-approximately:<\/span> 5<\/span> minutes<\/span><\/span>\n

The VMware snapshot is a critical component of VMware backup. In this guide to the basics of VMware backup, we walk you through the key processes and suggest some best practices.<\/strong><\/h2>\n\n\n\n

By Michelle Laverick<\/a><\/p>\n\n\n\n

Server virtualisation introduces a radically different approach to backing up data in the enterprise than simply using backup agents installed in the guest operating system and\u00a0backing up VMs\u00a0across the network: VM-aware backup technologies.<\/p>\n\n\n\n

If your virtualisation environment is growing exponentially, you\u2019ll soon begin to notice the CPU, disk and network hit if you don\u2019t quickly move over to such a technology.<\/p><\/blockquote><\/figure>\n\n\n\n

But, it\u2019s critical that you understand the role of the\u00a0VMware snapshot\u00a0and how\u00a0VM backup and restore works\u00a0before parting with your budget. In particular, you will want to ensure that VM-based backup offers the same level of granularity as your legacy backup system.<\/p>\n\n\n\n

Early\u00a0VMware backup\u00a0products were very good at backing up but somewhat lacking in flexibility when it came to the restore process. Sadly, our industry has got the whole issue the wrong way round. Backup software should be called restore software, because that\u2019s what customers buy it for.<\/p>\n\n\n\n

Basic operation<\/strong><\/h3>\n\n\n\n

Many vendors\u2019 VM backup products use the same methods and\u00a0APIs\u00a0for backing up VMs. The process begins with the backup software taking a VMware snapshot of the VM. This performs two main tasks.<\/p>\n\n\n\n

First, it triggers the\u00a0quiescing\u00a0of the VM and flushes the disk contents out of the file system cache. This leverages both the OS and application versions of Microsoft\u00a0Volume Shadow Copy Service (VSS)<\/a> that ensure files that may be locked and in use inside Windows are released in such a way that a full backup is more likely to happen. The snapshot is exactly the same as those available from the vSphere Client that can be taken manually by the VMware admin.<\/p>\n\n\n\n

Second, the VMware snapshot unlocks the files that make up a VM from the file system. When a snapshot is engaged, each virtual disk receives a snapshot\u00a0delta\u00a0\u00a0file (you will find it is called something like \u201cvmname<\/em>-00001.vmdk\u201d). From this point onwards, all disk changes accrue in the delta files, which grow in increments of 16 MB. This leaves the files that make up the VM, such as the VM\u2019s configuration file (VMX) and, critically, the virtual disk files (VMDK), free to be archived.<\/p>\n\n\n\n

Without the VMware snapshot engaged, the files would be locked by the ESX server that \u201cowns\u201d that VM when it is powered on. The situation is similar to when you try to copy or move a file that\u2019s already open in an application.<\/p>\n\n\n\n

Delta file size and removal of snapshots<\/strong><\/h3>\n\n\n\n

As you can probably guess, there are a\u00a0number of challenges associated\u00a0with the use of VMware snapshots. The longer the snapshot is engaged, the larger the delta files that make up a VMware snapshot can be — relative to the rate of \u201cchurn\u201d on your data. This can have implications for available free space on the volume where the snapshots reside and also a potential performance hit, dependent again on the rate of data churn and type of storage deployed. For example,\u00a0RAID-enabled SSD\u00a0or SAS drives will outperform SATA volumes in most cases.<\/p>\n\n\n\n

However, your main concern with VMware snapshots is how your backup vendor handles their removal. Once the backup job has completed, an instruction is normally sent to either vCenter or directly to the ESX servers to remove the VMware snapshot from the VMs. Assuming that communication to these nodes is available at that time, a failure to communicate from the backup system to the management layer of vSphere can result in \u201corphaned\u201d VMware snapshots left behind after the backup job completed.<\/p><\/blockquote>\n\n\n\n

A good backup product will at least log and\u00a0alert\u00a0the VMware admin to this fact, and the better ones will cycle through a garbage collection process to remove them at the earliest opportunity or when the next backup runs. There are many a sorry tale to be heard from VMware admins who have found a VMware snapshot file has grown so large that it fills a volume or a LUN.<\/p>\n\n\n\n

Restoration<\/strong><\/h3>\n\n\n\n

Another important feature is how the backup product goes about restoring files. In the early days of VM backup, many vendors merely mounted the virtual disks that made up the backup to their management system and left it to the VMware admin to copy files around using Window\u2019s hidden \u201cdollar\u201d shares, such as C$ and admin$. That\u2019s hardly approaching the sophisticated use of backup agents that intelligently restore files to the same or different locations.<\/p>\n\n\n\n

Fortunately, things have improved in recent years. There are two methods that most vendors support. In the first method, the backed-up VMDK files are taken from a shared location accessible to the ESX hosts and \u201chot-added\u201d to the VM to which they need to be recovered.<\/p>\n\n\n\n

The result is that the VM \u201cmagically\u201d has a new drive added to it whilst it is powered on. This appears as new X drive or Y drive, for example, and this allows the application owner of the VM to restore files using Windows Explorer.<\/strong><\/p><\/blockquote>\n\n\n\n

Secondly, if the entire VM has been lost, many vendors allow for a temporary VM to be started using the files that have been backed up. Once booted and in use on the network, the VMware admin can use\u00a0Storage vMotion\u00a0to relocate the restored VM to its rightful location.<\/p>\n\n\n\n

These two methods of restoring VMs are infinitely more sophisticated than copying files using Microsoft\u2019s CIFS protocol. You should ensure that your chosen backup vendor supports at least one of these methodologies.<\/p>\n\n\n\n

Scalable recovery<\/strong><\/h3>\n\n\n\n

Of course, backup shouldn\u2019t be your only strategy when it comes to data protection. While it\u2019s true that 99% of all recoveries are of relatively small amounts of end-user data, there are situations that require a more robust and scalable recovery strategy than backups allow on their own.<\/p>\n\n\n\n

What if you have very large VMs that hold terabytes of data? What if the storage array suffered a major outage? What if a storage admin took a LUN used by VMs offline and deleted it? All of these possibilities for data loss all share the same attribute: terrifying amounts of data lost in seconds. Attempting to recover this amount of data even with disk-to-disk backups could take hours or days depending on the volume of data and your maximum restore throughput.  <\/p>\n\n\n\n

For this reason, you really need to consider a cycle of snapshots driven by your storage vendor\u2019s array technology. The storage vendor snapshot offers your environment an enormous Undo button for your volumes and LUNs. This can be incredibly helpful if a couple of VMs get accidentally deleted or destroyed. The history of previous snapshots is available, and these can be presented to the ESX hosts and mounted by them directly from the storage layer.<\/p>\n\n\n\n

It\u2019s like having a Recycle Bin for VMs, for gigabytes or terabytes of data. Storage vendors such as Dell, EMC and NetApp now have tools that integrate directly with the vCenter system to facilitate this recovery process without the need to understand the storage management tools or speak to the storage admins.<\/p>\n\n\n\n

Storage vendor snapshots also form the basis of most storage vendors\u2019 replication technologies. This should also be one of the linchpins of your data recovery strategy. The single point of failure of virtualisation is often the storage array. All VMs are stored on it and it is central to virtualisation\u2019s advanced features such as vMotion, High Availability (HA), Distributed Resource Scheduler (DRS), Distributed Power Management (DPM), Fault Tolerance (FT) and maintenance mode.<\/p><\/blockquote>\n\n\n\n

Without some kind of centralised storage array, most virtualisation projects are hobbled from the get-go. At the same time, however, with a storage array, VMs become eggs stored in the proverbial basket.<\/p>\n\n\n\n

There are two ways to approach this risk — if maximum availability is required, most storage vendors have their own \u201ccontinuous availability\u201d models, where two arrays are kept at the same state using synchronous replication.  If one of the storage arrays goes down, the standby array takes the place of the primary.<\/p>\n\n\n\n

Sadly, this can be an expensive option. What\u2019s more viable is stretching out this replication between two arrays within a site to include another storage array in a different site. This gives the option to fail over if you lose the array and at the same time gives the business protection from the ultimate form of data loss: loss of an entire site.<\/p>\n","protected":false},"excerpt":{"rendered":"

Reading Time-approximately:<\/span> 5<\/span> minutes<\/span><\/span>The VMware snapshot is a critical component of VMware backup. In this guide to the basics of VMware backup, we walk you through the key processes and suggest some best practices. By Michelle Laverick Server virtualisation introduces a radically different approach to backing up data in the enterprise than simply using backup agents installed in the guest operating system and\u00a0backing<\/p>\n

Read More<\/a><\/p>\n","protected":false},"author":113,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[155,38,106,35,258,4,30,3,238,95,52,105],"tags":[],"class_list":["post-6825","post","type-post","status-publish","format-standard","hentry","category-batting-for-tech-in-the-covid-19-times","category-best-practices-for-data-center-operations","category-creating-and-upgrading-vmware-servers-and-vms","category-data-center-facilities","category-data-protection-backup-and-archiving","category-datacenter-news","category-expert-advise-and-opinion","category-industry-news-and-expert-advise","category-timeless-articles","category-timeless-tips","category-vmware-esx-and-esxi-administration","category-vmware-products"],"_links":{"self":[{"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/posts\/6825","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/users\/113"}],"replies":[{"embeddable":true,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/comments?post=6825"}],"version-history":[{"count":1,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/posts\/6825\/revisions"}],"predecessor-version":[{"id":6826,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/posts\/6825\/revisions\/6826"}],"wp:attachment":[{"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/media?parent=6825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/categories?post=6825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tekmart.co.za\/t-blog\/wp-json\/wp\/v2\/tags?post=6825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}