Snap on LVM

[ffsapher]

Hello to all proxmox enthusiasts.

At our company, we use a multipath-configured FC array(from old vmware clusters, netapp and ethernus mostly). We're currently running PVE8, but we'll be upgrading to PVE9 in the next few days.

We tested the new snap version on version 9, but with a 10TB VM, we need the same amount of space per snap, which is unacceptable.(with also huge inpact on performance)

However, we use Veeam on version 8. Imagine if Veeam could create efficient snaps during backups without any problems. We have, for example, a 10TB VM database on RAW LVM. Veeam creates a snap on a different disk for the data store directory and creates a .QCOW2 temp file. Even 30-hour backups aren't common, and we only want snaps for patching vulnerabilities, not for days at a time.

Could someone suggest how I could perform snapshots in a test environment like the Veeam Worker, but without using it? with reverse functionality of course

Best regards to everyone, and have a nice day!

 

[LnxBil]

Could someone suggest how I could perform snapshots in a test environment like the Veeam Worker, but without using it? with reverse functionality of course

You have to ask Veeam what strange things they do with their backup. I would assume they create a simple diff qemu file in which all writes are redirected, so that the actual disk itself does not change so that they can read consistently and afterwards they merge the accumulated writes back into the files.

 

[tomservo]

I don't actually know how veeam does snapshots, but I would guess that it's kinda like how the built-in backups works. To work even on storage that doesn't support snapshots, the backups instead set up a feature in qemu that can pause any write to the virtual disk just long enough to copy the old contents of that block off to the backup first. Optionally this can be accelerated by diverting the write to a temporary location instead of pausing it, which is called backup fleecing. This is what I suspect that qcow file is doing (being temp storage for the fleecing), but again I don't actually know anything about veeam and I am just guessing they do stuff similar to the proxmox backups. See https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_vm_backup_fleecing

This lets the system read the state of the drive into a backup as if there were a snapshot, but there isn't actually a snapshot of the storage. A real storage snapshot keeps both the old and new state and so is able to throw away the new state and revert to the old state. With a backup snapshot, when a write happens and the old contents of that part of the disk are sent to the backup file (or whatever backup storage), it then gets replaced by the new data. Unlike a storage snapshot, both states aren't saved on the datastore (the old state is only in the backup job). So because of this there isn't a way to revert to the snapshot state except to restore the data from the backup job, and you can't do that until the backup has finished.

To address the real issue, it sounds like you are using the LVM snapshot-as-volume-chain type snapshots. According to the documentation at https://pve.proxmox.com/wiki/Storage:_LVM#pvesm_lvm_config "For efficient support of snapshot-as-volume-chain, the backing storage must support thin-provisioning and discard. Each snapshot will appear to use thefull volume size on the PVE side, but the actual space usage on the underlying storage will be smaller if those requirements are met." So maybe you already have the snapshots you want and it just looks unacceptable, or maybe it really is bad. Either way, the doc does say it is a "tech preview" so you might not want to rely on it in production without a lot of testing first.