I was expecting an error message for the first entry beacuse the name is all nulls but pax doesn't complain about it. This is strange.

Anyway, I guess you can just use pax to extract the backup instead of tar, you need to have a look at its manual page for the syntax.

You may also want to check what /usr/sfw/gtar thinks about your archive.

Yes, strange, indeed. I'm afraid of tar, now, because I was just so confident that I would experience no problem with it... I had also checked largefile man page to be sure that no caveat existed. By the way, I'm slowly checking all of the files (I've to decompress them before) and let you know. I just checked the 3rd and it shows the same problem. What I did was just tar cEvf, then bzip2, then bunzip2 so I expect the problem to be tar's... Very strange indeed.

I'm doing it know and this seems to work:
I also tried gtar and it starts extracting, indeed, but issuing many warnings about unrecognized headers, which is to be expected.

Isn't it reasonably normal doing tarballs of many gigabytes?
Do you think this can be a tar bug?

I never had such an issue with tar but I usually avoid using it for complete filesystem backups as it isn't the best tool for that. If the filesystem is ufs, ufsdump is much better although non portable to another O/S, otherwise I often use cpio. "zfs export" is the right tool for ZFS.

That said, I still doubt it can be a tar bug. Perhaps your source filesystem has wierd files on it, or perhaps some short lived files disappearing.

What is the precise command you used to create the archives ?

Are you sure no error message was output during the backup ?

Thanks for the suggestions, jlliagre. What I was doing was this: I had zpool with 2 disks (RAID 0) and I had 4 file systems on it. Furthermore, I had another UFS partition from which I wanted to backup a directory tree and another disk with a FAT32 on it. So, I didn't think to dump the file systems because what I wanted to do wasn't a restoring them, but reorganizing their union on appropriate ZFS file system (on a single parity RAID Z, that's why I was going to destroy the first pool).

The machine was isolated, so I don't think a file could disappear. Furthermore I already moved all that information from my old Linux system some time ago, with GNU tar, and I had no problem doing it.

I did this most of the times:
tar cEvf - backup | bzip2 > backup.tar.bz2

To say the truth I didn't checked all of the output, I just spent some minutes monitoring the beginning. But if the problem was in the first bytes, that's strange. Now I realize that I didn't check tar exit code, because when I issued echo $? I was checking bzip2 exit code, instead.

Yes, tar error messages are often lost in the middle of quickly scolling file names. Better to either avoiding using the "v" flag or just redirecting stderr to a log file for later examination.

Thanks. I already banned "v".

By the way, 3 over 6 files were affected and I really cannot realize what's been the difference between these 3 backup and the others. Anyway, pax could extract all of the files from these broken archives and it appears as if I had lost nothing.

Thanks everybody for the help!
Enrico.