A backup is useful after compromise only if the attacker could not silently alter every copy and you can restore without trusting the damaged host. Use separate credentials, an isolated or immutable copy, documented retention, and regular restore exercises.
What should the backup design protect?
Protect three things separately: the data, the backup control plane, and the evidence needed to rebuild. A server-root credential should not automatically grant deletion or rewriting rights over every backup.
A small-team baseline is:
- Multiple copies on different failure domains.
- At least one copy offline, isolated, or protected by an immutability policy.
- Backup credentials unavailable to the application where practical.
- Retention long enough to precede unnoticed tampering.
- A clean rebuild and restore runbook stored outside the compromised host.
What changes during an incident?
Do not restore blindly onto the compromised machine. Preserve relevant evidence according to your incident plan, revoke or isolate credentials, identify a clean recovery environment, and decide which backup point predates the suspected intrusion. Treat backup metadata and logs as part of the investigation.
How do you know the plan works?
A successful backup job is not restore evidence. Test restoration of representative files and the full service path, including configuration, permissions, secrets replacement, DNS, certificates, and private-access recovery. Record duration, dependencies, and the person who can perform the work.
This design complements the site’s VPS exposure audit and server security review checklist. It is a design guide, not a claim that a particular restore has been performed.