Bottom line: Do not make the local dual-logging cache the assumed fallback for a remote logging outage. Define what records must remain available, where they must be retained and how an operator will recognize a gap in each destination.
\nThe Use docker logs with remote logging drivers documentation is the primary reference.
\nDocker Engine automatically enables dual logging when a configured driver cannot read logs, using the local driver as a cache for recent container logs. The limitations section says a remote-driver or plugin network issue results in no write to the local cache. It also says a failed logdriver write causes the cache write to fail, records the problem in the daemon log and does not retry the cache entry.
This article does not provide a durable buffering design or a lossless-delivery guarantee. It does not choose the workload’s blocking mode or change its retention requirements. Review those decisions separately, and do not interpret recent local output as proof that a remote destination received the same records.
\nDSE recommends writing the diagnostic and retention requirements before changing cache settings. Identify the users who need local recent output and those who need authoritative retained records. Give each requirement its intended destination and acceptance evidence rather than assigning both to a feature called a cache.
\nReview the actual driver, cache configuration and remote path with the logging owner. Keep container-to-driver delivery mode separate from the cache review. Ask what should happen during the failure being planned for and how the team will detect that condition without relying entirely on the affected stream.
\nPrepare a reconciliation method using harmless numbered records. Keep the generated sequence, local observations and destination observations separately attributable. Investigate any missing segment rather than accepting the newest visible record as evidence of continuous capture. Preserve daemon-side errors through the approved diagnostic process.
\nIf the requirement calls for retained outage records that this design does not establish, return that requirement to the responsible owner for a separately documented solution. Do not increase a cache limit and describe the problem as solved without exercising the relevant failure path. Keep application responsiveness, diagnostic availability and historical retention as distinct acceptance decisions.
\nProposed verification, not performed: use a disposable workload, approved remote destination and a small numbered sequence of nonessential messages. Record normal local and remote observations first. If authorized, introduce a bounded remote-path interruption and retain the resulting local, daemon and receiver observations separately.
\nAfter restoration, reconcile the sequence rather than assuming missing entries were replayed. Record the exact driver and cache settings, interruption window and actual gaps. Keep the application owner’s responsiveness check independent of record continuity. Do not reproduce disk exhaustion or remove write permissions on an important production host to demonstrate a documented limitation.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Do not make the local dual-logging cache the assumed fallback for a remote logging outage. Define what records must remain available, where they must be retained and how an operator will recognize a gap in each destination.\nSource fact: documented behavior\nThe Use docker logs with remote logging drivers documentation is the primary reference.\nDocker Engine automatically enables dual logging when a configured driver cannot read logs, using the local driver as a cache for recent container logs. The limitations section says a remote-driver or plugin network issue results in no write to the local cache. It also says a failed logdriver write causes the cache write to fail, records the problem in the daemon log and does not retry the cache entry.\nWhat the source does not establish\nThis article does not provide a durable buffering design or a lossless-delivery guarantee. It does not choose the workload’s blocking mode or change its retention requirements. Review those decisions separately, and do not interpret recent local output as proof that a remote destination received the same records.\nApplicability questions\n\nCan the configured driver read logs, or is dual logging supplying recent local access?\nWhich records must remain available through a remote-path interruption?\nHow will local, remote and daemon observations be reconciled?\nWhich approved alternative or recovery procedure addresses a missing-record requirement?\n\nDSE recommendation: state the failure requirement before the cache choice\nDSE recommends writing the diagnostic and retention requirements before changing cache settings. Identify the users who need local recent output and those who need authoritative retained records. Give each requirement its intended destination and acceptance evidence rather than assigning both to a feature called a cache.\nReview the actual driver, cache configuration and remote path with the logging owner. Keep container-to-driver delivery mode separate from the cache review. Ask what should happen during the failure being planned for and how the team will detect that condition without relying entirely on the affected stream.\nPrepare a reconciliation method using harmless numbered records. Keep the generated sequence, local observations and destination observations separately attributable. Investigate any missing segment rather than accepting the newest visible record as evidence of continuous capture. Preserve daemon-side errors through the approved diagnostic process.\nIf the requirement calls for retained outage records that this design does not establish, return that requirement to the responsible owner for a separately documented solution. Do not increase a cache limit and describe the problem as solved without exercising the relevant failure path. Keep application responsiveness, diagnostic availability and historical retention as distinct acceptance decisions.\nVerification and evidence\nProposed verification, not performed: use a disposable workload, approved remote destination and a small numbered sequence of nonessential messages. Record normal local and remote observations first. If authorized, introduce a bounded remote-path interruption and retain the resulting local, daemon and receiver observations separately.\nAfter restoration, reconcile the sequence rather than assuming missing entries were replayed. Record the exact driver and cache settings, interruption window and actual gaps. Keep the application owner’s responsiveness check independent of record continuity. Do not reproduce disk exhaustion or remove write permissions on an important production host to demonstrate a documented limitation.\nOfficial references\n\nUse docker logs with remote logging drivers — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Do not make the local dual-logging cache the assumed fallback for a remote logging outage. Define what records must remain available, where they must be retained and how an operator will recognize a gap in each destination.\n\n## Source fact: documented behavior\n\nThe [Use docker logs with remote logging drivers](https://docs.docker.com/engine/logging/dual-logging/) documentation is the primary reference.\n\nDocker Engine automatically enables dual logging when a configured driver cannot read logs, using the local driver as a cache for recent container logs. The limitations section says a remote-driver or plugin network issue results in no write to the local cache. It also says a failed logdriver write causes the cache write to fail, records the problem in the daemon log and does not retry the cache entry.\n\n## What the source does not establish\n\nThis article does not provide a durable buffering design or a lossless-delivery guarantee. It does not choose the workload’s blocking mode or change its retention requirements. Review those decisions separately, and do not interpret recent local output as proof that a remote destination received the same records.\n\n## Applicability questions\n\n- Can the configured driver read logs, or is dual logging supplying recent local access?\n\n- Which records must remain available through a remote-path interruption?\n\n- How will local, remote and daemon observations be reconciled?\n\n- Which approved alternative or recovery procedure addresses a missing-record requirement?\n\n## DSE recommendation: state the failure requirement before the cache choice\n\nDSE recommends writing the diagnostic and retention requirements before changing cache settings. Identify the users who need local recent output and those who need authoritative retained records. Give each requirement its intended destination and acceptance evidence rather than assigning both to a feature called a cache.\n\nReview the actual driver, cache configuration and remote path with the logging owner. Keep container-to-driver delivery mode separate from the cache review. Ask what should happen during the failure being planned for and how the team will detect that condition without relying entirely on the affected stream.\n\nPrepare a reconciliation method using harmless numbered records. Keep the generated sequence, local observations and destination observations separately attributable. Investigate any missing segment rather than accepting the newest visible record as evidence of continuous capture. Preserve daemon-side errors through the approved diagnostic process.\n\nIf the requirement calls for retained outage records that this design does not establish, return that requirement to the responsible owner for a separately documented solution. Do not increase a cache limit and describe the problem as solved without exercising the relevant failure path. Keep application responsiveness, diagnostic availability and historical retention as distinct acceptance decisions.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable workload, approved remote destination and a small numbered sequence of nonessential messages. Record normal local and remote observations first. If authorized, introduce a bounded remote-path interruption and retain the resulting local, daemon and receiver observations separately.\n\nAfter restoration, reconcile the sequence rather than assuming missing entries were replayed. Record the exact driver and cache settings, interruption window and actual gaps. Keep the application owner’s responsiveness check independent of record continuity. Do not reproduce disk exhaustion or remove write permissions on an important production host to demonstrate a documented limitation.\n\n## Official references\n\n- [Use docker logs with remote logging drivers](https://docs.docker.com/engine/logging/dual-logging/) — Docker Docs.\n\nSource review completed October 29, 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/keep-docker-dual-logging-separate-from-an-outage-spool/", "url": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/#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": "Keep Docker dual logging separate from an outage spool", "item": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/#article", "identifier": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/", "url": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/", "headline": "Keep Docker dual logging separate from an outage spool", "description": "Docker documents cases where remote-driver failure prevents a local dual-logging cache write.", "abstract": "Docker documents cases where remote-driver failure prevents a local dual-logging cache write. Review the cache as recent-log access, not assumed retention during a remote-path outage.", "articleBody": "Bottom line: Do not make the local dual-logging cache the assumed fallback for a remote logging outage. Define what records must remain available, where they must be retained and how an operator will recognize a gap in each destination.\nSource fact: documented behavior\nThe Use docker logs with remote logging drivers documentation is the primary reference.\nDocker Engine automatically enables dual logging when a configured driver cannot read logs, using the local driver as a cache for recent container logs. The limitations section says a remote-driver or plugin network issue results in no write to the local cache. It also says a failed logdriver write causes the cache write to fail, records the problem in the daemon log and does not retry the cache entry.\nWhat the source does not establish\nThis article does not provide a durable buffering design or a lossless-delivery guarantee. It does not choose the workload’s blocking mode or change its retention requirements. Review those decisions separately, and do not interpret recent local output as proof that a remote destination received the same records.\nApplicability questions\n\nCan the configured driver read logs, or is dual logging supplying recent local access?\nWhich records must remain available through a remote-path interruption?\nHow will local, remote and daemon observations be reconciled?\nWhich approved alternative or recovery procedure addresses a missing-record requirement?\n\nDSE recommendation: state the failure requirement before the cache choice\nDSE recommends writing the diagnostic and retention requirements before changing cache settings. Identify the users who need local recent output and those who need authoritative retained records. Give each requirement its intended destination and acceptance evidence rather than assigning both to a feature called a cache.\nReview the actual driver, cache configuration and remote path with the logging owner. Keep container-to-driver delivery mode separate from the cache review. Ask what should happen during the failure being planned for and how the team will detect that condition without relying entirely on the affected stream.\nPrepare a reconciliation method using harmless numbered records. Keep the generated sequence, local observations and destination observations separately attributable. Investigate any missing segment rather than accepting the newest visible record as evidence of continuous capture. Preserve daemon-side errors through the approved diagnostic process.\nIf the requirement calls for retained outage records that this design does not establish, return that requirement to the responsible owner for a separately documented solution. Do not increase a cache limit and describe the problem as solved without exercising the relevant failure path. Keep application responsiveness, diagnostic availability and historical retention as distinct acceptance decisions.\nVerification and evidence\nProposed verification, not performed: use a disposable workload, approved remote destination and a small numbered sequence of nonessential messages. Record normal local and remote observations first. If authorized, introduce a bounded remote-path interruption and retain the resulting local, daemon and receiver observations separately.\nAfter restoration, reconcile the sequence rather than assuming missing entries were replayed. Record the exact driver and cache settings, interruption window and actual gaps. Keep the application owner’s responsiveness check independent of record continuity. Do not reproduce disk exhaustion or remove write permissions on an important production host to demonstrate a documented limitation.\nOfficial references\n\nUse docker logs with remote logging drivers — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:40:45+00:00", "dateModified": "2026-10-29T17:41:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-docker-dual-logging-separate-from-an-outage-spool/" }, "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/keep-docker-dual-logging-separate-from-an-outage-spool/#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": "Keep Docker dual logging separate from an outage spool" }, "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": 549, "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 — Use docker logs with remote logging drivers", "url": "https://docs.docker.com/engine/logging/dual-logging/" } } ] } }