Re: Holding Disk Question
* John R. Jackson [EMAIL PROTECTED] (Thu, Apr 12, 2001 at 11:28:03AM -0500) Im currently using a single (big) holding disk. I have 2 smaller disks, that I'd like to use as holding disks. But the samller disks will not be able to hold the big 0 dumps. According to the docs, the holding disks are used in a round-robin way (dump 1 to HD1, dump 2 - HD 2, dump3 - HD3, dump4 - HD1 c c ) According to the code (you actually read and believed the docs? :-): Oddly enough, yes ;) It's in the comments in the example amanda.conf. /* find the holdingdisk with the fewest active dumpers and among * those the one with the biggest free space So you should not have any trouble using all three as a "pool". It might work even better if you set the holding disk chunksize down so they can be split up into pieces and scattered around. Will that work ? If I specify a chunksize of 1G, and dump a 9G backup, will it stick 3 chunks on each of the 3 hilding disks ? That would be really impressive ... What "docs" did you find the round-robin described? I seem to remember seeing that, too, but can't find it now and would like to get it updated. Line 82 and on in example/amanda.conf in the source tree # Specify holding disks. These are used as a temporary staging area for # dumps before they are written to tape and are recommended for most sites. # The advantages include: tape drive is more likely to operate in streaming # mode (which reduces tape and drive wear, reduces total dump time); multiple # dumps can be done in parallel (which can dramatically reduce total dump time. # The main disadvantage is that dumps on the holding disk need to be flushed # (with amflush) to tape after an operating system crash or a tape failure. # If no holding disks are specified then all dumps will be written directly # to tape. If a dump is too big to fit on the holding disk than it will be # written directly to tape. If more than one holding disk is specified then # they will all be used round-robin. ^ Thanks, Gerhard John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Currently listening to: Pearl Jam - 11 Off He Goes (VA Beach 8_3_00) Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O i hurt myself today to see if i still feel =`\, i focus on the pain the only thing that's real (=)/(=) the needle tears a hole the old familiar sting try to kill it all away but i remember everything
Re: Holding Disk Question
It's in the comments in the example amanda.conf. OK, I'll get those updated. Will that work ? No. I'm planning on getting a job in sales, so I'm just making all this up. :-) If I specify a chunksize of 1G, and dump a 9G backup, will it stick 3 chunks on each of the 3 hilding disks ? Not necessarily. Note that it takes both the number of active dumpers (how busy) each holding disk has and the amount of free space. So there are dynamics involved that cannot be known until runtime. But based on that one comment and a quick glance at the code, I would expect it to do more or less "the right thing". That would be really impressive ... It's Amanda. What did you expect? :-) Gerhard John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Holding Disk Question
* John R. Jackson [EMAIL PROTECTED] (Fri, Apr 13, 2001 at 07:06:20AM -0500) Will that work ? No. I'm planning on getting a job in sales, so I'm just making all this up. :-) Good ;) If I specify a chunksize of 1G, and dump a 9G backup, will it stick 3 chunks on each of the 3 hilding disks ? Not necessarily. Note that it takes both the number of active dumpers (how busy) each holding disk has and the amount of free space. So there are dynamics involved that cannot be known until runtime. But based on that one comment and a quick glance at the code, I would expect it to do more or less "the right thing". Good. BTW, does the chunksize have any performance benefiot/penalty ? Or is it more a convenience (as in this case where picking the right chunksize will have the load indeed split over multiple disks) That would be really impressive ... It's Amanda. What did you expect? :-) Miracles Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O Some say the end is near. =`\, Some say we'll see armageddon soon (=)/(=) I certainly hope we will I could use a vacation
Re: Holding Disk Question
does the chunksize have any performance benefiot/penalty ? No penalties I can think of at the 1 GByte level. If you went silly and told it 100 KBytes, there is an additional 32 KByte header on each chunk so you'd waste a tremendous amount of space, and I suppose at that small a size there might be some speed loss as Amanda was constantly doing the protocol and search for the next chunk. Or is it more a convenience (as in this case where picking the right chunksize will have the load indeed split over multiple disks) The original intent was to support file systems that cannot handle files larger than 32 KBytes (e.g. ext2 on Linux). But, as with all good ideas :-), it turns out to have some other nice benefits, such as what you're trying to do. When tape chunking is done, it will also allow disk chunks that have made it to tape to be released early (before either the dump or the tape is completely done), which will reduce the amount of holding disk space needed and also allow everything to flow through the holding disk, not just the complete images that will (were estimated to) fit, which will increase parallelism. Gerhard John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Holding Disk Question
* John R. Jackson [EMAIL PROTECTED] (Fri, Apr 13, 2001 at 07:44:09AM -0500) Or is it more a convenience (as in this case where picking the right chunksize will have the load indeed split over multiple disks) The original intent was to support file systems that cannot handle files larger than 32 KBytes (e.g. ext2 on Linux). But, as with all good ideas larger than 2G I assume ;) :-), it turns out to have some other nice benefits, such as what you're trying to do. Well, it's all in the amanda.conf now, We'll see tonight how it goes Currently listening to: The Radio (http://www.arrow.nl/specials/GVGVplaylist.htm) Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O If your watch is wound, wound to run, it will =`\, If your time is due, due to come, it will (=)/(=) Living this life, is like trying to learn latin in a chines firedrill
could not lock log file
On RedHat 7 with Amanda-2.4.2p2 rebuild from http://people.redhat.com/teg/ (reference list message 28027). Having the following issues with driver and planner. Thanks. I'd really like to get a backup done, I don't like being exposed like this. Steve /var/lib/amanda/amdump.# says: amdump: start at Fri Apr 13 09:24:31 EDT 2001 driver: could not lock log file /var/lib/amanda/DailySet1/log: Invalid argument driver: pid 1395 executable /usr/lib/amanda/driver version 2.4.2p2 planner: pid 1394 executable /usr/lib/amanda/planner version 2.4.2p2 planner: build: VERSION="Amanda-2.4.2p2" planner:BUILT_DATE="Wed Apr 4 11:35:05 EDT 2001" planner:BUILT_MACH="Linux porky.devel.redhat.com 2.2.17-8smp #1 SMP Fri Nov 17 16:12:17 EST 2000 i686 unknown" planner:CC="gcc" planner: paths: bindir="/usr/bin" sbindir="/usr/sbin" planner:libexecdir="/usr/lib/amanda" mandir="/usr/share/man" planner:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" planner:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/" planner:RDEV_PREFIX="/dev/" DUMP="/sbin/dump" planner:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient" planner:GNUTAR="/bin/tar" COMPRESS_PATH="/usr/bin/gzip" planner:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail" planner:listed_incr_dir="/var/lib/amanda/gnutar-lists" planner: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" planner:DEFAULT_TAPE_SERVER="localhost" planner:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE planner:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS planner:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP planner:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" planner:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" planner: dgram_bind: socket bound to 0.0.0.0.897 READING CONF FILES... planner: could not lock log file /var/lib/amanda/DailySet1/log: Invalid argument could not lock log file /var/lib/amanda/DailySet1/log: Invalid argument planner: pid 1394 finish time Fri Apr 13 09:24:31 2001 amdump: end at Fri Apr 13 09:24:31 EDT 2001 /tmp/amanda/amtrmidx.### says: amtrmidx: debug 1 pid 1353 ruid 33 euid 33 start time Fri Apr 13 09:06:35 2001 /usr/lib/amanda/amtrmidx: version 2.4.2p2 Keeping 6 index files localhost /etc could not open index directory "/var/lib/amanda/DailySet1/index/localhost/_etc/" amtrmidx: pid 1353 finish time Fri Apr 13 09:06:35 2001 /tmp/amanda/amtrmlog.### says: amtrmlog: debug 1 pid 1352 ruid 33 euid 33 start time Fri Apr 13 09:06:35 2001 /usr/lib/amanda/amtrmlog: version 2.4.2p2 Keeping 10 log files amtrmlog: pid 1352 finish time Fri Apr 13 09:06:35 2001
NFS mounted holding disk
Using a NFS mounted holding disk doesn't seem possible and I don't understand exactly why. amdump writes to it fine but when amflush tries to write to tape I get: The dumps were flushed to tape dailies02. *** A TAPE ERROR OCCURRED: [[writing file: Bad file number]]. It's not a bad tape or drive and if the files are on a locally mounted file system it's fine. Anyone else tried using remote holding disk? Jim Harmon Department of Lingusitics Ohio State University
Re: NFS mounted holding disk
Using a NFS mounted holding disk doesn't seem possible ... I would consider that a feature :-). Why in the world would you drag a bunch of dump images across the network to an Amanda server and then send them back across the network, using NFS of all things, then turn around and drag them back a third time to finally go to tape? Ick. That's more or less a rhetorical question. I fully realize (especially with universities :-) that some "unusual" configurations are attempted. and I don't understand exactly why. amdump writes to it fine but when amflush tries to write to tape I get: The dumps were flushed to tape dailies02. *** A TAPE ERROR OCCURRED: [[writing file: Bad file number]]. You didn't say what version of Amanda this is, but the only reference I see to that error message (in 2.4.2) says it comes from trying to write to the tape. There should have been more messages from amflush. Did you run it with the -f (foreground) option? If so, they went to your tty. If not, there may be an amflush.NN file, or a /tmp/amanda/amflush*debug file. It would be interesting to see what it had to say about initially opening the tape, etc. I assume you ran amflush as the Amanda user, i.e. the same user that ran amdump? Did it have anything interesting to say when it showed you what holding disk areas it found? It's not a bad tape or drive and if the files are on a locally mounted file system it's fine. So with everything exactly the same except the location of the holding disk (same Amanda config, same tape drive, etc), it works? Anyone else tried using remote holding disk? U, no. :-) Jim Harmon John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: could not lock log file
On RedHat 7 with Amanda-2.4.2p2 rebuild from
http://people.redhat.com/teg/ (reference list message 28027). ...
I'm not quite clear. Were you running Amanda before and have upgraded?
What part of the above is new and what was running before?
planner:LOCKING=POSIX_FCNTL ...
planner: could not lock log file /var/lib/amanda/DailySet1/log: Invalid argument
If you were running Amanda before, can you run the old amadmin and get
the locking it was using ("amadmin xx version | grep LOCKING")?
I don't know enough about Linux to give much guidance, but my bet would be
that whoever built this RPM (and now you know why the Amanda developers
frown on the use of them) has a different system configuration than you,
e.g. some kernel parameter is different or some feature is not loaded,
or some library is a different revision, etc.
You might try asking the RPM builder directly. Maybe they have a clue.
Steve
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: strange error
ERROR: X.XXX.duke.edu: [can not access LABEL=/home (/home): No such file or directory] ... (brought to you by Amanda 2.4.1p1) ... Any suggestions? This is fixed in 2.4.2p2. You may also want the post-p2 patch at www.amanda.org/patches.html. -Joe John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: strange error
On Fri, 13 Apr 2001, John R. Jackson wrote: ERROR: X.XXX.duke.edu: [can not access LABEL=/home (/home): No such file or directory] ... (brought to you by Amanda 2.4.1p1) ... Any suggestions? This is fixed in 2.4.2p2. You may also want the post-p2 patch at www.amanda.org/patches.html. I am upgrading as soon as a get the new server. But the strangeness comes from the fact that I have two other RH 7.0 boxes and they don't complain. --Joe
Re: strange error
On Apr 13, 2001, Joe Sauer [EMAIL PROTECTED] wrote:
I am upgrading as soon as a get the new server. But the strangeness comes
from the fact that I have two other RH 7.0 boxes and they don't complain.
Compare /etc/fstab on those boxes and the difference will become clear.
--
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
