Cloud Backup and Disaster Recovery

A recovery design starts with the business service that must return. We map the users, customer journeys, operational decisions and legal or contractual duties that depend on it, then identify the applications, data, identities, secrets, networks, certificates, configuration and suppliers beneath that service. A database restored without its encryption key, identity provider, message queue or current application build is not a recovered service. The record therefore distinguishes files, records, systems and a usable business outcome instead of treating them as the same recovery unit.

Recovery Point Objective describes the maximum acceptable data-loss interval expressed in time; Recovery Time Objective describes the target time for restoring the agreed service after disruption. Neither number should be copied from a product brochure. The client supplies impact tolerance, processing deadlines, manual workarounds and priority. We test whether the current backup interval, replication lag, restore throughput, decision process and available people can support those targets. An aspiration remains labelled as such until architecture and rehearsal evidence make it defensible.

Different failure modes need different responses. Accidental deletion may require a granular restore. Corruption may require a known-good point before the fault began. A failed region may call for rebuilt infrastructure and traffic redirection. Ransomware may require containment, evidence preservation, credential replacement and recovery into a clean environment rather than immediate restoration over compromised systems. Supplier failure, lost keys, unavailable administrators and damaged control planes are also considered where material. One generic runbook cannot safely cover every event.

The written commission fixes the boundary: assessment, architecture, product configuration, migration, restore testing, disaster-recovery exercise or separately managed operation. It names the services, tenants, workloads, data sets, locations, retention classes, scenarios and evidence included. It also states who may declare a disaster, approve data loss, invoke a secondary environment and authorise failback. Legal notification, forensics, crisis communications and business continuity beyond the technical recovery boundary require named owners or separate specialists.

The protection inventory covers databases, file systems, virtual machines, containers, object stores, SaaS data, endpoints, source code, infrastructure definitions, configuration, certificates, secrets and the documentation needed to rebuild. Each item has an owner, source of truth, capture method, schedule, retention, location, encryption boundary and restoration method. Snapshots, synchronisation, replication, archive and backup are classified by what they can and cannot recover. A second live replica may copy corruption quickly; a long archive may preserve records but be too slow for operational recovery.

Copy placement follows the threats and dependencies. Multiple copies should not share every account, credential, control plane, region or deletion authority. Depending on the estate, the design may use off-site, offline, logically isolated or immutable copies, separate administration, delayed deletion, object locking, versioning and multi-person approval. Immutability is a configured control with retention and cost consequences, not a magic property. Its effective state, administrative escape routes, expiry behaviour and recovery access have to be inspected and tested.

Backup administration receives a narrower trust boundary than ordinary production operation. We separate service identities where possible, restrict destructive actions, protect keys and recovery credentials, log policy changes and monitor attempts to disable jobs or shorten retention. Emergency access must remain available if the primary identity provider is down or compromised, but it is protected outside the same failure domain and exercised under controlled conditions. A cloud provider secures its platform; the customer still owns workload selection, policy, identity, configuration and recovery testing within the shared-responsibility model.

Retention is linked to detection time, correction needs, legal holds and cost. Keeping only the newest copy can preserve an undetected corruption, while indefinite retention may create privacy, discovery and expense problems. We define daily, weekly, monthly or event-based points only where the business case supports them and record deletion, expiry and hold behaviour. Encryption covers transit and storage, but key loss can make a healthy-looking backup unusable. Key custody, rotation, escrow and recovery are therefore part of the design boundary.

A recoverable service needs more than a data copy. The runbook identifies prerequisites, infrastructure build, network and DNS changes, identity, keys, databases, queues, storage, application tiers, integrations, scheduled jobs and external providers in their required order. It distinguishes what can be automated from what requires judgement. Infrastructure as code, versioned configuration and golden images can shorten rebuilds, but they also need protected sources, compatible dependencies and an exercised route into the recovery environment.

Recovery location is selected per scenario. A file may return in place; a compromised workload may need an isolated clean room; a site outage may require another zone, region, cloud or physical location. Capacity, quota, image availability, data sovereignty, network reach, certificates, DNS time-to-live, supplier access and security controls must exist before invocation. Cold, warm and hot strategies trade cost, data loss and return time differently. Labels are not acceptance evidence; the actual path and representative scale matter.

