On 12/13/22 6:10 PM, ToddAndMargo via users wrote:
On 12/13/22 15:28, Todd Zullinger wrote:
> Patrick O'Callaghan wrote:
>> However qcow also allows compression, sparse files,
>> encryption and copy-on-write snapshots (COW, hence the
>> name) [...]
>
> This is not meant to detract from your well-made point that
> the qcow2 format provides many benefits over raw filesystem
> images. :)
>
> Tangentially, the qemu-img(1) man page says of the
> encryption support:
>
> The use of encryption in qcow and qcow2 images is
> considered to be flawed by modern cryptography
> standards, suffering from a number of design problems:
>
> [...]
>
> Use of qcow / qcow2 encryption is thus strongly
> discouraged. Users are recommended to use an alternative
> encryption technology such as the Linux dm-crypt / LUKS
> system.
And if you can't back it up, it is ...
I really don't understand what the issue with restoring a qcow2 file might be. As far
as the host is concerned, it's just a file that contains a binary blob. Dumping and
restoring such a file should be no different from doing the same with any other file
containing an arbitrary arrangement of ONEs and ZEROs.
Did you, by any chance, do the dump operation while that qcow2 file was attached to a
running VM? That would likely be a disaster. I notice that your bug report showed only the
restore command, and never showed how the original dump was done.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.