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 <[email protected]> wrote: > On Wed, 16 Jan 2013 19:11:39 +0100 > Stephan Wiesand <[email protected]> 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 > [email protected] > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
