From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 128FC1FF0B3 for ; Wed, 11 Nov 2026 16:41:07 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 89481216A1; Wed, 11 Nov 2026 16:40:59 +0100 (CET) Message-ID: <8d597954-b22c-41f2-a1ba-5e95a05cea98@proxmox.com> Date: Wed, 11 Nov 2026 16:40:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH docs/guest-common/manager v2 0/4] fix #6464: backup: add backup retry strategies To: Jakob Klocker , pve-devel@lists.proxmox.com References: <20261111093407.109872-1-j.klocker@proxmox.com> Content-Language: en-US From: Jonas Theisen In-Reply-To: <20261111093407.109872-1-j.klocker@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1794411647137 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.093 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NZG4YUB6V6K4ARLWQWN2CFYI4EV5FVYM X-Message-ID-Hash: NZG4YUB6V6K4ARLWQWN2CFYI4EV5FVYM X-MailFrom: j.theisen@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 11/11/26 10:35, Jakob Klocker wrote: > > > If a guest succeeds on a retry, it is reported as successful in the > notification and no error is counted. If it still fails after the last > retry, the job finishes with errors as before. Task logging has been > switched to append mode so the log contains the complete transcript of > all attempts. I personally would prefer if a transient failure would still be reported as a warning. Retries are good to not miss the backup completely but it still in most cases means something is wrong. > I kept the retry options in the advanced tab of the backup job window, > but I'm not sure whether they should be moved to the general tab. > Opinions on this are appreciated. A more general issue is the combination of retries with the --stdout parameter, where the tar gets written to a stdout instead of a file. The resulting stream gets corrupted by a retry so probably the CLI should just bail in that combination. > > Testing info: > When testing I'd suggest to fail the backup by locking and > unlocking the guest with following commands: > `qm set -lock backup` > `qm unlock ` I also tested this in combination with an unreachable PBS by just yanking out the connection on the PBS side. This caused the backup task to fail even before the retries since it could not activate the storage. Since i assume this is one of the more common failure modes i think that should be covered by a retry. >