--On Friday, February 13, 2004 22:48:36 -0600 Fran Fabrizio <fran AT cis.uab
DOT edu> wrote:
>
> I have figured out the problem. The index for this problem filesystem (/www)
> has 99.9999999% of its entries preceeded by a string of numbers, like:
>
> 10010135161/./www/httpd/htdocs/info/mrmsd/cgi-bin/source.C_mainly.d/c/backup/1997102919_nph-sss.c.gz
> 10010134067/./sol8/pack.d/netscape_patches/108528-16/FJSVhea/reloc/usr/platform/sun4us/include/sys/machcpuvar.h
>
> then is has a very few lines that look normal, like:
>
> /www/httpd/htdocs/info/faculty/reilly/mrmsd/cgi-bin/source.C_mainly.d/c/backup/1997102919_nph-sss.c.gz
>
> Only the normal lines are showing up. Two questions:
>
> What is prepending this string of numbers and why? Wrong version of tar on
> the Solaris box perhaps? *looks* tar (GNU tar) 1.13.25
Yes, the leading numbers are a symptom of a broken version of tar.
However, 1.13.25 should be a working version. Look in your
/tmp/amanda/*.debug files on the client and see the full path of
tar that Amanda was configured with. I suspect that you may have
two different versions of tar on the box and Amanda is using a
broken one.
>
> If I were to take the index file, make a copy, strip the numbers and /./ out
> of the copy, and put it in place, would that work? (Writing some perl to
> find out, so this is somewhat of a rhetorical question. :-)
I don't think that works (or at least it didn't when I tried it a
few years ago). I recall havng to use amrestore to extract the
image and untar it somewhere, then manually dig through it to find
the files you want. You can then script renaming the directory
tree once you figure out which numbers correspond to which directory.
Fortunately I didn't have to do that as I was just needing a few
files from one subdirectory.
Good luck,
Frank
>
> Thanks,
> Fran
>
>
>
>
>
>> Yeah, something else is going on... the file was never deleted, it's still
>> there, I just accidentally blew over the new version with the old. Yes,
>> it defaults to today if you don't explicitly set the date, and the file
>> was definitely there today (and every day before it for many, many
>> months), so I -should- be seeing it. And then I did go back and look at
>> the index, and also set the date to the day of the full backup, and
>> neither of those enabled me to see the file. Weird, eh?
>>
>> Client is Solaris, Server is RH9 linux, Amanda is 2.4.4p2, if that's a
>> helpful clue. Color me baffled.
>>
>> -Fran
>>
>> Frank Smith wrote:
>>> --On Friday, February 13, 2004 16:13:10 -0600 Fran Fabrizio
>>> <fran AT cis.uab DOT edu> wrote:
>>>
>>>> I am trying to restore a file from my web document root. This is an
>>>> area that's been very static (except for today when I blew on top of
>>>> something I shouldn't have :-) I went to run amrecover, and it's only
>>>> showing files that have changed recently.
>>>> For example:
>>>>
>>>> /www
>>>> /htdocs
>>>> /staticarea
>>>> /news
>>>> /studentpages
>>>> /joeuser
>>>>
>>>> Ok, so my disklist is set to backup /www. None of these are symlinks or
>>>> anything out of the ordinary. So I run amrecover, and starting at /www,
>>>> what I see is...
>>>>
>>>> amrecover> ls
>>>> 2004-02-13 htdocs/
>>>> amrecover> cd htdocs
>>>> /www/htdocs
>>>> amrecover> ls
>>>> 2004-02-13 studentpages/
>>>> amrecover> cd studentpages
>>>> /www/htdocs/studentpages
>>>> amrecover> ls
>>>> 2004-02-13 joeuser/
>>>> /www/htdocs/studentpages/joeuser
>>>> amrecover> ls
>>>> 2004-02-13 filejoeuserchangedrecently.html
>>>> amrecover>
>>>>
>>>> Am I not understanding how amrecover works? Shouldn't I be seeing all
>>>> the files in that area? I want to restore
>>>> /www/htdocs/staticarea/news/page.html, how do I go about this?
>>>
>>> You should be seeing all the files as of the last backup. I think
>>> it defaults to today if you don't use setdate. Perhaps the missing
>>> files were deleted before the last backup. If so, just use setdate to
>>> go back in time until you find them.
>>>
>>>
>>>> Am I having a stupid Friday afternoon moment, or is this messed up? Did
>>>> my index get hosed or something?
>>>
>>> If you know the files were still there during the last backup, perhaps
>>> your index files are corrupt (most likely due to a bad [ < 1.13.19 ?]
>>> version of tar). Look at your index files on the server for that client
>>> and see if there are big numbers in front of the paths. If so, it is
>>> the tar problem. You can still restore the files, it will just take
>>> extra work (a lot of it if you have a large directory tree) to rename
>>> all the directories after the restore.
>>> If the index files look ok, something else is going on.
>>> Frank
>>>
>>>> -Fran
>>>>
>>>> --
>>>> Fran Fabrizio
>>>> Senior Systems Analyst
>>>> Department of Computer and Information Sciences
>>>> University of Alabama - Birmingham
>>>> fran AT cis.uab DOT edu
>>>> (205) 934-0653
>>>
>>
>> --
>>
>> Fran Fabrizio
>> Senior Systems Analyst
>> Department of Computer and Information Sciences
>> University of Alabama - Birmingham
>> fran AT cis.uab DOT edu
>> (205) 934-0653
>>
>
> Fran Fabrizio
> Senior Systems Analyst
> Department of Computer and Information Sciences
> University of Alabama - Birmingham
> fran AT cis.uab DOT edu
> (205) 934-0653
|
