Re: odd behavior after adding DLE
Gene Heskett wrote:
Generally speaking, when amanda sets something up to do, it uses a set of
defaults derived from previous stanza's. My not too well educated guess
is that if none have been established, the really empty options list is
the problem.
I'm not convinced that the use of two '/services' strings in the disklist
is 100% kosher either. From perusing mine, the first string is the alias
or the FQDN of the machine to be backed up.
That was one idea I had but even with a symbolic name, Services it had
problems. The tradeoff for me is matching up names on the printed reports
with files on the systems. I tend not to use a symbolic name (the second field
in my case) if I don't have to. I simplified to the DLE to look like
cluster1-node1.wmi.com /services global 1 local
and had the same problem. Since this relies on only 1 dumptype entry there
shouldn't be an ordering problem. The dumptypes come after all the other
options.
Where the use of {} is brought into play, see this stanza in your disklist
if you just added to the default disklist:
What do you mean by the default disklist?
So by using '/services' twice, technically I believe its correct, but I'd
be wary of unwanted interactions just to be my usual somewhat paranoid
self. But I think the real error is in the order of the dumptype defines
in your amanda.conf.
I moved the dumptype define for this DLE to the bottom of amanda.conf and
the problem was still there. When I added strategy skip to the dumptype
define the problem went away. I don't claim this proves my config files
are correct but I feel that's the hint I am getting. Also, if there were
an issue with the order of entries in amanda.conf then moving the DLE in
the diskfile shouldn't make a difference.
I do have more data points. The backup ran ok last night with that DLE
at the bottom of the disklist file. I also added a duplicate DLE using a
cname for the host. Both completed without problems. There are also
other entries that were disabled with strategy skip. If I remove this
line from the dumptype I see the same problem.
I didn't expect these issues when we moved to our new servers. Then again,
I should know better. I've been down this road before and there is always
a surprise waiting for you.
- Joel
Re: odd behavior after adding DLE
On Friday 22 December 2006 07:36, Joel Coltoff wrote:
Gene Heskett wrote:
Generally speaking, when amanda sets something up to do, it uses a set
of defaults derived from previous stanza's. My not too well educated
guess is that if none have been established, the really empty options
list is the problem.
I'm not convinced that the use of two '/services' strings in the
disklist is 100% kosher either. From perusing mine, the first string
is the alias or the FQDN of the machine to be backed up.
That was one idea I had but even with a symbolic name, Services it had
problems. The tradeoff for me is matching up names on the printed
reports with files on the systems. I tend not to use a symbolic name
(the second field in my case) if I don't have to. I simplified to the
DLE to look like
cluster1-node1.wmi.com /services global 1 local
and had the same problem. Since this relies on only 1 dumptype entry
there shouldn't be an ordering problem. The dumptypes come after all
the other options.
Where the use of {} is brought into play, see this stanza in your
disklist if you just added to the default disklist:
What do you mean by the default disklist?
The disklist that comes with the amanda install, dunno about packaged
versions but the tarball unpacks an example directory that contains a
sample of these files:
[EMAIL PROTECTED] dlds-misc]# ls /home/amanda/amanda-2.5.1p2-20061212/example
3hole.ps amanda-client.conf amanda.conf chg-mcutil.conf
chg-multi.conf config.site disklist EXB-8500.ps Makefile
Makefile.in
8.5x11.ps amanda-client.conf.in amanda.conf.in chg-mcutil.conf.in
chg-scsi.conf DIN-A4.psDLT.psHP-DAT.psMakefile.am
The default disklist is in there. When building from the tarball, these
are not 'installed', but they are there to show how its done.
So by using '/services' twice, technically I believe its correct, but
I'd be wary of unwanted interactions just to be my usual somewhat
paranoid self. But I think the real error is in the order of the
dumptype defines in your amanda.conf.
I moved the dumptype define for this DLE to the bottom of amanda.conf
and the problem was still there. When I added strategy skip to the
dumptype define the problem went away. I don't claim this proves my
config files are correct but I feel that's the hint I am getting. Also,
if there were an issue with the order of entries in amanda.conf then
moving the DLE in the diskfile shouldn't make a difference.
Agreed.
I do have more data points. The backup ran ok last night with that DLE
at the bottom of the disklist file. I also added a duplicate DLE using a
cname for the host. Both completed without problems. There are also
other entries that were disabled with strategy skip. If I remove this
line from the dumptype I see the same problem.
I didn't expect these issues when we moved to our new servers. Then
again, I should know better. I've been down this road before and there
is always a surprise waiting for you.
Yup, new dogs always have to be trained for the show. :)
And the use of the 'strategy skip' is something I'm unfamiliar with as
I've never used it. From a recent example/amanda.conf:
# strategy- set the dump strategy. Valid strategies are currently:
# standard - the standard one.
# nofull - do level 1 dumps every time. This can be
used,
# for example, for small root filesystems
that
# only change slightly relative to a
site-wide
# prototype. Amanda then backs up just the
# changes.
# noinc- do level 0 dumps every time.
# skip - skip all dumps. Useful for sharing a
single
# disklist in several configurations.
--
# to strategy 'nofull', but will increase
# the dump level as usual. Full dumps will
# only be performed when an 'amadmin force'
# has been issued
# Default: [strategy standard]
As I have only one configuration, I have never used the 'skip' option.
I don't have any more clues, perhaps someone else here can comment?
- Joel
--
Cheers Merry Christmas, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: odd behavior after adding DLE
You hit a known bug in 2.5.p1 with parsing the disklist file, it is
fixed in 2.5.1p2.
I didn't remember the detail, but try 2.5.1p2
Jean-Louis
Joel Coltoff wrote:
Hi,
I added a new DLE today
cluster1-node1.wmi.com /services /services {
system-files
} 1 local
Along with the dumptype in amanda.conf (a work in progress)
define dumptype global {
comment Global definitions
index yes
}
define dumptype system-files {
program GNUTAR
global
comment High priority
priority high
}
The DLE was right at the top of the disklist file.
If I run amadmin Daily disklist I get some of the
expected output plus the following:
*** glibc detected *** double free or corruption (fasttop): 0x09af6698
***
Abort
If I move the new DLE elsewhere in the file I see no hint that there
is a problem.
amanda version: 2.5.1p1
uname -a:
Linux cluster1-node1.wmi.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53
EST 2006
i686 i686 i386 GNU/Linux
gcc -v:
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Any ideas what is causing this? Is there a something that gets missed
when the DLE moves?
I've looked a bit at the forums list at zmanda and other have seen
this when doing dumps. I'm guessing all we do here is some parsing and
perhaps some high
level checking. i.e. it shouldn't matter which version of tar I use.
(1.13.25)
Thanks,
- Joel
Re: odd behavior after adding DLE
Now I remember, The bug is with the use of strategy skip or ignore. If you want to use them, you must upgrade your server to 2.5.1p2. Jean-Louis I moved the dumptype define for this DLE to the bottom of amanda.conf and the problem was still there. When I added strategy skip to the dumptype define the problem went away. I don't claim this proves my config files are correct but I feel that's the hint I am getting. Also, if there were an issue with the order of entries in amanda.conf then moving the DLE in the diskfile shouldn't make a difference. I do have more data points. The backup ran ok last night with that DLE at the bottom of the disklist file. I also added a duplicate DLE using a cname for the host. Both completed without problems. There are also other entries that were disabled with strategy skip. If I remove this line from the dumptype I see the same problem. I didn't expect these issues when we moved to our new servers. Then again, I should know better. I've been down this road before and there is always a surprise waiting for you. - Joel
Re: odd behavior after adding DLE
More info on my problem. There is a positional dependency on where the DLE goes. I can't just make it the second DLE. It's probably pointless to determine where it needs to go. The problem is somewhere else. If I change the hostname of the DLE from the server host to another host in the network there is no problem. The server host is running drdb and lvm. Output of df: * * /dev/drbd0 7052464 65884 6628336 1% /services * Perhaps drdb is getting in the way. I'll see what happens tonight when the backup runs. I've added the DLE a second time but used a cname we have for the host. - Joel
odd behavior after adding DLE
Hi,
I added a new DLE today
cluster1-node1.wmi.com /services /services {
system-files
} 1 local
Along with the dumptype in amanda.conf (a work in progress)
define dumptype global {
comment Global definitions
index yes
}
define dumptype system-files {
program GNUTAR
global
comment High priority
priority high
}
The DLE was right at the top of the disklist file.
If I run amadmin Daily disklist I get some of the
expected output plus the following:
*** glibc detected *** double free or corruption (fasttop): 0x09af6698 ***
Abort
If I move the new DLE elsewhere in the file I see no hint that there
is a problem.
amanda version: 2.5.1p1
uname -a:
Linux cluster1-node1.wmi.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006
i686 i686 i386 GNU/Linux
gcc -v:
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Any ideas what is causing this? Is there a something that gets missed
when the DLE moves?
I've looked a bit at the forums list at zmanda and other have seen this when
doing dumps. I'm guessing all we do here is some parsing and perhaps some high
level checking. i.e. it shouldn't matter which version of tar I use. (1.13.25)
Thanks,
- Joel
Re: odd behavior after adding DLE
On Thursday 21 December 2006 12:13, Joel Coltoff wrote:
Hi,
I added a new DLE today
cluster1-node1.wmi.com /services /services {
system-files
} 1 local
Along with the dumptype in amanda.conf (a work in progress)
define dumptype global {
comment Global definitions
index yes
}
define dumptype system-files {
program GNUTAR
global
comment High priority
priority high
}
The DLE was right at the top of the disklist file.
If I run amadmin Daily disklist I get some of the
expected output plus the following:
*** glibc detected *** double free or corruption (fasttop): 0x09af6698
*** Abort
If I move the new DLE elsewhere in the file I see no hint that there
is a problem.
Generally speaking, when amanda sets something up to do, it uses a set of
defaults derived from previous stanza's. My not too well educated guess
is that if none have been established, the really empty options list is
the problem.
This is also a caveat to observe when making a new dumptype in the
amanda.conf, it only reads it once and does not try to resolve what I'd
call for lack of a better name, a forward reference. Said another way,
you cannot re-use a definition unless its been fully defined in the
amanda.conf at a point above the re-use point. So my 'rule of thumb' is
to add anything new to the bottom of the file.
I'm not convinced that the use of two '/services' strings in the disklist
is 100% kosher either. From perusing mine, the first string is the alias
or the FQDN of the machine to be backed up.
The second is the absolute path to be backed up.
The third is the dumptype.
The fourth is the spindle number.
And the 5th is a specifier as to whether its local, or out on the local
network, eg local or le0
Where the use of {} is brought into play, see this stanza in your disklist
if you just added to the default disklist:
#hosta /diskA/ag /diskA {
# # all directories that start with [a-g] except big1 and big2
# high-tar
# include ./[a-g]*
# exclude ./big1 ./big2
# } 1
here we see that the dumptype is specified inside the {}, as are the
include and exclude definitions, but that the spindle number is outside
the {}, and I note that there should have been another item after the 1,
either a 'local' or an 'le0' to have it fully specified.
By specifying the spindle number as the same number for everything on a
given disk, you are telling amanda that she cannot parallelize these
backups, but must do them serially in order to keep from pounding the
seek mechanisms excessively.
So by using '/services' twice, technically I believe its correct, but I'd
be wary of unwanted interactions just to be my usual somewhat paranoid
self. But I think the real error is in the order of the dumptype defines
in your amanda.conf.
amanda version: 2.5.1p1
uname -a:
Linux cluster1-node1.wmi.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53
EST 2006 i686 i686 i386 GNU/Linux
gcc -v:
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Any ideas what is causing this? Is there a something that gets missed
when the DLE moves?
I've looked a bit at the forums list at zmanda and other have seen this
when doing dumps. I'm guessing all we do here is some parsing and
perhaps some high level checking. i.e. it shouldn't matter which
version of tar I use. (1.13.25)
Thanks,
- Joel
--
Cheers, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Odd behavior
Greetings, This morning I all of my backups failed. They all failed with the message: [no more holding disk space]. My setup: Debian 2.2 w/ a 2.4.18 kernel amanda 2.4.2p2 Yesterday I replaced a 18G drive with a 36G to increase my holding disk capacity. My holding disk is a software raid 1 set. Its total capacity is 81G. This error to me means that the holdingdisk if full, yet there is no data on my holdingdisk. hostname:~# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 1968588516212 1352376 28% / /dev/md0 84509240 32828 80183496 1% /holdingdisk hostname:~# uname -a Linux hostname 2.4.18 #9 SMP Mon Jun 17 14:28:08 EDT 2002 i686 unknown hostname:~# Anybody know why amanda would believe the holding disk if full? Thank you for you time. Andrew Hall
Re: Odd behavior
On Thu, 1 Aug 2002 at 11:43am, [EMAIL PROTECTED] wrote This morning I all of my backups failed. They all failed with the message: [no more holding disk space]. hostname:~# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 1968588516212 1352376 28% / /dev/md0 84509240 32828 80183496 1% /holdingdisk After rebuilding md0, did you make sure the amanda user still has permission to write in /holdingdisk? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Odd behavior
In the amanda.conf file, there is a place were it says: reserve 30 # percent Read what it says there, if you've reserved too much, it will look as if its full. 100 would make it full before you've even started! If its not this, you'll have to wait for the real genius to write, I'm under cover Cheers, Trevor. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 01, 2002 5:43 PM Subject: Odd behavior Greetings, This morning I all of my backups failed. They all failed with the message: [no more holding disk space]. My setup: Debian 2.2 w/ a 2.4.18 kernel amanda 2.4.2p2 Yesterday I replaced a 18G drive with a 36G to increase my holding disk capacity. My holding disk is a software raid 1 set. Its total capacity is 81G. This error to me means that the holdingdisk if full, yet there is no data on my holdingdisk. hostname:~# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 1968588516212 1352376 28% / /dev/md0 84509240 32828 80183496 1% /holdingdisk hostname:~# uname -a Linux hostname 2.4.18 #9 SMP Mon Jun 17 14:28:08 EDT 2002 i686 unknown hostname:~# Anybody know why amanda would believe the holding disk if full? Thank you for you time. Andrew Hall
Re: Odd behavior
Hello, Thanks for all the replys. It was permissions. I thought I checked that first, but I guess I overlooked it. Thanks again. Drew On Thu, 1 Aug 2002, Joshua Baker-LePain wrote: On Thu, 1 Aug 2002 at 11:43am, [EMAIL PROTECTED] wrote This morning I all of my backups failed. They all failed with the message: [no more holding disk space]. hostname:~# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 1968588516212 1352376 28% / /dev/md0 84509240 32828 80183496 1% /holdingdisk After rebuilding md0, did you make sure the amanda user still has permission to write in /holdingdisk? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
