On Mon, 4 Dec 2006, Ian R. Justman wrote:
I managed to get things working on limiting the files I want in a given set,
but it hasn't solved my larger problem, the ethernet interface goes down
during the course of the backup, but bounces back online. From what I've
been able to garner via
Just in case other people hit these problems and don't check the bug
tracker - I believe I've found and fixed (at least for my config) a couple
of problems in 2.5.1p1
1582254 - under some conditions skipping a DLE (because of strategy
skip in the dumptype definition) can cause the in-code
-Original Message-
From: Sean Noonan
Sent: 25 July 2006 22:45
snip
Use the -h option of amrestore to confirm if it was compressed,
probably with gzip.
If that is the case you will have to put a gzip -d command in
the pipeline between amrestore and restore.
My
From: Nicola Mauri
Sent: 31 May 2006 11:38
We are constantly encountering strange errors whith DLEs that
refer to cluster virtual addresses.
virtualA /apps/a lev 0 FAILED [data timeout]
virtualB /apps/b RESULTS MISSING
The disklist contains:
node1 /etc full
From: Paul Bijnens
Sent: 29 May 2006 10:07
On 2006-05-28 23:32, Ross Vandegrift wrote:
Approximately once a month, some of my servers fail to make backups
with this error message:
FAILURE AND STRANGE DUMP SUMMARY:
capote sda8 lev 1 FAILED [ [access as backup not
allowed
From: Ian Turner
Sent: 09 May 2006 16:54
On Tuesday 09 May 2006 11:06, Jon LaBadie wrote:
My autoloader is on /dev/st0 and tape are defined on /dev/nst0
I don't think so.
st0 and nst0 are the same device handled differenly on close.
The changer is probably on /dev/sg0 or /dev/sg1.
I've tracked down why three of my Amanda clients weren't working with my new
2.5.0 server. Problem is that these machines have virtual IP interfaces
(aliased interfaces like eth0:1) so that we can easily move services between
machines.
From monitoring the network traffic I can see that the
to indicate that this should just work (and
I'm just checked that the system is using the 2.5.0 taper - start of amdump log
says ...
taper: pid 17514 executable taper version 2.5.0)
Paul
-Original Message-
From: Paul Haldane
Jean-Louis Martineau said:
Are you on a machine where
]
taper: writing end marker. [AM1248 OK kb 89752352 fm 8]
chunker: error [bad command after RQ-MORE-DISK: QUIT]
chunker: time 20608.773: error [bad command after RQ-MORE-DISK: QUIT]
Paul
--
Paul Haldane
Unix Systems Team
Information Systems and Services
University of Newcastle upon Tyne
build: VERSION
From: Jim Summers
Sent: 03 April 2006 14:46
...
I checked it a little bit ago with amstatus and here is what
it is saying for that host/dle:
192095k dumping 108864k ( 56.67%) (0:21:55)
Is the 21:55 21hours and 55minutes?
Nope - that's the clock time that Amanda started doing
Jean-Louis Martineau said:
Are you on a machine where a LONG is 4 bytes in size?
Yup
Then it's an overflow, could you try the attached patch.
Thanks - patch applied, backup running, I'll let you know how it went tomorrow.
Paul
Paul Haldane wrote:
I've just installed 2.5.0 on one of our
so
I've managed to recover both times by killing off the amanda
processes. Next time this happens I plan to be less flustered :- and
hopeffully will have better data about what's causing the blockage.
Paul
--
Paul Haldane
Computing Service
University of Newcastle
making we very wary of adding our other two mail relays
to the Amanda schedule - I don't want to take all three out in one go :-.
Paul
--
Paul Haldane
Computing Service
University of Newcastle
build: VERSION=Amanda-2.4.2
BUILT_DATE=Tuesday August 29 12:24:57 BST 2000
BUILT_MACH
13 matches
Mail list logo
