--- title: Your Docker Container Restarted Successfully. The... description: Docker restart policies only recover the process, not the data. When a container restarts, any corrupted volume state persists unchanged — green container... canonical: https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Your Docker Container Restarted Successfully. The Corrupted Volume Restarted With It. | daily.dev og:description: Docker restart policies only recover the process, not the data. When a container restarts, any corrupted volume state persists unchanged — green container... og:url: https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g og:image: https://api.daily.dev/og/posts/QLWNkIV6g.png og:image:alt: Your Docker Container Restarted Successfully. The Corrupted Volume Restarted With It. 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 Docker Container Restarted Successfully. The Corrupted Volume Restarted With It. **[Medium](https://daily.dev/sources/medium_js)** · 8 min read · 0 upvotes · 0 comments ## Summary Docker restart policies only recover the process, not the data. When a container restarts, any corrupted volume state persists unchanged — green container status does not equal data integrity. The post explains the three-layer model (image, container, volume), why restart policies are not a repair framework, and how to properly respond to suspected volume corruption: freeze the scene before making changes, avoid destructive commands like `docker compose down -v`, use Docker's own inspection tools, and diagnose using the storage engine's native tooling. It also outlines a layered validation model (liveness, readiness, integrity, business correctness) and a structured recovery checklist including backup restore testing and alerting improvements. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does restarting a Docker container fix a corrupted volume? No, restarting a container only re-runs the entrypoint against the existing volume; it does not repair or validate the persisted data. Docker's restart policies (no, on-failure, always, unless-stopped) react to process termination and say nothing about whether the mounted volume is logically consistent, whether the storage device returned an I/O error, or whether the application's data passes integrity checks. _When storage failures strike production, teams researching Docker recovery steps often track deeper guidance through daily.dev._ ### Why does pg_isready passing not guarantee my PostgreSQL data is safe after a crash? pg_isready only tests whether PostgreSQL is accepting connections, not whether every relation is readable, every index is valid, every migration is present, or business queries return coherent results. A layered model separates liveness (is the process alive), readiness (can it take traffic), integrity (is persisted state valid), and business correctness (do representative operations behave correctly), and a passing readiness check covers only the first two. _Engineers hardening database health checks can follow deeper container reliability practices via daily.dev._ ### What should I do first if I suspect a Docker volume is corrupted? Reduce writes immediately rather than deleting or recreating anything: remove the service from traffic, stop writers or enable a proven read-only mode, record container and mount details, preserve logs outside the failing container, and snapshot or clone the volume using a supported storage mechanism before attempting any repair. Never run docker compose down -v or delete files inside Docker's volume storage directory, since both can destroy the state needed for recovery. _Anyone building an incident response runbook for stateful containers can find related practices on daily.dev._ ## Similar posts on daily.dev - [I added health checks to every Docker container, and now my homelab restarts its own broken services](https://daily.dev/posts/i-added-health-checks-to-every-docker-container-and-now-my-homelab-restarts-its-own-broken-services-arhxzw6yt) · XDA Developers · 0 upvotes · 0 comments - [When Kubernetes restarts your pod — And when it doesn’t](https://daily.dev/posts/when-kubernetes-restarts-your-pod-and-when-it-doesn-t-zhrxezkcv) · CNCF · 3 upvotes · 0 comments - [In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35](https://daily.dev/posts/in-place-pod-restarts-boosting-efficiency-and-workload-reliability-in-kubernetes-v1-35-ufjluvvsx) · Google Open Source Blog · 11 upvotes · 0 comments - [My production Postgres container kept running on an orphaned Portainer volume after an upgrade, and nothing warned me](https://daily.dev/posts/my-production-postgres-container-kept-running-on-an-orphaned-portainer-volume-after-an-upgrade-and--qsje7k6ni) · XDA Developers · 0 upvotes · 0 comments --- Tags: [#docker](https://daily.dev/tags/docker), [#orchestration](https://daily.dev/tags/orchestration) [View this post on daily.dev](https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g) ```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 Docker Container Restarted Successfully. The Corrupted Volume Restarted With It.","url":"https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g"},"datePublished":"2026-07-23T14:44:18.893Z","dateModified":"2026-09-13T20:42:23.930Z","description":"Docker restart policies only recover the process, not the data. When a container restarts, any corrupted volume state persists unchanged — green container...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c29d6ad38917f5e0f142ab51b58cf98?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c29d6ad38917f5e0f142ab51b58cf98?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","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":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"docker,orchestration","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Your Docker Container Restarted Successfully. The Corrupted Volume Restarted With It."}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/your-docker-container-restarted-successfully-the-corrupted-volume-restarted-with-it--qlwnkiv6g#faq","mainEntity":[{"@type":"Question","name":"Does restarting a Docker container fix a corrupted volume?","acceptedAnswer":{"@type":"Answer","text":"No, restarting a container only re-runs the entrypoint against the existing volume; it does not repair or validate the persisted data. Docker's restart policies (no, on-failure, always, unless-stopped) react to process termination and say nothing about whether the mounted volume is logically consistent, whether the storage device returned an I/O error, or whether the application's data passes integrity checks. When storage failures strike production, teams researching Docker recovery steps often track deeper guidance through daily.dev."}},{"@type":"Question","name":"Why does pg_isready passing not guarantee my PostgreSQL data is safe after a crash?","acceptedAnswer":{"@type":"Answer","text":"pg_isready only tests whether PostgreSQL is accepting connections, not whether every relation is readable, every index is valid, every migration is present, or business queries return coherent results. A layered model separates liveness (is the process alive), readiness (can it take traffic), integrity (is persisted state valid), and business correctness (do representative operations behave correctly), and a passing readiness check covers only the first two. Engineers hardening database health checks can follow deeper container reliability practices via daily.dev."}},{"@type":"Question","name":"What should I do first if I suspect a Docker volume is corrupted?","acceptedAnswer":{"@type":"Answer","text":"Reduce writes immediately rather than deleting or recreating anything: remove the service from traffic, stop writers or enable a proven read-only mode, record container and mount details, preserve logs outside the failing container, and snapshot or clone the volume using a supported storage mechanism before attempting any repair. Never run docker compose down -v or delete files inside Docker's volume storage directory, since both can destroy the state needed for recovery. Anyone building an incident response runbook for stateful containers can find related practices on daily.dev."}}]} ```