Re: Compression again
From the debug file: sendbackup: time 2612.878: 62:size(|): DUMP: 17753400 blocks (17337.30MB) amanda parse the number of block but it think they are blocks of 512 bytes. This problem is fixed only in amanda-2.5.2b1 (The MB value is used). Jean-Louis Sebastian Henrich wrote: My OS is openSUSE 10.1. server:~ # tar --version tar (GNU tar) 1.15.1 server:~ # dump dump 0.4b41 (using libext2fs 1.38 of 30-Jun-2005) The last dendbackup.*.debug is attached. Thanks Sebastian At 13:50 13.04.2007, Jean-Louis Martineau wrote: The orig-kb is the size reported by the backup tool (tar, dump, ...) It's possible that amanda doesn't parse the output correctly. What's your OS? backup tool? Could you post a sendbackup.*.debug file? It's probably already fixed in a newer version. Jean-Louis Sebastian Henrich wrote: Here is the result after deleting full-comp und incr-comp. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229585 2833801 127.1 10:58 4307.9 15:19 3083.2 server /profile0 4557175 4541611 99.7 21:07 3583.6 24:46 3055.3 server /daten 0 1221325 1796309 147.1 4:44 6321.5 9:46 3065.4 server /intorg 0 188995 199786 105.7 1:22 2427.2 1:07 2971.2 server /literatur 0 662255 1051091 158.7 2:36 6737.3 5:39 3097.9 server /projekte 0 8876700 11223553 126.4 43:33 4295.4 60:48 3076.9 Once again the data seems to grow while it's written to the tape. But I think I figured out the problem. During the calculation of the estimates everything seems to be ok and all sizes are like the real ones on the disk. The problems start with the dumper. The dumper doesn't compare his result with the real sizes but with the real sizes divided by two because of the default compression set to 0.50. A compression to 50% isn't possible on all the disks and that why the data seems to grow. My question is now, is this a bug of version 2.4.5? At the moment I don't get packages for openSUSE 10.1 from SuSE or the amanda homepage with the newest version. Perhaps I should try this next? Thanks again Sebastian At 22:20 12.04.2007, Jean-Louis Martineau wrote: I don't understand. Did you set a 'comprate' in your dumptype? You should remove it. Amanda will learn the compresion ratio after a few run. For all 'info' file, you can remove the value in the 'full-comp' and 'incr-comp' line. Jean-Louis Sebastian Henrich wrote: Here is the log. Sebastian
Re: Compression again
Because most user use tar on linux, and it's new that the blocksize is 1024. You can change client-src/sendbackup-dump.c: AM_SIZE_RE(DUMP: [0-9][0-9]* blocks, 512) to AM_SIZE_RE(DUMP: [0-9][0-9]* blocks, 1024) I also fixed the bug in the latest 2.5.1p3 snapshot available from http://www.zmanda.com/community-builds.php Jean-Louis Sebastian Henrich wrote: Mmh, why I'm the only person who ran into these problems? What should I do now? amanda-2.5.2b1 is in beta phase and I thinks it's no good idea to use it in a productional environment. Is there a possible workaround? Thank for helping me Sebastian From the debug file: sendbackup: time 2612.878: 62:size(|): DUMP: 17753400 blocks (17337.30MB) amanda parse the number of block but it think they are blocks of 512 bytes. This problem is fixed only in amanda-2.5.2b1 (The MB value is used). Jean-Louis Sebastian Henrich wrote: My OS is openSUSE 10.1. server:~ # tar --version tar (GNU tar) 1.15.1 server:~ # dump dump 0.4b41 (using libext2fs 1.38 of 30-Jun-2005) The last dendbackup.*.debug is attached. Thanks Sebastian At 13:50 13.04.2007, Jean-Louis Martineau wrote: The orig-kb is the size reported by the backup tool (tar, dump, ...) It's possible that amanda doesn't parse the output correctly. What's your OS? backup tool? Could you post a sendbackup.*.debug file? It's probably already fixed in a newer version. Jean-Louis Sebastian Henrich wrote: Here is the result after deleting full-comp und incr-comp. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229585 2833801 127.1 10:58 4307.9 15:19 3083.2 server /profile0 4557175 4541611 99.7 21:07 3583.6 24:46 3055.3 server /daten 0 1221325 1796309 147.1 4:44 6321.5 9:46 3065.4 server /intorg 0 188995 199786 105.7 1:22 2427.2 1:07 2971.2 server /literatur 0 662255 1051091 158.7 2:36 6737.3 5:39 3097.9 server /projekte 0 8876700 11223553 126.4 43:33 4295.4 60:48 3076.9 Once again the data seems to grow while it's written to the tape. But I think I figured out the problem. During the calculation of the estimates everything seems to be ok and all sizes are like the real ones on the disk. The problems start with the dumper. The dumper doesn't compare his result with the real sizes but with the real sizes divided by two because of the default compression set to 0.50. A compression to 50% isn't possible on all the disks and that why the data seems to grow. My question is now, is this a bug of version 2.4.5? At the moment I don't get packages for openSUSE 10.1 from SuSE or the amanda homepage with the newest version. Perhaps I should try this next? Thanks again Sebastian At 22:20 12.04.2007, Jean-Louis Martineau wrote: I don't understand. Did you set a 'comprate' in your dumptype? You should remove it. Amanda will learn the compresion ratio after a few run. For all 'info' file, you can remove the value in the 'full-comp' and 'incr-comp' line. Jean-Louis Sebastian Henrich wrote: Here is the log. Sebastian
Re: Compression again
At 16:40 16.04.2007, Jean-Louis Martineau wrote: Because most user use tar on linux, and it's new that the blocksize is 1024. This makes sense. What are the disadvantages of a tar backup? You can change client-src/sendbackup-dump.c: AM_SIZE_RE(DUMP: [0-9][0-9]* blocks, 512) to AM_SIZE_RE(DUMP: [0-9][0-9]* blocks, 1024) I also fixed the bug in the latest 2.5.1p3 snapshot available from http://www.zmanda.com/community-builds.php I'll try it on my test system. Jean-Louis Sebastian Henrich wrote: Mmh, why I'm the only person who ran into these problems? What should I do now? amanda-2.5.2b1 is in beta phase and I thinks it's no good idea to use it in a productional environment. Is there a possible workaround? Thank for helping me Sebastian From the debug file: sendbackup: time 2612.878: 62:size(|): DUMP: 17753400 blocks (17337.30MB) amanda parse the number of block but it think they are blocks of 512 bytes. This problem is fixed only in amanda-2.5.2b1 (The MB value is used). Jean-Louis Sebastian Henrich wrote: My OS is openSUSE 10.1. server:~ # tar --version tar (GNU tar) 1.15.1 server:~ # dump dump 0.4b41 (using libext2fs 1.38 of 30-Jun-2005) The last dendbackup.*.debug is attached. Thanks Sebastian At 13:50 13.04.2007, Jean-Louis Martineau wrote: The orig-kb is the size reported by the backup tool (tar, dump, ...) It's possible that amanda doesn't parse the output correctly. What's your OS? backup tool? Could you post a sendbackup.*.debug file? It's probably already fixed in a newer version. Jean-Louis Sebastian Henrich wrote: Here is the result after deleting full-comp und incr-comp. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229585 2833801 127.1 10:58 4307.9 15:19 3083.2 server /profile0 4557175 4541611 99.7 21:07 3583.6 24:46 3055.3 server /daten 0 1221325 1796309 147.1 4:44 6321.5 9:46 3065.4 server /intorg 0 188995 199786 105.7 1:22 2427.2 1:07 2971.2 server /literatur 0 662255 1051091 158.7 2:36 6737.3 5:39 3097.9 server /projekte 0 8876700 11223553 126.4 43:33 4295.4 60:48 3076.9 Once again the data seems to grow while it's written to the tape. But I think I figured out the problem. During the calculation of the estimates everything seems to be ok and all sizes are like the real ones on the disk. The problems start with the dumper. The dumper doesn't compare his result with the real sizes but with the real sizes divided by two because of the default compression set to 0.50. A compression to 50% isn't possible on all the disks and that why the data seems to grow. My question is now, is this a bug of version 2.4.5? At the moment I don't get packages for openSUSE 10.1 from SuSE or the amanda homepage with the newest version. Perhaps I should try this next? Thanks again Sebastian At 22:20 12.04.2007, Jean-Louis Martineau wrote: I don't understand. Did you set a 'comprate' in your dumptype? You should remove it. Amanda will learn the compresion ratio after a few run. For all 'info' file, you can remove the value in the 'full-comp' and 'incr-comp' line. Jean-Louis Sebastian Henrich wrote: Here is the log. Sebastian
Re: Compression again
Here is the result after deleting full-comp und incr-comp. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229585 2833801 127.1 10:58 4307.9 15:19 3083.2 server /profile0 4557175 4541611 99.7 21:07 3583.6 24:46 3055.3 server /daten 0 1221325 1796309 147.1 4:44 6321.5 9:46 3065.4 server /intorg 0 188995 199786 105.7 1:22 2427.2 1:07 2971.2 server /literatur 0 662255 1051091 158.7 2:36 6737.3 5:39 3097.9 server /projekte 0 8876700 11223553 126.4 43:33 4295.4 60:48 3076.9 Once again the data seems to grow while it's written to the tape. But I think I figured out the problem. During the calculation of the estimates everything seems to be ok and all sizes are like the real ones on the disk. The problems start with the dumper. The dumper doesn't compare his result with the real sizes but with the real sizes divided by two because of the default compression set to 0.50. A compression to 50% isn't possible on all the disks and that why the data seems to grow. My question is now, is this a bug of version 2.4.5? At the moment I don't get packages for openSUSE 10.1 from SuSE or the amanda homepage with the newest version. Perhaps I should try this next? Thanks again Sebastian At 22:20 12.04.2007, Jean-Louis Martineau wrote: I don't understand. Did you set a 'comprate' in your dumptype? You should remove it. Amanda will learn the compresion ratio after a few run. For all 'info' file, you can remove the value in the 'full-comp' and 'incr-comp' line. Jean-Louis Sebastian Henrich wrote: Here is the log. Sebastian
Re: Compression again
My OS is openSUSE 10.1. server:~ # tar --version tar (GNU tar) 1.15.1 server:~ # dump dump 0.4b41 (using libext2fs 1.38 of 30-Jun-2005) The last dendbackup.*.debug is attached. Thanks Sebastian At 13:50 13.04.2007, Jean-Louis Martineau wrote: The orig-kb is the size reported by the backup tool (tar, dump, ...) It's possible that amanda doesn't parse the output correctly. What's your OS? backup tool? Could you post a sendbackup.*.debug file? It's probably already fixed in a newer version. Jean-Louis Sebastian Henrich wrote: Here is the result after deleting full-comp und incr-comp. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229585 2833801 127.1 10:58 4307.9 15:19 3083.2 server /profile0 4557175 4541611 99.7 21:07 3583.6 24:46 3055.3 server /daten 0 1221325 1796309 147.1 4:44 6321.5 9:46 3065.4 server /intorg 0 188995 199786 105.7 1:22 2427.2 1:07 2971.2 server /literatur 0 662255 1051091 158.7 2:36 6737.3 5:39 3097.9 server /projekte 0 8876700 11223553 126.4 43:33 4295.4 60:48 3076.9 Once again the data seems to grow while it's written to the tape. But I think I figured out the problem. During the calculation of the estimates everything seems to be ok and all sizes are like the real ones on the disk. The problems start with the dumper. The dumper doesn't compare his result with the real sizes but with the real sizes divided by two because of the default compression set to 0.50. A compression to 50% isn't possible on all the disks and that why the data seems to grow. My question is now, is this a bug of version 2.4.5? At the moment I don't get packages for openSUSE 10.1 from SuSE or the amanda homepage with the newest version. Perhaps I should try this next? Thanks again Sebastian At 22:20 12.04.2007, Jean-Louis Martineau wrote: I don't understand. Did you set a 'comprate' in your dumptype? You should remove it. Amanda will learn the compresion ratio after a few run. For all 'info' file, you can remove the value in the 'full-comp' and 'incr-comp' line. Jean-Louis Sebastian Henrich wrote: Here is the log. Sebastian sendbackup.20070412234545.debug Description: Binary data
Re: Compression again
Post the amdump.1 log file. Jean-Louis Sebastian Henrich wrote: Hello again, I still try find the cause of my problems with amanda. When the backup finishes, I get the following dump summary: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - server /home 0 2229570 2833775 127.1 11:01 4287.6 15:21 3077.9 server /profiles 0 4553900 4539435 99.7 21:12 3569.5 24:46 3054.9 server /data 0 1221335 1796306 147.1 4:43 6347.3 9:52 3032.3 server /org13520 1109 31.5 0:08 135.0 0:03 344.0 server /lit1 402 5.0 0:011.4 0:030.6 server /projects 0 8876515 11223308 126.4 43:35 4292.3 60:48 3076.9 (brought to you by Amanda version 2.4.5) and the following notes planner: server /srv/samba/share/org 20070412 0 [dumps too big, 397003 KB, full dump delayed] planner: server /srv/samba/share/lit 20070412 0 [dumps too big, 1433505 KB, full dump delayed] taper: tape Tape05 kb 20394240 fm 6 [OK] The original data has the following sizes: /home 4452664 kB /profiles 8996864 kB /data 2437400 kB /org376376 kB /lit 1316660 kB /projects 17768808 kB So first I don't understand why ORIG-kB is half of the size. I use software compression (compress server best). Hardware compression ist turned off (amtapetype -c proofs this). Next I don't understand why the data grows during it's written to tape. The third thing I don't understand why amanda delayes two disk. If I summarize the sizes I get 21,19 GB to store. The tape length is 36 GB uncompressed. So it should fit on the tape. Hope that somebody can help me Thanks for helping me Sebastian
Re: amdump again
Hi, Filburt, on Donnerstag, 18. März 2004 at 08:07 you wrote to amanda-users: F I try to archive /var/www and get this error every time: F == F FAILURE AND STRANGE DUMP SUMMARY: Fmymachine /dev/ida/c0d0p2 lev 0 FAILED [disk /ida/c0d0p2, all F estimate failed] What OS is this? The devicename you use doesn't sound too familiar. I assume you should just use this in your disklist: mymachine c0d0p2 always-full -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amdump again
Filburt wrote:
I've changed the labelstr to 'mylabel[0-9][0-9]*$' as Frank suggested.
It's better now, but not perfect yet. B-)
Did amcheck complain about anything?
I try to archive /var/www and get this error every time:
==
FAILURE AND STRANGE DUMP SUMMARY:
mymachine /dev/ida/c0d0p2 lev 0 FAILED [disk /ida/c0d0p2, all
estimate failed]
NOTES:
planner: Adding new disk mymachine:/dev/ida/c0d0p2.
driver: WARNING: got empty schedule from planner
taper: tape mylabel01 kb 0 fm 0 [OK]
==
Content of disklist: mymachine /dev/ida/c0d0p2 always-full
It's not wrong, but when using tar to backup, it's more natural
to specify the directory instead of the device name. Amanda will
convert it for you anyway (and on some systems that gives added
complexity + sometimes a failure).
I presume /dev/ida/c0d0p2 is the device that is mounted on /var/www.
Content of the 'always-full' section in amanda.conf:
options no-compress , index
include list /var/www
So intend to backup /var/www only.
The directive include list means that there should be a file on
the client named /var/www which contains a list of things to include.
Of course amanda fails miserably when trying to read the directory
/var/www on the client, where it expects a plain file.
The files/directories to be included need to be relative to the
mountpoint.
You can probably find the error messages in one of the files
/tmp/amanda/debug.timestamp.* on the client.
Leave out the include directive. You don't need to specify it
twice (in the disklist and in the dumptype definition).
What version of amanda are you using anyway?
The syntax with options is very old, but still understood for
historical compatibility. Nothing in a recent man page talks about
this. Better use the modern syntax (see man page):
define dumptype allways-full {
compress none
index
}
--
Paul Bijnens, XplanationTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... Are you sure? ... YES ... Phew ... I'm out *
***
Re: Not again !!!
Also sprach Jon LaBadie (Wed 06 Aug 02003 at 04:59:41PM -0400): On Wed, Aug 06, 2003 at 02:39:17PM -0500, Michael D. Schleif wrote: Yes, agreed; but, are the plethora of insipid and specious virus-found alarms really necessary (read: on-topic) on this -- or any -- mailing list? Yes, absolutely. Otherwise I would not know a virus had been posted :)) O, yeah, I dint think o dat . . . -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: Not again !!!
On Wed, Aug 06, 2003 à 02:23:30PM -0500, Rebecca Pakish Crum wrote: those who are bothered to be unprepared. Get a spam server...deal with it, move on. Or maybe those complaining would like to contribute and maintain a spam/virus server for the list. This is the 4th or 5th time this year this subject has gone on for far too long. Amanda is free, the knowledge everyone gains and contributes her is free, if the price is to be 'bothered' with extra emails, then pay for some other backup utility and you won't be bothered again. Excuse me but I don't really understand where is the *need* of accepting attachements in a mailing list read by amanda sysadmins, people that use to deal with **TEXT** config files all day long ? There is **absolutly** no need to accept the attachements. If anyone would ever need a binary or a picture of my dog, I would post an URL. So simple ! That would avoid : - the viruses - the too many automatic answers coming from antivirus software - the network load - the long and repeating threads -- Nicolas Ecarnot
Re: Not again !!!
On Wed, Aug 06, 2003 at 02:39:17PM -0500, Michael D. Schleif wrote: Yes, agreed; but, are the plethora of insipid and specious virus-found alarms really necessary (read: on-topic) on this -- or any -- mailing list? Yes, absolutely. Otherwise I would not know a virus had been posted :)) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Not again !!!
way_off_topic On Wed, Aug 06, 2003 at 02:23:30PM -0500, Rebecca Pakish Crum wrote: ---cut--- It amazes me how often these two running arguments are repeatedly debated...using localhost and spam to the amanda list. For the love of pete...how many sys admins does it take to beat the dead horse? (I suppose I am now guilty as well by even responding to the tirades) joke Q: How many IBM CPUs does it take to do a logical right shift? A: 33: 1 to hold the bits and 32 to push the register. /joke another_joke Q: How many IBM CPUs does it take to execute a job? A: Four: three to hold it down, and one to pour Drano down its throat and then rip its head off. (Thanks to Harlan Ellison for the lovely Drano imagery! :) /another_joke Maybe there needs to be something addressed to the newbie's when they register with amanda.org as a part of the welcome email that says You are responsible for your own network...the list is open to everyone and everything, please don't complain about spam, viruses, etc. I find those who are bothered to be unprepared. Get a spam server...deal with it, move on. Or maybe those complaining would like to contribute and maintain a spam/virus server for the list. This is the 4th or 5th time this year this subject has gone on for far too long. Amanda is free, the knowledge everyone gains and contributes her is free, if the price is to be 'bothered' with extra emails, then pay for some other backup utility and you won't be bothered again. Amen. On Wed, Aug 06, 2003 at 02:39:17PM -0500, Michael D. Schleif wrote: ---cut--- Yes, agreed; but, are the plethora of insipid and specious virus-found alarms really necessary (read: on-topic) on this -- or any -- mailing list? No. /way_off_topic --Steve Lane /\ Doudna Lab \ / ASCII Ribbon Campaign U. C. BerkeleyX Against HTML Email / \
Re: Not again !!!
On Wednesday 06 August 2003 14:36, barryc wrote: From: Gene Heskett [EMAIL PROTECTED] Remember Kevin, its only the winderz people it bothers. Not true. Windows users are the only ones with anything to fear from these messages. It bothers (read: annoys) most of us. NOTE: For the purpose of this correspondance, most is defined as 'Some number of amanda-users subscribers, greater than or equal to two.' The definition of bother is relative I guess. Well, with the delete button only centimeters away, its not a bother to me. Now IF I was running winderz (I do not have a copy on the property) and got myself a viri, then that would 'bother' me. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Not again !!!
On Wednesday 06 August 2003 11:06, Kevin Passey wrote: Is there anyway of filtering out attachments on this list? Theses bloody viruses are becoming a pain.. Regards Kevin Remember Kevin, its only the winderz people it bothers. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
RE: Not again !!!
On Wednesday 06 August 2003 14:36, barryc wrote: From: Gene Heskett [EMAIL PROTECTED] Remember Kevin, its only the winderz people it bothers. Not true. Windows users are the only ones with anything to fear from these messages. It bothers (read: annoys) most of us. NOTE: For the purpose of this correspondance, most is defined as 'Some number of amanda-users subscribers, greater than or equal to two.' The definition of bother is relative I guess. Well, with the delete button only centimeters away, its not a bother to me. Now IF I was running winderz (I do not have a copy on the property) and got myself a viri, then that would 'bother' me. It amazes me how often these two running arguments are repeatedly debated...using localhost and spam to the amanda list. For the love of pete...how many sys admins does it take to beat the dead horse? (I suppose I am now guilty as well by even responding to the tirades) Maybe there needs to be something addressed to the newbie's when they register with amanda.org as a part of the welcome email that says You are responsible for your own network...the list is open to everyone and everything, please don't complain about spam, viruses, etc. I find those who are bothered to be unprepared. Get a spam server...deal with it, move on. Or maybe those complaining would like to contribute and maintain a spam/virus server for the list. This is the 4th or 5th time this year this subject has gone on for far too long. Amanda is free, the knowledge everyone gains and contributes her is free, if the price is to be 'bothered' with extra emails, then pay for some other backup utility and you won't be bothered again.
Re: Not again !!!
On Thu, Aug 07, 2003 at 08:19:15AM +0200, Nicolas Ecarnot wrote: There is **absolutly** no need to accept the attachements. If anyone would ever need a binary or a picture of my dog, I would post an URL. So simple ! How about source patches? If you include them in-line, instead of attaching them, their whitespace can get mangled (tabs turned into spaces, lines broken in the middle), and that'll keep them from applying cleanly. Admittedly, this might be more an issue over on amanda-hackers (in fact I learned about this from one-time Amanda maintainer Alexandre Oliva, who refused to accept patches *unless* they were sent as attachments). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot
Re: Not again !!!
Also sprach Rebecca Pakish Crum (Wed 06 Aug 02003 at 02:23:30PM -0500): snip / It amazes me how often these two running arguments are repeatedly debated...using localhost and spam to the amanda list. For the love of pete...how many sys admins does it take to beat the dead horse? (I suppose I am now guilty as well by even responding to the tirades) Maybe there needs to be something addressed to the newbie's when they register with amanda.org as a part of the welcome email that says You are responsible for your own network...the list is open to everyone and everything, please don't complain about spam, viruses, etc. I find those who are bothered to be unprepared. Get a spam server...deal with it, move on. Or maybe those complaining would like to contribute and maintain a spam/virus server for the list. This is the 4th or 5th time this year this subject has gone on for far too long. Amanda is free, the knowledge everyone gains and contributes her is free, if the price is to be 'bothered' with extra emails, then pay for some other backup utility and you won't be bothered again. Yes, agreed; but, are the plethora of insipid and specious virus-found alarms really necessary (read: on-topic) on this -- or any -- mailing list? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: Not again !!!
From: Gene Heskett [EMAIL PROTECTED] Remember Kevin, its only the winderz people it bothers. Not true. Windows users are the only ones with anything to fear from these messages. It bothers (read: annoys) most of us. NOTE: For the purpose of this correspondance, most is defined as 'Some number of amanda-users subscribers, greater than or equal to two.'
Re: Colorado, again
On Wednesday 18 September 2002 07:03, Brian Jonnes wrote:
Hi all,
Still gnashing my teeth over this HP Colorado drive. Found some
pointers which suggested disabling DMA -- have done so for both
drives on that controller. Got 3 successful dumps since Thursday
(3GB written).
The problem today is as follows. The dumps failed with an
Input/Output error after 299kb written. When amcheck ran
(without changing the tape) it failed before reading the tape. My
logs give me:
Sep 18 10:45:01 valhalla kernel: st: Version 20020205, bufsize
32768, wrt 30720, max init. bufs 4,
s/g segs 16
Sep 18 10:45:01 valhalla kernel: Attached scsi tape st0 at scsi0,
channel 0, id 0, lun 0
Sep 18 10:45:01 valhalla kernel: st0: Block limits 6684 - 1711130
bytes. Sep 18 11:00:01 valhalla kernel: scsi : aborting command
due to timeout : pid 329140, scsi0, channel 0, id 0, lun 0 Read
(6) 01 00 00 40 00 Sep 18 11:00:01 valhalla kernel: hdd: irq
timeout: status=0xc0 { Busy } Sep 18 11:00:02 valhalla kernel:
hdd: ATAPI reset complete Sep 18 11:00:02 valhalla kernel: hdd:
irq timeout: status=0x80 { Busy } Sep 18 11:00:02 valhalla
kernel: hdd: ATAPI reset complete Sep 18 11:00:02 valhalla
kernel: hdd: irq timeout: status=0x80 { Busy } Sep 18 11:00:02
valhalla kernel: st0: Error 2707 (sugg. bt 0x20, driver bt
0x7, host bt 0x7).
Sep 18 11:20:01 valhalla kernel: st: Unloaded.
Can I be sure that those IRQ timeouts are due to a faulty device?
Can there be another explanation?
Regards,
Brian Jonnes
I've run into a similar situation, but on my cdrw. When the driver
get its hole in the sock fixed, maybe, but till then its reboot
time to re-initilalize and fix the driver. One of the reasons to
use scsi where scsi does it best I guess.
What kernel version again please?
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.15% setiathome rank, not too shabby for a WV hillbilly
RE: Me again, still getting WARNING: host: selfcheck request time d out. Hostdown?
As stated in my email, my client and server are the same machine.
Here are the permissions on .amandahosts:
-rw---1 backup disk 174 May 22 13:14
/root/amanda-data/.amandahosts
Adding root entries, like this to .amandahosts:
10.1.0.2 backup
10.1.0.3 backup
server02.ctbackup
server01.ctbackup
broadcast backup
10.1.0.2 root
10.1.0.3 root
server02.ctroot
server01.ctroot
broadcast root
did not change any behavior. The debug/log output is identical.
amcheck still returns:
WARNING: server02.ct: selfcheck request timed out. Host down?
Client check: 1 host checked in 30.036 seconds, 1 problem found
Thank you,
Cory Visi
Martinez, Michael -
CSREES/ISTM To: 'Cory Visi'
[EMAIL PROTECTED],
[EMAIL PROTECTED][EMAIL PROTECTED]
eusda.govcc:
Subject: RE: Me again, still
getting
05/22/2002 12:29 PM WARNING: host: selfcheck request
time d out.
Host down?
You're .amandahosts on your tape server needs to include a line for root
for all your tape clients (including itself) ; and .amandahosts on your
clients needs to be chmod 400
-Original Message-
From: Cory Visi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 11:36 AM
To: [EMAIL PROTECTED]
Subject: Me again, still getting WARNING: host: selfcheck request timed
out. Host down?
Ok, I have looked into my issues further. Many replies on the list have
helped me, although I am still having problems and I do not understand what
Amanda is doing.
Firstly, this error:
amandad: dgram_send_addr: sendto(0.0.0.0.929) failed: Invalid argument
Is clearly not indicative of an error. Amanda uses broadcasts to find
clients/servers regardless of the configuration. Some people get this error
but have a perfectly working system.
This error, however:
Amanda Backup Client Hosts Check
WARNING: server02.ct: selfcheck request timed out. Host down?
Client check: 1 host checked in 30.028 seconds, 1 problem found
IS indicative of a problem.
So, starting from scratch I will explain all the details of my setup:
I am using Amanda 2.4.2p2 on Linux 2.4.13 with glibc 2.2.2 compiled by
myself.
I am running amandad, amindexd, amidxtaped from xinetd. All these protocols
are listed in my /etc/services.
Currently, I am only trying to backup the data on the same machine as the
server, so the server and client are the _same machine_. I am using the
eth0 interface IPs to communicate, although, clearly the packets will go
through the loopback. The local firewall is configured to _allow all
packets_ through on the loopback and the eth0 interface (since it's local
only).
The following are relevant files concerning my setup. Some of my setup may
seem redundant and superfluous, however, in my efforts to make things work,
I have tried a number of things.
/etc/passwd entry for amanda user:
backup:x:417:6:Amanda Backup:/root/amanda-data:/bin/bash
/root/amanda-data/.amandahosts:
10.1.0.3 backup
server02.ctbackup
broadcast backup
/etc/hosts:
127.0.0.1 localhost.localdomain localhost
10.1.0.3 server02.ct.internaldomain.com server02.ct
0.0.0.0broadcast broadcast
some of amanda.conf:
dumpuser backup
inparallel 4
netusage 51200 Kbps
dumpcycle 3 weeks
runspercycle 15
tapecycle 20 tapes
runtapes 1
tpchanger chg-manual
tapedev /dev/nst0
changerfile /root/amanda-data/changer-status
changerdev /dev/null
tapetype DAT
infofile /root/amanda-data/daily
logdir /var/log/amanda/daily
indexdir /root/amanda-data/daily
tapelist /root/amanda-data/daily/tapelist
define tapetype DAT {
comment Archive Python 04687-XXX
length 4000 mbytes
filemark 100 kbytes
speed 800 kbytes
}
disklist:
server02.ct sda1comp-root
server02.ct sda2comp-user
server02.ct sdb1comp-user
xinetd entries:
service amanda
{
disable= no
bind = 10.1.0.3
log_on_success += USERID
log_on_failure += USERID
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/local/libexec/amandad
}
service amandaidx
{
disable= no
bind = 10.1.0.3
log_on_success += USERID
log_on_failure
RE: Me again, still getting WARNING: host: selfcheck request time d out. Host down?
You can forget about .amandahosts for now, it's not getting that far. If it were an .amandahosts problem the error would be similar to [warning, access as backup not allowed from amanda@yourhost]. You seem to be having a connection problem. Check the following: Is there anything in /tmp/amanda? Can your amanda user create /tmp/amanda? Is the line for amanda in /etc/services is correct Is the line for amanda in inetd.conf correct (if running inetd) or do you have a correct amanda file in xinetd.d (if running xinetd). Did you restart (x)inetd (some systems seem to need a stop/start instead of just a signal)? Can you run the command line specified in (x)inetd as your amanda user without error (it should sit and do nothing until it times out or you type something)? Do you have iptables, hosts.allow/deny, or something else installed that might prevent packets getting to/from amandad? Can you see requests to and from the amandad port using snoop/tcpdump or whatever packet sniffing tool you have? Frank --On Wednesday, May 22, 2002 13:40:28 -0400 Cory Visi [EMAIL PROTECTED] wrote: As stated in my email, my client and server are the same machine. Here are the permissions on .amandahosts: -rw---1 backup disk 174 May 22 13:14 /root/amanda-data/.amandahosts Adding root entries, like this to .amandahosts: 10.1.0.2 backup 10.1.0.3 backup server02.ctbackup server01.ctbackup broadcast backup 10.1.0.2 root 10.1.0.3 root server02.ctroot server01.ctroot broadcast root did not change any behavior. The debug/log output is identical. amcheck still returns: WARNING: server02.ct: selfcheck request timed out. Host down? Client check: 1 host checked in 30.036 seconds, 1 problem found Thank you, Cory Visi Martinez, Michael - CSREES/ISTM To: 'Cory Visi' [EMAIL PROTECTED], [EMAIL PROTECTED][EMAIL PROTECTED] eusda.govcc: Subject: RE: Me again, still getting 05/22/2002 12:29 PM WARNING: host: selfcheck request time d out. Host down? You're .amandahosts on your tape server needs to include a line for root for all your tape clients (including itself) ; and .amandahosts on your clients needs to be chmod 400 -Original Message- From: Cory Visi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 11:36 AM To: [EMAIL PROTECTED] Subject: Me again, still getting WARNING: host: selfcheck request timed out. Host down? Ok, I have looked into my issues further. Many replies on the list have helped me, although I am still having problems and I do not understand what Amanda is doing. Firstly, this error: amandad: dgram_send_addr: sendto(0.0.0.0.929) failed: Invalid argument Is clearly not indicative of an error. Amanda uses broadcasts to find clients/servers regardless of the configuration. Some people get this error but have a perfectly working system. This error, however: Amanda Backup Client Hosts Check WARNING: server02.ct: selfcheck request timed out. Host down? Client check: 1 host checked in 30.028 seconds, 1 problem found IS indicative of a problem. So, starting from scratch I will explain all the details of my setup: I am using Amanda 2.4.2p2 on Linux 2.4.13 with glibc 2.2.2 compiled by myself. I am running amandad, amindexd, amidxtaped from xinetd. All these protocols are listed in my /etc/services. Currently, I am only trying to backup the data on the same machine as the server, so the server and client are the _same machine_. I am using the eth0 interface IPs to communicate, although, clearly the packets will go through the loopback. The local firewall is configured to _allow all packets_ through on the loopback and the eth0 interface (since it's local only). The following are relevant files concerning my setup. Some of my setup may seem redundant and superfluous, however, in my efforts to make things work, I have tried a number of things. /etc/passwd entry for amanda user: backup:x:417:6:Amanda Backup:/root/amanda-data:/bin/bash /root/amanda-data/.amandahosts: 10.1.0.3 backup server02.ctbackup broadcast backup /etc/hosts: 127.0.0.1 localhost.localdomain localhost 10.1.0.3 server02.ct.internaldomain.com
Re: amcheck ...again (but on a different machine)
It appears that the HUP was giving erroneous infoI bounced the box and it is content now... Thans for the advice John R. Jackson wrote: I'm not as slow as my questions indicate :-) :-) The things you're running into are among the most common initial problems. Don't despair. Since they are so common, they are even documented in the FAQ :-). Have you read and tried all the steps documented here: http://amanda.sourceforge.net/fom-serve/cache/16.html http://amanda.sourceforge.net/fom-serve/cache/140.html In addition to the above, have you tried all the tricks we talked about yesterday (the shell script and truss)? I would understand if it was a external box, but this is the same box. There is no difference as far as Amanda is concerned. It still makes a network connection (even though it's through the local host interface). In particular this means inetd has to be set up right, which is the most common source of trouble. Don Potter John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amcheck ...again (but on a different machine)
On Wed, 30 Jan 2002 at 3:05pm, Don Potter wrote I'm not as slow as my questions indicate Amanda is a rather nice system that can take a fair bit of elbow grease to get going. It also tweaks all sorts of things in the underlying OS setup and can often indicate problems there. In short, don't sweat it. Scenario: Starting up the production tape server have installed 2.4.2. Disklist has partitions on the tape server only (initial population). Ran amcheck conf and it fails saying that the host is down. The client and the tape server are one in the same. 1. ) netstat -a shows that the port is being listened 2.) parameters in /etc/inetd.conf and /etc/services are the settings that patch-system appends (index, tape, and amanda daemon) 3. ) ls -lu shows that the access time on the amandad doesn't change since install time (which means that the daemons aren't talkin' to each other) 4.) debug is created in the tmp space and indicates that it was local and an attempt was made (see pasted) amcheck: debug 1 pid 16456 ruid 9732 euid 0 start time Wed Jan 30 14:55:13 2002 amcheck: dgram_bind: socket bound to 0.0.0.0.1001 amcheck: pid 16456 finish time Wed Jan 30 14:55:43 2002 amcheck*debug is from the amcheck process, i.e. its a server side program. What you really need to check for is the client side stuff. Is an amandad*debug file is getting created when you run amcheck. If so, what are its conents? Any messages in the system logs? I would understand if it was a external box, but this is the same box. Amanda treats all clients the same, so it really doesn't matter that the client is the server (or vice versa). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: amcheck ...again (but on a different machine)
That's a relief...I was feeling rather inadequate I digress. No amandad debug file (since the access time hasn't changed that would be expectedright???) and nothing in /var/adm/messages as well I was concerened with the issue of access problems (from a previoous thread) and tried running amandad as root...same outcome.. I can invoke the amandad by hand it timesout after 30 seconds (as expected) and it creates the debug file with the expected contents of a happy daemon. Joshua Baker-LePain wrote: On Wed, 30 Jan 2002 at 3:05pm, Don Potter wrote I'm not as slow as my questions indicate Amanda is a rather nice system that can take a fair bit of elbow grease to get going. It also tweaks all sorts of things in the underlying OS setup and can often indicate problems there. In short, don't sweat it. Scenario: Starting up the production tape server have installed 2.4.2. Disklist has partitions on the tape server only (initial population). Ran amcheck conf and it fails saying that the host is down. The client and the tape server are one in the same. 1. ) netstat -a shows that the port is being listened 2.) parameters in /etc/inetd.conf and /etc/services are the settings that patch-system appends (index, tape, and amanda daemon) 3. ) ls -lu shows that the access time on the amandad doesn't change since install time (which means that the daemons aren't talkin' to each other) 4.) debug is created in the tmp space and indicates that it was local and an attempt was made (see pasted) amcheck: debug 1 pid 16456 ruid 9732 euid 0 start time Wed Jan 30 14:55:13 2002 amcheck: dgram_bind: socket bound to 0.0.0.0.1001 amcheck: pid 16456 finish time Wed Jan 30 14:55:43 2002 amcheck*debug is from the amcheck process, i.e. its a server side program. What you really need to check for is the client side stuff. Is an amandad*debug file is getting created when you run amcheck. If so, what are its conents? Any messages in the system logs? I would understand if it was a external box, but this is the same box. Amanda treats all clients the same, so it really doesn't matter that the client is the server (or vice versa).
Re: amcheck ...again (but on a different machine)
I'm not as slow as my questions indicate :-) :-) The things you're running into are among the most common initial problems. Don't despair. Since they are so common, they are even documented in the FAQ :-). Have you read and tried all the steps documented here: http://amanda.sourceforge.net/fom-serve/cache/16.html http://amanda.sourceforge.net/fom-serve/cache/140.html In addition to the above, have you tried all the tricks we talked about yesterday (the shell script and truss)? I would understand if it was a external box, but this is the same box. There is no difference as far as Amanda is concerned. It still makes a network connection (even though it's through the local host interface). In particular this means inetd has to be set up right, which is the most common source of trouble. Don Potter John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover again
... I load the tape manually and amanda started to read from the tape. After many hours ... You might be able to speed up the restore by pre-positioning the tape. Use amadmin config find host disk (or amtoc, etc) to find out what file on the tape has the image. Then after mounting the tape, do an mt -f /dev/nst0 fsf nn. That should go much faster than what amrestore has to do (read the first block, skip one file, read a block, skip a file, etc). amrecover stop but still the prompt was there amrecover ... It's normal that amrecover would come back with that prompt when it was done. And if it had any problems, they would show up just before it. Started amidxtaped with arguments 6 -h -p /dev/nst0 whiteley.tomandandy.com ^/Local/Users/lauren$ 20010626 Exec'ing /bin/gtar with arguments: tar -xpGvf - ./Database/database ... Started amidxtaped with arguments 6 -h -p /amanda_holding-2/20010706/whiteley.tomandandy.com._Local_Users_lauren.1 white ley.tomandandy.com ^/Local/Users/lauren$ 20010706 Exec'ing /bin/gtar with arguments: tar -xpGvf - ./Database/database This looks perfectly normal. First it read and processed the tape, then it did the image in the holding disk. Sandra John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: me again...
ERROR: /dev/nst0: Permission denied Did you run amcheck as the Amanda user? What is the Amanda user? What groups is it a member of? What are the modes and ownership on /dev/nst0? ERROR: localhost: [access as amanda not allowed from amanda@localhost] Are you using .rhosts or .amandahosts (amadmin xx version | grep HOSTS)? What is the home directory for "amanda"? Does it have access to it (some RH installations put it under another directory without world search access -- sigh). Do you have a file in ~amanda named .amandahosts (or .rhosts)? Does it contain this line: localhost amanda ERROR: plath.knox.net: [can not access /dev/sda1 (/): Permission denied] Same questions as the tape drive. isaac John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: me again...
On Feb 23, 2001, "isaac flemming" [EMAIL PROTECTED] wrote:
"how to install amanda on a linux box walk through's?"
docs/INSTALL
The book chapter linked to from www.amanda.org
The FAQ
--
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
