Performance Glossary
Backups: Measure the Restore, Not the Schedule
You have daily backups running and no idea how long a full restore takes or how much data the gap between copies would cost you.
The short answer
A backup is a copy of your files and database that can actually be restored — and the only measurement that matters is how long that restore takes and how current the recovered site is when it finishes.
Schedules and retention are inputs. Recovery time and the size of the gap between copies are the outputs, and they are the two numbers worth writing down somewhere you will find them under pressure.
By the HostingFast team · Reviewed 12 August 2026
100+
Terms, measured not asserted
2 min
To read one entry
Plain
Commands you can run
24/7
Engineers on shift
The adjectives do the work. Automatic, so remembering is not part of the process. Offsite, so the copy outlives the machine it protects. Tested, because someone has restored one for real. Deep, because retention has to reach past a compromise that sat quietly for a fortnight.
Daily automatic backups come with every plan and restore from the panel without a ticket. Careful operators keep a second copy somewhere entirely unrelated, for the category of day where the pessimism turns out to have been justified.
The two numbers worth knowing
Recovery time is how long from deciding to restore until the site serves correct pages again. Data loss window is how much work disappears — with daily copies, up to a day. Both are properties of your setup, and you can only learn them by running a restore and timing it.
Write both figures down. When something goes wrong, the question is always 'how long and how much', and the difference between answering it in seconds and guessing is an afternoon of avoidable panic.
Retention has to outlast a quiet compromise
Seven days of history is fine for a fat-fingered delete you notice immediately. It is useless against injected code that arrived three weeks ago, because every copy you hold already contains it. Depth is what covers the failures you find late.
That is the argument for keeping a periodic copy of your own alongside the platform's dailies — monthly is enough — so there is always a version predating anything you might later discover.
What the copy does not include
Check whether your backup covers both halves of the site: files and database. A files-only archive restores a theme with no content, and a database-only dump restores content with nothing to render it. Our panel backups take both together, which removes that particular failure.
Also consider what lives outside the account entirely — DNS records, mail routing, third-party integrations, API keys. None of that is in a hosting backup, and a restore that gets the site back while mail routes to the old server is only half a recovery.
Rehearsing on a clone
Restore into staging rather than over live. You get the timing, you get to check that content is current, uploads resolve and logins work, and you get all of it without touching the site that is still serving. Twenty minutes once a quarter is the whole exercise.
The finding is usually mundane and always worth having: a retention window shorter than you assumed, a restore slower than you expected, or a database that turned out to be excluded. Better on a Tuesday afternoon than at the worst possible moment.
Recovery, expressed as numbers
These entries convert reassuring words into figures you can quote: how long, how much, how far back. Anything else is a policy nobody has tested.
Daily backups cover files and databases together and restore from your own panel, on the same NVMe storage the live site runs on.
- Recovery time actually measured
- Retention judged against late discovery
- Coverage checked, both halves
- Rehearsal on staging, quarterly
Why HostingFast
Standard on every plan
Two numbers instead of a policy
Recovery time and data loss window, both established by running a restore rather than by reading a feature list.
Retention matched to the threat
Why a week of history covers a mistake and does nothing at all about a compromise found late.
Coverage audited
Confirming both files and database are in the copy, and noticing what lives outside the account entirely.
Rehearsal on a safe target
Restoring into staging so the timing is real and the live site never notices the exercise.
The findings are usually boring
Which is the point: mundane discoveries on a Tuesday beat urgent ones at three in the morning.
Self-service by default
Restores you run yourself from the panel, so recovery time is not gated on a queue.
Quick Start
From order to online
- 1
Restore into staging and time it
Start a clock when you begin and stop it when the clone serves correct pages. That figure is your real recovery time.
- 2
Check three things on the result
Content freshness, whether uploads resolve, and whether a login works. Any one of the three failing means the copy is incomplete.
- 3
Keep one copy older than a month
Platform dailies plus a periodic archive of your own covers the compromise you discover weeks after it arrived.
Built In
Loaded onto every plan
- Daily backups with a self-service restore you run yourself from the panel
- Staging you can clone, break and throw away before anything reaches live
- NVMe on every tier — the entry plan runs the same drives as the top one
- SSH, Git and Composer on the developer-focused plans
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- 99.9% uptime as the target, monitored around the clock
- A human on support at any hour, including for the awkward questions
- In-place upgrades between plans — no migration when you outgrow one
- Free SSL on every plan, reissued automatically well before it can expire
- Renewal billed at your signup rate — no year-two step change
Frequently Asked
What people ask us most often
How many copies do I actually need, and where?
The platform's daily copies plus a periodic archive of your own somewhere off our network. About a month of depth covers a compromise you discover late. A single copy sitting on the same server as the site protects you against almost nothing worth protecting against.
How do I know a backup will restore before I need it to?
Restore one into staging and look at the result. Twenty minutes a quarter buys you a real recovery time, a confirmation that both halves of the site are in the copy, and the discovery of any gap while the discovery is still cheap.
Can I run a restore without opening a ticket?
Yes. Every plan takes a daily backup and the restore runs from your own panel — files, databases or both — at whatever hour you discover the problem. Keeping an additional copy somewhere off our network remains good practice, and nothing in the platform stops you doing it.
What is the refund window if this turns out to be the wrong fit?
Thirty days on shared, business, WordPress and WooCommerce hosting; seven on reseller. VPS and dedicated servers are built to order the moment payment clears, so they sit outside the guarantee, as do domain registrations, where the registry charges the instant the name is secured.
Keep reading
Uptime
The share of time the platform answers, and how monitoring proves it.
Database
The queryable half of a site, and why a restore is never files alone.
How to Restore From a Backup
Running a restore from the panel, and rehearsing one before you need it.
Web Hosting
cPanel hosting on NVMe with LiteSpeed, free SSL and a migration included.
Domain Names
Register or transfer a name, with year one included on annual hosting orders.
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.
Know the recovery time before you need it.
Daily backups covering files and databases, restores you run yourself, and staging to rehearse one on this afternoon.
View Web Hosting plans