Write a recovery plan you can actually use

Define the service boundary

List the website, DNS, certificates, database and any outside services needed for the main visitor journey. Decide which components you control and which require provider support. A diagram with a few accurate boxes is more helpful than a large undocumented list of installed software.

Choose a recovery target

Discuss how much recent work can be lost and how long the service can be unavailable. These are requirements, not promises from the backup tool. They determine how frequently copies are made and how quickly replacement hosting must be available. Revisit them when the site's purpose changes.

Keep recovery independent

Store a copy outside the public document directory and maintain an additional independent backup where appropriate. Check access to recovery instructions without relying on the failed service. Protect credentials in an authorised password manager rather than embedding them in publicly accessible notes or archives.

Practise on a separate copy

Restore into a test location and inspect the pages, data and permissions. Do not overwrite the working service to discover whether a backup is complete. Record missing steps and correct the instructions. A successful archive extraction is only one part of a successful website restoration.

Include the hosting provider

Know the incident route and what information support will need. If DDoS protection is required, ask about covered traffic, escalation and any conditions that can interrupt service. KoDDoS can be considered within that comparison; validate its current arrangements for the particular plan being evaluated.

Close the loop after recovery

Check the public hostname, HTTPS, a deep page and any form or transaction that matters. Confirm that new backups are being made from the recovered service. Record what failed and update the plan while the details are fresh. Recovery is complete when the restored service and its protection have both been checked.

Put it into practice