Strange Dumps?
I am running Amanda versions 2.4.2p2 on a AIX 5.1 system. I have been getting these strange dump details, and would like To resolve these problems. The following information is provided. FAILED AND STRANGE DUMP DETAILS: /-- thunder /home lev 1 STRANGE sendbackup: start [thunder:/home level 1] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: Removing leading `./' from member names | Total bytes written: 16957440 (17MiB, 1.9MiB/s) sendbackup: size 16560 sendbackup: end \ /-- hail /home lev 4 STRANGE sendbackup: start [hail:/home level 4] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: Removing leading `./' from member names | Total bytes written: 19957760 (20MiB, 610KiB/s) sendbackup: size 19490 sendbackup: end \ /-- thunder / lev 2 STRANGE sendbackup: start [thunder:/ level 2] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: Removing leading `./' from member names | gtar: ./tmp/.s.PGSQL.5432: socket ignored Total bytes written: | 160993280 (154MiB, 5.9MiB/s) sendbackup: size 157220 sendbackup: end \ /-- hail / lev 1 STRANGE sendbackup: start [hail:/ level 1] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: Removing leading `./' from member names | gtar: ./dev/log: socket ignored | gtar: ./tmp/.s.PGSQL.5432: socket ignored | gtar: ./tmp/mysql.sock: socket ignored | gtar: ./var/run/fcron.fifo: socket ignored Total bytes written: | 393256960 (376MiB, 2.6MiB/s) sendbackup: size 384040 sendbackup: end Any help is would be greatly appreciated. Kevin D. Alford Sr. Systems Engineer TMC Technologies, Inc. (304)368-1862 Ext. 53
Samba and strange dumps revisited
Well, good news and bad news... The good news is that, after an apt-get upgrade on the tapehost[1] last week, the dumps from my samba DLEs seem to be reliable and complete. The bad news is that amanda still reports them as strange, with the strange dump summary consisting of several variations on ? SUCCESS - 0 listing \download\hp\laserjet\* ? SUCCESS - 0 opening remote file \download\hp\README.TXT (\download\hp\) Where do I go to tell amanda that these SUCCESS... messages should be considered normal? [1] Midway through, I discovered that I hadn't simply forgotten about the tapehost, but there was a good reason I had left it on potato: Its poor little 2G system drive wasn't big enough to handle an apt-get dist-upgrade. I (re)learned this the hard way when the 450M /usr partition filled while extracting packages... But it turned out the previous admin had installed all kinds of X and CD ripping crap on it (even though being a tapehost is its only purpose in life), so an hour or two of quality time with dpkg --get-selections and apt-get remove --purge freed up plenty of space. :p
Re: Samba and strange dumps revisited
On Fri, Mar 26, 2004 at 09:10:53AM -0600, Dave Sherohman wrote: Where do I go to tell amanda that these SUCCESS... messages should be considered normal? It's a hard-coded list. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau
Re: Samba and strange dumps revisited
On Fri, Mar 26, 2004 at 02:35:43PM -0500, Eric Siegerman wrote: On Fri, Mar 26, 2004 at 09:10:53AM -0600, Dave Sherohman wrote: Where do I go to tell amanda that these SUCCESS... messages should be considered normal? It's a hard-coded list. Then how about a (reasonably) simple way to wrap smbclient (or whatever amanda uses to interface with samba) with a script that filters them out before amanda sees them?
Re: Samba and strange dumps revisited
On Fri, Mar 26, 2004 at 02:35:43PM -0500, Eric Siegerman wrote: On Fri, Mar 26, 2004 at 09:10:53AM -0600, Dave Sherohman wrote: Where do I go to tell amanda that these SUCCESS... messages should be considered normal? It's a hard-coded list. But easily extended. See the source in client/sendbackup-gnutar.c. There is a list of Regular Expressions that can be added to. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Strange dumps - file changed as we read it
On Sun, Jan 05, 2003 at 01:22:49AM -0500, Gene Heskett wrote: I get around that problem here with the use of an extra directory on one of the drives here that has an rsync'd image of the stuff on the other machine I use mainly for a firewall that I would normally use samba for the backup data transport protocol. rsync does not seem to suffer from this foible. cron fires off that script about half an hour ahead of amanda. So in fact I only backup this machine as far as the entries in the disklist are concerned, but that includes the images of the other machine. If you have the space, and rsync can run on the bsd box (it should) then you may want to consider that alternative method. Hmmm. Well, yes, I could I suppose. I'd have to do a little creative repartitioning. It just seems like this should be able to be solved without such workarounds. Chuckle... No codicile about who sets it off? I think I'd find a new insurer. Heh. Imagine my guffaws when I read through my policy and stumbled upon THAT gem. ;) Benny ~~ Discharge of a nuclear weapon shall be deemed a warlike act, even if accidental. -- My homeowners insurance policy
Strange dumps - file changed as we read it
Hey folks, I'm having an odd problem with one of my backup clients. Every single night (I back up nightly), one particular partition ends up with a STRANGE report, saying that a file (pick a file, any file) has changed while it was being read. The stats: Client: OpenBSD 3.2-STABLE Server: OpenBSD 3.2-STABLE Amanda: 2.4.2p2 from OpenBSD ports tree, -STABLE branch Partition: /mp3, accessible via Samba for my local LAN, mode 0775 This partition, obviously, holds my MP3's for my listening pleasure. I've gone to an awful lot of work to rip and encode these things, so I'd like to make sure they're backed up. I'm just having a hard time figuring out why, on this particular partition, every night a file changed while it was being read. Could this be Samba? The timestamps on said files aren't changing. Last night, the file that changed wasn't even being accessed - I didn't even have a Windows machine on the LAN! And before you ask, no other machine was accessing it either. :) Thoughts? While this is just a minor annoyance, it pains me to not understand why this is happening. I'd appreciate any help you folks could give me. Benny ~~ Discharge of a nuclear weapon shall be deemed a warlike act, even if accidental. -- My homeowners insurance policy
Re: Strange dumps - file changed as we read it
On Saturday 04 January 2003 14:15, C. Bensend wrote: Hey folks, I'm having an odd problem with one of my backup clients. Every single night (I back up nightly), one particular partition ends up with a STRANGE report, saying that a file (pick a file, any file) has changed while it was being read. The stats: Client:OpenBSD 3.2-STABLE Server:OpenBSD 3.2-STABLE Amanda:2.4.2p2 from OpenBSD ports tree, -STABLE branch Partition: /mp3, accessible via Samba for my local LAN, mode 0775 This partition, obviously, holds my MP3's for my listening pleasure. I've gone to an awful lot of work to rip and encode these things, so I'd like to make sure they're backed up. I'm just having a hard time figuring out why, on this particular partition, every night a file changed while it was being read. Could this be Samba? The timestamps on said files aren't changing. Last night, the file that changed wasn't even being accessed - I didn't even have a Windows machine on the LAN! And before you ask, no other machine was accessing it either. :) Thoughts? While this is just a minor annoyance, it pains me to not understand why this is happening. I'd appreciate any help you folks could give me. Benny I've been told, and have repeated here, that the mtimes of a file are not supported by samba because they are not supported by the underlying (usually vfat) file system. So apparently, some dummy value gets plugged into that field, and if it changes, you get the message. If this is not the correct explanation, somebody jump in and bail me out here please. In a roundabout way, this also explains why a samba share will often get a level 1 that looks like a level 0 sizewise. I also have one non-samba, small dos partition for holding bios flash images and such, and it gets a full every night, apparently for this same reason. Minor detail in that case as its less than 20 megs. This to me, if its all true, is the one major achilles heel of samba. I keep my music on an ext3 partition :-) -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.21% setiathome rank, not too shabby for a WV hillbilly
Re: Strange dumps - file changed as we read it
Comments inline. On Sat, Jan 04, 2003 at 06:45:51PM -0500, Gene Heskett wrote: I've been told, and have repeated here, that the mtimes of a file are not supported by samba because they are not supported by the underlying (usually vfat) file system. So apparently, some dummy value gets plugged into that field, and if it changes, you get the message. Hey Gene, Actually, this is an ffs (native OpenBSD) partition. In a roundabout way, this also explains why a samba share will often get a level 1 that looks like a level 0 sizewise. I also have one non-samba, small dos partition for holding bios flash images and such, and it gets a full every night, apparently for this same reason. Minor detail in that case as its less than 20 megs. This to me, if its all true, is the one major achilles heel of samba. I keep my music on an ext3 partition :-) I can easily blame Samba; I think it's a reasonable assumption to say that Samba is touching the files somehow. However, that goes right out the door, when I add that this server has _three_ other Samba shares, on the same type of filesystem, that do _not_ have this annoyance. Now, how do we explain THAT? Thanks very much for your email... I'd appreciate any further thoughts. :) This is very perplexing. Benny ~~ Discharge of a nuclear weapon shall be deemed a warlike act, even if accidental. -- My homeowners insurance policy
Re: Strange dumps - file changed as we read it
On Sunday 05 January 2003 00:24, C. Bensend wrote: Comments inline. On Sat, Jan 04, 2003 at 06:45:51PM -0500, Gene Heskett wrote: I've been told, and have repeated here, that the mtimes of a file are not supported by samba because they are not supported by the underlying (usually vfat) file system. So apparently, some dummy value gets plugged into that field, and if it changes, you get the message. Hey Gene, Actually, this is an ffs (native OpenBSD) partition. ffs? That sounds like the amiga FastFileSystem. :-) Which had a few gotchas from time to time, so a lot of us wound up using SmartFileSyetm, a major step forward. Not of course germain here. In a roundabout way, this also explains why a samba share will often get a level 1 that looks like a level 0 sizewise. I also have one non-samba, small dos partition for holding bios flash images and such, and it gets a full every night, apparently for this same reason. Minor detail in that case as its less than 20 megs. This to me, if its all true, is the one major achilles heel of samba. I keep my music on an ext3 partition :-) I can easily blame Samba; I think it's a reasonable assumption to say that Samba is touching the files somehow. However, that goes right out the door, when I add that this server has _three_ other Samba shares, on the same type of filesystem, that do _not_ have this annoyance. Now, how do we explain THAT? Good question. My memory has cleared up enough to be able to state that it was Andrew Tridgell (spelling?) who wrote samba in the first place who made that statement in an old faq. I get around that problem here with the use of an extra directory on one of the drives here that has an rsync'd image of the stuff on the other machine I use mainly for a firewall that I would normally use samba for the backup data transport protocol. rsync does not seem to suffer from this foible. cron fires off that script about half an hour ahead of amanda. So in fact I only backup this machine as far as the entries in the disklist are concerned, but that includes the images of the other machine. If you have the space, and rsync can run on the bsd box (it should) then you may want to consider that alternative method. Thanks very much for your email... I'd appreciate any further thoughts. :) This is very perplexing. Benny ~~ Discharge of a nuclear weapon shall be deemed a warlike act, even if accidental. -- My homeowners insurance policy Chuckle... No codicile about who sets it off? I think I'd find a new insurer. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.21% setiathome rank, not too shabby for a WV hillbilly
Re: strange dumps
I using amanda to backup several servers, but now some of my disks started signaling the following error. Those are vx filesystems of an HP 10.20 ... | vxdump: SIGSEGV: ABORTING! This is either an HP or Veritas (is that who does VX?) problem. You'll probably need to talk to your vendor about it. Maybe there is a system patch available. What happens if you do this on odinn: /usr/sbin/vxdump 1sf 1048576 - /dev/vg02/rlvol2 /dev/null One wild guess possibility is that something bad happend to /etc/dumpdates on odinn. You might try zapping it (cp /dev/null /etc/dumpdates) and then forcing a full dump of the whole system. Check the modes and ownership on /etc/dumpdates, too, and make sure the Amanda user can write to it. Arnar Gestsson John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
strange dumps
Hi there, I using amanda to backup several servers, but now some of my disks started signaling the following error. Those are vx filesystems of an HP 10.20, I have done fbackup on those filesystems and I worked. I also tried to switch from compressed to noncompressed but with no luck. Has anyone any clue what has happened? TIA Arnar Gestsson SysAdm TrackWell Software Dump data FAILED AND STRANGE DUMP DETAILS: FAILURE AND STRANGE DUMP SUMMARY: odinn /home2 lev 1 STRANGE odinn /home lev 1 STRANGE /-- odinn /home2 lev 1 STRANGE sendbackup: start [odinn:/home2 level 1] sendbackup: info BACKUP=/usr/sbin/vxdump sendbackup: info RECOVER_CMD=/usr/sbin/vxrestore -f... - sendbackup: info end | vxdump: Date of this level 1 dump: Fri Jan 19 01:09:41 2001 | vxdump: Date of last level 0 dump: Thu Dec 28 01:35:40 2000 | vxdump: Dumping /dev/vg02/rlvol2 (/home2) to standard output | vxdump: mapping (Pass I) [regular files] | vxdump: mapping (Pass II) [directories] | vxdump: estimated 1527272 blocks (745.74MB) on 0.01 tape(s). | vxdump: dumping (Pass III) [directories] | vxdump: dumping (Pass IV) [regular files] | vxdump: 64.57% done, finished in 0:02 | vxdump: SIGSEGV: ABORTING! ? dumper: strange [missing size line from sendbackup] ? dumper: strange [missing end line from sendbackup] \
Re: strange dumps ?
On Nov 4, 2000, Aharon Schkolnik [EMAIL PROTECTED] wrote:
I'm still using 2.4.1 (does anyone know if there are 2.4.2 rpms
available yet ?).
You *might* be able to find them at rawhide.redhat.com
--
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: strange dumps ?
Can you tell me something about this report ? What does it mean FAILURE AND STRANGE DUMP ... Amanda watches the stderr lines from the backup program and pattern matches them against things it expects (normal). Every other line is considered "strange". If the backup failed or there were any strange lines, it reports them in this section of the E-mail. The character at the front of the line is a code for the class of line: | a normal (expected) line ? a strange (unclassified) line The latest 2.4.2 version has a pattern to treat your "socket ignored" messages as normal and thus ignore them. And I think it also ignores all that noise from smbtar. Michael John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
