Salesforce backup and recovery is the practice of copying your Salesforce data and metadata to a separate, independently controlled store, then restoring it accurately after loss or corruption, guided by a written Salesforce data backup and recovery strategy. Salesforce operates and secures the platform, but under its shared responsibility model, protecting and recovering the data you put into it is your job, not Salesforce's.
This guide covers who is responsible for Salesforce data, what causes loss, how backup differs from archiving, how to set recovery targets (RPO and RTO), how retention maps to compliance, and how to restore records without breaking your automations.
Does Salesforce back up your data, and who is responsible?
Salesforce keeps your org running, replicated, and available at the infrastructure level, but that is disaster recovery for the platform, not a backup of your business data. Under the Salesforce shared responsibility model, Salesforce secures the infrastructure while the customer is responsible for protecting and recovering their own data and configuration. If a user, an integration, or an automated process deletes or overwrites records, that change propagates to Salesforce's copies too.
Salesforce's own history makes the point. Salesforce retired its paid, last-resort Data Recovery Service on July 31, 2020, then, as the Salesforce Admins blog explains, reinstated it in March 2021 after customer feedback and retired it again after launching its own backup product in fall 2021, now sold as the paid Backup & Recover add-on. Either way, getting your data back depends on a backup you put in place, whether that is Salesforce's add-on or a dedicated backup solution.
The practical takeaway: platform-level resilience protects against Salesforce's own hardware and datacenter failures. It does not protect against the far more common causes of loss, which start inside your own org. Read more on the Salesforce shared responsibility model and how it shapes risk and governance decisions.
What causes data loss in Salesforce?
Most Salesforce data loss is self-inflicted rather than caused by platform outages. The common triggers are:
- Accidental deletion or a bad mass update by a user or admin
- A faulty data load, import, or integration writing wrong values at scale
- A misconfigured automation (Flow, trigger, or batch job) overwriting fields
- A deployment or package install that changes or removes metadata
- Malicious action or a compromised account
- More recently, agentic and AI-driven processes acting on records at machine speed
AI raises the stakes. When an automated agent can touch tens of thousands of records in a minute, a single bad rule can cause loss faster than a human can react. See what causes data loss in Salesforce and steps to prevent accidental data loss.
What is the difference between backup and archiving?
Backup and archiving solve different problems. Backup exists to recover recent, active data quickly after loss. Archiving exists to move older, inactive data out of your live org for retention and cost control while keeping it retrievable. Most regulated organizations need both.
A frequent mistake is treating archiving as a backup. Archived data is your system of record for old information, but it is not a rolling recovery point for today's active data. You need a current backup for that. For the retention side, see Salesforce data archiving.
How do you back up Salesforce data?
There are three broad approaches, each with tradeoffs:
- Manual exports. Salesforce's built-in Data Export (weekly or monthly) and Data Loader produce CSV files. They are free but manual, coarse-grained, and slow to restore from. Per Salesforce Help, the scheduled export runs at most weekly in Enterprise, Performance, and Unlimited editions, and monthly in Professional and Developer editions.
- Build-your-own. Scripted API extracts to your own storage. Flexible, but you own the maintenance, the relationship and metadata integrity on restore, and the failure modes.
- A dedicated backup solution. Automated, scheduled backups of both data and metadata with point-in-time recovery, field-level restore, and relationship rebuilding.
Two distinctions matter when you evaluate any method:
- Full vs incremental. A full backup copies everything each run. An incremental (delta) backup copies only what changed since the last run, which keeps daily backups fast and storage efficient. A sound strategy combines periodic fulls with frequent incrementals.
- Data vs metadata. Backing up records alone is not enough. If a deployment removes a field, an object, or an automation, restoring the data without the metadata that gives it structure will not bring your org back to a working state. Back up both.
Compare the options in more depth in data backup methods.
Follow the 3-2-1 rule
A durable backup strategy follows the 3-2-1 rule: keep at least 3 copies of your data, on 2 different types of media or storage, with 1 copy kept off-site or in a separate failure domain. CISA recommends the rule in its own backup guidance. For Salesforce, the principle means your backup should live in a separate control domain from the production org so a single compromise or bad change cannot take out your data and its only copy at once. See the 3-2-1 backup rule.
What are RPO and RTO, and how do they shape a Salesforce recovery plan?
RPO and RTO are the two targets that define a recovery plan. NIST defines the Recovery Point Objective (RPO) as the point in time to which data must be recovered after an outage, which in practice is how much recent data you can afford to lose. The Recovery Time Objective (RTO) is how long a system can stay in recovery before it harms the business, which is how long you can afford to be down. Both definitions come from NIST SP 800-34 Rev. 1.
The relationship is direct: a tighter RPO requires more frequent backups, and a tighter RTO requires faster, more granular restore. A weekly export gives you a one-week RPO and, in practice, a slow RTO because rebuilding relationships from CSVs by hand takes time. Regulated and revenue-critical orgs usually need far tighter targets. For the wider continuity picture, see Salesforce disaster recovery.
What do GDPR, HIPAA, SOX, and GxP require for Salesforce backup and retention?
Compliance requirements come from your regulatory regime, not from Salesforce. They shape both sides of data protection: how fast you must be able to restore, and how long you must keep records, which can far exceed what you want to keep live in the org. This is where backup, archiving, and a written Salesforce data retention policy meet. Confirm the exact obligations for your record types with your compliance team.
- GDPR (personal data of people in the EU). Article 32 requires security measures that include "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident," plus a process for regularly testing those measures. For Salesforce teams, that means a backup you can restore from and restore tests on a schedule. GDPR also gives people the right to erasure under Article 17, so your backup and archive need a way to honor deletion requests rather than quietly keeping copies forever.
- HIPAA (healthcare). Under 45 CFR 164.308(a)(7), the Security Rule makes a data backup plan and a disaster recovery plan required, not optional: covered entities must "create and maintain retrievable exact copies of electronic protected health information" and have procedures "to restore any loss of data." A backup vendor that handles ePHI is a business associate, so you need a business associate agreement in place. Required HIPAA documentation, such as your policies and procedures, must be kept for 6 years from when it was created or last in effect, under 45 CFR 164.316(b)(2)(i). That is a documentation rule; patient-record retention is set separately by state law. See HIPAA data backup.
- SOX (financial reporting). Under 17 CFR 210.2-06, the SEC rule adopted after SOX Section 802, auditors must keep audit workpapers and related records, including electronic records, for 7 years after the audit. Public companies commonly align retention of financial-reporting data with that period, and SOX Section 404 internal-control testing typically looks for evidence that financial data and changes to it are protected and recoverable. See SOX compliance for Salesforce.
- GxP and 21 CFR Part 11 (life sciences). Under the FDA's 21 CFR Part 11, electronic records must remain accurate, attributable, and retrievable for the full record retention period, with audit trails preserved. See 21 CFR Part 11 backup and restore.
The pattern across all four: you must be able to restore quickly and produce a specific, unaltered record long after it left active use. Backup keeps recent data recoverable; archiving keeps old records retrievable and out of your storage costs; both need retention and deletion rules that match your mandate.
How do you restore deleted Salesforce records without breaking automations?
Restoring is harder than backing up, because Salesforce data is relational and active. A clean restore has to rebuild parent-child relationships, respect field-level security, and avoid re-triggering the automations that fire on insert or update. A naive reload of records can fire Flows and triggers, send notifications, or overwrite good data with stale values.
What to look for in a restore capability:
- Granularity. Restore a single field, record, or object, not just a full-org rollback, so you fix the actual problem without disturbing everything else.
- Relationship integrity. Lookups and master-detail links are rebuilt so restored records reconnect correctly.
- Comparison before restore. See what changed between the backup point and now, and choose what to bring back.
- Automation-aware restore. Control whether triggers and Flows fire during the restore so you do not cause a second incident.
For a deeper walkthrough, see restoring accidentally deleted records. The Salesforce Recycle Bin is only a short-window safety net, 15 days by default (less if the org hits its Recycle Bin capacity), and is not a substitute for backup.
What is sandbox seeding, and how does it fit a backup strategy?
Sandbox seeding is the practice of populating a sandbox with production-like data so teams can build and test against realistic records without paying for a full-copy sandbox. It connects to backup and data protection in two ways: the same tooling that moves and reshapes data between orgs is what makes seeding safe, and seeding often needs masked or de-identified data so sensitive production values do not spread into lower environments.
A capable approach lets you select a subset of production data, mask sensitive fields, and load it into a sandbox with relationships intact. This is a Flosum Data Migrator function rather than a backup function, but it draws on the same data-integrity discipline. See Salesforce sandbox seeding for the full method.
How does Flosum Backup & Archive fit in?
Flosum Backup & Archive is built to do the functional work this guide describes: automated, scheduled backup of both Salesforce data and metadata; incremental backups for a tight RPO; point-in-time and field-level recovery for a fast, low-blast-radius RTO; and long-term archiving to meet retention mandates while reclaiming org storage. It pairs with Flosum Data Migrator for sandbox seeding and with risk and governance controls for regulated orgs.
You also choose where your backups live. Flosum Backup & Archive can be deployed Salesforce-native, in the Flosum-hosted cloud, or customer-hosted, so you can keep backup copies in the control domain your security and compliance teams require, which is the 3-2-1 principle applied to your own architecture.
Data protection is your responsibility under Salesforce's shared responsibility model, and meeting that responsibility takes a strategy: current backups of data and metadata, recovery targets you can hit, retention that matches your compliance regime, and a restore you can trust not to make the incident worse.
See how fast recovery looks on your own org: book a demo.
FAQs
Thank you for subscribing
