backing up huge partitions (100G) / full backups
Hello *, we're going to set up a backup-server running Amanda and using a 'HP SureStore Autoloader 1/9' with FreeBSD. We're planning to use a 73GB (ok, technically it's 70GB) (dedicated) holding disk. One of our Servers has a 140GB Partition (on RAID) and has almost uncompressable data. As I read in the FAQ it is not possible to split dumps to multiple tapes using amanda. Our Autoloader has a stacker-mode, where all 9 DLT tapes are logically concaternated and the system sees just one tapedrive with 360GB. But on the other hand amanda wants to have /one tape per day/ for the incre- mental backups it wouldn't be a really good idea to change 9 tapes every day with only just some little incrementals on it :-/ Is it possible to run a multi-volume tar as a full backup manually and just use dump to get the incrementals (in amanda)? It would need 3 /9 of our tapes, and the other 6 tapes will be available to use with Amanda. What do you think all about this? Any other/better ideas? TIA Regards Raphael Becker PS: mtx is able to talk to the autoloader through /dev/pass0 (= /dev/sg0 in Linux), so using it will not be a problem for me. In stacker-mode the loader is handled internally only / is not available to the host. PPS: Loader-Info in dmesg: sa0 at ahc0 bus 0 target 1 lun 0 sa0: BNCHMARK DLT1 391B Removable Sequential Access SCSI-2 device sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) pass0 at ahc0 bus 0 target 0 lun 0 pass0: HP C7145 2330 Removable Changer SCSI-3 device pass0: 3.300MB/s transfers
Re: Confirmation for subscribe amanda-users
I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: *** sendsize: debug 1 pid 10396 ruid 33 euid 33 start time Thu Jan 24 03:54:22 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 10396 finish time Thu Jan 24 03:54:23 2002 ** However, when I run dump manually on wookie, it runs with no problem and: /sbin/dump 0Ssf 1048576 - /dev/sda2 displays: 9334784 I have read the FAQ and the question regarding this issue did not seem to apply. The filesystem is very small and I didn't really understand the rest. I am in the testing phase and this is the only filesystem I am attempting to dump in an attempt to isolate the problem. I am running Red Hat Linux 7.2 and amanda-2.4.2p2 on the client and host. Can anyone help? I can post any files needed to help diagnose the problem. Thanks, Dick
Re: Confirmation for subscribe amanda-users
On 24 Jan 2002 at 11:10am, [EMAIL PROTECTED] wrote I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Second, dump isn't being run with the proper permissions. What group is the amanda user in? And what does 'ls -l /dev/sda2' say? However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: backing up huge partitions (100G) / full backups
On Thu, 24 Jan 2002 at 11:42am, Raphael H. Becker wrote Is it possible to run a multi-volume tar as a full backup manually and just use dump to get the incrementals (in amanda)? It would need 3 /9 of our tapes, and the other 6 tapes will be available to use with Amanda. dump would need something from which to calculate the incrementals, so I don't think that would work. What do you think all about this? Any other/better ideas? I've got a 560GB RAID that I backup using AIT1 tapes. I use tar, and split the RAID up into lots of smaller chunks (by user, e.g.). You just have to make sure that none of the chunks get bigger than a tape. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: backing up huge partitions (100G) / full backups
On Thu, Jan 24, 2002 at 07:11:46AM -0500, Joshua Baker-LePain wrote: On Thu, 24 Jan 2002 at 11:42am, Raphael H. Becker wrote Is it possible to run a multi-volume tar as a full backup manually and just use dump to get the incrementals (in amanda)? It would need 3 /9 of our tapes, and the other 6 tapes will be available to use with Amanda. dump would need something from which to calculate the incrementals, so I don't think that would work. You can update the /etc/dumpdates file by hand. This is what dump uses to determine when the last dump of a given level was performed. -- Steve Feehan
Problem with amoverview: Bad interpreter?
I just noticed a problem this morning. When I run amoverview, I get: amanda@admin:~ amoverview DailySet1 bash: /usr/local/sbin/amoverview: bad interpreter: No such file or directory amanda@admin:~ I could have sworn I've run amoverview on this system before without problems. The listing doesn't seem to indicate that anything has changed with the file: -rwxr-xr-x1 amanda disk 4351 Jan 4 11:21 /usr/local/sbin/amoverview However, amcheck seems to work fine: amanda@admin:~ amcheck DailySet1 Amanda Tape Server Host Check - Holding disk /var/amanda: 5664532 KB disk space available, that's plenty NOTE: skipping tape-writable test Tape DailySet106 label ok Server check took 20.453 seconds Amanda Backup Client Hosts Check Client check: 5 hosts checked in 0.065 seconds, 0 problems found (brought to you by Amanda 2.4.3b1) amanda@admin:~ I also got what looks like a normal backup off the system last night. I searched the archives for interpreter but got no hits. Anyone seen this problem before? Any suggestions for fixing it? Thanks for your thoughts and time. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139
End of tape errors
Hello all. We have been experiencing some very strange errors on our Sun StorEdge L20 system and were wondering if anyone had similar problems or knew of a solution. Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. That began to fail when the amount of data reached a significant size. We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. The only thing different from the tapetype suggestion is that we changed the filemark from 0 to 2024 kbytes. Is my filemark issue the problem or is something sinister afoot? Michael Campfield Labstaff Computer Science Department University of Tennessee, Knoxville
Re: End of tape errors
Did you add those patches ??? 111972-02 112068-01 Chamby - Original Message - From: Michael P Campfield [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 10:10 AM Subject: End of tape errors Hello all. We have been experiencing some very strange errors on our Sun StorEdge L20 system and were wondering if anyone had similar problems or knew of a solution. Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. That began to fail when the amount of data reached a significant size. We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. The only thing different from the tapetype suggestion is that we changed the filemark from 0 to 2024 kbytes. Is my filemark issue the problem or is something sinister afoot? Michael Campfield Labstaff Computer Science Department University of Tennessee, Knoxville
amanda fails after upgrade
Hi, I upgraded one of the i386 hosts to RedHat 7.2 and now the server running amanda amanda-2.4.1p1 returns an error: WARNING: xtreme19: selfcheck request timed out. Host down? The amanda client log file amandad..debug ends with: amandad: error [getpwuid(33) fails] error [getpwuid(33) fails] What does it mean? Thanks in advance, Ted amandad: debug 1 pid 21482 ruid 33 euid 33 start time Thu Jan 24 07:18:04 2002 amandad: version 2.4.2p2 amandad: build: VERSION=Amanda-2.4.2p2 amandad:BUILT_DATE=Fri Jul 13 18:48:49 EDT 2001 amandad:BUILT_MACH=Linux stripples.devel.redhat.com 2.4.5-10enterprise #1 SMP Wed Jun 27 14:01:18 EDT 2001 i686 unknown amandad:CC=gcc amandad: paths: bindir=/usr/bin sbindir=/usr/sbin amandad:libexecdir=/usr/lib/amanda mandir=/usr/share/man amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda amandad:CONFIG_DIR=/etc/amanda DEV_PREFIX=/dev/ amandad:RDEV_PREFIX=/dev/r DUMP=/sbin/dump amandad:RESTORE=/sbin/restore SAMBA_CLIENT=/usr/bin/smbclient amandad:GNUTAR=/bin/tar COMPRESS_PATH=/usr/bin/gzip amandad:UNCOMPRESS_PATH=/usr/bin/gzip MAILER=/usr/bin/Mail amandad:listed_incr_dir=/var/lib/amanda/gnutar-lists amandad: defs: DEFAULT_SERVER=localhost DEFAULT_CONFIG=DailySet1 amandad:DEFAULT_TAPE_SERVER=localhost amandad:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN=amanda FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc got packet: Amanda 2.4 REQ HANDLE 006-60850508 SEQ 1011885348 SECURITY USER amanda SERVICE selfcheck OPTIONS ; GNUTAR /home82 0 OPTIONS |;bsd-auth;index;exclude-list=/usr/local/etc/amanda/exclude; GNUTAR /usr/pgi 0 OPTIONS |;bsd-auth;index;exclude-list=/usr/local/etc/amanda/exclude; GNUTAR /usr/local 0 OPTIONS |;bsd-auth;index;exclude-list=/usr/local/etc/amanda/exclude; GNUTAR / 0 OPTIONS |;bsd-auth;index;exclude-list=/usr/local/etc/amanda/exclude; sending ack: Amanda 2.4 ACK HANDLE 006-60850508 SEQ 1011885348 amandad: error [getpwuid(33) fails] error [getpwuid(33) fails] amandad: pid 21482 finish time Thu Jan 24 07:18:04 2002
Re: Problem with amoverview: Bad interpreter?
KEVIN ZEMBOWER wrote: I just noticed a problem this morning. When I run amoverview, I get: amanda@admin:~ amoverview DailySet1 bash: /usr/local/sbin/amoverview: bad interpreter: No such file or directory Somebody moved perl to another place, or simply renamed it (or removed it?) See the first line in amoverview. It looks like: #!/bin/perl at me, and it should point to the perl executable. -- Paul Bijnens, Lant Tel +32 16 40.51.40 Interleuvenlaan 15 H, B-3001 Leuven, BELGIUM Fax +32 16 40.49.61 http://www.lant.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 * ***
GNUtar instead of dump, no time estimate
Hi all,
maybe this is no problem but lack of information:
I use GNUtar instead of dump.
There is no time estimation done:
---cut-on---
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 1:02
---cut-off---
I'd appreciate a funded information about that.
adTHANXvance
Sascha Wuestemann
Re: amanda fails after upgrade
On Thu, 24 Jan 2002 at 10:26am, Ted Sariyski wrote The amanda client log file amandad..debug ends with: amandad: error [getpwuid(33) fails] error [getpwuid(33) fails] Did you remember to add the amanda user? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Problem with amoverview: Bad interpreter?
Thank you so much, Paul. Yes, it was that simple. I did change a symlink for perl, but I just didn't realize that amoverview was a perl program until I looked at it. Thanks for your help. -Kevin Zembower Paul Bijnens [EMAIL PROTECTED] 01/24/02 10:40AM KEVIN ZEMBOWER wrote: I just noticed a problem this morning. When I run amoverview, I get: amanda@admin:~ amoverview DailySet1 bash: /usr/local/sbin/amoverview: bad interpreter: No such file or directory Somebody moved perl to another place, or simply renamed it (or removed it?) See the first line in amoverview. It looks like: #!/bin/perl at me, and it should point to the perl executable. -- Paul Bijnens, Lant Tel +32 16 40.51.40 Interleuvenlaan 15 H, B-3001 Leuven, BELGIUM Fax +32 16 40.49.61 http://www.lant.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 * ***
amrecover can't find index files...
Hello all, I'm having a problem restoring from tape. Here's what it spits back: amrecover setdate 2002-01-09 200 Working date set to 2002-01-09. amrecover sethost host1 200 Dump host set to host1. amrecover setdisk c1t6d0s7 Warning: no log files found for tape user-week-3 written 2002-01-09 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator The file 'host1/c1t6d0s7/20020109_0.gz' does indeed exist in the indexdir as specified in amanda.conf. I've heard about some versions of tar can screw up the index file (adding extra numbers to the start of each line), so I checked and they look fine. From 'hots1/c1t6d0s7/20020109_0.gz': /rootmail/logsold/585 /rootmail/logsold/586 /rootmail/logsold/587 /rootmail/logsold/588 /rootmail/logsold/589 /rootmail/logsold/590 /rootmail/logsold/591 /quotas /coolbay/ /coolbay/.mail I've every thing I can think of, and am running out of options. Any suggestions would be greatly appreciated. --Chris
Re: amrecover can't find index files...
On Thu, Jan 24, 2002 at 12:14:11PM -0500, Chris Noon wrote: Hello all, I'm having a problem restoring from tape. Here's what it spits back: amrecover setdate 2002-01-09 200 Working date set to 2002-01-09. amrecover sethost host1 200 Dump host set to host1. amrecover setdisk c1t6d0s7 Warning: no log files found for tape user-week-3 written 2002-01-09 The index will not be found if the log file is not there? Where is your log file (log.20020109.0)? Jean-Louis 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator The file 'host1/c1t6d0s7/20020109_0.gz' does indeed exist in the indexdir as specified in amanda.conf. I've heard about some versions of tar can screw up the index file (adding extra numbers to the start of each line), so I checked and they look fine. From 'hots1/c1t6d0s7/20020109_0.gz': /rootmail/logsold/585 /rootmail/logsold/586 /rootmail/logsold/587 /rootmail/logsold/588 /rootmail/logsold/589 /rootmail/logsold/590 /rootmail/logsold/591 /quotas /coolbay/ /coolbay/.mail I've every thing I can think of, and am running out of options. Any suggestions would be greatly appreciated. --Chris -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: amanda fails after upgrade
On Thu, 24 Jan 2002 at 11:03am, Ted Sariyski wrote Joshua Baker-LePain wrote: Did you remember to add the amanda user? Yes, Even I can rsh from the server to the client without a password. And is the UID the same as it was before? Did you do a upgrade install, or did you wipe the filesystems and start over? (P.S. Please keep amanda-users on the cc list, so everyone can help out.) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: amrecover can't find index files...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jean-Louis Martineau Sent: Thursday, January 24, 2002 1:00 PM To: Chris Noon Cc: [EMAIL PROTECTED] Subject: Re: amrecover can't find index files... I found the log file in $logdir/oldlog . I don't know if this oldlog dir was setup by amamda (couldn't find any mention of it in amanda.conf), so I tried moving it back to the logdir. I ran amrecover again and it found the logfile, but still couldn't find the index. amrecover setdisk c1t6d0s7 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator Although, I'm pretty sure I recall getting the no log file warnging before, yet it still finding the index. Are you sure that the log file is a prerequisite for finding the indexes? --Chris On Thu, Jan 24, 2002 at 12:14:11PM -0500, Chris Noon wrote: Hello all, I'm having a problem restoring from tape. Here's what it spits back: amrecover setdate 2002-01-09 200 Working date set to 2002-01-09. amrecover sethost host1 200 Dump host set to host1. amrecover setdisk c1t6d0s7 Warning: no log files found for tape user-week-3 written 2002-01-09 The index will not be found if the log file is not there? Where is your log file (log.20020109.0)? Jean-Louis 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator The file 'host1/c1t6d0s7/20020109_0.gz' does indeed exist in the indexdir as specified in amanda.conf. I've heard about some versions of tar can screw up the index file (adding extra numbers to the start of each line), so I checked and they look fine. From 'hots1/c1t6d0s7/20020109_0.gz': /rootmail/logsold/585 /rootmail/logsold/586 /rootmail/logsold/587 /rootmail/logsold/588 /rootmail/logsold/589 /rootmail/logsold/590 /rootmail/logsold/591 /quotas /coolbay/ /coolbay/.mail I've every thing I can think of, and am running out of options. Any suggestions would be greatly appreciated. --Chris -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: End of tape errors
Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. ... Those numbers seem reasonable. Why do you think they are too high? Are you using hardware compression (put a different way, what device name are you using for the tape drive)? Are you using software compression? That began to fail when the amount of data reached a significant size. ... What do you mean by significant? We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. The filemark and length of tape values are **only** used by Amanda to do the estimates. Once the actual backups start, Amanda keeps writing until it gets an error. So when it reported the short write, that's exactly what it meant -- you banged into physical end of tape. There should have been a line something like this in the NOTES section: taper: tape 041138/champion kb 43321088 fm 34 writing file: short write This tells you *exactly* how much data had been written when the OS returned the error (43321088 KBytes - ~41.3 GBytes in the example). So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. That looks like you used the wrong density or forced it on the front panel. What device name did you use? Did you make certain the tape mounted at 35.0 GByte density? The only thing different from the tapetype suggestion is that we changed the filemark from 0 to 2024 kbytes. As above, that would only affect how much Amanda had to work with to do the estimates. It would have nothing to do with actually writing to the tape. Michael Campfield John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: GNUtar instead of dump, no time estimate
There is no time estimation done: ... Estimate Time (hrs:min)0:00 What version of Amanda? In the corresponding log.MMDD.NN file, what does the STATS driver startup time line say? Sascha Wuestemann John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: amrecover can't find index files...
Eureka! It seems I had a bit of a compound problem. there *was* an issue with the log files, but after I followed your advice and put the logfile back into $logdir, amanda seemed to dislike the fact that the tape wasn't rewound (but didn't bother to report it :/). after doing an mt r and having the log file in the proper location, it worked like a champ. Thank you much Jean and Rebecca!! --Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jean-Louis Martineau Sent: Thursday, January 24, 2002 1:00 PM To: Chris Noon Cc: [EMAIL PROTECTED] Subject: Re: amrecover can't find index files... I found the log file in $logdir/oldlog . I don't know if this oldlog dir was setup by amamda (couldn't find any mention of it in amanda.conf), so I tried moving it back to the logdir. I ran amrecover again and it found the logfile, but still couldn't find the index. amrecover setdisk c1t6d0s7 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator Although, I'm pretty sure I recall getting the no log file warnging before, yet it still finding the index. Are you sure that the log file is a prerequisite for finding the indexes? --Chris On Thu, Jan 24, 2002 at 12:14:11PM -0500, Chris Noon wrote: Hello all, I'm having a problem restoring from tape. Here's what it spits back: amrecover setdate 2002-01-09 200 Working date set to 2002-01-09. amrecover sethost host1 200 Dump host set to host1. amrecover setdisk c1t6d0s7 Warning: no log files found for tape user-week-3 written 2002-01-09 The index will not be found if the log file is not there? Where is your log file (log.20020109.0)? Jean-Louis 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator The file 'host1/c1t6d0s7/20020109_0.gz' does indeed exist in the indexdir as specified in amanda.conf. I've heard about some versions of tar can screw up the index file (adding extra numbers to the start of each line), so I checked and they look fine. From 'hots1/c1t6d0s7/20020109_0.gz': /rootmail/logsold/585 /rootmail/logsold/586 /rootmail/logsold/587 /rootmail/logsold/588 /rootmail/logsold/589 /rootmail/logsold/590 /rootmail/logsold/591 /quotas /coolbay/ /coolbay/.mail I've every thing I can think of, and am running out of options. Any suggestions would be greatly appreciated. --Chris -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
RE: amrecover can't find index files...
Eureka! It seems I had a bit of a compound problem. there *was* an issue with the log files, but after I followed your advice and put the logfile back into $logdir, amanda seemed to dislike the fact that the tape wasn't rewound (but didn't bother to report it :/). after doing an mt r and having the log file in the proper location, it worked like a champ. Thank you much Jean and Rebecca!! --Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jean-Louis Martineau Sent: Thursday, January 24, 2002 1:00 PM To: Chris Noon Cc: [EMAIL PROTECTED] Subject: Re: amrecover can't find index files... I found the log file in $logdir/oldlog . I don't know if this oldlog dir was setup by amamda (couldn't find any mention of it in amanda.conf), so I tried moving it back to the logdir. I ran amrecover again and it found the logfile, but still couldn't find the index. amrecover setdisk c1t6d0s7 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator Although, I'm pretty sure I recall getting the no log file warnging before, yet it still finding the index. Are you sure that the log file is a prerequisite for finding the indexes? --Chris On Thu, Jan 24, 2002 at 12:14:11PM -0500, Chris Noon wrote: Hello all, I'm having a problem restoring from tape. Here's what it spits back: amrecover setdate 2002-01-09 200 Working date set to 2002-01-09. amrecover sethost host1 200 Dump host set to host1. amrecover setdisk c1t6d0s7 Warning: no log files found for tape user-week-3 written 2002-01-09 The index will not be found if the log file is not there? Where is your log file (log.20020109.0)? Jean-Louis 200 Disk set to c1t6d0s7. No index records for disk for specified date If date correct, notify system administrator The file 'host1/c1t6d0s7/20020109_0.gz' does indeed exist in the indexdir as specified in amanda.conf. I've heard about some versions of tar can screw up the index file (adding extra numbers to the start of each line), so I checked and they look fine. From 'hots1/c1t6d0s7/20020109_0.gz': /rootmail/logsold/585 /rootmail/logsold/586 /rootmail/logsold/587 /rootmail/logsold/588 /rootmail/logsold/589 /rootmail/logsold/590 /rootmail/logsold/591 /quotas /coolbay/ /coolbay/.mail I've every thing I can think of, and am running out of options. Any suggestions would be greatly appreciated. --Chris -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
RE: amanda fails after upgrade
Sounds like a firewall to me: /etc/init.d/ipchains stop /etc/init.d/iptables stop -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Baker-LePain Sent: Thursday, January 24, 2002 1:30 PM To: Ted Sariyski Cc: [EMAIL PROTECTED] Subject: Re: amanda fails after upgrade On Thu, 24 Jan 2002 at 11:03am, Ted Sariyski wrote Joshua Baker-LePain wrote: Did you remember to add the amanda user? Yes, Even I can rsh from the server to the client without a password. And is the UID the same as it was before? Did you do a upgrade install, or did you wipe the filesystems and start over? (P.S. Please keep amanda-users on the cc list, so everyone can help out.) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Will do. Second, dump isn't being run with the proper permissions. What group is the amanda user in? From /etc/group: disk:x:6:root,rwk,amanda And what does 'ls -l /dev/sda2' say? brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 Also, amcheck *does* run successfully. Please advise and thank you for your help! Dick However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
advfs.diff
Does anyone know if the advfs.diff patch is already included in the redhat release for 7.2, namely: amanda-2.4.2p2-4.rpm amanda-client-2.4.2p2-4.rpm amanda-server-2.4.2p2-4.rmp Thanks, Dick
Remote amrestore
Installed basic amanda on RH7.2 using RH rpm's got basic system running and tried default /etc backup of localhost. amrestore allowed single file restore... interface seems simple enough to use. updated disklist with remote machine this time using comp-root for / on a machine with 15G in use. backup went just fine. tried to do amrestore got error message: # amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d /dev/nst0 AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ... amrecover: Unexpected server end of file. the /tmp/amanda/amrecover.2002datestuff.debug file contains. amrecover: debug 1 pid 29658 ruid 0 euid 0 start time Thur ... amrecover: stream_client: connected to 65.64.90.11.10082 amrecover: stream_client: our side is 0.0.0.0.540 I have entries for amanda, amandaidx, amidxtape in /etc/services for both the client and server. I have restarted network and xinetd on both servers RH 7.2 is using /etc/xinetd.d for inetd configuration. There are 3 files, one for amanda, amandaidx, amidxtape. On both machines I have these set to disable=no tried to find archives to look through... latest I could find on ftp site ended in 1999. references in those messages seemed to point to problems in /etc/services and /etc/inetd.conf I have reviewed all that and added the 10082 10083 entries on both machines with the above noted restarted services. nothing seems to change the error (except putting the firewall up on the server... but that is down for these testsgrin) Any pointers or ideas would be appreciated. thanks Kurt L Vanderwater President, Meridian Data Systems, Inc. Phone: (405) 755-6690 Fax: (405) 415-0676
Re: Remote amrestore
# amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d /dev/nst0 AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ... amrecover: Unexpected server end of file. the /tmp/amanda/amrecover.2002datestuff.debug file contains. ... What's in /tmp/amanda/amindexd*debug on tserv.meridian-ds.com? RH 7.2 is using /etc/xinetd.d for inetd configuration. What's the amindexd config file look like? In particular, make sure you do *not* have a server args (or whatever it's called) entry. tried to find archives to look through... latest I could find on ftp site ended in 1999. Look toward the bottom of the Amanda web page (www.amanda.org). It refers you to the searchable E*groups (Yahoo) mailing list archive. Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Remote amrestore
# amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d
/dev/nst0
AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ...
amrecover: Unexpected server end of file.
the /tmp/amanda/amrecover.2002datestuff.debug file contains.
...
What's in /tmp/amanda/amindexd*debug on tserv.meridian-ds.com?
amindexd: debug 1 pid 28366 ruid 33 euid 33 start time Thu Jan 24 16:29:08
2002
amindexd: version 2.4.2p2
gethostbyaddr: Success
amindexd: pid 28366 finish time Thu Jan 24 16:29:08 2002
RH 7.2 is using /etc/xinetd.d for inetd configuration.
What's the amindexd config file look like? In particular, make sure
you do *not* have a server args (or whatever it's called) entry.
couldn't find amindexd... at least not in refernce to /etc/xinetd.d
so... assuming you meant one of the files in /etc/xinetd.d
in all cases, there server args thingie (very technical term) doesn't seem
to be there.
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amanda
group = disk
server = /usr/lib/amanda/amandad
}
# default: off
#
# description: Part of the Amanda server package
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amindexd
}
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amidxtaped
}
tried to find archives to look through... latest I could find on ftp site
ended in 1999.
Look toward the bottom of the Amanda web page (www.amanda.org). It refers
you to the searchable E*groups (Yahoo) mailing list archive.
I'll look there... thanks
Kurt L Vanderwater
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** amandad*debug says: ** amandad: debug 1 pid 8614 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 amandad: version 2.4.2p2 amandad: build: VERSION=Amanda-2.4.2p2 amandad:BUILT_DATE=Thu Jan 24 16:50:09 MST 2002 amandad:BUILT_MACH=Linux wookie.americom.com 2.2.16-22enterprise #1 SMP Tue Aug 22 16:29:32 EDT 2000 i686 unknown amandad:CC=gcc amandad: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin amandad:libexecdir=/usr/local/libexec mandir=/usr/local/man amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda amandad:CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/ amandad:RDEV_PREFIX=/dev/ DUMP=/sbin/dump amandad:RESTORE=/sbin/restore SAMBA_CLIENT=/usr/bin/smbclient amandad:GNUTAR=/bin/gtar COMPRESS_PATH=/usr/bin/gzip amandad:UNCOMPRESS_PATH=/usr/bin/gzip MAILER=/usr/bin/Mail amandad:listed_incr_dir=/usr/local/var/amanda/gnutar-lists amandad: defs: DEFAULT_SERVER=wookie.americom.com amandad:DEFAULT_CONFIG=DailySet1 amandad:DEFAULT_TAPE_SERVER=wookie.americom.com amandad:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN=amanda FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc got packet: Amanda 2.4 REQ HANDLE 000-20720708 SEQ 1011917624 SECURITY USER amanda SERVICE sendsize OPTIONS maxdumps=1;hostname=wookie.internal.americom.com; DUMP /boot 0 1970:1:1:0:0:0 -1 sending ack: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 bsd security: remote host gorn.americom.com user amanda local user amanda amandahosts security check passed amandad: running service /usr/local/libexec/sendsize amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-20720708 SEQ 1011917624 OPTIONS maxdumps=1; /boot 0 SIZE -1 amandad: got packet: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 amandad: pid 8614 finish time Thu Jan 24 17:13:44 2002 ** killpgrp*debug says: ** killpgrp: debug 1 pid 8616 ruid 33 euid 0 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/killpgrp: version 2.4.2p2 sending SIGTERM to process group 8616 child process exited with status 1 ** The amcheck program succeeds. Is there anything I can run on the client to indicate why it is failing? Thanks, Dick I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Will do. Second, dump isn't being run with the proper permissions. What group is the amanda user in? From /etc/group: disk:x:6:root,rwk,amanda And what does 'ls -l /dev/sda2' say? brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 Also, amcheck *does* run successfully. Please advise and thank you for your help! Dick However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
[EMAIL PROTECTED] wrote: I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:[EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
# su -c amanda id uid=33(amanda) gid=6(disk) groups=6(disk) # ls -l /dev/sda2 brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 # ls -ln /dev/sda2 brw-rw1 06 8, 2 Aug 24 2000 /dev/sda2 # grep disk /etc/group disk:x:6:root,rwk,amanda # grep amanda /etc/passwd amanda:x:33:6:Amanda user:/var/lib/amanda:/bin/bash Also, I can run dump manually (on the client) as the amanda user and it runs with no problem: # sys su amanda -c '/sbin/dump 0Ssf 1048576 - /dev/sda2' 9334784 What do you make of it? The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. [EMAIL PROTECTED] wrote: I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:[EMAIL PROTECTED]
Input/Output error
I'm getting the following error: ***A TAPE ERROR OCCURRED: [[writing filemark: Input/output error]]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is: DailySet101. FAILURE AND STRANGE DUMP SUMMARY: localhost/etclev 0 FAILED [out of tape] (snip) NOTES: planner: Last full dump of localhost:/etc on tape overwritten in 1 run. taper: tape DailySet100 kb 0 fm 0 writing filemark: Input/output error driver: going into degraded mode because of tape error. This happens with all my tapes. It's a brand new Seagate STT8000N (IDE) tape drive, and I'm able to use it fine with mt and tar. I'm running Amanda version 2.4.2p2, on a Redhat 7.1 system (kernel upgraded to 2.4.16). I was able to successfully amlabel my tapes, and amcheck appears to be happy. But amdump and amflush both generate the preceding error. I tried mt rewind beforehand, just to be sure I was at the beginning of the tape, but that didn't help. When I start amdump, I get some disk activity when the holding disk is written to, and then the tape runs for a while, and then it just hangs for a hour or so, until something times out and fails. I'd appreciate any suggestions. Steve Stanners
Re: Remote amrestore
amindexd: debug 1 pid 28366 ruid 33 euid 33 start time Thu Jan 24 16:29:08 2002 amindexd: version 2.4.2p2 gethostbyaddr: Success amindexd: pid 28366 finish time Thu Jan 24 16:29:08 2002 That gethostbyaddr: Success line is a problem. I'm pretty sure what it's trying to say (and I'll get the message fixed so it's clearer) is that it cannot do a host name lookup on the IP address of the client coming in (e.g. the machine you're running amrecover on). So I'd start checking that kind of thing on your server (tserv.meridian-ds.com). I use the following two little programs, if it helps: ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyaddr.c ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyname.c They are better than groping around through /etc/hosts or using nslookup because they issue the same actual system library call Amanda does, so they go through whatever lookup mechanisms your system is set up to use (files, NIS, DNS, whatever). couldn't find amindexd... at least not in refernce to /etc/xinetd.d so... assuming you meant one of the files in /etc/xinetd.d ... Yeah, that's what I meant. Sorry for the confusion between service name and server/program name. in all cases, there server args thingie (very technical term) doesn't seem to be there. Agreed. And server args thingie is as technical as I could get :-). The only Linux machine I have access to doesn't have any man pages :-( so I couldn't look it up. There is a parameter in those files that allows you to pass command line arguments to the service when it is started. Some documentation or RPM's incorrectly converted the inetd.conf line to the xinetd format and included this entry with the name of the program. But passing that as an arg to Amanda services really confuses them. In any case, you don't have that problem, so this is all academic. Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ... sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot Note that it's not sendsize whining about LABEL=, it's dump itself. My guess is your version of dump needs to be updated, and it wouldn't surprise me to hear that that also fixes the permission denied problem. Dick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
One other thing. Joshua asked what your amandad xinetd entry looked like. In particular, you need groups yes (or something like that) to make xinetd put amandad in all the alternate groups (why they didn't make this the default is beyond me). Without that, amandad will only be run in its primary group, which is not disk and thus has no access. When you use su, you get all the alternate groups, so that's why it works from there. I have a TODO list item to log the alternate groups in the debug file, which would help diagnose this problem, but it's harder than you might think (it used to be a non-standard system call, so portability is a problem). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: problems with backup to one specific box
-BEGIN PGP SIGNED MESSAGE-
John == John R Jackson [EMAIL PROTECTED] writes:
I setup a new config for just that system. I ran it with tcpdump watching.
I never saw an attempt to connect to backup.
...
*** A TAPE ERROR OCCURRED: [label DailySet120 doesn't match labelstr ^LOX[0-9
][0-9]*$].
...
loxwd0a lev 0 FAILED [can't switch to incremental dump]
...
planner: Adding new disk lox:wd0a.
John When Amanda sees a client/disk it has never done before, it has to do
John a level 0 (full) dump to get things started. However, a tape error,
John such as the label string mismatch, tells Amanda it should drop into
Okay, fair enough.
John degraded mode in which it will only do incrementals of anything that
John has not yet been processed. But it cannot do that in your case since
John the disk is new, so it gave up.
John Short answer -- fix the tape problem so Amanda has a tape to write to.
John Longer answer -- you can change the reserve parameter to a value less
John than the default of 100% to allow Amanda to go ahead and do level 0
John dumps into the holding disk (assuming they will fit) even when a tape
John error happens.
That will help me diagnose the problem on the limited config. (with just
the one host).
It doesn't address the fundamental problem.
Why is there a write file problem, I'm not sure. I think my tape size
estimate is slightly off, so i fall off the end of the tape. However, many
things did go to disk. I will toggle reserve to see if that helps.
(My hold disk is 15Gb in size. My tapes are HP DAT DDS-II drive, so there
is no problem running)
[note, slightly edited to remove host names that I do now want public]
These dumps were to tape DailySet120.
*** A TAPE ERROR OCCURRED: [[writing file: Input/output error]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: DailySet109.
FAILURE AND STRANGE DUMP SUMMARY:
marajade wd0h lev 0 FAILED [disk wd0h offline on marajade?]
loxwd1g lev 0 FAILED [Request to lox timed out.]
loxwd1f lev 0 FAILED [Request to lox timed out.]
loxwd1e lev 0 FAILED [Request to lox timed out.]
loxwd0g lev 0 FAILED [Request to lox timed out.]
loxwd0f lev 0 FAILED [Request to lox timed out.]
loxwd0e lev 0 FAILED [Request to lox timed out.]
loxwd0a lev 0 FAILED [Request to lox timed out.]
cassidyhdc3 lev 5 FAILED [out of tape]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)1:10
Run Time (hrs:min) 6:55
Dump Time (hrs:min)7:43 6:36 1:07
Output Size (meg)2355.4 988.7 1366.8
Original Size (meg) 4504.7 2681.6 1823.2
Avg Compressed Size (%)52.3 36.9 75.0 (level:#disks ...)
Filesystems Dumped 19 4 15 (1:9 2:1 3:4 5:1)
Avg Dump Rate (k/s)86.7 42.6 346.8
Tape Time (hrs:min)0:43 0:24 0:19
Tape Size (meg) 1035.6 539.3 496.2
Tape Used (%) 26.9 14.0 12.9 (level:#disks ...)
Filesystems Taped17 3 14 (1:9 2:1 3:4)
Avg Tp Write Rate (k/s) 407.8 379.3 444.0
NOTES:
planner: Adding new disk marajade:wd0h.
planner: Incremental of istari:sd0e bumped to level 3.
planner: Dump larger than tape: full dump of cassidy:hdc3 delayed.
planner: Full dump of istari:sd0e promoted from 21 days ahead.
planner: Full dump of marajade:wd0a promoted from 21 days ahead.
planner: Full dump of istari:sd3g promoted from 21 days ahead.
planner: Full dump of istari:sd2e promoted from 21 days ahead.
taper: tape DailySet120 kb 1664544 fm 18 writing file: Input/output error
driver: going into degraded mode because of tape error.
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
- -- -
cassidy hda11 32010 2848 8.9 1:33 30.7 0:12 232.3
cassidy hda33 238140 170720 71.7 8:02 353.9 6:15 455.7
cassidy hdc11 330 32 9.7 1:26 0.4 0:001194.8
cassidy hdc23 226490 78464 34.6 5:41 229.8 2:59 438.8
cassidy hdc35 1062490 891904 83.9 28:34 520.4 N/A N/A
cassidy hdc43 186390 183424 98.4 5:34 548.6 6:50 447.8
istari sd0a1 399 96 24.1 0:26 3.7 0:00 759.8
istari sd0e0 188251 28192 15.0 46:51 10.0 1:16 373.4
istari sd0f1 121 32 26.4 0:46 0.7 0:00 454.2
istari sd1a2 42061 15136 36.0 3:30 72.2 0:43 349.0
Re: GNUtar instead of dump, no time estimate
On Thu, 24 Jan 2002 14:15:56 -0500 John R. Jackson [EMAIL PROTECTED] wrote: There is no time estimation done: ... Estimate Time (hrs:min)0:00 What version of Amanda? In the corresponding log.MMDD.NN file, what does the STATS driver startup time line say? Hi John, The version is amanda-2.4.2p2 The line for all logs (not so many, so far) is ---cut-on--- /var/log/amanda/DailySet1/log.20020111.0:STATS driver startup time 2.476 /var/log/amanda/DailySet1/log.20020111.1:STATS driver startup time 2.350 /var/log/amanda/DailySet1/log.20020111.2:STATS driver startup time 2.432 /var/log/amanda/DailySet1/log.20020111.3:STATS driver startup time 2.320 /var/log/amanda/DailySet1/log.20020111.4:STATS driver startup time 2.325 /var/log/amanda/DailySet1/log.20020111.5:STATS driver startup time 3.970 /var/log/amanda/DailySet1/log.20020111.6:STATS driver startup time 3.916 /var/log/amanda/DailySet1/log.20020115.0:STATS driver startup time 17.492 /var/log/amanda/DailySet1/log.20020116.0:STATS driver startup time 14.452 /var/log/amanda/DailySet1/log.20020117.0:STATS driver startup time 15.813 /var/log/amanda/DailySet1/log.20020118.0:STATS driver startup time 15.456 /var/log/amanda/DailySet1/log.20020119.0:STATS driver startup time 14.777 /var/log/amanda/DailySet1/log.20020122.0:STATS driver startup time 13.311 /var/log/amanda/DailySet1/log.20020123.0:STATS driver startup time 16.649 /var/log/amanda/DailySet1/log.20020124.0:STATS driver startup time 17.156 /var/log/amanda/DailySet1/log.20020125.0:STATS driver startup time 20.569 I hope that helps (which I can't see, yet :) Sincerly, Sascha