Cyber recovery adds a trust question: which recovery point and which components are clean enough to use? Restoration is coordinated with containment and, where commissioned, incident-response or forensic specialists. Known-good time, credential rotation, configuration integrity, malware scanning, vulnerability treatment and connection to still-compromised systems need decisions. Starting a restored server quickly can reintroduce the attacker or overwrite evidence. The technical recovery plan therefore records dependencies on investigation and the authority that can release the service.

Validation happens at service level. File presence and checksum can be useful, but users may still be unable to authenticate, transactions may not reconcile, queues may replay twice, integrations may hold stale credentials and scheduled tasks may run out of order. Acceptance tests cover data consistency, representative business transactions, permissions, observability, performance within stated conditions and downstream effects. Any manual reconciliation, lost interval, deferred interface or unsupported platform is recorded before the service is declared available.

Successful-job status is only one signal. Operations should observe source coverage, last protected point, missed schedules, changed data volume, replication lag, retention state, immutable lock, repository capacity, key and certificate expiry, catalogue consistency, malware indicators, restore-test age and alert delivery. A green dashboard can still hide an excluded database, expired credential or unprotected new tenant. Coverage is reconciled against the authorised inventory and material changes trigger review.

Change management keeps recovery aligned with production. New services, regions, dependencies, schemas, encryption keys, identity providers and release patterns may invalidate a runbook or alter restore time. Backup policies and infrastructure definitions are versioned where practical, changes are reviewed and emergency exceptions expire. Product updates, deprecations, licence limits and provider terms are tracked by their owners. Recovery requirements are included in the definition of done for material platform changes rather than discovered during an incident.

Cost is modelled across more than stored gigabytes. It may include backup software, protected instances, API operations, snapshots, immutable retention, retrieval, egress, secondary compute, reserved capacity, network transfer, testing environments, support and staff time. A low-cost archive can become expensive or too slow during a full restore; a continuously warm environment can cost far more than its business impact justifies. The proposal separates NobleJackal work from provider consumption and records the assumptions behind estimates.

Ongoing responsibility is explicit. The operating matrix names who watches failed jobs, investigates gaps, approves policy changes, manages capacity, rotates keys, runs restores, maintains runbooks, contacts suppliers and declares or closes recovery. Monitoring hours, response expectations, change allowance and escalation routes exist only when purchased in writing. A design or implementation project does not silently provide 24/7 monitoring, unlimited storage, incident response or a guaranteed recovery service.

Testing is tiered. A backup integrity check does not replace a restore; a file restore does not prove an application; an application restore does not prove regional failover or cyber recovery. The test plan states scenario, scale, recovery point, environment, participants, time source, safety conditions, abort criteria and evidence. Tabletop exercises test decisions and communication. Technical exercises test rebuild, restore, validation, routing and return. Production failover requires separate authority because it can affect real users and data.

Observed RPO and recovery duration are reported with their measurement boundaries. The clock may include detection, declaration, access approval, provisioning, data transfer, restore, replay, reconciliation, business validation and release. Test data volume, bandwidth, concurrency, provider limits, cache state and staff availability are recorded. A result from a small sample is not extrapolated silently to the whole estate, and a target met once is not presented as a permanent guarantee under every future incident.

Failback is part of recovery, not an afterthought. The plan covers data accumulated in the secondary environment, conflict handling, synchronisation direction, maintenance windows, DNS or traffic changes, validation and rollback. Some events require a new primary rather than a return to the old one. Cyber incidents may also require evidence retention and staged reconnection. The decision record names what was tested, what remained simulated and who accepts the residual risk before ordinary change processes resume.

Handover includes the service and dependency map, RPO and RTO register, protection policies, retention and key records, architecture, access model, monitoring and escalation, restore and disaster runbooks, test evidence, supplier contacts, known limitations and next exercise date. Secrets move through an approved secure channel. The closeout separates delivered, accepted, deferred and excluded items. No statement implies zero data loss, guaranteed restoration, uninterrupted operation, ransomware immunity, compliance, certification, insurer acceptance, ranking, leads or revenue.