Backups that run, and an admin console that is no longer wide open
Scheduled backups that can't collide, and a guard on Odoo's database manager that a compromised admin account can't switch off.
The problem a client brought us
“We have database backups configured, but we're not confident they'd actually work in an emergency — and honestly, we're not sure how exposed our admin console is either.”
Before and after
Anyone with the right access could switch it off
- Admin account
- Database access
- Database manager routes
Where the guard reads its settings
The server config file
What we found and built
Automatic backups across nine destination types, with PostgreSQL advisory locks so concurrent workers can't run two backups at once.
Alongside it, a security guard for Odoo's normally-unauthenticated database management routes: IP allowlisting, failed-login lockout, and full audit logging — with every setting read from the server config file, not the database, so a compromised admin account can't disable its own guard rail.
Result
Backups that actually run on schedule, and an admin console that's no longer wide open on the internet.
The pattern behind it
Keep the off switch out of the threat's reach
A recovery secret that lives in the database protects nothing from a database administrator. Security settings and recovery secrets live in the server config instead, on both platforms.
How we think about problemsRecognise any of this?
Most of our work starts with a message that sounds a lot like this one did.