From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
aderumier@odiso.com,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [pbs-devel] [PATCH 00/11] live-restore for PBS snapshots
Date: Tue, 12 Jan 2021 11:31:48 +0100 [thread overview]
Message-ID: <a92a21dc-58a1-7c41-71a0-b840118e323a@proxmox.com> (raw)
In-Reply-To: <a91ee7b1e8094581fefa180f02b40a47f14eb722.camel@odiso.com>
On 11.01.21 16:50, aderumier@odiso.com wrote:
> if we could make some kind of qemu-nbd + mount loop of the backup
> volume for example.
That is already possible through qemu-nbd tool (we have a PBS block driver backend),
see: https://lists.proxmox.com/pipermail/pve-user/2020-July/171883.html
Or do you mean something else?
FWIW, there's an idea (and some intial POC) to later also have a file explorer similar
like for file level backups in PVE, which starts a minimal VM, directly booting a
shipped Linux initrd and pbs rust daemon, providing an API to list/extract files from
any blocklevel backup containing a filesystem a modern Linux kernel can understand.
The VM is used for isolation purpose, every kernel FS dev says mounting a filesystem
should be considered unsafe and can theoretically altered to break the host. As
backups may not be 100% trusted a VM environment is much safer.
WARNING: multiple messages have this Message-ID
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
aderumier@odiso.com,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [pve-devel] [PATCH 00/11] live-restore for PBS snapshots
Date: Tue, 12 Jan 2021 11:31:48 +0100 [thread overview]
Message-ID: <a92a21dc-58a1-7c41-71a0-b840118e323a@proxmox.com> (raw)
In-Reply-To: <a91ee7b1e8094581fefa180f02b40a47f14eb722.camel@odiso.com>
On 11.01.21 16:50, aderumier@odiso.com wrote:
> if we could make some kind of qemu-nbd + mount loop of the backup
> volume for example.
That is already possible through qemu-nbd tool (we have a PBS block driver backend),
see: https://lists.proxmox.com/pipermail/pve-user/2020-July/171883.html
Or do you mean something else?
FWIW, there's an idea (and some intial POC) to later also have a file explorer similar
like for file level backups in PVE, which starts a minimal VM, directly booting a
shipped Linux initrd and pbs rust daemon, providing an API to list/extract files from
any blocklevel backup containing a filesystem a modern Linux kernel can understand.
The VM is used for isolation purpose, every kernel FS dev says mounting a filesystem
should be considered unsafe and can theoretically altered to break the host. As
backups may not be 100% trusted a VM environment is much safer.
next prev parent reply other threads:[~2021-01-12 10:32 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 11:13 [pve-devel] " Stefan Reiter
2021-01-11 11:13 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:13 ` [pve-devel] [PATCH qemu 01/11] PVE: explicitly add libuuid as linking dependency Stefan Reiter
2021-01-11 11:13 ` [pbs-devel] " Stefan Reiter
2021-01-12 12:04 ` [pve-devel] " Thomas Lamprecht
2021-01-12 12:04 ` Thomas Lamprecht
2021-01-18 10:27 ` [pve-devel] [PATCH pve-qemu] explicitly specify " Stefan Reiter
2021-01-27 8:29 ` Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH qemu 02/11] PVE: block/pbs: fast-path reads without allocation if possible Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-12 9:29 ` [pve-devel] " Wolfgang Bumiller
2021-01-12 9:29 ` [pbs-devel] " Wolfgang Bumiller
2021-01-11 11:14 ` [pve-devel] [PATCH qemu 03/11] block: add alloc-track driver Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-12 10:54 ` [pve-devel] " Wolfgang Bumiller
2021-01-12 10:54 ` [pbs-devel] " Wolfgang Bumiller
2021-01-12 11:29 ` Stefan Reiter
2021-01-12 11:29 ` [pbs-devel] " Stefan Reiter
2021-01-12 13:42 ` Wolfgang Bumiller
2021-01-12 13:42 ` [pbs-devel] " Wolfgang Bumiller
2021-01-11 11:14 ` [pve-devel] [PATCH proxmox-backup 04/11] RemoteChunkReader: add LRU cached variant Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH proxmox-backup-qemu 05/11] access: use bigger cache and LRU chunk reader Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH qemu-server 06/11] make qemu_drive_mirror_monitor more generic Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-12 13:19 ` [pve-devel] " Wolfgang Bumiller
2021-01-12 13:19 ` [pbs-devel] " Wolfgang Bumiller
2021-01-11 11:14 ` [pve-devel] [PATCH qemu-server 07/11] cfg2cmd: allow PBS snapshots as backing files for drives Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-28 16:25 ` [pve-devel] " Thomas Lamprecht
2021-01-28 16:25 ` [pbs-devel] " Thomas Lamprecht
2021-01-11 11:14 ` [pve-devel] [PATCH qemu-server 08/11] enable live-restore for PBS Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH qemu-server 09/11] extract register_qmeventd_handle to QemuServer.pm Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH qemu-server 10/11] live-restore: register qmeventd handle Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 11:14 ` [pve-devel] [PATCH manager 11/11] ui: restore: add live-restore checkbox Stefan Reiter
2021-01-11 11:14 ` [pbs-devel] " Stefan Reiter
2021-01-11 15:50 ` [pve-devel] [PATCH 00/11] live-restore for PBS snapshots aderumier
2021-01-11 15:50 ` [pbs-devel] " aderumier
2021-01-11 16:42 ` Stefan Reiter
2021-01-12 9:10 ` aderumier
2021-01-12 10:31 ` Thomas Lamprecht [this message]
2021-01-12 10:31 ` [pbs-devel] " Thomas Lamprecht
2021-01-12 11:23 ` [pve-devel] [pbs-devel] " Thomas Lamprecht
2021-01-12 11:23 ` [pbs-devel] [pve-devel] " Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a92a21dc-58a1-7c41-71a0-b840118e323a@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=aderumier@odiso.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.