Backups & Recovery

Overview

There are two kinds of “going back”, and they protect different things:

Restore Points

Open the resource in your dashboard and go to its Backups page. It lists the restore points that exist for that resource right now, when each was taken, and how many restores your plan has left. That page is the source of truth: if a restore point is not listed there, it does not exist.

Restore points are a safety net, not a guarantee of any particular schedule. Before a risky change (a migration, a bulk delete, a big upgrade), take your own export as well.

Restoring Data

1. Go to the resource's Backups page and pick a restore point.
2. Press Restore next to it. The restore is made into a separate copy, so your live data is never overwritten.
3. We tell you when the copy is ready. Check it, then tell support (or the AI assistant) which data to bring back.

The AI assistant and the MCP tools can do the same for you: list_vm_backups shows the restore points and request_vm_restore asks for a restore. They only reach resources on your own account.

Rolling Back a Deploy

Every deploy builds a new release while the current one keeps serving, and the release it replaces is kept. If a deploy goes wrong, open the site and press Rollback. The button shows when the previous build is from.

• Only the app code changes. Your database, uploads and environment variables are not touched.
• The site is checked after the switch. If the previous build doesn't start, your site stays on the current build and nothing changes.
• Press Rollback again to undo it.
• Rollback waits while a deploy is running.
• One previous build is kept, so rollback goes back one deploy, not to any older one.

From an agent: the rollback_site MCP tool does the same. See Deployments.

Your Own Exports

Keep a copy you control, especially before migrations.

# PostgreSQL: a compressed dump you can restore anywhere
pg_dump "$DATABASE_URL" -Fc -f backup-$(date +%F).dump

# Restore it into a NEW database, check it, then switch over
pg_restore --no-owner -d "$NEW_DATABASE_URL" backup-2026-11-05.dump

# MySQL / MariaDB
mysqldump --single-transaction -h "$DB_HOST" -u "$DB_USER" -p "$DB_NAME" | gzip > backup.sql.gz

# Files your app writes (uploads)
tar -czf uploads-$(date +%F).tar.gz ./uploads

# Check a file arrived intact
sha256sum backup-2026-11-05.dump

Best Practices

• Export before migrations. Take a dump, then run the migration.
• Restore into a new database. Point a test copy of your app at it, check it, then switch DATABASE_URL.
• Practise a restore before you need one, on a throwaway database.
• Keep one copy off Hostwares for data you cannot lose.
• Write the runbook down: who restores, how to switch over, and how to check.