Bottom line: Give protocol finalization its own completion condition when reviewing a custom Proxmox Backup client. Keep uploaded data, closed indexes, the manifest and the finish response distinguishable so an interrupted upload is not presented as a completed backup.
\nThe Proxmox Backup protocol reference allows blobs, fixed indexes and dynamic indexes to be uploaded through the backup protocol. It requires uploaded blobs and index files to be added to the manifest, uploaded as index.json.blob before POST /finish. The finish call commits the data, verifies and persists the manifest, and ends the backup protocol. The reference distinguishes blobs uploaded outside the backup protocol, such as client logs, as not tracked by that manifest.
This article concerns the documented custom-client protocol sequence. It does not prove a workload’s application consistency, recoverability or complete diagnostic retention. DSE keeps ordinary product job acceptance separate from this client-implementation review and does not infer completion from transferred byte counts alone.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a state model for the custom client before changing its dashboard or wrapper. Name the expected data and indexes, their close state, manifest submission and finish result. Record the evidence required to leave each state. Ask another implementer to identify which state an interrupted session can honestly report without inferring the next step.
\nUse two proposed disposable-client cases: one completing the documented sequence and one interrupted before finalization. Keep both on harmless data in an isolated or approved test datastore. Define the reporting expectation before the exercise: the interrupted case must remain distinguishable from a positively observed finish. Do not invent a supported abort or repair command from the protocol overview.
\nReview diagnostic custody independently of the backup manifest. Decide which client logs are needed to investigate an incomplete attempt and where authorized responders will find them. Keep credentials and sensitive payload details out of ordinary status records. Avoid marking an interrupted attempt successful merely because a log exists or every expected upload was requested.
\nKeep the proposed interruption point explicit in the test record. Ask the operator to name the last confirmed protocol state before reading the dashboard. Preserve any mismatch as an implementation finding rather than editing the expected result to match the displayed completion label.
\nProposed verification: observe the complete client sequence with identifiers for the submitted files, index-close steps, manifest and finish response. Compare the reporting state with the actual recorded transitions. For the interruption case, retain the last positively observed step and check that downstream reporting does not advance it to completion.
\nUse the applicable official reader or recovery procedure for a separately approved limited restoration check of the completed test backup. Compare representative restored data with the harmless source fixture and record the actual result. Preserve protocol evidence and client diagnostics as separately identified artifacts. Escalate inconsistent state rather than declaring success from a convenient progress percentage.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Give protocol finalization its own completion condition when reviewing a custom Proxmox Backup client. Keep uploaded data, closed indexes, the manifest and the finish response distinguishable so an interrupted upload is not presented as a completed backup.\nSource fact: what the authority says\nThe Proxmox Backup protocol reference allows blobs, fixed indexes and dynamic indexes to be uploaded through the backup protocol. It requires uploaded blobs and index files to be added to the manifest, uploaded as index.json.blob before POST /finish. The finish call commits the data, verifies and persists the manifest, and ends the backup protocol. The reference distinguishes blobs uploaded outside the backup protocol, such as client logs, as not tracked by that manifest.\nWhat the source does not establish\nThis article concerns the documented custom-client protocol sequence. It does not prove a workload’s application consistency, recoverability or complete diagnostic retention. DSE keeps ordinary product job acceptance separate from this client-implementation review and does not infer completion from transferred byte counts alone.\nApplicability questions\n\nWhich client implementation and server release are being assessed?\nWhat expected blobs and index files belong in the selected backup?\nHow does the client distinguish upload progress from a successful finish result?\nWhere are client diagnostics retained when they are outside the manifest?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a state model for the custom client before changing its dashboard or wrapper. Name the expected data and indexes, their close state, manifest submission and finish result. Record the evidence required to leave each state. Ask another implementer to identify which state an interrupted session can honestly report without inferring the next step.\nUse two proposed disposable-client cases: one completing the documented sequence and one interrupted before finalization. Keep both on harmless data in an isolated or approved test datastore. Define the reporting expectation before the exercise: the interrupted case must remain distinguishable from a positively observed finish. Do not invent a supported abort or repair command from the protocol overview.\nReview diagnostic custody independently of the backup manifest. Decide which client logs are needed to investigate an incomplete attempt and where authorized responders will find them. Keep credentials and sensitive payload details out of ordinary status records. Avoid marking an interrupted attempt successful merely because a log exists or every expected upload was requested.\nKeep the proposed interruption point explicit in the test record. Ask the operator to name the last confirmed protocol state before reading the dashboard. Preserve any mismatch as an implementation finding rather than editing the expected result to match the displayed completion label.\nVerification and evidence\nProposed verification: observe the complete client sequence with identifiers for the submitted files, index-close steps, manifest and finish response. Compare the reporting state with the actual recorded transitions. For the interruption case, retain the last positively observed step and check that downstream reporting does not advance it to completion.\nUse the applicable official reader or recovery procedure for a separately approved limited restoration check of the completed test backup. Compare representative restored data with the harmless source fixture and record the actual result. Preserve protocol evidence and client diagnostics as separately identified artifacts. Escalate inconsistent state rather than declaring success from a convenient progress percentage.\nOfficial references\n\nProxmox Backup Server — Backup Protocol — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Give protocol finalization its own completion condition when reviewing a custom Proxmox Backup client. Keep uploaded data, closed indexes, the manifest and the finish response distinguishable so an interrupted upload is not presented as a completed backup.\n\n## Source fact: what the authority says\n\nThe [Proxmox Backup protocol reference](https://pbs.proxmox.com/docs/backup-protocol.html) allows blobs, fixed indexes and dynamic indexes to be uploaded through the backup protocol. It requires uploaded blobs and index files to be added to the manifest, uploaded as index.json.blob before POST /finish. The finish call commits the data, verifies and persists the manifest, and ends the backup protocol. The reference distinguishes blobs uploaded outside the backup protocol, such as client logs, as not tracked by that manifest.\n\n## What the source does not establish\n\nThis article concerns the documented custom-client protocol sequence. It does not prove a workload’s application consistency, recoverability or complete diagnostic retention. DSE keeps ordinary product job acceptance separate from this client-implementation review and does not infer completion from transferred byte counts alone.\n\n## Applicability questions\n\n- Which client implementation and server release are being assessed?\n\n- What expected blobs and index files belong in the selected backup?\n\n- How does the client distinguish upload progress from a successful finish result?\n\n- Where are client diagnostics retained when they are outside the manifest?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a state model for the custom client before changing its dashboard or wrapper. Name the expected data and indexes, their close state, manifest submission and finish result. Record the evidence required to leave each state. Ask another implementer to identify which state an interrupted session can honestly report without inferring the next step.\n\nUse two proposed disposable-client cases: one completing the documented sequence and one interrupted before finalization. Keep both on harmless data in an isolated or approved test datastore. Define the reporting expectation before the exercise: the interrupted case must remain distinguishable from a positively observed finish. Do not invent a supported abort or repair command from the protocol overview.\n\nReview diagnostic custody independently of the backup manifest. Decide which client logs are needed to investigate an incomplete attempt and where authorized responders will find them. Keep credentials and sensitive payload details out of ordinary status records. Avoid marking an interrupted attempt successful merely because a log exists or every expected upload was requested.\n\nKeep the proposed interruption point explicit in the test record. Ask the operator to name the last confirmed protocol state before reading the dashboard. Preserve any mismatch as an implementation finding rather than editing the expected result to match the displayed completion label.\n\n## Verification and evidence\n\nProposed verification: observe the complete client sequence with identifiers for the submitted files, index-close steps, manifest and finish response. Compare the reporting state with the actual recorded transitions. For the interruption case, retain the last positively observed step and check that downstream reporting does not advance it to completion.\n\nUse the applicable official reader or recovery procedure for a separately approved limited restoration check of the completed test backup. Compare representative restored data with the harmless source fixture and record the actual result. Preserve protocol evidence and client diagnostics as separately identified artifacts. Escalate inconsistent state rather than declaring success from a convenient progress percentage.\n\n## Official references\n\n- [Proxmox Backup Server — Backup Protocol](https://pbs.proxmox.com/docs/backup-protocol.html) — official product documentation; confirm the installed release and configuration.\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/require-the-proxmox-backup-finish-step-before-declaring-api-completion/", "url": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/#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": "Require the Proxmox Backup finish step before declaring API completion", "item": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/#article", "identifier": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/", "url": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/", "headline": "Require the Proxmox Backup finish step before declaring API completion", "description": "The Proxmox Backup protocol commits data and verifies and persists its manifest at POST /finish; uploaded chunks and indexes are earlier states.", "abstract": "The Proxmox Backup protocol commits data and verifies and persists its manifest at POST /finish; uploaded chunks and indexes are earlier states.", "articleBody": "Bottom line: Give protocol finalization its own completion condition when reviewing a custom Proxmox Backup client. Keep uploaded data, closed indexes, the manifest and the finish response distinguishable so an interrupted upload is not presented as a completed backup.\nSource fact: what the authority says\nThe Proxmox Backup protocol reference allows blobs, fixed indexes and dynamic indexes to be uploaded through the backup protocol. It requires uploaded blobs and index files to be added to the manifest, uploaded as index.json.blob before POST /finish. The finish call commits the data, verifies and persists the manifest, and ends the backup protocol. The reference distinguishes blobs uploaded outside the backup protocol, such as client logs, as not tracked by that manifest.\nWhat the source does not establish\nThis article concerns the documented custom-client protocol sequence. It does not prove a workload’s application consistency, recoverability or complete diagnostic retention. DSE keeps ordinary product job acceptance separate from this client-implementation review and does not infer completion from transferred byte counts alone.\nApplicability questions\n\nWhich client implementation and server release are being assessed?\nWhat expected blobs and index files belong in the selected backup?\nHow does the client distinguish upload progress from a successful finish result?\nWhere are client diagnostics retained when they are outside the manifest?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a state model for the custom client before changing its dashboard or wrapper. Name the expected data and indexes, their close state, manifest submission and finish result. Record the evidence required to leave each state. Ask another implementer to identify which state an interrupted session can honestly report without inferring the next step.\nUse two proposed disposable-client cases: one completing the documented sequence and one interrupted before finalization. Keep both on harmless data in an isolated or approved test datastore. Define the reporting expectation before the exercise: the interrupted case must remain distinguishable from a positively observed finish. Do not invent a supported abort or repair command from the protocol overview.\nReview diagnostic custody independently of the backup manifest. Decide which client logs are needed to investigate an incomplete attempt and where authorized responders will find them. Keep credentials and sensitive payload details out of ordinary status records. Avoid marking an interrupted attempt successful merely because a log exists or every expected upload was requested.\nKeep the proposed interruption point explicit in the test record. Ask the operator to name the last confirmed protocol state before reading the dashboard. Preserve any mismatch as an implementation finding rather than editing the expected result to match the displayed completion label.\nVerification and evidence\nProposed verification: observe the complete client sequence with identifiers for the submitted files, index-close steps, manifest and finish response. Compare the reporting state with the actual recorded transitions. For the interruption case, retain the last positively observed step and check that downstream reporting does not advance it to completion.\nUse the applicable official reader or recovery procedure for a separately approved limited restoration check of the completed test backup. Compare representative restored data with the harmless source fixture and record the actual result. Preserve protocol evidence and client diagnostics as separately identified artifacts. Escalate inconsistent state rather than declaring success from a convenient progress percentage.\nOfficial references\n\nProxmox Backup Server — Backup Protocol — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:09:57+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/" }, "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/require-the-proxmox-backup-finish-step-before-declaring-api-completion/#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": "Require the Proxmox Backup finish step before declaring API completion" }, "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": 579, "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": "Proxmox Backup Server — Backup Protocol", "url": "https://pbs.proxmox.com/docs/backup-protocol.html" } } ] } }