How BackupYourSite works

From the moment you add a site to the moment you restore it — here's exactly what happens, with no magic and no hand-waving.

1 · You connect a site

Add the site's SSH host, username and folder. Prefer keys? Generate an ed25519 keypair in the dashboard and paste the public half into your hosting panel — we never have (or want) a way to install keys on a server ourselves. Click Test and we verify the login, resolve the real remote path, and — for PHP apps — run a real connection test against the database credentials, so misconfiguration is caught while you're looking, not at 4am.

2 · The nightly run

At your scheduled time, our servers open an SSH connection to yours. For WordPress, the database credentials are read from wp-config.php right then — so they're always current. Your files are tarred and your database dumped, and both are streamed back over the same SSH channel directly into our staging area. Nothing is written to your server's disk at any point.

3 · Verification

Before a run may report success, each archive must pass integrity checks and the database dump must end with MySQL's own "dump completed" marker, with sizes above sanity floors. Fail any check and the run is marked failed and retried — we'd rather tell you a backup failed than store a broken one silently.

4 · Offsite storage & retention

Verified archives are uploaded to encrypted offsite storage in your own isolated namespace, then local staging is wiped. Backups older than your retention window are cleaned up only after a fully clean run — so a failing night can never remove your last good copy.

5 · You stay informed

Failures alert immediately; every morning a summary email covers the previous 24 hours — including any enabled site that silently didn't run, which is the one failure most monitoring never catches. Full run history is always in your dashboard.

6 · Restoring

Pick a site, see every backup actually held in storage (listed from storage itself, not from a log that might be stale), choose files / database / both, and confirm twice — the second confirmation is checked on our servers, not just in your browser. Archives are verified again before anything is touched, then streamed back over SSH the same way they came. Live progress in the dashboard; permanent entry in the restore log.

The design rule behind all of it

Every decision follows one rule: the failure mode must never be silent data loss. Verification before success, retention only after clean runs, restore lists read from storage itself, and alerts for the backup that didn't run — not just the one that failed.

Start your free trial