Odoo stores everything in a PostgreSQL<\/strong> database. Customers, products, orders, stock moves, journal entries, attachments, settings \u2014 all of it, in one place.<\/p>\n 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.<\/p>\n This article covers what a business owner needs to understand, not how to administer a server.<\/p>\n The one thing nobody regrets over-investing in.<\/p>\n An Odoo backup has two parts: the database<\/strong> (all your records) and the filestore<\/strong> (attachments, images, uploaded documents).<\/p>\n Both are needed.<\/strong> A database backup without the filestore restores your invoices with every attachment missing. People discover this at the worst possible moment.<\/p>\n It depends on how much work you can afford to lose.<\/p>\n Daily is the minimum for most businesses. If you process a high volume of transactions, more often.<\/p>\n Ask it this way: if we lost everything since the last backup, how bad would that be?<\/strong> Set the frequency from the answer, not from a default.<\/p>\n At least one copy somewhere other than the server running Odoo.<\/p>\n 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.<\/p>\n An untested backup is not a backup.<\/strong><\/p>\n Restore one, into a separate database, at least once a quarter. Open it. Check a recent invoice, an attachment, and a stock figure.<\/p>\n The number of companies who discover their backups have been silently failing for months \u2014 at the moment they need one \u2014 is not small.<\/p>\n FIGURE 1: A BACKUP POLICY THAT ACTUALLY PROTECTS YOU<\/p>\n Back up database and filestore<\/p>\n Set frequency by what you can lose<\/p>\n Store a copy elsewhere<\/p>\n Test a restore quarterly<\/p>\n A grown-up Odoo setup has more than one database. Three is typical.<\/p>\n Production.<\/strong> The live system your business runs on. Real data, real users. Nothing untested goes here.<\/p>\n Staging.<\/strong> 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.<\/p>\n Development.<\/strong> Where new work is built. Data may be old or artificial.<\/p>\n FIGURE 2: HOW A CHANGE SHOULD REACH YOUR LIVE SYSTEM<\/p>\n Development<\/p>\n Staging<\/p>\n Approved<\/p>\n Production<\/p>\n The rule:<\/strong> changes flow one way. Development to staging to production. Nothing skips a step because it seems small.<\/p>\n Odoo.sh provides this structure out of the box. Self-hosted setups need it created deliberately, and it is worth the effort.<\/p>\n A copy of production contains real customer email addresses and real scheduled jobs.<\/p>\n Restoring it without care means test emails going to real customers, and scheduled tasks firing against live external systems. Odoo has a neutralise<\/strong> option for exactly this. Use it every time.<\/p>\n Odoo releases a new version each year and supports each for roughly three years.<\/p>\n An upgrade is not a patch. It changes the data structure, and it needs the same discipline as any other change:<\/p>\n The custom modules are what make this real work.<\/strong> A standard Odoo with no customisation upgrades fairly cleanly. Every custom module needs checking, and sometimes reworking.<\/p>\n 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.<\/p>\n Databases get slower as they grow. Three things cause most of it.<\/p>\n Attachment volume.<\/strong> The filestore grows quietly and can become very large. Know how big yours is.<\/p>\n Unarchived history.<\/strong> Millions of old records that nobody queries but every index carries.<\/p>\n Badly built custom code.<\/strong> 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.<\/p>\n Regular maintenance \u2014 database vacuuming, index checks, log rotation \u2014 is routine server administration. If nobody in your company does this, it is an argument for hosted Odoo.<\/p>\n Three basics, in order of how often they are neglected.<\/p>\n Users leave and keep access.<\/strong> Deactivate accounts as part of your leaving process, not months later.<\/p>\n Everyone is an administrator.<\/strong> Common in small companies and genuinely risky. Administrator access can delete records, change accounting settings and export everything.<\/p>\n The master password is shared.<\/strong> The database master password controls creating, dropping and restoring databases. It should be known by very few people and should not be the default.<\/p>\n FIGURE 3: A SYSTEM THAT IS LOOKED AFTER<\/p>\n Well managed<\/p>\n Poorly managed<\/p>\n Odoo Online.<\/strong> Odoo manages everything. Simplest, least control, limited custom code.<\/p>\n Odoo.sh.<\/strong> Odoo’s platform for customised systems. Gives you staging environments, backups and version control, with Odoo handling the infrastructure.<\/p>\n Self-hosted.<\/strong> Full control, full responsibility. Backups, security patching, monitoring and upgrades are yours.<\/p>\n A practical test:<\/strong> 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.<\/p>\n Four habits, and they are habits rather than technology:<\/p>\n Back up both parts, off-site, and test the restore.<\/strong><\/p>\n Never change production directly.<\/strong><\/p>\n Test upgrades in staging, especially your custom modules.<\/strong><\/p>\n Review who has access, particularly when people leave.<\/strong><\/p>\n None of this is complicated. It is simply the part that gets skipped until the day it matters.<\/p>\n Not sure whether your Odoo is properly protected?<\/p>\n Get in touch. We will check your backups, your environments and your access \u2014 starting with whether anyone has ever successfully restored one.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" One database, one company Odoo stores everything in a PostgreSQL database. Customers, products, orders, stock moves, journal entries, attachments, settings \u2014 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9110,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9109","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nBackups<\/h2>\n
What a backup contains<\/h3>\n
How often<\/h3>\n
Where<\/h3>\n
The rule everyone knows and few follow<\/h3>\n
\n
\n
\n
\n
Environments<\/h2>\n
\n
\n
\n
\n
Staging must be neutralised<\/h3>\n
Upgrades<\/h2>\n
\n
Performance<\/h2>\n
Access and security<\/h2>\n
\n
\n
Hosted or self-hosted<\/h2>\n
The short version<\/h2>\n