Hi,
Nevermind folks, I figured it out. Guess I just panicked because it was
the Friday before Christmas... ;)
The problem was large filesystems that were all scheduled for level 0
dumps. Amanda was timing out before dump was finished estimating the
sizes. Increasing "etimeout" in amanda.conf
Hi,
I'd *really* like to fix this before the holidays... ;)
My tapehost can't seem to back itself up. Last night's report indicates
"request timed out", as does a subsequent amcheck. I've consulted the
FAQ for amcheck, and since /tmp/amanda/amandad.debug had not been
rewritten since the previo
Hi,
Every time I look at Amanda's debug output I learn something new...
Can anyone tell me what the last message means in this sendsize.debug
excerpt?
DUMP: Date of this level 2 dump: Tue Dec 12 01:53:14 2000
DUMP: Date of last level 1 dump: Wed Dec 6 02:25:22 2000
DUMP: Dumping /dev/rda0s
Yann PURSON wrote:
>
> >
> >
> >> Total bytes listed: -993766132
> >> .
> >
> >
> > Are you trying to backup files, or images larger than 2GB?
>
> I was just trying to backup a single directory with one small file in it
> (it was just a test...)...
>
> >
> > Have you applied the samba patch
Nevermind folks. Sandro Ferrand was kind enough to prod my gray matter
and I realized I had not put the operator user into the disk group. I
told you it was a simple mistake! ;^)
Thanks,
Eric
--
Eric Sproul, Systems Administrator
Cornerstone Networks Inc. (http://www.cstone.net)
Yann PURSON wrote:
>
> FAILURE AND STRANGE DUMP SUMMARY:
> deuterium //NT-AGENCE/Public lev 0 FAILED [disk //NT-AGENCE/Public
> offline on deuterium?]
Yann,
I am having exactly the same problem. I have been asking on the samba
list about why smbclient reports a negative size for the dump. Wh
Hi,
I am setting up a new backup client and have copied as much as possible
the config from a similar working client. My OS is Redhat 6.2. I have
configured Amanda 2.4.1p1 from source thusly:
--with-user=operator
--with-group=disk
--without-server
--with-amandahosts
.amandahosts is installed a
Hi,
Got a new problem...
Backing up a FreeBSD 4.0 box, the client does not report any problems
during amcheck, but after the nightly run, the summary reports:
real.cho.c da0s1a lev 0 FAILED [could not connect to
real.cho.cstone.net]
It seems to connect fine during the check process? Here's the
"John R. Jackson" wrote:
>
> >>ERROR: admin1.corp.walid.com: [can not read/write /etc/dumpdates: No such
> >>file or directory]
> >...
> >Go chown /etc/dumpdates back to user amanda and it will be fine.
>
> If it was a permissions problem, the error code would have said
> "permission denied" or
"Eric A. Sproul" wrote:
> So the byte size is normal-looking but now it doesn't report the file
> entries as it did before. Is this a Samba issue? If so I'll quit
> bugging you guys... ;^)
Whoops, my bad. This time it worked (just got the notification), but
one
"Eric A. Sproul" wrote:
>
> "John R. Jackson" wrote:
> >
> > By "it" you mean Samba, right? Because it's clearing giving Amanda
> > garbage and so isn't Amanda's fault.
>
> I guess so. I have removed the rpm version a
"John R. Jackson" wrote:
>
> By "it" you mean Samba, right? Because it's clearing giving Amanda
> garbage and so isn't Amanda's fault.
I guess so. I have removed the rpm version and done a vanilla install
of Samba 2.0.7 from source.
>
> Have you applied the patches on the Amanda web page (ww
Hi,
I've been searching the archives for a solution to this, and I am
reasonably sure it has something to do with sendsize. Maybe someone
here can clarify, because I'm not *entirely* sure how this works...
Tapehost is FreeBSD 3.2 running amanda-2.4.1p1 compiled from source
Amanda client is Linux
13 matches
Mail list logo
