4 Common Mistakes to Avoid When Backing up VMs

Backing up virtual environments has its challenges

The growing interest in virtualization and building a data center based on new opportunities create new challenges for the data protection market. Both infrastructure providers and virtual machine backup developers strive for the same:

• simplification of management
• processes automation
• saving time and resources
• increased reliability.

Backing up virtual environments has its challenges. It is worth familiarizing yourself with a few key topics to avoid common errors related to snapshots, replication, backup schedules, and differences between agent and agent-less backup to create solid and useful backups of virtual machines.

It is worth noting that even the best virtual machine backup software will not give us much in the event of a disaster if we misunderstand the essence of backup. But let’s start by making sure that the backup application benefits from the many benefits of a virtualization architecture and meets your needs. If this point is clear – let’s go further.

Here are some key issues to look out for:

Virtual machine snapshots are not backups

One of the most common mistakes is treating snapshots as an equivalent for backup. Virtual machine snapshots perceives the state of the virtual machine from the moment the snapshot was taken. Of course, this is very useful functionality, but even snapshots need to be backed up. Why?

Snapshots are useful as an additional backup method for short-term or ad hoc backups if you need to restore previous state of VM, such as when applying patches or updating applications. But if there is a problem with your infrastructure – also your snapshots can be corrupted. If the storage system, or even the volume on which the snapshot is based, fails, all the backup snapshots associated with that system or volume are useless.

Backup allows you to replicate data snapshots to another system so they are stored in another repository.

Snapshots also have other limitations. Usually, they are not useful for restoring individual files because they only restore the entire virtual machine image to its current state. However, if you use a proper backup tool, like vProtect, it is possible to restore even individual files.

We do not deny its validity here – it is a nice feature, useful in some situations. However, it should never be used as the primary method for backing up virtual machines. You only need to use it consciously. One more thing to keep in mind – impact on performance.

Problem with virtual machine snapshots is that creating too many snapshots (this is often an automatic process, and its frequency is set by the user) can reduce the performance of virtual machines in anticipation of unblocking LUNs. Also, each snapshot is a separate file that grows as you save data, and running multiple snapshots can cause your data stores to run out of disk space.

Replications 

Replication is an exact copy of the main data center. If a disaster hits one – you can continue working using his twin. Although this solution seems very interesting for your Disaster Recovery plan at first glance, it has some cons to keep in mind.

Replication is not a backup – although both backup and replication are essentially ways to backup data, there is a major difference. Replication is a single copy of data, not a versioning copy. A backup is a copy of a version that captures your system and its history.

Errors are also replicated – because replication is usually a continuous process, any problems in the base copy will also be replicated. This includes any corruption or accidental deletion or even duplication of infected files.

Costs of maintaining the second, twin infrastructure – require investment in additional infrastructure to enable recovery and business continuity.

Plan your backups carefully

If your backup software does not have settings that allow you to control the number of simultaneous operations, you should carefully plan your backups.

Limit the number of simultaneous backups of virtual machines on the host and shared data stores. Among other things, because virtual machines share host resources and hosts share memory devices. Plan your backup schedules to ensure that your backups are done in a sustainable manner that will not cause resource problems for virtual machines. Bottlenecks for all virtual machines on the host also appear if you are backing up too many virtual machines on the same host.

Everything, of course, can be seen on the statistics available in the administrator console.

Understand the differences between agent-based and agentless backup

Virtualization is increasingly replacing the physical data center. This change also favors lightweight, agent-less backup solutions, instead of requiring time-consuming management of agent-based ones. Thus, the main criteria that support paying attention to agent-less solutions are cost and efficiency. Here are just a few examples.

Agents generate CPU load and consume memory on the VM to read, processing, and write operations. That’s why the backup process can only be started during “backup windows” when the application is to be idle.

In addition, the agent does not understand that it is in a virtual machine so when you want to restore data, you need to create the appropriate virtual machine and only then initiate the recovery process. Instead of using backup agents on the guest operating system, backup servers should go directly to the virtualization layer and not include the guest operating system. To properly back up an image at the virtualization layer, you need to use backup applications that are aware of virtualization and can use the virtualization layer APIs to access virtual disk files.

Modern solutions for data backup and restore, such as vProtect, have all the necessary functions to perform tasks related to data protection following good practices.