Backup and recovery setup: nine steps for a small business

Most backup arrangements are configured in the order the software presents, which is the order that suits the software. The order below suits the business. It starts with two decisions that cost nothing and determine everything, and it ends with a copy somebody has actually read back.

Each step closes with a test. Do not move on because a step looked simple; the point of the test is that several of them fail on the first attempt, and finding that out now is the whole exercise.

What to take away

Step one: list what would hurt

Walk through the business and write down where data actually lives. This takes an afternoon and produces surprises every time.

Beside each entry, note who would notice first if it vanished. That person is the one to ask whether the arrangement you build later actually covers what they use.

Test: ask a colleague to name something they work on daily and find it on the list. If it is not there, the list is not finished.

Step two: two numbers per system

For each item on the list, answer two questions in plain language.

How much of this could we lose without real damage? A day, an hour, nothing. That sets how often it is copied.

How long could the business run without it? An afternoon, a day, a week. That sets how it is stored and how it comes back.

Do not answer these for the business as a whole. The accounting database and the archive of old photographs deserve different treatment, and treating them alike is how a small budget gets spent in the wrong place. The reasoning behind both numbers, and what they are called, is in backup and recovery.

Test: the two numbers differ across at least three systems. If every system got the same answer, the questions were not really asked.

Step three: decide the copies

From the numbers, decide what copies exist. Most small businesses need three.

Something convenient, for the everyday mistake: version history, a local copy, whatever restores in minutes.

Something elsewhere, automated, so that the building is not a single point of failure.

Something the running environment cannot alter, by write-once storage or by being unplugged. This one is the reason the whole arrangement exists.

Configure the third one first. It is the one that gets postponed, and postponing it leaves the business exposed to the case it most needs to survive. The Cybersecurity and Infrastructure Security Agency's note on data backup options is a short summary of the same shape if you want something to hand to a colleague.

Test: from an ordinary administrator account, try to delete or alter the third copy. It must refuse, or be physically absent.

Step four: separate credentials before configuring anything

Create the backup account with its own login and its own second factor. Do not reuse the administrator account for the systems being backed up. Put the recovery codes on paper somewhere off the network, and make sure a second person can reach them.

Doing this now, rather than later, avoids the common outcome where the arrangement works and is protected by the same credential as everything else. The rules that apply are the ones in identity and access.

Test: somebody other than you signs in to the console using the documented route.

Step five: configure by system, not by folder

Point the software at systems from your list rather than at paths, wherever it allows that. Turn on whatever reports what was skipped. Set retention with a long tail: frequent recent points thinning to weekly and monthly ones that reach back months.

Run the first full copy deliberately, at a time when saturating the connection does not matter, and watch it finish.

Test: open the first report and find something that was excluded. There is always something. Decide whether it should have been.

Step six: the encryption key

Encrypt the copies. Then deal with the key as its own object: write down what it opens, store it outside every environment it would be used to recover, and have a second person retrieve it while you watch.

Test: the second person produces the key without your help and without opening anything on the office network.

Step seven: notifications to a route somebody reads

Failures, skipped items and retention changes go to a person, not to a dashboard. Choose the route that person already reads. Then break something on purpose, such as renaming a source folder, and confirm the notice arrives.

Test: the notice arrives, and the person who received it can say what it meant.

Step eight: restore before you call it done

Restore one file from a week ago into a scratch location. Open it. Then restore a whole share or machine into an isolated place and time it.

Write the duration down. That number governs decisions you will make later about whether a local copy is needed for speed, and it is almost always longer than anyone guessed.

Test: somebody who did not configure the arrangement performs the file restore unaided.

Step nine: write the page

One printed page is kept off the systems it describes. It records what is backed up, where each copy is, who holds the keys, the order things come back in, and the date and duration of the last successful restore.

If the business needs more later, the United States government's guidance on writing a business continuity plan is the plain version. The page is its first section.

That page is what feeds the decisions in incident response, and it is the part that ages fastest. Put a date on it.

The steps and their tests

Common questions

How long does the whole thing take?

Two afternoons for a small business, spread over a fortnight so the first full copy has time to run. The listing and the two numbers take longer than the software.

Can we skip the two numbers and just back everything up hourly?

You can, and you will pay for the demanding option on systems that never needed it while still not knowing how long a restore takes. The numbers are what make the rest of the decisions cheap.

What if a system cannot be backed up the way we want?

Ask its supplier what a consistent copy requires. Where the answer is that the application must be closed, a scheduled copy after hours is usually the practical version, and it belongs on the page in step nine so nobody assumes otherwise.

How often do we repeat step eight?

A file quarterly, a whole system annually, and after any significant change. Writing the date somewhere visible is the honest measure of the whole arrangement, which is the argument the sequence in security foundations makes for restore testing over any purchase.