Essential SOPs, Part 3: Backup & Disaster Recovery, the SOP You Hope You Never Use
This is the third post in our Essential SOPs for Salesforce Admins series, based on my session at Texas Dreamin'. Part 1 made the case for routine maintenance. Part 2 covered user management. This post kicks off three weeks on data: first, protecting it.
Salesforce is remarkably reliable. Your users are not.
The disaster you're most likely to face isn't a platform outage. It's a bad data load that overwrote a field on 40,000 records. It's an automation that misfired over a weekend. It's a well-meaning admin who ran a mass update against the wrong list view. The Recycle Bin has limits, retention windows expire, and none of it will save you from a cascading update that changed data instead of deleting it.
Which is why backup and disaster recovery is an SOP and not a project. A backup you set up once and never look at again isn't protection. It's a false sense of it.
If You Have a Third-Party Backup Tool
Plenty of orgs check the backup box by buying a tool, and that's a good start. But the SOP isn't "confirm the backups are running." It's "prove you can restore."
Test a restoration on a regular schedule. Pick a sandbox, pick a scenario (a corrupted field across one object is a realistic one), and actually run the restore. You're testing three things: that the backup contains what you think it contains, that the restore process works, and that you know how to run it under calm conditions before you ever have to run it under panicked ones. A backup you've never restored from is a hope, not a plan.
Confirm your coverage matches your org today. Backup tools get bought at a point in time, and orgs keep growing after that. If you've added Data Cloud or other expanded storage since the tool was purchased, verify it's actually covered. Coverage gaps love to hide in the products you added after you signed the backup contract.
If You Don't Have a Third-Party Tool
Use what's built in, and put it on the calendar.
Schedule the weekly Data Export. On Enterprise Edition, the native Data Export can run weekly. The catch: Salesforce generates the files, but someone has to download them and store them somewhere safe, on a schedule, every time. An export sitting in Salesforce waiting to expire is not a backup. Assign the task to a person, not to "the team."
Back up your metadata, not just your data. Your flows, custom objects, page layouts, and validation rules represent years of accumulated work, and a records-only backup won't capture any of it. Archive your configuration through a DevOps process or a Git repository. Even a simple scheduled metadata retrieval is enough to make "we lost the config" a sentence you never have to say.
Either Way: Write the Recovery Plan
The middle of an incident is a bad time to design your incident response. Write the plan while nothing is on fire:
Who declares an incident, and who has authority to run a restore?
What gets restored first? Rank your objects by business impact so you're not deciding priority during the outage.
How long should it take? Know your realistic recovery time before leadership asks for it mid-incident.
Who gets told, and when? A restore that surprises your users creates a second incident.
Keep the plan somewhere that doesn't depend on Salesforce being up, and review it once a year, ideally right after your restore test while the gaps are fresh.
Where to Start
If this pillar is your pick to start the series, here's the single move: schedule one restore test this quarter. Not a tool evaluation, not a strategy document. One test restore into a sandbox. It will either confirm you're protected or show you exactly where you're not, and both outcomes are worth more than another month of assuming.
What's Next
Next post, we stay on the data and tackle the mess that comes in the front door: duplicates, and the monthly routines that keep your matching rules tuned to how data actually enters your org.
