Every webcare service claims backups. Almost none can prove theirs restore. Ours are verified byte-for-byte at capture time and drilled with a real restore every week — because the worst day to discover a broken backup is the day you need it.
Most backup failures are silent: the dump looks valid, the file uploads, and the data inside is already wrong.
Files and database are captured with charset and binary data preserved — including the serialized arrays, emojis and BLOB columns that naive export tools quietly mangle.
After every backup we compare what was captured against the source. Not “the file exists” — the bytes match. An empty or truncated dump is rejected and flagged, never uploaded and forgotten.
Backups are encrypted and stored in a private Cloudflare R2 bucket, away from your hosting. Downloads happen through short-lived scoped links — there is no public URL to leak.
Every week we restore a real backup into an isolated scratch database and scan the recovered data for corruption. If a backup can't restore cleanly, we find out on our schedule — not during your outage.
We ran a full data-fidelity audit of our backup and restore path, found six ways WordPress data can silently corrupt, fixed every one, and turned each into a permanent automated check. The full write-up is on the data safety page.
Thirty days of retention with one-click restore from any of them. Malware discovered two weeks late is still inside your restore window.
Updates run against a fresh restore point, with Safe Updates screenshotting before and after. A bad update rolls back instead of becoming your client’s problem.
Ask for your backups and we hand them over — no lock-in, no export fee. Cancel and your data leaves with you. It’s in the terms, not just the marketing.
Send us your URL. We’ll look at what your current setup would really recover — and tell you straight, even if the answer is “you’re fine.”