Configuration

Every setting in Automatic Database Backup, and what each one changes.

1. Create a destination

Settings → Database Backup → Destinations → New

Press Test Destination before saving anything you rely on. It checks the folder is writable, or that the SFTP credentials work, without dumping a database.

ZIP or SQL dump

This is the one setting people get wrong, and they find out during a restore.

Choose ZIP unless you have a specific reason not to. An SQL-only backup restores a database whose attachments are all missing, and there is no way to get them back from that file.

Where to put the files

• Not inside your Odoo installation or its filestore — an upgrade will wipe it.
• Not on the same disk as PostgreSQL, if you can help it. A backup on the same disk protects you from a mistaken delete, not from the disk failing.
• Give the folder to the Odoo user with mode 750. A backup contains every password hash in your system.

Two destinations, not one

The arrangement that actually works is a nightly local copy plus a second copy that leaves the machine. Create two destinations; both run on the same schedule and are recorded separately, so a failing off-site copy is visible even while the local one keeps succeeding.

2. Turn the schedule on

Settings → Technical → Automation → Scheduled Actions → Database Backup: Run Destinations

It ships inactive, on purpose: installing a module should not start dumping your database somewhere nobody has chosen. Set it active, and set Next Execution Date to the first quiet hour you want it to run — the dump loads the server, so the middle of the working day is a poor choice.

Daily is the usual interval. The cron runs every active destination in turn and a failure in one does not stop the others.

3. Retention

Backups older than Keep For (days) are deleted after a successful run. Never after a failed one: deleting yesterday's good backup because today's failed is exactly the wrong moment to be tidy.

Retention only ever removes files this module wrote, matched by the database name and its own timestamp pattern. Anything else in the folder — a manual copy, another database's backups, somebody's spreadsheet — is left alone.

Retention is not applied to SFTP destinations. The remote server decides what it keeps; guessing would risk deleting somebody else's archive on a machine this module knows nothing about.

Choosing a window

Long enough to survive a problem you did not notice immediately. Thirty days is a reasonable default: it covers a corruption discovered a fortnight late. Weigh it against disk — the History screen shows real sizes, so multiply.

4. Alerts

Add users to Alert On Failure. They are emailed the moment a run fails, with the server's own error message.

There is deliberately no success email. A nightly "backup succeeded" is deleted unread within a week, and after that so is the one that says it failed.

If you want a positive heartbeat, watch the History screen instead — or point external monitoring at it.

5. Who can configure this

Only Settings-level users. A destination is a pipe carrying your entire database somewhere, so pointing one is deliberately an administrator's power.

For people who only need to know whether backups are running, grant the Backup: History Only group: they see the run history and results, and never the folder paths or the SFTP password.