Backup of soft-raid device?
Is it possible to backup a device /dev/md0/, which is a software raid level 0, at all? I get the following messages: FAILED AND STRANGE DUMP DETAILS: /-- merten1.me md0 lev 1 STRANGE sendbackup: start [merten1.merten.lab:md0 level 1] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: WARNING: There is no inferior level dump on this filesystem | DUMP: WARNING: Assuming a level 0 dump by default | DUMP: Date of this level 0 dump: Wed Dec 27 17:12:33 2000 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/md0 (/striped) to standard output | DUMP: Label: none | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 1822702 tape blocks. | DUMP: Volume 1 started at: Wed Dec 27 17:12:35 2000 | DUMP: dumping (Pass III) [directories] | DUMP: SIGSEGV: ABORTING! ? dumper: strange [missing size line from sendbackup] ? dumper: strange [missing end line from sendbackup] \ What does it indicate? It is a new device that I' ve wrote in the disklist. Anything special about that? Didn't find any docs howto backup soft-raid devices. Thanks Rainer -- Chemisches Labor Dr. Merten GmbH Röderstr. 8-10 79104 Freiburg Tel: 0761 29648-0
Problem with chg-scsi
Hi, I have some Problems with chg-scsi. My machine is a Sun Ultra1 with Solaris 2.6. The Library is an Oveland-LXB Loader. This time I got a different error message when running chg-scsi -reset: DeviceCapabilitiesPage == NULL Amanda runs already with root-permissons and I use the modified verion of sst.c. What does "ioctl on 4 failed, errno 5, ret -1" In the Attachment is the chg-scsi.debug-file. Any idea what's wrong? greetings Alex | Alexander Schubert | | phone: | |office: +49 / (0) 5251 / 603318 | |private:+49 / (0) 5259 / 932181 | | call: +49 / (0) 173 / 5273184| | e-mail: [EMAIL PROTECTED] | chg-scsi: debug 1 pid 14465 ruid 0 euid 0 start time Thu Dec 28 12:59:34 2000 ARG [0] : /usr/local/libexec/amanda/chg-scsi ARG [1] : -reset Number of configurations: 1 Tapes need eject: No Tapes need sleep: 60 seconds Cleancycles : 10 Changerdevice : /dev/rsst6 Labelfile : /etc/amanda/daily/labelfile Tapeconfig Nr: 0 Drivenumber : 0 Startslot : 0 Endslot : 9 Cleanslot : -1 Devicename: /dev/rmt/4hbn changerident : none SCSITapedev : none tapeident : none statfile : /etc/amanda/daily/tape0-status Slotfile : /etc/amanda/daily/tape0-slot Cleanfile : /etc/amanda/daily/tape0-clean Usagecount: /etc/amanda/daily/totaltime # START OpenDevice OpenDevice : /dev/rsst6 # START SCSI_Inquiry SCSI_Inquiry start length = 56: # START DecodeSCSI SCSI_ExecuteCommand : INQUIRY 12 00 00 00 38 00 # STOP DecodeSCSI 08 80 4A 02 33 00 00 30 4F 56 45 52 4C 41 4E 44..J.3..0OVERLAND 4C 58 42 20 20 20 20 20 20 20 20 20 20 20 20 20LXB. 30 34 30 39 32 32 2D 4D 61 72 2D 39 39 00 00 00040922.Mar.99... 00 00 00 00 0E 01 02 00 SCSI_Inquiry : end 0 # START PrintInquiry qualifier 0 type8 data_format 2 ansi_version2 ecma_version1 iso_version 1 type_modifier 0 removable 1 vendor_info OVERLAND prod_ident LXB prod_version0409 vendor_specific 22-Mar-99 using ident = generic, type = Generic driver tape/robot [generic] # START OpenDevice OpenDevice : /dev/rmt/4hbn # START SCSI_Inquiry SCSI_Inquiry start length = 56: # START DecodeSCSI SCSI_ExecuteCommand : INQUIRY 12 00 00 00 38 00 # STOP DecodeSCSI 01 80 02 02 33 00 00 38 51 55 41 4E 54 55 4D 203..8QUANTUM. 44 4C 54 37 30 30 30 20 20 20 20 20 20 20 20 20DLT7000. 32 30 34 42 71 4B 00 07 29 12 01 00 00 2D 00 00204BqK.. 00 00 00 02 41 30 30 32 SCSI_Inquiry : end 0 # START PrintInquiry qualifier 0 type1 data_format 2 ansi_version2 ecma_version0 iso_version 0 type_modifier 0 removable 1 vendor_info QUANTUM prod_ident DLT7000 prod_version204B vendor_specific qK using ident = DLT7000, type = DLT Tape [DLT7000] ## START get_drive_count get_drive_count : fd 4 # START GenericElementStatus # START SCSI_ModeSense SCSI_ModeSense start length = 255: # START DecodeSCSI SCSI_ExecuteCommand : MODE SENSE 1A 08 3F 00 FF 00 # STOP DecodeSCSI ioctl on 4 failed, errno 5, ret -1 # START RequestSense # START DecodeSCSI SCSI_ExecuteCommand : REQUEST SENSE 03 00 00 00 1D 00 # STOP DecodeSCSI ioctl on 4 failed, errno 5, ret -1 # START RequestSense # START DecodeSCSI SCSI_ExecuteCommand : REQUEST SENSE 03 00 00 00 1D 00 # STOP DecodeSCSI ioctl on 4 failed, errno 5, ret -1 # START RequestSense # START DecodeExtSense SCSI_ExecuteCommand:Extended Sense # START DecodeSense SCSI_ExecuteCommand:Sense Keys ErrorCode 00 Valid 0 ASC 00 ASCQ 00 Sense key 00 No Sense Log Parameter Page Code 00 Log Parameter Code 00 Underrun/Overrun Counter00 Read/Write Error Counter0 Remaing 1024 byte tape blocks 0 Tracking Retry Counter 00 Read/Write Retry Counter00 Fault Sympton Code 00 # START DecodeExtSense SCSI_ExecuteCommand:Extended Sense # START DecodeSense SCSI_ExecuteCommand:Sense Keys ErrorCode 70 Valid 0 ASC 00 ASCQ 00 Sense key 00 No Sense Log Parameter Page Code 00 Log Parameter Code 00 Underrun/Overrun Counter00 Read/Write Error Counter0 Remaing 1024 byte tape blocks 0 Tracking Retry Counter 00
How can I tell what's happening?
How can I tell whether anything good is happening with my amanda backup? I'm new to amanda and trying to get it working on a system that I suspect has never been backed up. (I see messages in amdump like "isgadmin:/dev/hda1 overdue 11318 days for level 0.") My tapelist shows: su-2.03# cat tapelist 20001226 daily02 reuse 20001221 daily09 reuse 2817 daily01 reuse 0 daily10 reuse 0 daily08 reuse 0 daily07 reuse 0 daily06 reuse 0 daily05 reuse 0 daily04 reuse 0 daily03 reuse Which to me indicates that I successfully made a backup on Aug. 17, Dec. 21 and 26. (We've been faithfully changing tapes daily for the last five months. Oh, well ...) No other tapes seem to be used. "amstatus daily" shows: Using /var/log/amanda/daily/amdump from Tue Dec 26 16:01:00 EST 2000 centernet:/dev/sda1 0 no estimate centernet:/dev/sda3 0 no estimate centernet:/dev/sdb1 0 no estimate centernet:/dev/sdb2 0 no estimate cgi:/dev/hda112304k finished (16:30:02) cgi:/dev/hda30 647610k dumping to tape (16:30:05) isgadmin:/dev/hda1 0 no estimate isgadmin:/dev/hda2 0 no estimate isgback:/dev/ad0s1a 0 [input: No such file or directory] (16:30:03) isgback:/dev/ad0s1e 0 [input: No such file or directory] (16:30:03) isgback:/dev/ad0s1f 0 [input: No such file or directory] (16:30:04) mailinglists:/dev/hda1 0 no estimate mailinglists:/dev/hda2 0 no estimate mailinglists:/dev/hda7 0 no estimate virtual:/dev/hda10 no estimate virtual:/dev/hda30 no estimate SUMMARY part real estimated size size partition : 16 estimated : 51284715k failed : 14 635815k ( 49.49%) wait for dumping: 0 0k ( 0.00%) dumping to tape : 1 647610k ( 50.41%) dumping : 00k0k ( 0.00%) ( 0.00%) dumped : 1 2304k 1290k (178.60%) ( 0.18%) wait for writing: 00k0k ( 0.00%) ( 0.00%) writing to tape : 00k0k ( 0.00%) ( 0.00%) failed to tape : 00k0k ( 0.00%) ( 0.00%) taped : 1 2304k 1290k (178.60%) ( 0.18%) 3 dumpers idle : not-idle taper writing, tapeq: 0 network free kps: 2970 holding space :10652k (100.00%) dumper0 busy : 0:14:16 ( 98.88%) taper busy : 0:00:09 ( 1.07%) 0 dumpers busy : 0:00:06 ( 0.79%)no-diskspace: 0:00:06 (100.00%) 1 dumper busy : 0:14:19 ( 99.20%)no-diskspace: 0:14:16 ( 99.69%) not-idle: 0:00:02 ( 0.31%) Is cgi:hda3 still dumping to tape? This job has been running since about 4:00pm on Dec. 26. It's now 11am on Dec. 28. The Dec. 21 job did lead me to believe that the tape ran for 60 hours. Is this possible or likely? Yesterday, the tape showed activity, on and off, all during the day, so I didn't disturb it. Today, I haven't caught it doing anything when I walk into the next room. I attached amdump and the log file, if they help. Any suggestions for this amanda newbie? Thanks in advance for your help and efforts. -Kevin Zembower E. Kevin Zembower 410-659-6139 ÿWPCL ûÿ 2 B J #| x Ð °° ÐÐ ÐÐÐ Ø p °Ð ÐÃ ÃFrom: Ä ÄÁØ Ø ÁKevin Zembower [EMAIL PROTECTED] Ã ÃTo:Ä ÄÁØØ Á[EMAIL PROTECTED] Ã ÃDate: Ä ÄÁØ Ø Á12/28/00 10:04AM ÐÐ °` ¸ hÀpÈ x Ð (#%Ø'0*,à.813è5@8:ðH? AøCPF¨H KXM°OR`T¸VYh[À]` °Ð Ðamdump: start at Tue Dec 26 16:01:00 EST 2000 planner: pid 18247 executable /usr/local/libexec/planner version 2.4.2-19991216-beta1 planner: build: VERSION="Amanda-2.4.2-19991216-beta1" planner:BUILT_DATE="Thu May 18 11:29:28 EDT 2000" planner:BUILT_MACH="FreeBSD isgback.jhuccp.org 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386" planner:CC="gcc" planner: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" planner:libexecdir="/usr/local/libexec" mandir="/usr/local/man" planner:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" planner:CONFIG_DIR="/usr/local/etc/amanda" DEV_PREFIX="/dev/" planner:RDEV_PREFIX="/dev/r" DUMP="/sbin/dump"
amreport
hello every body: i'm testing amreport with an amanda run i have just done. i go to the /usr/local/etc/amanda/Diario where i have amanda.conf i type amreport segmentation fault(core dump) why??
No Subject
lists
Re: How can I tell what's happening?
How can I tell whether anything good is happening with my amanda backup? ... The usual way is to look at the E-mail report you get after every run. You are getting those, right? If not, you'd better take a look at "mailto" in amanda.conf. Take a look at amanda.conf for the "logdir" variable. In that directory should be a bunch of files named log.MMDD.N. You can regenerate a report like this: amreport CONFIG -l LOGDIR/log.MMDD.N Which to me indicates that I successfully made a backup on Aug. 17, Dec. = 21 and 26. ... That only says Amanda rewrote the tape label on those days. It does not mean anything useful happened. I attached amdump and the log file, if they help. And they show all sorts of problems (which would also be in the E-mail): error result for host isgadmin disk /dev/hda2: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] error result for host isgadmin disk /dev/hda1: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] See the FAQ at www.amanda.org for information on this error. planner: FAILED mailinglists /dev/hda1 0 [missing result for /dev/hda1 in mailinglists response] planner: FAILED virtual /dev/hda1 0 [missing result for /dev/hda1 in virtual response] planner: FAILED centernet /dev/sda1 0 [missing result for /dev/sda1 in centernet response] These say Amanda was not able to get any estimates from these hosts. Later on: driver: result time 1743.049 from dumper0: FAILED 01-4 [access as amanda not allowed from [EMAIL PROTECTED]] open of /home/amanda/.amandahosts failed I don't know why this happened, but it's bad. The first rule with Amanda is always to run "amcheck CONFIG". If it's not happy (which I'm pretty sure it will not be for you), amdump is also not going to work. -Kevin Zembower John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amreport
i type amreport segmentation fault(core dump) What version of Amanda are you using? Did you get a core file in that directory or /tmp/amanda? If so, what do you get when you run a debugger on amreport and the core file and enter the "where" command, e.g.: $ gdb /path/to/amreport /path/to/core gdb where ... gdb quit Amreport is normally run for you as part of amdump. Why are you running it by hand (not that that's bad, I'm just curious)? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: How can I tell what's happening?
On Thu, 28 Dec 2000, KEVIN ZEMBOWER wrote: How can I tell whether anything good is happening with my amanda backup? I'm new to amanda and trying to get it working on a system that I suspect has never been backed up. (I see messages in amdump like "isgadmin:/dev/hda1 overdue 11318 days for level 0.") My tapelist shows: ... The first thing to run when setting up a new amanda config is amcheck. Amcheck will help you to debug most configuration errors before you proceed to amdump. Once you've gotten your config debugged and are ready to move on to a daily run it's still a good idea to run "amcheck -m" on a daily basis to make sure everything is still right. My advise at this point is to kill any amanda processes running on your server and all clients and then run "amcheck daily" to see what things need attention first. After you've taken care of the problems amcheck flags, there will be fewer if any left to track down from the amdump run. -Mitch P.S. Please put carriage returns (enter key) in your e-mail messages to break up lines to something less than 80 characters each. This will make your messages legible to far more people. Thanks.
Re: How can I tell what's happening?
Thanks, John, for taking the time to try to give me a hand. I've only gotten one email report, but I did get that one, so I believe that the "mailto" is correct. That one came after the Dec. 21 run. It's also the one that gave me the idea that it took 60 hours. I can only "find" one log file: su-2.03# find / -name "log*2000*" -print /usr/local/etc/amanda/daily/log.20001226.0 This is the one I attached to the message. As to the errors: error result for host isgadmin disk /dev/hda2: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] error result for host isgadmin disk /dev/hda1: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] These are puzzling, since I have both a /var/lib/amanda/.amandahosts and a /home/amanda/.amandahosts file (the passwd entry for amanda is: amanda:x:37:6:Amanda Admin:/var/lib/amanda:/bin/bash ), both files are identical, both are owned by amanda:amanda, and both contain "isgback.jhuccp.org amanda. On what I believe is a related note, I also get this error in the log file: FAIL dumper isgback /dev/ad0s1a 0 [[access as amanda not allowed from [EMAIL PROTECTED]] open of /home/amanda/.amandahosts failed I believe that this is related to the fact that /home/amanda/.amandahosts has owner:group of 37:102, neither one of which show up in /etc/passwd or /etc/group, although, as you can see from the preceding paragraph, amanda IS user 37 over on the isgadmin box. The /home directory is actually an NIS mount from the isgadmin machine, but this doesn't seem to be working well either, since I get an "Operation not permitted" error when I try to chown them. One more thing I've discovered in the three weeks that I've been here that I need to fix. I just learned from my coworker that the tape drive has been running intermittently today. Any hope that anything useful is being written to the tape? If so, I'm happy to let it run over the holidays, and work on the problem on Tuesday. But, if it's just garbage, I'll kill it now and start working on troubleshooting. It seems to me that your overall advice is to kill amanda and work on getting amcheck to run without error. Please help me to make sure I do this right. Is killing amanda completely as simple as looking at "ps -aux" and killing individually anything related to amanda or owned by amanda, such as taper or dumper? Should I then manually remove any files, or will amcleanup do all this for me? Anything else I should do to kill it completely, so that I can work with amcheck without any interference? Thanks, again, for all your help. Have a happy New Year. -Kevin Zembower E. Kevin Zembower 410-659-6139 [EMAIL PROTECTED] 12/28/00 12:40PM How can I tell whether anything good is happening with my amanda backup? ... The usual way is to look at the E-mail report you get after every run. You are getting those, right? If not, you'd better take a look at "mailto" in amanda.conf. Take a look at amanda.conf for the "logdir" variable. In that directory should be a bunch of files named log.MMDD.N. You can regenerate a report like this: amreport CONFIG -l LOGDIR/log.MMDD.N Which to me indicates that I successfully made a backup on Aug. 17, Dec. = 21 and 26. ... That only says Amanda rewrote the tape label on those days. It does not mean anything useful happened. I attached amdump and the log file, if they help. And they show all sorts of problems (which would also be in the E-mail): error result for host isgadmin disk /dev/hda2: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] error result for host isgadmin disk /dev/hda1: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] See the FAQ at www.amanda.org for information on this error. planner: FAILED mailinglists /dev/hda1 0 [missing result for /dev/hda1 in mailinglists response] planner: FAILED virtual /dev/hda1 0 [missing result for /dev/hda1 in virtual response] planner: FAILED centernet /dev/sda1 0 [missing result for /dev/sda1 in centernet response] These say Amanda was not able to get any estimates from these hosts. Later on: driver: result time 1743.049 from dumper0: FAILED 01-4 [access as amanda not allowed from [EMAIL PROTECTED]] open of /home/amanda/.amandahosts failed I don't know why this happened, but it's bad. The first rule with Amanda is always to run "amcheck CONFIG". If it's not happy (which I'm pretty sure it will not be for you), amdump is also not going to work. -Kevin Zembower John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
VXA Tape V17
Anyone using Ecrix VXA V17 tapes?
I found this config in the faq-omatic
I have a question:
This drive is supposed to write 66gb with hardware compression.
This config only reflects "length 30609 mbytes" about half of that.
define tapetype VXA {
comment "Ecrix VXA-1 V17"
length 30609 mbytes
filemark 2141 kbytes
speed 2892 kbytes
}
I ran the tapetype utility with hardware compression turned on and got
some differnt results.
define tapetype VXA {
comment "Ecrix VXA-1 V17"
length 27379 mbytes
filemark 8872 kbytes
speed 2540 kbytes
}
- how do I take advantage of hardware compression?
- Is the large differnce in filemarks a problem?
Thanks
brad
Re: How can I tell what's happening?
I've only gotten one email report, but I did get that one, so I believe that t he "mailto" is correct. ... OK, that's good. As to the errors: error result for host isgadmin disk /dev/hda2: isgadmin: [access as amanda not allowed from [EMAIL PROTECTED]] These are puzzling, since I have both a /var/lib/amanda/.amandahosts and a /home/amanda/.amandahosts file (the passwd entry for amanda is: amanda:x:37:6:Am anda Admin:/var/lib/amanda:/bin/bash ), both files are identical, both are own ed by amanda:amanda, and both contain "isgback.jhuccp.org amanda. I assume all the directories down to the file are open enough for the Amanda user to read them? For instance, what happens if you run this as root: # su amanda -c "cat /var/lib/amanda/.amandahosts" # su amanda -c "cat /home/amanda/.amandahosts" On what I believe is a related note, I also get this error in the log file: FAIL dumper isgback /dev/ad0s1a 0 [[access as amanda not allowed from amanda@i sgback.jhuccp.org] open of /home/amanda/.amandahosts failed I believe that this is related to the fact that /home/amanda/.amandahosts has owner:group of 37:102, neither one of which show up in /etc/passwd or /etc/group ... Huh? Which machine are you looking at this from that does not have the Amanda user listed in /etc/passwd? Are you using NIS for passwd files? What happens if you do this as root: su amanda -c pwd ... The /home directory is actually an NIS mount from the isgadmin machine, but this doesn't seem to be working well either, since I get an "Operation not permitted" error when I try to chown them. One more thing I've discovered in the three weeks that I've been here that I need to fix. Did you try to chown them as root or amanda? Does root map to root across the NFS mount? I just learned from my coworker that the tape drive has been running intermitt ently today. Any hope that anything useful is being written to the tape? ... If it's blinking, it's probably working. I have no idea yet why it's going so slow, but it sounds like you have so many other things going wrong we should defer that until we get a good baseline. However ... It seems to me that your overall advice is to kill amanda and work on getting amcheck to run without error. ... This would also be a reasonable step since while it may be sort of working it's clearly not doing everything right, so maybe it's better to get it all straightened out now and start over. Yes, killing Amanda is simply finding all the "ps -u amanda" processes and nailing them, then running amcleanup (which should send you E-mail). Anything else I should do to kill it completely, so that I can work with amcheck without any interference? That should do it. When you start working with amcheck, use the "-cl" options. That will check the client and server without accessing the tape drive and go a little faster. -Kevin Zembower John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: VXA Tape V17
Also Sprach Bradley Glonka:
Anyone using Ecrix VXA V17 tapes?
I found this config in the faq-omatic
I have a question:
This drive is supposed to write 66gb with hardware compression.
This config only reflects "length 30609 mbytes" about half of that.
define tapetype VXA {
comment "Ecrix VXA-1 V17"
length 30609 mbytes
filemark 2141 kbytes
speed 2892 kbytes
}
I ran the tapetype utility with hardware compression turned on and got
some differnt results.
define tapetype VXA {
comment "Ecrix VXA-1 V17"
length 27379 mbytes
filemark 8872 kbytes
speed 2540 kbytes
}
- how do I take advantage of hardware compression?
- Is the large differnce in filemarks a problem?
Thanks
brad
In the www.ecrix.com site under tech support there are
utils for Linux, Solaris, and Windows to manipulate the
tape drive settings. I set favor capcity over speed and
turned compression on but because my data is a mix of
compressible and non-compressible I don't get more than
about 40GB per tape.
--
C. Chan [EMAIL PROTECTED]
PGP Public Key: finger [EMAIL PROTECTED]
Re: VXA Tape V17
This drive is supposed to write 66gb with hardware compression. This config only reflects "length 30609 mbytes" about half of that. Which is pretty close to correct, then. Manufactures reports twice the "native" density when giving the number for compression. I ran the tapetype utility with hardware compression turned on and got some differnt results. Don't do that. Tapetype deliberately generates random data to defeat hardware compression. - how do I take advantage of hardware compression? You fudge the length up from what you think it will do native based on the amount of compression you expect to get. And here's a tip -- **nobody** gets double :-). I typically see 20-35%. brad John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: VXA Tape V17
Also Sprach John R. Jackson: - how do I take advantage of hardware compression? You fudge the length up from what you think it will do native based on the amount of compression you expect to get. And here's a tip -- **nobody** gets double :-). I typically see 20-35%. brad John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Thanks to the increase in JPEG, MPEG, and MP3 files I would expect that in the near future turning on compression, hardware or software, will actually cause the size of the backups. -- C. Chan [EMAIL PROTECTED] PGP Public Key: finger [EMAIL PROTECTED]
Re: VXA Tape V17
Also Sprach C. Chan: You fudge the length up from what you think it will do native based on the amount of compression you expect to get. And here's a tip -- **nobody** gets double :-). I typically see 20-35%. brad John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Thanks to the increase in JPEG, MPEG, and MP3 files I would expect that in the near future turning on compression, hardware or software, will actually cause the size of the backups. ... to increase by 10-20% I mean. I think Amanda with software compression is smart enough not to compress if it means an increase in size but currently software compression takes too long to fit in my backup window. -- C. Chan [EMAIL PROTECTED] PGP Public Key: finger [EMAIL PROTECTED]
Re: VXA Tape V17
... I think Amanda with software compression is smart enough not to compress if it means an increase in size ... I don't think so. Compression is always done in a pipeline so there is no chance to recover the original data if at the end it looks like it was a bad idea. C. Chan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
DLT7000 drive not streaming ?
I have a FreeBSD system running Amanda 2.4.2 with a DLT7000 tape drive. I notice that the drive doesn't stream continously. The tape shuttles back and forth. Is there a way to maximize tape drive throughput so that the tape drive will stream continously? Thanks, Joe DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - clock.via.ne wd0s1a 0 40384 40384 --0:49 827.9 1:01 665.6 clock.via.ne wd0s1e 04064 4064 --0:031471.9 0:11 363.8 clock.via.ne wd0s1f 0 918048 918048 -- 23:44 644.5 10:241470.5 mail.via.net da0f0 12009601200960 -- 23:18 859.2 2:407508.9 mail.via.net da0s1 0 21216 21216 --0:24 889.4 0:063737.1 mail.via.net wd0s1a 0 28384 28384 --0:191485.6 0:102989.8 mail.via.net wd0s1f 0 18683521868352 -- 39:37 786.0 11:492635.4 ns.via.net ad0s1a 0 33696 33696 --0:056428.7 0:065289.1 ns.via.net ad0s1e 01952 1952 --0:011436.5 0:03 756.5 ns.via.net ad0s1f 0 824192 824192 -- 20:59 654.8 10:291311.0 secure.via.n ad0s1a 0 28192 28192 --0:055360.8 0:074032.0 secure.via.n ad0s1e 0 17568 17568 --0:044829.0 0:044303.7 secure.via.n ad0s1f 0 54503365450336 -- 68:421322.2 13:536545.5 stats.via.ne sd0s1a 0 19744 19744 --0:131501.2 0:054333.8 stats.via.ne sd0s1e 02656 2656 --0:05 537.8 0:021326.8 stats.via.ne sd0s1f 0 18422721842272 -- 23:441293.8 3:567793.0 stats.via.ne sd1s1e 0 93004489300448 -- 100:001550.1 15:569725.6 www3.via.net sd0a0 16096 16096 --0:062587.8 0:043753.5 www3.via.net sd0s1e 0 53376 53376 --0:153574.0 0:087059.2 www3.via.net sd0s1f 0 806528 806528 -- 22:34 595.8 11:441146.2 www3.via.net sd1s1e 0 576576 --0:24 24.4 0:03 213.1 www3.via.net sd2e0 24289922428992 -- 41:14 981.6 8:284777.9 www5.via.net sd0s1a 0 15968 15968 --0:111471.0 0:043852.2 www5.via.net sd0s1e 02048 2048 --0:02 922.7 0:03 674.4 www5.via.net sd0s1f 0 32991043299104 -- 70:49 776.4 9:235857.3 www6.via.net sd0s1a 0 15744 15744 --0:062790.0 0:043887.9 www6.via.net sd0s1e 03712 3712 --0:031428.3 0:031392.1 www6.via.net sd0s1f 0 12147521214752 -- 13:121533.2 2:298165.0 www6.via.net sd1s1e 0 27695042769504 -- 77:59 591.9 8:155595.0 www8.via.net sd0s1a 0 15648 15648 --4:44 55.1 0:19 828.3 www8.via.net sd0s1e 01536 1536 --0:50 30.7 0:03 608.7 www8.via.net sd0s1f 0 10014081001408 -- 485:48 34.4 2:048055.8 www8.via.net sd1e0 12059841205984 -- 490:14 41.0 3:495258.9 www8.via.net sd2e0 576576 --0:52 11.1 0:02 245.9 (brought to you by Amanda version 2.4.2) -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124
Re: How can I tell what's happening?
I ran these test on the isgadmin box, one of the targets. isgback is the amand a server. Both seemed to work fine; both listed the contents of the file. OK so far. What I meant to say is that the userID 37 doesn't show up in the /etc/passwd f ile of isgback. Similarly, the groupID 102 doesn't show up in the /etc/group file of isgback. su-2.03# grep 37 /etc/passwd su-2.03# grep 102 /etc/group Amanda insists the .amandahosts file be owned by the Amanda user, so it looks like you need to get all of that in sync on your various machines. I'm not sure I know what "root mapping to root across the NFS mount" means. NFS servers often map "root" to "nobody" when a client makes a request as a security technique. Since user "nobody" rarely has any privileges, "root" on such a client usually cannot do very much in an NFS area. If you want "root" to stay "root", you probably need to add some options to the NFS server export configuration information (the specifics of which depend on the server). Thanks, John, for all your help. I'm tired, I've got tomorrow off, it's New Ye ars ... Sounds like a plan. Have a nice few days off and we'll pick this up again next week. -Kevin John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
