# Require the Proxmox Backup finish step before declaring API completion > The Proxmox Backup protocol commits data and verifies and persists its manifest at POST /finish; uploaded chunks and indexes are earlier states. - Canonical URL: https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:09:57+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know The Proxmox Backup protocol commits data and verifies and persists its manifest at POST /finish; uploaded chunks and indexes are earlier states. ## Potentially affected Custom clients using the documented Proxmox Backup Server backup protocol; ordinary product job behavior requires its own status evidence. ## DSE recommendation DSE recommends separate upload, index-close, manifest and finish states in a custom-client completion review. ## Article 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. ## Source fact: what the authority says The [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. ## What the source does not establish 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. ## Applicability questions - Which client implementation and server release are being assessed? - What expected blobs and index files belong in the selected backup? - How does the client distinguish upload progress from a successful finish result? - Where are client diagnostics retained when they are outside the manifest? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE 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. Use 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. Review 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. Keep 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. ## Verification and evidence Proposed 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. Use 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. ## Official references - [Proxmox Backup Server — Backup Protocol](https://pbs.proxmox.com/docs/backup-protocol.html) — official product documentation; confirm the installed release and configuration. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Proxmox Backup Server — Backup Protocol - Authority: pbs.proxmox.com - URL: https://pbs.proxmox.com/docs/backup-protocol.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Require the Proxmox Backup finish step before declaring API completion,” DSE Security, https://update.dsesecurity.com/updates/require-the-proxmox-backup-finish-step-before-declaring-api-completion/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.