On Thu, 2024-04-18 at 11:19 +0000, Andy Smith via BitFolk Users wrote:

Hi Conrad,

On Thu, Apr 18, 2024 at 11:50:59AM +0100, Conrad Wood via BitFolk Users wrote:
My usecase would be something like this:
1) trigger image via http/wget/curl/API
2) poll for it be completed
3) download image
4) delete image (via some api)

Okay so this is a slightly different set of concerns for us, because
snapshots are at the moment full LVM snapshots which consume disk
space and negatively affect IO performance, which means they need to
be fairly short-lived.

In the solution I am proposing for the one customer who asked,
BitFolk is going to be in control of how long the LVM snapshot stays
around for, so we can keep that burden acceptable. We archive it off
and delete the snapshot quite quickly.

There is always interest in disk snapshots, so possibly it is worth
looking into moving to some other snapshot technology. There is no
getting away from the fact that snapshots use storage though, so
either the storage used will have to be paid for or the lifetime of
the snapshots will have to be limited in some way.

Maybe I misunderstand. my thinking is, that the snapshot mechanism is the same for backup as well as for my usecase.

Terminology might confuse me. I think of a "disk image" as a file containing the data of a block-device byte-for-byte. I think of a "snapshot" as a block-device as created by "lvcreate -s" (in case of LVM). I understand the snapshot must be short-lived, but the disk-image need not, right?

I thought the process is something like

1. LVM snapshot of VM backing store,

2. copy snapshot to disk image,

3. send disk-image to some archive-server,

4. drop snapshot on VM backing store.

The _only_ differences I see are:

- api to create, delete and trigger a disk image

and bitfolk charges me for disk-space used of the disk-image (by hour/minute or as pre-allocated space)

thanks for the clarification on restore - makes sense to me.

Conrad