Backup and recovery features to insist on and to skip

A backup feature is only worth what the failure it prevents would cost. Read the list that way, and mark each entry insist or skip before you talk to a supplier. Each entry names the feature, the failure it stops, and the condition under which you can leave it out.

A small business paying for capability it will never configure has bought nothing twice.

What to take away

Capture: two to insist on, two to weigh

Four capture features decide whether a restore returns what the business runs on. Selection by system and scope reporting are always worth having; the other two depend on what you hold.

Selection by system rather than by folder: insist. You name a mailbox, a database, a machine, and the product works out what that involves. It prevents the failure where a new share was added in March and nobody added it to the job. You find out when a restore returns everything except the folder the business runs on.

Open-file and application-aware capture: skip it only if nothing you hold is a database or a mailbox. That is rarer than it sounds. The feature copies a file that is in use, or asks the application to settle first, and it prevents a restore that produces a database the software refuses to open.

Scope reporting: insist. It is a list of what was skipped and why. It prevents the slow, silent shrinking of coverage that no dashboard shows, because the job still says success. This one is worth more than most of the rest of the list.

Bare-metal or whole-machine capture: skip it for laptops whose contents live elsewhere anyway. It brings a machine back on different hardware and prevents a two-day rebuild of a machine nobody has documented. Keep it for the two or three machines that would stop trading.

Protecting the copy: where skipping costs the most

The copy itself is the target in the incidents that matter most, so this group has the fewest features you can leave out. Four controls here protect the copy itself from tampering.

Retention lock, or write-once storage: insist, unless a disconnected copy does the same job. The copy cannot be altered or deleted until a period expires. It prevents the case the whole category exists for: someone with your credentials removing the reason not to pay them. You find out you needed it on the only morning that matters.

The United States Cybersecurity and Infrastructure Security Agency's introduction to ransomware is plain about why destroying the recovery comes before anything visible happens.

A separate credential for the backup system: insist. Give it its own account, its own second factor, and no shared administrator with the systems it protects. It prevents one stolen login from taking both the data and the recovery. It is a configuration choice more than a product feature, governed like any privileged access in identity and access.

An alert when retention is shortened: insist, because it costs nothing. Somebody is told when the window is reduced or a job is disabled. It prevents the quiet preparation that precedes the visible part of a bad incident. It is cheap and rarely enabled.

Encryption with a key you can reach from elsewhere. It protects the copy in transit and at rest. It creates a second problem, which is where the key lives, and a key stored only inside the environment being restored is the most common way a technically perfect backup fails.

Proof: the features that show a backup works

Proof features separate a backup that exists from one that restores. Content verification is the one to insist on; automated test restores can be replaced by a calendar entry and a person.

Verification that reads content: insist. It opens the archive and checks the data rather than comparing a file size. It prevents the discovery that two years of copies are unreadable. Ask specifically what a candidate's verification does, because the word covers everything from a checksum to a full test restore.

Automated test restores: skip them only if you will genuinely do the test by hand every quarter. The product restores something into an isolated place on a schedule and reports whether it worked. It prevents the annual test being skipped because everyone was busy.

Where the product cannot do this, a person does it quarterly instead, and the calendar entry is the feature.

Rehearsing recovery rather than assuming it is the recurring theme of the United States National Institute of Standards and Technology's guide for cybersecurity event recovery.

A readable restore history. It records what was restored, by whom, when, and how long it took. It prevents an argument with an insurer, and it gives you the recovery time number that every other decision depends on.

Restore speed: price the features against downtime

Restore-speed features each remove one delay, and each can be left out when that delay is affordable. Decide how long the business can wait, then buy only what closes the gap.

Granular restore from a whole-machine copy. You pull one file out of an image without rebuilding the machine. It prevents an hour of work becoming an afternoon.

Local cache with a remote copy behind it: skip it if your data is small and your connection is fast. Recent data restores from the building, older data from elsewhere. It prevents the slow bulk restore across a broadband connection, which is the number that surprises people most.

Run from backup: skip it if an hour of downtime is affordable. The machine boots directly from the copy while the real restore proceeds. It prevents the business stopping entirely. Ask what the performance is like while running that way, and how long the move back takes, because both are usually absent from the description.

Restore to different hardware or a different platform. It prevents the arrangement failing because the identical machine no longer exists to buy.

Notices: making sure a person finds out

Notices are where the arrangement either reaches a human or does not. Failure notices by a route somebody reads are not optional, and the console only has to be usable by the least technical person.

Failure notices by a route somebody reads: insist. Not a dashboard. They prevent the single most common backup failure in small businesses, which is months of failed jobs into an unread mailbox.

A weekly summary that is short enough to read. It prevents notification fatigue, which is the same failure wearing a different hat.

A console someone can use under pressure. It prevents the first restore being attempted for the first time during an incident by someone reading documentation. Test this during a trial by having the least technical person find and restore yesterday's file.

The insist-or-skip table

What no feature covers

No feature decides what the business cannot trade without, or the order things come back in. Those are decisions taken in advance and written down, which is the whole argument of incident response.

No feature covers the services you never pointed it at. What an online platform retains on your behalf, and for how long, is a separate question, and assuming it is handled is one of the more expensive assumptions available.

Common questions

Which single feature would you insist on?

An alert, by a route someone reads, when a job fails or a retention window shrinks. Every other feature protects data. That one protects the arrangement from quietly stopping.

Which feature can go first if the budget is tight?

The one whose skip condition you already meet, such as application-aware capture when you hold no databases or mailboxes. Do not drop a feature marked insist to afford one marked skip.

Is application-aware capture worth it for a small accounting system?

Ask the software supplier what a consistent copy of their database requires. If the answer is that the application must be closed, then a nightly copy after hours is the cheaper version of the same feature.

We have run from backup in a demonstration. Is it as good as it looked?

It restores availability, not performance. Ask what the machine feels like to use in that state, how long the full move back takes, and whether any of it needs a license tier above the one on your quote.

How do we test the console under pressure without an incident?

Hand it to the person least involved in setting it up, give them a file name and a date, and time them without helping. Whatever they struggle with is what will go wrong on the day.