Results 1 to 8 of 8

Thread: 12.3: restore: This restore version doesn't support bzlib decompression

  1. #1

    Default 12.3: restore: This restore version doesn't support bzlib decompression

    In preparing for a OpenSuse 12.2 -> 12.3 upgrade, I backed up all of my partitions with

    dump 0 -j9 -f <file.dump.bz> <partition>

    with no issues. I like to do a full install rather than an in-place upgrade for its cleanliness.

    I did the 12.3 install with no particular issues. When I mounted my backup files and prepared to put my customizations back on / with

    restore -if ./root.dump.bz

    imagine my surprise when I get

    restore: This restore version doesn't support bzlib decompression

    I was hoping that perhaps the file was just bzip'd so I could simply either bunzip2 the file and then run it through restore or

    bunzip2 -c root.dump.bz | restore -if -

    but apparently that's not how dump does its compression. Neither of those approaches worked, and I see that "file" reports:

    # file root.dump.bz
    root.dump.bz: new-fs dump file (little endian), This dump Sat Jun 8 12:33:02 2013, Previous dump Wed Dec 31 19:00:00 1969, Volume 1, Level zero, type: tape header, Label none, Filesystem /, Device /dev/mapper/system-root, Host towelie, Flags 83

    This was going from 64-bit 12.2 to 64-bit 12.3. The installed dump package I have seems to be dump-0.4b43-12.1.1.x86_64.

    Googling (and Duck-Duck-Go'ing) for this particular error string ("restore version doesn't support bzlib compression") did not yield any useful results that I could find. Unless I'm not searching these forums properly, I also don't see anything relevant here.

    So needless to say, I'm not a happy camper that I did my due dilligence in backing up my old OS files only to find that the version of openSuse I just moved to won't read my backup files.

    Is this any kind of a known issue?

    Thanks

  2. #2
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    20,037
    Blog Entries
    14

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    I've never used dump to backup entire partitions for years. The only thing I backup within the OS is /etc. That's enough since I keep mysql and webserver root on separate partitions. During a clean install I import the partitioning from the previous install. For backup of the data on the partitions I atm use luckybackup + dd for the laptop, an rsync script for the server.

    I'll have to get some sleep now, but I'm intrigued by this regression. Will dive into it tomorrow.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    https://en.opensuse.org/openSUSE:Board#Members
    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  3. #3
    Join Date
    Jun 2008
    Location
    Earth - Denmark
    Posts
    10,730

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    i really don't think i can solve this problem...mostly because i've
    never used dump, but i find the situation challenging, did some
    reading and head scratching and offer:


    > dump 0 -j9 -f <file.dump.bz> <partition>
    >
    > with no issues.


    what was the reported exit status?
    what was the file system type in use on the system backed up? (list
    all if more than one was involved)


    > When I mounted my backup files and prepared to ...


    were they all in one backup file, or several?

    the backup file(s) all on one tape? was BSD tape format in use?

    if not tape, what kind of medium were the backup file(s) written to?
    and what file system is/was in use on it?

    was the storage location on a networked drive?


    >
    > restore -if ./root.dump.bz
    >
    > restore: This restore version doesn't support bzlib
    > decompression


    what version of restore was used?

    what happens if you try to restore interactively?

    did you have the backup file(s) on a remote site?

    did you try using any other of the restore command line switches?
    like, could it correctly generate a comparison of files in the backup
    vs files it finds on the system (with the -C switch, for example)

    >
    > # file root.dump.bz
    > root.dump.bz: new-fs dump file (little endian), This dump Sat Jun 8
    > 12:33:02 2013, Previous dump Wed Dec 31 19:00:00 1969, Volume 1, Level
    > zero, type: tape header, Label none, Filesystem /, Device
    > /dev/mapper/system-root, Host towelie, Flags 83


    is that tape holding the backup file really 43 years old??

    i wonder why it designates the file type as "new-fs dump file" which
    is why i asked above what was the file system type of the 12.2 system
    backed up? were any of the partitions listed in 12.2's fstab or mtab
    btrfs, reiserfs, fat, vfat, smbfs, msdos other?

    why is that "little endian" in there? (very confusing to me)


    > I'm not a happy camper that I did my due dilligence
    > in backing up my old OS files only to find that the version of openSuse
    > I just moved to won't read my backup files.


    once you had 12.2 on tape (or in some number of files on some
    non-tape media) did you then test the ability to restore from those
    tapes/files?

    that is, most consider backing up a multi-step process:

    1. backup
    2. test ability to restore from that backup

    and _then_ proceed with

    3. format/install
    4. restore from proven backup


    > Is this any kind of a known issue?


    maybe--for version 0.4b43, man dump says:

    -Dump examines files on an ext2/3/4 filesystem

    -It might be considered a bug that this version of dump can only
    handle ext2/3/4 filesystems. Specifically, it does not work with FAT
    filesystems.

    -You will need at least the 0.4b22 version of restore in order to
    extract compressed tapes

    -Tapes written using compression will not be compatible with the BSD
    tape format.

    -Dump exits with zero status on success.

    and, for version 0.4b43, man restore says:

    - When doing remote restores, assume the remote file is a regular
    file (instead of a tape device). If you're restoring a remote
    compressed file, you will need to specify this option [-l] or restore
    will fail to access it correctly.


    all very interesting...

    --
    dd
    http://tinyurl.com/DD-Caveat

  4. #4

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    Well, I've got a workaround if nothing else.

    The dump package (i.e. where both dump and restore commands come from) in 12.3 is dump-0.4b43-12.1.1.x86_64.

    I grabbed the dump package from a 12.2 repository which is dump-04b43-9.1.2.x86_64 and pulled it apart with rpm2cpio. The 12.2 restore worked perfectly under 12.3 and I was able to recover my files.

    So either there was a build problem that someone never noticed or this was intentional. If it was intentional that makes me um, grumpy, because if there's one set of OS tools you don't want to change lightly it's backup and restore tools.

    I noticed a few other things. While the 12.3 'dump' man page shows the -j option, if you run the command with the -j argument it says it's an invalid option. If you do an ldd against the dump or restore packages for 12.3 you'll see the libbz2.so.1 is not included in the list of shared object libraries. If you do the same against dump/restore in the 12.2 package, that library is listed. It really seems like it was a build problem that wasn't noticed.

    I opened bug 824859.

    Thanks

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,447
    Blog Entries
    2

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    Quote Originally Posted by mfrost2 View Post
    Well, I've got a workaround if nothing else.

    The dump package (i.e. where both dump and restore commands come from) in 12.3 is dump-0.4b43-12.1.1.x86_64.

    I grabbed the dump package from a 12.2 repository which is dump-04b43-9.1.2.x86_64 and pulled it apart with rpm2cpio. The 12.2 restore worked perfectly under 12.3 and I was able to recover my files.

    So either there was a build problem that someone never noticed or this was intentional. If it was intentional that makes me um, grumpy, because if there's one set of OS tools you don't want to change lightly it's backup and restore tools.

    I noticed a few other things. While the 12.3 'dump' man page shows the -j option, if you run the command with the -j argument it says it's an invalid option. If you do an ldd against the dump or restore packages for 12.3 you'll see the libbz2.so.1 is not included in the list of shared object libraries. If you do the same against dump/restore in the 12.2 package, that library is listed. It really seems like it was a build problem that wasn't noticed.

    I opened bug 824859.

    Thanks
    Theorizing that this may actually be normal and expected.

    I think most backup/recovery tools assume you're restoring to the <same> OS and level OS.
    As each OS is released, a newer version of the backup and recovery tool should be expected.

    IMO that also likely means that your "workaround" is likely the proper way to go about "recovering" the files... The principle is to use the same tools to recover that you used to create.

    IMO that's also likely why when <upgrading> and sometimes <migrating> a good principle is to always backup to some kind of raw format... eg simply making copies of the bytes and blocks using dd or a universal, cross-platform format like a virtual disk. Compression and applications that compress can create custom files nothing else can work with.

    IMO,
    TSU

  6. #6
    Join Date
    Jun 2008
    Location
    Earth - Denmark
    Posts
    10,730

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    On 06/14/2013 01:26 AM, tsu2 wrote:
    > IMO that also likely means that your "workaround" is likely the proper
    > way to go about "recovering" the files... The principle is to use the
    > same tools to recover that you used to create.


    good point. but still rude that the 12.3 version of the tool won't do
    the job running in 12.3--so, thanks to the OP for the bug logged.

    --
    dd


  7. #7
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    On 2013-06-14 06:43, dd wrote:
    > On 06/14/2013 01:26 AM, tsu2 wrote:
    >> IMO that also likely means that your "workaround" is likely the proper
    >> way to go about "recovering" the files... The principle is to use the
    >> same tools to recover that you used to create.

    >
    > good point. but still rude that the 12.3 version of the tool won't do
    > the job running in 12.3--so, thanks to the OP for the bug logged.


    I doubt that restore should be used with the same version. I hate that,
    I have backup media only readable in the original 20 year old machine.

    backups are also made for archival purposes...

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.3 x86_64 "Dartmouth" at Telcontar)

  8. #8
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,870
    Blog Entries
    3

    Default Re: 12.3: restore: This restore version doesn't support bzlib decompression

    Quote Originally Posted by tsu2 View Post
    I think most backup/recovery tools assume you're restoring to the <same> OS and level OS.
    No, I disagree.

    One of the uses of backup is to move to newer hardware and migrate data to a new system release.

    Quote Originally Posted by tsu2 View Post
    As each OS is released, a newer version of the backup and recovery tool should be expected.
    I agree with this. However, backup/restore software should maintain upward compatibility. That is, newer versions of the software should be able to handle older versions of the data. It is unreasonable to expect older software versions to handle newer data.

    This upward compatibility need not be forever, but it does need to be able to span several versions.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •