Backup and recovery

What this category is for

Copies of the things whose loss would stop the company, and a tested route back from that loss. The products here cover endpoints, servers, virtual machines, databases and the software suites where most business data now sits.

Two jobs hide under one word. Backup is about getting working again quickly. Archiving is about keeping records for years because a regulator, a contract or a court might ask. Buying one and assuming you have the other is the mistake that repeats across this whole shelf.

Where the files live day to day is file storage. Watching whether systems are up is monitoring.

Two numbers decide everything

Before comparing products, write down two figures for each system you care about.

How much recent work can you afford to lose, measured in minutes or hours? And how long can that system be down before the loss stops being an inconvenience? The first number sets how often copies run. The second sets what kind of restore you need to buy.

A nightly copy is fine for an archive of finished projects and useless for an order system that takes four hundred transactions an hour. Most disappointment in this category comes from buying a schedule that never matched the answer.

What actually gets covered

Coverage gaps are quiet until the day they are not.

• Endpoints including laptops that are rarely on the network at the right hour.
• Servers and virtual machines, whole-image or file level, on your own hardware or in a cloud.
• Databases, which need consistent snapshots rather than a copy of files being written to.
• Cloud suites covering mail, drive, chat and the site collections nobody remembers creating.
• Business applications whose vendor keeps data for a limited window and expects you to keep your own copy.

That last group catches people out constantly. A subscription service holding your records is not a backup of them, and the terms usually say so in plain language.

Restore is the product, not the copy

Nobody buys backup. Everybody buys restore, and only discovers which one they bought under pressure.

Ask how granular a restore can be. Pulling back one mailbox item, one file version or one table beats reinstating an entire server when someone deleted a single row. Ask how long a full restore takes at your data volume, with a real figure rather than a marketing one.

Then ask about the ugly cases. A restore into a different machine than the original. A restore when the vendor’s console is unreachable. A restore of a system whose software version has moved on since the copy was made.

Test one properly during the trial and put the result in writing. An untested backup is a belief, not a control.

Ransomware changed the requirements

Attackers now go for the copies first, because that is what makes payment feel necessary.

Immutable storage is the answer that works: a copy that cannot be altered or removed for a fixed period, whatever credentials the attacker holds. Check whether it is available on your plan, how long the lock lasts and whether an administrator can shorten it.

Offsite separation matters alongside it. A copy in the same account, on the same domain, reachable with the same password is one compromise away from being gone. Alerting on failed or missing jobs closes the last gap, because backups that silently stopped in March are the most common finding in any incident review.

How the money works

Pricing runs per user, per device, per workload or per terabyte, and vendors mix these freely.

Storage tiers are the part to read carefully. Cheaper archive storage costs less to keep and more to read back, sometimes with a delay measured in hours. Retention length drives cost more than anything else, since seven years of daily copies is a different product from thirty days of them. The wider pattern of quiet meters is covered in what pricing pages hide.

Writing the restore plan down

The document matters as much as the software, and most organisations discover its absence at the worst moment.

Record what is backed up, how often, where copies live and how long they are kept. Record who is authorised to run a restore and how they reach the console if the usual route is unavailable. Record the expected time to recover each system at its real size.

Then rehearse it once a year with somebody who did not write it. A plan that only its author can execute is a single point of failure wearing a document’s clothing.

Keep a copy of the plan somewhere that does not depend on the systems it describes. Instructions stored only in the file server you are trying to restore are a familiar and avoidable irony.