Re: [RFC cluster/common/container/docs/installer/manager 00/21] add rudimentary host backup mechanism

["Shannon Sterz" <s.sterz@proxmox.com>]

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 gathering
>> some input.
> [snip]