In short
- Salesforce's Recycle Bin and scheduled exports are not a restore plan. A backup tool is.
- Spanning backs up data, files and 17 metadata types daily, plus on-demand snapshots.
- Take an on-demand backup before every import, mass update or bulk delete.
- Test a restore before you need one, and know what a backup will not fix.
Why Salesforce needs a backup tool like Spanning
Salesforce keeps your data running. It does not protect you from your own changes: a bad import, a flow that overwrites a field on every record, an integration that maps the wrong value, or a user who deletes the wrong list.
- The Recycle Bin holds deleted records for a limited time, and does nothing for values that were overwritten.
- The Data Export service gives you CSV files on a schedule. Getting them back into Salesforce, with relationships intact, is a project.
A backup tool gives you a restore button. That is the difference.
What Spanning Backup for Salesforce covers
- Data: standard and custom object records, files, attachments and Chatter.
- Metadata: 17 types, including objects, layouts, reports, dashboards, profiles, permission sets, flows and Apex classes.
- Daily automated backups, at a time you choose.
- On-demand backups whenever you want a snapshot.
Restores happen inside Salesforce: specific fields or whole records, related child records, everything from a point in time, or data and metadata into another org.
How we set up Spanning in each org
Install and connect
Install Spanning in the org and connect it with an admin user that can see every object you want backed up.
Pick the backup time
Schedule the daily backup outside working hours, away from heavy integration jobs.
Check coverage
Confirm the custom objects, files and metadata types your org depends on are included.
Set who can restore
Decide whether users can restore their own records, or only admins can.
Write it down
Add the backup setup and the restore steps to the org's documentation.
Talk through your project
A free call about your integration, your CRM or whatever you are stuck on. Honest advice, even if you never hire us. No obligation.
What we learned running backups across 15 Salesforce orgs
- Back up before you change. An on-demand backup before an import, mass update, bulk delete or deployment gives you a clean restore point, and Spanning puts no cap on on-demand backups.
- Test a restore early. Restore a test record or a field in a sandbox, so the first restore is not during an emergency.
- Check that backups are still running. A changed admin password or a deactivated user can stop them.
- Restore narrowly. Restore the fields or records that changed, not the whole org, so good changes since the backup stay.
- Keep it in the ticket. Note the backup and any restore in the Jira ticket for the change, so the history is in one place.
When a backup does not save you
- The cause is still running. If an integration keeps overwriting a field, a restore is undone by the next sync. Stop the cause first.
- The data was not in Salesforce to begin with. A backup only holds what Salesforce held.
- The change was right, but the process was wrong. A backup cannot replace a sandbox, testing and review.
- Metadata outside the supported types needs your deployment history or source control.
Backing up Salesforce with patient data
A backup is a full copy of your org, patient data included. If you are in healthcare, check that your backup vendor will sign a BAA before you connect it. We sign BAAs for our healthcare work.
Want backups set up and checked for you? It is part of our Salesforce managed services. Book a free call.
Want help with this?
Book a free call about your CRM, integrations or reporting, or map your systems first with our free tech stack diagram builder.