Virtualization lets a company run a dozen workloads on a handful of servers, which is exactly why it saves money. It also means that a single failed ESXi host, a corrupted datastore or a ransomware attack can take several business systems down at once. A VMware environment needs a backup plan that is designed for VMware, not one carried over from the days of physical servers.
This guide walks through the three common ways to back up VMware vSphere, the trade-offs of each, and the practices that decide whether you can actually recover when something goes wrong. It draws on NAKIVO's VMware backup guide (NAKIVO is the backup vendor JAI Solution resells), adapted for IT teams and business owners in Thailand.
Three ways to back up VMware
Copying VM files
The simplest approach is to copy a VM's virtual disks (VMDK) and configuration files from the datastore to another location. It needs no software inside the guest, but the VM usually has to be powered off for the copy to be consistent, and you can only restore the whole machine. Getting back a single deleted file means restoring the entire VM first.
Agent-based backup
Here you install a backup agent inside each guest operating system, the same way you would back up a physical server. Teams find it familiar and it can restore individual files. The cost is that every agent uses the VM's CPU and memory during backups, and every new VM needs its own agent installed, configured and kept up to date. With dozens of VMs, that maintenance adds up quickly.
Agentless, host-level backup
Modern VMware backup tools, NAKIVO included, read VM data directly from the ESXi host through VMware's APIs. Nothing is installed in the guests, running VMs do not need to be shut down, and the load on each VM is far lower. Full-VM recovery is fast, and good products can still pull out single files or application items. One limitation: the free edition of ESXi does not expose the APIs this method relies on, so it needs a licensed vSphere edition.
What setting up a VMware backup job involves
With an agentless tool the workflow is short. You add your vCenter Server or ESXi hosts to the backup software and create a backup repository as the destination. Then you create a job: choose the VMs to protect, set the schedule and retention rules, and decide whether the backups should be immutable. Before running it, review options such as application-aware processing, Changed Block Tracking for fast incremental runs, and automatic verification of the backups. The job can then run immediately or wait for its schedule.
Practices that make VMware backups dependable
Match RPO and RTO to each system
Decide for every important system how much recent data you can afford to lose (RPO) and how long it can be down (RTO). An ERP or database server may need backups every hour and a fast restore path, while a test server can be backed up once a day. Setting these targets first stops you from over-protecting minor VMs and under-protecting the ones the business runs on.
Snapshots are not backups
A VMware snapshot depends on the original virtual disk. If that disk or the datastore is damaged, the snapshot goes with it, and long-lived snapshots also slow the VM down and fill up storage. A backup is an independent copy you can use to rebuild the VM somewhere else. For VMs running databases, Active Directory or mail servers, use application-aware backups, which use VMware Tools and Microsoft VSS to put the application in a consistent state before the copy is taken.
Use GFS retention
A grandfather-father-son policy keeps recent restore points close together and older ones further apart. For example, you might keep daily backups for 10 days, weekly ones for two months and monthly ones for two years. You get a fresh copy for everyday mistakes and an older one for problems that go unnoticed for months, without storing every single day forever.
Follow the 3-2-1 rule and tier your storage
Keep three copies of your data, on two different types of storage, with at least one copy off site. In practice, the most recent backups sit on fast local storage for quick restores, a second copy goes to slower disk or the cloud, and older copies move to tape or low-cost cloud storage. If the whole server room is lost, the off-site copy is what you rebuild from.
Protect at least one copy with immutability
Ransomware operators look for backups and delete or encrypt them before they encrypt production systems. Keep at least one backup copy on storage that supports immutability, also called WORM (write once, read many): an object-lock cloud bucket, a hardened local repository, or tape. Until the retention period ends, nobody can change or delete that copy, including an attacker who has stolen an administrator password.
Pick an efficient transport mode
Backing up over the regular network can be slow and can affect users. Where the infrastructure supports it, LAN-free backup directly over the SAN (Fibre Channel or iSCSI), or the Hot Add method that mounts disks to a backup appliance VM, keeps backup traffic off the production network and shortens the backup window for large VMs.
Automate the routine
Manual backups get forgotten. Schedule jobs, stagger them so they do not compete for the same storage, and use the software's API or integrations to fit backups into existing processes. Automated reports showing which jobs succeeded and which failed are better than discovering a gap during an emergency.
Test restores regularly
A backup you have never restored is only an assumption. Restore real VMs and files on a regular schedule to prove the process works and to learn how long it takes. Many current tools can boot a backed-up VM automatically, take a screenshot of the running OS as proof, and email you the result, which takes most of the manual effort out of testing.
Monitor the environment
Use monitoring that shows the health of hosts, datastores and backup jobs in one place, with alerts for failed jobs and storage running low. Small warnings caught early, such as a job that has been failing quietly for a week, are much cheaper than surprises during a recovery.
Keep the backup software updated
Backup servers have broad access to your infrastructure, which makes them a target. Updates close security holes, add support for new vSphere versions and fix bugs. Leaving the backup system unpatched is a risk that is easy to overlook because the system is rarely in front of anyone.
Summary
A reliable VMware backup comes from three decisions more than from any single product: clear RPO and RTO targets for each system, backups that follow the 3-2-1 rule with at least one immutable copy, and restores that are tested on a schedule. If you cannot yet answer all three for your own environment, that is the place to start, before an incident forces the question.
Source
Written by the JAI Solution team based on NAKIVO's guide VMware Backup Guide: Methods and Best Practices, which has more technical detail on each method.