Database, files and compatible code belong to the same recovery scenario.
Define the scope first
An application needs more than database records. Odoo stores attachments in a filestore, so a transfer procedure must account for both database and matching files. Code and installed modules also affect startup. Separate data, code and configuration rather than treating one archive as proof of recovery.
A verifiable outcome is a restored, tested workflow, rather than merely an existing archive.
Check consistency
Backups and application activity may happen at the same time. Explain which database and file snapshot is used and how omissions are prevented. PostgreSQL documentation distinguishes SQL dumps, file system backups and continuous archiving; the choice depends on system conditions.
Restore in an authorised environment
Test recovery separately from the working application. You need an available test environment, explicit limits on external effects and startup acceptance criteria. Check mail, webhooks and scheduled actions so the restored system does not unexpectedly contact real recipients.
Test the workflow, not just startup
Check sign-in, expected records, attachments and a key working process. Inspect error logs and record limitations. A running container and an accessible login page are not evidence that the application works.
A clear solution and a practical next step
| Object | Check |
|---|---|
| Database | Expected records can be read |
| Files | Attachments can be opened |
| Code | Version and modules are compatible |
| External effects | Delivery restrictions are checked |
Leave a repeatable procedure
Document backup contents, required version, restore command, expected checks, responsibility and rollback conditions. Do not publish secrets or internal infrastructure addresses. Another person should be able to repeat the procedure without guessing.