Backup is the only way to protect your data in case of a disaster and to ensure data integrity you should follow the best practices to backup VMware vSphere VMs.
To backup VMware vSphere virtual machines, there are some rules you should follow to be sure that data are properly protected and can be restored in case of a disaster.
Failures, accidental deletion, overwriting, and ransomware are some of the reasons why you should backup your data. Performing a backup is not the only step required to protect your data, but you must ensure that data can be restored, compliant with the 3-2-1 backup rule, ensure that databases have been backed up consistently and so forth.
Best practices to backup VMware vSphere VMs
During the definition of the backup strategy to use, terms like RPO and RTO should be familiar since are the keys for a successful design. Ensure to know how to calculate RTO and reduce downtime with Nakivo.
These are some best practices you should follow for an efficient backup strategy.
3-2-1 backup rule
A good backup design must comply the 3-2-1 backup rule:
- 3 copies of backup - having a single backup is not enough to guarantee data integrity and availability, especially if it stored on a single point of failure component.
- 2 different storage media - storing one backup on a storage, and a copy on tape or cloud ensure protection in case one media fails.
- 1 offsite backup - keeping a copy on a offsite storage or the cloud ensure data availability in case of disaster in the primary site.
When designing your backup infrastructure make sure to follow this simple rule.
Backup
Avoid production infrastructure - backups shouldn't be stored on production infrastructure. Storing backup on same storage used for production does not guarantee the integrity and availability of your data in case of failures.
Snapshots - keep in mind that snapshots are not backups. Too often some administrators think that taking a snapshot is the equivalent of doing a backup. Wrong. Snapshots are not a safe way to protect your data:
- A snapshot resides in the same storage as the production virtual machine. If the VM gets corrupted or the storage fails, the VM is lost.
- VMware best practices recommend to keep snapshots only for a short period of time to avoid performance issues.
- Since a snapshot depends on a chain starting from the parent disk, an individual snapshot cannot be used to restore data without the availability of the base virtual disk.
Image-level backups - backing up just files and folders is not enough to properly backup VMs. An image-level backup can backup not only files and folders but also the entire VM structure to quickly restore the full functionality with a single operation.
Use CBT - Changed Block Tracking (CBT), is a native VMware feature that allows to backup only the blocks that have changed, rather than backing up every block of every VM in the infrastructure. This feature allows to save disk space and requires less time to complete the backup.
Application-aware processing (VSS) and log truncate
Image level backups based on snapshot technology are defined crash-consistent backups since applications that use databases (Active Directory, Exchange, SharePoint, MS-SQL for example) are not properly backed up and they are left in an inconsistent state with the risk of having a corrupted database.
For the supported application is fundamental to enable the application-aware processing (VSS) to ensure databases are backed up in a consistent-state (application-consistent). Nakivo includes the capability to perform DB consistent-backups for the supported applications, such as Active Directory, Exchange, SharePoint, and MS-SQL.
For databases such as MS-SQL, it is also recommended to perform the log truncate to avoid filling the log file causing the block of the database or consuming the entire disk space. Logs are pruned once a successful backup has been taken.
Multiple backup copies
To comply the 3-2-1 backup rule, you should have multiple copies of your backups in case something goes horribly wrong with your primary backup repository or infrastructure.
With Nakivo's Backup Copy feature, copies of your backup can be sent to another backup repository and/or to the cloud.
Offsite copies
Having at least one copy of your backups offsite ensure the protection of your data in case a disaster occurs in the build where your infrastructure is located (hurricanes, land quakes, for example).
Nakivo Backup & Replication supports S3 object storage allowing the administrators to store backup copies directly to cloud environments (S3, S3 compatible) such as AWS and Wasabi.
Verify backups
Taking only the backup of your VMs is not enough to guarantee the data protection. To be sure that all backups are good and protected data can be restored successfully, backups must be verified to assure they are not corrupted.
To check your backups status on regular basis, Nakivo provides the Screenshot Verification feature to verify backups and replicas with the additional capability of sending the screenshot of recovered VMs as a proof.
Immutability - s3 object lock
The Immutability is a feature used to protect your backups against overwriting, accidental deletion, ransomware attacks and internal intruders.
This technology leverages the Object Lock option available during the creation of a new S3 Bucket (AWS or Wasabi) which provides a protection against data deletion or modification from the storage.
In Nakivo Backup & Replication, the Immutability can be enabled to backups during the configuration of a Backup Job.
Encryption
To add an extra layer of security, backups should be encrypted to protect data in case the repository or the used media is stolen.
Encryption is recommended especially if backups are sent to the cloud to keep away unauthorized readers and impossible to decipher when attacked.
Nakivo Backup & Replication uses AES 256 encryption for protecting VM backups providing the ability to encrypt backup repositories so that backup data at rest is secure.
Nakivo Backup & Replication is available to download as 30-day trial.
