Cloudways backup and restore test

Backups are the part of hosting everyone says they believe in and almost nobody tests. The gap is easy to explain: backup schedules run on their own, while a restore test takes an hour of deliberate work on a day when nothing is wrong. That is why it gets skipped, and it is also why it matters. The day you need a restore is the worst possible day to learn what the backup contains.

What a restore test proves

A scheduled backup, running green in the panel, is a claim. It claims the whole site came along, that the copy is intact, and that bringing it back works. Only a restore checks any of that, and it checks all three at once, plus a fourth thing nobody thinks about until the test: that you know how to drive the restore process at all. Interfaces that feel obvious in a calm hour feel unfamiliar during an incident. Spend the calm hour.

Scope is the other thing a test reveals. What a backup covers is a settings decision made once, on a busy day, and never revisited: application files, database, or both. The restore puts the question in the open, because you can see exactly what came back and what did not, instead of trusting a schedule name to mean what you assumed.

The safe method: restore onto a clone

Never run a restore test against the live site. The safe target is a clone, and the panel's cloning makes that cheap: clone the application, then run the restore on the clone. Live traffic never knows the test happened.

The method, as I run it.

Clone the live application, to staging or to a new application on the same server. The clone is expendable by design.

On the clone, change something visible. Publish a test post, upload a marker image, change the site tagline. This matters more than it first appears: without a deliberate difference between the clone and the backup point, you cannot tell a successful restore from a clone that simply still looks like the live site.

Pick the backup point and run the restore on the clone from the panel. Restores are a one-click operation, automated and on-demand backups alike, and offsite storage bills at $0.033 per GB per server as of October 2026, so the raw materials of this test cost roughly nothing.

Then check the clone the way a visitor would.

What to check after the restore

The admin loads and works: dashboard, plugins page, one edit screen. Content matches the backup point, meaning the posts that existed then are there and your deliberate changes from earlier are gone. The media library opens and recent uploads display full size. Forms submit and their notifications arrive, because form plugins store settings in the database and attachments on disk, and a restore that brought back one half may leave the other half behind. The front page and a couple of interior pages render. If the site sells anything, load a product page and the cart.

A pass gives you a backup you can defend to a client. A failure gives you the same knowledge on a day of your choosing, which is the entire value of the exercise.

How often to run one

Two triggers, whichever comes first. Calendar: I run one on a fixed rhythm, twice a year as the floor and more often on sites that change weekly. Events: any structural change to the site reruns the test. A new ecommerce plugin that stores data outside the standard tables, a changed backup schedule, a migration, a pile of new upload types. Structural changes alter what a backup needs to cover even when the backup settings themselves are untouched. Put the first test in the calendar this week, while the intention is fresh. The second one is easier once the first exists.

Making it part of normal operations

Anyone running several sites needs this to be boring, and boring means scheduled. The restore test sits on my maintenance calendar alongside plugin updates and the monthly bill, in the same place, so it competes for attention with real work instead of hiding behind good intentions. On Cloudways the pieces are all there: staging and cloning included in every plan as of October 2026, automated offsite backups, one-click restore. Scheduling the first test is the part the panel cannot do for you.

The wider routine this fits into is in how we host multiple production sites, and what the platform's backups cost at scale is covered in the Cloudways review.