Business backup & disaster recovery services

Backup and recovery are different questions

Backup protects data: it keeps a copy so that a deletion, a corruption or an encryption event can be reversed. Recovery protects the business: it describes how operations resume, on what equipment, in what order, and who decides. The two are connected but not interchangeable. An organisation can hold excellent backups and still be unable to work for a week, because nothing established which systems had to return first or where people would work while they did. Buy backup as one decision and recovery as another, and make sure somebody owns each, because they fail in different ways.

• Backup answers: can we get the data back.
• Recovery answers: can we trade again, and how soon.
• Two owners, because the two failure modes differ.
• Excellent backups do not imply a usable recovery plan.

Contingency planning has a published vocabulary, and it is worth using

The reason conversations about recovery drift is that the words are used loosely. NIST's Contingency Planning Guide for Federal Information Systems, SP 800-34 Revision 1, published in May 2010 and corrected in November of that year, fixes them. Contingency planning there produces not one document but a set of related plans: a business continuity plan for sustaining mission and business functions through a disruption, a continuity of operations plan for the organisation's essential functions, a disaster recovery plan for restoring an information system after a major disruption, an information system contingency plan for the system-specific recovery and resumption, and a crisis communications plan for what is said, internally and externally, while it is happening. It also sets out the sequence the work follows: a policy statement, a business impact analysis, preventive controls, contingency strategies, the plan itself, then testing, training and exercises, then maintenance. Reading your own arrangements against those five plan types is a quick way to find the gap — most small and mid-sized businesses have the disaster recovery plan without the business continuity plan, which is why the technical restore works and the trading does not.

• Name which of the five plan types you actually have.
• Write the business impact analysis before choosing any technology.
• Separate the continuity plan from the technical recovery plan.
• Put the crisis communications plan in writing, with named spokespeople.
• Diary the test and the review as recurring events, not one-off projects.

Recovery objectives are business numbers, and the standard says so

Two figures describe what recovery has to achieve, and they are defined rather than invented. The recovery point objective is the point in time to which data must be recovered after a disruption, expressed as the maximum acceptable amount of loss measured in time. The recovery time objective is the target period within which a system or function has to be restored so that the impact stays inside acceptable limits. Both are decisions about what the business will accept, not specifications a supplier proposes, and both are cheaper to meet for some systems than others. The standard carries the arithmetic into the controls as well: in the contingency planning family of NIST SP 800-53 Revision 5, CP-9 System Backup requires backups of user-level information, system-level information and system documentation at a frequency consistent with the recovery time and recovery point objectives, and retention sufficient to meet them. That is the sentence to quote when a provider's default schedule does not match the number the business signed off. The workable method is to sort systems into a small number of tiers — those that must be running within hours, those that can wait a day, those that can wait longer — and set the pair of objectives per tier rather than per application. The cost of protection rises steeply as the acceptable window shrinks, so a shorter number should be justified rather than assumed.

• How long the system may be down, per tier.
• How much data may be lost, in time, per tier.
• Which systems must be back before others can function.
• Who signs off on each tier, and why the number is what it is.
• Whether the backup frequency purchased is consistent with that number.

What is protected, how often, and for how long

Coverage is not a single setting. File-level protection restores documents but not the server that held them; an image restores the whole machine but takes longer; application-consistent protection understands the database and produces something that will actually start. Databases and line-of-business applications usually need the third kind, and that is where protection is most often assumed rather than verified. Retention is the other half, and it is not purely a recovery decision: for regulated records it is a compliance decision, which is why the retention question belongs in the first conversation rather than the last. Decide how often a protected copy is taken against your working rhythm, how long each is kept, and whether the pattern keeps older monthly and yearly copies for the records that must survive that long.

• File, image or application-consistent, named per system.
• How often a protected copy is taken, and at what time of day.
• How long daily, monthly and yearly copies are retained.
• Whether a retention rule, not only a recovery objective, sets that period.
• Whether data held inside a hosted application is protected at all.

Ransomware changed what protection has to be, and immutability has named modes

