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

English Applications
1

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

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.

3

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

  1. format/install
  2. 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

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

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

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

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

No, I disagree.

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

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.