Backups you’ll actually need to use.
Most backup setups are never tested until the day they’re needed — and that is the day the gaps are discovered. Our work is the test-restore drill that proves your backups are real, complete, and ready before they are required.
Eight components.
One tested recovery plan.
A backup is not the file in your storage bucket. A backup is the successful restoration of that file onto a working server, in time, before customers notice. Anything short of a tested restore is an assumption dressed up as a safety net.
We treat backup work as recovery work. Every component below exists to answer one question — when something goes wrong, can we put your business back together quickly enough that it doesn’t matter? The answer should never depend on luck.
Daily Snapshots
FoundationalAutomated daily backups of files and database, captured during low-traffic windows so they don’t compete with real visitors. We configure the schedule, set the retention rolling-window (typically 30 days), and verify each night’s snapshot completes successfully — not by trusting the dashboard’s green tick, but by sampling the archive and confirming it actually holds what it claims to. For WordPress sites we use UpdraftPlus configured against an off-site target; for VPS hosts we use the provider’s snapshot APIs. Either way, the cadence is daily, the verification is automatic, and a missed snapshot raises an alert.
Weekly Archives
Long-tail recoveryA daily-only retention strategy fails the moment a problem is discovered weeks after it happened — a slow-draining database corruption, a malware injection that bedded in quietly, an accidentally deleted product page nobody noticed for a fortnight. Weekly archives give you a longer recovery horizon: typically twelve weeks of weekly restore points kept alongside the rolling daily window. Storage is inexpensive; the regret of not having last month’s clean version is not.
Off-Site Replication
Geographic separationBackups stored on the same server they were taken from are not backups — they are a single point of failure waiting to fail in unison. We replicate every snapshot to off-site storage in a different provider and a different region: Backblaze B2, Wasabi, AWS S3, or your preferred object storage. The hosting provider can suffer a regional outage, the entire account can be locked, ransomware can encrypt the primary disk; the off-site copy remains untouched and immediately recoverable.
Database Dumps
Atomic recoveryA whole-site snapshot is the right tool for catastrophic recovery, but it is the wrong tool when you need to roll back a corrupted product table or recover a single accidentally deleted user. We configure separate, frequent database dumps — every six to twelve hours for transactional sites — alongside the full snapshots. The dumps are smaller, faster to ship off-site, faster to import, and small enough to keep at higher cadences than full backups would economically allow.
Server Snapshots
Whole-machine recoveryApplication-level backups capture the site’s data; server snapshots capture the entire machine — operating system, configuration, installed packages, certificates, cron jobs, and the small undocumented changes that have accumulated over time. We schedule provider-level snapshots (DigitalOcean, Linode, AWS, Vultr) on a weekly cadence so that, in the worst case, the entire VPS can be redeployed from a known-good state in minutes rather than rebuilt from scratch over a stressful afternoon.
Test-Restore Drills
VerificationThis is the work that turns a configured backup into a real one. Every quarter we restore your most recent snapshot to a clean staging environment, run the site, and confirm — visually, functionally, and at the database level — that the restored copy matches the live site. The drill catches the silent failures: backups that completed but excluded the uploads directory, database dumps that ran but never finished writing, archive files that downloaded but cannot be unpacked. We document each drill, log the recovery time, and report any gap in the procedure to you in plain English.
RPO & RTO Planning
Recovery objectivesRecovery Point Objective (RPO) is the most data you can afford to lose, measured in time — fifteen minutes, six hours, twenty-four hours? Recovery Time Objective (RTO) is the longest you can afford the site to be down before the cost outruns the cure. We work through both with you against your real business reality, then design the backup cadence, retention, and restore procedure to meet those numbers. RPO and RTO are not vanity metrics; they are the contract that tells the rest of the system how to behave on the worst day.
Documented Restore Procedure
Under pressureA restore procedure that lives in someone’s head is a procedure that fails when that person is unreachable. We write a step-by-step runbook covering every recovery scenario your site is realistically exposed to — single-file recovery, database rollback, full-site restore, server rebuild — with exact commands, credential locations, and verification checkpoints. The runbook is stored alongside your infrastructure documentation, kept current as the stack evolves, and is written so that any competent technician can execute it under pressure without needing to improvise.
Configure. Replicate.
Restore. Verify.
Backup work fails along predictable lines: someone configures a backup that runs but does not capture everything, someone ships archives off-site that nobody ever opens, someone trusts the green dashboard tick. Our process is built to make each of those failure modes visible long before they matter.
Restore is the test, not the backup
We do not call a backup configured until we have restored it once, in full, to a clean environment, and confirmed the restoration is functionally identical to the original. Configuration without verified restoration is a leap of faith dressed up as engineering. Every initial setup ends with a recorded test restore, so the first time anyone restores your site is not the day it has actually broken.
Three copies, two media, one off-site
The 3-2-1 rule remains the floor for serious backup work: at least three copies of the data, on at least two different storage media, with at least one off-site. We design every backup architecture against this baseline and document where each copy lives, how it is refreshed, and who has access to it. If a single failure — a provider outage, a compromised account, a corrupted disk — can take all your copies down, the architecture is wrong.
Tested every quarter
We schedule a restore drill every quarter and we run it whether or not anything looks worrying. A backup that has been sitting untouched for months is not known to work; it is suspected to work. The quarterly drill is how we move it from suspected to known. We log restore time, identify any gap that has crept in, and tighten the procedure before the next cycle. Backups erode quietly — the drill is what catches the erosion.
Plain-English runbook
Every backup configuration is paired with a written restore procedure that any competent technician — not just us — can execute. Step-by-step commands, where credentials live, what counts as a successful verification, what to escalate. The runbook does not assume you’ll have us on call when you need it; it assumes the worst-case scenario where someone else has to do the work, and it makes that someone’s job survivable.
Sites where downtime
costs more than storage.
Backup and recovery is the kind of work that justifies its retainer cost on the first incident — and is invisible until then. It is most valuable for businesses where a lost day, a corrupted database, or a ransomware event would directly cost revenue, customer trust, or compliance standing.
A few recurring profiles where the test-restore work pays for itself the first time it is needed.
- i Businesses relying on a host’s free backup tierThe host’s own backup is configured and visible in the dashboard — but nobody on the team has ever tested a restore. The default tier is usually retained for seven days, lives on the same provider, and excludes media uploads.
- ii WooCommerce stores where every order mattersAn hour of corrupted database costs orders, customer trust, and reconciliation work for weeks. Frequent database dumps, off-site replication, and a tested rollback procedure are not optional at this stage.
- iii Professional firms with sensitive intake dataLegal, healthcare, financial — anywhere a form collects information you have a duty to protect. Backups need to live outside the primary environment, retention needs to match your regulatory obligations, and the restore procedure needs to actually have been rehearsed.
- iv WordPress sites that have never been auditedYou inherited a site, the previous developer set up “backups”, and nobody has looked at them since. The audit usually surfaces at least one of: an expired plugin licence, a full storage bucket, an exclusion list that quietly skips uploads, or a target that has been failing for months.
- v Teams preparing for a major changeMigration, redesign, plugin overhaul, theme rebuild. A verified restore point taken the day before the work starts is the safety net that lets the team be bold rather than cautious. We schedule and verify it as part of every change-window engagement.
Backup and recovery is also the unglamorous prerequisite for every other piece of infrastructure work we do. Server hardening, SSL certificate renewals, plugin updates, theme migrations — all of it carries non-zero risk, and all of it becomes far easier to attempt when there is a tested restore point sitting one command away. We don’t sell backup as an add-on; we treat it as the floor that the rest of the practice stands on.
Curious how Google sees your site?
Send us your URL. We’ll send back a Premium SEO Report, prepared by hand, within 48 hours — domain authority, keyword rankings, backlinks, competitor gap, and the quick wins worth chasing first.
No sales call required.
A backup that has never been restored is a story you tell yourself. The restore drill is what makes it true.— The Aureole Practice —
Questions we get
about recovery.
If a question is missing here, the contact link at the foot of the page goes straight to the person who would answer it. No ticket queues, no funnels.
i Our hosting already includes backups — why pay for more?
ii How often should backups actually be tested?
iii What is RPO and RTO, and why do I need to think about them?
iv Can you take over a backup setup someone else built?
v What happens if the site is hit by ransomware?
vi How long does the initial setup take?
Where backup fits in
the wider practice.
Backup and recovery is one layer of the IT services practice — the floor that lets the rest of the work move quickly without losing nerve. The link below returns to the parent service; the pills extend laterally to the sister sub-disciplines that compound with restore-tested infrastructure.
Parent service
Sister sub-disciplines
Adjacent services
Ready to find out
if your backups work?
Tell us where the site lives and what is currently configured. We’ll audit the existing setup, run a real test restore, and report back in plain English on what is solid and what needs tightening — before the day you actually need to use it.