{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
        "slug": "keep-borg-repository-checking-separate-from-lossy-repair-mode",
        "url": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/keep-borg-repository-checking-separate-from-lossy-repair-mode/"
        },
        "title": "Keep Borg repository checking separate from lossy repair mode",
        "summary": "Preserve read-only Borg findings and an independent copy before considering repair.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "continuity-recovery",
            "label": "Continuity & recovery",
            "alt": "Paired infrastructure paths converging on a stable recovered service.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "business-continuity",
                "name": "Business Continuity",
                "url": "https://update.dsesecurity.com/topic/business-continuity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-15T13:33:01+00:00",
        "modified_at": "2026-10-15T13:36:16+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 252,
        "potentially_affected": "This applies to Borg 1.4.5 repository integrity checking. It addresses the difference between observation, data verification, and repair, not the separate manifest verification used for PostgreSQL base backups.",
        "dse_recommendation": "DSE recommends saving the read-only findings and the exact command mode before discussing repair.",
        "primary_source": {
            "name": "Borg 1.4.5 — borg check",
            "url": "https://borgbackup.readthedocs.io/en/stable/usage/check.html",
            "published_on": null,
            "authority": "borgbackup.readthedocs.io"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Preserve read-only Borg findings and an independent copy before considering repair.</p>\n<h2>Source facts</h2>\n<p>Borg 1.4.5 check is read-only by default and reports discovered corruption without repairing it. Adding repair changes that behavior and can sacrifice data, including additional data affected by corruption the repair cannot handle. The documentation recommends backing up the repository before repair. Repair cannot recreate data that no longer exists. Data verification is also distinct from checking only repository structure; verify-data cannot be combined with repository-only. A check result therefore needs its exact mode attached.</p>\n<p>Source: <a href=\"https://borgbackup.readthedocs.io/en/stable/usage/check.html\">Borg 1.4.5 — borg check</a>.</p>\n<h2>Applicability</h2>\n<p>This applies to Borg 1.4.5 repository integrity checking. It addresses the difference between observation, data verification, and repair, not the separate manifest verification used for PostgreSQL base backups.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends saving the read-only findings and the exact command mode before discussing repair. Have the backup owner identify independent recovery copies and obtain a storage diagnosis where hardware is suspect. Review any repair as a change with a known loss risk and a preserved pre-repair repository, rather than adding the option to make a scheduled check pass. Keep the original error report available for later comparison, including which archives or chunks were affected.</p>\n<h2>Verification</h2>\n<p>On an expendable repository copy, confirm that routine checking leaves the repository unchanged and that the selected mode examines the intended data. Rehearse the review and preservation steps before any repair experiment. Validate restored files afterward and record losses explicitly instead of equating repository consistency with complete content recovery.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://borgbackup.readthedocs.io/en/stable/usage/check.html\">Borg 1.4.5 — borg check</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Preserve read-only Borg findings and an independent copy before considering repair.\nSource facts\nBorg 1.4.5 check is read-only by default and reports discovered corruption without repairing it. Adding repair changes that behavior and can sacrifice data, including additional data affected by corruption the repair cannot handle. The documentation recommends backing up the repository before repair. Repair cannot recreate data that no longer exists. Data verification is also distinct from checking only repository structure; verify-data cannot be combined with repository-only. A check result therefore needs its exact mode attached.\nSource: Borg 1.4.5 — borg check.\nApplicability\nThis applies to Borg 1.4.5 repository integrity checking. It addresses the difference between observation, data verification, and repair, not the separate manifest verification used for PostgreSQL base backups.\nDSE recommendation\nDSE recommends saving the read-only findings and the exact command mode before discussing repair. Have the backup owner identify independent recovery copies and obtain a storage diagnosis where hardware is suspect. Review any repair as a change with a known loss risk and a preserved pre-repair repository, rather than adding the option to make a scheduled check pass. Keep the original error report available for later comparison, including which archives or chunks were affected.\nVerification\nOn an expendable repository copy, confirm that routine checking leaves the repository unchanged and that the selected mode examines the intended data. Rehearse the review and preservation steps before any repair experiment. Validate restored files afterward and record losses explicitly instead of equating repository consistency with complete content recovery.\nOfficial reference\nBorg 1.4.5 — borg check. Reviewed October 15, 2026.",
        "content_markdown": "Preserve read-only Borg findings and an independent copy before considering repair.\n\n## Source facts\n\nBorg 1.4.5 check is read-only by default and reports discovered corruption without repairing it. Adding repair changes that behavior and can sacrifice data, including additional data affected by corruption the repair cannot handle. The documentation recommends backing up the repository before repair. Repair cannot recreate data that no longer exists. Data verification is also distinct from checking only repository structure; verify-data cannot be combined with repository-only. A check result therefore needs its exact mode attached.\n\nSource: [Borg 1.4.5 — borg check](https://borgbackup.readthedocs.io/en/stable/usage/check.html).\n\n## Applicability\n\nThis applies to Borg 1.4.5 repository integrity checking. It addresses the difference between observation, data verification, and repair, not the separate manifest verification used for PostgreSQL base backups.\n\n## DSE recommendation\n\nDSE recommends saving the read-only findings and the exact command mode before discussing repair. Have the backup owner identify independent recovery copies and obtain a storage diagnosis where hardware is suspect. Review any repair as a change with a known loss risk and a preserved pre-repair repository, rather than adding the option to make a scheduled check pass. Keep the original error report available for later comparison, including which archives or chunks were affected.\n\n## Verification\n\nOn an expendable repository copy, confirm that routine checking leaves the repository unchanged and that the selected mode examines the intended data. Rehearse the review and preservation steps before any repair experiment. Validate restored files afterward and record losses explicitly instead of equating repository consistency with complete content recovery.\n\n## Official reference\n\n[Borg 1.4.5 — borg check](https://borgbackup.readthedocs.io/en/stable/usage/check.html). Reviewed October 15, 2026."
    },
    "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-borg-repository-checking-separate-from-lossy-repair-mode/",
                "url": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Keep Borg repository checking separate from lossy repair mode",
                        "item": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/#article",
                "identifier": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
                "url": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/",
                "headline": "Keep Borg repository checking separate from lossy repair mode",
                "description": "Preserve read-only Borg findings and an independent copy before considering repair.",
                "abstract": "Preserve read-only Borg findings and an independent copy before considering repair.",
                "articleBody": "Preserve read-only Borg findings and an independent copy before considering repair.\nSource facts\nBorg 1.4.5 check is read-only by default and reports discovered corruption without repairing it. Adding repair changes that behavior and can sacrifice data, including additional data affected by corruption the repair cannot handle. The documentation recommends backing up the repository before repair. Repair cannot recreate data that no longer exists. Data verification is also distinct from checking only repository structure; verify-data cannot be combined with repository-only. A check result therefore needs its exact mode attached.\nSource: Borg 1.4.5 — borg check.\nApplicability\nThis applies to Borg 1.4.5 repository integrity checking. It addresses the difference between observation, data verification, and repair, not the separate manifest verification used for PostgreSQL base backups.\nDSE recommendation\nDSE recommends saving the read-only findings and the exact command mode before discussing repair. Have the backup owner identify independent recovery copies and obtain a storage diagnosis where hardware is suspect. Review any repair as a change with a known loss risk and a preserved pre-repair repository, rather than adding the option to make a scheduled check pass. Keep the original error report available for later comparison, including which archives or chunks were affected.\nVerification\nOn an expendable repository copy, confirm that routine checking leaves the repository unchanged and that the selected mode examines the intended data. Rehearse the review and preservation steps before any repair experiment. Validate restored files afterward and record losses explicitly instead of equating repository consistency with complete content recovery.\nOfficial reference\nBorg 1.4.5 — borg check. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:33:01+00:00",
                "dateModified": "2026-10-15T13:36:16+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/keep-borg-repository-checking-separate-from-lossy-repair-mode/"
                },
                "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-borg-repository-checking-separate-from-lossy-repair-mode/#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 Borg repository checking separate from lossy repair mode"
                },
                "articleSection": [
                    "Business Continuity",
                    "IT"
                ],
                "keywords": [
                    "Business Continuity",
                    "IT",
                    "Guide",
                    "Information 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": 252,
                "timeRequired": "PT2M",
                "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": "Borg 1.4.5 — borg check",
                    "url": "https://borgbackup.readthedocs.io/en/stable/usage/check.html"
                }
            }
        ]
    }
}