Encryption incidents exposed a weakness in conventional backup design: a copy that the production environment can write to, and that uses credentials the production environment holds, can be encrypted alongside the data it was protecting. The published countermeasure is separation — copies that cannot be altered for a period you choose, credentials an attacker on the network does not possess, and at least one copy that is not reachable from production — and the widely repeated practice is to keep offline, encrypted copies and to test a restore rather than assuming it works, because ransomware commonly targets the accessible backups first. Immutability is now a product feature with documented modes, and the mode matters more than the label. Amazon S3 Object Lock stores objects in a write-once, read-many state, with a retention period and an optional legal hold. In governance mode a user with special permissions can still alter the retention setting or delete the object; in compliance mode a protected version cannot be overwritten or deleted by any user, including the account's root user. Azure's immutable storage for blobs works the same way: a time-based retention policy lets objects be created and read but not modified or deleted while it is in effect, and once the interval expires they can be deleted but not overwritten, while a legal hold lasts until it is explicitly cleared. The Azure feature also carries a records angle worth knowing: Microsoft had Cohasset Associates assess its WORM configuration against CFTC Rule 1.31, FINRA Rule 4511 and SEC Rule 17a-4(f), which is the kind of validation a regulated buyer can ask for by name. The practical questions are which mode is configured, who holds the credentials that could shorten the window, and how a restore is performed when the production environment is untrusted.

• Immutable copies, held for a period you specify.
• Which retention mode is configured, and who can shorten it.
• Backup credentials separate from the production environment.
• At least one copy unreachable from the production network.
• A documented restore path that assumes production is compromised.

Recovery strategies, and the failback nobody plans for

There is a spectrum of recovery approaches, and each buys a shorter outage with more cost and more complexity, and the standard names the rungs. The alternate site categories in SP 800-34 are worth using precisely because they are gradeable: a cold site is a facility with space, power, telecommunications and environmental controls but no IT equipment, so the equipment has to be brought in; a warm site is partially equipped, holding some or all of the hardware, software, telecommunications and power; a hot site is sized and configured to the requirement with the supporting infrastructure and staff, and can be taken over rapidly. Mobile sites, mirrored sites, service bureaux and reciprocal agreements sit alongside those three as different arrangements for the same need. NIST SP 800-53 Revision 5 turns that vocabulary into named controls: CP-6 Alternate Storage Site and CP-7 Alternate Processing Site both carry a separation-from-primary-site enhancement, and CP-7 adds a priority-of-service provision so that essential functions are served first when the alternate site is activated. Bringing operations back to the normal environment raises the same questions again, and it is the step most often left undocumented, so the plan should say what the route back is, what the replication lag means for transactions already lost, and how traffic is redirected.

• The chosen strategy, expressed as one of the standard site types.
• Whether the alternate site is genuinely separated from the primary.
• Data replication lag, and what that means for lost transactions.
• How traffic is redirected, and whether addresses change.
• The documented route back to normal operation after the event.

Testing and declaring are where the plan becomes real

A recovery plan is only as good as its last exercise, and the guidance treats that as the discipline rather than the epilogue. NIST's Guide for Cybersecurity Event Recovery, SP 800-184, published in December 2016, is about exactly that work: planning the recovery, building playbooks for the events you can foresee, testing them, and improving the plan from what the test and the real events taught. Restoring a single file tests almost nothing; the exercise that matters restores a system, proves the application starts, confirms users can reach it, and records how long each step took against the objective. Then decide who may declare a disaster, because the decision is usually needed before the full picture is available and waiting for certainty is itself a choice. The storage layer has its own guidance too: SP 800-209, Security Guidelines for Storage Infrastructure, published in October 2020, sets out recommendations that reach beyond ordinary IT practice into data protection, isolation, restoration assurance and encryption, and it is direct on one point worth repeating — physical backup media for sensitive data should be held far enough from the primary data to be out of the same disaster.

• A system restore exercise, timed against the objective.
• Who may declare a disaster, and who may stand it down.
• A playbook for the two or three event types that are most likely here.
• Dependencies, because systems rarely restore usefully in isolation.
• Physical copies held far enough away to share no single point of failure.

What to gather, and how HighGround helps

Bring the system list with its tier and objectives, the data volumes involved, which systems depend on which, any retention obligation that applies, the immutability mode the business needs, and the credentials and access a provider would require. HighGround works as an advisor-assisted channel rather than a directory, scoping a requirement around the systems that actually have to come back and the obligations attached to them. Fit cannot be judged responsibly without knowing what has to be recoverable and how quickly, so the tiering and the objectives come before any shortlist. An inquiry places no order and commits you to nothing, and HighGround may receive compensation from a provider on a completed purchase.

• System list with tier, recovery time and recovery point objectives.
• Data volumes, growth, and which systems depend on which.
• Retention obligations from regulation, contracts or insurers.
• The immutability mode and the period it has to cover.
• Who on your side owns testing, and when the last test was.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions