Treat Docker live restore as bounded daemon-maintenance support

Keeping a container alive does not guarantee indefinite management or logging while its daemon is absent.

Source facts

Docker live restore can leave containers running when the daemon becomes unavailable. Docker documents support for daemon patch updates rather than arbitrary major-version upgrades, and warns that skipped releases may prevent reconnection. While the daemon is down, container log buffers can fill and block additional logging. Continued process execution is therefore only part of the maintenance outcome.

Source: Docker documentation — Live restore.

Applicability

This concerns standalone Docker live restore. Docker documents separate behavior for Swarm services and platform-specific limitations.

DSE recommendation

DSE recommends defining a short maintenance window, supported upgrade path, reconnection check, and fallback before relying on live restore. Monitor application health from outside the daemon as well as through container status afterward. Account for expected log volume during the interruption, especially for verbose services. Do not describe the feature as a high-availability solution or permission to skip upgrade compatibility review. Keep a recovery plan for containers the new daemon cannot manage and ensure the application owner understands any residual interruption risk.

Verification

In a nonproduction host, perform the intended supported maintenance path and observe application continuity, logging, and daemon reconnection. Confirm every expected container returns to management. Retain the observed limits before approving the same procedure for production workloads. Retain the exact old and new daemon versions and options in the rehearsal record. Have the operator reconcile the complete expected container list with the post-maintenance managed list, and define the unresolved-container escalation before starting the change.

Official reference

Docker documentation — Live restore. Reviewed October 20, 2026.