Snapshot or backup: what protects my data?
Taking a snapshot before an update can provide a quick way back. That alone does not tell you whether your data will survive failed storage or a compromised administrator account. What matters is which copy remains available in each failure scenario and how you turn it into a working system.
What a snapshot is useful for
A snapshot records a system or storage state at a point in time. The implementation depends on the platform. For VMware, Broadcom describes snapshots as changes relative to an underlying virtual disk. Without that base, the snapshot is not an independent replacement. Your platform's actual design matters more than the label in its control panel.
For a planned software update, decide who takes the snapshot, which functional test confirms success and when it will be removed. An ever-growing collection without an owner is not a recovery plan. Also consider whether rolling back would overwrite orders or files created since the snapshot.
Why three storage copies do not replace a backup
Replication maintains several copies of the live data. NUXOA's server infrastructure stores three Ceph copies on separate hosts. This provides protection against individual disk or host failures within the available redundancy. If a file is accidentally deleted or overwritten by an application, that change is replicated too. Recovering an earlier state requires a backup or a suitable snapshot.
NUXOA managed servers also include seven daily on-site backups and two weekly off-site backups. Storage redundancy and these historical backups serve different purposes. A recovery test establishes whether databases and configuration, as well as files, can be restored to a usable state.
Plan for the actual failure
Ask your provider three specific questions: can the backup be accessed if production storage fails? Can the same credentials delete both production and backup data? Can you restore an older version after discovering corruption late? The answers show whether the copy addresses your risks. Another folder on the same disk, for example, does not solve the first problem.
CISA's ransomware guidance includes offline encrypted backups and regular recovery tests. In practical terms, separation and permissions must match the threat you are planning for. An external copy helps, but remains vulnerable if a compromised account can also modify or remove it.
Worked example: how much work is missing?
Suppose the last usable backup of an order system is from 02:00 and the system fails at 15:00. Without another recovery method, 13 hours of changes may be missing. Ask the business team whether they could reconstruct that period and which records would remain available outside the system.
Downtime is a separate question. Downloading data, preparing a replacement server, starting the application and checking records also takes time. Record acceptable data loss and the desired recovery time separately. Frequent backups do not, by themselves, demonstrate that the application can be restored quickly.
A recovery test that provides evidence
- Choose a specific backup and make the required keys and credentials available.
- Restore into a separate test environment and prevent automatic emails, payments and other production actions.
- Check sign-in, a known record, permissions and a representative business task.
- Record start and finish times, the data's age, missing components and business acceptance.
- Assign an owner to unresolved issues and repeat the test after changing the backup process.
What to include in the quotation
Ask which data and configuration are covered, where copies are stored, how long they are retained, how deletion is controlled and who performs recovery. A database application also needs a method for producing a consistent data set. Record whether recovery assistance is included or separately commissioned. These answers matter just as much as memory and disk capacity when selecting a server.