Troubleshooting
What goes wrong with Automatic Database Backup, how to recognise it, and what to do.
"No space left on device"
The disk is full. Either free space, shorten Keep For (days), or move the destination to a bigger volume.
Check what the backups are actually costing you: the History screen shows real sizes, so multiply by your retention window.
"Permission denied" or "Odoo cannot write to..."
The folder's ownership no longer matches the user Odoo runs as. Usually follows a server rebuild or a manual mkdir as root.
sudo chown odoo:odoo /var/backups/odoo
sudo chmod 750 /var/backups/odooThen press Test Destination.
"... is not a folder on this server"
Either it does not exist, or Odoo cannot see it. Two things to check:
- A path on a network share may be mounted for your login and not for the service account.
- If Odoo runs in a container, the path must exist inside the container and be a mounted volume. A host path that is not mounted simply is not there.
The scheduled action never runs
- Is it active? It ships inactive on purpose. Settings - Technical - Automation - Scheduled Actions - Database Backup: Run Destinations.
- Is Next Execution Date stuck in the past? That means Odoo's cron worker is not running - check that the server is started with at least one cron thread (--max-cron-threads greater than zero).
- Is the destination archived? Archived destinations are skipped.
SFTP: "SFTP backups need the paramiko library"
Install it into the same Python environment Odoo runs in:
sudo -u odoo /opt/odoo/venv/bin/pip install paramiko
sudo systemctl restart odooA pip install paramiko into the system Python while Odoo runs from a virtualenv is the most common reason this message keeps appearing.
SFTP: "Authentication failed"
The password changed, or the account is key-only. This module authenticates with a password. If your server requires a key, use a local destination and move the files with your own key-based rsync or scp - which is a better arrangement anyway.
"The backup archive is corrupt"
Verification did its job. Something went wrong while writing. Nearly always a full disk; occasionally a network filesystem that dropped out mid-write.
Free space, check the destination is local storage rather than a flaky mount, and run it again.
The backup file is much smaller than usual
Look at the size graph in History. A sudden drop usually means the database genuinely lost data - a truncating import, an uninstalled module, an integration that deleted more than it should. Investigate the database, not the backup.
Do not let retention age out your older backups while you investigate. Copy the last good one somewhere safe first.
A run says success but I cannot find the file
Check the Written To field on the run record. If the destination is SFTP, the file is on the remote server, not this one - the local copy is temporary and is deleted after upload.
Odoo hangs or slows down while backing up
A dump is I/O heavy and, on a large database, will be noticeable. Move the schedule to a quiet hour. If it is still disruptive, the honest answer is that pg_dump from a replica or a filesystem snapshot is a better fit for that size of database than any in-process approach.
Restoring does not work
See RESTORING.md. The step people skip is copying the filestore into place - without it the database restores perfectly and every attachment is missing.
Still stuck
Email info@technovision.dev with your Odoo version, the module version, the destination type, and the exact message from the failed run record.