From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 035491FF0C0 for ; Wed, 21 Oct 2026 16:44:09 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id D209821616; Wed, 21 Oct 2026 16:44:06 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 21 Oct 2026 16:44:02 +0200 Message-Id: To: "Nicolas Frey" , Subject: Re: [RFC cluster/common/container/docs/installer/manager 00/21] add rudimentary host backup mechanism X-Mailer: aerc 0.20.0 References: <20260828133030.351140-1-s.sterz@proxmox.com> <3e24a410-7891-4d35-9e53-3097e8ce6259@proxmox.com> In-Reply-To: <3e24a410-7891-4d35-9e53-3097e8ce6259@proxmox.com> From: "Shannon Sterz" X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792593842694 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.720 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: KT2VZMI33XLYW34TBKIX5TEH7PCFO23R X-Message-ID-Hash: KT2VZMI33XLYW34TBKIX5TEH7PCFO23R X-MailFrom: s.sterz@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 Tue Oct 20, 2026 at 5:47 PM CEST, Nicolas Frey wrote: > Hi, thanks for the patches! Thank you for taking a look, much appreciated! > I tested the changes on the PVE side and the installer (i.e. disaster > recovery) on a VM with zfs on root: > > PVE side: > > works well, using it is quite intuitive. I didn't run into any issues. > I had some thoughts of how it could be extended: > > * allow the user to add additional paths that they might want backed > up too, e.g. custom scripts outside of `/etc` Yep, makes sense and I already did some ground work there (see the "additional-files" section of the job config added in 07/21). So you could already add files there directly in the jobs config. What I didn't get around to is the UI part. To make that nicely useable a file picker for the root disk would probably be ideal, but that would have required new API endpoints. I'll see if I manage to add it for a v1, though. > * allow local backups, which would make it possible to plug it into > own backup scripts/solutions As you mention below, this was deemed out of scope for this series fairly early on. Sorry for not mentioning that in the cover letter. The goal being to first establish a process that works robustly enough for disaster recovery and then expanding from there (otherwise this could have been a much bigger series too). However, it shouldn't be too hard to add that once this mechanism is established as all information is gathered in one directory first. Other backup providers would only need to plug into the part were this series currently uses the PBS client to back up the data. > Both of these are probably beyond the scope of "disaster recovery" and > may also be out of scope for the initial series, but I just wanted to > mention them. > > The installer: > > I had some difficulties with testing the installer changes, mainly > because it depended on proxmox-backup-client, which isn't in our ISO > build. after getting DNS to work so I could pull in packages via apt, > I was able to install the package. > > I was also a bit puzzled by how the restore functioned (I went through > a whole TUI installer dialog until realizing I'd have to pass '-r' to > initiate the process, though that wouldn't be an issue if I didn't > have to start the installer in debug mode and chose a "restore from > backup" option. These two should not be issues in a final ISO build, but I'll add a section on how to test this for a v1. Thanks for the feedback. > Also, manually needing to fill in all the PBS information in the > installer was a bit annoying, though I reckon that would be solved by > the auto-installer. Yep this could be improved. One thing that I should have mentioned is that the fingerprint can be populated automatically by the installer if you test the connection or move on from the screen without filling in the fingerprint. Selecting the proper backup could probably be improved by querying backups that exist on the PBS. The rest is a bit more tricky. I suppose allowing username and password authentication instead of only tokens would improve usability somewhat. > Perhaps also making it possible to restore from a local backup (not > from PBS) might make sense? It would plug in nicely with the second > point for PVE above. > > I otherwise didn't run into any issues on the auto installer, I > restored the VMs (which's config was backed up by the host backup) via > PBS and the single node was running pretty much as it was before. > > --- > > The series looks quite good already! Thanks! > On 8/28/26 3:31 PM, Shannon Sterz wrote: >> This is still very early stages and rough around the edges. I am sending= this >> now, because the rough mechanism seems to work well enough to start gath= ering >> some input. > [snip]