Creating backups for virtual environments can be an easy task. But, there are some common mistakes that need to be avoided by users when backing up the virtual environments.
In this blog, we will mainly discuss the mistakes to avoid while backing up VMware environment along with some general things that one should not do while performing the virtual machine backup.
Some of the mistakes are in general for all hypervisors, not just VMware, since users tend to make the same mistakes when backing up other virtual environments too.
Let us try to enumerate the most important mistakes that users and customers always do when backing up their virtual environments.
1 – Since I work with virtual backups, the most common and top mistake for new users is they handle a virtual backup like physical backups. Today with Virtual Environments, spreading in companies we see less this behavior, but for customers that are migrating from physical to virtual environments, this mistake continues to be the first mistake that they make. Customers are still trying to handle, or plan their backup in the same way they plan for their physical infrastructure.
How physical backups work?
Backup agents are installed inside each physical machine and backups are processed at file-level. Whereas, backup of virtual machines need to be processed using Agentless Backup method at image-level with/without application-aware inside the Guest OS.
One of the first rules for virtual backups, backup agents are not recommended. It is right for VMware environments, also for Hyper-V (In previous Hyper-V, this rule needs to be bypass because of the specifications of how Hyper-V works. However, most recent Hyper-V versions there is no need for agents).
So if possible, always use software backup tools that offer the agentless backup solution for virtual environment. Backups should always be processed through the hypervisor (through vCenter or through ESXi host) to guest OS and must be processed at image-level backup and not an at file-level backup as agent-based method works.
When selecting a backup tool for your virtual environment always avoid virtual backup tools that use agents inside guest OS to perform backup. Those type of backup software is suitable only for physical backups and can only backup virtual machines using agents inside each guest OS. Backup software for Virtual Environments, like Vembu, offers Agentless Backup and is most suitable to backup your VMware environment.
2 – Another top mistake is the use of Snapshots as backups. I can’t count how many times I had this discussion with customers regarding this subject and tried to explain the difference between a backup and snapshots.
Perpetual snapshots can cause severe performance issues on the host and Storage layer and could end into data loss. Recommendations from VMware for snapshots is 48h. For many customers, this is not suitable, but for large disks and production environments VMs, you should always try to follow this 48h rule.
A snapshot preserves a specific point in time of your VM and data and records delta changes from a particular point in time.
A backup is a copy of your Virtual Machine (image-level or file –level) that is independent of your Hypervisor where was created(unlike snapshots).
You should have a script or a 3rd party tool, to scan your Virtual Environment for any perpetual snapshots and delete them, or inform users to delete the snapshots. For special requests non-production (like testing environments and development) and smaller, medium Virtual Machines, I have a rule of 1 week for the maximum of snapshots can exist.
Virtual Backups tools create and use snapshots to create a backup (on VMware layer, or at Storage layer) and copy the data, but deletes the snapshot after the backup is finished (except on Storage Backups since they work differently). With snapshots, you cannot perform granular restores.
Is essential to take track of snapshots created by Backup Tools. Sometimes those snapshots are not correctly deleted after the backup has finished. Those “phantom” snapshots can also have a significant impact on your VMs performance. I had to fix VMs with more than one hundred snapshots left behind by Backups.
Always avoid using Snapshots as backups and use a proper Software Backup tool to backup your VMware environment.
3 – Backing up of applications without App-aware is also a mistake that many users do when planning to backup their VMware infrastructure. For Domain Controllers, Databases or email Servers – application aware process is essential. These are the type of applications that require transactional consistency using Microsoft VSS, and application-awareness should always be enabled.
Ordinarily, virtual backups process backup at the image level, and are not aware of any applications, or files, inside the Guest OS. Before backup starts, backup tool needs to quiesce the application writers so that application backup is in a consistent state. If not, your backup may have data that is not consistent and not in the state that can adequately be restored. This is the reason why it is very important to have applications-aware enabled for this type of Virtual Machines.
When you restore your virtual machine and consequently your applications, with application-awareness, you can always be sure that you have a non-corrupted and valid backup to restore.
4 – Backup virtual machines without VMware tools installed. Even this is not mandatory but is essential for a good backup. Primarily if you are using application-awareness backups.
This mistake is a follow-up to the previous mistake. To have application-awareness and to quiesce the Virtual Machine state, you need VMware Tools installed.
One of the VMware best practice is, all Virtual Machines should have an updated VMware Tools installed. But, backups can also be improved by using VMware Tools drivers.
5 – Another mistake and bad planning is, when users backup many VMs at the same time. Many concurrent backups jobs stress your ESXi hosts, Network, and Storage and reduce the performance of your VMware environment drastically using a lot of your VMware infrastructure resources.
Besides the performance degradation, backup jobs take longer time to complete, also some could not finish successfully because of the time-out or network issues. Snapshots could not be created or deleted at the end of the backup.
Always plan your backup jobs so that your environment doesn’t suffer performance degradation. The number of concurrent jobs, it always depends on your environment. So understand your VMware Infrastructure and create a backup plan before starting the backup schedule to avoid faulty backups and performance degradation.
6 – Another mistake is, not verifying backups. Always ensure that backup verification tests are performed. During restoration, if the required data is corrupted or missing, then the backup cannot be restored. Thus, checks on data integrity are mandatory for data recoverability to ensure business continuity. It also suits for VMware Virtual Backups.
Users should always perform a backup verification after the backup schedule. Vembu BDR uses a three-tier verification of your backup. It runs integrity tests on Boot check, Mount check and Integrity check. Ensures virtual machine data restoration and booting of Guest OS. With this tests, Vembu assures verified data recoverability after a disaster.
7 – Encrypted backups could not be at the top of the mistakes, but still is a subject that users and companies should take into account very seriously.
Data theft and ransomware are at the top of actions that were known in the last years. The ransomware hackers can attack not only your VMware Infrastructure but also your backups.
To secure your data Vembu BDR uses End-to-End Encryption (E2EE) and AES-256 algorithm to encrypt and decrypt the data over internet and storage repositories locations. Check here to check Vembu options to encrypt your data backups.
Another option is encryption at virtual machine level before the backups. In VMware 6.5 made significant improvements in this area, and Virtual Machine can be encrypted. If data protection and privacy are critical for your company, use it and encrypt your data at Hypervisor level, but also at backup level. Applying an extra level of encryption gives you extra security to protect your data from hackers, intruders, and criminals.
8 – Change block tracking (CBT) disabled is a subject that we could not fit in this top mistakes, but in my opinion is a critical one.
There were some issues in the past regarding VMware CBT, and the solution was to disable this feature so that backups could finish and we have data consistency.
As you know CBT is a feature that backup tools use to track the data that has been changed since the last backup and performs block-level backup/replication for the incremental job. When the process doesn’t know the last changes, the backup job starts a full backup, then you would have a space problem at storage repository at some point in time.
9 – Last is the backup of VMware vCenter Server Appliance (VCSA). Don’t want to finish this article without referring to this mistake that should be avoided. Just adding your vCenter appliance to a backup job and backing up the vCenter is not a good practice. Please read best practices from VMware how to Backup and Restore a vCenter Server Environment using image-based.
You could also read how to correctly manually backup and restore your VCSA in this Vembu blog post by Xavier Avrillier
Conclusion
Most of the above mistakes should be avoided to make your backups safer and process the VMware backup easier with better performance.
We could list more mistakes, but in my opinion the above are some of the most important points that you should think about when planning to backup your VMware Infrastructure.
The aforementioned mistakes to avoid while configuring backups fits for VMware virtual backups, and also for other virtual environment backups. Because these are general best practices that one should always follow in backup.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
