Bottom line: Identify the active image store before treating an empty Docker listing as deleted data. Keep the pre-switch inventory and storage locations available so an operator can distinguish backend visibility from a real loss or cleanup result.
\nThe containerd image store with Docker Engine documentation is the primary reference.
\nDocker says changing storage backends temporarily hides the other backend’s images and containers; their data remains on disk and becomes accessible again when the prior configuration is restored. The guide attributes greater disk use for the same images to containerd keeping compressed layers as well as their extracted form. Containerd uses a separate storage path, so a custom Docker data directory does not automatically relocate containerd’s data.
\nThis article concerns manual backend visibility and data-location review. It does not qualify an image migration, archive, application recovery or disk-reclamation procedure. It excludes lazy-pulled image handling and the page’s experimental automatic-migration branch; those require their own documented assessment.
\nDSE recommends retaining the daemon identity, active backend and relevant inventories before a manual change. Record image and container identifiers needed for the workload, alongside the intended management context. Keep a missing listing as an observation to investigate instead of immediately recreating or pruning resources.
\nReview both data locations with the host owner. Trace any existing custom Docker data directory separately from the containerd configuration. Compare actual disk observations with that map before reporting reclaimed capacity. Do not remove an unexplained backend directory to make the current listing and disk total appear consistent.
\nUse the installed version’s documented backend inspection method to confirm the selected configuration after the change. If a rollback is considered, have the workload owner review the prior backend and required state before restoring it. Keep a visibility check distinct from application startup and data acceptance.
\nPlan any image-transfer or archival step through a separately reviewed workflow with its own completeness evidence. Preserve the original inventory until the owner accepts the intended image and container access. Do not assume that a changed backend has migrated, deleted or successfully backed up the old data solely because the new daemon operates.
\nProposed verification, not performed: use a disposable native Engine test setup and harmless local images under the documented manual-switch procedure. Record the original inventory and active store, observe the switched listing, then inspect the retained data locations through the approved host route.
\nIf an authorized return to the prior configuration is included, compare the resulting visibility with the original inventory. Keep observed image access, container state and actual disk use as separate results. Retain configuration revisions, backend observations and inventory differences. Do not exercise the experimental automatic-migration path or claim an archive/recovery result from this narrower visibility test.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Identify the active image store before treating an empty Docker listing as deleted data. Keep the pre-switch inventory and storage locations available so an operator can distinguish backend visibility from a real loss or cleanup result.\nSource fact: documented behavior\nThe containerd image store with Docker Engine documentation is the primary reference.\nDocker says changing storage backends temporarily hides the other backend’s images and containers; their data remains on disk and becomes accessible again when the prior configuration is restored. The guide attributes greater disk use for the same images to containerd keeping compressed layers as well as their extracted form. Containerd uses a separate storage path, so a custom Docker data directory does not automatically relocate containerd’s data.\nWhat the source does not establish\nThis article concerns manual backend visibility and data-location review. It does not qualify an image migration, archive, application recovery or disk-reclamation procedure. It excludes lazy-pulled image handling and the page’s experimental automatic-migration branch; those require their own documented assessment.\nApplicability questions\n\nWhich storage backend is active on the actual daemon?\nWhat images and containers were recorded before the switch?\nWhere do Docker and containerd actually store their data?\nWhich observations establish required access before any cleanup is approved?\n\nDSE recommendation: preserve the two-backend record\nDSE recommends retaining the daemon identity, active backend and relevant inventories before a manual change. Record image and container identifiers needed for the workload, alongside the intended management context. Keep a missing listing as an observation to investigate instead of immediately recreating or pruning resources.\nReview both data locations with the host owner. Trace any existing custom Docker data directory separately from the containerd configuration. Compare actual disk observations with that map before reporting reclaimed capacity. Do not remove an unexplained backend directory to make the current listing and disk total appear consistent.\nUse the installed version’s documented backend inspection method to confirm the selected configuration after the change. If a rollback is considered, have the workload owner review the prior backend and required state before restoring it. Keep a visibility check distinct from application startup and data acceptance.\nPlan any image-transfer or archival step through a separately reviewed workflow with its own completeness evidence. Preserve the original inventory until the owner accepts the intended image and container access. Do not assume that a changed backend has migrated, deleted or successfully backed up the old data solely because the new daemon operates.\nVerification and evidence\nProposed verification, not performed: use a disposable native Engine test setup and harmless local images under the documented manual-switch procedure. Record the original inventory and active store, observe the switched listing, then inspect the retained data locations through the approved host route.\nIf an authorized return to the prior configuration is included, compare the resulting visibility with the original inventory. Keep observed image access, container state and actual disk use as separate results. Retain configuration revisions, backend observations and inventory differences. Do not exercise the experimental automatic-migration path or claim an archive/recovery result from this narrower visibility test.\nOfficial references\n\ncontainerd image store with Docker Engine — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Identify the active image store before treating an empty Docker listing as deleted data. Keep the pre-switch inventory and storage locations available so an operator can distinguish backend visibility from a real loss or cleanup result.\n\n## Source fact: documented behavior\n\nThe [containerd image store with Docker Engine](https://docs.docker.com/engine/storage/containerd/) documentation is the primary reference.\n\nDocker says changing storage backends temporarily hides the other backend’s images and containers; their data remains on disk and becomes accessible again when the prior configuration is restored. The guide attributes greater disk use for the same images to containerd keeping compressed layers as well as their extracted form. Containerd uses a separate storage path, so a custom Docker data directory does not automatically relocate containerd’s data.\n\n## What the source does not establish\n\nThis article concerns manual backend visibility and data-location review. It does not qualify an image migration, archive, application recovery or disk-reclamation procedure. It excludes lazy-pulled image handling and the page’s experimental automatic-migration branch; those require their own documented assessment.\n\n## Applicability questions\n\n- Which storage backend is active on the actual daemon?\n\n- What images and containers were recorded before the switch?\n\n- Where do Docker and containerd actually store their data?\n\n- Which observations establish required access before any cleanup is approved?\n\n## DSE recommendation: preserve the two-backend record\n\nDSE recommends retaining the daemon identity, active backend and relevant inventories before a manual change. Record image and container identifiers needed for the workload, alongside the intended management context. Keep a missing listing as an observation to investigate instead of immediately recreating or pruning resources.\n\nReview both data locations with the host owner. Trace any existing custom Docker data directory separately from the containerd configuration. Compare actual disk observations with that map before reporting reclaimed capacity. Do not remove an unexplained backend directory to make the current listing and disk total appear consistent.\n\nUse the installed version’s documented backend inspection method to confirm the selected configuration after the change. If a rollback is considered, have the workload owner review the prior backend and required state before restoring it. Keep a visibility check distinct from application startup and data acceptance.\n\nPlan any image-transfer or archival step through a separately reviewed workflow with its own completeness evidence. Preserve the original inventory until the owner accepts the intended image and container access. Do not assume that a changed backend has migrated, deleted or successfully backed up the old data solely because the new daemon operates.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable native Engine test setup and harmless local images under the documented manual-switch procedure. Record the original inventory and active store, observe the switched listing, then inspect the retained data locations through the approved host route.\n\nIf an authorized return to the prior configuration is included, compare the resulting visibility with the original inventory. Keep observed image access, container state and actual disk use as separate results. Retain configuration revisions, backend observations and inventory differences. Do not exercise the experimental automatic-migration path or claim an archive/recovery result from this narrower visibility test.\n\n## Official references\n\n- [containerd image store with Docker Engine](https://docs.docker.com/engine/storage/containerd/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/", "url": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Account for hidden images after a Docker image-store switch", "item": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/#article", "identifier": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/", "url": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/", "headline": "Account for hidden images after a Docker image-store switch", "description": "Switching Docker Engine storage backends can hide the previous backend's images and containers while data remains on disk.", "abstract": "Switching Docker Engine storage backends can hide the previous backend's images and containers while data remains on disk. Verify the active store and both data locations before cleanup.", "articleBody": "Bottom line: Identify the active image store before treating an empty Docker listing as deleted data. Keep the pre-switch inventory and storage locations available so an operator can distinguish backend visibility from a real loss or cleanup result.\nSource fact: documented behavior\nThe containerd image store with Docker Engine documentation is the primary reference.\nDocker says changing storage backends temporarily hides the other backend’s images and containers; their data remains on disk and becomes accessible again when the prior configuration is restored. The guide attributes greater disk use for the same images to containerd keeping compressed layers as well as their extracted form. Containerd uses a separate storage path, so a custom Docker data directory does not automatically relocate containerd’s data.\nWhat the source does not establish\nThis article concerns manual backend visibility and data-location review. It does not qualify an image migration, archive, application recovery or disk-reclamation procedure. It excludes lazy-pulled image handling and the page’s experimental automatic-migration branch; those require their own documented assessment.\nApplicability questions\n\nWhich storage backend is active on the actual daemon?\nWhat images and containers were recorded before the switch?\nWhere do Docker and containerd actually store their data?\nWhich observations establish required access before any cleanup is approved?\n\nDSE recommendation: preserve the two-backend record\nDSE recommends retaining the daemon identity, active backend and relevant inventories before a manual change. Record image and container identifiers needed for the workload, alongside the intended management context. Keep a missing listing as an observation to investigate instead of immediately recreating or pruning resources.\nReview both data locations with the host owner. Trace any existing custom Docker data directory separately from the containerd configuration. Compare actual disk observations with that map before reporting reclaimed capacity. Do not remove an unexplained backend directory to make the current listing and disk total appear consistent.\nUse the installed version’s documented backend inspection method to confirm the selected configuration after the change. If a rollback is considered, have the workload owner review the prior backend and required state before restoring it. Keep a visibility check distinct from application startup and data acceptance.\nPlan any image-transfer or archival step through a separately reviewed workflow with its own completeness evidence. Preserve the original inventory until the owner accepts the intended image and container access. Do not assume that a changed backend has migrated, deleted or successfully backed up the old data solely because the new daemon operates.\nVerification and evidence\nProposed verification, not performed: use a disposable native Engine test setup and harmless local images under the documented manual-switch procedure. Record the original inventory and active store, observe the switched listing, then inspect the retained data locations through the approved host route.\nIf an authorized return to the prior configuration is included, compare the resulting visibility with the original inventory. Keep observed image access, container state and actual disk use as separate results. Retain configuration revisions, backend observations and inventory differences. Do not exercise the experimental automatic-migration path or claim an archive/recovery result from this narrower visibility test.\nOfficial references\n\ncontainerd image store with Docker Engine — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:14+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Account for hidden images after a Docker image-store switch" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 530, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — containerd image store with Docker Engine", "url": "https://docs.docker.com/engine/storage/containerd/" } } ] } }