One database, one company
Odoo stores everything in a PostgreSQL database. Customers, products, orders, stock moves, journal entries, attachments, settings — all of it, in one place.
That is why the system is consistent, and it is why looking after the database properly matters more than in a patchwork of separate tools. There is no second copy of anything to fall back on.
This article covers what a business owner needs to understand, not how to administer a server.
Backups
The one thing nobody regrets over-investing in.
What a backup contains
An Odoo backup has two parts: the database (all your records) and the filestore (attachments, images, uploaded documents).
Both are needed. A database backup without the filestore restores your invoices with every attachment missing. People discover this at the worst possible moment.
How often
It depends on how much work you can afford to lose.
Daily is the minimum for most businesses. If you process a high volume of transactions, more often.
Ask it this way: if we lost everything since the last backup, how bad would that be? Set the frequency from the answer, not from a default.
Where
At least one copy somewhere other than the server running Odoo.
A backup on the same machine protects you from a mistake. It does not protect you from the machine failing, being encrypted by ransomware, or the account being compromised.
The rule everyone knows and few follow
An untested backup is not a backup.
Restore one, into a separate database, at least once a quarter. Open it. Check a recent invoice, an attachment, and a stock figure.
The number of companies who discover their backups have been silently failing for months — at the moment they need one — is not small.
FIGURE 1: A BACKUP POLICY THAT ACTUALLY PROTECTS YOU
Back up database and filestore
- A database alone restores your records with every attachment missing.
Set frequency by what you can lose
- Daily is the floor. Ask what a day of lost work would actually cost.
Store a copy elsewhere
- Same-server backups do not survive the server.
Test a restore quarterly
- An untested backup is not a backup. Open it and check real records.
Environments
A grown-up Odoo setup has more than one database. Three is typical.
Production. The live system your business runs on. Real data, real users. Nothing untested goes here.
Staging. A recent copy of production, used to test changes. Whatever you are about to do to production, do it here first and see what happens.
Development. Where new work is built. Data may be old or artificial.
FIGURE 2: HOW A CHANGE SHOULD REACH YOUR LIVE SYSTEM
Development
- Built and unit-tested
Staging
- Tested on a copy of real data
Approved
- Your team confirms the result
Production
- Released, with a backup taken first
The rule: changes flow one way. Development to staging to production. Nothing skips a step because it seems small.
Odoo.sh provides this structure out of the box. Self-hosted setups need it created deliberately, and it is worth the effort.
Staging must be neutralised
A copy of production contains real customer email addresses and real scheduled jobs.
Restoring it without care means test emails going to real customers, and scheduled tasks firing against live external systems. Odoo has a neutralise option for exactly this. Use it every time.
Upgrades
Odoo releases a new version each year and supports each for roughly three years.
An upgrade is not a patch. It changes the data structure, and it needs the same discipline as any other change:
- Take a full backup
- Upgrade a copy in staging first
- Test your custom modules against it
- Test your integrations against it
- Have your team run real scenarios
- Only then schedule production
The custom modules are what make this real work. A standard Odoo with no customisation upgrades fairly cleanly. Every custom module needs checking, and sometimes reworking.
This is the strongest practical argument for keeping customisation in proper modules rather than Studio clicks or edited core files. At upgrade time, the difference is measured in days.
Performance
Databases get slower as they grow. Three things cause most of it.
Attachment volume. The filestore grows quietly and can become very large. Know how big yours is.
Unarchived history. Millions of old records that nobody queries but every index carries.
Badly built custom code. A single inefficient query in a custom module can slow the whole system. Performance problems are more often a custom module than the database itself.
Regular maintenance — database vacuuming, index checks, log rotation — is routine server administration. If nobody in your company does this, it is an argument for hosted Odoo.
Access and security
Three basics, in order of how often they are neglected.
Users leave and keep access. Deactivate accounts as part of your leaving process, not months later.
Everyone is an administrator. Common in small companies and genuinely risky. Administrator access can delete records, change accounting settings and export everything.
The master password is shared. The database master password controls creating, dropping and restoring databases. It should be known by very few people and should not be the default.
FIGURE 3: A SYSTEM THAT IS LOOKED AFTER
Well managed
- Tested backups, stored off the server
- Separate staging, neutralised
- Changes tested before production
- Access reviewed when people leave
Poorly managed
- Backups nobody has ever restored
- Changes made directly on live
- Upgrades attempted without testing
- Everyone an administrator forever
Hosted or self-hosted
Odoo Online. Odoo manages everything. Simplest, least control, limited custom code.
Odoo.sh. Odoo’s platform for customised systems. Gives you staging environments, backups and version control, with Odoo handling the infrastructure.
Self-hosted. Full control, full responsibility. Backups, security patching, monitoring and upgrades are yours.
A practical test: if nobody in your company can confidently restore a backup and patch a server, self-hosting is a false economy. The licence you save is smaller than the cost of the incident you eventually have.
The short version
Four habits, and they are habits rather than technology:
Back up both parts, off-site, and test the restore.
Never change production directly.
Test upgrades in staging, especially your custom modules.
Review who has access, particularly when people leave.
None of this is complicated. It is simply the part that gets skipped until the day it matters.
Not sure whether your Odoo is properly protected?
Get in touch. We will check your backups, your environments and your access — starting with whether anyone has ever successfully restored one.
