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 0971A1FF0B4 for ; Tue, 10 Nov 2026 16:52:53 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id B504721608; Tue, 10 Nov 2026 16:52:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stuttgart.de; s=s1022; t=1794325432; bh=XJvKW2jqGetnODzK7hUHwVpKFpJ7YtEBd3MFUZVF/4k=; h=Date:Subject:To:References:From:In-Reply-To:From; b=OeEOucaUxT3LVqSla97/uPFSGlsfof0xBBY5j7ptG+as25TNgut4/7X7UFqi2zJ7v 2wJju7/mJzULvNslHJnS+a+qtvfZ8lEC5oCAVDxNCeMAksewx86ZoL/9Plg3f3m5bv 4Isjv0slePM3xdAA1NEx5Be10n+wRrjeo8cLIKLu1+e32jOlozwwyKfK521O7leJpH k+saq0YsZoV6SWUrcuMLHn4MK8knYG+0i7sjPQQpcsLqU0BTu9fZ9ssniqjTzRB8ER 871zZqCAIK8FCzVziZPJcOvuSg2jjIADlYfACOPME8xXoxcHAYCuSPuIBpvo10XYT+ UZxZ7Zlm90pgg== Message-ID: <146a8e68-4a25-45aa-bd29-a65fa2a7a940@stuttgart.de> Date: Tue, 10 Nov 2026 16:43:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH proxmox-backup 0/4] fix 7333 use multiple tape drives for restoring To: Dominik Csapak , pbs-devel@lists.proxmox.com References: <20261106133826.1692620-2-tobias@stuttgart.de> Content-Language: en-US From: Jakob-Tobias Winter In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 Adjusted score from AWL reputation of From: address DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: TCR77I4PAXU54XRES64KAUMRX567L3PI X-Message-ID-Hash: TCR77I4PAXU54XRES64KAUMRX567L3PI X-MailFrom: prvs=9510975028=tobias@stuttgart.de 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 Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, On 11/10/26 14:15, Dominik Csapak wrote: > > On 11/6/26 2:39 PM, Jakob-Tobias Winter wrote: >> >> A full restore writes the snapshot archives straight into the >> datastore. That is safe with a single drive, because a tape backup >> writes the chunks of a snapshot before its snapshot archive, to the >> same or an earlier media. With several drives, a snapshot archive can >> be read while an earlier media is still being restored, and an aborted >> restore would leave snapshots with missing chunks behind. So with more >> than one drive, a full restore runs the phases of the selective restore >> for all snapshots, which only add the snapshots once all chunks are >> restored. The restore window already takes that path whenever it sends >> a namespace mapping. The trade-offs are that the media set catalog is >> needed, every media is loaded twice (once for the snapshot archives, >> once for the chunks), and the snapshots only show up at the end. >> > > maybe the double loading of tapes could be avoided by restoring > the snapshots of the subsequent tapes in a temporary location > and moving those afterwards? the first tape is generally > exempt here since there the guarantees must hold anyway > (but special casing this might be overkill) > > so we could simply go through each tape, restore all chunks > to the chunks dir and snapshots to a tmpdir, then no tape > has to be loaded twice? I thought about avoiding the double load as well (it's possible with the temp dir approach) but wanted to make as little changes as possible to the restore logic overall, so not to do too much at once. I would keep the existing restore logic for now and improve it later, if that is fine with you? >> Open questions: >> >> - Is 'drive' plus 'additional-drives' fine, or would you prefer >>    something else, e.g. a 'drives' list, or the changer plus "use all >>    free drives"? > > i'd probably add a 'drives' parameter that replaces the 'drive' one. > we could then always use that and deprecate 'drive' > > this is the most flexible and straightforward way i think. Agreed.> > >> - Is a maximum of four drives in total OK or can we drop the limit? > > I'd probably not restrict it to an arbitrary limit, since it's > impossible to know what is a good limit beforehand. > The number of drives directly controls the number of threads and > necessary read performance, so the user has to know what his system > can handle. Ok. > >> - Standalone drives (without changer) work, but the pool cannot know >>    which tape is in which drive, so the operator has to follow the >>    per-drive "insert media" notifications. Is that OK? > > Not sure this feature makes too much sense for standalone drives > at all, since it's rather unlikely that a single pbs install > has multiple standalone drives intended for a single restore > job, but yes, following the notification mails is ok IMO. > >> - Should the "drive 'NAME': " prefix also be used with a single drive, >>    for consistency? > > no, in that case i would simply write the used drive at the beginning of > the log somewhere so it's clear (when not done already). At the moment, it's written into the log when it's loading the media into the drive used, so it's clear what's going on without prefixing. So let's keep it only when using more drives. Thanks for your feedback, I will send a new version once you've had a chance to go over the complete set.