Backup, Recovery & Operational Resilience

A Salesforce backup is not a recovery plan

JSBC Labs8 November 20268 min read

A green backup job does not prove recovery

An integration overwrites thousands of customer consent values. The weekly export completed successfully, so the incident team assumes recovery is straightforward. They then discover that the affected records span several objects, the export is four days old, files were handled separately, identifiers changed during recreation and active automations begin processing restored rows. The backup exists; the business state cannot yet be recovered safely.

The JSBC Labs position is that backup is an input to a recovery system. A copy protects against loss only when the organisation can locate the correct version, restore dependencies in a controlled sequence, preserve or remap identity, suppress harmful side effects and prove the resulting state. Job success answers “did we capture something?” Recovery planning answers “can the business resume within an accepted loss and time window?”

Define recovery objectives by business process

Start with failure scenarios: accidental deletion, faulty bulk update, integration corruption, malicious change, metadata deployment error, file loss and a wider continuity event. For each, define the recovery point objective—the maximum acceptable data loss—and the recovery time objective—the maximum acceptable interruption. A weekly export cannot meet a four-hour RPO, regardless of how reliably it completes.

Set objectives for capabilities rather than one undifferentiated org. Service cases may require tighter recovery than old campaign responses; authentication configuration may need faster restoration than historical dashboards. Name the incident commander, technical owner, business validator and approval authority for destructive recovery actions. Recovery begins under pressure, so decision rights and escalation thresholds must be explicit before anyone starts importing data.

Back up the complete service, not one data plane

Salesforce distinguishes business data from metadata such as fields, layouts, reports, permissions and Apex. Files and content add another plane, while connected systems may hold documents, identities or financial events that Salesforce only references. A complete inventory maps each critical process to records, metadata, files, integration state, encryption or credential dependencies and external systems of record.

Choose a capture method for each plane. Salesforce documents Data Export Service, Data Loader, Bulk API, Salesforce Backup and partner solutions for data, while source control and supported metadata retrieval protect customisation. Include new objects and file versions deliberately. Do not call a sandbox a backup: refreshes copy current state and can overwrite the very environment needed for investigation, whereas recovery requires retained, dated and independently protected versions.

Know what an export does not preserve

Data Export Service produces CSV archives on a weekly or monthly cadence depending on edition. Salesforce notes that delivery can be delayed, links expire, large orgs produce multiple archives and formula or roll-up summary values are excluded because they are derived. Scheduled “include all data” selections also need attention when new objects are introduced. These are manageable characteristics, but they invalidate assumptions that an export is a point-in-time image ready for immediate replay.

Automate collection into controlled storage where policy permits, validate expected files and object counts, and alert when delivery or volume deviates. Record the snapshot time, schema version, encryption state and retention class. Test whether the backup can be read without the employee who scheduled it or the workstation that downloaded it. A recovery asset must survive staff changes, account suspension and the incident affecting the production org.

Restore relationships as a dependency graph

Salesforce warns that restore order matters if relationships are to be preserved. Recreated records receive new Salesforce IDs, so parent records often need restoration before children, followed by an old-to-new ID mapping. Stable external IDs can make upsert and relationship reconstruction safer, but only when they are unique, retained in the backup and governed as business identifiers.

Build an object dependency map covering master-detail, lookup, junction, self-referential and polymorphic relationships. Define cycles that require staged updates and identify objects with special access rules. Salesforce Backup can expose related records and export ID mappings and row-level errors, but operators still need to decide the correct business scope. Restore the smallest coherent aggregate that re-establishes invariants rather than every row sharing a timestamp.

Control automation before data re-enters the org

A technically correct import can trigger duplicate emails, platform events, outbound calls, rollups, approvals, flows and Apex. Decide which automation must run to rebuild derived state and which must be suppressed to avoid repeating real-world consequences. Avoid a single global bypass that disables every invariant. Use governed, time-bound controls with named operators, narrow scope and a recorded reason.

Plan for validation rules, duplicate rules, record locks, ownership, sharing recalculation and required reference data. Restore under a dedicated identity with least privilege sufficient for the run and preserve audit context where supported. External systems need reconciliation because Salesforce rollback cannot reverse a message already consumed or a payment already processed. Recovery finishes only when cross-system state agrees, not when an import job reports success.

Rehearse partial and full recovery

Run quarterly drills for representative failures: one field on a record set, a deleted parent with children, files, a metadata component and a cross-system transaction. Salesforce Well-Architected guidance recommends documented runbooks, regular partial restore tests and periodic full recovery exercises. Use a safe non-production environment, production-shaped volume and the same permissions, tools and approval steps intended for a real event.

Measure discovery time, backup selection, preparation, restore throughput, error handling, reconciliation and business validation. Record every manual transformation and ambiguous decision; those are automation and documentation opportunities. A drill should also test abort and rollback criteria. If the team discovers that the chosen snapshot is wrong halfway through, it needs a controlled way to stop without compounding corruption.

Prove recoverability continuously

Monitor backup completion, delay, coverage, object and file volumes, retention, encryption and failed restores. Sample records from each critical domain and verify that the snapshot contains their values, relationships and required content. Reconcile metadata backups with the release repository and investigate production changes that exist in neither. Protect backup administrators and exports as privileged access because historical copies can contain data users are no longer allowed to see.

Review retention against legal deletion and privacy obligations, including copies held outside Salesforce. Update runbooks whenever the data model, integration landscape, automation or business priority changes. Report recovery readiness to decision-makers using tested RPO and RTO results, not the percentage of green backup jobs. The useful measure is simple: after a realistic failure, can the organisation restore a coherent, secure service within its promised window and demonstrate what was recovered?