7:22 a.m.
Has dump/restore been superseded with something else?
It ain't work right!
dump restores a qcows drive as a blank drive
https://bugzilla.redhat.com/show_bug.cgi?id=2152393
7:40 a.m.
El 11/12/2022 a las 14:22, ToddAndMargo via users escribió:
Has dump/restore been superseded with something else?
It ain't work right!
dump restores a qcows drive as a blank drive
https://bugzilla.redhat.com/show_bug.cgi?id=2152393
_______________________________________________
I used last week rsnapshot to clone a running FreeBSD box and worked
great for me. Don't know if is a valid solution in Linux.
9:58 a.m.
I love dump/restore. Old fashioned maybe. But you have to use dnf to
install dump. Restore should already be there. IDK about its status with
fedora.
On 12/11/2022 8:22 AM, ToddAndMargo via users wrote:
> Has dump/restore been superseded with something else?
>
> It ain't work right!
>
> dump restores a qcows drive as a blank drive
> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
>
10:07 a.m.
On 12/11/2022 8:22 AM, ToddAndMargo via users wrote:
> Has dump/restore been superseded with something else?
>
> It ain't work right!
>
> dump restores a qcows drive as a blank drive
> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
On 12/11/22 07:58, Bill Cunningham wrote:
I love dump/restore. Old fashioned maybe. But you have to use dnf to
install dump. Restore should already be there. IDK about its status with
fedora.
I got them both. I have used them for years and adore them.
10:45 a.m.
I will say, not looking at the bug report and not being to familiar with
qcows, you might be running into a sparse file situation. Like I say, I
don't have the bug report in front of me right now. Restoring data without
meta data will get you into this. As a side note, I also like fsarchiver
and there's always rsync.
On Sun, Dec 11, 2022, 11:08 AM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
> On 12/11/2022 8:22 AM, ToddAndMargo via users wrote:
>> Has dump/restore been superseded with something else?
>>
>> It ain't work right!
>>
>> dump restores a qcows drive as a blank drive
>> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
On 12/11/22 07:58, Bill Cunningham wrote:
> I love dump/restore. Old fashioned maybe. But you have to use dnf to
> install dump. Restore should already be there. IDK about its status with
> fedora.
>
I got them both. I have used them for years and adore them.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
11:28 a.m.
You might want to look into qemu img, in using these files, qcows is indeed
a sparse file. These can save into a small file, but when expanded fill up
your drive with nothing. Qemu-img converts these files I guess. Maybe a
qcows user can help.
On Sun, Dec 11, 2022, 11:08 AM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
> On 12/11/2022 8:22 AM, ToddAndMargo via users wrote:
>> Has dump/restore been superseded with something else?
>>
>> It ain't work right!
>>
>> dump restores a qcows drive as a blank drive
>> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
On 12/11/22 07:58, Bill Cunningham wrote:
> I love dump/restore. Old fashioned maybe. But you have to use dnf to
> install dump. Restore should already be there. IDK about its status with
> fedora.
>
I got them both. I have used them for years and adore them.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
1:42 a.m.
On 12/11/22 05:22, ToddAndMargo via users wrote:
Has dump/restore been superseded with something else?
It ain't work right!
dump restores a qcows drive as a blank drive
https://bugzilla.redhat.com/show_bug.cgi?id=2152393
I don't see how dump would ever work on a qcow file. You can't read
that file directly as a filesystem, so I don't understand how dump isn't
throwing all sorts of errors.
8:44 a.m.
On Sun, 2022-12-11 at 23:42 -0800, Samuel Sieb wrote:
On 12/11/22 05:22, ToddAndMargo via users wrote:
> Has dump/restore been superseded with something else?
>
> It ain't work right!
>
> dump restores a qcows drive as a blank drive
> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
I don't see how dump would ever work on a qcow file. You can't read
that file directly as a filesystem, so I don't understand how dump
isn't
throwing all sorts of errors.
I assumed he was dumping the filesystem the qcows file is on, i.e. it's
just a file.
I wonder if it's in a BTRFS subvolume, which dump might treat as a
separate filesystem and not actually copy.
poc
2:27 a.m.
On 12/11/22 05:22, ToddAndMargo via users wrote:
Has dump/restore been superseded with something else?
It ain't work right!
dump restores a qcows drive as a blank drive
https://bugzilla.redhat.com/show_bug.cgi?id=2152393
You might want to look into nbdkit and nbdkit-libvirt-plugin.
That should work for dump, but you'll have to convert the restored data
back into qcow again.
3:16 p.m.
On 12/13/22 00:27, Samuel Sieb wrote:
On 12/11/22 05:22, ToddAndMargo via users wrote:
> Has dump/restore been superseded with something else?
>
> It ain't work right!
>
> dump restores a qcows drive as a blank drive
> https://bugzilla.redhat.com/show_bug.cgi?id=2152393
You might want to look into nbdkit and nbdkit-libvirt-plugin.
That should work for dump, but you'll have to convert the restored data
back into qcow again.
I successfully test restored four of my main VM
disk files after converting them to "raw".
It may just be my perception, but I think raw
just might be faster than qcows2
4:23 p.m.
On Tue, 2022-12-13 at 13:16 -0800, ToddAndMargo via users wrote:
On 12/13/22 00:27, Samuel Sieb wrote:
> On 12/11/22 05:22, ToddAndMargo via users wrote:
> > Has dump/restore been superseded with something else?
> >
> > It ain't work right!
> >
> > dump restores a qcows drive as a blank drive
> > https://bugzilla.redhat.com/show_bug.cgi?id=2152393
>
> You might want to look into nbdkit and nbdkit-libvirt-plugin.
>
> That should work for dump, but you'll have to convert the restored
> data
> back into qcow again.
I successfully test restored four of my main VM
disk files after converting them to "raw".
It may just be my perception, but I think raw
just might be faster than qcows2
For many workloads it probably is, as qcow adds a layer of indirection
to filesystem access. However qcow also allows compression, sparse
files, encryption and copy-on-write snapshots (COW, hence the name)
independently of whether the underlying guest system supports these
things.
poc
5:28 p.m.
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.
--
Todd
6:10 p.m.
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 ...
7:50 p.m.
On 12/13/22 16:10, 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 ...
There are many ways to back it up. Just not "dump" without some extra
setup. I don't really see dump being a particularly good option for
backups though.
10:39 p.m.
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.
10:43 p.m.
On 12/13/22 20:39, 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.
"dump" and "restore" are specific utilities for exporting and
recreating
an ext filesystem. They can't work on a qcow file because they're
expecting a disk partition or equivalent. e.g. a raw file would work as
well.
5:40 a.m.
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
505
days inactive
508
days old
17 comments
8 participants
participants (8)
-
Bill C -
Bill Cunningham
-
José María Terry Jiménez -
Patrick O'Callaghan -
Robert Nichols -
Samuel Sieb -
Todd Zullinger -
ToddAndMargo