Re: chg-zd-mtx-2.4.3b4 problem
At 1:09 PM -0600 10/29/02, Paul T. Root wrote: Hi, I have a problem with the zd-mtx script. I traced it down to the point in the script where it decides it needs to run the cleaning tape. Line 968 or so: I do not have a useful answer. Instead, another question. This cleaning stuff is new to my radar screen... Is the "chg-zd-mtx" changer module that exists between AMANDA and the MTX program supposed to determine when a cleaning occurs? (or any changer module for that matter?)
Re: disk offline
On Tue, 29 Oct 2002 at 3:20pm, Chad Morland wrote > Error from sendsize*debug: > runtar: error [must be invoked by operator] > > However, amanda is in my operator group. > torbackup# id amanda > uid=1000(amanda) gid=1000(amanda) groups=1000(amanda), 5(operator) Are you using inetd or xinetd? If it's xinetd, you need "groups = yes" in your amanda service file to pick up secondary groups. When you configured and compiled amanda, what USER and GROUP did you define? You did 'make install' as root, right? > And the from amandad*.debug: > > (Environment variables cut out) > Amanda 2.4 REQ HANDLE 000-00360708 SEQ 1035907903 > SECURITY USER amanda > SERVICE noop > OPTIONS features=feff9f00; > > > sending nack: > > Amanda 2.4 NAK HANDLE 000-00360708 SEQ 1035907903 > ERROR unknown service: noop This is a result of running 2.4.3 on the server but not on this client (I think). It's not a problem in itself. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: disk offline
Error from sendsize*debug: runtar: error [must be invoked by operator] However, amanda is in my operator group. torbackup# id amanda uid=1000(amanda) gid=1000(amanda) groups=1000(amanda), 5(operator) And the from amandad*.debug: (Environment variables cut out) Amanda 2.4 REQ HANDLE 000-00360708 SEQ 1035907903 SECURITY USER amanda SERVICE noop OPTIONS features=feff9f00; sending nack: Amanda 2.4 NAK HANDLE 000-00360708 SEQ 1035907903 ERROR unknown service: noop -CM - Original Message - From: "Joshua Baker-LePain" <[EMAIL PROTECTED]> To: "Chad Morland" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 3:08 PM Subject: Re: disk offline > On Tue, 29 Oct 2002 at 2:39pm, Chad Morland wrote > > > backup. /backup lev 0 FAILED [disk /backup offline on > > backup.domain.com?] (I have also tried using the device > > [/dev/vinum/striped]) > > > *snip* > > > > My backup partition is a 430G striped vinum partition on FreeBSD. I have > > followed everything that is in the FAQ on this subject but nothing seems > > to be solving it. Anyone have any ideas on how to solve this? > > What's in /tmp/amandad*debug and /tmp/sendsize*debug on backup? Can you > access the device *as the amanda user*? > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > >
Re: disk offline
On Tue, 29 Oct 2002 at 2:39pm, Chad Morland wrote > backup. /backup lev 0 FAILED [disk /backup offline on > backup.domain.com?] (I have also tried using the device > [/dev/vinum/striped]) > *snip* > > My backup partition is a 430G striped vinum partition on FreeBSD. I have > followed everything that is in the FAQ on this subject but nothing seems > to be solving it. Anyone have any ideas on how to solve this? What's in /tmp/amandad*debug and /tmp/sendsize*debug on backup? Can you access the device *as the amanda user*? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
disk offline
I am having some problems getting amanda to run. I have used amanda before and this is the first time that I have encountered this problem. I followed the instuctions from the backup and recovery chapter and amcheck is not reporting any problems. However, when I run amdump I get the following sent to me in the report about 30 seconds after running the command: backup. /backup lev 0 FAILED [disk /backup offline on backup.domain.com?] (I have also tried using the device [/dev/vinum/striped]) and further down: NOTES: planner: Adding new disk torbackup.inquent.com:/backup. driver: WARNING: got empty schedule from planner taper: tape DailySet11 kb 0 fm 0 [OK] My backup partition is a 430G striped vinum partition on FreeBSD. I have followed everything that is in the FAQ on this subject but nothing seems to be solving it. Anyone have any ideas on how to solve this? -CM
Amanda 2.4.3b4 chio changer problems
Since upgrading from 2.4.2p1 to 2.4.3b3 and 2.4.3b4 I get this problem. The changer does do the change, but I guess the script doesn't wait to check. So as long as I know that I'm not on the last tape, I ignore it. But I'd rather it work. You know, I'm wondering if maybe this wasn't an OS upgrade. I'm running FreeBSD 4.7-Stable. But this was happening in 4.6-Stable for a while too. Any ideas? Paul. Amanda Tape Server Host Check - Holding disk /amanda/hold: 4659412 KB disk space available, that's plenty amcheck-server: slot 1: date 20021029 label IACES22 (active tape) amcheck-server: fatal slot chio:: /dev/ch0: CHIOMOVE: Invalid argument ERROR: label IACES23 or new tape not found in rack (expecting tape IACES23 or a new tape) NOTE: skipping tape-writable test Server check took 72.793 seconds Amanda Backup Client Hosts Check Client check: 4 hosts checked in 1.587 seconds, 0 problems found (brought to you by Amanda 2.4.3b4)
chg-zd-mtx-2.4.3b4 problem
Hi, I have a problem with the zd-mtx script. I traced it down to the point in the script where it decides it needs to run the cleaning tape. Line 968 or so: if [ $autoclean -ne 0 -a $accesscount -gt $autocleancount ] then internal_call=`expr $internal_call + 1` loadslot clean > /dev/null 2>&1 status=$? internal_call=`expr $internal_call - 1` The changer was in slot 8 of 10. The cleaning tape is in slot 1. Any ideas? Thanks, Paul. Amanda Tape Server Host Check - Holding disk /amanda/hold: 12242301 KB disk space available, that's plenty amcheck-server: slot 8: date 20021029 label Aces46 (active tape) amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found amcheck-server: slot /usr/local/libexec/chg-zd-mtx-2.4.3b4:: loadslot: not found ERROR: label Aces47 or new tape not found in rack (expecting tape Aces47 or a new tape) NOTE: skipping tape-writable test Server check took 139.449 seconds Amanda Backup Client Hosts Check Client check: 11 hosts checked in 2.540 seconds, 0 problems found (brought to you by Amanda 2.4.3b4) -- Paul T. Root CCSA, CCSE, CCNA Qwest Communications PAG: +1 (877) 693-7155 600 Stinson Blvd, Flr 1S WRK: +1 (612) 664-3385 Minneapolis, MN 55413 FAX: +1 (612) 664-4778
Forcing write to tape (or cleaning up tapelist)?
I guess during the initial tape cycle, the tapes got run in the wrong order. Specifically, we have a tape, sb-prod07, that was in the wrong slot and now every subsequent cycle expects that tape to be the next in sequence. How can I straighten this out? The more I look into it, the more disorganised it appears. For example, here's my /etc/amanda/DailySet1/tapelist: 20021018 sb-prod18 reuse 20021016 sb-prod16 reuse 20021014 sb-prod14 reuse 20021013 sb-prod13 reuse 20021012 sb-prod12 reuse 20021011 sb-prod11 reuse 20021010 sb-prod10 reuse 20021009 sb-prod09 reuse 20021006 sb-prod06 reuse 20021005 sb-prod05 reuse 20021004 sb-prod04 reuse 20021003 sb-prod03 reuse 20021002 sb-prod02 reuse 20021001 sb-prod01 reuse 20020929 sb-prod27 reuse 20020928 sb-prod26 reuse 20020927 sb-prod25 reuse 20020926 sb-prod24 reuse 20020925 sb-prod23 reuse 20020924 sb-prod22 reuse 20020923 sb-prod21 reuse 20020922 sb-prod20 reuse 20020921 sb-prod19 reuse 20020920 sb-prod17 reuse 20020919 sb-prod28 reuse 20020918 sb-prod15 reuse 20020910 sb-prod08 reuse 20020909 sb-prod07 reuse I've got 28 tapes that I'd like to cycle through, but when they're out of order like this, it fails every night as it expects the wrong tape to be loaded. At any rate, I'd _really_ appreciate any tips on how to get this all cleaned up. Thanks in advance, -Charlie
Re: New file tape type for backup to disk.
On Tue, Oct 29, 2002 at 10:29:32AM -0500, Brian Kennedy wrote: > I've got the backups running smoothly, some scripts to change "tapes" > (move symlinks) but I cant get a recover to work. OK - a little background on my setup so that later becomes clear - I have a partition /backup on a server called backup. In /backup I have created my "tapes" and I backup to backup:/backup/tape where tape is a symlink to the appropriate "tape" (I've a notion that a more 'elegant' olsution to this whole kludge would be a hacked mtx of some sort, but I digress) > amrecover conf > .. select some files and extract.. > Restore files into.. > continue? Y > Load tape ... > continue? Y > and then: > amrecover: error reading tape: Connection reset by peer > extract_list - child returned non-zero status: 1 > > any clues as to what is wrong? I think amanda doesn't know where it should be looking - below an extract from our local operations manual: At this point using physical tapes, it's time to load the desired tape. But because we are using amanda's ability to use virtual tapes on disk, rather than loading a tape we must tell amanda where the "tape" is. The 't' option at this prompt allows us to do so Continue [?/Y/n/t]? t New tape device [?]: backup:file:/backup/TIZdaily04 Here we've told amanda where the "tape" is. The syntax is as in the example above backup:file:/backup/ followed by the tape name. Now here's the bit that ISN'T in our operations manual - you can't tell amanda to use a tape called file:/backup/store because then it tries to use a host called file. I'm presuming your store is a symlink analogous to my tape ? I start amrecover like this (my configuration is TIZ) amrecover TIZ -s backup -t backup and I don't even bother specifying a tape device. I have moaned about this already, and the problem is essentially the overloading of : . As it's an eminently workaroundable :-) problem, I don't suppose there's a huge incentive to fix it. Kindest regards, Niall O Broin
Re: a few backups in to one tape
On Tue, Oct 29, 2002 at 05:23:05PM +0300, Lishtovny Denis wrote: > Everyday amanda2.4 doing backup into one tape. (one day, one tape). > Is it possible to do two or more backups into one tape? (14*2=28 Gb) (two > days, one tape). > If it is possible, please tell me how. Short answer: No. Detailed answer: No. Between backups, amanda does not have control of the tape drive. If something else rewinds it, you would be overwriting your old backup with the new one, which would be Very Bad. Accurate answer: Amanda does not support this, but you could allocate a large holding disk and then 'forget' to switch tapes every night, causing the backups to stay on the holding disk. When the holding disk fills up to your satisfaction, switch tapes and manually run amflush. Personally, I find this to be too much of a hassle to do intentionally, but amflush is the only way to get amanda to put multiple runs on one tape.
Re: Performance degrading over time?
--On Tuesday, October 29, 2002 11:43:30 +0100 "Patrick M. Hausen" <[EMAIL PROTECTED]> wrote:
As you can see from April up until August the dumpsize increased
about 1.5 fold while the dump _time_ increased by a factor of
about 2.5. Dump rate dropped from 7.5 K/s to 4.6 K/s.
From August until now the dump size increased by about 10%
while dump time continues to grow dramatically.
I'll look into the "lots of small files added?" question.
Since your dumper and taper times are always nearly identical you probably
aren't using a holding disk and are dumping directly to tape. And since
the rates for one filesystem have remained constant while the other one has
dropped I would look into possible recent changes on the larger (slower)
filesystem. Try doing a dump to /dev/null and see how fast (or slow) that is.
If data isn't fed to the tape fast enough the tape drive has to stop and
reposition itself every time it runs out of data, which will slow it down
considerably.
Frank
Thanks,
Patrick
---
5. April 2002 15:29
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:54 1:53 0:00 (0:01 start, 0:00 idle)
Output Size (meg) 48155.548155.50.0
Original Size (meg) 48155.548155.50.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 24.1 24.10.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7284.9 7284.9--
Avg Tp Write Rate (k/s) 7282.8 7282.8--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1199200 1199200 -- 6:27 3100.76:28 3089.9
allianz01 c1t0d0s6 0 48112064 48112064 -- 106:22 7538.5 106:23 7537.7
1. Mai 2002 01:25
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:51 1:49 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 49187.349187.30.0
Original Size (meg) 49187.349187.30.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 24.6 24.60.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7700.0 7700.0--
Avg Tp Write Rate (k/s) 7698.5 7698.5--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1201184 1201184 -- 5:50 3427.75:52 3416.7
allianz01 c1t0d0s6 0 49166592 49166592 -- 103:11 7941.9 103:11 7941.6
1. Juni 2002 01:26
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:53 1:51 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 50107.250107.20.0
Original Size (meg) 50107.250107.20.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 25.1 25.10.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7674.4 7674.4--
Avg Tp Write Rate (k/s) 7672.9 7672.9--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1202656 1202656 -- 5:45 3487.65:46 3476.1
allianz01 c1t0d0s6 0 50107072 50107072 -- 105:41 7902.1 105:41 7901.9
1. Juli 2002 01:30
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:58 1:56 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 51813.251813.20.0
Original Size (meg) 51813.251813.20.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 25.9 25.90.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7640.7 7640.7--
Avg Tp Write Rate (k/s) 7639.2 7639.2--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1634400 1634400 -- 6:50 3985.36:51
New file tape type for backup to disk.
I'm trying this sucker out planning to make use of it for a couple satalite offices, but having some trouble. I've got the backups running smoothly, some scripts to change "tapes" (move symlinks) but I cant get a recover to work. amrecover conf .. select some files and extract.. Restore files into.. continue? Y Load tape ... continue? Y and then: amrecover: error reading tape: Connection reset by peer extract_list - child returned non-zero status: 1 from the amrecover.*.debug: amrecover: stream_client_privileged: connected to 10.12.0.2.10083 amrecover: stream_client_privileged: our side is 0.0.0.0.719 amrecover: try_socksize: receive buffer size is 65536 Started amidxtaped with arguments "6 -h -p file:/backup/store ^ns$ ^//haff/mydoc$ 20021029" amrecover: error reading tape: Connection reset by peer amrecover: pid 32699 finish time Tue Oct 29 10:11:25 2002 amrecover: pid 32690 finish time Tue Oct 29 10:12:21 2002 any clues as to what is wrong? Thanks... ...Brian
a few backups in to one tape
Hello All. My backup data is ~14 Gb I have 6 tapes in backup device per 40 Gb each. Everyday amanda2.4 doing backup into one tape. (one day, one tape). Is it possible to do two or more backups into one tape? (14*2=28 Gb) (two days, one tape). If it is possible, please tell me how. Thanks. Sorry for my bad english.
Re: tru64 5.1 & 2.4.2p2
Toby, I have a few Tru64 5.1 alphas and I got the same error when using amanda 2.4.2p2. I fixed it by commenting out the ruserok line in common-src/amanda.h. #ifndef HAVE_RUSEROK_DECL //extern int ruserok P((const char *rhost, int suser, //const char *ruser, const char *luser)); #endif It then compiled fine without any problems and we have been backing up these machines since the've been upgraded to 5.1. Hope this helps, Jeremy [EMAIL PROTECTED] wrote: amanda 2.4.2p2 on tru64 5.1 - make stops on error: cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src-g -c alloc.c cc: Warning: amanda.h, line 946: In this declaration, parameter 1 has a different type than specified in an earlier declaration of this function. (mismatparam) extern int ruserok P((const char *rhost, int suser, ---^ cc: Error: amanda.h, line 946: In this declaration, the type of "ruserok" is not compatible with the type of a previous declaration of "ruserok" at line number 705 in file /usr/include/unistd.h. (notcompat) extern int ruserok P((const char *rhost, int suser, ---^ *** Exit 1 Stop. *** Exit 1 Stop. Found a message in the archives that points to ftp://gandalf.cc.purdue.edu/pub/amanda/configure.jfkoenig as a possible solution, but ftp on gandalf.cc.purdue.edu does not seem to be up. Would that file help me? Does anyone have a copy to send me? Thanks -- toby bluhm philips medical systems, mr development, cleveland, ohio [EMAIL PROTECTED] 440-483-5323 -- - Jeremy Heslop Unix System Administrator Horn Point Laboratory University of Maryland Center for Environmental Science Office - 410-221-8241 Fax - 410-221-8490 [EMAIL PROTECTED]
Re: compression
On Tue, Oct 29, 2002 at 09:41:57PM +1100, Craig Dewick wrote: > Hey there Joseph! > > It's good to see a familiar name here on the list... > > > I would like to know where and what do I insert into the amanda.conf for > > allow tape compression to work. > > > > the tape unit is a hp1537A in a six stacker based unit. > > Can it be done with jumers on the drive, or by DIP switches in the > autochanger's electronics? You're probably better off to set it via > hardware, though if that's not possible there should be a way to configure > the SCSI side of the Amanda software which communicates directly with the > tape drive to enable compression. HP-1537A? I think that is the same changer I have. It has 2 DIP switches that control two things: - what state compression begins in when power is first applied - whether this state is changeable by software control IIRC, those particular switches are internal (requiring case removal). hp.doc, support, doc/manuals is a good site for online documentation. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Performance degrading over time?
Hi all!
Jay Lessert wrote:
> So the first thing is to look at two AMANDA MAIL
> REPORT outputs: one from a "fast" run in June, and one from a "slow"
> run yesterday.
>
> Look at Estimate Time, Dump Time, Tape Time, Dump Rate, and Taper Rate
> for your one file system. Where is the increase happening?
>
> My personal bet is estimate time, and that your 6GB of growth is in the
> form of a large number of small files, but that is a wild guess.
The dump time is increasing way beyond the growth rate of data
to be dumped.
> If you give us actual data, we can do much better. :-)
See below.
As you can see from April up until August the dumpsize increased
about 1.5 fold while the dump _time_ increased by a factor of
about 2.5. Dump rate dropped from 7.5 K/s to 4.6 K/s.
>From August until now the dump size increased by about 10%
while dump time continues to grow dramatically.
I'll look into the "lots of small files added?" question.
Thanks,
Patrick
---
5. April 2002 15:29
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:54 1:53 0:00 (0:01 start, 0:00 idle)
Output Size (meg) 48155.548155.50.0
Original Size (meg) 48155.548155.50.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 24.1 24.10.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7284.9 7284.9--
Avg Tp Write Rate (k/s) 7282.8 7282.8--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1199200 1199200 -- 6:27 3100.76:28 3089.9
allianz01 c1t0d0s6 0 48112064 48112064 -- 106:22 7538.5 106:23 7537.7
1. Mai 2002 01:25
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:51 1:49 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 49187.349187.30.0
Original Size (meg) 49187.349187.30.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 24.6 24.60.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7700.0 7700.0--
Avg Tp Write Rate (k/s) 7698.5 7698.5--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1201184 1201184 -- 5:50 3427.75:52 3416.7
allianz01 c1t0d0s6 0 49166592 49166592 -- 103:11 7941.9 103:11 7941.6
1. Juni 2002 01:26
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:53 1:51 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 50107.250107.20.0
Original Size (meg) 50107.250107.20.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 25.1 25.10.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7674.4 7674.4--
Avg Tp Write Rate (k/s) 7672.9 7672.9--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1202656 1202656 -- 5:45 3487.65:46 3476.1
allianz01 c1t0d0s6 0 50107072 50107072 -- 105:41 7902.1 105:41 7901.9
1. Juli 2002 01:30
STATISTICS:
Total Full Daily
Dump Time (hrs:min)1:58 1:56 0:00 (0:02 start, 0:00 idle)
Output Size (meg) 51813.251813.20.0
Original Size (meg) 51813.251813.20.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 25.9 25.90.0
Filesystems Dumped2 2 0
Avg Dump Rate (k/s) 7640.7 7640.7--
Avg Tp Write Rate (k/s) 7639.2 7639.2--
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
--
allianz01 c0t0d0s0 0 1634400 1634400 -- 6:50 3985.36:51 3974.2
allianz01 c1t0d0s6
Re: compression
Hey there Joseph! It's good to see a familiar name here on the list... > I would like to know where and what do I insert into the amanda.conf for > allow tape compression to work. > > the tape unit is a hp1537A in a six stacker based unit. Can it be done with jumers on the drive, or by DIP switches in the autochanger's electronics? You're probably better off to set it via hardware, though if that's not possible there should be a way to configure the SCSI side of the Amanda software which communicates directly with the tape drive to enable compression. Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
