Write down how much data you can afford to lose (RPO), and how long you can afford to be without the system (RTO), then check whether anything you currently have can meet those numbers. On Salesforce most orgs discover the honest answers are “about 24 hours” and “several days”, which is usually not what the business assumed. The gap is the finding. The backup product is the remediation.
The two numbers
| RPO — recovery point objective | RTO — recovery time objective | |
|---|---|---|
| Question | How much data can we lose? | How long can we be down? |
| Measured in | Time since last recoverable state | Time to restore service |
| Improved by | More frequent backups | Faster, more practised restore |
| Typical assumption | “We have backups” | “Salesforce will handle it” |
They are independent. Hourly backups with a restore nobody has tested gives you a good RPO and an unknown RTO, which is the most common configuration in the field.
What Salesforce’s own resilience does and does not cover
Salesforce runs the infrastructure, replicates data, and handles instance-level failure. That covers the disaster you are not going to have.
It does not cover the disasters you actually have:
- An admin deletes 40,000 records with a bad data load.
- An integration writes wrong values over good ones for a week before anybody notices.
- A deployment removes a field and its data.
- A departing employee exports and then deletes.
All four are ordinary, none is an infrastructure failure, and none is fixed by the platform being highly available. Availability and recoverability are different properties and are routinely conflated in planning documents.
What you get natively
Recycle Bin. Deleted records are recoverable for a limited retention period, with a per-org capacity cap. Good for an accident noticed the same day. Useless for one noticed next month, and useless for overwritten data, which was never deleted.
Weekly Export. A CSV export of your data, requested weekly (or more often depending on edition). That is the native answer, and it defines a native RPO of up to a week.
Field History Tracking. Up to 20 fields per object, retained for a limited period. It is an audit trail, not a backup, and it cannot restore.
Sandbox copies. A full sandbox is a point-in-time copy and can be a recovery source. Refresh intervals mean it is usually stale, and getting data out of it and back into production is a manual project.
Metadata is a separate story and usually the better one: if your metadata is in version control and deployable, your metadata RTO is a deploy. Teams with good DevOps often have an excellent metadata posture and no data posture at all.
Calculating your real RPO
Time since the last restorable copy, at the worst moment. If you export weekly on Sunday and the incident is Saturday, your RPO is six days. Not “one week” — six days of real transactions.
Then ask what six days means in your business. For a support org, six days of case updates. For a sales org at quarter end, the entire quarter’s pipeline changes. The number is only meaningful translated into what is lost.
Calculating your real RTO, which is harder
RTO is not the restore runtime. It is detection plus decision plus preparation plus restore plus verification.
- Detection. How long before anybody notices? For a deletion, hours. For corrupted values written by an integration, often weeks.
- Decision. Who authorises a restore that will itself overwrite current data? If that person is not named in advance, add a day.
- Preparation. Extracting the right subset, re-parenting records whose parents also changed, deciding what to do about records created since.
- Restore. The load itself, subject to lock contention, automation firing on every restored record, and validation rules rejecting historical data.
- Verification. Proving it worked, which nobody plans for and which takes as long as the restore.
Step four contains the trap that turns a one-day restore into a week: restoring records fires all your automation. Roll-ups recalculate, flows run, integrations fire outbound messages about records that are not new. A restore without a bypass mechanism can cause a second incident.
Relationships are the actual hard part
Restoring 40,000 Contacts means restoring them under the right Accounts. The old Salesforce Ids are gone, a restored record gets a new Id, so every child pointing at a restored parent needs re-mapping, and every lookup from elsewhere in the org still points at an Id that no longer exists.
This is why external Ids are a disaster-recovery feature and not only an integration one. With a stable external key on each object, a restore can re-establish relationships by upserting on that key. Without one, relationship reconstruction is a bespoke data project every single time.
Writing the plan
- State RPO and RTO per object group, not for the org. Losing a day of Cases and a day of Opportunities are different events.
- Name the person who authorises a restore, and their deputy.
- Write down the automation bypass procedure, tested, before you need it.
- Test a restore of one object into a sandbox, annually at minimum. An untested restore procedure is a hypothesis.
- Record the actual elapsed time of that test. That is your RTO. Everything else is a wish.
Frequently asked
Does Salesforce still offer a paid data recovery service?
Salesforce has offered a restore service at various points and its availability and terms have changed over the years, so check the current position with your account team rather than assuming. Historically it has been expensive and slow, measured in weeks, which is not a viable RTO for most businesses either way.
Is Weekly Export enough?
It is enough to say you have something. It gives you a multi-day RPO, no incremental capability, and a restore you build by hand. For most orgs it is a floor, not a plan.
Do I need a third-party backup product?
If your stated RPO is under a day or your RTO is under a week, yes — nothing native gets you there. The honest framing is that you are buying an RTO, so evaluate products on restore, not on backup.
What about metadata?
Version control plus a repeatable deployment is a better metadata backup than any product. If you have that, your metadata recovery is in good shape and the gap is data.
How often should the restore be tested?
At least annually, and after any significant change to the data model. Test one object end to end rather than attempting a full-org rehearsal that nobody will ever schedule.
Reference: Data Export Service, Recycle Bin and Field History Tracking, Salesforce Help; Backup and Restore Considerations, Salesforce Architect resources.
