[OpenAFS] Re: recover data from corrupted volume

[Dimitris Z]

Thanks everyone for your replies.

It looks like the rsync I did did not preserve ownership information.
This may explain why the salvager cannot do a proper restoration of
the volumes or why the volumes are not working. Is there a way to get
around this? It does not really matter if they are salvaged with the
correct owner, as long as they can be salvaged.

Other than that running a quick file on  the backup returns lots of
useful data preserved, for example

/AFSIDat/p1/pT++U/+/N/b61++wuT=: raw G3 data, byte-padded
./AFSIDat/p1/pT++U/+/N/zA1++I6U=: raw G3 data, byte-padded
./AFSIDat/p1/pT++U/+/N/C91++gqx: ELF 32-bit LSB executable, Intel
80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses
shared libs), not stripped
./AFSIDat/p1/pT++U/+/N/181++oyT=: raw G3 data, byte-padded
./AFSIDat/p1/pT++U/+/N/G91++QuX=: a bbrpywrapper script text executable
./AFSIDat/p1/pT++U/+/N/oA1++UvX=: Tenex C shell script text executable
./AFSIDat/p1/pT++U/+/N/V91++U1U=: raw G3 data, byte-padded
./AFSIDat/p1/pT++U/+/N/Y61+++pX=: Bourne-Again shell script text executable
./AFSIDat/p1/pT++U/+/N/7C1++E9U=: raw G3 data, byte-padded
./AFSIDat/p1/pT++U/+/N/qC1++AzX=: perl script text executable
./AFSIDat/p1/pT++U/+/N/j71++AyT=: raw G3 data, byte-padded

I have not found much in K1 or zzzzz

Best regards,


On Wed, Jan 16, 2013 at 9:45 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> On Wed, 16 Jan 2013 19:11:39 +0100
> Stephan Wiesand <stephan.wiesand@desy.de> wrote:
>
>> On Jan 16, 2013, at 18:25 , Dimitris Z wrote:
>>[...]
>> > 01/16/2013 17:14:45 totalInodes 6446
>
> Presumably you have at least some data there. The salvager found a bunch
> of inodes relevant to that volume, so you certainly haven't lost
> everything. But it probably deleted them all on salvage because the
> volume metadata is screwed up.
>
>> If there are remnants left, you should find them in AFSIDat/K1/Kz++U .
>> If you can't find that directory, look for the files named
>> zzzz5Mx1++0, zzzz9Mx1++0, zzzzDMx1++0, zzzzPMx1++0, possibly in
>> lost+found. If you can't find any of those, I'm out of ideas/hope.
>
> If it's not clear, look at this stuff before you salvage. For the most
> part, the files in AFSIDat/K1/Kz++U are plain file blobs; there's no
> structure or mangling or anything like that. The exceptions are the
> metadata files in the dir called 'special', and the directory blobs. The
> 'special' files you can easily skip by just not looking at the 'special'
> directory, but the directory blobs look like normal files. You could
> filter out the directory blobs I think based on the filename, but I'd
> have to think about how specifically to do that.
>
> If you want to get back the directory structure and filenames and all
> that, it's may still be possible, but you need to do some work messing
> around with the volume metadata. That's probably not worth it if you're
> fine with getting files back without their name or dir structure.
>
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info