A backup is useful only when you can recover the application from it. Check which backup service, retention and storage are actually included in your order. This guide does not promise that off-site backups are enabled on every server.
1. Capture the complete application
- WordPress: database, uploads, themes/plugins and configuration.
- Odoo: PostgreSQL database, its matching filestore, custom add-ons and configuration.
- ERPNext: database, public/private files, installed app versions and protected site configuration including encryption keys.
- Magento: database, media, application/dependency version records and protected configuration/encryption keys.
Use application-aware database exports. Copying a running database's raw files is not a general-purpose consistent backup. Coordinate files and database changes so their recovery points agree.
2. Create and protect the backup
Schedule backups according to how much recent work you can afford to lose. Keep an encrypted copy outside the server and use a separate restricted account for backup storage. Do not store database dumps under a public website directory.
For an existing Frappe deployment, the following command creates a site backup including files. Run it inside the correct backend environment, replace the example site name and check available disk space first:
Run each command separately:
bench --site erp.example.com backup --with-files
Keep the corresponding site configuration separately in protected storage. Record the backup time, app versions and where its restore instructions are held. Verify that scheduled jobs actually produce recent files and alert on failures.
3. Perform a restore drill
- Create a separate private recovery environment with matching application and database versions. Never test restoration by overwriting your live store or business database.
- Disable outbound customer mail, live payment actions and integrations on the recovered copy before starting it.
- Restore the database, files and necessary protected configuration together. Do not blindly restore networking or server identities from another machine.
- Log in and check representative records, attachments, a page and background jobs. Verify that older records and recent records are both present.
- Record the recovered timestamp, time taken and any missing components. Correct the backup process if the drill fails.
4. Upgrade only with a recovery path
Take a new backup before upgrades. Test the upgrade and recovery on a copy, including custom modules. Changing a container tag is not a database migration plan. Do not delete volumes or reinstall the server to fix an application error.
References: WordPress backups · Frappe backup operations · Odoo persistent data.
Technical guidance reviewed: 28 October 2026. Match instructions to your actual service and application version.
