Recovery Path Questions: What to Ask Before Your Host Fails
Most small teams discover their recovery options during an outage, when there is no time to read documentation or make calm decisions. A quieter approach is to write down, in advance, what recovery would look like for your specific site and what you would need to find out before you could rely on it. This article offers a set of questions and a practical method for working through them. It does not assume any particular provider's capabilities. Instead, it helps you build an honest picture of your own recovery path, which you can then check against whatever your hosting provider has actually stated in writing.
Start With the Outage You Are Actually Worried About
Recovery planning becomes vague when the imagined failure is vague. Before asking any questions of a host, pick two or three concrete scenarios: the site returns errors on every page, the database becomes unavailable after a bad change, a content editor deletes a folder, or the server stops responding for an unknown period. Each scenario points to different recovery needs. A broken deployment calls for a way to return to the previous version. A deleted folder calls for a copy of the files from some earlier point. A server that stops responding calls for knowing who to contact and what the escalation path looks like.
Write each scenario as a single sentence that starts with "If this happens at 9 p.m. on a Friday." The time matters because it reveals whether anyone with the right access is awake, and whether the people who are reachable know the steps. Keep the list short. Three realistic scenarios produce better answers than thirty hypothetical ones.
Questions About Your Own Copies of the Site
Every recovery path depends on having something to recover to. Ask yourself where your site's files, database exports, and configuration live right now, and who created each copy. Many small sites have a single live copy, plus perhaps a developer's local machine that is out of date. Mark each location with the date it was last updated and whether anyone could retrieve it without the person who created it.
Next, ask the host what is stated in its own documentation about copies of your data. Look for plain language about what is retained, for how long, and how you request a restore. If the documentation says nothing on a point, treat it as unknown rather than assuming a default. Write the unknowns down. A question such as "Can I restore a single file from a copy taken before last Tuesday?" is specific enough to get a real answer, and specific enough that a vague answer is easy to recognize.
Keep your own independent copy under your control whenever you can. Exporting the site files and database to a location you manage, on a schedule you choose, does not depend on any provider feature. Test that the copy opens and imports before you need it.
Questions About Who Can Act and How Fast
Recovery is a people problem as much as a technical one. Build a short roster: who holds account credentials, who can approve a restore, who can talk to the host, and who makes the call to roll back. For a team of two or three, these may be the same people, which is fine as long as each role is named. Confirm that at least two people can reach the hosting control panel without going through one individual's personal device or inbox.
Then ask the host how support requests are handled outside business hours, what information they need to act, and what they will and will not do without account verification. Do not accept "we respond quickly" as an answer. Ask instead what the stated response process is, whether it is written down, and whether the stated process has any time commitments. If the provider's terms do not describe a time commitment, record that fact in your runbook so the team does not plan around one.
A Comparison Method for Recovery Expectations
When you evaluate a hosting plan, whether shared hosting, managed WordPress, or a VPS, the recovery picture differs even when the marketing looks similar. On shared hosting, you usually depend more on the provider's environment and its stated restore tools, and you have less direct control over the server itself. On a VPS, you typically gain control and therefore responsibility: the copies, the restore steps, and the rebuild process fall to you unless you have arranged otherwise. Managed WordPress sits between these, but the exact division of duties should be read from the provider's own terms rather than from a general description.
Use the same three columns for each plan you consider: what the provider has stated about copies of your data, what the provider has stated about restore requests, and what you would have to do yourself. Leave a cell empty if the answer is not stated. Empty cells are useful information; they show where you would be guessing during an incident.
Turning Answers Into a Recovery Runbook
Once you have answers, write a runbook that a colleague who has never touched the site could follow. Each step should name the location of the copy, the account needed, the command or control panel path, the expected result, and what to do if the result differs. Test the runbook by having someone who did not write it walk through a restore to a staging environment. Where the test fails, fix the runbook, not the person.
Finally, schedule a review. Hosting plans, provider documentation, and team members change. A runbook that was accurate last year can quietly become wrong. Quarterly is a reasonable starting point for a small site, with an extra review whenever the plan, the provider, or a key person changes. The goal is not a perfect plan but a plan whose gaps you know about, so that during an outage you are following written steps rather than discovering them.