What can go wrong
| Risk | What it looks like | What helps |
|---|---|---|
| Hardware failure | The server stops responding | Off-server backups, a tested restore, a standby plan |
| Network problems | Visitors cannot reach the site | Monitoring from outside your server, a provider with clear incident reports |
| Human error | A file is deleted or a setting is broken | Change logs, staging copies, restore points |
| Attack | Malware, defacement or a flood of requests | Updates, firewall rules, a WAF, DDoS protection from your provider |
| Ageing software | Unsupported versions stop getting security fixes | A schedule for upgrades and end-of-life dates |
Backups you can rely on
- Keep at least one copy off the server, in a different location.
- Keep several generations, so you can go back to a date before a problem started.
- Test a restore every few months, and time how long it takes.
- Back up databases and files together, so the site restores as one piece.
Monitoring and alerts
Monitor the site from outside your server, so you learn about an outage even when the server cannot report it. Add alerts for disk space, memory, failed services and expired certificates. An alert that nobody reads is no use, so name a person for each type of alert.
A written recovery plan
- List the services in priority order: the website, email, payments, then everything else.
- Write down who decides, who restores, and how customers are told.
- Keep the plan with the backup details, somewhere you can read during an outage.
- Review the plan after each incident and after each major change.
Locations and legal obligations
Where a server sits can matter for latency and for the data rules that apply to your business. It does not remove your own obligations, such as privacy and copyright law, and it does not stop legitimate takedown requests or legal orders. Decide the location with your users and your legal advice in mind.
Plan for growth
Traffic grows unevenly. Track your resource use monthly, plan upgrades before a sale or launch, and load-test the site beforehand. For a closer look at scaling options, see our guide to scaling with Cloud VPS hosting.
Communicate during an incident
Decide in advance how you will tell customers about an outage: where you post updates, who writes them, and how often. Short, factual updates with a time for the next update reduce support requests and build trust.
Test the plan
A plan that has never been tried is a guess. Once or twice a year, run a short exercise: restore a backup to a test server, switch DNS to it in a test domain, and time each step. Write down what took longer than expected and update the plan.
Know the cost of downtime
Estimate what an hour of downtime costs: lost sales, staff time and damage to reputation. The result helps you decide how much to spend on backups, standby capacity and monitoring, and makes the case for the investment.
Assign roles before an incident
Name one person to decide on actions, one to carry them out and one to speak to customers. Include a backup for each role, because the usual person may be unavailable at the time. Keep their contact details with the recovery plan.
Document the systems
Keep a short description of each service: where it runs, who manages it, which backups cover it and how to restore it. Review the description after each major change, because an out-of-date document is almost as bad as none.
Third-party services
Email delivery, payment processing, DNS and analytics are often provided by other companies. Note which ones your site depends on, how to reach each provider, and what happens if one of them is unavailable.
Review the plan after each change
Each new service, provider or major update can change what the recovery steps look like. Add a short review to every change request: does the backup still cover this service, does the restore still work, and who needs to know about it?
Need help putting this into practice?
Our team can review your setup and help you choose the right plan. Contact @CustomerPanel for support.
Frequently asked questions
What is the most important continuity measure?
Tested backups kept off the server. Without a tested restore, a backup is only a hope.
How often should I test a restore?
Every few months, and after any change to the backup process.
Do I need a standby server?
It depends on how much downtime the business can accept. Many sites are covered by fast restores; critical services may need a second server.
Who should receive the alerts?
A named person, with a backup contact, so that alerts are read at any hour.
