On this page
What gets backed up
- User website roots (for example
/home/john/apps/mysite) - User databases and metadata needed for restore targeting
- Snapshot manifest for structured restore/download behavior
Supported backends
| Backend | Use case | Notes |
|---|---|---|
| Local disk | Fast local snapshots | Target path should be writable by the user running backups. |
| SFTP | Remote off-server backups | Use dedicated backup credentials and key-based auth where possible. |
| S3 | Object storage backup strategy | Configure endpoint, key pair, bucket, and optional region settings. |
| rclone (advanced) | Specialized storage targets | Prepare rclone config via CLI as the current user before validating backend. |
Scheduling and retention
- Define one backup policy per user repository
- Use quick schedule presets (hourly, 6-hourly, daily, weekly)
- Apply retention by count/time using restic forget + prune operations
- Prevent overlapping runs with lock/concurrency controls
Restore model
Snapshot records keep website/database associations so restore targets are explicit and predictable.
- Select a snapshot row from the snapshots table.
- Review included resources and backup type information.
- Trigger restore for desired target with confirmation.
- Verify completion status and post-restore app health.
Download snapshots as ZIP
FastCP can export snapshot contents into a portable ZIP layout:
websites/
databases/
manifest.json
README.txt
This structure avoids deep server-specific absolute path prefixes and improves portability.
For reliable long-term operations, keep backup password secrets safe and test restore workflows regularly on a staging environment.