Backups people actually test: a practical 3-2-1 routine for a small business VM

Small businesses rarely skip backups on purpose. Someone set up a copy job once, then a drive filled up or a password changed. Nobody noticed, because nobody ever tried to restore anything.

This post assumes a common setup: one business application running in a virtual machine on a back-office computer, used by staff from their browsers. The ideas apply to almost any small server.

The rule, translated for a small shop

The classic 3-2-1 rule says:

• 3 copies of your data: the live one plus two backups.
• 2 different kinds of storage, so one failure mode can't take out everything.
• 1 copy outside the building, so fire, theft or a flooded back room doesn't end the business.

In a small shop, that usually becomes:

1. The live data inside the VM.
2. A copy on a NAS or a second computer on the local network.
3. A copy on an external drive that rotates off-site.

None of this needs special software. It does need a schedule, a written owner and a habit of checking.

Know what you are backing up

There are two different things worth protecting, and they fail differently.

The data. Customers, tickets, invoices, inventory, notes. This changes every day and is the part you truly cannot recreate.

The machine. The VM itself: operating system, application, configuration. You can usually rebuild this, but it takes time you would rather not spend on a busy morning.

That suggests two kinds of backup:

• Application-level exports, taken often. If your software has a built-in export or backup feature, use it. These files are small, fast to create and usually easy to restore into a fresh install.
• Full VM exports, taken less often. An exported appliance (for example an .ova file) captures the whole machine, so you can bring the system back on new hardware without reinstalling anything.

If you only do one, do the application export. A VM export without current data is just a nicely configured empty box.

Snapshots are not backups

Hypervisor snapshots are great before an update: if something breaks, you roll back in seconds. But a snapshot lives on the same disk as the VM. If that disk dies, the snapshot dies with it.

Use snapshots as an undo button, then delete them once you're happy.

A schedule you can keep

Pick a rhythm that matches how much work you can afford to redo. A reasonable starting point:

• Daily: application export, copied automatically to the NAS or second computer.
• Weekly: application export copied to the external drive that is currently on-site.
• Monthly, or before any big change: full VM export, with the VM shut down cleanly first.

On a Linux host running VirtualBox, a clean full export looks like this:

VBoxManage controlvm "Business VM" acpipowerbutton
# wait until it is really off
VBoxManage showvminfo "Business VM" --machinereadable | grep VMState=
VBoxManage export "Business VM" -o "/srv/backups/business-vm-$(date +%F).ova"

Shutting down first matters. Exporting a running database can give you a file that looks fine and restores into a mess. Do it after closing.

Rotate the external drives

The off-site copy is the one people get lazy about, because it involves physically moving something.

Make it boring:

• Buy two external drives and label them clearly, for example "A" and "B".
• One stays in the shop and receives the weekly copy. The other is somewhere else: the owner's home or another trusted place.
• On a set day, swap them. The drive that comes back gets the next copy; the one that leaves takes the latest data with it.
• Encrypt both drives. A backup drive in a bag is customer data in a bag.

Write the swap day on the calendar. If the drive that is supposed to be off-site is sitting on the desk, the rule is broken.

Use the NAS, but don't trust it blindly

A NAS or second computer is the convenient copy: always on, always reachable, fast to restore from.

A few precautions keep it useful:

• Use a dedicated account for backup jobs, with write access only to the backup folder.
• Don't map the backup share as a drive letter on everyday workstations. Ransomware loves mapped drives.
• Keep versions. If the NAS supports snapshots or versioned folders, turn them on, so a bad file today doesn't overwrite a good one from last week.
• Prune with a rule, not by hand. Something like: keep recent daily copies, a handful of weeklies and a few monthlies. Write the rule down.

Restore drills: the part that actually matters

A backup is a theory until you restore it. The goal of a drill is simple: prove that someone other than the person who set it up can bring the data back.

A practical drill:

1. Pick a backup at random, not the newest one. You want to know older copies work too.
2. Use a spare machine or a separate test VM. Never restore over the live system to "see if it works".
3. Disconnect it from the shop network before starting it, or put it on an isolated network. You don't want a test copy sending notifications or fighting the real server for an address.
4. Import the VM or a fresh install, then load the application export.
5. Check real things: search for a recent customer, open a ticket from last week, compare a total against what you remember. Write down what you checked.
6. Time it. Not to hit a target, but so you know how long the shop would be without its system.
7. Delete the test copy when you are done, or keep it powered off and clearly labeled.

Rotate who runs the drill. The written steps improve every time someone gets stuck.

The monthly checklist

Put this on a single page near the server:

• [ ] Latest daily export exists on the NAS and opens without errors.
• [ ] Weekly copy is on the on-site external drive.
• [ ] Drives were swapped on schedule; the off-site drive is actually off-site.
• [ ] Free space on the NAS and external drives is comfortable.
• [ ] Backup job logs show no errors or silent skips.
• [ ] Monthly VM export completed after a clean shutdown.
• [ ] Old snapshots removed from the hypervisor.
• [ ] Passwords and encryption keys for the backups are stored somewhere the owner can reach without the server.
• [ ] Restore drill done this quarter, with notes.

Sign and date it. When something goes wrong, that sheet tells you what was last known to be good.

Where this fits

If you run a repair shop, this routine fits RepairAmigo well: it is free repair shop software that runs as one VirtualBox VM on your shop network and is used from any browser, with no ticket or user limits. Setup takes about an hour.

Whatever software you use, the important part is the habit: copy, rotate, restore, write it down. Then do it again next month.