Quick Answer
70% of Odoo implementations don't have a tested rollback plan. When a GL mapping breaks or a deployment fails, they panic and lose $40k-$180k. The fix: 3-layer strategy (backup/restore, configuration rollback, Git version control). Cost: $2k-$6k/year. One disaster prevented pays for decades.
The Rollback Problem Nobody Prepares For
Your consultant deployed a configuration change to production Monday morning. By Tuesday, you realize the GL account mapping is wrong. Orders are being recorded to the wrong accounts. Your finance team has already entered 120 transactions.
Now what?
| Scenario | Action | Cost |
|---|---|---|
| Option A: Panic | Hope someone knows how to fix it. Lose Wednesday to firefighting. | $8,400 |
| Option B: Rollback Plan | Restore to Monday 6 AM backup, verify data, re-apply correct config. Back to normal by 10 AM. | $300 |
The difference between these two scenarios is one thing: you have a rollback strategy and you've actually tested it.
We've implemented 150+ D2C brands. The ones who treat rollback as a critical operational concern? They've never had a disaster. The ones who skip it ("That won't happen to us")? We've seen them lose $40,000-$180,000 in downtime, data corruption, emergency consulting, and lost orders.
Real Example: The GL Mapping Disaster
A $2.2M fashion brand implemented a new GL account structure. Consultant deployed it to production Monday morning without testing in staging first.
Tuesday, 9 AM: Finance notices invoices are being recorded to wrong accounts
Tuesday, 10 AM: Investigation starts. Discovery: the mapping is backwards. 847 orders in wrong accounts.
Tuesday, 4 PM: Decision: restore to Monday 6 AM backup
Tuesday, 5 PM: Restoration begins. But backup process was never tested. It fails. 3 hours troubleshooting.
Tuesday, 8 PM: Finally restored. Finance must manually re-enter 847 orders.
Wednesday-Thursday: Manual rework. 40 hours of finance team labor.
Friday: Data finally clean. System back to normal.
Total cost: $18,400 in lost productivity, plus emergency consultant rates.
If They'd Had a Rollback Plan:
Monday morning: Deploy to staging instead of production
Monday afternoon: Test in staging. Discover GL mapping is wrong.
Monday, 4 PM: Fix the issue in staging. Re-test.
Monday, 5 PM: Deploy corrected configuration to production.
Zero downtime. Zero data corruption. Zero cost.
The Three Layers of Rollback Protection
| Layer | Use Case | Recovery Time |
|---|---|---|
| Backup & Restore | Complete database corruption, catastrophic data loss | 1-3 hours |
| Configuration Rollback | GL mapping errors, workflow breaks, field issues | 5-30 minutes |
| Version Control | Custom module deployment breaks something | 10 minutes |
Layer 1: Backup & Restore Strategy
What Gets Backed Up?
Odoo consists of two parts:
1. The Database (PostgreSQL)
• All business data: customers, orders, GL entries, inventory
• All configurations: GL account structure, sales workflows, custom fields
• All user data: dashboards, custom reports, filters
2. The FileStore (Binary files)
• Attachments (PDFs, images, documents)
• Website content
• Product images
⚠️ Critical: Both must be backed up together. If you restore database without filestore, you'll have orders with missing attachments.
Backup Frequency & Retention
| Backup Type | Frequency | Retention |
|---|---|---|
| 6-hour backups | Every 6 hours | 48 hours |
| Daily backups | Every day | 30 days |
| Weekly backups | Every week | 12 months |
| Monthly backups | Every month | 7 years (compliance) |
| On-demand | Before risky changes | As needed |
Creating a Backup (Step-by-Step)
Method 1: Odoo.sh Cloud (Easiest)
If you're on Odoo.sh, backups are automatic and easy:
1. Log into Odoo.sh dashboard
2. Go to "Backups" for your project
3. Click "Create Backup"
4. System takes a full backup (5-15 minutes depending on size)
5. You can now download or restore this backup anytime
Method 2: Self-Hosted Odoo (Automated Script)
#!/bin/bash
# Set variables
BACKUP_DIR="/backups/odoo"
DB_NAME="odoo_production"
TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S)
BACKUP_FILE="$BACKUP_DIR/odoo_backup_$TIMESTAMP.dump"
# Create backup directory if it doesn't exist
mkdir -p $BACKUP_DIR
# Backup PostgreSQL database
pg_dump -U postgres -Fc -d $DB_NAME > $BACKUP_FILE
# Backup filestore
tar -czf "$BACKUP_DIR/filestore_backup_$TIMESTAMP.tar.gz" /opt/odoo/filestore
# Delete backups older than 30 days
find $BACKUP_DIR -name "*.dump" -mtime +30 -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete
# Upload to cloud storage (optional but recommended)
# s3cmd sync $BACKUP_DIR s3://my-backup-bucket/odoo/
echo "Backup completed: $BACKUP_FILE"Restoring from a Backup (The Nuclear Option)
When to restore: Database is corrupted, configuration change broke critical workflows, or you need to roll back to a known-good state.
⚠️ Before you restore: DO NOT restore without understanding why. If the backup itself is corrupted, restoring makes things worse. Investigate first.
Restore Process (Odoo.sh):
1. Go to Odoo.sh dashboard → Backups
2. Find the backup you want to restore (e.g., "2025-12-19 6 AM")
3. Click "Restore" → Choose destination: odoo_production_restored (NOT your live database)
4. Odoo restores to a new database (your live database is untouched)
5. Test the restored database: "Does the old configuration work?" "Is data correct?"
Restore Process (Self-Hosted):
sudo su postgres
createdb odoo_restoredpg_restore -d odoo_restored /backups/odoo/odoo_backup_2025-12-19_06-00-00.dumpcd /opt/odoo/filestore
tar -xzf /backups/odoo/filestore_backup_2025-12-19_06-00-00.tar.gz[options]
db_name = odoo_restored
db_user = odoo
db_password = [your password]sudo systemctl restart odooTimeline: Restore takes 15 minutes to 2 hours depending on database size.
Layer 2: Configuration Rollback (The Smart Fix)
Most problems don't require a full database restore. They require undoing a specific configuration change.
Example: You changed the GL account structure. Orders are now going to the wrong accounts. You don't need to restore the entire database—you just need to undo that one change.
Reverting a Workflow Configuration
Scenario: You modified the Sales Order workflow to require manager approval before invoicing. But the logic is broken, and no orders can be invoiced now.
Fix:
1. Go to Settings → Technical → Workflows
2. Find "Sale Order" workflow
3. Click the workflow
4. Undo the approval step (delete it or disable it)
5. Test: Create a test order, verify you can invoice it
Time: 10 minutes. Data impact: Zero (all existing orders are unaffected).
Reverting GL Account Mapping
Scenario: You mapped "Sales Revenue" GL account wrong. All orders since yesterday are posting to the wrong account.
Fix:
1. Go to Accounting → Chart of Accounts
2. Find the wrong account mapping
3. Correct it
4. Odoo has a feature to "Recalculate" recent transactions
5. OR manually fix the 47 transactions entered since the change
Time: 20-30 minutes. Data impact: Corrects incorrect GL entries without losing them.
Reverting Custom Fields
Scenario: You added a custom field to Invoices. But the field has a formula that's breaking calculations.
Fix:
1. Go to Settings → Technical → Fields
2. Find the custom field
3. Delete it OR fix the formula
4. Odoo gives you option: "Delete associated data" or "Keep data"
5. If you keep data, it's archived (invisible but recoverable)
Time: 5 minutes. Data impact: Zero if you just delete the custom field.
Layer 3: Version Control (Git-Based Code Revert)
If you have custom code (custom modules, API integrations, custom reports), you need version control to track changes and enable rollback.
Setup: Using Git for Custom Modules
GitHub Repository (Private)
├── custom_modules/
│ ├── my_module_1/
│ ├── my_module_2/
│ └── my_module_3/
├── scripts/
│ ├── deploy.sh
│ └── backup.sh
└── README.mdWorkflow:
Development branch: You develop new features
Staging branch: Code goes to staging for testing
Production branch: Tested code goes to production
# Developer creates new branch from production
git checkout -b feature/new-reporting-module
# Develop the module locally
# Make changes, test locally
# Push to GitHub
git push origin feature/new-reporting-module
# Create a Pull Request for review
# Team reviews code
# Merge to staging branch
git merge feature/new-reporting-module
# Deploy to staging server for testing
# Test in staging environment
# If good, merge to production branch
git merge staging
# Deploy to production
# Odoo.sh automatically pulls from production branchIf Something Breaks in Production:
# Revert to previous working version
git revert HEAD
# or checkout a known-good commit
git checkout abc123def456
# Push to production
git push origin production
# Odoo automatically deploys the rolled-back code
# All data is unaffected; only code is revertedTimeline: Code rollback takes 5 minutes. Odoo deploys the rolled-back code within 5-10 minutes.
The Complete Rollback Plan (Document Template)
Create a document that outlines exactly how to recover from every type of disaster. This document should be:
✓ Stored securely (Google Drive, shared with your consultant, backed up)
✓ Tested regularly (every 6 months, run a practice restore)
✓ Known by 2+ people (not just one person who has the knowledge)
The Real Cost of Proper Rollback Preparation
| Investment | Cost |
|---|---|
| Setting up backup automation | $0-$5,000 (one-time) |
| Monthly backup storage | $150-$400 |
| Version control setup | $0 (Git is free) |
| Testing rollback (every 6 months) | 4 hours × $50 = $200 |
| Documentation | 8 hours × $50 = $400 |
| Annual cost | $2,000-$6,000 |
Cost of NOT having rollback plan: $40,000-$180,000 (one uncontrolled outage)
ROI: One incident recovers the entire multi-year investment.
Action Items: Protect Your Odoo System
Before Go-Live
❏ Identify your backup strategy (Odoo.sh automatic OR self-hosted automated)
❏ Configure backup retention (6-hour backups, 30-day retention minimum)
❏ Set up Git repository for custom code (if you have custom modules)
❏ Create a rollback runbook (document template above)
❏ Schedule practice restore (after go-live, do a test restore to verify backups work)
After Go-Live
❏ Monthly: Verify backups are running (check backup logs)
❏ Quarterly: Test restore to a non-production database
❏ Pre-deployment: Take an on-demand backup before deploying risky changes
❏ Incident: Reference rollback plan, don't improvise
Frequently Asked Questions
When should I use a full database restore vs configuration rollback?
Use configuration rollback for specific issues (wrong GL mapping, broken workflow). Takes 5-30 minutes. Use full restore only for catastrophic failures (database corruption, multiple broken systems). Takes 1-3 hours.
How often should I test my rollback plan?
Quarterly. Every 3 months, restore a backup to a test database and verify data integrity. This ensures your backups actually work when you need them. Takes 2 hours.
What's the difference between Odoo.sh backups and self-hosted backups?
Odoo.sh: Automatic, encrypted, one-click restore. Cost: $0 extra. Self-hosted: You manage scripts, storage, monitoring. Cost: $150-$650/month. Odoo.sh is easier for most D2C brands.
Can I rollback custom code without affecting business data?
Yes. With Git version control, you can revert custom modules to a previous working version. All business data (orders, customers, GL entries) remains untouched. Only code changes are reverted. Takes 10 minutes.
Free Disaster Recovery Planning Session
Stop flying blind on recovery. We'll audit your current backup and recovery setup, identify gaps, design a rollback strategy, and create a tested runbook you can execute under pressure. Most D2C brands discover they have no tested rollback plan. One small incident would cost them $40,000+ in downtime and manual recovery.