A disaster recovery plan
A backup is not a plan. A plan is knowing what comes back, in what order, how fast, and having proven it works before the bad day.
Two numbers decide everything
Recovery time objective is how long you can be down. Recovery point objective is how much data you can afford to lose. Pick honest numbers for each service — they set how often you back up and how much standby you pay for. A five-minute RPO and a one-hour RTO are a very different budget from a day of each.
Decide the order of return
Not everything comes back at once. Write down the dependency order: the database before the app, DNS and auth before anything that needs them. A short runbook for this is worth more than any tool — see writing a runbook.
Test the restore, not the backup
The only proof that a backup works is a restore into a clean machine. We can provision a staging server for a dry run. Rehearse it on a schedule, because the restore you never tested is the one that fails. Start from backups and restoring a backup, and keep an offline copy per ransomware-resistant backups.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base