Security and backups
Odoo Security on Your Own Server: A Practical Hardening Checklist
TLS and proxy mode, the database manager, master password, updates, firewalls, two-factor sign-in, least privilege and logs for self-hosted Odoo.
· 9 min read
Key takeaways
- A usable Odoo backup has two halves, the PostgreSQL database and the filestore, taken together, plus the configuration and code needed to rebuild the server.
- Agree a recovery point and a recovery time first. They decide how often you back up and how fast a restore has to be.
- Follow the 3-2-1 rule: three copies, two kinds of storage and one off-site copy that the Odoo server itself cannot reach or delete.
- Odoo Online and Odoo.sh back up production daily. On your own server, scheduling, encryption, monitoring and off-site copies are your job.
- Restore a backup to a separate, neutralized database every quarter and time it. Until it restores, it is only a file.
Setting up an Odoo backup takes minutes. Proving that it restores takes a deliberate test, and that step is easy to skip. The difference only shows on a bad day: a failed disk, a module update that breaks the database, ransomware on the server or a user who archives the wrong records in bulk. On that day, the only Odoo backup that counts is one you can restore completely, quickly and with confidence.
If your Odoo Enterprise database runs on Odoo Online or Odoo.sh, Odoo backs up production for you. If you run Odoo Enterprise or Community on your own server or a private cloud, the strategy is yours. This guide sets one out for self-hosted Odoo 19.
What a Complete Odoo Backup Contains
Every Odoo database lives in two places. PostgreSQL holds the records: contacts, orders, invoices, stock moves, journal entries and settings. The filestore, a folder in Odoo's data directory, holds attachments and binary fields such as scanned bills, signed contracts, product images and generated PDFs. Restore one without the other and Odoo looks complete until somebody opens an attachment.
The two halves must also come from the same moment. Odoo's ZIP backup can pack them together, as a dump.sql file, a manifest.json and the filestore folder. In the Odoo 19 database manager the Include filestore box is ticked by default, and unticking it produces a ZIP without attachments. The pg_dump custom format always leaves the filestore out, so it only works if the files are copied separately on the same schedule.
A database is not a server, so also keep what you need to rebuild one:
- The Odoo configuration file, stored securely because it contains passwords.
- Your custom and third-party modules at the exact versions running in production, ideally in a Git repository.
- A note of the Odoo version, the operating system packages and the Python libraries your modules depend on.
- Any key that a module keeps outside the database. SBS Password Manager, for example, keeps its encryption key in the configuration file or an environment variable, and without that key the stored passwords cannot be recovered. Keep a recovery copy in a secret manager, never next to the database backups.
Set Recovery Targets before You Choose a Schedule
Two targets drive every backup decision. The recovery point objective (RPO) is how much recent work you can afford to lose. The recovery time objective (RTO) is how long the business can wait for Odoo to come back. Agree both with finance and operations, because they feel the loss first.
With one backup a night, a failure late in the afternoon can cost a full day of invoices, receipts and payments. If that is too much, back up more often or add PostgreSQL continuous archiving, which replays the database's write-ahead log so you can restore to a chosen moment. The PostgreSQL backup documentation explains this point-in-time recovery alongside plain dumps and file system copies.
Recovery time depends on the size of the database and filestore, how fast you can fetch the off-site copy and how well the steps are rehearsed. The only reliable figure is the one you measure during a real test restore.
Backup Frequency and Retention
Odoo's own deployment guide recommends daily backups of databases and filestore for self-hosted servers. Add an extra backup before every risky change: installing or updating modules, applying Odoo updates, large imports and version upgrades, as in our Odoo 19 upgrade checklist.
Retention protects you from problems noticed late, such as a mass deletion or a faulty import discovered weeks afterwards. Daily, weekly and monthly generations cover both recent and older mistakes, and it is the same pattern Odoo uses for Odoo.sh production databases. A starting schedule for a self-hosted server could look like this:
| Backup | When | Keep | Where |
|---|---|---|---|
| Full backup, database and filestore | Every night | The last 7 | Backup server or NAS on site |
| Weekly copy | Once a week | The last 4 | Off-site location or cloud account |
| Monthly archive | First night of each month | At least 3 | Off-site, versioned or write-once storage |
| Year-end archive | After the year-end close | As long as your records policy requires | Off-site, encrypted, tightly restricted |
| Pre-change backup | Before updates, imports or upgrades | Until the change is proven | Next to the nightly backups |
Adjust the numbers to your recovery point and storage budget. For year-end archives, follow the record-keeping periods your auditor advises and check the latest guidance from the Federal Tax Authority.
Have a question about this guide? Ask the engineers who wrote it.
The 3-2-1 Rule, Applied to Odoo
The 3-2-1 rule, set out in a US-CERT paper that CISA publishes, is a quick test for any backup plan: keep three copies of important data, on two different types of storage, with one copy off-site. On a self-hosted Odoo server it can look like this:
- Copy one is the live database and filestore on the production server.
- Copy two is the nightly backup on a separate backup server or NAS, close enough for a fast restore.
- Copy three sits off-site, in another building, data center or cloud account, safe from fire, theft and a compromised server.
Odoo's deployment guide adds the detail that matters most against ransomware: the remote archive should not be accessible from the Odoo server itself. If production can delete its own off-site backups, so can anyone who takes over production. Pull-based copies, where the backup server fetches the files, separate credentials and versioned or write-once storage all close that gap.
Location is a decision too. If your policies say business data stays in the UAE, choose an off-site destination with storage in the UAE and get that confirmed in writing.
Encrypt and Protect the Backup Files
A backup holds everything in Odoo: customers and prices, salaries, bank details and user password hashes. Protect it like the live database.
- Encrypt backups at rest, before they leave the server or on the storage itself, and keep the keys away from the backups.
- Move them over encrypted channels such as SFTP, FTP over TLS or HTTPS, never plain FTP.
- Limit who can read backup folders and buckets, and use backup credentials that exist nowhere on the Odoo server.
- Never store the Odoo master password in a backup script. It can create, delete, dump or restore any database on the server.
That last point matters, because scripts that call Odoo's database manager page need the master password. Odoo strongly recommends disabling the database manager on internet-facing systems, notes that it is not designed for large databases and expects production backups to be run by the system administrator. Tools that run pg_dump directly avoid the dependency.
What Odoo Online and Odoo.sh Already Provide
On Odoo's cloud, much of this is done for you, but know exactly what you get.
- Odoo Online: the Cloud Hosting SLA describes 14 full backups kept for at least three months, replicated on at least three machines in data centers in Europe and Canada, plus a frozen copy in immutable cold storage. You can download a backup from the database manager, but you cannot choose the regions where backups are replicated. If a database is too large to download that way, Odoo Support offers another route.
- Odoo.sh: production is backed up daily, keeping seven daily, four weekly and three monthly backups, each with the database dump, the filestore, logs and sessions. Staging and development databases are not backed up automatically, and manual backups are kept for a few days only, so download any snapshot you want to keep.
Even on Odoo's cloud, downloading a copy now and then and keeping it under your own control gives you an independent record for audits, disputes or a later change of hosting. Our comparison of Odoo Online, Odoo.sh and on-premise hosting covers the other differences.
Testing an Odoo Backup: A Restore Procedure
A restore test turns a file into evidence. Run one at least quarterly, after any change to the backup set-up and whenever someone new takes over the job. This procedure suits most self-hosted Odoo 19 servers:
- Pick a backup at random, not just last night's, and fetch it from the off-site copy.
- Check its integrity first by comparing its checksum or size with what the backup job recorded.
- Restore it on a separate server or under a new database name, never over production.
- Neutralize it. In the database manager, tick Neutralize and choose This database is a copy; on the command line, use
odoo-bin db loadwith its--neutralizeoption. Neutralization disables scheduled actions, outgoing emails, bank synchronization, payment providers, delivery methods and other external services, so the test cannot email customers or move money. - Sign in as a few different users and check what the business would check: the latest invoice and payment, the trial balance at the last month-end, stock for a busy product and a handful of attachments.
- Record how long the restore took and compare it with your recovery time objective.
- Log the date, the backup used, the result and any fixes, then delete the test database.
Tip: Make the restore test a named person's job, with a date in the calendar. Backups fail quietly, and a scheduled restore is the routine that notices.
Scheduling Backups with SBS Automatic Database Backup
For self-hosted Odoo 19 and Odoo.sh, our free SBS Automatic Database Backup module schedules backups from inside Odoo without ever storing the master password. It calls PostgreSQL's pg_dump for the database Odoo is running in, and there is no database selector, so a job cannot reach any other database on the server.
- Two formats: a full Odoo restore ZIP that Odoo's own restore page accepts and that can include the filestore, or a smaller SQL-only PostgreSQL custom dump, restored with pg_restore, for when files are copied separately.
- Eight destinations: local storage, FTP over TLS, SFTP, Google Drive, Dropbox, OneDrive, Nextcloud and Amazon S3 or S3-compatible storage.
- One record per job, each with its own schedule and retention, so a nightly local ZIP and a weekly off-site dump can run side by side.
- The filename, exact size and SHA-256 checksum recorded for every run, a Test Destination button and an email to a chosen user whether a run succeeds or fails.
- Local archives written owner-only, beneath a root folder the server administrator sets in the Odoo configuration file.
It is built and tested on Odoo 19 Community and listed for Odoo.sh and on-premise installations, not Odoo Online. We tested local storage in both formats, retention, checksums, the connection test and email notification on a live database. The remote destinations need live third-party accounts and have not been tested by us yet, so prove your chosen destination with a restore test. The module handles scheduling; off-site separation, storage encryption and restore tests remain part of your plan.
An Odoo Backup Checklist
- Database and filestore backed up together, at least daily.
- An extra backup before updates, module installs, imports and upgrades.
- Configuration and custom modules backed up, and module keys held in a separate secret store.
- Daily, weekly and monthly generations, plus a year-end archive.
- One copy off-site that the Odoo server cannot reach or delete.
- Encryption at rest and in transit, with keys stored separately.
- No master password in scripts or modules.
- An alert whenever a backup fails or does not run.
- A timed restore test on a neutralized copy, at least quarterly.
How Star Bit Solutions Can Help
Through OdooStar, we implement and support Odoo Enterprise on Odoo Online, Odoo.sh and your own servers, and Odoo Community where it fits. For self-hosted databases, our support and maintenance covers monitoring and backups: we set the schedule around your recovery targets, arrange encrypted off-site copies, configure SBS Automatic Database Backup where it helps and run restore tests with your team.
Want a second opinion on your current set-up? Contact us, call +971 55 973 4524 or email [email protected].
Written by the Star Bit Solutions team
Star Bit Solutions is a software company in Ajman, UAE, founded in 2014. We implement and customize Odoo Enterprise and Odoo Community, and build StarBiz (AI-driven ERP), StarHub (life super app), StarBot (conversational AI), StarLearn (adaptive learning) and StarSense (AI and IoT platform). About us
