For websites you host anywhere

Restorable, notmerely backed up.

Your files, your database and the configuration you would actually need to rebuild, on a schedule, into a vault we cannot read. Plus an email the day a backup stops running, so silence never gets mistaken for success.

Files + databaseClient-side encryptedHealth alertsRestore drills
backup healthfresh
Last success
4h ago
Schedule
daily 04:00
Included
files + db
Retention
30 days
Vault used
site + mysqldumptoday 04:00ok
site + mysqldumpyesterday 04:00ok
site + mysqldump2 days ago 04:00ok
If this panel went stale, you would get an email before you noticed.
What it looks like

A scheduled job on your server, writing to your vault

No agent to install, no plugin with access to your database, no dashboard that needs a password to your site. Restic runs from cron, encrypts on your machine, and writes over SSH.

/etc/cron.daily/sc-site-backup
mysqldump --single-transaction wp_live | zstd > /tmp/db.sql.zst restic backup /var/www/example.com /tmp/db.sql.zst /etc/nginx/sites-available repository 3f7a91c2 opened (version 2, compression level auto) Files: 12 new, 341 changed, 18422 unmodified Added to the repository: 214.882 MiB (61.203 MiB stored) processed 18775 files, 3.918 GiB in 0:47 snapshot 9d41f0be saved

Two lines of that matter. 61 MiB stored for a 3.9 GiB site, because restic deduplicates and compresses. And snapshot 9d41f0be, which is the thing you name when you restore. If you cannot name a snapshot, you do not have a backup, you have a hope.

Scope

What gets captured, and what that answers

CapturedWhy it is in the set
Document rootApplication code, themes, plugins and uploads. The part everyone remembers.
Database dumpTaken with a consistent transaction so the dump matches the files, not a half-written state.
Web server configVhosts and rewrites. Restoring files without these gives you a site that will not serve.
Certificates and cronThe small things that make a restore take an afternoon instead of ten minutes.

Environments this fits today

EnvironmentWhat it needs
Linux serverSSH access, a known document root, a dump command.
WordPressFiles, uploads, database, and wp-config. Runs from the host, not a plugin.
CloudPanel and similar panelsSite-aware paths; the job is per site rather than per server.
Several small sitesOne vault, one place to see which one stopped running.

Why "a backup exists" is not an answer

A useful setup answers four questions without anyone guessing: when did the last successful backup run, what was in it, where is it stored, and how do we restore it. Most website backups fail at least two, and you find out the night the drive dies.

Backups that live inside the hosting account they protect are not backups. A compromised panel, a billing lapse or a deleted account takes both copies at once. Yours land in a separate vault, encrypted before they leave your machine, on infrastructure your host does not control.

We publish a real end-to-end restore on a schedule, with the snapshot ID and matching SHA-256 manifests. See the latest drill, with receipts.

If you would rather we hosted the site as well, backups are already included and there is nothing to configure. That is Website Hosting.

Start Free