1

I have a client whose sites were migrated to a new server back in 2012, and I am trying to piece together the old archive to retrieve one of the sites that was not moved. I found a set of files in a temp directory on the new host that had 15 files in it, all named "obfw" followed by 6 random characters, and all randomly dated, ranging from 0 bytes to 207MB. They are all archives, and if I append .tar.gz to the end of any of them (aside from the 0 byte one) and open them with the archive manager, they all show that they are archives for a 2GB folder named backup-9.8.2012_13-35-26_p24acata, all from the same date (which is the date that they were migrated). I have tried joining the files together in various orders (alpha, alpha reversed, by apparent dates), and each one dies when I try and extract the resulting archive either with "truncated gzip input" or "gzip compression failed". However, it appears that the different orders that I cat the files together in give varying amounts of the correct data, so it definitely seems like there is at least a chance that they can all be recombined to create a valid archive.

Is there a way to read the headers of these fragments to see what order I should put them in?

1

You need to compose all possible orders. A Perl way:

#!/usr/bin/perl
use Algorithm::Permute;

@files = grep /^archive/, <*>;

my $p = new Algorithm::Permute([@files]);

while (@res = $p->next) {
    print "order='", join ' ', @res,"'\n";
    print "cat \$order > perm.tar.xz\n";
    print "tar xvJf perm.tar.xz\n";
}

and

perl compose.pl|bash 

Depending of the number of chunks the complexity is n!. See also Permutation.

0

There's a contradiction here:

I have tried joining the files together in various orders (alpha, alpha reversed, by apparent dates), and each one dies when I try and extract the resulting archive either with "truncated gzip input" or "gzip compression failed". However, it appears that the different orders that I cat the files together in give varying amounts of the correct data,

If they don't work and throw an error, in what sense do they give an amount of correct data?

Anyway, if they all work as tar files individually but are truncated, you are probably out of luck; tar files start with a header which is where the information comes from. So any file which appears to be a tar file this way is a tar file -- it is not a piece from the middle of one, since such a piece would not contain a header. Particularly not a header in exactly the right place, that works to allow them to function as an individual tar file.

However, if you look at what you can actually find in each piece, they might contain different pieces for whatever reason; they might also just contain the same thing in varying lengths.

0

If all non-zero size files show that they are tar file then they are. It is more easy to check that using the file command from the commandline, no need to rename the files for that.

However concatenating tar files doesn't get you a new tar file to extract, you can try to do that with something like:

$ echo a > a
$ echo b > b
$ tar cvf a.tar a
a
$ tar cvf b.tar b
b
$ cat a.tar b.tar > c.tar
$ tar tvf c.tar
-rw-rw-r-- anthon/users      2 2014-02-21 07:34 a

Notice that b is not shown in the result of tar (it is there, but there is some end of file marker at the end of a.tar which makes tar stop reading from the file.

So concatenating the tar files together as you indicate will not help. What you can try is extract the content from the tar files one at the time and look at any files in the directory (what you indicate as "folder") and use file on that extracted data to see if you find something that is some archive type. Hopefully you find some thing makes sense (another, possible compressed, tar or cpio archive, what would be the header and work from there by concatenating the output together.

Make sure to rename each extracted output directory/folder since they all have the same name.

There might be extra information in the tar files (or at the end beyond the tar marking marker) that the program that created these files can use for reconstruction:

$ echo xxxx >> a.tar
$ tar tvf a.tar
-rw-rw-r-- anthon/users      2 2014-02-21 07:34 a

without knowing the program that made this.


The 2GB parts make sense as there is this filesize limit on older (file-)systems. Archives of videofiles where the first ones for me to hit that limit back in the mid 90's and I had to switch from using EFS to XFS as filesystem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.