Am 01.04.25 um 20:21 schrieb Thomas Lamprecht: > Am 01.04.25 um 18:02 schrieb Andreas Rogge: >>> The backup provider gives a path to the disk image that will be >>> restored. The path needs to be something 'qemu-img' can deal with, >>> e.g. can also be an NBD URI or similar. >> Um... that has nothing to do with what you provided when we take the >> backup. Is there a reason PVE cannot provide a writeable block device to >> restore to?
Good idea! I'll look into adding a second restore mechanism with this approach. >> For Bareos this requirement would imply that we need an unpleasantly >> large staging area on the PVE node to facilitate a restore: As we can >> only stream the data we'd have to create a temporary disk image that PVE >> can then read. This sounds pretty inefficient - especially when >> comparing with qmrestore's ability to just read read from stdin. > > Bareos could provide a NBD that is streamed directly from the backup > repository, this should be quite efficient w.r.t. space usage. > But as this was v4 and a few things changed, and I'm less involved as > the actual author it might make more sense for her to answer this. It's still mostly the same in the current version. But yes, you can provide an NBD URI or path to a FUSE virtual file to avoid the need for a temporary image. Best Regards, Fiona _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
