Recovery targets · Intermediate · an hour, restore timed
How to schedule server backups — Two Numbers Decide Everything: How Much You Lose, and How Long You Are Down
You have a cron job writing archives somewhere and no idea how much work a failure would cost you or how many minutes the site would be down.
The short answer
Decide two numbers before you write a single cron line. Recovery point is how much work you are willing to lose — that sets your backup frequency. Recovery time is how long the site may be down while you get it back — that sets where the copies live and how they are packaged. Every other decision on this page is derived from those two figures.
Then make the copies actually restorable: a database dump taken with --single-transaction so it is consistent without locking the tables, a file archive from the same moment, at least one copy off the machine, a retention ladder rather than one rolling overwrite, and a restore you have performed and timed rather than one you assume would work.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Skill floor
an hour
Hands-on time
5
Numbered stages
24/7
Support cover
An hour of setup for something you hope never matters. Assumed: cron, a shell, and somewhere off this machine to push to. The part most setups skip is the last one, which is the only part that produces evidence.
The deliverable is a figure you can quote: the number of minutes a full restore takes on this stack. Until a restore has actually succeeded, what you have is a directory of files you are hoping will turn out to be useful.
Set the two numbers, then derive everything else
A brochure site that changes monthly tolerates a nightly copy comfortably; a store taking orders every hour does not, and its recovery point has to be measured in hours or minutes rather than days. Write the figure down, because it is the only honest way to choose a frequency and it is also what you are implicitly promising everyone who depends on the site.
Recovery time is the other half and it is the one people never measure. It includes finding the archive, transferring it, importing the database, fixing file ownership and checking the site actually renders. Guessing at it is how a two-hour outage turns into a six-hour one.
Dumps that are consistent, archives that match
mysqldump --single-transaction takes the dump inside a transaction, so InnoDB tables come out consistent without locking writes for the duration. Without it, a busy database can produce an archive where one table reflects an order and another does not, which is a file that restores and a site that does not add up.
Take the file archive at the same moment. A file tree from midnight paired with a database from six in the morning restores a site whose uploads do not match its posts, and that mismatch is far harder to diagnose than a straightforward missing file. Snapshot them as a pair and name them by the same timestamp.
Off the box, and more than one generation
A backup living on the machine it protects shares a failure domain with the thing it is insuring. Push to object storage or a second host, and check the transfer succeeded rather than only that the archive was created — a full disk produces a truncated file and a happy exit code more often than anyone expects.
Keep a ladder, not a single rolling copy. Corruption and quiet defacement are frequently noticed days later, and one overwritten archive will have faithfully replaced the good version with the broken one. Several dailies, a few weeklies and a monthly is enough to recover from a problem you spot in week three.
Make the script report, then time a real restore
A cron job that fails silently is worse than no cron job, because you believe you are covered. Have the script check its own exit codes and the resulting file size, then send a short message on success and a loud one on failure. A backup that stopped six weeks ago should be discovered then and not on the morning you need it.
Then restore one on purpose, into a disposable environment, with a stopwatch running. That is your recovery time, and it is usually longer than the guess. Our platform already runs a daily backup on every plan with restores you run yourself from the panel, so this whole exercise sits on top of a floor that already exists rather than replacing it.
The floor your own backups sit on
Daily backups run on every plan and restore from the panel — files, databases or both — without a support ticket in the way. That is your baseline recovery time; everything you build on top exists either to shorten it or to survive the platform itself being unavailable.
Order an annual plan and the first year of your domain registration costs you nothing.
- Daily backups on every plan, with self-service restores
- Staging environments to run the restore drill on
- SSH and cron on the developer-focused plans
- Engineers on shift at whatever hour you need a hand restoring
Why HostingFast
Standard on every plan
Two numbers up front
Recovery point and recovery time are decided first, and every schedule, location and format choice follows from them.
Consistent by construction
--single-transaction for the dump and a matching file archive, so a restore adds up instead of half-agreeing with itself.
A failure domain apart
At least one copy off the machine, with the transfer verified rather than assumed from a happy exit code.
A retention ladder
Several dailies, a few weeklies, a monthly — because the problem you notice in week three needs a copy from week two.
Scripts that speak up
Exit codes and file sizes checked, a quiet message on success and a loud one on failure, so a stopped job is noticed the same week.
A timed restore
You end with a figure in minutes for a full recovery, which is the only version of this that is worth anything.
Quick Start
From order to online
- 1
Write down the recovery point and recovery time
How much work you can afford to lose, and how long you can be down. Frequency, storage location and packaging all follow from these two figures.
- 2
Dump the database consistently
mysqldump --single-transaction so InnoDB tables come out coherent without locking writes, and name the output by date so it pairs with the file archive.
- 3
Archive the files at the same moment
A file tree and a database from different hours restore a site whose uploads and posts disagree. Take them as a pair, timestamped identically.
- 4
Push a copy off the machine
Object storage or a second host, with the transfer result checked — a full disk yields a truncated file and a successful exit code more often than you would like.
- 5
Alert on failure, then time a restore
Report exit codes and file sizes, loudly on failure. Then rebuild the site somewhere disposable with a stopwatch running: that number is your real recovery time.
Built In
Loaded onto every plan
- Daily backups on every plan, with restores you run yourself from the panel
- Staging environments for rehearsing a change before it ships
- SSH, Git and Composer on the developer-focused plans
- NVMe SSD storage on every tier, including the entry plan
- Per-site PHP version switching from the control panel
- cPanel — the control panel most of the industry already runs
- Year one of your domain free when you order annually
- 99.9% uptime as the target, monitored around the clock
- Your existing site moved across by our engineers, free of charge
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Which mysqldump flags give a consistent dump without locking the site?
--single-transaction is the important one on InnoDB: it takes the dump inside a transaction so the output is coherent while writes carry on. Add --quick for large tables so rows stream rather than buffering in memory, and --routines if you have stored procedures. Without the transaction flag, a busy database can produce an archive whose tables disagree with each other.
How do I know a backup file is not truncated?
Check the exit code and the resulting file size in the script, and compare that size against the previous run — a sudden drop is the signal. Better still, periodically decompress and import it somewhere disposable. A full disk very reliably produces a partial archive alongside a perfectly cheerful exit code, which is why size alone is worth logging every night.
What should the cron job do when a backup fails?
Tell you, loudly and by a channel you read. A silent failure is worse than no backup at all because you believe you are covered. Send a short confirmation on success too — an absent message is ambiguous, whereas a missing daily 'backup ok' at the usual time is something you will notice within a day or two.
How long does restoring the platform's daily backup take?
It is a self-service restore from the panel — files, databases or both — so there is no ticket queue in the middle of it, and the actual duration depends on how much data you are restoring. Time it once on a staging clone so the figure is known rather than estimated, exactly as you would with your own archives.
Keep reading
How to Migrate a WordPress Site
Move a WordPress site to new hosting with no visitor catching a gap, and the TTFB measured on both sides — intermediate, roughly 1–2 hours, or a free ticket to us.
How to Set Up Email in Outlook
Get a domain mailbox working properly in desktop Outlook, with the right ports and no send failures — beginner, roughly 10 minutes.
Best Hosting With Daily Backups
The same decision as a buying guide: what a daily backup is actually worth, and the plan we would sign.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and one flat monthly price.
PHP Hosting
Choose your PHP version per site, on fast NVMe hardware.
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.
Start with a daily backup already running.
Daily backups with self-service restores, staging clones to drill on, SSH and cron on developer plans, and year one of the domain free on annual orders.
View VPS Hosting plans