Data backup methods are the different techniques used to create recoverable copies of business information, each trading off backup speed, storage cost, and how quickly you can restore. The eight covered here range from traditional scheduled copies to continuous, real-time protection.
The method you choose matters more than it used to. Business-critical data no longer sits only on servers you control. It lives in SaaS platforms like Salesforce, where the vendor protects the infrastructure but you remain responsible for your own records, metadata, and configuration.
A single integration error, bulk update mistake, or malicious deletion can erase years of operational data. Weekly CSV exports are not a recovery plan, and the gap only becomes visible when someone needs a restore.
This guide explains each of the eight data backup methods, compares them directly, and shows how they apply to Salesforce data backup methods specifically, including what to automate and how often to run it.
Understanding Your Backup Requirements
Recovery Time Objective (RTO) sets how quickly you must restore operations after an incident. Mission-critical systems may need sub-hour recovery, while archival data can tolerate day-long restoration windows. Our guide to Recovery Time Objective covers how to calculate a realistic target.
Recovery Point Objective (RPO) defines how much data loss the business can absorb. Financial transactions typically demand near-zero loss, while reporting systems might tolerate a day of changes. The distinction between Recovery Point Objective and RTO drives most architecture decisions.
Retention and compliance mandates vary by industry and geography. Healthcare organizations need HIPAA-aligned retention, financial services require auditable change history, and businesses operating in the EU must account for GDPR data residency and erasure obligations.
The table below maps common business profiles to the requirements that typically follow from them.
Data Backup Methods in Salesforce
Salesforce data backup methods differ from traditional infrastructure backup in one fundamental way: you cannot back up the server. There is no volume to snapshot and no virtual machine to image. Everything must be captured through the API.
That constraint changes what a complete backup means. A Salesforce backup has to capture four distinct layers, and missing any one of them produces a restore that fails when it matters.
- Records. The field values in standard and custom objects. This is the layer most people picture, and the only layer native exports reliably cover.
- Metadata. Custom objects and fields, validation rules, flows, page layouts, permission sets, and profiles. Records restored into an org whose metadata has changed will not behave the way they did before.
- Files and attachments. Salesforce Files, ContentDocument versions, and legacy attachments, which are stored separately from record data.
- Relationships. Parent-child links between objects. Restoring records without preserving relationship integrity produces orphaned data that satisfies a row count but breaks reporting and automation.
Native tooling leaves real gaps. The Recycle Bin retains deletions for 15 days, subject to a storage cap that can purge sooner, and never captures overwrites. The Data Export Service produces a zip of CSV files, available weekly in Enterprise, Performance, and Unlimited editions and every 29 days elsewhere.
Several documented constraints limit its usefulness as a recovery mechanism. Export files are deleted 48 hours after the notification email, not counting weekends. Formula and roll-up summary fields are always excluded. The service does not run in sandboxes, and Salesforce does not guarantee a completion time.
Most importantly, the export contains data, not metadata, and provides no restore function. Recovery means manually reloading CSVs and rebuilding relationships by hand.
Traditional Backup Methods
Traditional backup methods create scheduled copies at predetermined intervals. Full, incremental, and differential backups have decades of operational history behind them and remain the foundation of most strategies, including in Salesforce.
Full Backup
A full backup captures every selected record, file, and configuration at a single point in time. It serves as the baseline every other method measures against.
In Salesforce, a full backup means a complete org snapshot: all object data, metadata, and attachments captured together, which is what makes it the only method that can rebuild an org from scratch.
- Strengths: fastest restore with no dependency chain, satisfies point-in-time compliance archives, and creates a clean baseline before major changes.
- Limitations: longest run time, highest storage and API consumption, and potential performance impact during the backup window.
- Best used for: quarterly compliance snapshots, pre-deployment preservation, and baselines after significant configuration changes.
Incremental Backup
An incremental backup captures only what changed since the last backup of any type. It is the method that makes frequent backup schedules affordable.
Salesforce backup platforms lean on incrementals heavily, because change-only capture is what keeps API consumption manageable in orgs with high transaction volume.
- Strengths: completes in minutes, conserves storage and API calls, and supports tight recovery point objectives.
- Limitations: restore requires the base backup plus every subsequent increment, and one missing link breaks the chain.
- Best used for: high-change environments where frequent protection matters more than restore simplicity.
Differential Backup
A differential backup captures all changes since the last full backup, always measuring against the same baseline rather than the previous job. That produces a two-file restore, which removes the chain-integrity risk incrementals carry.
- Strengths: simpler and faster restore than incremental chains, with less exposure to a single corrupted file.
- Limitations: each differential grows larger until the next full backup, making it less storage efficient than incremental.
- Best used for: organizations that want daily coverage and value restore simplicity over storage efficiency.
Modern Automated Approaches
Automation is what separates a backup policy from a backup habit. Scheduled jobs run whether or not anyone remembers, retention applies consistently, and failures surface as alerts rather than as surprises during a restore.
Synthetic Full Backup
A synthetic full backup produces a complete backup without reading from the production system. The platform takes the existing baseline, applies accumulated incrementals inside backup storage, and writes a fresh full copy.
Consider a global org running around the clock with no maintenance window. Incrementals run every few hours against production, and the synthesis job assembles a new full backup overnight in storage, so production never absorbs the load of a full capture.
- Strengths: removes backup windows and bandwidth spikes while preserving single-file restore simplicity.
- Limitations: requires an enterprise-grade backup platform and adds operational complexity around the synthesis process.
- Best used for: large datasets with continuous operations and no acceptable downtime window.
Continuous Data Protection (CDP)
Continuous data protection eliminates scheduled windows entirely, capturing every modification as it happens and enabling recovery to a specific moment rather than a specific job.
In Salesforce, true CDP is constrained by the API. Change capture depends on mechanisms like Change Data Capture and platform events, and API allocations set a practical ceiling on how continuous the capture can be across every object.
The realistic pattern is selective. Apply near-continuous capture to a small set of high-value objects, such as Opportunity or Case, and keep scheduled incrementals across everything else.
- Strengths: near-zero data loss, granular point-in-time recovery, and detailed audit trails.
- Limitations: higher storage cost, greater operational complexity, and in Salesforce, API consumption that scales with change volume.
- Best used for: transaction-level systems where losing individual records carries direct financial or regulatory consequence.
Infrastructure-Level Protection
Infrastructure-level methods operate below the application layer, using storage and virtualization capabilities to protect entire systems quickly.
One clarification matters first: these methods protect infrastructure you own, not SaaS application data. If Salesforce holds business-critical records, infrastructure backup covers none of it, and that gap is easy to miss on a coverage report that only lists servers.
Array-Based Snapshots
Array-based snapshots capture point-in-time images of entire storage volumes at the hardware layer, completing in seconds without consuming application resources.
The trade-off against application-aware backup is granularity. Application-aware backup understands records and relationships, so it can restore one record. A snapshot treats data as blocks, so recovery means restoring the whole volume.
- Strengths: near-instant creation regardless of data volume, with no performance impact.
- Limitations: volume-level recovery only, limited portability between storage platforms, and no application awareness.
- Best used for: rapid disaster recovery on infrastructure you control, paired with application-aware backup for granular restores.
Image-Level Backup
Image-level backup captures complete virtual or physical machines, preserving the operating system, applications, configuration, and data in a bootable image.
This method cannot protect SaaS platforms. There is no machine to image in Salesforce and no bare-metal recovery path, so teams relying on image backup still need a separate API-based strategy for every SaaS platform they run.
- Strengths: complete system recovery including OS and applications, and restoration to dissimilar hardware.
- Limitations: large storage footprint, no selective data recovery, and no applicability to SaaS.
- Best used for: complex on-premises systems with intricate dependencies and configuration.
Real-Time Replication Method
Replication maintains a synchronized copy of a production system so operations can fail over immediately during an outage. Rather than creating periodic copies, it mirrors every change as it occurs.
Backup vs. Replication: What's the Difference?
Backup and replication solve different problems and are not substitutes for one another. Backup retains historical copies you can restore from. Replication maintains a current copy you can switch to.
The difference becomes concrete in a deletion scenario. If someone deletes 40,000 records at 2pm, replication deletes them on the replica within seconds. A backup taken at noon still holds them.
Takeaway: replication protects against infrastructure failure. Backup protects against human error, corruption, and ransomware. Most resilient architectures run both.
Mirror Backup
Mirror backup maintains a synchronized replica of production, enabling near-instantaneous failover. Every insertion, update, and deletion copies to the target in real time.
One warning deserves emphasis, because the name contains the word backup. Mirroring is replication, not backup. It carries no version history, so accidental deletion, bad data loads, and encryption from ransomware all propagate to the mirror immediately and cannot be reversed from it.
- Strengths: near-instantaneous failover and a consistent system state with no complex recovery procedure.
- Limitations: replicates corruption and deletions immediately, requires parallel infrastructure investment, and offers no historical recovery point.
- Best used for: continuity during infrastructure outages, always paired with a retained backup for logical errors.
Building Your Resilient Data Protection Strategy
No single backup method addresses every threat. Resilient strategies layer complementary approaches, balancing cost and complexity against the requirements set at the start.
The Foundation Strategy
Scheduled full backups establish clean baselines, and frequent incrementals narrow the recovery point objective between them. This combination covers most business scenarios at reasonable cost.
Enhanced Protection Strategy
The enhanced layer adds synthetic full backups to remove production impact and continuous protection on the objects that matter most.
In practice, a Salesforce team might apply near-continuous capture to Opportunity, Case, and Account while everything else stays on the scheduled cadence, then use synthetic fulls so the weekly baseline never consumes production API capacity.
Complete Infrastructure Protection Strategy
The complete layer adds array-based snapshots for rapid disaster recovery and selective mirroring for immediate failover across owned infrastructure.
How to Automate Salesforce Data Backups
Automating backup of critical business data means removing every step that depends on someone remembering. Four components carry most of the weight.
- Scheduling. Define backup frequency per object group rather than one blanket interval, so high-change objects get frequent coverage without every object consuming the same API budget.
- Retention policies. Set how long each backup generation is kept and let the platform expire old copies automatically. Retention should be driven by your regulatory obligations, not by available storage.
- Monitoring and alerting. Every job needs a success or failure signal that reaches a person. Silent failures are the most common reason a backup program fails its first real test.
- Automated restore testing. Schedule periodic restores into a sandbox and verify record counts, relationships, and metadata. A backup is only proven when it has been restored.
API consumption deserves specific attention in Salesforce. Backup jobs draw on the same daily API allocation as integrations, so a poorly tuned schedule can compete with production traffic. Excluding objects that do not need protection and relying on incrementals between fulls keeps that manageable.
Takeaway: automation is what turns backup from an intention into a control you can evidence during an audit.
How Often Should You Back Up Business Data?
Back up business data as often as your recovery point objective requires. If losing four hours of data would be unacceptable, a daily backup is already insufficient regardless of how reliable it is.
The table below maps common criticality tiers to a practical starting cadence.
Frequency also has a floor set by tooling. An organization depending on the Salesforce Data Export Service is capped at weekly in Enterprise, Performance, and Unlimited editions, and every 29 days elsewhere, which sets the recovery point objective whether or not the business finds it acceptable.
Industry-Specific Requirements
Requirements differ meaningfully across sectors, and the differences usually show up in retention rather than frequency.
- Healthcare. HIPAA requires documented retention and audit capability for systems holding protected health information, so backup history and access logging matter as much as backup frequency.
- Financial services. Transaction-level protection and long retention windows are standard, and regulated record-keeping rules can require years of retrievable history well beyond typical SaaS defaults.
- SaaS and technology. Customer-facing availability drives the requirement, so tight recovery time objectives and frequent capture usually take priority over long retention.
Strategic Implementation Considerations
Deployment succeeds or fails on sequencing and follow-through rather than on tool selection. The checklist below covers the steps most commonly skipped.
Implementation Sequence
- Inventory what needs protecting, including objects, metadata, files, and any integrations that write into the platform.
- Set recovery time and recovery point objectives per system tier, and get them agreed by the business rather than assumed by IT.
- Establish baseline protection with scheduled full and incremental backups covering data and metadata.
- Verify the first restore into a sandbox before declaring the deployment complete.
- Add advanced layers, such as continuous protection on critical objects, once the baseline is proven.
- Document the runbook, including who executes a restore and what authorization it requires.
- Schedule recurring restore tests and treat a failed test as an incident.
Continuous Strategy Evolution
Backup success is measured by restores, not by completed jobs. A green dashboard confirms that data was copied, not that it can be brought back in a usable state.
Test restores at least quarterly and record how long each takes against the stated recovery time objective. The gap between assumed and actual recovery time is usually where the real risk sits.
The Power of Layered Backup Approaches
Three ideas are worth carrying out of this guide. No single backup method covers every failure mode. Replication is not backup. And a backup that has never been restored is an assumption rather than a control.
For Salesforce specifically, the requirement is narrower than the general backup landscape suggests. Infrastructure methods do not apply, so protection comes down to how well an API-based approach captures records, metadata, files, and relationships, and how quickly it can put them back.
Flosum Backup & Archive is a cloud-based backup solution purpose-built for Salesforce, from an end-to-end enterprise DevSecOps platform. Its composite backup approach captures data, metadata, and configuration together in a single operation, which keeps coverage complete while reducing the API overhead of running full and incremental protection separately.
Talk with one of our experts to see how layered backup coverage works in practice, or request a demo.
Frequently Asked Questions (FAQ)
Thank you for subscribing
