Data backup methods are the ways you make recoverable copies of business data. The eight covered here are full, incremental, differential, synthetic full, continuous data protection, array snapshots, image-level backup and mirror backup.
Each one trades backup speed, storage space and restore time differently, so a good data backup strategy often combines two or three.
Where your data lives changes which types of data backup you can use. If your records sit in a SaaS platform like Salesforce, a server snapshot won't help, because you don't control the servers.
Below, we go through each method, compare them side by side and point out which ones apply to Salesforce.
What should you decide before choosing a backup method?
Start with two numbers. Your recovery time objective, or RTO, is how fast you need systems back after an incident.
Our guide to recovery time objective shows how to set one you can actually hit.
Your recovery point objective, or RPO, is how much data loss you can accept, measured in time. If you can't lose more than an hour of orders, you need a very different setup from a team that can rebuild yesterday's reports by lunch.
The difference between RTO and RPO shapes most of what follows.
Then check what the regulators say. HIPAA's Security Rule requires a data backup plan that creates retrievable exact copies of electronic protected health information.
GDPR Article 32 expects the ability to restore personal data in a timely way, along with regular testing of your safeguards.
How do Salesforce data backup methods differ?
In Salesforce, there's no server for you to back up. You can't snapshot a volume or image a machine, so every data backup has to go through Salesforce's APIs or its export tools.
A complete Salesforce backup has four layers. Records come first: the field values in your standard and custom objects.
Metadata is the second, meaning objects, fields, validation rules, flows, page layouts, profiles and permission sets. Restore records into an org whose metadata has since changed, and they won't behave the way they used to.
Files and attachments are the third, and Salesforce counts them in file storage, separately from record data.
The fourth layer is relationships between parent and child records. It's the easiest one to overlook.
Restore records without their relationships and you get orphaned data. The row count looks right, but reports and automation break.
Salesforce's own tools leave gaps. The Recycle Bin keeps deleted data for 15 days, or until the bin reaches a set size, and it never sees a record that was overwritten instead of deleted.
The Data Export Service gives you CSV files in a zip. According to Trailhead, Enterprise, Performance and Unlimited Editions can export weekly and Professional and Developer Editions every 29 days.
Those zip files are deleted 48 hours after the email goes out. To restore data from one, you reload the CSVs and rebuild the relationships yourself.
For deleted records specifically, see our post on Salesforce Recycle Bin retention.
What are the traditional backup methods?
Full, incremental and differential backups all run on a schedule. They're a sensible place to start a backup strategy, in Salesforce too.
The table compares the three on the things you'll care about when you pick a schedule.
1. Full backup
A full backup copies all the data you've selected, every record, file and setting, at one point in time. The other backup methods build on top of it.
In Salesforce, a full backup is a copy of the whole org, with data, metadata and attachments together. It's what you'd rebuild an org from.
Restores are as fast as they get, because there's one file and no chain to depend on.
The catch is that a full backup takes the longest to run and uses the most storage space and API calls. So you might save it for a compliance snapshot, a copy before a big deployment or a fresh baseline after major configuration changes.
2. Incremental backup
An incremental backup copies only the data that has changed since the last backup of any kind. That's what makes frequent backups affordable.
In a busy Salesforce org, incremental backups keep API use down, because each run picks up only the changes. They finish quickly and support a tight RPO.
The trade-off shows up at restore time. You need the last full backup plus every subsequent incremental backup, and if one file in that chain is missing, the restore fails.
That makes incremental backup a fit for orgs with a lot of change, where frequent protection outweighs a simple restore.
3. Differential backup
A differential backup copies all the data that has changed since the last full backup. Because differential backups always compare against the same baseline, a restore needs just two files: the full backup and the latest differential.
That makes restores simpler and faster than working through an incremental chain. One corrupted file also does less damage.
The downside is size. Each differential grows until the next full backup and needs more storage space than incremental backups would.
If your team wants daily coverage and cares more about easy restores than storage capacity, differential backups are a good fit.
What do automated backup methods add?
A backup policy only protects you if the backup operations actually run. Automation makes sure they do and applies retention the same way every time.
It also turns a failed job into an alert, instead of a nasty surprise halfway through a restore.
4. Synthetic full backup
A synthetic full backup builds a new full copy without reading from production. The backup software takes the last full backup, applies the incremental backups since then inside backup storage and writes out a fresh full copy.
That's what makes an incremental forever backup approach possible: one initial full backup, then only incremental backups from production.
Picture an org that's in use around the clock with no maintenance window. Incremental backups run against production every few hours, and the synthetic full backup gets assembled overnight in storage.
Production never carries the load of a full backup. You keep one-file restores without the backup window or the bandwidth spike.
You do need backup software that supports it, and it's one more process to monitor. Our synthetic backup guide goes deeper.
5. Continuous data protection (CDP)
Continuous data protection captures every change as it happens. Instead of recovering to the last scheduled job, you can recover to a specific moment, which minimizes data loss.
In Salesforce, capture that reads through the REST or SOAP API draws on your org's daily API allocation. So continuous capture has limits there.
A selective approach works: near-continuous capture on a few high-value objects like Opportunity or Case, and scheduled incremental backups for everything else.
You lose very little data and get a detailed change history. You also take on more backup storage, more to run and API use that climbs with the volume of change.
So you may want to keep CDP for transaction data, where losing a single record costs real money or causes a regulatory problem.
Which backup methods protect infrastructure, not applications?
The next two methods work below the application. They use storage and virtualization features to protect whole systems quickly, but only systems you own.
If Salesforce holds your critical data, these methods don't cover it. That's an easy gap to miss when the coverage report only lists servers.
6. Array-based snapshots
An array snapshot captures a point-in-time image of an entire storage volume at the hardware level. It's quick to create, even for very large volumes.
What you give up is detail. A snapshot sees blocks, not records, so getting one record back means restoring the whole volume.
Snapshots also don't move easily between storage systems. They're good for fast recovery and disaster recovery on infrastructure you control, paired with an application-aware backup for single records.
7. Image-level backup
Image-level backup captures a whole virtual or physical machine as a bootable image, including the operating system, applications, settings and data. You can recover the full system after a hardware failure, even onto different hardware.
It takes a lot of storage and doesn't let you pick out individual items. It also can't protect SaaS platforms, because there's no machine to image in Salesforce.
So teams that use image backup for on-premises systems still need an API-based backup for every SaaS platform they run.
What's the difference between backup and replication?
Backup and replication aren't the same thing. Backup keeps multiple versions you can restore from, and replication keeps a current copy you can switch to.
The difference is easiest to see with human error. Say someone deletes 40,000 records at 2 p.m.
Replication deletes them from the replica within seconds. A backup taken at noon still has them.
Here's the comparison in full.
8. Mirror backup
A mirror backup keeps a synchronized copy of production so you can fail over almost instantly. Every insert, update and delete gets copied to the target as it happens.
Despite the name, a mirror backup is replication, not backup. It keeps no history, so an accidental deletion, a bad data load or ransomware encryption all land on the mirror straight away.
It also needs parallel infrastructure. Use a mirror backup to stay up through outages, and keep a real backup next to it for logical errors.
Where should you store backups?
Where you store backups matters as much as the method. Local storage, network attached storage or an external storage device gives fast recovery, but a fire or a ransomware attack can reach them too.
Cloud backup sends copies to a cloud storage service run by cloud providers, reachable over an internet connection. Offsite backups like these survive a local disaster.
An immutable backup can't be changed or deleted for a set period, which helps against ransomware. Keeping copies in multiple backup destinations follows the 3-2-1 backup rule.
How do you combine backup methods into one strategy?
No single method covers every kind of failure. A resilient data backup strategy layers a few of them, weighing cost and complexity against your RTO and RPO.
Treat this table as a starting point. The cadences are examples to adapt, not benchmarks.
For the Salesforce side, read our guide to building a Salesforce data backup and recovery strategy.
How do you automate Salesforce data backups?
The goal is to take out every step that depends on someone remembering. Scheduling comes first.
Set the frequency per group of objects rather than one interval for everything. Busy objects get frequent coverage without the whole org using the same API budget.
Retention is next. Decide how long each backup is kept, let old copies expire automatically and base those periods on your regulatory obligations, not on free storage capacity.
Every job needs a success or failure signal that reaches a named person. A failed job nobody sees is as bad as no job.
Finally, restore into a sandbox on a schedule and check record counts, relationships and metadata. A backup isn't proven until it's been restored.
Backup jobs that read through the REST or SOAP API use the same daily API allocation as your integrations. Leaving out objects that don't need protection keeps that in check.
There's more in our posts on automated Salesforce backup and restore and Salesforce backup best practices.
How often should you back up business data?
As often as your RPO requires. If losing four hours of data isn't acceptable, a daily backup isn't enough, however reliable it is.
This table gives a starting cadence for each type of data. Adjust it to your own RPO.
Your backup solutions can set a floor, too. If you rely on the Data Export Service, your RPO is a week at best, or 29 days on some editions.
Some industries have extra rules. In healthcare, HIPAA requires a data backup plan and lists periodic testing of contingency plans, so keep a backup history and a record of restore tests.
In EU financial services, DORA Article 12 requires a backup policy that sets a minimum backup frequency based on how critical the data is. Restores onto in-house systems have to use infrastructure segregated from the source system.
What should you check when you roll out a backup plan?
Start by listing every object, metadata type and file store that needs protecting. Include the integrations that write into the org, since they can push bad data straight back in after a restore.
Next, agree RTO and RPO for each tier with the business, not just IT. Check retention against what you're actually obligated to keep.
Then set up scheduled full and incremental backups that cover data, metadata and files.
Before you call the rollout done:
- Run a full test restore into a sandbox.
- Add continuous protection on critical objects once the baseline works.
- Write the restore runbook, including who approves a production restore.
- Test restores at least quarterly, and treat a failed test as an incident.
To know it's working, measure successful recovery, not finished jobs.
Time each test restore against your RTO, and use our disaster recovery test plan checklist to structure the tests.
How does Flosum back up Salesforce?
Infrastructure methods don't apply to Salesforce. What matters is how well an API-based backup captures records, metadata, files and relationships, and how quickly it can restore data.
Flosum Backup & Archive protects Salesforce data, metadata, files, attachments and the relationships between objects. It runs scheduled, incremental and high-frequency backups, and restores to a point in time at field, record or full-org level.
It runs as a Flosum Cloud App, either Flosum-hosted on Flosum-managed AWS or customer-hosted on your own AWS, Azure or GCP.
A hybrid option lets Flosum run the application while backups land in an S3 bucket or Azure Blob container you own. For single records, see our guide to recovering deleted records in Salesforce.
FAQs
Book a demo to see how a restore works in your own org with Flosum Backup & Archive.
Thank you for subscribing
