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]
SAMBA: selfcheck request timed out. Host down?
Hi
I am trying to get amanda backup from windows machines up and running,
currently without any success:
I have tried three hosts two windows machines and one unix box and both
windows boxes fail.
The log of amcheck -c looks like this:
Amanda Backup Client Hosts Check
WARNING: snap1: selfcheck request timed out. Host down?
WARNING: wins4: selfcheck request timed out. Host down?
Client check: 3 hosts checked in 29.156 seconds, 2 problems found
The disklist:
snap1 //snap1/iss/ samba
wins4 //wins4/software/ samba
sun10 /var/www/ comp-user-tar
amandapass:
//snap1/iss/user%password TUD_FB20_ISS
//wins4/software/ user%password TUD_FB20_ISS
the dumptype samba of amanda.conf
define dumptype samba {
program GNUTAR
comment partitions dumped with tar
options compress-fast
priority low
}
The system itself is a 2.4.2x linux box with debian woody and a
backported amanda from debian sid:
ii amanda-server 2.4.4p2-1 Advanced Maryland Automatic Network Disk Archiver
(Server)
The most unusual ist the backported smbclient:
ii smbclient3.0.2a-0.backports.org.2 a
LanManager-like simple client for Unix
But since there is an entry in the changelog about fixing a bug with
samba 3.0 i suppose it should work. The unix backup is working. There's
no firewall, and amanda is listed in the inetd.conf:
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
amandaidx stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amindexd
amidxtape stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amidxtaped
host.deny is empty and host.allow has:
amanda: snap1.vlsi.informatik.tu-darmstadt.de
It seems to me that amcheck tries to initiate a amanda connection via
udp. Which doesn't work with windows machines? I would apreciate any
hints.
Thanks
Tim
RedHat list
Sorry, for this non-amanda question: Does anybody know if there is a good RedHat 9 users mail-list Bill
Re: SAMBA: selfcheck request timed out. Host down?
On Thu, 11 Mar 2004 at 1:40pm, Tim Krieglstein wrote The log of amcheck -c looks like this: Amanda Backup Client Hosts Check WARNING: snap1: selfcheck request timed out. Host down? WARNING: wins4: selfcheck request timed out. Host down? Client check: 3 hosts checked in 29.156 seconds, 2 problems found The disklist: snap1 //snap1/iss/ samba wins4 //wins4/software/ samba sun10 /var/www/ comp-user-tar *snip* It seems to me that amcheck tries to initiate a amanda connection via udp. Which doesn't work with windows machines? I would apreciate any hints. The client in your disklist (the first column) for 'doze boxes backed up via samba needs to be a *nix box with smbclient installed. When amanda contacts the *nix box, that box will then initiate the smbclient connection to the 'doze box. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: RedHat list
On Thu, 11 Mar 2004 at 8:04am, Bill Clery wrote Sorry, for this non-amanda question: Does anybody know if there is a good RedHat 9 users mail-list https://www.redhat.com/mailman/listinfo/redhat-list/ -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Disaster Recovery
What are the files needed for a Disaster Recovery on the backup server?? Thanks in Advance... Todd E. Zenker CNE-GSFC NASA Goddard Space Flight Center Raytheon Mailstop 200.1 http://cne.gsfc.nasa.gov https://webdrive.gsfc.nasa.gov
Re: Disaster Recovery
On Thu, 11 Mar 2004 at 10:43am, todd zenker wrote What are the files needed for a Disaster Recovery on the backup server?? I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the infofile dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs And I think that's it. It also wouldn't hurt to grab client related files if your amanda server is also a client. Those include /etc/amanda*, and the gnutar-lists directory. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Disaster Recovery--- Thanks
Thanks Joshua. I figured that is what is needed in order to recover my backup server. I'm familiar with Tivoli Disaster Recovery. Thanks again. At 11:01 AM 3/11/2004, Joshua Baker-LePain wrote: On Thu, 11 Mar 2004 at 10:43am, todd zenker wrote What are the files needed for a Disaster Recovery on the backup server?? I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the infofile dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs And I think that's it. It also wouldn't hurt to grab client related files if your amanda server is also a client. Those include /etc/amanda*, and the gnutar-lists directory. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University Todd E. Zenker CNE-GSFC NASA Goddard Space Flight Center Raytheon Mailstop 200.1 http://cne.gsfc.nasa.gov https://webdrive.gsfc.nasa.gov
Re: SAMBA: selfcheck request timed out. Host down?
Hi Joshua The client in your disklist (the first column) for 'doze boxes backed up via samba needs to be a *nix box with smbclient installed. When amanda contacts the *nix box, that box will then initiate the smbclient connection to the 'doze box. Thanks for the hint. It did the trick. Thats why is was staring at the man page and couldn't understand the wording. 8) Tim
retrieving 1 year old file
Hi list, I'm starting to play win amanda (2.4.4p2) on rh9 and using external hard disk as virtual tapes. I was wondering how do I setup amanda to be able to retrieve a 1 year old file? in other words, I want to have 1 year bkp with level 0 weekly. If someone has any other idea .. pls share.:-) here's my relevant configuration on amanda.conf: dumpcycle 7 daysrunspercycle 5 tapecycle 6 tapes runtapes 1 tpchanger chg-disk tapedev file:/amandavtapes (this is a entire disk) my virtual tapes are: (amtape daily show) slot 2: date 20040311 label daily2 slot 3: date 20040311 label daily3 slot 4: date 20040311 label daily4 slot 5: date 20040311 label daily5 slot 6: date 20040310 label daily6 slot 1: date 20040311 label daily1 thx, Sergio
Could not get changer info
When I run amcheck Diaria I get this message: amcheck-server: could not get the changer info: badly formed result from charge: "YPBINDPROC_DOMAIN: Domain not bound" And I can´t label de tapes with amlabel Diaria Diaria01 slot 1 ... The tape changer I use is "/usr/local/libexec/chg-disk" Antivirus Filtros antispam 6 MB gratis ¿Todavía no tienes un correo inteligente?
Re: retrieving 1 year old file
--On Thursday, March 11, 2004 11:46:16 -0500 Sergio Pereira [EMAIL PROTECTED] wrote: Hi list, I'm starting to play win amanda (2.4.4p2) on rh9 and using external hard disk as virtual tapes. I was wondering how do I setup amanda to be able to retrieve a 1 year old file? in other words, I want to have 1 year bkp with level 0 weekly. If someone has any other idea .. pls share.:-) here's my relevant configuration on amanda.conf: dumpcycle 7 daysrunspercycle 5 tapecycle 6 tapes runtapes 1 tpchanger chg-disk tapedev file:/amandavtapes (this is a entire disk) I'm assuming you mean to retrieve a file deleted a year ago, and not a file deleted yesterday that's been there for a year. Your current setup will only let you go back one week. To go back a year with this setup you would need at least 260 'tapes' Tapes = (365/dumpcycle)*runspercycle*runtapes It would probably be more practical to set up a second, 'archive' config to run at some interval (monthly, biweekly, weekly; whatever period your normal config tapecycle covers) that only does full backups with a tapecycle that could cover a year. Frank my virtual tapes are: (amtape daily show) slot 2: date 20040311 label daily2 slot 3: date 20040311 label daily3 slot 4: date 20040311 label daily4 slot 5: date 20040311 label daily5 slot 6: date 20040310 label daily6 slot 1: date 20040311 label daily1 thx, Sergio -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Disaster Recovery
Joshua Baker-LePain wrote: I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the infofile dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs How I deal with it is that I just rsync the amanda account home directory to another server periodically. If you wanted to, you could probably set it up as a daily cron job or something. --jonathan
Re: retrieving 1 year old file
On Thu, 2004-03-11 at 12:11, Frank Smith wrote: --On Thursday, March 11, 2004 11:46:16 -0500 Sergio Pereira [EMAIL PROTECTED] wrote: Hi list, I'm starting to play win amanda (2.4.4p2) on rh9 and using external hard disk as virtual tapes. I was wondering how do I setup amanda to be able to retrieve a 1 year old file? in other words, I want to have 1 year bkp with level 0 weekly. If someone has any other idea .. pls share.:-) here's my relevant configuration on amanda.conf: dumpcycle 7 daysrunspercycle 5 tapecycle 6 tapes runtapes 1 tpchanger chg-disk tapedev file:/amandavtapes (this is a entire disk) I'm assuming you mean to retrieve a file deleted a year ago, and not a file deleted yesterday that's been there for a year. Your current setup will only let you go back one week. To go back a year with this setup you would need at least 260 'tapes' Tapes = (365/dumpcycle)*runspercycle*runtapes hmmm .. not goot at all. To maintain all the 260 'tapes' and all the space required will be hard. It would probably be more practical to set up a second, 'archive' config to run at some interval (monthly, biweekly, weekly; whatever period your normal config tapecycle covers) that only does full backups with a tapecycle that could cover a year. you mean setup another configuration the way it can do a monthly backup. that way I will have 1 config for 'daily' and another for 'mothtly', did I get it right? In this case, how will work when recovering a file/folder? just to clarify, I'm just trying to find the best way to have 1 yr of backup. Frank my virtual tapes are: (amtape daily show) slot 2: date 20040311 label daily2 slot 3: date 20040311 label daily3 slot 4: date 20040311 label daily4 slot 5: date 20040311 label daily5 slot 6: date 20040310 label daily6 slot 1: date 20040311 label daily1 thx, Sergio --
*Slow* amrestore
I'm reading some somewhat large (14-18GB) images off of AIT3 tapes, and it's taking *forever*. Some crude calculations show it coming off the tape at around 80 KB/s, whereas it was written out at 11701.6 KB/s. The tapes were written in variable block size mode. What's the best way to read these images more quickly? Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: *Slow* amrestore
Joshua Baker-LePain wrote: I'm reading some somewhat large (14-18GB) images off of AIT3 tapes, and it's taking *forever*. Some crude calculations show it coming off the tape at around 80 KB/s, whereas it was written out at 11701.6 KB/s. The tapes were written in variable block size mode. What's the best way to read these images more quickly? Are you piping the amrestore output, say to uncompress and extract files? Maybe the extraction process is too slow, and causes the tape to have to stop and reposition while the pipe is emptying out. I wonder if you could put a bigger buffer in the pipe somehow, that might help, say 64 MB to begin--I remember seeing a cat-like program that could buffer a pipe, I think it was with Linux software for doing backups to CD-R. I would try amrestore -c to just dump the image off the tape, and then do the uncompress and extraction separately, but you will need enough disk space to do it. Worst case, you could try amrestore -r and use dd bs=32k skip=1 if=dump-file to skip over the header, and then pipe that to the uncompress and extract processes. --jonathan
Re: *Slow* amrestore
On Thu, 11 Mar 2004 at 2:21pm, Jonathan Dill wrote I would try amrestore -c to just dump the image off the tape, and then do the uncompress and extraction separately, but you will need enough disk space to do it. Worst case, you could try amrestore -r and use dd bs=32k skip=1 if=dump-file to skip over the header, and then pipe that to the uncompress and extract processes. The current slow-running process is 'amrestore -r'. I'm guessing it's forcing the block size that's the culprit here -- the amrestore man page isn't quite clear, but it seems to say that if you don't specify -b, it'll default to 32k. I tried just 'dd if=/dev/nst1 of=img.raw' but it said dd: reading `/dev/nst1': Cannot allocate memory. tapeinfo says this about blocksizes for the drive: MinBlock:2 MaxBlock:16777215 Maybe I should try dd with bs=16M? But will that pad the output file with an unacceptable-to-tar chunk at the end since the tapefile is unlikely to be an exact multiple of 16M? Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: *Slow* amrestore
--On Thursday, March 11, 2004 2:30 PM -0500 Joshua Baker-LePain [EMAIL PROTECTED] wrote: [snip] Maybe I should try dd with bs=16M? But will that pad the output file with an unacceptable-to-tar chunk at the end since the tapefile is unlikely to be an exact multiple of 16M? In my experience, dd should read in chunks of 16M but the last block (incomplete) will not be filled in (padded) to complete the block. Even if it was, here is what my gnu tar thinks of a tar with garbage at the end: --- [EMAIL PROTECTED](p1)(0):~/tartest% tar czvf foo.tar.gz foo foo/ foo/bar/ foo/bar/baz/ [EMAIL PROTECTED](p1)(0):~/tartest% ls -l foo.tar.gz -rw-r--r--1 areidstaff 152 Mar 11 14:42 foo.tar.gz [EMAIL PROTECTED](p1)(1):~/tartest% dd if=/dev/zero of=blank bs=1k count=10 10+0 records in 10+0 records out [EMAIL PROTECTED](p1)(0):~/tartest% ls -l total 16 -rw-r--r--1 areidstaff 10240 Mar 11 14:43 blank drwxr-xr-x3 areidstaff 102 Mar 11 14:42 foo/ -rw-r--r--1 areidstaff 152 Mar 11 14:42 foo.tar.gz [EMAIL PROTECTED](p1)(0):~/tartest% cat foo.tar.gz blank test.tar.gz [EMAIL PROTECTED](p1)(0):~/tartest% tar tzf test.tar.gz gzip: stdin: decompression OK, trailing garbage ignored foo/ foo/bar/ foo/bar/baz/ tar: Child returned status 2 tar: Error exit delayed from previous errors [EMAIL PROTECTED](p1)(2):~/tartest% --- Yes, it does return '2' but the data has been extracted already. Actually, come to think of it, gzip is ignoring the garbage.. - [EMAIL PROTECTED](p1)(0):~/tartest% gunzip foo.tar.gz [EMAIL PROTECTED](p1)(0):~/tartest% cat foo.tar blank test.tar [EMAIL PROTECTED](p1)(0):~/tartest% tar tvf test.tar drwxr-xr-x areid/staff 0 2004-03-11 14:42:08 foo/ drwxr-xr-x areid/staff 0 2004-03-11 14:42:08 foo/bar/ drwxr-xr-x areid/staff 0 2004-03-11 14:42:08 foo/bar/baz/ [EMAIL PROTECTED](p1)(0):~/tartest% - Tar doesn't even complain on my system here: tar (GNU tar) 1.13.25 Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University Just my 2cents.. antoine -- Antoine Reid Administrateur Système - System Administrator __ Logient Inc. Solutions de logiciels Internet - Internet Software Solutions 417 St-Pierre, Suite #700 Montréal (Qc) Canada H2Y 2M4 T. 514-282-4118 ext.32 F. 514-288-0033 www.logient.com *AVIS DE CONFIDENTIALITÉ* L'information apparaissant dans ce message est légalement privilégiée et confidentielle. Elle est destinée à l'usage exclusif de son destinataire tel qu'identifié ci-dessus. Si ce document vous est parvenu par erreur, soyez par la présente avisé que sa lecture, sa reproduction ou sa distribution sont strictement interdites. Vous êtes en conséquence prié de nous aviser immédiatement par téléphone au (514) 282-4118 ou par courriel. Veuillez de plus détruire le message. Merci. *CONFIDENTIALITY NOTE* This message along with any enclosed documents are confidential and are legally privileged. They are intended only for the person(s) or organization(s) named above and any other use or disclosure is strictly forbidden. If this message is received by anyone else, please notify us at once by telephone (514) 282-4118 or e-mail and destroy this message. Thank you.
Re: *Slow* amrestore
Hmm. Check also mt status to make sure the drive thinks that the blocksize is 0 if not change it with mt blksize. The files will be perfectly fine with bs=16M. gzip and/or tar will probably give a warning bitching about the nulls at the end, but it won't have any effect on the restore, the files will still be intact. In some desparate cases in the past, where some mung brain had data on Sony Video 8 tapes (!) I ended up mucking around with mt blksize and just using cat to try to grab the stuff off the tape without any blocking, crazy as that sounds, but that was also on SGI IRIX with Exabyte 820 Eagle drives. It was a pain, and there were loads of errors, but I got most of the data off the tapes. --jonathan Joshua Baker-LePain wrote: On Thu, 11 Mar 2004 at 2:21pm, Jonathan Dill wrote I would try amrestore -c to just dump the image off the tape, and then do the uncompress and extraction separately, but you will need enough disk space to do it. Worst case, you could try amrestore -r and use dd bs=32k skip=1 if=dump-file to skip over the header, and then pipe that to the uncompress and extract processes. The current slow-running process is 'amrestore -r'. I'm guessing it's forcing the block size that's the culprit here -- the amrestore man page isn't quite clear, but it seems to say that if you don't specify -b, it'll default to 32k. I tried just 'dd if=/dev/nst1 of=img.raw' but it said dd: reading `/dev/nst1': Cannot allocate memory. tapeinfo says this about blocksizes for the drive: MinBlock:2 MaxBlock:16777215 Maybe I should try dd with bs=16M? But will that pad the output file with an unacceptable-to-tar chunk at the end since the tapefile is unlikely to be an exact multiple of 16M? Thanks.
Re: *Slow* amrestore
On Thu, 11 Mar 2004 at 8:34pm, Gerhard den Hollander wrote I am assuming the disk you are writing to, the machine the tape drive is attached to and the machine on which the amrestore is running are all the same ? Yep. If not, your network might be the bottleneck. I was originally doing this via amrecover, and thought that may be it. Thus I switched to amrestore writing to a local disk. If it is, check your syslog (usually /var/log/messages /var/log/allmessages) and look if there is anything weird. Is the disk you are writing to OK ? Nothing strange in the syslog at all, and the disk is plenty quick. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: *Slow* amrestore
On Thu, 11 Mar 2004 at 2:52pm, Jonathan Dill wrote Hmm. Check also mt status to make sure the drive thinks that the blocksize is 0 if not change it with mt blksize. The files will be perfectly fine with bs=16M. gzip and/or tar will probably give a warning bitching about the nulls at the end, but it won't have any effect on the restore, the files will still be intact. mt agress that the blocksize is variable: SCSI 2 tape drive: File number=4, block number=0, partition=0. Tape block size 0 bytes. Density code 0x32 (no translation). Soft error count since last status=0 General status bits on (8501): EOF WR_PROT ONLINE IM_REP_EN But dd doesn't seem to like my suggestions for blocksize: [EMAIL PROTECTED] data]$ sudo dd if=/dev/nst1 of=img.raw bs=16M dd: reading `/dev/nst1': Invalid argument OK, so 16M is technically bigger than the stated limits, so: [EMAIL PROTECTED] data]$ sudo dd if=/dev/nst1 of=img.raw bs=16777215 dd: reading `/dev/nst1': Value too large for defined data type [EMAIL PROTECTED] data]$ sudo dd if=/dev/nst1 of=img.raw bs=8M dd: reading `/dev/nst1': Value too large for defined data type But 4M works. ?? And to add insult to injury, that's going at about 70K/s. In some desparate cases in the past, where some mung brain had data on Sony Video 8 tapes (!) I ended up mucking around with mt blksize and just using cat to try to grab the stuff off the tape without any blocking, crazy as that sounds, but that was also on SGI IRIX with Exabyte 820 Eagle drives. It was a pain, and there were loads of errors, but I got most of the data off the tapes. That sounds... fun. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: retrieving 1 year old file
On Thu, Mar 11, 2004 at 01:54:19PM -0500, Sergio Pereira wrote: On Thu, 2004-03-11 at 12:11, Frank Smith wrote: --On Thursday, March 11, 2004 11:46:16 -0500 Sergio Pereira [EMAIL PROTECTED] wrote: Hi list, I'm starting to play win amanda (2.4.4p2) on rh9 and using external hard disk as virtual tapes. I was wondering how do I setup amanda to be able to retrieve a 1 year old file? in other words, I want to have 1 year bkp with level 0 weekly. If someone has any other idea .. pls share.:-) It would probably be more practical to set up a second, 'archive' config to run at some interval (monthly, biweekly, weekly; whatever period your normal config tapecycle covers) that only does full backups with a tapecycle that could cover a year. you mean setup another configuration the way it can do a monthly backup. that way I will have 1 config for 'daily' and another for 'mothtly', did I get it right? In this case, how will work when recovering a file/folder? just to clarify, I'm just trying to find the best way to have 1 yr of backup. Because it would be a different configuration, the config name, the config logs and directories, and the tapes and tape labels would be different. If you want to recover from the monthly config you use that name. Otherwise use the daily config name. Both would have level 0 dumps, the monthly would have only level 0 while the daily would have a mixture of level 0 and incrementals. The monthly archive config doesn't care when the last level 0 was done so there is no need to record that it did a level 0. Thus, set the record parameter to no. Otherwise the daily config might get confused as to when it did the last level 0. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: *Slow* amrestore
Have you taken a look around in /proc/scsi? /proc/scsi/scsi should give you some basic information, and the subdir for your driver should give more details, such as what transfer rate the drive is negotatiated at, for example /proc/scsi/aic7xxx/0 for an Adaptec 2940 series. Perhaps there was a bus problem and the device hooked up at 10 MHz async or something. Reboot and get into the SCSI bios config page and make sure everything in there is kosher. I have even seen a few terminators go bad, so such things are not impossible, even though the drive was writing fine before. Since dd is having just as much problems, I would suspect that amanda is not the problem per se. Could be kernel, could be hardware, could be the tape cartridge, could be some stupid, proprietary Sony thing, dip switch settings on the drive, hardware compression settings. In some cases, I have taken tape drives and hooked them up to a Windows box so I could run proprietary diagnostics, take a look at the tape drive's internal logs, update the drive firmware. I think the weirdest stuff was using a 9600 bps null modem serial terminal connection to connect to the embedded console on an Exabyte 10h library, very strange set up. I have also pulled out SCSI cards and put them on a Windows box to check out the SCSI BIOS and load new firmware. Run a cleaning tape through just in case--with some drives, I had the problem of drives actually needing cleaning more frequently than the drives thought they needed it. Exabyte Eliant drives were notorious for that--I would run into these problems where I had to run a cleaning tape through 5-6 times in a row (even though the drive said it didn't need cleaning) and then finally it was fine, but in those cases, I was also seeing read and/or write errors. The Eliants just based cleaning on hours of read/write time, which turned out not to be often enough, so crud would accumulate over time--no doubt because amanda was streaming so efficiently that the drive was actually processing more length of tape than ordinarily anticipated :-) --jonathan
Re: *Slow* amrestore
On Thu, Mar 11, 2004 at 03:29:23PM -0500, Joshua Baker-LePain wrote: But 4M works. ?? And to add insult to injury, that's going at about 70K/s. What about our old oft occuring observations on scsi devices, Writing through that cable uses different wires than reading. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: *Slow* amrestore
On Thu, 11 Mar 2004 at 4:08pm, Jon LaBadie wrote On Thu, Mar 11, 2004 at 03:29:23PM -0500, Joshua Baker-LePain wrote: But 4M works. ?? And to add insult to injury, that's going at about 70K/s. What about our old oft occuring observations on scsi devices, But isn't 1 goat/week enough? Writing through that cable uses different wires than reading. So, here's where it gets fun. The tape drive I've been using is one of two in my library. It happens to be the 2nd one -- both in terms of position on the chain and SCSI ID. On a lark, I moved the tape to /dev/nst0 (note: same chain). 'amrestore -r' chugged right along at what looked to be full speed for the tape drive. The drives are the same model (SDX-700C), although I only recently added the second (slow) one, so it has less usage and a newer firmware revision. I cleaned the slow drive once, and that made an improvement, but only to 900K/s or so. Although, if I watch xosview, the transfer appears very bursty, whereas on the fast drive it's pretty consistent. I'll run the cleaning cycle again, and maybe upgrade the firmware on it (there is a newer firmware revision available). As an aside, Sony actually provides a Linux tool to do this, which almost shocked me out my boots. If all that doesn't work, I may have to look at the cable between nst0 and nst1. Anyways, it looks to be hardware, and not amanda or kernel related. So, thanks all, and sorry for the noise. Is it Friday yet? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
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
