Automated Database Backup & Restore for Odoo

This is a build-to-order engagement, not an instant download. Typical delivery is 2 to 4 weeks from the point we confirm your requirements (Odoo version, destinations, retention rules, encryption preferences). The timeline covers development, testing against your Odoo 17/18/19 environment, installation, a verified test restore, documentation, and a handover session. Straightforward single-database setups land nearer 2 weeks; multi-database or unusual destination/security requirements nearer 4.

Every engagement includes a post-delivery support and bug-fix window during which we fix any defects and make reasonable adjustments at no extra charge. Because we build to your specific environment, you own the delivered source and it will keep working on your instance. When you upgrade Odoo (for example 18 to 19) or want new destinations, retention rules, or alerting channels, we offer an optional ongoing support/maintenance retainer to keep the module current and compatible.

The module writes to local disk, remote SFTP/SCP servers, and any S3-compatible object store — AWS S3, Backblaze B2, Wasabi, MinIO, and DigitalOcean Spaces are all supported. It runs on Odoo Community and Enterprise, versions 17, 18, and 19. You can enable several destinations at once (for example local plus S3 plus an off-site SFTP box) each with its own retention policy.

Yes on both counts. Each archive is AES-256 encrypted before it leaves the server, and all off-site transfers travel over an encrypted tunnel (SFTP over SSH or TLS to S3), so no plaintext database is ever exposed. Every snapshot bundles the PostgreSQL dump and the filestore, so a restore rebuilds a complete, working system. We include optional automatic restore-verification that test-restores backups into a disposable database, and we perform one full verified restore with you during handover.

Backups run from an `ir.cron` job, so you schedule them for off-peak windows (for example overnight). Transfers are compressed and can be throttled, and large filestores can be streamed incrementally to keep memory and bandwidth impact low. On busy servers we tune the schedule and concurrency during setup so backups do not compete with business-hours traffic.

Access is controlled with `ir.model.access.csv` and record rules that restrict backup configuration, destination credentials, and the restore action to a dedicated Backup Administrator group. Destination secrets (SFTP keys, S3 credentials, encryption keys) are stored isolated from standard config and are never shown in list views, logs, or exports. Regular users cannot see or trigger backups or restores.

Yes. The module exposes backup status through JSON-RPC / XML-RPC and an optional webhook, so tools like Grafana, Uptime Kuma, or PagerDuty can query last-run time, outcome, and next-run schedule. Combined with the success/failure email alerts and the QWeb audit report, you get layered proof that backups are running — not just an assumption.