Backing Up Your Self-Hosted Site: A Backup Strategy for Databases, Files, and Configs with Offsite Storage

The Three-Part Backup Kit for Self-Hosted Sites: Backup Frequencies for Databases, Files, and Configs, Plus a 3-2-1 Offsite Storage Strategy

Backing Up Your Self-Hosted Site: A Backup Strategy for Databases, Files, and Configs with Offsite Storage

Bottom line first: What you need to back up on a self-hosted site isn’t “the whole server” but three types of assets: the database (transactions and content), files (user uploads and media), and configs (code and environment). The three have completely different backup frequencies and methods, and backing them up together is guaranteed to cause problems. Put the 3-2-1 principle to work: 3 copies, 2 types of media, 1 offsite, with the latter two in different data centers. The most critical, counterintuitive insight is this: a successful backup doesn’t count for anything. Only a full recovery from that backup within 4 hours counts. A backup you’ve never test-restored is as good as no backup at all.

1. Why You Can’t Just “Back Up the Whole Disk and Call It Done”

Many site owners back up by “packing up the entire server and storing it every day.” It sounds safe, but it has three problems.

First, the full package is too big. A single backup run takes hours, and incremental backups can’t be done at a fine enough granularity. Second, the three types of assets change at wildly different rates: the database changes every hour, files change occasionally, and configs sit untouched for months. Backing them all up at the same frequency either wastes resources or falls short. Third, when you restore from a full package, you restore junk files and hacked code along with everything else, which means you restore the incident too.

Here’s the counterintuitive judgment:The value of a backup doesn’t depend on how much you backed up, but on whether you can restore it and how fast. I’ve seen too many sites that “back up daily” only to discover on the day the server dies that the backup files are corrupt, nobody knows the password, and the offsite copy never actually uploaded successfully.

There’s only one acceptance test for a backup strategy: take that backup to a brand-new machine and see whether you can get the site running within 4 hours. This is also why Backup and recovery drills for your site emphasizes “recoverability verification.”

Asset type	What It Includes	Change Frequency	Consequence of Missing It
Database	Orders, inquiries, users, content tables	Hourly	Loss of transaction and customer data
Document	User uploads, images, attachments, media	Daily	Loss of attachments and product images
Configs / Code	Themes, plugins, Nginx configs, environment variables	On every change	Can’t reproduce the original site after a reinstall
Full-disk package	All of the above plus system junk	Daily	Too big, too slow, and restores carry the infection

2. Database Backups: Full Plus Incremental, with RPO Kept Under 1 Hour

The database is the most important of the three asset types, and the one you can least afford to lose. The strategy is full plus incremental: run a logical full backup once a day in the early morning (mysqldump or an equivalent tool), and turn on binlog for hourly incrementals. In the worst case you lose only the last hour of data. This metric is called RPO (Recovery Point Objective).

Two details are non-negotiable. First, don’t run full backups during peak hours; schedule them between 3 and 5 a.m. Second, verify the integrity of backup files. Don’t just check that the file was created. Restore to a temporary database and spot-check the data, otherwise the backup file may have been corrupt since some earlier run. As the database grows, logical backups slow down; at that point consider physical backups or the automatic backups built into your cloud database.

Example scenario: At 4 a.m., an order table is accidentally dropped. Recovery: restore yesterday’s early-morning full backup to a temporary database, then replay the binlog from 4 a.m. yesterday up to the moment before the incident. The database is back to one minute before the incident. The whole process takes about an hour, keeping the loss to a minimum.

Backup method	Frequency	RPO	Best-fit stage
Daily full logical backup	Once a day	About 24 hours	Fewer than 5,000 daily visits
Full + binlog incremental	Full daily, incremental hourly	≤ 1 hour	Standard setup for sites with transactions
Cloud database automatic backup	Managed by the provider	Usually within 5 minutes	The worry-free choice once you’re on the cloud
Primary-replica real-time sync	Real-time	Close to 0	Add when you need high availability

3. Files and configuration: back them up separately, don’t mix them into database backups

Files (inquiry attachments, product images and media uploaded by users) are large and change slowly, so they don’t belong in a daily database backup. Use a separate incremental sync tool to sync the upload directory to offsite object storage once a day, and that’s enough. For managing large files like images and videos, see Media Asset Governance.

Configuration and code are the easiest things to overlook. Many people back up their database well but forget that Nginx configs, plugin versions and environment variables are scattered across servers, so after a rebuild they have no idea how the site used to run.

The right approach: put all code and configuration in a Git repository, and store environment variables and secrets separately in a password vault, not in Git. That way configuration isn’t something you “back up” — every change is versioned, and you can pull back any historical state at any time.

Assets	Backup tool / method	Frequency	Offsite storage
Database full backup	mysqldump automated script	Every early morning	Object storage in a different region
Database incremental	binlog archiving	Every hour	Offsite along with the full backup
User-uploaded files	Incremental sync to object storage	Daily	Written directly to offsite storage
Code and configuration	Git commits	On every change	Remote repository in the cloud
Environment variables and secrets	Password vault	Saved on every change	Encrypted in the cloud

4. Offsite storage: putting the 3-2-1 principle into practice

3-2-1 is the old rule of backups, but solo teams often only do the first half. Its full meaning is: keep 3 copies of data, on 2 different types of media, with 1 copy off-site. The key to “off-site” isn’t “another hard drive” — it’s “another place that won’t be wiped out by the same disaster.”

