Implement a Backup Strategy
Configure automated backups with retention policies, test restore, and set up offsite verification for disaster recovery.
This tutorial walks you through setting up a production-ready backup strategy for your Odoo instances. You will configure automated backups, set retention policies, verify the restore process, and implement offsite backup storage.
Estimated time: 25 minutes
This tutorial assumes you have at least one Odoo instance running. If not, complete the Deploy Your First Odoo Instance tutorial first.
What you will configure
- Automated backup schedule for database and filestore
- Retention policies to manage storage usage
- A tested restore procedure
- Offsite backup destination for disaster recovery
Step 1: Configure a backup destination
Before setting up backup schedules, configure where backups will be stored.
Navigate to your organization's Settings page and select the Backups tab.
Click Add Backup Destination and choose a storage type:
| Storage Type | Best For | Notes |
|---|---|---|
| Local | Development, small setups | Stored on the same server; no offsite protection |
| S3-compatible | Production | AWS S3, MinIO, DigitalOcean Spaces, Backblaze B2 |
| Google Cloud Storage | Production | GCS buckets with service account authentication |
For an S3-compatible destination, provide:
- Endpoint URL (e.g.,
https://s3.amazonaws.comor your MinIO URL) - Bucket name
- Access key ID
- Secret access key
- Region (e.g.,
us-east-1)
Click Test Connection to verify oCore can write to the destination. Once confirmed, click Save.
Backup settings
Configure backup destinations in your organization settings.
For production environments, always configure at least one offsite (remote) backup destination. Local-only backups are lost if the server fails.
Step 2: Set up an automated backup schedule
Configure automatic backups for your Odoo instances.
Navigate to your instance and select the Backups tab.
Click Configure Backup Schedule and set the parameters:
| Parameter | Recommended Value | Description |
|---|---|---|
| Frequency | Daily | How often backups run |
| Time | 02:00 UTC | Schedule during low-traffic hours |
| Include filestore | Yes | Back up uploaded files alongside the database |
| Destination | Your S3 destination | Where backups are stored |
| Compression | gzip | Reduces backup size |
Enable the schedule and click Save.
Instance backups
Navigate to your instance to configure backup schedules.
Recommended schedules by environment
| Environment | Frequency | Retention | Rationale |
|---|---|---|---|
| Production | Daily + before deployments | 30 days | Maximum data protection |
| Staging | Daily | 7 days | Enough to recover recent test data |
| Development | Weekly | 3 days | Minimal; easily recreated |
Step 3: Configure retention policies
Retention policies automatically clean up old backups to prevent unbounded storage growth.
In the backup schedule configuration, find the Retention section.
Configure retention rules:
| Rule | Value | Effect |
|---|---|---|
| Keep daily | 7 | Keep one backup per day for the last 7 days |
| Keep weekly | 4 | Keep one backup per week for 4 weeks |
| Keep monthly | 6 | Keep one backup per month for 6 months |
| Maximum total | 50 | Hard limit on total backup count |
oCore applies retention rules in order: daily first, then weekly, then monthly. Backups that do not match any retention rule are automatically deleted.
Click Save to apply retention policies.
Retention policies run after each successful backup. You can also trigger a manual retention cleanup from the backup management page.
Step 4: Test backup and restore
Never trust a backup you have not tested. Verify that your backups can actually be restored.
Trigger a manual backup by clicking Backup Now on your instance's Backups tab. Wait for it to complete.
Verify the backup appears in the backup list with status Completed and a non-zero file size.
Test the restore process. There are two approaches:
Option A: Restore to a new instance (recommended for production)
- Create a new temporary environment
- Select the backup and click Restore to Environment
- Choose the temporary environment as the target
- Verify the restored instance works correctly
- Delete the temporary environment when done
Option B: Restore in place (for development only)
- Select the backup and click Restore
- Confirm the in-place restore (this overwrites current data)
- Wait for the restore to complete
After restoring, verify:
- Odoo starts successfully
- You can log in with existing credentials
- Data is present and recent (check timestamps on records)
- Uploaded files (filestore) are intact
Restoring in place overwrites all current data in the instance. For production environments, always restore to a separate instance first to verify the backup before replacing live data.
Step 5: Set up offsite backup verification
For critical production environments, implement verification that offsite backups are complete and readable.
In the backup destination settings, enable Backup Verification. This tells oCore to verify each backup after upload by:
- Checking the file size matches the local backup
- Verifying the checksum (SHA-256) of the uploaded file
- Confirming the file is readable from the remote location
Configure verification alerts so you are notified if:
- A scheduled backup fails to run
- A backup upload to the offsite destination fails
- A backup verification check fails
- Backup size decreases significantly (potential data loss indicator)
Set up a monthly restore drill reminder. Even with automated verification, periodically restore from your offsite backups to a test environment to confirm the full recovery process works.
Best practices for disaster recovery
The 3-2-1 rule
Follow the industry-standard 3-2-1 backup rule:
- 3 copies of your data (production + 2 backups)
- 2 different storage types (local server + remote object storage)
- 1 offsite copy (in a different physical location or cloud region)
Pre-deployment backups
Configure oCore to take an automatic backup before each deployment:
- In your environment settings, enable Pre-deployment backup
- This creates a snapshot before any code changes are applied
- If a deployment causes issues, you can quickly roll back to the pre-deployment state
Document your recovery procedure
Keep a runbook that documents:
- Where backups are stored (destinations, credentials)
- How to restore from each destination
- Expected recovery time (RTO) and acceptable data loss window (RPO)
- Contact information for team members with access to backup credentials
- Steps to verify a restored instance is functioning correctly
What to do next
- Set up monitoring alerts for backup failures. See Monitoring.
- Configure email notifications for your organization to receive backup status updates.
- Review the Self-Hosting guide for production infrastructure best practices. See Self-Hosting.
- Test your disaster recovery plan quarterly to ensure it still works as your infrastructure evolves.