On Thu, Mar 10, 2005 at 08:13:42PM -0500, Marc N. Cannava wrote:
> Hi all,
>
> I've been using Amanda for a while with no issue.
>
> I recently moved from RH9 to Gentoo and re-installed amanda with the
> latest version available in the ebuild tree (amanda 2.4.4_p3). Using my
> same config files
On Thu, Mar 10, 2005 at 04:41:00PM -0800, Kevin Dalley wrote:
> I ran amstatus as follows:
> sudo su - backup -c 'amstatus normal --dumping --writing --summary
> --waitdumping'
>
> It included the following line:
>
> condor://linnet/g$ 17k flushing to tape (14:27:46)
>
> However
On Fri, Mar 11, 2005 at 02:15:07AM +, Bruce S. Skinner wrote:
> Hmmm,
>
> I've considered all the good suggestions, but it isn't anything like
> write-protect or anything that simple (after all I just used amlabel
> to label 12 tapes). I installed the manual changer to no effect.
> I've looke
> > > DISK planner alsike alsike_root
> > > DISK planner alsike alsike_boot
> > > DISK planner alsike alsike_archive_a
> > > DISK planner alsike alsike_archive_b
> > > DISK planner alsike alsike_home
> > > START planner date 20050310
- -
- - - -
amflush: start at Fri Mar 11 01:54:27 GMT 2005
amflush: datestamp 20050311
FLUSH alsike alsike_archive_a 20050310 0
/var/spool/amanda/20050310/alsike.alsike__archive__a.0
FLUSH alsike alsike_boot 20050310 0
/var/spool/amanda/20050310/alsike.alsike__boot.0
FLUSH a
ets start rolling onto my holding disk. The smallest
> > dump is alsike_boot at 28MB so it's done first and when taper attempts
> > to write it says:
> >
> > FAIL taper alsike alsike_boot 20050310 0 [out of tape].
> >
> > I'm running a DLT8000 with
Ah!! I found the log.
This is what Amanda said from the last run:
taper: read label `Homenet18' date `X'
taper: wrote label `Homenet18' date `20050310'
planner: time 231.726: got result for host ziyal disk /data2/public: 0
-> 2071100K, 1 -> 2071100K, 2 -> 207110
On Mar 10, 2005, at 8:36 PM, Kevin Dalley wrote:
Do you have something like this in your amdump file:
planner: time 1817.635: got result for host condor disk //bunting/e$:
0 -> 5524252K, 1 -> 108113K, 2 -> 108113K
You know, I just realized that Amanda isn't logging where I expect
(/tmp/amanda).
Do you have something like this in your amdump file:
planner: time 1817.635: got result for host condor disk //bunting/e$: 0 ->
5524252K, 1 -> 108113K, 2 -> 108113K
It should verify that it calculates the level 0 and level 1 backups.
Is the level 0 actually written entirely to disk (or tape).
Hi all,
I've been using Amanda for a while with no issue.
I recently moved from RH9 to Gentoo and re-installed amanda with the
latest version available in the ebuild tree (amanda 2.4.4_p3). Using my
same config files and backing up to disk (using chg-disk).
Very, very odd problem now: No matter
I just tried the latest subversions release of samba on the SAMBA_3_0
branch. Files have stopped disappearing, and the memory leak is
gone. Last night's backup was one of the cleanest I have had in
ages. Here's the latest information on this samba patch.
https://bugzilla.samba.org/show_bug.cgi?
I ran amstatus as follows:
sudo su - backup -c 'amstatus normal --dumping --writing --summary
--waitdumping'
It included the following line:
condor://linnet/g$ 17k flushing to tape (14:27:46)
However, this backup is quite a bit bigger than 7k.
[EMAIL PROTECTED]:/archive/jon$ su
; backup amcheck -sclt Norstead) which reports all is ok;
>
> I invoke amdump (sudo -u backup amdump Norstead) the estimates get
> done and dump sets start rolling onto my holding disk. The smallest
> dump is alsike_boot at 28MB so it's done first and when taper attempts
> to
If you place this line in your amanda.conf:
autoflush on
then you don't have to worry about this type of problem in the
future. Anything left over from the previous run will be flushed
without the need for an amflush. Sometimes, my tape fails partway
through, or I run out of memory, or some oth
On Thu, 2005-03-10 at 22:41 +0100, Paul Bijnens wrote:
> Erik P. Olsen wrote:
>
> > There was nothing left in the staging area, but what made me suspicious
> > was the fact that the amflush command took so little time to complete.
> >
>
> That's probably becuase with the default value for "reser
Erik P. Olsen wrote:
There was nothing left in the staging area, but what made me suspicious
was the fact that the amflush command took so little time to complete.
That's probably becuase with the default value for "reserved", 100%,
all of the holdingdisk is reserved for incremental backups when
fa
On Thu, 2005-03-10 at 11:44 -0500, Gene Heskett wrote:
> On Thursday 10 March 2005 10:25, Erik P. Olsen wrote:
> >I have had a peculiar situation where a back-up failed to succeed.
> > The error message was:
> >epo.dk /var lev 2 FAILED [no more holding disk space]
> >
> >It later turned out not
7;s done first and when taper attempts
> to write it says:
>
> FAIL taper alsike alsike_boot 20050310 0 [out of tape].
>
> I'm running a DLT8000 with no tape changer, but have set "runtapes 3"
> with "autoflush on" on the assumption that when a tape gets fu
writetab on the tape.
I invoke amdump (sudo -u backup amdump Norstead) the estimates get
done and dump sets start rolling onto my holding disk. The smallest
dump is alsike_boot at 28MB so it's done first and when taper attempts
to write it says:
FAIL taper alsike alsike_boot 20050310 0 [out of
7;s done first and when taper attempts
> to write it says:
>
> FAIL taper alsike alsike_boot 20050310 0 [out of tape].
>
> I'm running a DLT8000 with no tape changer, but have set "runtapes 3"
> with "autoflush on" on the assumption that when a tape g
Bruce S. Skinner wrote:
I'm running a DLT8000 with no tape changer, but have set "runtapes 3"
with "autoflush on" on the assumption that when a tape gets full it
will wait for me to load another and kick it with amflush.
I'm not sure if this is related to your error message, but for this
behaviour
ll is ok;
I invoke amdump (sudo -u backup amdump Norstead) the estimates get
done and dump sets start rolling onto my holding disk. The smallest
dump is alsike_boot at 28MB so it's done first and when taper attempts
to write it says:
FAIL taper alsike alsike_boot 20050310 0 [out of tape].
I&
On Thursday 10 March 2005 10:25, Erik P. Olsen wrote:
>I have had a peculiar situation where a back-up failed to succeed.
> The error message was:
>epo.dk /var lev 2 FAILED [no more holding disk space]
>
>It later turned out not to be too little holding disk space. I had
>simply forgotten to se
On Thu, 2005-03-10 at 16:25 +0100, Erik P. Olsen wrote:
> I have had a peculiar situation where a back-up failed to succeed. The
> error message was:
> epo.dk /var lev 2 FAILED [no more holding disk space]
>
> It later turned out not to be too little holding disk space. I had
> simply forgotte
I have had a peculiar situation where a back-up failed to succeed. The
error message was:
epo.dk /var lev 2 FAILED [no more holding disk space]
It later turned out not to be too little holding disk space. I had
simply forgotten to set the write inhibit switch off when I inserted the
tape. Of c
25 matches
Mail list logo
