Plan the manager stop before backing up Swarm state

Bottom line: Review the manager stop and remaining quorum before the backup window. Treat the state-directory copy, protected key custody and separate restoration exercise as distinct acceptance checkpoints.

Source fact: documented behavior

The Administer and maintain a swarm of Docker Engines documentation is the primary reference.

Docker stores manager state, manager logs and Raft-log encryption keys in /var/lib/docker/swarm/; the documentation requires those keys for restoration. The backup procedure stops Docker on the selected manager before copying the entire state directory; it describes a running-manager backup as possible but less predictable on restoration. The remaining managers must maintain quorum during that stop, and an autolocked Swarm also requires its unlock key to restore the backup.

What the source does not establish

This article reviews the documented backup preparation and artifact boundary. It does not guarantee recovery, define application-data backup or authorize forced-cluster recovery. Keep routine autolock rotation, manager membership repair and application restoration under their separate approved procedures.

Applicability questions

• Which manager will be stopped, and what manager population remains available?
• Who owns the approved stop, backup and restart sequence?
• Does the protected recovery material include the required unlock-key reference when autolock applies?
• Which isolated restoration exercise will establish that the retained backup is usable for the intended recovery?

DSE recommendation: review availability and the recovery set together

DSE recommends a backup worksheet identifying the selected manager, its state-directory location, remaining manager population and protected key custodian. Have the Swarm owner approve the maintenance sequence before stopping Docker. Resolve an already unavailable manager through the established operational procedure rather than treating the planned backup as the only loss to consider.

Define the copy boundary explicitly. Have the backup owner preserve the complete documented directory through the approved backup tooling, with access control and retention appropriate to the material. Keep sensitive keys and directory contents outside ordinary tickets or unprotected diagnostic bundles. Record controlled artifact identifiers instead of exposing credentials in the evidence.

Prepare the restart and observation checkpoints before the stop. Name the operator who confirms the manager returns to the expected state, and define when further maintenance may proceed. Record the actual backup interval separately from any later Swarm changes. Do not relabel a convenient live copy as the reviewed stopped-manager procedure.

Connect the backup to a separately approved recovery exercise. Identify the intended recovery environment, the protected unlock-key retrieval path where applicable and the application acceptance owner. Keep application data and dependencies visible as separate requirements. Require observed restoration evidence before treating successful file transfer alone as a completed recovery capability.

Verification and evidence

Proposed verification, not performed: use an isolated test Swarm and the approved manager-availability plan. Record the pre-stop manager population, stop the selected manager through the managed procedure, capture the complete state-directory backup and observe the approved restart checkpoints.

Under a separate isolated restoration plan, use the retained artifact and authorized key retrieval without exposing key values. Compare the recovered Swarm state with the test inventory, and run the application owner’s permitted checks. Retain backup identity, timestamps, sanitized manager observations and restoration findings. Report gaps in state or application recovery explicitly; this proposed sequence claims no performed restore or universal recovery outcome.

Official references

• Administer and maintain a swarm of Docker Engines — Docker Docs.

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