My Backup Routine, Written Down After Nearly Needing It

Fifty-nine of the ninety posts on this blog were about to go to draft in a single pass, from a script talking to the WordPress REST API. It was 19 September 2026, and I have done mass edits that way before without anything dramatic happening. That is the problem with them: nothing dramatic happens until the status field is right but the filter is not, and by then the thing you are looking at is the only copy.

So I did not run it. I pulled the whole site onto my laptop first, and then did something I had been putting off since the site launched: I wrote down what my backups actually cover, file by file, rather than what I assume they cover. This post is that list, including the four holes I found in it and the one test I still have not done.

What I pulled, and what it weighs

The copy came out of the public WordPress REST API, not out of a plugin: every post and page with _embed so the author, category and media references come along, the rendered HTML of each post in its own file, the taxonomy, and the handful of raw files at the root of the domain that nothing else would have captured.

That last row is the one I would not have thought of a year ago. A whole Next.js export is still sitting on this domain from before the move to WordPress, and the plan is to delete it. Copying something before you delete it is obvious right up until the moment you are deleting it, which is when you are tired and it is late. I have written up how that old export kept breathing on the same domain for months after the migration separately.

Four things that copy does not contain

I went looking for the gaps on purpose, because an export you have not audited is just a folder you feel good about. Four of them, roughly in the order they would hurt:

• Anything not published. The public REST API returns published content, so drafts and scheduled posts are not in that file. If I had a month of posts queued up, my backup would not know they existed.
• The images. media.json has two entries: a logo and an icon. That is the entire media library. Everything else in those ninety posts is referenced from elsewhere, so an export of the library is an export of almost nothing, and I had been counting it as coverage.
• Settings. Theme options, plugin configuration, permalinks, menus, the snippets I added by hand. Rebuilding from this copy would give me my words back and nothing else.
• The database itself. Users, comments, options tables, anything a plugin keeps in its own rows. A REST export is a content export, not a database dump, and should not be described as one.

None of that makes the copy useless. It makes it a content backup, which is what I was worried about losing to a bad loop. The mistake would have been calling it a site backup.

The copy the panel makes, and what the page says about it

Three of my sites sit on one Hostinger shared plan. The panel makes its own backups, and how often depends on the tier you are on. On the Hostinger shared hosting page, checked on 20 September 2026: Premium lists weekly backups at $2.99/month renewing at $10.99/month, Unlimited lists daily backups at $3.99 renewing at $16.99, and Cloud Startup lists daily plus on-demand backups at $7.99 renewing at $25.99. Those entry prices all assume a 48-month term paid up front.

I am pointing at the renewal column for a reason. Backup frequency is one of the features people use to justify moving up a tier, and weekly against daily is a real difference. But the price you weigh it against is the four-year prepay number, not what you pay in year five. I have worked through what those renewals do to the eight-year total elsewhere; backups are one of the few upsells that survives the arithmetic.

Why a host backup is not the whole answer

A backup that lives inside the same account as the site shares that account’s failure modes, and it is a short, boring list: the account gets suspended, the card on file fails at the wrong moment, or the person with the password does something stupid. In all three cases the live site and the backup of it are on the same side of the same locked door.

I am not going to dress that up with a statistic about how many sites get hacked per day. The version of this post I am replacing opened with one, and I could not find where the number came from. The argument stands without it: two copies in one account is one copy with extra steps.

The account password is part of the backup strategy, whether or not you think of it that way. When I audited these blogs I found the REST API happily listing the login name of the only account on the site: not a breach, but a free head start for anyone trying the door. What I found open on my own blogs and what I closed is its own write-up.

The static site, where the backup is the site

One of my sites is static and runs on Cloudflare Pages on the free plan. No database, no PHP, no admin login. The site is a folder of files and deploying it is copying that folder, so the backup question changes shape completely: the folder on my machine and the thing on the internet are the same files, and there is nothing else to lose.

