Setting up offsite backup has a reputation problem: every guide tells you why you need it and what could go wrong without you, then skips to a screenshot of a plugin settings page. The actual setup — the sequence of decisions and clicks between “I have nothing” and “a copy of my site leaves this server automatically” — usually gets two paragraphs. This is the missing middle, as a sequence you can run in one afternoon.
Five steps, in the order that prevents rework: choose the destination class, connect it with separate credentials, schedule the job, encrypt what leaves the server, and prove the whole thing with a real restore test. The steps deliberately end at proof rather than configuration, because a configured-but-untested backup is the single most common end state in small-site backup setups — and the one that fails loudly during incidents.
Step One: Choose The Destination Class
Pick the class before the brand. The realistic options for a small WordPress site are a cloud object-storage bucket, a consumer cloud drive with a backup plugin connector, or a second hosting account in a different organization. The decision rule is independence, not features: the destination must sit outside your primary hosting account, under credentials that a compromise of your site cannot reach. A backup folder on the same server, in the same account, or behind the same admin password is not offsite in the sense that matters; it is the same egg in a marginally different basket. Our backup access and ownership for small businesses guide covers the access and custody questions this step raises.
Step Two: Connect With Separate Credentials
Create dedicated credentials for the backup job at the destination — a bucket key, an app password, or an API token scoped to nothing but writing backups. Do not reuse your everyday login, and do not grant delete permissions the job does not need: a write-only credential means that even a fully compromised site can overwrite future backups but cannot destroy the archive. Store the credential in the backup tool’s configuration or a secrets manager, never in a notes file or a committed config. This step takes ten minutes and converts a later catastrophe into a later inconvenience.
Step Three: Schedule The Job
Match frequency to how much change your site can afford to lose, not to how often the tool can run. A brochure site updated monthly needs weekly copies, not hourly ones; a store with daily orders needs daily or better. Start conservative — daily copies kept for thirty days is a sane default for most small WordPress sites — and tune afterwards using the reasoning in how often should I back up my WordPress site and the ready-made patterns in small WordPress site backup schedule. Enable whatever success and failure notifications the tool offers, routed to an inbox you actually read; silent job death in month three is the classic failure this step exists to catch.
Step Four: Encrypt What Leaves The Server
If the destination is one you control end to end, server-side encryption handled by the provider is acceptable. If the destination is anywhere else — a shared bucket, a managed service, anything with other humans in the access path — encrypt the backup archive itself with a passphrase only you hold. The tradeoff is real and worth stating plainly: lose the passphrase and the backups are unreadable to you too, which makes passphrase custody a first-class part of the setup rather than an afterthought. Government incident-recovery guidance, including CISA’s StopRansomware materials, treats protected backups as part of surviving ransomware precisely because attackers otherwise encrypt or delete reachable copies.
Step Five: Prove It With A Real Restore
The final step is not a settings review; it is a restoration. Spin up a staging site or a local copy, pull a backup from the destination using nothing but the stored credentials, and walk the restore until the site loads with recent content. Follow the website backup restore test checklist while you do it. This is the moment you discover the wrong database prefix, the missing uploads folder, the credential that silently lacks read permission — every defect that configuration screens hide and restores reveal. Schedule the drill to repeat quarterly; the setup you proved once decays, and the quarterly re-proof is what keeps it honest.
Common Setup Mistakes To Avoid
Three mistakes account for most failed setups, and all three are cheap to avoid. The first is treating the same-account copy as offsite — it satisfies a checklist line while surviving none of the incidents the checklist was written for. The second is granting the backup job full account permissions for convenience, which silently converts every site compromise into an archive compromise. The third is declaring victory at the first green checkmark in the plugin dashboard; a successful upload proves transport, not recovery, and only step five distinguishes the two.
The Five-Step Setup At A Glance
| Step | Decision | Failure it prevents |
|---|---|---|
| Choose destination class | Outside your hosting account and failure domain | Backups lost in the same incident as the site |
| Connect separate credentials | Write-only, dedicated, non-reusable | A site compromise becoming an archive compromise |
| Schedule the job | Frequency matched to tolerable loss, alerts routed | Silent job death and stale copies |
| Encrypt outbound archives | Passphrase custody planned before enabling | Destination breach exposing your data |
| Prove with a real restore | Quarterly staged restoration drill | Discovering the broken backup during the incident |
Run the five steps once and the setup holds with modest maintenance; skip step five and the previous four are configuration, not protection. If an afternoon is all you have this week, spend it in exactly this order and let the quarterly drill carry the maintenance from there.