Pick a Host With a Real Recovery Plan (Vetting Checklist)

If your host goes down and their own support tells you they can't reach the server, the problem isn't bad luck — it's that nobody owns the hardware and there's no real recovery plan to move you. Before you sign with any host, ask three plain questions: do they control their own machines, how fast can they spin up a replacement node, and what copy of your site do you keep so you're never fully at their mercy?

This came up again on r/webhosting this week: someone launching that night on IONOS shared hosting hit an outage where support admitted they had no access to the server. On launch day, with money on the line, "we can't get in either" is about the worst sentence you can hear. The good news is you can screen for this in about ten minutes of questions, and you can protect yourself even from a host you already picked.

Here's how to vet a host's recovery plan, and what to hold on your side so a single outage never strands you.

Why "we have no access to the server" happens at all

That sentence usually means the host resells someone else's infrastructure and the outage sits below the layer they control. When a provider rents capacity from a larger platform and repackages it, an incident in the underlying stack leaves their support team doing exactly what you're doing: refreshing a status page and waiting.

Big-brand shared hosting packs a lot of sites onto shared platforms, and support tiers are scripted to keep costs down. The first person you reach often can't touch the actual box — they can open a ticket that climbs toward a team that can. During a wide outage that queue is thousands deep. None of this is malice. It's the predictable result of scale plus outsourced hardware plus support that isn't staffed by people who can log into a hypervisor.

The fix isn't finding a host that never fails. Everyone fails eventually. The fix is finding one where the people answering the phone can actually do something, and keeping enough on your side that you can walk if they can't.

Question one: does the host control its own hardware?

Ask directly whether they own and operate the servers your site runs on, or resell another platform's capacity — the answer changes who can fix things at 2am. A host that runs its own machines in its own racks can reboot a node, migrate a VM, or pull a drive. A reseller can only escalate upstream and wait.

You don't need to be an infrastructure expert to get a straight answer. Try these:

• "Do you own the servers, or do you rent capacity from a larger cloud provider?"
• "If a physical node dies at 2am, who is authorised to touch the hardware — your staff or a third party?"
• "Where are your data centres, and do you operate them or colocate?"

The answers tell you how many hands your emergency has to pass through. At TPC Hosting we run our own hardware in EU data centres, which is the whole reason our engineers can act on a failing node instead of filing a ticket with someone else. That's not a slogan — it's the difference between "we're on it" and "we've reported it."

Question two: how fast can they spin up a replacement node?

The number that matters isn't uptime on a brochure — it's how long it takes to rebuild your site somewhere else when a machine genuinely dies. Ask for that in minutes and hours, with a real example.

Here's what a healthy recovery actually looks like when you play it out. A node hosting your site fails at 3am. The host takes hourly snapshots, so the most recent one is at most 60 minutes old — you lose the last order or two, not the whole day. An engineer (or an automated failover) provisions a fresh node and restores that snapshot; for a small WordPress site that's a few gigabytes, so the restore itself runs in a handful of minutes. DNS already points at the host's edge, so once the data lands you're serving pages again without touching your registrar. Total time your visitors see an error: minutes, not the hours you'd wait for a reseller to escalate. That's the shape of the answer you want — snapshot age, restore time, and who does the work — not a vague promise.

Good hosts can answer this because they've done it. Push past the marketing:

• "How often do you snapshot or back up my account, and how far back do restores go?"
• "If my node fails, do you restore me onto healthy hardware automatically, or do I have to ask?"
• "Walk me through your last real incident — what broke, and how long until sites were back?"

A host that can describe a specific past outage and the recovery timeline is telling you the plan exists and has been used. Vague reassurance ("our systems are highly redundant") with no numbers is a red flag. You want backup frequency, restore window, and whether failover is a person clicking a button or an automatic process. When you move to a new host, TPC includes free migration, and the same engineers who handle that move are the ones on support 24/7 — so the person who can rebuild your site is the person you're already talking to.

Question three: what do you keep on your side?

No matter how good the host is, keep your own current backup and your own control of the domain — those two things mean no single outage can trap you. This is the part you fully control, and it's what turns "I need to leave tonight" from a panic into a two-hour job.

Here's the short list to hold on your side, independent of any host:

• An off-site backup you can download. A full site archive plus a database dump, stored somewhere that isn't the host — your laptop, Backblaze, an S3 bucket. Automate it weekly at minimum, daily if you take orders.
• Your domain registrar, separate from hosting. If the registrar and host are the same company and that company has an outage, you can't even repoint DNS. Keep the domain where you can change nameservers no matter what.
• Low DNS TTL before any planned move. Drop your A-record TTL to 300 seconds a day ahead. When you cut over, the internet follows within minutes instead of hours.
• Credentials written down. Registrar login, DNS login, database password, SFTP details — in a password manager, not only in your host's control panel.

For WordPress, a plain manual backup is two commands if you have shell access:

• Database: mysqldump -u USER -p DBNAME | gzip > backup.sql.gz — piping through gzip keeps big dumps small; a plain > backup.sql on a large database can balloon and quietly fill your disk.
• Files: tar -czf site.tar.gz /path/to/public_html

Then actually test the restore before you need it — load the dump into a throwaway database with gunzip < backup.sql.gz | mysql -u USER -p TESTDB and confirm the tables are all there. A backup you've never restored is a guess, not a safety net. Download both files. That single archive is your entire site. With it and access to your registrar, you can be live on new hosting the same evening — which is exactly the situation that Reddit poster was stuck in without one.

A ten-minute pre-signup checklist

Run this list before you pay anyone, and re-run it on your current host to find your gaps. It maps to the three questions above.

One more thing worth doing: open a support ticket before you commit, with a mildly technical question, and time the reply. How a host answers a calm question tells you a lot about how they'll answer a panicked one. TPC Hosting gives you 30 days to back out, which is enough runway to actually run this test on a live migration rather than trusting a landing page.

What to do tonight if you're the one stranded

If your host is down right now and can't help, don't wait for them — pull whatever you can and stand the site up elsewhere in parallel. Recovery beats waiting. Work through these steps in order:

• 1. Grab your latest off-site backup. If you don't have one and the control panel or SFTP is still reachable at all, download the files and run a database dump right now before the box goes fully dark.
• 2. Note your MX records. If you host email with the same provider, write down your MX entries before you change anything so mail keeps flowing after the move.
• 3. Sign up somewhere that can migrate you fast. Pick a host whose own engineers do the move, so you're not learning a new panel at 2am.
• 4. Drop your DNS TTL. Set the A record to 300 seconds so the cutover propagates in minutes.
• 5. Restore and verify on the new host. Load your backup, then hit the site by its temporary IP or hostname to confirm it works before you touch DNS.
• 6. Repoint the domain. Update the A record (and MX, if needed) once the copy is confirmed live.

Once you're stable, do the vetting above so the next host is a deliberate choice and not a 2am scramble. The lesson from this week isn't "IONOS bad." It's that a host you can't reach and a site you can't move is a single point of failure you built yourself. Fix both, and outages become an inconvenience instead of an emergency.

FAQ