# Backup, restore, and production checklist

## Application backup

Users with `backups.create` can create a consistent backup from Settings → Backup. MySQL backups use `mysqldump --single-transaction --routines --events`; files are private, checksummed, audited, and permission-protected. Schedule an additional infrastructure backup outside the application.

Recommended policy: daily encrypted database backup, weekly full application/storage backup, 35 daily copies, 12 monthly copies, and at least one off-site region/account. Test restoration quarterly.

## Restore rehearsal

Never restore over a live database without an approved outage and a verified pre-restore backup.

1. Provision an isolated MySQL database.
2. Verify the stored SHA-256 checksum.
3. Import with `mysql -u USER -p DATABASE < backup.sql`.
4. Point a non-production `.env` to the restored database.
5. Run `php artisan migrate:status`, login, reconcile the latest invoice/journal/stock ledger, and run acceptance tests.
6. Record duration, recovery point, and evidence.

## Production go-live checklist

- [ ] PHP 8.3 and MySQL 8 are patched; required extensions are enabled.
- [ ] TLS is enforced; the document root is `public/`; directory listing is disabled.
- [ ] `APP_ENV=production`, `APP_DEBUG=false`, a unique `APP_KEY`, secure sessions, and warning-level logs are configured.
- [ ] Database and SMTP use dedicated least-privilege credentials stored outside source control.
- [ ] Administrator default password changed; named accounts, roles, and branch access reviewed.
- [ ] Official company data, VAT certificate number, national address, logo/stamp, bank details, VAT rate, and document sequences approved.
- [ ] Financial year is open and period-lock policy approved.
- [ ] Negative stock is disabled unless explicitly authorized; credit limits and overrides are tested.
- [ ] Storage and cache permissions are minimal; private backup directory is not web-accessible.
- [ ] Queue worker and scheduler are supervised; log rotation, uptime monitoring, disk/DB alerts, and error reporting are active.
- [ ] `composer audit`, `php artisan test`, route/view/config cache, migration status, and a staging smoke test pass.
- [ ] Backup and isolated restore are proven; recovery owner and outage contacts are documented.
- [ ] Sample/test transactions are removed or clearly retained as opening/test evidence before real numbering begins.
- [ ] ZATCA scope is recorded as Phase 1 only; no Phase 2 integration is claimed.