What does this service cover?
Most backup disasters are discovered at the worst moment: the “backup” contains files but no database, or a database but no uploads folder, or everything — stored on the same server that just failed. A backup is a recovery plan, not a zip file, and it only counts once a restore has been proven to work.
This service treats backup and restore as one discipline. Before risky work I create a focused, complete backup; existing packages get sanity-checked for completeness; and restores are performed deliberately — to the same environment or a replacement host — with URL and path adjustments and real post-restore testing, not just an extraction log.
What is the typical scope?
Every engagement starts from the same place: a clear, agreed list of what is included before any work begins.
- Complete file and database backup
- Backup package sanity checks
- Restore to same or new hosting
- Post-restore testing and handover
The exact scope is confirmed from the real site and problem before changes are made.
How does the work proceed?
- Assess what exists: check whether a backup exists, what it contains — database, uploads, wp-content — and whether the target server can run the site.
- Create or verify the package: build a complete backup or sanity-check the existing one before it is needed.
- Restore deliberately: restore to the same or a replacement environment, with URL and path adjustments where required.
- Test the recovery: verify key pages, login, forms and functionality — a restore is not done until the site works.
What you need to provide
Most of the technical work is on my side. To start, I usually need:
- Hosting access for the source, the destination, or both
- Any existing backup files and where they are stored
- The domain situation — same domain, new domain or temporary URL
- What happened, if this is a recovery (failed update, hack, host loss)
Typical timelines
Backup creation and verification take 1–2 days. Restores take 1–3 days once a usable package and a suitable target environment are confirmed. Recovery from incomplete backups takes longer and is scoped honestly.
Frequently asked questions
My host says they keep backups — do I still need this?
Host backups are better than nothing, but they are often incomplete, short-retention, or unrestorable without the host's help. I verify a backup is actually complete and restorable.
What is usually missing from a bad backup?
The uploads folder, the database, or both. A “files only” or “database only” backup cannot rebuild a working site — I check for completeness before you need it.
Can you restore my site to a different host?
Yes — that is a standard case. URL and path adjustments are handled, and the target server is checked for compatibility first.
My backup is corrupted. Can you still help?
Sometimes partial recovery is possible. I will assess what is salvageable and tell you honestly whether it is a recovery job or a rebuild job — they are priced differently.
How often should backups run?
It depends on how often the site changes. Brochure sites: weekly. Active blogs or stores: daily, with off-site copies. I set the schedule to match the risk.
Where should backups be stored?
Off the server being backed up — cloud storage or a separate account. A backup on the same server it protects is not a backup.
What this service is not.
Forensic incident response and guaranteed recovery from incomplete or corrupted backups require a different specialist scope.
The first step is diagnosis and a proportionate scope. If the issue is broader than it initially appears, that is identified before expanding the work.
At completion, you get a concise explanation of the work performed, the checks completed and any follow-up item that remains outside the agreed scope.
Start with a clear scope
Describe your website and what needs to happen. You will receive a fixed scope, price and timeline before any work starts — no passwords needed at the enquiry stage.