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.
\nThe Administer and maintain a swarm of Docker Engines documentation is the primary reference.
\nDocker 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.
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.
\nDSE 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.
\nDefine 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.
\nPrepare 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.
\nConnect 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.
\nProposed 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.
\nUnder 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Administer and maintain a swarm of Docker Engines documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich manager will be stopped, and what manager population remains available?\nWho owns the approved stop, backup and restart sequence?\nDoes the protected recovery material include the required unlock-key reference when autolock applies?\nWhich isolated restoration exercise will establish that the retained backup is usable for the intended recovery?\n\nDSE recommendation: review availability and the recovery set together\nDSE 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.\nDefine 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.\nPrepare 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.\nConnect 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.\nVerification and evidence\nProposed 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.\nUnder 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.\nOfficial references\n\nAdminister and maintain a swarm of Docker Engines — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Administer and maintain a swarm of Docker Engines](https://docs.docker.com/engine/swarm/admin_guide/) documentation is the primary reference.\n\nDocker 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which manager will be stopped, and what manager population remains available?\n\n- Who owns the approved stop, backup and restart sequence?\n\n- Does the protected recovery material include the required unlock-key reference when autolock applies?\n\n- Which isolated restoration exercise will establish that the retained backup is usable for the intended recovery?\n\n## DSE recommendation: review availability and the recovery set together\n\nDSE 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.\n\nDefine 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.\n\nPrepare 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.\n\nConnect 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.\n\n## Verification and evidence\n\nProposed 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.\n\nUnder 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.\n\n## Official references\n\n- [Administer and maintain a swarm of Docker Engines](https://docs.docker.com/engine/swarm/admin_guide/) — Docker Docs.\n\nSource review completed October 30, 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/plan-the-manager-stop-before-backing-up-swarm-state/", "url": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/#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": "Plan the manager stop before backing up Swarm state", "item": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/#article", "identifier": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/", "url": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/", "headline": "Plan the manager stop before backing up Swarm state", "description": "Review manager quorum, the full Swarm state directory and any required autolock key before accepting a backup procedure.", "abstract": "Review manager quorum, the full Swarm state directory and any required autolock key before accepting a backup procedure.", "articleBody": "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.\nSource fact: documented behavior\nThe Administer and maintain a swarm of Docker Engines documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich manager will be stopped, and what manager population remains available?\nWho owns the approved stop, backup and restart sequence?\nDoes the protected recovery material include the required unlock-key reference when autolock applies?\nWhich isolated restoration exercise will establish that the retained backup is usable for the intended recovery?\n\nDSE recommendation: review availability and the recovery set together\nDSE 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.\nDefine 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.\nPrepare 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.\nConnect 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.\nVerification and evidence\nProposed 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.\nUnder 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.\nOfficial references\n\nAdminister and maintain a swarm of Docker Engines — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:26+00:00", "dateModified": "2026-10-30T06:05:14+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/plan-the-manager-stop-before-backing-up-swarm-state/" }, "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/plan-the-manager-stop-before-backing-up-swarm-state/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Plan the manager stop before backing up Swarm state" }, "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": 557, "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 — Administer and maintain a swarm of Docker Engines", "url": "https://docs.docker.com/engine/swarm/admin_guide/" } } ] } }