Am 01.04.25 um 20:21 schrieb Thomas Lamprecht:
For more current discussion it might be best to check out the recently
posted v7 of this series, if nothing bigger comes up it should be very
close to what gets applied for an initial version – i.e., one that will
be supported for a long time, which does not necessarily mean that it
cannot evolve.
https://lore.proxmox.com/pve-devel/20250401173435.221892-1-f.eb...@proxmox.com/T/#t
Thank you. I'll take a look at that one.
The Perl code required for a production quality interface is not that
much, and certainly does not require in-depth perl experience. Perl
is a mature language, for better or worse, that allowed and still
allows all kind of users to create tools that can work fine if one keeps
them simple, and as the core design is rather fixed here, it should not
be that much work, and we certainly can help on questions or problems;
just reach out on the developer list and point to your public plugin
code.
Fair enough. We're probably able to maintain a few lines of Perl-based
glue-code.
To do its job[1], Bareos must be able to schedule backup and restore
jobs all by itself. If I understood correctly, backups utilizing one of
the plugins can be run by calling `vzdump`, so that this is at least
possible.
Exactly, we want a native PVE implementation so that such plug-ins are
actually nicely integrated and feel almost native (in the long run,
missing a few bits for that), so users get a first-class experience
on "both sides" of the backup and can also see what's going on at the
source side of things, if they want.
I totally understand why a lot of people want that.
Nevertheless, Bareos supports super-paranoid setups. We have users that
shutdown their backup-server when no backup is running, some have
pre-/post scripts that enable/disable a server's switch-port in the
backup network. Some people even write their VM backups to WORM tapes.
So while integration is nice-to-have it must be at least opt-out, but
preferably opt-in.
However, what we've seen other vendors do is that they provide an API
where you just tell the system what VM you want to back up and then you
are provided with access to metadata (i.e. VM configuration, disk
layouts, nvram content, etc) and disk contents.
You can send an API request that basically results in exactly that, just
that the plugin is providing you the info then. A big advantage is that
the user can also trigger backups from the PVE side and thus get a much
better integration.
Bareos' architecture doesn't support client-side triggering. The only
way to integrate that would be to have PVE initiate a console connection
to the Bareos director, which then initiates a backup or restore job.
2. Restore API
2.1. Restore Mechanisms
Bareos could provide a NBD that is streamed directly from the backup
repository, this should be quite efficient w.r.t. space usage.
There is no such thing like a random accessible backup repository in
Bareos. What would have to be exposed can be stored on several tape
volumes. To make this accessible as NBD we'd need to stage it somewhere
first.
Nothing in the proposed methods should technically hinder such a
separation, it's just the interface, no protection mechanism on the backup
systems side need to be adapted or changed, and one could construct the
plugin such that it can only work with jobs that got started from the
backup system, albeit that would be IMO not really reasonable or at
least not really a nice experience especially as the attack surfaces
stays rather the same either way, as data needs effectively to be sent
in both directions
Maybe you're not considering the same attack vectors as we do.
Just assume PVE is compromised (and you didn't notice yet). In that case
an attacker can do anything that can be done from PVE. This includes,
but is not limited to:
* (re)set backup retention periods
* potentially remove existing backups
* spam the backup system with new backups
* run malicious restore jobs
Even if an attacker can only see your backup retention period or what
backups exist, that's a great indicator on how long to wait before there
is no "clean" backup left after your VMs have been compromised.
Feel free to consider this more of an academic thought experiment. We
have already seen ransomware operators targeting ESXi with pretty
devastating results. While I really hope something like that never
happens to PVE, I really want our users to be prepared.
For a nicely integrated solution that can bring back last week's VM
snapshot with a few clicks, there's Proxmox Backup Server, which works
great.
Do you not want a nicely integrated solution? I think users want both,
a nice integration into PVE and additional features and capabilities
of backup solution like yours.
Sure. But we consider being inaccessible from the production system a
feature. While many users might not need this, this is still what we are
planning and preparing for.
Best Regards,
Andreas
--
Andreas Rogge andreas.ro...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
