Re: Cant run two Linux Servers behind my firewall at the same time - only one and vice versa.
Chuck; Chuck Amadi Systems Administrator schrieb: Hi List I was hoping for some direction to my issue with two servers behind a firewall running ipchains I can backup one or the other but when I uncomment both DLE I get host down. As I don't run amanda across network boundaries, probably I can be of little help here. Few pointers, however: * Did you spent some quality time using tcpdump and friends to see your modified build of amanda actually is exclusively using the port range you want it to use? I recommend doing some monitoring and figuring out what happens in your setup. * Perhaps you might consider using an option other than amanda for doing cross-network backups. No offense folks, I love amanda and its feature set, but sync'ing machines across networks usually I fall back to using rsync/ssh as it needs way less firewall tweaking / port opening. Overally, as I dislike the idea of having _one_ amanda installation making its way through a firewall, the idea of having even _two_ of them gives me the creeps. :) Cheers, Kristian -- Dipl.-Ing.(BA) Kristian Rink * Software- und Systemingenieur planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden fon: 0351 4657770 * mail: [EMAIL PROTECTED] * http://www.pm-planc.de
backup still messed up...
Hello all; after getting last weeks issues fixed, downgrading amanda (now 2.5.0-20060424) as well as tar (now 1.14-2.2), Thursday and Friday incremental dumps worked out. However, weekend dump once again didn't to as it is supposed to. I had an eye on the amanda processes all the weekend and it _seemed_ fine, but in the end it ain't. Some excerpts and log dumps: - according to amstatus, nothing has been written to tape: backer:/tmp# /opt/sbin/amstatus --config Full Using /var/log/amanda/Full/amdump.1 from Sa Aug 19 03:00:02 CEST 2006 [...] backer:backervar getting estimate backer:jka getting estimate backer:planc10304732110k partial estimate done backer:planc30118291530k estimate done backer:refastgetting estimate SUMMARY part real estimated size size partition : 7 estimated : 2423023640k flush : 0 0k failed : 00k ( 0.00%) wait for dumping: 00k ( 0.00%) dumping to tape : 00k ( 0.00%) dumping : 0 0k 0k ( 0.00%) ( 0.00%) dumped : 0 0k 0k ( 0.00%) ( 0.00%) wait for writing: 0 0k 0k ( 0.00%) ( 0.00%) wait to flush : 0 0k 0k (100.00%) ( 0.00%) writing to tape : 0 0k 0k ( 0.00%) ( 0.00%) failed to tape : 0 0k 0k ( 0.00%) ( 0.00%) taped : 0 0k 0k ( 0.00%) ( 0.00%) tape 1: 0 0k 0k ( 0.00%) Back00 5 dumpers idle : not-idle taper idle network free kps: 600 holding space : 0k ( 0.00%) 0 dumpers busy : 0:00:00 ( 0.00%) - Likewise, amverify (could this input/output error be caused by a defective drive / tape or is this just the result of the tape being empty?): Tapes: Back00 Errors found: Back00 (): amrestore: missing file header block amrestore: missing file header block amrestore: error reading file header: Input/output error ** No header 0+0 in 0+0 out [...] - amandad debug log: Is the timeout caused by tar taking too long to actually calculate the size of the DLE in question? [...] amandad: time 1.161: sending PREP pkt: OPTIONS features=feff9ffe07; planc3 0 SIZE 118291530 planc3 1 SIZE 2544890 planc1 0 SIZE 304732110 amandad: time 21600.749: /opt//libexec/sendsize timed out waiting for REP data amandad: time 21600.761: sending NAK pkt: ERROR timeout on reply pipe amandad: time 21600.761: pid 23250 finish time Sat Aug 19 09:00:03 2006 - sendsize, again, is filled with error messages like those below, even though the files definitely are around and usually an arbitrary application also is capable of opening / reading them without a problem. sendsize[23820]: time 9689.225: getting size via gnutar for planc1 level 0 sendsize[23268]: time 9689.226: waiting for any estimate child: 1 running sendsize[23820]: time 9689.324: spawning /opt//libexec/runtar in pipeline sendsize[23820]: argument list: /bin/tar --create --file /dev/null --directory /backup/PV/ --one-file-system --l isted-incremental /opt//var/amanda/gnutar-lists/backer.planconnect.netplanc1_0.new --sparse --ignore-failed-read --totals . sendsize[23820]: time 16883.005: /bin/tar: ./docs/work/d2845/d736/qw78xmm4/file.doc: Warning: Cannot seek to 0: Bad file descriptor sendsize[23820]: time 16883.016: /bin/tar: ./docs/work/d2845/d754/vsbed359/class.all: Warning: Cannot seek to 0: Bad file descriptor sendsize[23820]: time 16883.016: /bin/tar: ./docs/work/d2845/d754/vsbed359/file.doc: Warning: Cannot seek to 0: Bad file descriptor Again, same questions - hardware error? Tape error? Misconfiguration? Right now, I tried to manually dump some data to the drive, ending like this: backup:/tmp# tar czvf /dev/nst0 /backup/PV/ [...] /backup/PV/docs/work/d0301/d880/t37adzo8/ /backup/PV/docs/work/d0301/d880/t37adzo8/class.all /backup/PV/docs/work/d0301/d880/t37adzo8/file.hpgl tar: /dev/nst0: Cannot open: Input/output error Ideas, enlightenments, hints, ... really much appreciated... :/ Thanks and bye, Kristian -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden Tel: 0351 4657770 * Fax: 0351 4657778 * [EMAIL PROTECTED]
Re: backup ceased working? (longer mail)
Hey Gene, folks; Gene Heskett schrieb: I have had several instances of exactly this failure, and I can cause it to repeat virtually at will by installing any snapshot of amanda newer than 2.5.0-20060424 here. It will occur, not generally on the first run after the install of a newer version, but will blow up exactly as you describe on the 2nd and subsequent runs after the install. That seems to be it. Actually, I followed your recommendations, got rid of Debian amanda, downgraded tar and built 2.5.0-20060424, and this nights dumps worked well... Let's see how things will move on the next days, but I'm carefully optimistic. :) Thanks loads for your help! Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden Tel: 0351 4657770 * Fax: 0351 4657778 * [EMAIL PROTECTED]
backup ceased working? (longer mail)
Hi all, please forgive me posting longer texts to that list, but right now I am into a situation where I sort of feel lost within my amanda configuration and log files. After working well for quite a while, our tape backup ceased working a few days ago, and by now I haven't managed to figure out why. Basically, we do run two configurations - full dump to tapes each weekend, incrementals every weekday. Last weekends full dumps did not finish. Neither did any of the incrementals the last days. I am completely unsure why, the only last thing I can remember having done to the backup machine is chown -R'ing the whole filesystem because of a change in the Windows domain these machines belong to. Initially, I thought incremental to take exceptionally long because due to chown'ing all files have been touched, but after Full dump also ending unfinished, I start doubting this. Unfortunately, I am rather short on evidence on what is goin' on as there hardly are any log messages to make me think. What to be _observed_: - We run dumps from a local disk filesystem directly to tape, no holding disk. - The last days, dumps seemed to be started well, having a bunch of dumpers and a taper process running as well as sendsize/tar, and things seem fine. - Sooner or later, sendsize/tar disappears from the process list, leaving the dumper and taper processes running until all eternity. Attaching to them using strace -p, however, shows that they seem to be waiting - for what? - Manually killing all the processes and doing amcleanup ends in a notification mail to be sent out telling me that all dump results are missing. - Running amverify leaves me thinking that actually nothing has been stored to tape so far. This also fits what amrestore keeps thinking about the tape: --- amverify output: [...] Loading current slot... changer: got exit: 0 str: 3 /dev/nst0 Using device /dev/nst0 Waiting for device to go ready... Rewinding... Processing label... Volume Back07, Date 20060816 Rewinding... End-of-Information detected. Rewinding... --- /amverify --- amrestore output: backer:/tmp# amrestore /dev/nst0 amrestore: missing file header block amrestore: 2: reached end of information --- /amrestore output - The only real? error message to be seen is in amandad.2006XXX.debug: [...] amandad: time 21599.282: /usr/lib/amanda/sendsize timed out waiting for REP data amandad: time 21599.298: sending NAK pkt: ERROR timeout on reply pipe amandad: time 21600.301: pid 19395 finish time Wed Aug 16 09:00:04 2006 - The regular amanda dump logs seem to be fine except for log to not be showing any proof of any dumps put to tape: --- /var/log/amanda/Incremental/log: [...] DISK planner backer.planconnect.net backercfg DISK planner backer.planconnect.net backervar START planner date 20060816 WARNING planner tapecycle (4) = runspercycle (4) STATS driver startup time 0.066 START taper datestamp 20060816 label Back07 tape 0 --- log --- corresponding amdump tail: [...] changer: opening pipe to: /usr/lib/amanda/chg-zd-mtx -slot current changer: got exit: 0 str: 3 /dev/nst0 taper: slot: 3 wrote label `Back07' date `20060816' driver: result time 4.889 from taper: TAPER-OK driver: state time 4.889 free kps: 600 space: 0 taper: idle idle-dumpers: 5 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 driver-idle: not-idle driver: interface-state time 4.889 if : free 600 driver: hdisk-state time 4.889 planner: time 7232.420: got partial result for host backer.planconnect.net disk backervar: 1 - -2K, 2 - -2K, -1 - -2K planner: time 7232.444: got partial result for host backer.planconnect.net disk backercfg: 1 - -2K, -1 - -2K, -1 - -2K planner: time 7232.444: got partial result for host backer.planconnect.net disk refast: 1 - -2K, -1 - -2K, -1 - -2K [...] planner: time 14160.633: got partial result for host backer.planconnect.net disk planc1: 1 - -2K, 2 - -2K, -1 - -2K planner: time 14160.633: got partial result for host backer.planconnect.net disk planc3: 1 - 2471980K, 2 - 2466110K, -1 - -2K taper: DONE [idle wait: 35325.938 secs] taper: writing end marker. [Back07 OK kb 0 fm 0] --- /amdump - sendsize log has a strange error, as well, for some of the files in the backup fs: --- sendsize log: [...] sendsize[19779]: time 31925.159: /bin/tar: ./docs/work/d2845/d894/oi01ngxo/file.hpgl: Warning: Cannot seek to 0: Bad file descriptor sendsize[19779]: time 31925.161: /bin/tar: ./docs/work/d2845/d895/ega9cq2a/file.hpgl: Warning: Cannot seek to 0: Bad file descriptor sendsize[19779]: time 31925.162: /bin/tar: ./docs/work/d2845/d896/z5l00n0d/file.hpgl: Warning: Cannot seek to 0: Bad file descriptor sendsize[19779]: time 32962.193: Total bytes written: 30046720 (280GiB, 44MiB/s) sendsize[19779]: time 32962.205: . sendsize[19779]: estimate time for planc1 level 2: 6551.741 sendsize[19779]: estimate
dump tape full?
Hi all; being merrily running amanda for about three years now, right now our tapes are slowly getting filled. This weekends full dump obviously seems to have completed without errors, but, running amverify ended up with the following: ... amverify Full Mo Jun 12 13:01:54 CEST 2006 Loading current slot... Using device /dev/nst0 Volume Back00, Date 20060610 Checked backer.planconnect.net.planc3.20060610.0 Checked backer.planconnect.net.ablage.20060610.0 Checked backer.planconnect.net.refast.20060610.0 Checked backer.planconnect.net.backervar.20060610.0 Checked backer.planconnect.net.jka.20060610.0 Checked backer.planconnect.net.backercfg.20060610.0 Checked backer.planconnect.net.planc1.20060610.0 End-of-Information detected. Loading next slot... ... Hmmm, there's currently only one tape inside the changer (the one of last weekend), and, according to the amdump log files, last weekends dump filled up about 84% of the tape. So: What does End-of-Information mean in this context? Is the tape (for whichever reason) filled and amverify expecting more information on another one? Did amverify actually finish checking all disks and see the end of the dump? I'm confused here, and the amverify documentation unfortunately wasn't that helpful... For what I saw, ... Checked backer.planconnect.net.planc1.20060610.0. ... makes be believe the check of this part of the backup was successful, am I right on that? Can someone enlighten me (or point me where to read)? Thanks in advance and bye Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: dump tape full?
Hello John, all: and at first thanks for your comments... Jon LaBadie schrieb: to have completed without errors, but, running amverify ended up with the following: This is just guesswork, given that I'm bad and don't run amverify. Hmmm, honestly I am also bad most of the time but a little more careful right now - our backup system consists of an external SCSI-to-IDE RAID system and an LTO-2 autoloader; hosts on the network dump their data to the RAID system and amanda is about to hammer those data to tape at night (incremental) or weekend (full). The RAID system hasn't been in good condition lately after some of the drives went down, so I am worried about the state of my tape backup, as well... That's why I initially played around with amverify in order to see whether there actually _is_ anything backed up at all... :) amverify Full Mo Jun 12 13:01:54 CEST 2006 ... Checked backer.planconnect.net.planc1.20060610.0 End-of-Information detected. Loading next slot... ... Does the list of DLEs shown by amverify match the total of what were expected? Yes. The way it looks until then, at least every DLEs have been processed and found backed up on tape. Did the report that amdump mailed out report early on that Some dumps may have been left on the holding disk? No, nothing like this. Looking at the report mails, everything is fine... The questions above would help confirm this guess, but I suspect that taper actually ran out of space on the tape. Whether the DLE it was taping when it reached the end was backer.planconnect.net.planc1.20060610.0 or the next DLE I don't know. When taper hits the end of the tape the emailed report shows successful tape usage, that is your 84%. The remaining 16% might have been a partially taped DLE. To be a little more verbose on that, here's an excerpt taken from yesterdays Full dump log (sizes): [...] Output Size (meg) 172568.1 172568.10.0 Original Size (meg)372550.6 372550.60.0 Avg Compressed Size (%)46.3 46.3-- Filesystems Dumped7 7 0 Avg Dump Rate (k/s) 1198.0 1198.0-- [...] Tape Size (meg)172568.1 172568.10.0 Tape Used (%) 86.4 86.40.0 Filesystems Taped 7 7 0 [..] USAGE BY TAPE: LabelTime Size %NbNc Back00 40:59 176709760k 86.4 7 0 I'm not sure right now, but the way I understand this, we did back up 372.5 gig of data (which seems reasonable looking at the RAID disk usage), compressed to 172.5gig. Assuming that LTO-2 at this level is capable of storing 200gig data, the 86.4% usage of that very (single) tape do make sense. This way, the End-Of-Information message seems rather obscure... :o Any more ideas, anyone? :) Thanks for your patience and bye, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: [OT] stupid question: amanda company references?
Hi all,... ...and, simply, thanks for all your hints / input. I can imagine that several corporations don't want to talk about the sort of software they chose and run - anyhow I am thankful to at least have some hints about people using the same software we do. Thanks a lot anyone! Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
[OT] stupid question: amanda company references?
Hi all,... ...after our amanda installation works pretty smoothly right now (thanks to all those around here who were of very much help during getting this done!), I'm left with a slightly non-technical, probably rather stupid question which, somehow, is important as I am doing documentation of that project: Since our company's administration is _very_ interested in knowing who else uses the software we use, so I am searching for sort of a list of companies, institutions,... that successfully run amanda to store their valuable data. On amanda.org, there ain't such a thing; so, whoever you are out there: If you're using amanda, do you mind telling me which company you work for, in which business you are and what amounts of data you use to back up using amanda? Thanks and bye, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: regular expression
Hi Pascal,... On Tue, 30 Mar 2004 11:21:21 +0100 pascal thomas [EMAIL PROTECTED] wrote: what exactly means the * and the $ in the following line? labelstr ^Full-[0-9][0-9]*$ $ indicates the end-of-line (end of the string, in this case). A construct like [0-9]* means that there might zero or more of the specified characters may follow up, meaning this pattern should match Full-1 Full-14 Full-203 Full-5910 . . . and so on. :) Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: scsi-changer debugging...
Hi Christoph, Joshua et al,... On Sat, 13 Mar 2004 08:36:33 +0100 Christoph Scheeder [EMAIL PROTECTED] wrote: seems like chg-scsi does not know your changer/tape at the moment, and as a result can't handle the messages it get's back from it. if you have a little experience with programming, have a descrition of the sense-codes your changer generates and a little bit time left, you can take a look at chg-scsi.c/h in the sources of amanda. There are some tables defining the sensecodes returned Thanks to the both of your for your hints; much appreciated (as always; I've seen way too much friendly helping on this list by now - thanks everyone!). So, situation is as follows: I temporarily switched my configuration to use chg-zd-mtx, yesterday, and it seems to just work. Good, so far. About the chg-scsi - situation: I'll check whether I can find sensecodes for that machine and try to get them into the chg-scsi source as soon as I've got some spare minutes to do that, would be glad to do a (though damn small) contribution to this fine piece of work. Cheers and thanks, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: mixed full / incremental backup...
Hi Stefan et al,... ...and at first, thanks for all the input - much appreciated! :) On Tue, 9 Mar 2004 11:17:26 +0100 Stefan G. Weichinger [EMAIL PROTECTED] wrote: Wrong syntax there ... Doesn't amcheck complain ?? Not really, everything seems to be fine, though I made some modifications in my configuration according to the hints I gathered here. Anyhow, in the end I guess it all comes down to some problems with our autoloader working with chg-scsi, sometimes ending amcheck / amdump without finding the correct tape, sometimes (like this morning) freezing a chg-scsi -slot current process for hours (backup scheduled to start at 6:00 am, still waiting in right this situation at 9:30 am ... :/ ). I'll play around with the changer debugging options and see what happens... :( Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
scsi-changer debugging...
Hi all,... ...after still having some weird issues with my backup runs not running as expected (scheduled) running chg-scsi, I was playing around with the debug files a little, and here's the result (see attached: scsidebug): basically, after START SCSI_LoadUnload, messages like ---snip--- # START SenseHandler Ident = [ULTRIUM-TD2], function = [generic_changer] # START GenericSenseHandler # START DecodeSense GenericSenseHandler : Sense Keys Extended Sense ASC 04 ASCQ 00 Sense key 02 Not Ready Sense2Action START : type(1), ignsense(0), sense(02), asc(04), ascq(00) Sense2Action generic start : Sense2Action generic END : no match for generic return - 2/Default for SENSE_ NOT_READY # STOP GenericSenseHandler STOP SenseHandler ---snip--- keep filling up my chg-scsi.*.debug log; most of the times the file itself grows up to 500k just filled with those message. There doesn't seem to be a way to reproduce why exactly this is happening, as it doesn't seem to depend on whether the right tape is in drive or no tape is loaded at all. It also doesn't happen all the time; sometimes am[check|dump] just run through smoothly without any trouble at all. I'm currently thinking about several different ways of dealing with this, including usage of chg-multi instead of chg-scsi but I wanted to check whether anyone actually has experiences already running amanda using the following device: backer:~# loaderinfo -f /dev/sg4 Product Type: Medium Changer Vendor ID: 'NEC ' Product ID: 'LL0101H-0A ' Revision: '0002' Attached Changer: No EAAP: Yes Number of Medium Transport Elements: 1 Number of Storage Elements: 10 Number of Import/Export Element Elements: 0 Number of Data Transfer Elements: 1 Transport Geometry Descriptor Page: Yes Invertable: No Device Configuration Page: Yes Can Transfer: No I attached a scsidebug output and my changer.conf just in case anyone might wants to look at it... TIA and have a calm friday / weekend anyone... Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED] scsidebug Description: Binary data changer.conf Description: Binary data
mixed full / incremental backup...
Hi all,... Since people around here still are stuck wanting to have a friday-full/rest-of-the-week-incremental backup strategy, I read through http://www.backupcentral.com/amanda-19.html created two amanda configurations with the same disklist for full and for incremental backup, labeled my tapes and tested the whole mess. About the full backup, things work pretty fine. However, trying to run the incremental setup always leaves me with an error mail such as below: *** A TAPE ERROR OCCURRED: [label Back06 or new tape not found in rack]. Some dumps may have been left in the holding disk. This is strange - tape Back06 actually _is_ inside the changer and labeled correctly. FAILURE AND STRANGE DUMP SUMMARY: larger than tape, -1 KB, skipping incremental] localhost work/04 lev 1 FAILED [dump larger than tape, -1 KB, skipping incremental] localhost project lev 1 FAILED [dump larger than tape] This is what always uses to show up in those situations - dump larger than tape for all the dle's I used to set up. I doubt that because the full dump itself fits on tape rather well. Can anyone point me where to put my eyes to get this fixed? amanda.conf of the incremental setup is included. TIA, have a fine day everyone. Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED] amanda.conf Description: Binary data
Re: mixed full / incremental backup...
Hi Stefan, ...and at first, thanks for your reply. On Tue, 9 Mar 2004 10:02:59 +0100 Stefan G. Weichinger [EMAIL PROTECTED] wrote: KR This is strange - tape Back06 actually _is_ inside the changer KR and labeled correctly. Does amcheck run through fine ? Is Back06 in your tapelist? I got that fixed in the meantime finding out that the tape was unloaded to a slot this amanda-setup is not intended to use. Entirely my fault... KR doubt that because the full dump itself fits on tape rather KR well. At first let me tell you that you should not use localhost in your DLEs. Use the fully qualified hostname (FQDN) instead. localhost bites you at recovery time. Okay, thanks for the hint. Anyhow, I am just running amanda to back up files from this one host; is the naming likely to get me into trouble even this way? 2. The message does not say that localhost:work/04 does not fit on tape. It says that the size of the whole dump (~ all DLEs) is larger than your tape. Hmmm, okay, but even this seems to be strange while the full dump doesn't complain about this and just moves anything found in the file area to tape... KR Can anyone point me where to put my eyes to get this fixed? KR amanda.conf of the incremental setup is included. And the disklist? see attachment. :) Basically, I split up the base directory of our document management system into several smaller chunks because it won't take long for the tree to not fit on a single tape anymore... Thanks / bye, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED] disklist Description: Binary data
Re: mixed full / incremental backup...
Hi again,...
On Tue, 9 Mar 2004 10:52:02 +0100
Stefan G. Weichinger [EMAIL PROTECTED] wrote:
KR Okay, thanks for the hint. Anyhow, I am just running amanda to
KR back up files from this one host; is the naming likely to get
KR me into trouble even this way?
amrecover will not work as expected.
Hmm, this is not a good thing, so I will change this.
[disklist]
You have in your disklist:
localhost work/04 /backup/PlanC3/bf381/docs/work {
I am not sure but I would not use something like work/04 as
diskname.
The diskfile is the same for the incremental and the full backup,
and running the full backup works as expected with the same dle's...
At least I'll modify the hostname there to have this fixed.
Show us your AMANDA email report ...
(see attached...)
Cheers,
Kris
--
Kristian Rink -- Programmierung/Systembetreuung
planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden
0176 24472771 * [EMAIL PROTECTED]
planConnect_AMANDA_MAIL_REPORT_FOR_March_9,_2004
Description: Binary data
[SOLVED(?)]: Re: getting past sendsize
Hi Stefan, Charlie et al,...
...and at first, thanks for your hints / recommendations. Actually,
after frequently being stuck with sendsize, I once again checked all
my configuration, run amcheck to fix up three or four errors in my
disklist (caused by missing blanks, like
localhost sql /backup/PlanC3/Mssql7{
^
root-tar
} 1
instead of
localhost sql /backup/PlanC3/Mssql7 {
root-tar
} 1
), and now in the end it seems I am having a working backup on my
tapes. Good thing. Thanks all for your hints! :)
Cheers,
Kris
--
Kristian Rink -- Programmierung/Systembetreuung
planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden
0176 24472771 * [EMAIL PROTECTED]
amandahostsauth failed
Hi all,... ...slowly getting my amanda system to work with our tape libary, by now I am still not able to dump any data to tape. In the end, amdump each and every time fails with ERROR planner localhost: [access as backup not allowed from [EMAIL PROTECTED] amandahostsauth failed I found some solutions to amandahostsauth failures while googling around, modified both the /etc/amandahosts and /var/backups/.amandahosts file in several ways and yet haven't found a working solution for that problem. Amanda is only running on one single server (Debian testing) and is configured to just dump a huge drive connected right to that server, so there's just one host involved in this configuration. Can anyone point me a direction to success? :) TIA and bye, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: amandahostsauth failed
Hi Stefan et al,... On Tue, 24 Feb 2004 12:45:17 +0100 Stefan G. Weichinger [EMAIL PROTECTED] wrote: backer backup even better backer.domain.xyz backup Hmmm, that did it! Actually, removing localhost from the amandahosts helped much, and now the whole system seems to do something. Goood - thanks a lot! :)) Btw: Where to post a new amanda tapetype definition for the FAQs? Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
getting past sendsize
Hello all,... ...now that amanda on my server finally is doing something, I am (unfortunately) stuck with the next strange thing. First of all: The file system I am about to back up is on an external RAID system and around 600 GB in size so I am using GNUTAR to back up the whole mess (since, at least as I read in various mailing lists, it's not possible to make amanda dump file systems across multiple tapes). Most of the things seem to work fine, amdump itself starts, spawns several dumper-processes and launches an amandad which starts sendsize and does a tar across the filesystem to be backed up. Some minutes later, all the processes ended again, nothing has been written to any tape, and I am grepping around the amanda documentation, being pretty clueless where to look at, now. Can someone enlighten me (again)? TIA, have a calm afternoon anyone. Cheers, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
