Website backups you can actually restore.
Two things catch people out, and both look identical to a working backup until the day you need one: a schedule that quietly stopped months ago, and an archive that does not restore.
Two things catch people out, and both look identical to a working backup until the day you need one: a schedule that quietly stopped months ago, and an archive that does not restore.
Backups are the easiest thing in hosting to appear to do. A schedule is configured once, everybody relaxes, and nobody looks again. The failure modes are silent by nature: a plugin that stopped running after an update, a storage account that filled, a credential that expired. Nothing announces any of it.
The second failure is worse because it only appears at the moment of maximum stress. An archive exists, it is the right size, and it does not restore — a truncated database dump, a missing uploads directory, a file somebody will have to explain.
So the useful question is not whether you have backups. It is when somebody last confirmed the job ran, and when anybody last restored one.
What we do
Working UK-wide and internationally — directly with businesses, and white label behind design and marketing agencies.
Discuss a projectOff-site, so losing the machine does not lose the backups with it. A backup on the same server protects you from mistakes, not from losing the account.
The platform checks a backup job exists and that it ran, and reports when it did not. A schedule that silently stops is the commonest failure there is.
We restore from real archives rather than assuming they work. A backup nobody has restored is an assumption.
Daily, kept for fourteen days. Longer retention is available by arrangement where you need it.
Both, consistent with each other. A database from Tuesday and files from Thursday is not a restore point.
Taken before scheduled changes, so a bad update is reversed rather than debugged live.
Fourteen days is fourteen days. If something goes wrong and nobody notices for a month, the clean copy has rolled off. Tell us if you need longer.
They let you go back to a point in time. They do not tell you what changed or why, which is a different tool for a different problem.
A restore is not instant, particularly on a large site. Knowing roughly how long yours takes is worth establishing before you need the answer.
A lot of our work is delivered white label or under agreement, so these describe the problem and the approach rather than naming the client.
Ten brand websites across one instruments group. Several we built, the rest we inherited — and all ten are hosted, maintained and supported by the same team.
Migration · DevelopmentFive separate legacy CMS sites, five databases and five themes, consolidated into a single multilingual multisite CMS platform.
Preventive WordPress security: filtering before the CMS loads, site isolation, patching and scanning — and an honest account of what it cannot promise.
Monitoring that checks real pages rather than just the home page, and alerts the people who can fix it rather than only telling you.
Ongoing support and maintenance for WooCommerce shops: checkout kept working, updates tested before they go live, and someone who can read the code.
If the answer is never, that is worth knowing now rather than later. Send us the site and we will tell you what the backup position actually is.