If your site is down right now and you’re searching for how to recover a website after server crash, take a breath. Most server crashes are recoverable within hours if you act methodically. Most extended outages (24+ hours) happen because someone panics, makes things worse, or tries to restore without verifying what they’re restoring to.
This is an emergency 8-step playbook. Read it once before doing anything. Then work through it in order. It assumes you have basic admin access (hosting panel, DNS, possibly WordPress admin) but no deep DevOps expertise.
Step 1: Confirm What’s Actually Down
Before touching anything, verify what’s broken. The panic instinct is “restore everything immediately.” That often makes things worse.
Check from outside your own network:
- Site status: open the site in your phone’s mobile data, or use
downforeveryoneorjustme.com - Server status: check your hosting provider’s status page (Hetzner, AWS, IONOS all publish status)
- DNS resolution:
dig yourdomain.defrom a terminal, ordnschecker.org - SSL certificate: is it expired? Visit via HTTPS and check the browser warning
- WordPress admin: can you reach
/wp-admin/?
What you find determines the next step. Don’t restore a backup if the actual problem is an expired SSL certificate.
Step 2: Identify Failure Category
Server crashes fall into five categories. Each needs a different response.
Category A: Hosting Provider Outage
Your provider’s status page shows the issue. You can’t fix it; you can only wait or fail over to a backup environment.
Action: monitor provider status, communicate with customers via status page or Twitter, do not panic-migrate.
Category B: Server Restarted / Service Crashed
Your VPS rebooted; nginx or PHP-FPM didn’t auto-restart. Common after host-side maintenance.
Action: SSH in (or use hosting console) and restart services. systemctl restart nginx php-fpm mysql. Usually back in 60 seconds.
Category C: Disk Full
The server is up but unable to write. Common cause: log files, uploads, or database growth ran out of space.
Action: clear log files (/var/log/), oldest backups, or temp files. Then increase disk size.
Category D: Database Corruption
Site loads but throws DB errors. Could be ungraceful shutdown, hardware issue, or accidental schema change.
Action: stop writes immediately. Snapshot current DB. Restore from last good backup. Do not keep operating in a corrupted state.
Category E: Hacked / Compromised
Site shows defacement, malware warnings, or unexpected redirects. This is the worst category — and requires GDPR breach assessment.
Action: take site offline immediately. Don’t try to “clean” while serving traffic. Investigate, restore from clean backup, harden, notify Datenschutz if personal data may be exposed.
Step 3: Take Snapshots Before You Restore Anything
Most critical mistake during recovery: overwriting evidence.
Before restoring:
- Take a current-state snapshot of the server (most hosts offer this in their panel)
- Download a copy of the database as-is (even if corrupted — it may have data not in your latest backup)
- Download a copy of
/wp-content/uploads/and any user-generated content - Note the exact error messages and timestamps
This snapshot is your safety net if the restore introduces new problems. Don’t skip this step.
Step 4: Restore From the Right Backup
The backup hierarchy that should exist for any serious WordPress site:
| Backup type | Frequency | Where stored | Restore time |
|---|---|---|---|
| Database | Hourly or daily | Offsite (S3, Hetzner Storage Box) | 5–30 min |
| Full site (files + DB) | Daily | Offsite | 30 min – 2 hrs |
| Server snapshot | Daily or before changes | Hosting provider | 5–30 min |
| Disaster recovery (3-2-1) | Weekly | Geographically separate | Several hours |
Restore the most recent backup that you know was clean. For Category E (hacked), restore from a backup taken before the compromise — sometimes weeks back.
WordPress restore options:
- UpdraftPlus (free + paid)
- BackupBuddy / Solid Backups
- Duplicator
- ManageWP (free version available)
- Hosting-provided backups (Plesk, cPanel, Hetzner Cloud snapshots)
Step 5: Verify the Restore Before Going Live
Don’t put a restored site directly back online. Verify first:
- Database queries return expected rows
- File permissions are correct (
644for files,755for directories) - WordPress admin loads without errors
- Frontend pages render
- Forms submit and emails arrive
- Plugin licences still active
- Cron jobs are running
For Category E (compromised), additionally:
- Run malware scan (Wordfence, Sucuri, MalCare)
- Compare file checksums against known-good versions
- Audit user accounts for unfamiliar admins
- Rotate all passwords and API keys
Step 6: Handle DNS Carefully
If you’re moving to a new server, DNS is the last step, not the first.
- Verify the new server fully before pointing DNS
- Lower DNS TTL to 300 seconds in advance if you can (gives faster propagation later)
- Use
digordnschecker.orgto verify the change propagates globally - Keep the old server running until DNS fully propagates (24–48 hours worst case)
Common mistake: panic-changing DNS to a server that isn’t fully ready. Now you have two broken environments and an angry customer base.
Step 7: GDPR Breach Notification (Category E Only)
If your site was hacked and personal data may have been accessed, you have a 72-hour notification clock under GDPR Article 33.
Steps:
- Document the breach (what happened, when, what data, how many people)
- Notify your data protection officer (Datenschutzbeauftragter) if you have one
- Notify the relevant German Landesdatenschutzbeauftragte (state DPA) within 72 hours
- Notify affected individuals if the risk is high (Article 34)
- Keep written record of the breach and your response (GoBD-aligned)
For Mittelstand operations, this is non-optional. Failing to notify is itself a violation.
Step 8: Post-Mortem and Prevention
After recovery, do a written post-mortem:
- What was the root cause?
- What signals could have warned us earlier?
- What’s our updated backup strategy?
- What’s our updated monitoring?
- Who has the runbook for next time?
Add to the runbook so the next incident is handled in 30 minutes, not 8 hours.
The 3-2-1 Backup Rule (Memorise This)
3 copies of your data. 2 different storage media. 1 offsite (geographically separate from your primary server).
For a typical German SME WordPress site:
- Copy 1: Live database + files on production server
- Copy 2: Hosting-provider daily backups (Hetzner snapshots or equivalent)
- Copy 3: Offsite backup to Hetzner Storage Box, AWS S3 Frankfurt, or BackBlaze EU
Any backup strategy without a true offsite copy will fail you the day your hosting provider has a regional outage.
What German SMEs Should Have In Place Before a Crash
Five things to set up now if you haven’t:
- Automated daily offsite backups (UpdraftPlus → Hetzner Storage Box or S3 Frankfurt)
- Monthly restore test — actually restore a backup to a staging environment to verify
- Uptime monitoring (UptimeRobot, Pingdom — alerts within 1–5 min of downtime)
- Server-level monitoring (disk space, memory, CPU)
- Written runbook with who-to-call, login credentials location, GDPR breach steps
Hosting Providers in Germany With Strong Recovery Support
For DACH-based SMEs, providers with reliable infrastructure and good support:
- Hetzner Cloud — German, low-cost, ISO 27001-aligned data centres, good support
- IONOS — Established German host, full support tier available
- Mittwald — Managed WordPress specialist, German-language support
- Raidboxes — Premium managed WordPress, German team
- AWS Frankfurt — Enterprise option, full ecosystem but more complex
For broader hosting discussion in DACH, see our best web hosting Germany for business services overview.
Realistic Recovery Time Expectations
If your site goes down today, realistic recovery times by category:
| Category | Time to recover (with backups) | Time to recover (without) |
|---|---|---|
| A: Provider outage | Provider-dependent | Provider-dependent |
| B: Service crash | 5–60 min | 1–4 hrs (rebuild) |
| C: Disk full | 30 min – 2 hrs | 4–8 hrs |
| D: DB corruption | 1–4 hrs | 4–24 hrs |
| E: Hacked | 4–24 hrs | 1–5 days |
Sites without backups in place when a crash happens face 5–10x longer recoveries. Sometimes the data is unrecoverable.
When to Call for Emergency Help
Most server crashes can be handled in-house if someone on the team is comfortable in a hosting panel + WordPress admin. Call for professional help when:
- The site has been down 4+ hours and you can’t identify the cause
- The crash involves potential GDPR breach (personal data exposure)
- The site is critical for revenue and every hour costs more than the help would
- The team is stressed enough that mistakes are likely
For emergency response on critical projects, we offer a 24/7 response option for retainer clients. You can book a meeting to discuss ongoing maintenance and emergency response arrangements.
Frequently Asked Questions About Recovering a Website After Server Crash
Don’t panic; confirm the crash from outside your network and identify the failure category before acting.
30 minutes to 4 hours with good backups; 1–5 days without.
3-2-1 rule: 3 copies, 2 storage types, 1 offsite (Hetzner Storage Box or AWS S3 Frankfurt).
Only if personal data was accessed; then you have 72 hours to notify the state DPA.
No — restore from a pre-compromise backup, then harden security before returning online.
€100–€500 for routine cases; €1,500–€10,000 for hacked site recovery with forensics.
Automated offsite backups, monitoring, monthly restore tests, written runbook, and managed hosting.
Final Word on How to Recover a Website After Server Crash
The hardest part of website recovery isn’t the technical work — it’s staying methodical while the site is down and the team is panicking. Work through the 8 steps in order. Snapshot before you restore. Verify before going live. Notify under GDPR if needed.
If you’d like to set up proper backup and monitoring before the next crash — or you need emergency help right now — you can book a meeting with our team. We offer maintenance retainers and emergency response for German SMEs.