On a single cloud server, that means: keep one recent backup on the local disk (fastest to restore), one in the server’s data center, and push one to object storage in another city. Block storage snapshots in the same account and region don’t count as true off-site — if the data center burns down or the account gets locked, they all go together. Keep off-site copies for at least 30 days, with a monthly long-term archive from six months back, so ransomware can’t encrypt your old backups too.

Example scenario: Your server gets encrypted by ransomware. The local backup and the server backup are both encrypted, but the copy from 30 days ago in object storage in another city is offline — the encryption software can’t reach it. You restore that copy to a new machine, lose at most 30 days of data, and the site is still up.

That’s the point of the off-site copy — it’s not for faster recovery, it’s so you still have something when “all your online copies are gone.” For the cleanup process after a hack, see After your site gets hacked.

Copy location	Media	Retention period	Role
Server local disk	Cloud disk	Last 7 days	Daily quick recovery
Object storage in the same data center	Object storage	Last 30 days	Recovery when the server fails
Off-site object storage	Bucket in another region	30 days + monthly archive	Data center / account-level disaster
Local download copy	Personal hard drive	One copy per quarter	Fallback when the vendor can’t be trusted either

5. Pitfalls: the four most common false senses of security in backups

The first pitfall is “backups on the same machine.” Storing backup files in another directory on the server means when the server goes down or gets deleted, both copies go together. Backups must leave the machine. The second pitfall is “never testing a restore.” The script says backups succeed every day, but you’ve never actually restored one — very likely some backup has been corrupted since six months ago.

The third pitfall is “backing up data but not configuration.” You restore the database, but you can’t remember which plugin version you were using or how Nginx was configured, and the site still won’t run. The fourth pitfall is “no alerts on backups.” The backup script silently dies for three weeks and nobody notices until the day you need to restore and find it’s empty. Backup jobs must have failure alerts — if two days in a row fail, notify you.

False sense of security	What it looks like	Real problem	Fix
Backup in another directory on the same machine	Backup files exist every day	Everything is lost when the server goes down	Must store off-site
Never testing a restore	Backup script reports success	Backup files may already be corrupted	Quarterly restore drill
Only backing up the database	Database is backed up daily	Configuration and code are scattered	Put configuration in Git, keys in a vault
No alerts on backups	Silent for three weeks and you’d never know	Backup jobs fail without a sound	Alert after 2 consecutive failures

FAQ

How often should you back up your site?

It depends on the asset. Run a full database backup daily plus hourly binlog increments to keep RPO within 1 hour. Sync user uploads incrementally once a day. Commit code and config to Git on every change. Don’t apply one schedule to everything. If your site has no transactions yet, a daily full database backup is fine, but once orders and inquiries start coming in, you need hourly recovery.

In the 3-2-1 rule, how far away does “offsite” actually have to be?

What matters isn’t physical distance, it’s that one incident can’t take out both copies. Two disks in the same data center don’t count as offsite, and neither do snapshots in the same account and region. Keep at least one copy in object storage in another city. For especially important data, download another copy to a personal drive as a quarterly fallback, so you still have one if your provider fails too.

Why run recovery drills? Isn’t it enough to have the backup file?

No. A successful backup doesn’t mean it can be restored. With an untested backup, you often discover during recovery that the file is corrupt, the password is forgotten, or the steps are out of date. Do this every quarter: restore the most recent backup to a brand-new machine and time it. Aim for an RTO under 4 hours; if you exceed that, optimize the process. Only after this step is a backup truly valid.

Are automatic snapshots from my cloud provider enough?

They work as one copy, but don’t rely on them alone. Provider snapshots live in the same account and region, so a data center failure, a locked account, or a provider outage takes them down along with your production data. Use them correctly: snapshots for day-to-day fast recovery, plus a separate copy of your database and files in offsite object storage. Keeping the two separate gives you both everyday convenience and disaster fallback.

Should user-uploaded images and attachments be backed up with the database?

Don’t mix them. Images and attachments are large and change slowly, so packing them into the daily full database backup makes it big and slow. Just use an incremental sync tool to copy the uploads directory to offsite object storage once a day. Naming, compressing, and reusing product images and media files should also go hand in hand with media asset governance, so your backups don’t pile up with duplicate large images.

How does a backup script know when it has quietly died?

Set up failure alerts for your backup jobs. After each run, check three things: whether the exit code is 0, whether the backup file size is normal, and whether the offsite copy actually uploaded. If any check fails, or no new backup file appears for two consecutive days, notify your usual channels immediately. A backup with no alerts means betting your safety on the script never failing.

Final thoughts

Backups are the easiest place to fool yourself: scripts are running, files are saved, everything looks safe. But the only real test is a restore. If you run a one-person site, split your three asset types, keep offsite copies on the 3-2-1 rule, and do one restore drill each quarter. You can set the whole thing up in an afternoon, then it just runs daily and you check alerts once a week.

Three steps to get it live: first, run a full database backup daily plus hourly incrementals, targeting an RPO of 1 hour. Second, separate files from config: sync files to offsite object storage daily, and put code and config in Git. Third, run a restore drill every quarter, keep it under 4 hours, and wire backup jobs to failure alerts.

Once these three steps are done, your confidence when a server fails shifts from “I hope the backup is good” to “I know I can be back up within half a day.” For the maintenance rhythm, see Website Maintenance Schedule and plan them together.

One line worth remembering: a backup isn’t just a copy of your files, it’s insurance that lets your site start over after a disaster. A policy you’ve never tested with a claim is just scrap paper.