# Account for hidden images after a Docker image-store switch > 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. - Canonical URL: https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:14+00:00 - Modified: 2026-10-29T19:50:09+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know 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. ## Potentially affected Review scope: manual Docker Engine image-store selection and retained backend data; lazy pulling and experimental automatic migration are excluded. ## DSE recommendation Preserve the pre-switch inventory and active-store evidence, then reconcile hidden backend data before declaring deletion or reclaiming disk space. ## Article 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. ## Source fact: documented behavior The [containerd image store with Docker Engine](https://docs.docker.com/engine/storage/containerd/) documentation is the primary reference. Docker 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. ## What the source does not establish This 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. ## Applicability questions - Which storage backend is active on the actual daemon? - What images and containers were recorded before the switch? - Where do Docker and containerd actually store their data? - Which observations establish required access before any cleanup is approved? ## DSE recommendation: preserve the two-backend record DSE 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. Review 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. Use 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. Plan 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. ## Verification and evidence Proposed 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. If 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. ## Official references - [containerd image store with Docker Engine](https://docs.docker.com/engine/storage/containerd/) — Docker Docs. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — containerd image store with Docker Engine - Authority: docs.docker.com - URL: https://docs.docker.com/engine/storage/containerd/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Account for hidden images after a Docker image-store switch,” DSE Security, https://update.dsesecurity.com/updates/account-for-hidden-images-after-a-docker-image-store-switch/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.