"We have a backup, hosting takes a nightly snapshot." We hear this in every second conversation about protecting an ERP. And in every second one, it turns out there is no backup — just a machine image the database won't come up from cleanly.
A database isn't a regular file. While Comarch Optima, enova365, Subiekt or Microsoft Dynamics AX are running, things happen inside the database that you can't see from the operating system: open transactions, memory buffers, the transaction log that records changes before they land in the data files. When the hypervisor takes a snapshot at a random moment, it captures that state "mid-sentence". After a restore, SQL Server comes up, runs recovery and — with luck — reaches a consistent state. Without luck, the database ends up in SUSPECT mode and you're calling the ERP vendor.
This isn't theory. It's a scenario we see at customers every year, mostly after a power outage or ransomware.
What a "server snapshot" actually does
A VM snapshot in Hyper-V, VMware or Proxmox freezes the disk state (and optionally RAM) at a specific moment. From the hypervisor's point of view — very convenient. From the database's point of view — it's as if someone yanked the power.
Better-grade hypervisors can cooperate with applications via VSS (Volume Shadow Copy Service) on Windows. Before the dump, the system asks SQL Server to "step outside for a moment" — close open transactions, flush buffers to disk. This is called an application-consistent snapshot and it's the only kind of snapshot worth fighting for.
The problem is that in practice, at small companies, this often doesn't work. The reasons are simple:
- The snapshot is taken from the VPS layer at the hosting provider, which never invokes VSS.
- The VSS writer for SQL Server has been disabled since some update and nobody noticed.
- The database lives on the free SQL Server Express edition, where some mechanisms are trimmed.
- The snapshot covers two disks and only one was frozen consistently.
The result: you have a VMDK, VHDX or QCOW2 file that looks like a backup, and after a restore it turns out the database is damaged or the last few hours of operations are missing.
What happens when you actually have to restore
At one of our customers — a 25-person electrical wholesaler running Comarch Optima on SQL Server Express — the RAID controller died on a Wednesday evening. The host had a daily 3 AM snapshot. Restoring the machine took an hour. Bringing Optima up took another 3 hours, because the database fell into recovery pending and needed manual intervention.
When it finally came up, it turned out that 8 hours of transactions were missing — every invoice, warehouse receipt and payment from the whole working day. The company spent the next two days manually rebuilding data from paper delivery notes and bank statements. Lost time for sales and accounting was estimated at around 30,000 PLN. The snapshot existed, it "worked" — and the company still lost a whole day of work.
Had a classic database backup strategy been in place instead — a full backup every night, differential backups every 6 hours and transaction log backups every 15 minutes — the recovery point (RPO) would have been at most 15 minutes, not 8 hours. Setting it up costs a few hours of configuration and a few dozen gigabytes of storage per month.
What a properly done database backup looks like
For most SME installations of Comarch Optima, enova365, Subiekt GT/Nexo or Dynamics AX on Microsoft SQL Server, a simple pattern works:
- Full backup (FULL) once a day, at night, when nobody is working.
- Differential backup (DIFF) every 4–6 hours during working hours — a few percent of the FULL in size.
- Transaction log backup every 15 minutes — lets you restore to a specific point in time with minute-level precision.
- Backups in FULL recovery model, not SIMPLE — otherwise the log is useless.
- Verification (RESTORE VERIFYONLY) after each copy — checks file integrity.
- Backups kept in at least two locations — one on-site, one off-site (cloud, second office, offline drive).
You can automate all of this with Ola Maintenance Plans, SQL Server Agent (if you have the Standard edition) or the free Ola Hallengren's SQL Server Maintenance Solution. Comarch Optima also has its own backup mechanism from the console — for small databases it's plenty, but you have to enable it.
One caveat: SQL Server Express doesn't include SQL Server Agent. You have to automate the schedule from the Windows Task Scheduler or a PowerShell script. That works, but you have to do it — otherwise "we have a backup" means "we have hope".
Off-site backup — because ransomware doesn't play nicely
Even the best database backup is useless if it sits on the same server as production. Modern ransomware hunts for .bak, .trn, .mdf files and encrypts them along with everything else. We've seen a case where a company had 60 days of backups — all on the same network share, all encrypted in 20 minutes.
The 3-2-1 rule (three copies, on two media, one off-site) applies to ERP databases too. In practice for SMEs that means:
- a local copy on the server,
- a copy on a second physical device (NAS in another room, second server in another location),
- a copy off-site — Azure Blob Storage, AWS S3, a backup at the hosting provider, or a USB drive that goes home with the CEO each evening.
The off-site copy should be immutable or kept on an account with separate credentials that the domain admin account cannot access. Otherwise ransomware that gets to the server will also wipe the cloud.
A restore test — the only real proof
A backup that has never been restored is a Schrödinger backup — it both exists and doesn't. Regularly testing a restore into a test environment is the only way to know the copy actually works.
Our recommendation: once a month, RESTORE the latest FULL plus all DIFF/LOG copies onto a separate test server, start Optima/enova/AX on that copy, open a few invoices, generate a report. It takes about 2 hours for someone prepared; you can do it once, write down a step-by-step instruction (IT documentation — see our separate post).
If during the test the database won't restore — you have a known problem, not a problem discovered in the middle of an outage. That's the whole difference.
Wrap-up
A machine snapshot is part of the plan, not the whole plan. For an ERP, you need a separate database backup strategy with a short RPO, an off-site copy and regular restore tests. Without that, the first serious incident costs you a day of work, sales data, nerves — and often the trust of customers whose invoices you have to reissue.
If you're not sure whether your company is in the better half, book half an hour. We'll tell you exactly what to check and where to start if the backup isn't really there.
A backup you've never restored isn't a backup — it's hope. And hope isn't an IT strategy.