Incident runbook · Beginner · 10–30 min
Restoring a Backup: Scope It, Time It, Verify It
A restore is a scoped operation with a clock on it — files, database or both, from the newest copy that predates the fault rather than the newest copy you have.
The short answer
Restore the narrowest scope that fixes the fault — files if the layout or an asset broke, the database if content or settings vanished, both only if you have genuinely lost everything — and take it from the newest copy that predates the problem, not the newest copy in the list.
The two steps people skip are the ones that decide whether the restore holds: purging every cache layer afterwards, and verifying with evidence rather than a glance at the homepage. A restored database sitting behind a warm page cache and a stale object cache will look exactly like a restore that did not work.
By the HostingFast team · Reviewed 12 August 2026
Beginner
Assumed level
5
Stages to verified
Free
Support cost
Proven
Proven on our platform
Ten to thirty minutes, depending on scope. Every plan here carries a daily backup, Nitro takes one every six hours, and the restore itself runs from your panel without a support ticket in the way.
The verification commands below assume WP-CLI over SSH, which ships on every shared tier. If the application is not WordPress, the same principle applies with whatever integrity check it offers.
Scope the restore from the symptom
Broken layout, missing images, a white screen after a file edit: that is files. Content that has disappeared, settings that reverted, an option someone changed: that is the database. A defacement or a wiped account is both. Restoring more than broke is not caution, it is data loss — a full restore to yesterday takes today's orders, comments and form entries with it.
Write down what you expect to change before you start. If you cannot say which half is damaged, spend five more minutes diagnosing; the answer is usually visible in the error log or in a file listing sorted by modification time.
Choosing the restore point is arithmetic, not instinct
Find when the fault started, then take the copy before it. For a bad deploy that is obvious. For a slow-burn problem such as a compromise it is not, and the newest backup will carry the problem with it. Over SSH, find . -type f -name '*.php' -newermt '-7 days' lists what changed in the last week, and the raw access log will usually show the first anomalous request.
Know your intervals before you need them. Daily backups run on every plan and the restore is yours to trigger from the panel; Nitro takes a copy every six hours, which narrows the worst case considerably. That interval is your recovery point objective whether or not you have ever called it that.
What a restore does to your caches
The restore replaces files and rows. It does not touch the LiteSpeed page cache, an object cache, or anything held at a CDN edge. So the sequence matters: restore, then purge LiteSpeed, then flush the object cache, then purge the CDN, then test. Do it in the other order and you will be inspecting a cached copy of the broken site and concluding that the restore failed.
Expect some collateral: logged-in sessions may be invalidated if the restore rolls back session or user rows, and any transient or scheduled task stored in the database goes back with it. Neither is a problem, but both are worth knowing before somebody reports it as one.
Verify with evidence, then fix the cause
Confirm three things: the fault is gone, nothing healthy was removed, and the application's integrity is intact. On WordPress that is wp core verify-checksums for the files, a row count on your busiest tables before and after, and a load of three different templates — homepage, a content page, and whatever your transactional path is. Then take a TTFB reading and compare it with your baseline, because a restore that leaves the site slow has left something behind.
Finally, the part that is not a restore at all: the plugin, the credential or the human slip that caused the fault is still in place. A restore rewinds the symptom and schedules the repeat.
The recovery tooling on our own platform
Every restore described here runs from the cPanel account you would be given: pick the scope, pick the date, trigger it yourself. No ticket, no queue, and it works just as well at three in the morning as at three in the afternoon.
Backups run daily on every plan, and restoring a file or a database is a single click in the panel rather than a support request.
- Restore scoping decided by symptom, not by habit
- The command that dates the fault, printed in full
- Cache purge order spelled out, in sequence
- Engineers on call at every hour, including the small ones
Why HostingFast
Standard on every plan
Narrow scope by default
Files or database, chosen from the symptom, so a fix for one half never overwrites the healthy other half.
A dated restore point
The find command and the log query that place the fault in time, so the copy you pick is genuinely clean.
Cache order, in order
Restore, LiteSpeed purge, object cache flush, CDN purge, then test — the sequence that stops you debugging a stale copy.
Verification you can show someone
Checksums, row counts and a TTFB reading beat clicking the homepage and feeling relieved.
Intervals stated plainly
Daily backups on every plan and every six hours on Nitro, which is your recovery point objective in plain numbers.
Root cause kept on the list
The guide ends by pointing at the plugin or credential that caused it, because the restore did not fix that.
Quick Start
From order to online
- 1
Freeze writes before you overwrite anything
Put the site into maintenance mode. Restoring a database while customers are still submitting into it means losing whatever landed during the restore, and you will not have a record of what that was.
- 2
Date the fault, then pick the copy behind it
find . -type f -name '*.php' -newermt '-7 days' over SSH, plus the first odd entry in the access log. Choose the newest backup that predates both, which for a compromise may be several days back.
- 3
Restore the narrow scope from the panel
Files, database or both, and the date. It runs in minutes, under your control, with no ticket in the queue. Nitro accounts get a copy every six hours to choose from; every other plan gets a daily one.
- 4
Purge the layers in sequence
LiteSpeed cache, then the object cache, then the CDN if you run one. Skip this and the site you are about to test is the one you were trying to replace.
- 5
Verify, then remove the cause
wp core verify-checksums, row counts on the busy tables, three templates loaded, and a TTFB comparison against your baseline. Then patch the plugin or rotate the credential that made the restore necessary.
Built In
Loaded onto every plan
- Daily backups on every plan, with self-service restores from the panel
- Backups every six hours on the Nitro tier
- Restore scope you choose: files, databases, or both
- Full SSH access with Git and Composer for WP-CLI and integrity checks
- LiteSpeed caching in the server, with a purge control you own
- NVMe SSD storage on every tier, so restores complete in minutes
- Staging environments for testing a change before it reaches visitors
- Free migration by our engineers if the site currently lives elsewhere
- Money-back cover: 30 days on hosting plans, 7 on reseller
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Will a restore roll back orders and form entries taken since the backup?
A database restore will, which is exactly why scope matters. If the damage is to files, restore files only and the database keeps every order taken since. If you genuinely must roll the database back, export the affected tables first — orders, form entries, comments — so you can reconcile afterwards rather than discover the gap from a customer.
Do I need to purge the cache after restoring the database?
Yes, and in order: LiteSpeed page cache, then any object cache, then the CDN. The restore rewrites rows and files; it does not know that a cached HTML page or a cached query result exists. Most reports of the restore did not work are a cached copy being served, and a purge resolves them in seconds.
How far back can I restore, and how often is a copy taken?
Every plan takes a daily backup that you can restore yourself from the panel, and the Nitro tier takes one every six hours. That interval is your recovery point objective: the most work you can lose is one interval. If your site changes faster than that, keep your own additional copy — a cron job that dumps the database somewhere offsite costs nothing and nothing here prevents it.
How do I prove the restore actually worked?
Three checks. wp core verify-checksums confirms the application files match upstream. A row count on your busiest tables, compared with what you expected, confirms the database landed where you meant. Loading three different templates — not just the homepage — confirms the site is functional. Add a TTFB reading against your baseline and you also know nothing slow was left behind.
Keep reading
How to Free Up Mailbox Storage
Find what is actually filling the mailbox, then reclaim it without losing mail.
How to Create a Professional Email Signature
A signature that renders the same everywhere and does not weigh anything.
Backup (Glossary)
What a backup covers, what it does not, and how often a copy is taken here.
Ecommerce Hosting
A store on NVMe behind a LiteSpeed cache, with the checkout path kept uncached.
Domain Names
Registration, renewal and delegation, with your first year free on annual plans.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Hosting where the rollback is yours to run.
Daily backups on every plan, six-hourly on Nitro, self-service restores from the panel, and engineers on the desk at any hour you need one.
View Ecommerce Hosting plans