Get started

Infrastructure

Backups

Take manual snapshots or schedule automated backups for your server, databases, apps, and email. Restore with a single click.

What is backed up

  • Servers — Full server snapshot (DigitalOcean / Hetzner snapshot of the root disk)
  • Databases — Logical dumps: mysqldump, pg_dump, mongodump, or Redis BGSAVE
  • Apps — Application directory and configuration files
  • Email — Mail data directories and Postfix/Dovecot configuration

Manual backups

  1. Navigate to Backups in the server sidebar.
  2. Click Create Backup.
  3. Select the scope: full server, specific database, app, or email.
  4. Click Start.

The backup runs in the background. Status updates appear on the Backups page. Most database backups complete in under a minute; full server snapshots take longer depending on disk size.

Scheduled backups

From the Backups page, click Schedule to configure automatic backups:

  • Frequency: daily, weekly, or custom cron expression
  • Retention: number of backups to keep (older ones are deleted automatically)
  • Scope: per-server or per-resource

Scheduled backups run at the configured time in UTC. A notification is recorded in the portal on success or failure.

Restoring a backup

  1. Navigate to Backups and find the snapshot you want to restore.
  2. Click Restore.
  3. Confirm the restore. For database restores, the current data is replaced.

Full server restores provision a new server from the snapshot — the original server is not modified. Database restores stop the container, restore the dump, and restart the container.

Where backups are stored

Backups are stored in the cloud provider’s object storage or snapshot service (DigitalOcean Spaces / Hetzner Snapshots). They are stored in the same region as your server by default. Backup storage costs are billed by the provider at their standard rates, separate from your Simplewala plan.

Troubleshooting

Backup stuck in “running” state

Check the command log for the backup job. If the underlying command failed, the backup will be marked as failed on the next status check. If it has been running for more than 30 minutes, SSH into the server and check for the backup process (ps aux | grep mysqldump etc.).

Restore fails for a database

Confirm the database container is stopped before restoring, or use the Restore button which handles this automatically. If restoring a PostgreSQL dump manually: pg_restore --clean --if-exists -d mydb backup.dump.