A backup only helps if it survives the same failure boundary as production and can still be restored cleanly after an incident.
A backup that sits beside production can disappear with production. The file, snapshot or bucket may still look present in a dashboard until the moment a team needs it, then it turns out to be encrypted, deleted, incomplete or unreachable because the same credentials, permissions or cloud boundary were hit. That is the failure mode many operators miss. They see a copy and assume recovery, but the real question is whether the copy can survive the same incident that takes down the live system.
This matters most to small and mid-sized teams that keep convenience close to the server, account or project running the service. The storage may be cheap, the setup may be tidy, and the backup may even be automated, yet none of that proves it is recoverable. The useful distinction is not between 'backup' and 'no backup'. It is between a copy that merely exists and a protected recovery copy that can still be used after the outage, account compromise or ransomware event that affected production.
What the documentation actually says
The core evidence is mechanism-level, not vendor marketing. PostgreSQL’s backup documentation says databases should be backed up regularly, that there are three fundamentally different approaches to backing up PostgreSQL data, and that each approach has its own strengths and weaknesses. In other words, backup topology is a design choice with trade-offs, not a single universal action. The document also stresses that teams need a clear understanding of the techniques and assumptions behind the strategy, which is the right lens for judging whether a backup will still be usable after an incident.
CISA’s ransomware guidance points in the same direction from the recovery side. It recommends offline or cloud-to-cloud backups, says to enable delete protection or object lock on storage that attackers often target, and advises restoring from offline, encrypted backups after a ransomware incident. The practical meaning is plain: if the backup stays writable from the same administrative boundary as production, ransomware or a compromised account can reach both copies. A protected recovery copy has to live outside that blast radius.
That is the operational distinction worth keeping in view. A backup is not defined by where it lives in a diagram or by how often it runs. It is defined by the failure boundary it can survive. If the same incident can delete the backup, encrypt it, or corrupt the permissions needed to access it, then the backup is not a recovery asset. It is only a second copy with the same exposure. In practice, that means the question is not whether a team has storage labelled 'backup', but whether the backup can outlast the exact failure that would otherwise take the service down.
| Topology | What it means | What it protects against | Where it still fails | Decision |
|---|---|---|---|---|
| Same-boundary | Backup lives in the same account, project, cluster or admin domain as production | Very little beyond ordinary user error | Credential theft, ransomware or deletion can take both production and backup | Do not treat it as a protected recovery copy |
| Separately managed | Backup is in a different account, project or admin path with delete protection or object lock | Many production-side deletions and overwrites | Still depends on access control and restore validation | Better, but only if restores are verified |
| Offline or cloud-to-cloud | Protected copy is disconnected or held in a separate backup service outside the primary writable boundary | Ransomware, local site loss and routine production failure | Restore time, clean-room access and process discipline still matter | Strongest posture in the supplied guidance |
The table is useful because it shifts the question from presence to survivability. A same-boundary backup may be fine for quick rollback in normal operations, but it is a poor answer to ransomware or account compromise. A separately managed copy reduces shared-failure risk, yet it still needs protection against deletion and a tested restore path. An offline or cloud-to-cloud recovery copy is stronger because it changes the control relationship, not just the storage location. That is why topology matters more than branding: the important detail is who can alter the copy when production is already under pressure.
Two checks that separate a recoverable copy from a dangerous illusion
If either check fails, the next move is not to buy more retention or assume a longer backup history will save the day. The response is structural. Move at least one recovery copy outside the primary failure boundary, turn on delete protection or object lock where the platform supports it, and make restore verification part of normal operations. The point is not to keep every copy immutable forever. The point is to ensure that one copy survives the incident long enough to restore cleanly.
What the backup does not protect against
No source in this packet says that an offsite copy is automatically recoverable, and that is the right caution. A backup can still fail because it is corrupted, incomplete, misconfigured or restored too early. PostgreSQL’s documentation is explicit that backup methods have different trade-offs and assumptions, which means teams must know what their chosen method can and cannot do. CISA adds another hard limit: if a team restores systems before identifying the malware or cleaning the environment, it can reintroduce the compromise into the rebuilt system.
There are also gaps the supplied evidence cannot fill. It does not give a minimum restore-test cadence, a retention period, a vendor comparison or Kenya-specific incident data. It supports a decision guide, not a product ranking. That matters for readers in East Africa and elsewhere because local infrastructure choices, cloud contracts and compliance duties vary. The principle holds across those differences, but the implementation has to fit the team’s own control boundaries and recovery objectives. In other words, the idea is portable, but the operating detail is local.
