Re: [pve-devel] [PATCH storage v4 09/27] plugin: introduce new_backup_provider() method

[Andreas Rogge <andreas.rogge@bareos.com>]

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.ebner@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.rogge@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