That is one of the reasons I keep putting small sites there. The catch is that it only holds if the folder you have is the folder you deployed, and the only thing enforcing that is you. If you edit a file directly in a dashboard somewhere and never bring it back down, you have quietly started running a site whose source you no longer hold.

The part of my VPS nobody is backing up

I also run a small Node app on a Hostinger KVM 1 VPS, with Caddy in front of it and systemd keeping it alive. The VPS pricing page, checked 20 September 2026, lists that plan at $6.49/month on a 24-month term renewing at $11.99, with 1 vCPU, 4 GB of RAM, 50 GB of NVMe and 4 TB of transfer. What it lists is the machine. The backup wording I quoted earlier is on the shared hosting page, a different product.

On an unmanaged box, everything that keeps the site alive is something somebody typed: the Caddy config, the systemd unit, the certificate settings that took two attempts to get right. None of it is content, so none of it is in a content export. In my case the configuration survives because I deploy from a folder on my own machine, where those files live too. The database the app writes to is another matter: as far as I have set anything up, it exists on that server alone. “It is on the server” is not a backup. I keep a running list of the jobs that are mine on the VPS and not mine on shared, and this sits near the top of it.

If you are considering a VPS because it is six dollars a month and the shared plan annoys you, that configuration work is the part of the bill that is not denominated in dollars.

What I am not going to recommend to you

There is no backup plugin installed on either of my WordPress blogs. So I am not going to rank UpdraftPlus against BlogVault against Jetpack’s backup product, quote you annual prices for them, or tell you which one restores best under pressure. I have not run any of them, and anything I wrote would be a summary of their marketing pages with my name on it. The version of this article I am replacing did exactly that, with approximate prices and confident verdicts attached. Deleting it was the easiest decision in this rewrite.

What I will say, because it requires no experience I do not have: a backup plugin that writes to storage you own, under an account your host does not control, solves the same-door problem above. That is the property worth shopping for.

I have never restored any of this

Here is the part a tidier article would cut. I have a content export I audited yesterday, a host that makes its own copies on a published schedule, a static site whose source I hold, and a VPS whose database I do not. And I have never restored a site from any of them. The only restore I have ever done was a handful of logo and favicon files pulled back out of a panel backup for my agency site in July 2026, which worked and proves very little. Nothing with a database, no test run, nothing restored to a staging subdomain.

So everything above describes files, not a recovery. I know what is in my copy because I opened it and counted. I do not know how long a restore takes, or which settings I would find missing forty minutes into a bad afternoon. Anybody who says their backups work without having restored from them is saying their backups exist. Different claims, and I have been making the wrong one.

The fix is scheduled rather than done: restore this blog to a staging copy and write down how long it took and what was wrong with it. When that happens it becomes its own post, with timings. Until then, treat this one as an inventory rather than a recommendation.

The routine, as it currently stands

Written down so it stops living in my head, in the order things actually happen:

• Before any change that touches more than one page at once — a mass edit, a theme change, a plugin removal — pull a fresh content export and check the file count against what the site says it has. Five minutes, and the only step here I have never skipped.
• Before deleting anything from the server, download it first, even when it is obviously dead. The old static export proves that “obviously dead” and “still serving 200 to Google” are compatible states.
• Know which tier you are on, because weekly and daily are not the same promise and the pricing page tells you which one you bought.
• Keep one copy outside the hosting account. Mine is a folder on a machine that has nothing to do with the host. Unglamorous, and the single property that survives an account problem.
• Write down what your copy does not contain. Mine is missing drafts, media, settings and the database, and I would rather have that sentence in a file than discover it during a restore.
• Test a restore. Still outstanding. Marked as such on purpose.

That is a routine assembled by someone who has been lucky rather than careful, which is most of us. The useful part was not buying a tool. It was spending an hour opening my own backup and counting, and finding that two of the four things I thought it held were not in there at all.