The best way to protect virtual machines is to run image-level, application-aware backups on a schedule tied to your recovery objectives. Keep several copies, with at least one offline or immutable and stored away from production. Then test restores on a routine until you know how long recovery really takes. Everything below explains how to do each of those things and where businesses most often go wrong.
This guide is written for IT managers and business owners who run VMware or Hyper-V, or virtual machines in the cloud, and who need backups that hold up on the worst day, not just backups that report "success."
TL;DR
- Back up at the virtualization layer with image-level, application-aware jobs, so databases and directory services come back consistent.
- Follow 3-2-1 at a minimum: three copies, two media types, one offsite. Keep at least one copy offline or immutable to survive ransomware.
- Snapshots are short-term rollback points. They never replace a formal backup.
- Set frequency from your RPO and change rate, and set retention from business and regulatory needs.
- A green backup report proves little. Test restores in an isolated network and check that applications work.
Table of Contents
- Start with recovery goals, not backup tools
- Back up at the hypervisor layer, not inside each guest
- Make backups application-aware for live servers
- Do not treat snapshots as backups
- Keep multiple copies, and keep one out of reach
- Harden the backup environment itself
- Set frequency, retention and timing deliberately
- Test restores, not just backup jobs
- Monitor and alert on every job
- Perspective: what we see in the field
- How Secure Techies can help
- FAQ
- Sources
Start with recovery goals, not backup tools
Before choosing software, schedules or storage, decide what "recovered" means for each workload. Two numbers drive every other decision:
- RPO (recovery point objective): how much data you can afford to lose, measured in time. An RPO of one hour means you need a restore point at least every hour.
- RTO (recovery time objective): how long the business can be without the system before the damage becomes unacceptable.
Microsoft's cloud security benchmark tells organizations to align backup frequency with data change rates and RPO, and to align retention with business and regulatory needs. It gives a simple illustration: hourly backups for high-transaction databases and daily backups for less frequently changing data. The same page recommends automating backups for business-critical resources, protecting and monitoring the backups, and regularly testing recovery.
A practical way to apply this is to sort your virtual machines into tiers:
| Tier | Typical workloads | Suggested approach |
|---|---|---|
| Tier 1 | SQL Server, line-of-business apps, email, domain controllers | Frequent application-aware backups, offsite and offline copies, quarterly restore tests |
| Tier 2 | File servers, internal web apps, print and licensing servers | Daily image-level backups, offsite copy, semiannual restore tests |
| Tier 3 | Test, development and rarely changed systems | Daily or weekly backups, shorter retention |
The tiers are a planning aid, not a standard. Your own RPO and RTO conversations with department heads should set the numbers. If a mortgage company cannot tolerate losing more than an hour of loan-system data, that system belongs in Tier 1 regardless of how small the VM is.
We cover the testing side of these targets in more depth in our guide to proving RTO and RPO through disaster recovery testing.
Back up at the hypervisor layer, not inside each guest
Installing a backup agent inside every guest operating system works, but it consumes CPU, memory and disk I/O on the machine you are trying to protect, and it multiplies the number of agents you must patch and monitor. For VMware, TechTarget's vSphere guidance recommends backing up VMs at the virtualization layer with image-level backups so that guest resources are not drained by the backup process.
Image-level backups capture the whole machine: operating system, configuration, applications and data. That matters at restore time. You can bring back a complete server to a new host without rebuilding Windows, reinstalling applications and reapplying settings by hand.
A few habits make image-level backups more reliable:
- Keep the environment healthy. Update VMware Tools or Hyper-V integration services, apply operating system patches and avoid leaving machines with a reboot pending. Backup engines depend on these components to coordinate with the guest.
- Use a dedicated backup account with the minimum permissions needed, rather than a shared domain admin login.
- Exclude what does not need protection, such as page files and temporary data, to shorten backup windows and reduce storage.
- Document the job. Record which VMs belong to which job, their schedule, retention and target, so that nothing is silently left out when someone adds a new server.
Make backups application-aware for live servers
A crash-consistent backup of a running VM is like pulling the power cord and copying the disk. The machine usually boots, but a database may need repair and an application may lose its last transactions. Application-aware processing avoids that by quiescing the application before the backup point is taken.
For VMware, the TechTarget guidance recommends image-level backups plus quiescing transactional applications through application-aware processing, with VMware Tools and VSS supporting this for Windows guests. Hyper-V uses the same Volume Shadow Copy Service approach for Windows guests.
This matters most for:
- SQL Server and other databases, where transaction logs must be consistent with data files.
- Active Directory domain controllers, where a poorly restored copy can cause replication problems.
- Exchange or other mail servers that you still host.
- Any system with write-heavy workloads, such as loan origination or case management software.
A few VMs do not play well with snapshot-based backup. TechTarget notes that for Fault Tolerance VMs, which do not support snapshots, cloning the VM and backing up the copy is an alternative. Identify these exceptions early so they are not discovered during an outage.
Do not treat snapshots as backups
Snapshots are convenient, and that is why they get misused. A snapshot is a point-in-time record that depends on the original virtual disk. If the datastore is lost, the snapshot goes with it.
TechTarget's guidance is blunt: snapshots are meant for short-term, ad hoc use and should never replace formal backups. They also degrade performance as they grow, consume significant datastore space, and can cause a VM to shut down if the underlying storage runs out.
Use snapshots for what they are good at, such as a rollback point before a patch or software upgrade. Then:
- Delete the snapshot once the change is confirmed good.
- Set an internal rule on maximum snapshot age, and report on any that exceed it.
- Make sure your backup tool consolidates its own temporary snapshots cleanly after each job.
Keep multiple copies, and keep one out of reach
The familiar 3-2-1 rule means three copies of your data, on two types of media, with one copy offsite. It is a baseline, not a ceiling. Many businesses now extend it to 3-2-1-1-0: add one copy that is offline or immutable, and zero errors after verification.
Why the extra copy? Attackers who reach your network look for backups first. Microsoft and VMware guidance both point the same way: protect recovery infrastructure with separate administrative access, appropriate network boundaries, and offline or immutable copies. If the same domain credentials that run your servers also run your backup server, one compromised admin account can erase both.
A workable layout for a small or mid-size business looks like this:
- Copy one: local backup repository on separate storage from the production datastore, for fast restores.
- Copy two: offsite or cloud copy, sent over an encrypted connection.
- Copy three: immutable or offline copy that cannot be altered or deleted for a fixed retention period, even by an administrator.
Where you keep each copy is a cost and speed trade-off. Google Cloud's documentation advises choosing repositories based on application requirements, costs and backup-software capabilities, noting that options differ in cost, RTO, number of copies and transfer charges. Local disk restores fastest. Cloud object storage is cheaper per terabyte and survives a site loss, but pulling a large dataset back over the internet takes time you must account for in your RTO.
For a deeper look at this layout, see our posts on ransomware-ready 3-2-1 backups for SMBs and the 3-2-1-1-0 ransomware backup strategy.
Harden the backup environment itself
Backups are a high-value target, so treat the backup system as production infrastructure:
- Separate credentials. Do not join the backup server to the same domain as production if you can avoid it, or at least use dedicated accounts and require multi-factor authentication for console access.
- Network boundaries. Limit which systems can reach the backup repositories, and block inbound remote access from the internet.
- Encryption. Encrypt backup data in transit and at rest, and store the keys somewhere that does not depend on the systems being recovered.
- Least privilege. Restrict who can delete restore points or change retention settings, and alert on any such change.
- Patching. Keep the backup software, hypervisor and storage firmware current.
The same redundancy thinking applies beyond servers. If your public website also needs protecting, this overview of website backup plugins shows how redundancy and ransomware resilience apply to hosted site platforms too.
Backup compromise is not the only threat. Plan for accidental deletion, failed storage, bad patches and administrator mistakes, all of which a versioned backup with sensible retention handles well.
Set frequency, retention and timing deliberately
Frequency follows RPO. Retention follows business and regulatory needs. If you operate under HIPAA, SEC recordkeeping or contractual requirements, confirm with your compliance advisor how long certain data must be retained, and how long it must not be retained, before you set a blanket policy.
A sensible retention pattern usually layers short and long periods:
- Short term: frequent restore points kept for days or a few weeks, for everyday mistakes.
- Medium term: daily or weekly points kept for months, for problems that go unnoticed for a while.
- Long term: monthly or yearly points kept as required by regulation or contract.
Timing matters too. Microsoft's Azure Backup guidance recommends scheduling backups during non-peak production hours and distributing VM backups across different times of day rather than starting every job at once. Staggering reduces storage and network contention, and shortens the window in which production users notice slowdowns. This advice is written for Azure, but the logic applies to on-premises hosts sharing a datastore and a backup network.
Also watch growth. Backup storage needs expand with every new VM, and with every longer retention rule. Review capacity on a schedule so that a full repository does not quietly stop your jobs.
Test restores, not just backup jobs
A backup that has never been restored is an assumption. Job reports show that data was copied. They do not show that a database mounts, that users can log in or that the application starts.
VMware's engineers make this point directly: focus on restores, because a success report does not show whether the application works. The recovery test should verify that services work, including user authentication and database recovery, not merely that the VM powers on.
Microsoft's benchmark adds that testing should be routine and automated, run in an isolated, non-production network, and that you should record results, recovery times and any procedural gaps so restoration plans stay effective as the environment changes.
Here is a simple restore-test routine:
- Pick a representative sample. Include at least one VM from each tier, and rotate through the rest over the year.
- Restore into an isolated network so duplicate servers do not conflict with production.
- Check function, not boot. Log in as a user, open the application, run a query, confirm the domain controller serves authentication.
- Time the whole process and compare it with your RTO.
- Record the result with date, backup used, who tested, time taken and anything that failed.
- Fix gaps such as missing documentation, expired credentials or an undersized restore host, then retest.
Also run a full-scenario exercise at least once: assume the primary site is unavailable and walk through who does what, in what order. The sequence of dependencies (network, directory, database, application) is where plans most often fail.
Monitor and alert on every job
Automation is only safe with monitoring. Configure alerts for failed, skipped or partially completed jobs, jobs that run much longer than usual, repository capacity thresholds and changes to retention or credentials. Review the alert stream daily, and assign a named owner for it. An alert nobody reads is not monitoring.
For businesses without a full-time infrastructure team, this daily review is where outsourcing often pays off. Someone has to notice at 2 a.m. that a job failed, and then fix it before the next business day.
Perspective: what we see in the field
We find that most backup failures are process failures, not product failures. The software ran. Nobody checked that the SQL VM came back consistent, or that the offsite copy was out of reach of the same admin account that manages production.
Our approach to virtual machine protection is proactive: define recovery objectives with the business first, back up at the hypervisor layer with application awareness, keep an immutable or offline copy, and prove recovery with scheduled restore tests. We monitor jobs around the clock, because a failed backup discovered during an outage is too late.
For regulated organizations such as healthcare providers, law firms, banks and mortgage companies, we also tie retention and access controls to the compliance standards that apply, including HIPAA. Our billing is flat-rate and transparent, without long-term contracts, so protection does not depend on a budget fight each quarter.
Alex
How Secure Techies can help
If you would rather not run this alongside everything else on your plate, our Backup & Disaster Recovery service covers the practices in this guide for Southern California businesses: image-level VM backups, offsite and immutable copies, monitoring and recovery testing. It sits within our broader managed IT services, which include 24/7 monitoring and a local team.
We can start with an assessment of your current VM environment and recovery objectives, then show you where your backups would and would not hold up. Contact us through securetechie.com to talk through your setup. For more on planning, read our backup and disaster recovery plan overview.
FAQ
How often should I back up virtual machines?
Match frequency to how much data you can afford to lose. Microsoft's guidance gives hourly backups for high-transaction databases and daily backups for data that changes less often. Start with your RPO for each system, then set the schedule to meet it.
Are VM snapshots enough as a backup?
No. Snapshots are for short-term use, such as a rollback point before a patch. They depend on the original storage, grow over time and can hurt performance or even shut down a VM if storage fills. Use them alongside, never instead of, formal backups.
What is the 3-2-1 backup rule for virtual machines?
Keep three copies of your data on two types of media, with one copy offsite. Many organizations add an offline or immutable copy so that ransomware or a compromised administrator account cannot delete every restore point.
How do I know my VM backups will actually restore?
Test them. Restore a sample of VMs into an isolated network, then confirm that users can authenticate, databases open and applications work. Time the process against your RTO and record the results, because a completed backup job alone does not prove recovery.
Do I need application-aware backups?
Yes, for any VM running databases, directory services or other transactional applications. Quiescing the application before the backup point keeps data consistent, which reduces repair work and speeds recovery after a restore.
Sources
- Microsoft cloud security benchmark v2: Backup and Recovery
- Guidance and best practices for Azure Backup
- Top 8 VMware vSphere backup best practices
- Back up VMware environments with these best practices and tips
- Workload VM backup solutions, Google Cloud documentation
- Not About Backups, It's About Restores