Why is it just sitting here?
I started a backup last night, manually running 'amdump DailySet1'. Now this
morning, amstatus reports that it is all done, except for one thing (the other
lines say "finished"):
navajo.hq.consys.com://vekol/data0 2715147k dumping to tape
The tape drive doesn't seem to be doing anything, usually the little green light
flashes when it's active. Right now it's just sitting there. The holding disk
just has an empty subdirectory in it. It seems to be stuck somehow. The hard
disk that //vekol/data is on isn't even being accessed, it's quiet (makes lots
of noise when it's being backed up).
Why is this one trying to dump directly to tape, instead of to the holding disk
first?
Why would it stall out like it seems to have done?
If it is actually stuck, I suppose I can kill the amdump process with a ctrl-C
command, but then a flush wouldn't do anything, because this data isn't on the
holding disk, right? I would have to do an amcleanup. And I wouldn't get the
emailed report, either, would I?
Is there any way of gracefully regaining control without just killing amdump?
Following is information for you experts out there who might have ideas. Thanks
in advance for any and all advice!
--- Eric Wadsworth
[EMAIL PROTECTED]
My holding disk has sixty gigabytes of available space (that's not a typo).
The tape can hold 20 gigs (40 compressed).
Information on this particular samba share:
This happens to be a directory on my own NT workstation. The 'data' samba share
is 7.2 Gigs in size, but some portions of this share have their permissions set
such that the backup operators cannot read them (security policy requires that a
particular project not be included in the backup) leaving about 5 gigs of data
to back up. I'm using compression, so the 2.7 gig number makes sense. Several
other NT boxes have similiar exclusions, and they backed up fine.
Here's the summary from amstatus. (Ignore the 2 failed entries, the user of that
NT box did a "shutdown" instead of logging out. Silly users.)
SUMMARY part real estimated
size size
partition : 39
estimated : 37 14376628k
failed : 2 0k
wait for dumping: 0 0k
dumping to tape : 12715147k
dumping : 00k0k
dumped : 36 12531488k 11661481k
wait for writing: 00k0k
writing to tape : 00k0k
failed to tape : 00k0k
taped : 36 12531488k 11661481k
3 dumpers idle : not-idle
taper writing, tapeq: 0
network free kps: 1970
holding space : 53545924
Here's the pertinent line from disklist:
navajo.hq.consys.com //vekol/deneb css-nt-workstations
Here's some lines from amanda.conf:
define dumptype css-global {
comment "CSS Global definitions"
index yes
program "GNUTAR"
}
define dumptype css-nt-workstations {
css-global
comment "User's Windows NT workstations"
priority medium
compress client best
}
Re: Why is it just sitting here?
Mine did this. It turned out the filesystem being dumped was just a little bigger
than my dump disk had free. What it turns out was happeneing is I was doing
Server compression so it was sending the filesystem to my server to compress
and it was then being written to tape directly. It wasn't streaming fast enough
for me to see without sitting for quite a while and watching the drive. I
litterally
had to cancel that nights backups and I let it run out of curiosity.
It finished and then the level 1 the next night ran great.
Do an "mt status -f /dev/". It will tell you if the device is locked or
busy.
Eric Wadsworth wrote:
> I started a backup last night, manually running 'amdump DailySet1'. Now this
> morning, amstatus reports that it is all done, except for one thing (the other
> lines say "finished"):
>
> navajo.hq.consys.com://vekol/data0 2715147k dumping to tape
>
> The tape drive doesn't seem to be doing anything, usually the little green light
> flashes when it's active. Right now it's just sitting there. The holding disk
> just has an empty subdirectory in it. It seems to be stuck somehow. The hard
> disk that //vekol/data is on isn't even being accessed, it's quiet (makes lots
> of noise when it's being backed up).
>
> Why is this one trying to dump directly to tape, instead of to the holding disk
> first?
> Why would it stall out like it seems to have done?
> If it is actually stuck, I suppose I can kill the amdump process with a ctrl-C
> command, but then a flush wouldn't do anything, because this data isn't on the
> holding disk, right? I would have to do an amcleanup. And I wouldn't get the
> emailed report, either, would I?
> Is there any way of gracefully regaining control without just killing amdump?
>
> Following is information for you experts out there who might have ideas. Thanks
> in advance for any and all advice!
>
> --- Eric Wadsworth
> [EMAIL PROTECTED]
>
> My holding disk has sixty gigabytes of available space (that's not a typo).
> The tape can hold 20 gigs (40 compressed).
>
> Information on this particular samba share:
> This happens to be a directory on my own NT workstation. The 'data' samba share
> is 7.2 Gigs in size, but some portions of this share have their permissions set
> such that the backup operators cannot read them (security policy requires that a
> particular project not be included in the backup) leaving about 5 gigs of data
> to back up. I'm using compression, so the 2.7 gig number makes sense. Several
> other NT boxes have similiar exclusions, and they backed up fine.
>
> Here's the summary from amstatus. (Ignore the 2 failed entries, the user of that
> NT box did a "shutdown" instead of logging out. Silly users.)
>
> SUMMARY part real estimated
> size size
> partition : 39
> estimated : 37 14376628k
> failed : 2 0k
> wait for dumping: 0 0k
> dumping to tape : 12715147k
> dumping : 00k0k
> dumped : 36 12531488k 11661481k
> wait for writing: 00k0k
> writing to tape : 00k0k
> failed to tape : 00k0k
> taped : 36 12531488k 11661481k
> 3 dumpers idle : not-idle
> taper writing, tapeq: 0
> network free kps: 1970
> holding space : 53545924
>
> Here's the pertinent line from disklist:
> navajo.hq.consys.com //vekol/deneb css-nt-workstations
>
> Here's some lines from amanda.conf:
> define dumptype css-global {
> comment "CSS Global definitions"
> index yes
> program "GNUTAR"
> }
>
> define dumptype css-nt-workstations {
> css-global
> comment "User's Windows NT workstations"
> priority medium
> compress client best
> }
--
: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);'
Re: Why is it just sitting here?
Ah, interesting! 'mt status' shows that yes, indeed, the tape drive is busy.
But the holding disk has 60 gigs free... and I'm using client compression,
although since it is a samba share, and the samba server is also the tape host,
that UNIX machine is doing all the compression anyway.
The mystery still exists, why is it writing directly to tape instead of using
the holding disk?
But I'll take your advice, and just let it sit for now. In fact, I'll go over
and stare at the tape drive for a while.
--- Eric
"Robert L. Harris" wrote:
>
> Mine did this. It turned out the filesystem being dumped was just a little bigger
> than my dump disk had free. What it turns out was happeneing is I was doing
> Server compression so it was sending the filesystem to my server to compress
> and it was then being written to tape directly. It wasn't streaming fast enough
> for me to see without sitting for quite a while and watching the drive. I
> litterally
> had to cancel that nights backups and I let it run out of curiosity.
>
> It finished and then the level 1 the next night ran great.
>
> Do an "mt status -f /dev/". It will tell you if the device is locked or
> busy.
> Eric Wadsworth wrote:
>
> > I started a backup last night, manually running 'amdump DailySet1'. Now this
> > morning, amstatus reports that it is all done, except for one thing (the other
> > lines say "finished"):
> >
> > navajo.hq.consys.com://vekol/data0 2715147k dumping to tape
> >
> > The tape drive doesn't seem to be doing anything, usually the little green light
> > flashes when it's active. Right now it's just sitting there. The holding disk
> > just has an empty subdirectory in it. It seems to be stuck somehow. The hard
> > disk that //vekol/data is on isn't even being accessed, it's quiet (makes lots
> > of noise when it's being backed up).
> >
> > Why is this one trying to dump directly to tape, instead of to the holding disk
> > first?
> > Why would it stall out like it seems to have done?
> > If it is actually stuck, I suppose I can kill the amdump process with a ctrl-C
> > command, but then a flush wouldn't do anything, because this data isn't on the
> > holding disk, right? I would have to do an amcleanup. And I wouldn't get the
> > emailed report, either, would I?
> > Is there any way of gracefully regaining control without just killing amdump?
> >
> > Following is information for you experts out there who might have ideas. Thanks
> > in advance for any and all advice!
> >
> > --- Eric Wadsworth
> > [EMAIL PROTECTED]
> >
> > My holding disk has sixty gigabytes of available space (that's not a typo).
> > The tape can hold 20 gigs (40 compressed).
> >
> > Information on this particular samba share:
> > This happens to be a directory on my own NT workstation. The 'data' samba share
> > is 7.2 Gigs in size, but some portions of this share have their permissions set
> > such that the backup operators cannot read them (security policy requires that a
> > particular project not be included in the backup) leaving about 5 gigs of data
> > to back up. I'm using compression, so the 2.7 gig number makes sense. Several
> > other NT boxes have similiar exclusions, and they backed up fine.
> >
> > Here's the summary from amstatus. (Ignore the 2 failed entries, the user of that
> > NT box did a "shutdown" instead of logging out. Silly users.)
> >
> > SUMMARY part real estimated
> > size size
> > partition : 39
> > estimated : 37 14376628k
> > failed : 2 0k
> > wait for dumping: 0 0k
> > dumping to tape : 12715147k
> > dumping : 00k0k
> > dumped : 36 12531488k 11661481k
> > wait for writing: 00k0k
> > writing to tape : 00k0k
> > failed to tape : 00k0k
> > taped : 36 12531488k 11661481k
> > 3 dumpers idle : not-idle
> > taper writing, tapeq: 0
> > network free kps: 1970
> > holding space : 53545924
> >
> > Here's the pertinent line from disklist:
> > navajo.hq.consys.com //vekol/deneb css-nt-workstations
> >
> > Here's some lines from amanda.conf:
> > define dumptype css-global {
> > comment "CSS Global definitions"
> > index yes
> > program "GNUTAR"
> > }
> >
> > define dumptype css-nt-workstations {
> > css-global
> > comment "User's Windows NT workstations"
> > priority medium
> > compress client best
> > }
>
> --
>
> :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),(u
Re: Why is it just sitting here?
On Nov 28, 2000, Eric Wadsworth <[EMAIL PROTECTED]> wrote:
> The mystery still exists, why is it writing directly to tape instead
> of using the holding disk?
Look for `chunksize' in the man-page, the FAQ and/or the sample
configuration file.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why is it just sitting here?
Ah! This was it! Thanks so much! --- Eric Alexandre Oliva wrote: > > On Nov 28, 2000, Eric Wadsworth <[EMAIL PROTECTED]> wrote: > > > The mystery still exists, why is it writing directly to tape instead > > of using the holding disk? > > Look for `chunksize' in the man-page, the FAQ and/or the sample > configuration file. === Eric Wadsworthemail: [EMAIL PROTECTED] Conceptual Systems and Software http://www.consys.com ===
