Backups & Disaster Recovery

Overview

Hostwares protects both your running sites and your data. Database snapshots, deployment images, and volume backups work together so you can roll back quickly and recover from failures without data loss.

What Is Backed Up

• Database content — full logical dump plus write-ahead logs for point-in-time recovery where supported.
• Deployment images — every successful build is stored as an immutable image tagged by deployment ID and Git commit.
• Environment metadata — env variable keys (not values) and build settings are snapshotted with each deploy.
• Not included — ephemeral container filesystem, in-memory cache, and external object storage you manage yourself.

# What a backup contains
backup-2026-05-13/
  dump.sql.gz        # pg_dump (custom format)
  manifest.json      # DB version, size, checksum
  wal/               # WAL segments (if PITR enabled)

# What a deployment image contains
image: registry.hostwares.app/sites/abc123:deploy_xyz789
  build: npm run build output
  env snapshot: keys only (values stay encrypted separately)

Automatic Backups

Enabled by default — no action required.

You will see each automatic backup in Databases → [DB] → Backups orSite → Deployments with status Completed, duration, and size.

# Example: list backups via API
curl -s https://hostwares.com/api/databases/$DB_ID/backups \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" | jq

# Response
[
  { "id": "bk_1a2b3c", "type": "automatic", "status": "completed", "sizeMB": 412, "createdAt": "2026-05-13T03:02:11Z" },
  { "id": "bk_4d5e6f", "type": "manual", "status": "completed", "sizeMB": 418, "createdAt": "2026-05-12T14:20:00Z" }
]

Manual Backups

Create a backup before risky changes (migrations, bulk deletes, major deploys).

1. Go to Databases → [DB] → Backups → Create Backup.
2. Optionally add a label (e.g., before-migration-2026-05-13).
3. Wait for status to become Completed — usually under 2 minutes per GB.

# Trigger manual backup via API
curl -X POST https://hostwares.com/api/databases/$DB_ID/backups \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label": "before-migration-2026-05-13"}'

# CLI
hostwares db backup create --database $DB_ID --label "pre-release"

Application-level dumps

# pg_dump directly (works from any Hostwares container or locally via connection string)
pg_dump "$DATABASE_URL" -Fc -f backup.dump

# MySQL / other engines (if using external DB)
mysqldump -h $DB_HOST -u $DB_USER -p $DB_NAME | gzip > backup.sql.gz

# Filesystem (volumes with uploads)
tar -czf uploads-backup.tar.gz /data/uploads

Retention & Storage

Need longer retention? Export backups to your own object storage (S3/R2) on a schedule — see Download & Export below — or contact support for extended retention.

Restoring

Database restore (in-place)

1. Databases → [DB] → Backups → pick a snapshot → Restore.
2. Confirm — the DB will be briefly unavailable during restore (typically seconds to a few minutes).
3. Verify with your app's health check before resuming traffic.

# Restore to same database via API
curl -X POST https://hostwares.com/api/databases/$DB_ID/restore \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"backupId": "bk_1a2b3c"}'

# Restore to a NEW database (safe: original untouched)
curl -X POST https://hostwares.com/api/databases \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-db-restored", "sourceBackupId": "bk_1a2b3c"}'

Site rollback (zero rebuild)

Every successful deployment keeps its image. Rolling back swaps the running container to the prior image — no rebuild needed. See Deployments → Rollbacks.

# Rollback via API
curl -X PATCH https://hostwares.com/api/sites/$SITE_ID \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "rollback", "deploymentId": "dep_prev123"}'

Point-in-time recovery (PITR)

For supported database plans, PITR replays WAL segments to restore to any second within the retention window. Contact support to enable PITR and request a PITR restore.

Download & Export

Keep an off-site copy or feed backups into your own archival pipeline.

# Download a backup file (presigned URL)
curl -s https://hostwares.com/api/databases/$DB_ID/backups/bk_1a2b3c/download \
  -H "Authorization: Bearer $HOSTWARES_API_KEY" | jq -r .url | xargs curl -o backup.dump

# Nightly export to S3 (cron in any Hostwares container or external runner)
0 4 * * * pg_dump "$DATABASE_URL" -Fc | aws s3 cp - s3://my-bucket/hostwares/$(date +\%F).dump

# Verify integrity
sha256sum backup.dump
# Compare against manifest.json checksum shown in dashboard

Disaster Recovery

Plan for the worst — test recovery before you need it.

# Safe restore pattern: never overwrite prod blindly
# 1. Restore to new DB
# 2. Point a staging site at new DB and verify
# 3. Swap DATABASE_URL on prod and redeploy
DATABASE_URL=postgresql://user:[email protected]:5432/app  # updated in Site → Environment

Best Practices

• Backup before migrations — create a labeled manual backup, then run migrate deploy.
• Test restores quarterly — restore to a throwaway DB and run your test suite against it.
• Export off-site weekly — push one dump to S3/R2 for retention beyond Hostwares windows.
• Keep images — don't delete recent successful deployments; they are your fastest rollback.
• Monitor backup status — alert on failed automatic backups via Webhooks (backup.failed).
• Document the runbook — who restores, how to cut over DATABASE_URL, and how to verify.