Account for hidden images after a Docker image-store switch

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 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 — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.