hi all, IS there a way to do this with Vzdump and the exclude options..
First the pros, with Vzdump and qmrestore we have a way to get the backed up Windows VM's (mostly win 2016 server VM's on new PVE 5.1) back into PVE and get them working in case of mishaps.. OK
Since the OS boot LV Thin block device Windows VM is only like 40GB, this workx!
BUT
Now the cons, when these windows KVM server VM's are put to work and we attach more LV Thin block devices to them, because the data partitions are 1TB+ LV Thin block devices (NTFS data partitions) we end up with something typical like this:
pve-vm--225--disk--1 (is the 40GB win2016 svr VM boot partition)
pve--vm--225--disk--2 (is the 1TB+ NTFS data partition)
pve--vm--225--disk--3 (is another 1TB+ NTFS data partition)
I would still like to use Vzdump but would like to exclude the 2 NTFS data partitions
Now for windows KVM's set up in ths manner
is there a way to do this with vzdump's exclude option feature,, bcs only mount points in a regular mounted directory file structure can be excluded as far as i can tell..
Its not practical to include the 2 or more attached LV Thin (NTFS data partitions) devices in a vzdump, only the boot-os disk is all we want to get, the NTFS data is backed up in other traditional ways.
We just want a way ot QUICKLY recover the win VM's boot-OS smaller partitions if a mishap happened..
It's very practical for us to do this, say; qmrestore the LV Thin pve-vm--225--disk--1 and be up and running again with the small 40GB boot-OS VM, say its a Win2016svr KVM VM, but then we'd have to manually attach the NTFS LV Thin NTFS partitions, BUT, we would have to have uptodate GOOD and tested backups of JUST that 40GB boot-OS win2016svr portion in order to be able to do this!! THUS the problem!!?
If this is not possible
What are other people using to backup & recover individual windows' KVM VM's??? that can be boot ready as soon as they are recovered..
Bcs to use vzdump on an entire VM that with all its data partitions equals 6TB's would take a week!!, NOT practical! it's much more practical to JUST backup the small "train-engine", not the "entire train" .., so to speak..
Later same day..
Unless someone has come up w a better idea for the above, what we've come up with is to periodically stop the Windoze VM and surgically perform a "raw-out" dd of the LV Thin block device that is the smaller boot-OS partition and then crunch it down with "Qemu-img convert" to a compressed qcow2 format and put it into some type of "rotated" & "safe" storage .
If done manually this is repetetive and time consuming so the only option is to bash script it and cron it
Here's wat we're thinking has to be done periodically after stopping the VM.
dd if=/dev/mapper/pve-vm--225--disk--1 of=/path/to/some/mount/point/foo.raw bs=8M status=progress (we'd wanna experiment with diffrent values of the "bs" param, like bs=16M )
then then run qemu-img convert to compress it down into a qcow2 format for keeping as a backup..
qemu-img convert -p -c -f raw foo.raw -O qcow2 /path/to/some/place/foo.qcow2
So if there's a better way to do wat we are seeking to do, by all means pls offer your 2 cents.. thx all
First the pros, with Vzdump and qmrestore we have a way to get the backed up Windows VM's (mostly win 2016 server VM's on new PVE 5.1) back into PVE and get them working in case of mishaps.. OK
Since the OS boot LV Thin block device Windows VM is only like 40GB, this workx!
BUT
Now the cons, when these windows KVM server VM's are put to work and we attach more LV Thin block devices to them, because the data partitions are 1TB+ LV Thin block devices (NTFS data partitions) we end up with something typical like this:
pve-vm--225--disk--1 (is the 40GB win2016 svr VM boot partition)
pve--vm--225--disk--2 (is the 1TB+ NTFS data partition)
pve--vm--225--disk--3 (is another 1TB+ NTFS data partition)
I would still like to use Vzdump but would like to exclude the 2 NTFS data partitions
Now for windows KVM's set up in ths manner
is there a way to do this with vzdump's exclude option feature,, bcs only mount points in a regular mounted directory file structure can be excluded as far as i can tell..
Its not practical to include the 2 or more attached LV Thin (NTFS data partitions) devices in a vzdump, only the boot-os disk is all we want to get, the NTFS data is backed up in other traditional ways.
We just want a way ot QUICKLY recover the win VM's boot-OS smaller partitions if a mishap happened..
It's very practical for us to do this, say; qmrestore the LV Thin pve-vm--225--disk--1 and be up and running again with the small 40GB boot-OS VM, say its a Win2016svr KVM VM, but then we'd have to manually attach the NTFS LV Thin NTFS partitions, BUT, we would have to have uptodate GOOD and tested backups of JUST that 40GB boot-OS win2016svr portion in order to be able to do this!! THUS the problem!!?
If this is not possible
What are other people using to backup & recover individual windows' KVM VM's??? that can be boot ready as soon as they are recovered..
Bcs to use vzdump on an entire VM that with all its data partitions equals 6TB's would take a week!!, NOT practical! it's much more practical to JUST backup the small "train-engine", not the "entire train" .., so to speak..
Later same day..
Unless someone has come up w a better idea for the above, what we've come up with is to periodically stop the Windoze VM and surgically perform a "raw-out" dd of the LV Thin block device that is the smaller boot-OS partition and then crunch it down with "Qemu-img convert" to a compressed qcow2 format and put it into some type of "rotated" & "safe" storage .
If done manually this is repetetive and time consuming so the only option is to bash script it and cron it
Here's wat we're thinking has to be done periodically after stopping the VM.
dd if=/dev/mapper/pve-vm--225--disk--1 of=/path/to/some/mount/point/foo.raw bs=8M status=progress (we'd wanna experiment with diffrent values of the "bs" param, like bs=16M )
then then run qemu-img convert to compress it down into a qcow2 format for keeping as a backup..
qemu-img convert -p -c -f raw foo.raw -O qcow2 /path/to/some/place/foo.qcow2
So if there's a better way to do wat we are seeking to do, by all means pls offer your 2 cents.. thx all
Last edited:
