Re: dump/restore?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2022-12-13 at 22:39 -0600, Robert Nichols wrote:
> 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.

I think there's some lack of clarity in ToddAndMargo's original post. I
originally thought it meant that the qcow2 file is just part of some
filesystem that is being dumped along with everything else, in which
case it's a raw file and should dump and restore without issue. However
subsequent comments seems to indicate it's being dumped itself *as a
filesystem* (or partition) in which case dump is trying to interpret
its contents, and I wouldn't expect that to work, especially after the
sparsify process.

poc
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux