Backups

A backup is only useful if it can be restored. Take backups on a schedule, store them off the server and test a restore on a staging copy.

What to back up

Item	Why	Frequency
Database	Orders, customers, vendors, settlements	Daily, or more often at volume
Uploads	Menu images, logos, documents	Daily incremental
`.env`	Keys, database credentials, mail settings	On change, encrypted
Code/repository	Customisations and deployed release	Every release, tagged
App signing keys	Future app updates	On creation, offline copy
Gateway and store accounts	Recovery and ownership	Documented, access controlled

3-2-1 rule

Keep at least three copies, on two different media, with one off-site. A backup on the same VPS does not protect against disk loss, ransomware or a deleted database. Use object storage in a different region and restrict delete permissions.

Schedule

Database: daily full backup, retained for 30 days; weekly retained for 12 weeks.
Uploads: daily incremental, weekly full.
Before every upgrade: on-demand database and file backup.
Monthly: restore the latest backup to staging and run a test order.

Restore drill

Provision a clean staging server with the same PHP/MySQL versions.
Restore the database and uploads.
Restore .env with staging credentials.
Run the installer/upgrade steps only if required.
Log in, place a test order and check an image.
Record the time taken and fix anything missing.

Encrypt off-site backups. They contain customer names, addresses, phone numbers and order history. Restrict access and delete old copies according to your retention policy.