Bottom line: DSE recommendation: decide how a scheduled backup job will report an unsuccessful or unrecognized result before using its run history as operational evidence. Keep that decision separate from which files were selected and whether a recovery exercise has passed.
\nThe restic scripting guide identifies version 0.19.1. Its general table defines zero as success. For backup, code 3 means some source data could not be read; for forget, it means one or more snapshots could not be removed. Unknown exit codes must be treated as failure, with command-specific help providing further detail.
\nThis table is not proof that a particular job protected the intended files, produced an application-consistent recovery point or can restore a service. This article does not certify a wrapper, scheduler or installed client. Treat those as separate review subjects and retain uncertainty when the observed result cannot be explained.
\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.
\nBuild the classification around the exact operation, not a green status shared by all jobs. In the review sheet, give the backup and forget cases their own names, command identifiers and reviewed source meanings. Keep the recorded exit status next to the operation so the interpretation can be checked.
\nAsk the reviewer to explain two status-3 records without relying on a generic label. Which one reports unreadable source data, and which one reports unsuccessful snapshot removal? Require that distinction to survive the scheduler, dashboard and notification handoffs. Keep secrets and sensitive file names out of the shared comparison.
\nGive an unknown result a separate non-success route with a named investigator. Preserve the native status and redacted diagnostics before other wrapper steps. Decide retry or recovery policy separately; neither is established by this general code table. Keep a missing run distinct from a completed run with an unsuccessful result.
\nProposed verification, not a performed test: define BACKUP-READ for a genuine backup status 3 and FORGET-REMOVE for a genuine forget status 3. Obtain either result only in a disposable, nonsensitive exercise where the condition can be safely reproduced; otherwise mark it untested. Compare each with its command-specific meaning above, without asserting that a snapshot was created.
\nDefine UNKNOWN-RESULT as a synthetic status absent from the reviewed table, injected at the wrapper boundary. Require its downstream record to remain non-success and identify the injection clearly. Retain the invocation, native or injected value, classification and attended notification. Ask another operator to trace all three records through each handoff; assess backup scope and restoration evidence separately.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: DSE recommendation: decide how a scheduled backup job will report an unsuccessful or unrecognized result before using its run history as operational evidence. Keep that decision separate from which files were selected and whether a recovery exercise has passed.\nSource fact: what the authority says\nThe restic scripting guide identifies version 0.19.1. Its general table defines zero as success. For backup, code 3 means some source data could not be read; for forget, it means one or more snapshots could not be removed. Unknown exit codes must be treated as failure, with command-specific help providing further detail.\nWhat the source does not establish\nThis table is not proof that a particular job protected the intended files, produced an application-consistent recovery point or can restore a service. This article does not certify a wrapper, scheduler or installed client. Treat those as separate review subjects and retain uncertainty when the observed result cannot be explained.\nApplicability questions\n\nWhich client version and exact command will the job execute, and who owns changes to that combination?\nDoes the wrapper preserve the process result before running another command, and what will its attended recipient call non-success?\nWhere will an unexpected code, interrupted run or missing completion record be investigated?\nWhich separate evidence will establish backup scope and recoverability rather than merely process completion?\n\nDSE recommendation: controlled next steps\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\nBuild the classification around the exact operation, not a green status shared by all jobs. In the review sheet, give the backup and forget cases their own names, command identifiers and reviewed source meanings. Keep the recorded exit status next to the operation so the interpretation can be checked.\nAsk the reviewer to explain two status-3 records without relying on a generic label. Which one reports unreadable source data, and which one reports unsuccessful snapshot removal? Require that distinction to survive the scheduler, dashboard and notification handoffs. Keep secrets and sensitive file names out of the shared comparison.\nGive an unknown result a separate non-success route with a named investigator. Preserve the native status and redacted diagnostics before other wrapper steps. Decide retry or recovery policy separately; neither is established by this general code table. Keep a missing run distinct from a completed run with an unsuccessful result.\nVerification and evidence\nProposed verification, not a performed test: define BACKUP-READ for a genuine backup status 3 and FORGET-REMOVE for a genuine forget status 3. Obtain either result only in a disposable, nonsensitive exercise where the condition can be safely reproduced; otherwise mark it untested. Compare each with its command-specific meaning above, without asserting that a snapshot was created.\nDefine UNKNOWN-RESULT as a synthetic status absent from the reviewed table, injected at the wrapper boundary. Require its downstream record to remain non-success and identify the injection clearly. Retain the invocation, native or injected value, classification and attended notification. Ask another operator to trace all three records through each handoff; assess backup scope and restoration evidence separately.\nOfficial references\n\nrestic 0.19.1 — Scripting — official product documentation; source version and applicability limits are stated above.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: DSE recommendation: decide how a scheduled backup job will report an unsuccessful or unrecognized result before using its run history as operational evidence. Keep that decision separate from which files were selected and whether a recovery exercise has passed.\n\n## Source fact: what the authority says\n\nThe [restic scripting guide](https://restic.readthedocs.io/en/stable/075_scripting.html) identifies version 0.19.1. Its general table defines zero as success. For backup, code 3 means some source data could not be read; for forget, it means one or more snapshots could not be removed. Unknown exit codes must be treated as failure, with command-specific help providing further detail.\n\n## What the source does not establish\n\nThis table is not proof that a particular job protected the intended files, produced an application-consistent recovery point or can restore a service. This article does not certify a wrapper, scheduler or installed client. Treat those as separate review subjects and retain uncertainty when the observed result cannot be explained.\n\n## Applicability questions\n\n- Which client version and exact command will the job execute, and who owns changes to that combination?\n\n- Does the wrapper preserve the process result before running another command, and what will its attended recipient call non-success?\n\n- Where will an unexpected code, interrupted run or missing completion record be investigated?\n\n- Which separate evidence will establish backup scope and recoverability rather than merely process completion?\n\n## DSE recommendation: controlled next steps\n\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\n\nBuild the classification around the exact operation, not a green status shared by all jobs. In the review sheet, give the backup and forget cases their own names, command identifiers and reviewed source meanings. Keep the recorded exit status next to the operation so the interpretation can be checked.\n\nAsk the reviewer to explain two status-3 records without relying on a generic label. Which one reports unreadable source data, and which one reports unsuccessful snapshot removal? Require that distinction to survive the scheduler, dashboard and notification handoffs. Keep secrets and sensitive file names out of the shared comparison.\n\nGive an unknown result a separate non-success route with a named investigator. Preserve the native status and redacted diagnostics before other wrapper steps. Decide retry or recovery policy separately; neither is established by this general code table. Keep a missing run distinct from a completed run with an unsuccessful result.\n\n## Verification and evidence\n\nProposed verification, not a performed test: define BACKUP-READ for a genuine backup status 3 and FORGET-REMOVE for a genuine forget status 3. Obtain either result only in a disposable, nonsensitive exercise where the condition can be safely reproduced; otherwise mark it untested. Compare each with its command-specific meaning above, without asserting that a snapshot was created.\n\nDefine UNKNOWN-RESULT as a synthetic status absent from the reviewed table, injected at the wrapper boundary. Require its downstream record to remain non-success and identify the injection clearly. Retain the invocation, native or injected value, classification and attended notification. Ask another operator to trace all three records through each handoff; assess backup scope and restoration evidence separately.\n\n## Official references\n\n- [restic 0.19.1 — Scripting](https://restic.readthedocs.io/en/stable/075_scripting.html) — official product documentation; source version and applicability limits are stated above.\n\nSource review completed October 28, 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/classify-restic-job-failures-from-the-documented-exit-status/", "url": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/#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": "Classify restic job failures from the documented exit status", "item": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/#article", "identifier": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/", "url": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/", "headline": "Classify restic job failures from the documented exit status", "description": "The restic 0.19.1 scripting guide requires unknown exit codes to be treated as failure; review the job result separately from backup scope and recovery…", "abstract": "The restic 0.19.1 scripting guide requires unknown exit codes to be treated as failure; review the job result separately from backup scope and recovery evidence.", "articleBody": "Bottom line: DSE recommendation: decide how a scheduled backup job will report an unsuccessful or unrecognized result before using its run history as operational evidence. Keep that decision separate from which files were selected and whether a recovery exercise has passed.\nSource fact: what the authority says\nThe restic scripting guide identifies version 0.19.1. Its general table defines zero as success. For backup, code 3 means some source data could not be read; for forget, it means one or more snapshots could not be removed. Unknown exit codes must be treated as failure, with command-specific help providing further detail.\nWhat the source does not establish\nThis table is not proof that a particular job protected the intended files, produced an application-consistent recovery point or can restore a service. This article does not certify a wrapper, scheduler or installed client. Treat those as separate review subjects and retain uncertainty when the observed result cannot be explained.\nApplicability questions\n\nWhich client version and exact command will the job execute, and who owns changes to that combination?\nDoes the wrapper preserve the process result before running another command, and what will its attended recipient call non-success?\nWhere will an unexpected code, interrupted run or missing completion record be investigated?\nWhich separate evidence will establish backup scope and recoverability rather than merely process completion?\n\nDSE recommendation: controlled next steps\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\nBuild the classification around the exact operation, not a green status shared by all jobs. In the review sheet, give the backup and forget cases their own names, command identifiers and reviewed source meanings. Keep the recorded exit status next to the operation so the interpretation can be checked.\nAsk the reviewer to explain two status-3 records without relying on a generic label. Which one reports unreadable source data, and which one reports unsuccessful snapshot removal? Require that distinction to survive the scheduler, dashboard and notification handoffs. Keep secrets and sensitive file names out of the shared comparison.\nGive an unknown result a separate non-success route with a named investigator. Preserve the native status and redacted diagnostics before other wrapper steps. Decide retry or recovery policy separately; neither is established by this general code table. Keep a missing run distinct from a completed run with an unsuccessful result.\nVerification and evidence\nProposed verification, not a performed test: define BACKUP-READ for a genuine backup status 3 and FORGET-REMOVE for a genuine forget status 3. Obtain either result only in a disposable, nonsensitive exercise where the condition can be safely reproduced; otherwise mark it untested. Compare each with its command-specific meaning above, without asserting that a snapshot was created.\nDefine UNKNOWN-RESULT as a synthetic status absent from the reviewed table, injected at the wrapper boundary. Require its downstream record to remain non-success and identify the injection clearly. Retain the invocation, native or injected value, classification and attended notification. Ask another operator to trace all three records through each handoff; assess backup scope and restoration evidence separately.\nOfficial references\n\nrestic 0.19.1 — Scripting — official product documentation; source version and applicability limits are stated above.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-28T23:23:25+00:00", "dateModified": "2026-10-28T23:23:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/classify-restic-job-failures-from-the-documented-exit-status/" }, "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/classify-restic-job-failures-from-the-documented-exit-status/#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": "Classify restic job failures from the documented exit status" }, "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": 528, "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": "restic 0.19.1 — Scripting", "url": "https://restic.readthedocs.io/en/stable/075_scripting.html" } } ] } }