Fast VM Backups in 5 Minutes with OVF/OVA
If you’re running a lab on VMware Workstation or managing a few standalone VMs on ESXi, don’t overcomplicate things. The fastest way to get a reliable backup is by exporting them to OVF or OVA format. The biggest advantage is that the output is highly compressed, making it easy to copy to a USB or upload to another server without worrying about checksum errors or missing files.
In VMware Workstation, simply power off the VM, then go to File > Export to OVF. For ESXi/vCenter, right-click the VM and select Export OVF Template.
# Automate with ovftool to save time:
ovftool vi://[email protected]/MyVM /local/path/backup/MyVM.ovfThis trick is extremely useful when you need to hand over a VM to a colleague or want to save a clean “golden image” before diving deep into system configurations.
Are Snapshots Backups? The Dangerous Misconception
Junior admins often have a dangerous habit: clicking Snapshot and feeling confident that their data is safe. In reality, I once managed an 8-host ESXi cluster, and the first lesson I taught newcomers was: Snapshots are absolutely NOT backups.
Think of it this way: when you take a snapshot, VMware creates a -delta.vmdk file to record new changes. The original file stays put. If the disk holding that original file fails or if someone accidentally deletes it, your snapshot becomes useless junk. Moreover, keeping snapshots for too long (over 72 hours) causes VM performance to tank, and the eventual disk consolidation becomes an I/O nightmare.
Pro tip: Use snapshots only for quick rollbacks before OS updates or testing new software. For real safety, you must move your data off the current storage.
The 3-2-1 Rule: The Golden Standard for VMware Infrastructure
Managing systems without knowing the 3-2-1 rule is extremely risky. This is the formula I always apply to sleep soundly at night:
- 3 copies of data: One production copy, one local backup (Local Repo), and one stored elsewhere.
- 2 different media types: Don’t put all your eggs in one basket. Store backups on a dedicated NAS (like a Synology DS923+) and another on Tape or external drives.
- 1 offsite copy: This is your last line of defense in case of office fires or Ransomware. I usually push this to the Cloud (S3 Object Lock) or keep an external drive in a safe location.
Professional Backup Deployment: Veeam or GhettoVCB?
Depending on your company’s budget, you can choose one of the following two paths:
1. Veeam Backup & Replication (Enterprise Grade)
If your company has the budget, go with Veeam. It’s the “king” thanks to CBT (Changed Block Tracking) technology. From the second backup onwards, Veeam only copies the data blocks that have actually changed, resulting in incredibly fast speeds.
The most valuable feature is Instant VM Recovery. I once had a Domain Controller blue screen at 2 AM. It took exactly 2 minutes to boot it back up directly from the backup file. The whole company started work at 8 AM without ever knowing an incident had occurred.
2. GhettoVCB (The Powerhouse for Free Version Users)
For those on ESXi Free, Veeam’s API access is locked. This is where the ghettoVCB script becomes your best friend. It runs directly on the ESXi shell, automates snapshots, copies vmdk files to a NAS, and then cleans up the snapshots.
Here is a ghettoVCB.conf configuration file I often optimize for clients:
VM_BACKUP_VOLUME=/vmfs/volumes/NFS_BACKUP/backups
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3 # Keep the 3 most recent backups
POWER_VM_DOWN_BEFORE_BACKUP=0 # Hot backup, no shutdown required
EMAIL_LOG=1 # Daily email reportsRestore Procedures: Don’t Wait for the Fire to Look for a Hose
Backing up without testing is pointless. Every 3 months, my team performs “drill” restores of key VMs into an isolated network. This ensures databases aren’t corrupted and the OS boots properly.
When restoring on vSphere, keep these points in mind:
- Select a target Host and Datastore different from the production one to avoid accidental overwrites.
- Crucial: Disconnect the Network before powering on the restored VM. Otherwise, IP conflicts will wreak havoc on your network.
- Verify internal services are stable before proceeding with any data migration.
Lessons Learned from Heart-Stopping Moments
After years of working with various clusters, I’ve gathered these key takeaways:
- Check logs every morning: Don’t rely blindly on automation. One day a full NAS or a script error could lead to disaster if left unnoticed.
- Invest in bandwidth: If your data reaches several TBs, use 10Gbps SFP+. Backing up over outdated 100Mbps or 1Gbps networks will leave you waiting for days.
- Use meaningful names: Don’t name VMs like
New_VM_2. Use standards likeSRV-APP-01so you know exactly what to prioritize during a disaster.
Building a proper backup strategy might take effort upfront, but it’s the cheapest insurance for your career. If you run into issues configuring GhettoVCB or optimizing Veeam, feel free to leave a comment, and I’ll do my best to help.
