--- title: Your backups are green. That does not mean you can restore. description: A green backup dashboard only proves a job finished, not that you can actually recover a PostgreSQL database. In one composite incident pattern, a column was... canonical: https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Your backups are green. That does not mean you can restore. | daily.dev og:description: A green backup dashboard only proves a job finished, not that you can actually recover a PostgreSQL database. In one composite incident pattern, a column was... og:url: https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx og:image: https://api.daily.dev/og/posts/F9dWEiJcX.png og:image:alt: Your backups are green. That does not mean you can restore. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Your backups are green. That does not mean you can restore. **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 7 min read · 0 upvotes · 0 comments ## Summary A green backup dashboard only proves a job finished, not that you can actually recover a PostgreSQL database. In one composite incident pattern, a column was dropped at 09:38 and the restore that followed took more than two days, with data loss, because no restore host existed and a WAL segment was missing from the archive. Common failure modes include broken WAL chains, corruption copied faithfully into every backup, mismatched retention between backups and WAL, missing surroundings like roles and certificates, lost encryption keys, and no machine to restore to. The only real test is restoring files, starting the cluster, replaying to a point in time, and verifying the data. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did my PostgreSQL point-in-time restore fail even though backups always showed as successful? A successful backup job only confirms a process ran and bytes were copied, not that recovery works. Common causes of restore failure include a broken WAL archive chain, missing files outside the data directory like roles and certificates, retention windows that don't line up between backups and WAL, or a damaged page that was faithfully copied into every backup for months. _Anyone who has hit a failed restore after a green backup can compare recovery pitfalls on daily.dev._ ### Why does my PostgreSQL WAL archiving fail silently without stopping the database? A broken WAL archive does not stop the database or the backup job, so PostgreSQL just keeps the segments and retries while disk pressure builds on pg_wal. The fix is freeing disk space is the wrong reaction since it can permanently break point-in-time recovery; instead monitor archive failure count, the age of the newest archived segment, and pg_wal size separately from the backup job. _Teams hardening disaster recovery setups track archiving pitfalls like this one on daily.dev._ ### How long should I retain PostgreSQL backups to protect against data corruption? Retention does not protect against corruption the way it protects against accidental deletion; a damaged page gets copied into every backup within the retention window, so thirty days of retention is really just thirty days to notice before the last clean copy expires. Data checksums being disabled on older clusters makes silent corruption more likely to go unnoticed until a rarely run report fails. _Engineers planning retention policies can weigh real-world recovery trade-offs like this on daily.dev._ ## Similar posts on daily.dev - [Inside branch-based restores in Lakebase Postgres](https://daily.dev/posts/inside-branch-based-restores-in-lakebase-postgres-udhwx0m8z) · Neon · 1 upvotes · 1 comments - [pgBackRest and PostgreSQL failover: why archive\_mode matters](https://daily.dev/posts/pgbackrest-and-postgresql-failover-why-archive-mode-matters-rurfsamas) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostgreSQL Recovery Internals](https://daily.dev/posts/postgresql-recovery-internals-fyfrz2lny) · CYBERTEC PostgreSQL · 3 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Your backups are green. That does not mean you can restore.","url":"https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx"},"datePublished":"2026-10-26T11:04:18.188Z","dateModified":"2026-10-26T11:13:32.628Z","description":"A green backup dashboard only proves a job finished, not that you can actually recover a PostgreSQL database. In one composite incident pattern, a column was...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b9cc39cbd3b3f0eded6acf443d1561e1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b9cc39cbd3b3f0eded6acf443d1561e1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"Your backups are green. That does not mean you can restore."}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/your-backups-are-green-that-does-not-mean-you-can-restore--f9dweijcx#faq","mainEntity":[{"@type":"Question","name":"Why did my PostgreSQL point-in-time restore fail even though backups always showed as successful?","acceptedAnswer":{"@type":"Answer","text":"A successful backup job only confirms a process ran and bytes were copied, not that recovery works. Common causes of restore failure include a broken WAL archive chain, missing files outside the data directory like roles and certificates, retention windows that don't line up between backups and WAL, or a damaged page that was faithfully copied into every backup for months. Anyone who has hit a failed restore after a green backup can compare recovery pitfalls on daily.dev."}},{"@type":"Question","name":"Why does my PostgreSQL WAL archiving fail silently without stopping the database?","acceptedAnswer":{"@type":"Answer","text":"A broken WAL archive does not stop the database or the backup job, so PostgreSQL just keeps the segments and retries while disk pressure builds on pg_wal. The fix is freeing disk space is the wrong reaction since it can permanently break point-in-time recovery; instead monitor archive failure count, the age of the newest archived segment, and pg_wal size separately from the backup job. Teams hardening disaster recovery setups track archiving pitfalls like this one on daily.dev."}},{"@type":"Question","name":"How long should I retain PostgreSQL backups to protect against data corruption?","acceptedAnswer":{"@type":"Answer","text":"Retention does not protect against corruption the way it protects against accidental deletion; a damaged page gets copied into every backup within the retention window, so thirty days of retention is really just thirty days to notice before the last clean copy expires. Data checksums being disabled on older clusters makes silent corruption more likely to go unnoticed until a rarely run report fails. Engineers planning retention policies can weigh real-world recovery trade-offs like this on daily.dev."}}]} ```