Apparently you are using Solaris platform. There are a bug in
Solaris's ufsrestore command. That bug is affected only on large
filesystem with a lot of files (e.g. over 30,000 files) You will
need to download patch from sunsolve.sun.com to fix the problem.
With the bug, ufsrestore was unable to generate a file listing for
amindex server. When sendbackup process on the client side makes a
dump, it pipes to ufsrestore to collect index information to be sent
to the Amanda index server. What happens is that when a dump is really
large and terminates with a "xtrmap: too many map entries" error and
never dumped the file listing to amindex server. Apparently it never
showed in
the debug files generated by sendbackup. I discovered the
error message only when I did an ufsrestore directly from the dump to
figure out why it never generated a file listing. So the patch listed
below will fix the xtrmap bug and will generate file listing for amindex
server.
I don't know which version or platform you are using but I'll list
all patch numbers for each platform.
SunOS 5.5.1/SPARC 104490-06
SunOS 5.5.1/x86 104491-06
SunOS 5.6/SPARC 105722-05
SunOS 5.6/x86 104723-05
SunOS 5.7/SPARC 106793-05
SunOS 5.7/x86 106794-05
Solaris 8 patches is available only for customers with support
contract with Sun:
SunOS 5.8/SPARC 109091-02
SunOS 5.8/SPARC 109092-02
If you don't have a support contract with Sun, let me know and
I can forward you the patch file for Solaris 8.
Josh
"Robert L. Harris" wrote:
> Ok,
> I decided to try a recover before I NEEDED to do one. I just did an
> "amoverview"
> and it showed a level 0 on my dumpserver last thurs, and level 1 on
> friday. I
> followed with this:
>
> {0}:powderday:/>amrecover
> AMRECOVER Version 2.4.1p1. Contacting server on
> powderday.vail.agency.com ...
> 220 powderday AMANDA index server (2.4.1p1) ready.
> 200 Access OK
> Setting restore date to today (2000-11-13)
> 200 Working date set to 2000-11-13.
> 200 Config set to DailySet1.
> 501 No index records for host: powderday.vail.agency.com. Invalid?
> Trying powderday.vail.agency.com ...
> 501 No index records for host: powderday.vail.agency.com. Invalid?
> Trying powderday.eriver.com ...
> 501 No index records for host: powderday.eriver.com. Invalid?
> Trying powderday ...
> 501 No index records for host: powderday. Invalid?
> Trying loghost ...
> 501 No index records for host: loghost. Invalid?
> amrecover> quit
>
> I have this in my disk list:
> powderday c0t0d0s0 generic-cb # /
> powderday c0t0d0s3 generic-cb # /var
> powderday c0t0d0s4 generic-cb # /opt
> powderday c0t0d0s6 generic-cb # /usr
> powderday c0t1d0s6 generic-cb #
> /export/home
>
> Thoughts?
>
> I put "powderday.vail.agency.com root" in my .amandahosts because
> it complained I wasn't allowed to connect. That error went away.
>
> Robert
>
> --
>
> :wq!
> ---------------------------------------------------------------------------
> Robert L. Harris | Micros~1 :
> Unix System Administrator | For when quality, reliability
> at Agency.com | and security just aren't
> \_ that important!
> DISCLAIMER:
> These are MY OPINIONS ALONE. I speak for no-one else.
> FYI:
> perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
