[pve-devel] [POC storage v3 14/34] add backup provider example

Fiona Ebner f.ebner at proxmox.com
Wed Mar 12 14:05:19 CET 2025


Am 13.11.24 um 11:52 schrieb Fabian Grünbichler:
> didn't give this too close a look since it's an example only, but the
> hard-coded NBD indices make me wonder whether we want to have some sort
> of mechanism to "reserve" NBD slots while using them, at least for *our*
> usage?

Fixed in v5. I just copied over the corresponding method added in v4 in
qemu-server. This plugin is just a POC to test all mechanisms. I'll add
a note there to explain that actual plugins should never need to mess
with NBD block nodes, i.e. either they should speak NBD with the export
directly instead of binding to a block device node, or use the
'block-device' backup mechanism.

> On November 7, 2024 5:51 pm, Fiona Ebner wrote:
>> +my sub get_bitmap_id {
>> +    my ($self, $vmid, $vmtype) = @_;
>> +
>> +    return if $self->{'storage-plugin'}->get_vm_backup_mode($self->{scfg}) ne 'incremental';
>> +
>> +    my $previous_info_dir = "$self->{scfg}->{path}/$vmid/";
>> +
>> +    my $previous_info_file = "$previous_info_dir/previous-info";
>> +    my $info = file_read_firstline($previous_info_file) // '';
>> +    $self->{$vmid}->{'old-previous-info'} = $info;
>> +    my ($bitmap_id, $previous_backup_id) = $info =~ m/^(\d+)\s+(\d+)$/;
>> +    my $previous_backup_dir =
>> +	$previous_backup_id ? "$self->{scfg}->{path}/$vmid/$vmtype-$previous_backup_id" : undef;
> 
> so the backup ID is an epoch - wouldn't it be nicer to use the formatted
> one as subdir, rather than the epoch itself?

If we ever want to spin out a variant of a directory plugin for real
production support, yes sure. I didn't bother for the example here.

>> +
>> +    if ($bitmap_id && -d $previous_backup_dir) {
>> +	$self->{$vmid}->{'previous-backup-dir'} = $previous_backup_dir;
>> +    } else {
>> +	# need to start fresh if there is no previous ID or the associated backup doesn't exist
>> +	$bitmap_id = $self->{$vmid}->{'backup-time'};
>> +    }
>> +
>> +    $self->{$vmid}->{'bitmap-id'} = $bitmap_id;
>> +    make_path($previous_info_dir);
>> +    die "unable to create directory $previous_info_dir\n" if !-d $previous_info_dir;
>> +    file_set_contents($previous_info_file, "$bitmap_id $self->{$vmid}->{'backup-time'}");
>> +
>> +    return $bitmap_id;
>> +}
>> +
>> +# Backup Provider API
>> +
>> +sub new {
>> +    my ($class, $storage_plugin, $scfg, $storeid, $log_function) = @_;
>> +
>> +    my $self = bless {
>> +	scfg => $scfg,
>> +	storeid => $storeid,
>> +	'storage-plugin' => $storage_plugin,
>> +	'log-function' => $log_function,
>> +    }, $class;
>> +
>> +    return $self;
>> +}
>> +
>> +sub provider_name {
>> +    my ($self) = @_;
>> +
>> +    return 'dir provider example';
>> +}
>> +
>> +# Hooks
>> +
>> +my sub job_start {
>> +    my ($self, $start_time) = @_;
>> +
>> +    log_info($self, "job start hook called");
>> +
>> +    run_command(["modprobe", "nbd"]);
> 
> this duplicates the modprobe in qemu-server, but without the parameter..

Since v4, qemu-server ships a modprobe config to load it during boot.
Replaced the above with a die if not already loaded. Thinking about
this, if we do go for that config, I'll also add a postinst hook to load
it during upgrade of qemu-server in v5.




More information about the pve-devel mailing list