Backup and Restore
Purpose
This page documents the backup and restore approach for Maqsafy services, including database backups, file backups, restore validation, retention, and security rules.
Backup Scope
| Component | Backup Required | Notes |
|---|---|---|
| MySQL Database | Yes | Core operational and financial data |
| Uploaded Files | Yes | Attachments, invoices, reports, media |
| Environment Configuration | Yes | Store securely, do not place secrets in documentation |
| Application Code | Yes | Managed through version control or release artifacts |
| Nginx Configuration | Yes | Required for recovery |
| Docker Compose Files | Yes, if used | Required to rebuild services |
| SSL Certificates | Yes | Store securely with restricted access |
| Logs | Optional / Policy-based | Useful for audit and incident investigation |
Backup Types
| Type | Description |
|---|---|
| Full Backup | Complete backup of the database or file set |
| Incremental Backup | Backup of changes since the last backup |
| Logical Database Backup | SQL dump that can recreate schema and data |
| File Backup | Backup of uploaded files, invoices, exports, and media |
| Configuration Backup | Backup of service configuration files |
Database Backup
MySQL provides mysqldump as a logical backup utility that can produce SQL statements to recreate database objects and table data.
Example placeholder:
mysqldump --single-transaction --routines --triggers \
-h <db-host> -u <db-user> -p <database-name> > backup.sql
Compressed example:
mysqldump --single-transaction --routines --triggers \
-h <db-host> -u <db-user> -p <database-name> | gzip > backup.sql.gz
File Backup
Document the actual file paths used in production.
Example placeholders:
tar -czf uploads-backup.tar.gz /path/to/storage/app/public
tar -czf nginx-config-backup.tar.gz /etc/nginx/sites-available
Backup Schedule
| Backup Item | Frequency | Retention | Storage Location | Status |
|---|---|---|---|---|
| MySQL Database | Daily | Lifetime / indefinite retention | S3 | Confirmed |
| Uploaded Files | To be confirmed | Lifetime / indefinite retention if included | S3 | Needs Technical Verification |
| Configuration Files | To be confirmed | Lifetime / indefinite retention if included | S3 | Needs Technical Verification |
Restore Procedure
A backup is only useful if restoration is tested.
General restore flow:
- Identify the required restore point.
- Confirm the affected environment.
- Stop affected services if required.
- Restore database backup.
- Restore uploaded files if required.
- Restore configuration files if required.
- Clear application cache.
- Restart services.
- Validate application functionality.
- Document the restore result.
Database Restore Example
Use placeholders only.
gunzip backup.sql.gz
mysql -h <db-host> -u <db-user> -p <database-name> < backup.sql
If the backup is not compressed:
mysql -h <db-host> -u <db-user> -p <database-name> < backup.sql
Laravel Post-Restore Commands
After restore, validate configuration and clear cache if needed.
php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
php artisan queue:restart
Restore Validation Checklist
| Check | Expected Result |
|---|---|
| Application loads | Homepage or health endpoint responds |
| Login works | Authorized users can log in |
| Database connection works | Dashboard data loads |
| Files are accessible | Uploaded files and attachments load |
| Queue workers work | Background jobs process correctly |
| Reports work | Key reports generate correctly |
| Logs are clean | No new critical errors |
RPO and RTO
| Term | Meaning | Maqsafy Target | Status |
|---|---|---|---|
| RPO | Maximum acceptable data loss window | Zero data loss target | Needs technical wording validation |
| RTO | Maximum acceptable time to restore service | Less than 1 hour | Confirmed |
Restore Test Status
| Item | Status | Notes |
|---|---|---|
| Restore test performed | Confirmed | Technical team confirmed restore testing exists |
| Restore evidence available | Needs Evidence | Add date, environment, and validation result |
| Last restore test date | Needs Evidence | Add when confirmed |
Backup Security
- Backup files must not be publicly accessible.
- Backup files should be encrypted where applicable.
- Access to backups must be restricted to authorized personnel only.
- Backup storage credentials must not be documented.
- Backup download links must not be public.
- Backup restore actions must be logged.
Backup Testing
Test restore procedures periodically.
| Test | Frequency | Notes |
|---|---|---|
| Database restore test | TBD | Restore to non-production environment |
| File restore test | TBD | Validate uploaded files and attachments |
| Full environment recovery test | TBD | Validate application, database, files, and services |
Incident Restore Log
Use this format when a restore operation is performed.
## YYYY-MM-DD - Restore Operation
| Field | Details |
|---|---|
| Environment | Production / Staging / Local |
| Restore Point | Backup timestamp |
| Reason | Incident or maintenance reason |
| Database Restored | Yes / No |
| Files Restored | Yes / No |
| Configuration Restored | Yes / No |
| RPO Impact | Actual data loss window |
| RTO Impact | Actual restore duration |
| Validation Result | Passed / Failed |
| Owner | Responsible person/team |
Rules
- Do not overwrite production data without approval.
- Do not run restore commands before confirming the target environment.
- Do not expose backup files publicly.
- Do not document real backup passwords or storage keys.
- Do not store backup archives inside public web directories.