DDoS protection and backups: build two different lines of defence
An available network and recoverable data solve different problems. HM Bastion includes DDoS protection in its infrastructure, while a sound operating plan still needs access controls, application maintenance and a recovery copy you have tested.
The practical takeaway
Use mitigation to reduce malicious traffic, maintain the application to reduce compromise risk, and keep independently recoverable data for the failures that protection cannot prevent.
Name the failure before choosing the defence
A volumetric traffic flood can consume network capacity. An expensive application request can exhaust a service with far less traffic. A stolen administrator credential can change or delete content while the network remains healthy. These events have different causes, so one protection feature cannot stand in for a complete operating plan.
DDoS mitigation aims to identify and reduce attack traffic while allowing useful traffic through. The precise handling depends on the attack and protected service. Always-on protection does not mean every application is invulnerable, that all protocols behave identically, or that an uptime guarantee has been created.
Keep the application behind the gate healthy
For a VPS or dedicated server, keep administrative access deliberate. Remove services you do not need, apply operating-system and application updates, and restrict privileged access to the people and systems that require it. Keep secrets out of public folders and review logs when behaviour changes.
For a web application, consider authentication controls, request limits and cache behaviour alongside network mitigation. Expensive uncached endpoints deserve attention even when the surrounding network has room. A legitimate traffic surge can expose the same application bottleneck as abusive requests, so normal capacity planning still matters.
Record the ports, domains and protocols the application actually needs. When opening a support request about an incident, provide the affected service, approximate time, visible symptoms and safe diagnostic details. Never include a wallet secret, account password or private recovery key in a ticket.
Give each recovery layer its own job
| Layer | Useful for | Keep in mind |
|---|---|---|
| Replicated storage | Continuity through some storage hardware failures | An unwanted data change can be replicated too |
| Snapshot | Returning to a captured system state | Retention and independence differ from a separate backup |
| Independent backup | Recovering data from a separate copy | It must include the needed files, databases and restore knowledge |
HM Bastion cloud specifications describe Ceph-replicated storage and snapshots. Web-hosting ranges publish daily backups with up to ten restore points. Read the feature attached to the service you are buying; do not assume the same backup arrangement exists on every hosting family.
Choose a recovery schedule around how much recent work the project can lose and how long restoration can take. A brochure site and an active order database have different needs. Keep recovery credentials separately from the running application, and ensure more than one authorised person knows where the procedure is stored.
Test a restore while the system is healthy
- Identify the website files, database, uploads and configuration required to restart.
- Create an independent copy with access limited to authorised people.
- Restore into a safe test environment rather than overwriting production.
- Check content, application access and the important user journeys.
- Record the result, the elapsed time and anything missing from the procedure.
A file that exists in backup storage is useful evidence of a copy, but a successful restore is stronger evidence of recoverability. Repeat the test after a significant application or storage change. This turns a vague promise to recover later into a procedure the team can actually follow.
When an incident does happen, keep network mitigation, application diagnosis and data recovery as separate workstreams with a clear owner for each. That structure helps the team act on the actual failure instead of reaching for the same reset or rollback action every time.
