Backups & Maintenance
Sugerir una ediciónPlan database and file backups, rehearse a restore, and maintain the services that keep the store running.
On this pageJump to a section
Build a recoverable operation instead of relying on an untested ZIP or a successful-looking backup notification.
Define what must be recoverable
| Component | Why it matters |
|---|---|
| Database | Catalog, orders, customers, settings and transaction history |
| Uploads/storage | Product media, documents and other user-managed files |
| Environment/configuration | APP_KEY, database/mail configuration and deployment settings |
| Themes/extensions | Your installed versions and custom work |
| Release/recovery record | The core version, required dependencies, backup id and restore instructions |
Protect database exports and .env as sensitive data. Store backups outside the public web root and restrict access. A public download URL for a backup is a security incident, not a convenient operating shortcut.
Choose a backup schedule
Use a schedule based on the amount of data you can afford to lose and the time you can afford to be down. Frequent orders require a different plan from an occasional test store. Include a backup before upgrades, large imports, theme replacements, and significant integration changes.
Coordinate database and files so they represent a compatible state. Keep retention and off-host copies appropriate to your business, and monitor backup failures. A backup on the same disk does not protect against that disk being lost.
Rehearse restoration on staging
- Create a separate isolated environment and database.
- Restore the database and required files from a known backup.
- Restore the matching configuration securely, then change URLs and disable real payments/email for the test copy.
- Verify admin access, representative products, orders, customer-account behavior, and media.
- Record how long recovery took, what was missing, and who can perform it.
Do not perform a restoration drill over production. A restore can overwrite orders created after the backup; plan a maintenance window and reconciliation before any real rollback.
Upgrade backups and recovery
The platform upgrade flow supports its own backups and recovery. Read Upgrade Preparation for wento:upgrade, the backup location, and recovery considerations. Recovery tokens and credentials must remain private.
An upgrade backup does not replace an ongoing backup policy. Keep a known previous release and understand how your host restores files and database together.
Maintain services and observe failures
- Check disk space, log growth, failed jobs, and mail delivery.
- Run the queue/scheduler processes required by enabled features under the host’s supported process-management setup.
- Review expiring certificates/domains and provider credentials.
- Use maintenance mode for appropriate planned work and test customer/admin access rules.
- Keep extension/theme versions and change records available for troubleshooting.
Know the safe first action
If checkout or admin breaks, capture the error and timestamp, preserve logs, and identify the last change. Do not delete the install lock, reset the database, or regenerate APP_KEY as a generic repair step. Those actions can make recovery harder. Use a verified rollback only after considering new transactions and the actual failure.
Continue learning
Upgrade Preparation · Staff & Permissions · Installation Errors