Rules
Part of Backup and recovery: a grounded overview
Image versus file, chain versus full: comparing backup architectures
Backup architectures compared rather than brands: image against file, chain against synthetic full, agent against agentless, and where each one fails you.
Two backup products built on different architectures behave differently on the worst morning, and the difference is not visible in a feature list. A file-level copy and a whole-machine image both say backup on the invoice. One of them gets a bookkeeper working again in ten minutes and the other takes a day; which is which depends on what broke.
What follows is six architectural pairs. Each is a real choice a small business makes, usually without noticing, and each is described by what it does well, what it does badly, and the situation that decides it.
What to take away
- Choose the architecture from the failure you are planning for, not from the storage price.
- Every chain has a weakest link, and in most products it is the oldest full copy.
- The pair that matters most is whether your own credentials can destroy the copy.
File level or whole machine image
A file-level copy holds documents and folders. An image holds the whole machine: the operating system, the installed software, the settings, and the files.
File level restores quickly for the common case, stores efficiently, and is easy to browse. It does not bring back a machine. Reinstalling everything from scratch and then restoring documents is a day, sometimes two.
An image brings the machine back as it was, which is the only realistic answer when the hardware is gone or the disk is encrypted. It is larger, slower to take, and restoring a single file from it is more work in some products than others.
Most small businesses need file level for everything and images for the two or three machines whose configuration would take a day to rebuild: the accounting server, the machine running the till, the one nobody remembers setting up.
Inside the environment or outside it
A copy in the building, on your own network, under your own credentials. Or a copy somewhere else, under separate credentials.
Inside is fast in both directions and useless against anything that reaches the network. Outside is slower to restore in bulk and survives the case you actually bought insurance against.
This is the pair that is not really a choice. The pillar on backup and recovery states the reason plainly: the copy that saves you is the one your compromised environment could not alter.
An unbroken chain or periodic full copies
Some products take one full copy and then only changes, forever, merging them behind the scenes. Others take a fresh full copy on a schedule with changes in between.
A forever chain is cheaper in storage and in backup window, and it has a single point of failure: if the base or a link is damaged, everything after it may be unreadable. Products that merge changes into a new synthetic full copy reduce this, and it is worth asking specifically whether yours does.
Periodic full copies waste storage and are stubbornly resilient. Each full copy is independently readable, so a damaged link costs you one period rather than the archive.
Ask two questions of any candidate. How often does an independently readable copy exist? And what does the product do when it finds a link is corrupt: tell you, repair it, or carry on?
Alterable or write-once
Ordinary storage lets whoever holds the credentials delete what is there. Write-once storage refuses changes until a retention period expires.
The second is the property that separates a backup from an expensive copy, and it is worth checking rather than assuming. Ask whether an administrator of your own account can shorten the retention window, because in several arrangements they can, and an intruder holding that account is exactly the case being defended against.
Where write-once is not available, physical disconnection does the same job with a person instead of a policy. The United States National Institute of Standards and Technology's practice guide on recovering from ransomware and other destructive events is built around this property, and it is the clearest statement of why the pair exists at all.
An agent on the machine or a copy taken from underneath
An agent runs on the machine, understands the applications, and can quiet a database long enough to take a consistent copy. It must be installed, updated and defended.
Copying from underneath, at the level of the whole virtual machine or the storage, needs nothing installed and knows nothing about what is running. For documents that is fine. For a database mid-write it can produce a copy that restores into a state the application refuses to open.
Where a system holds a database that matters, ask the software supplier what a consistent copy requires. That answer, not the backup vendor's, decides this pair.
Copies you keep briefly or copies that reach back months
Frequent recent copies answer the everyday mistake. A long tail of weekly and monthly points answers the problem discovered late, which is the more expensive one, because an intrusion found in November may be present in every copy taken since August.
Storage for old, infrequent points is the cheap part of the arrangement. Retention that reaches back further than feels necessary is the single most commonly regretted setting, and the reason sits in the recovery guidance the same institute publishes as its guide for cybersecurity event recovery.
The pairs at a glance
Choose the first when
- File or image
- Documents are what matters
- Inside or outside
- Never on its own
- Chain or periodic fulls
- Storage and backup window are tight
- Alterable or write-once
- Nothing; pair it with disconnection instead
- Agent or from underneath
- An application needs a consistent copy
- Short retention or a long tail
- Never on its own
Choose the second when
- File or image
- A machine would take a day to rebuild
- Inside or outside
- Always, for at least one copy
- Chain or periodic fulls
- You want each period independently readable
- Alterable or write-once
- Always, if the tier offers it
- Agent or from underneath
- Plain files, or machines you cannot install on
- Short retention or a long tail
- Always; the long tail is the cheap part
What none of the pairs decide
None of them decide whether anybody restores anything. An elegantly architected arrangement that has never returned a file is in worse shape than a rotated drive somebody reads back every quarter, because the first one is trusted.
They also do not decide who holds the key. Encryption is the right default and the key is a separate object with its own custody problem, which belongs under the same discipline as any other privileged credential in identity and access.
And they do not decide the order things come back in. That is a business decision made before the incident, and it lives in incident response with the rest of the choices that should not be made at three in the morning.
Common questions
Do we need images for every machine?
No, and paying for that is a common misdirection of a small budget. Identify the machines whose rebuild would stop the business, image those, and take file-level copies of the rest.
Our product uses a forever chain. Is that a problem?
Not by itself. Ask when an independently readable copy last existed and what the product does when it detects corruption. If neither question has a clear answer, add a periodic independent export of the data that matters most.
Is a backup taken from underneath a virtual machine enough for a database?
Ask the software supplier, not the backup vendor. Some databases tolerate it, some produce a copy that will not open, and the difference is discovered at the worst moment.
What if we cannot get write-once storage on our plan?
Then use disconnection. A drive that is written and unplugged has the same property, enforced by physics rather than by a setting, and the fundamentals in security foundations rate it above any control you have to remember to configure.
