Re: amanda + tape changer + solaris 8
[btw. i was not able to send you an email to the adress below: "user unknown" - ok but now to the content ...] Thomas Hepper <[EMAIL PROTECTED]> wrote: > Hi, > On Tue, Jul 31, 2001 at 11:13:15AM +0200, thomas graichen wrote: > [...] >> use inside of amanda ... any help would be appreciated > First which version of amanda ?. Lets assume 2.4.2p2 from cvs, if > not please get the cvs version. i am using the latest source tarball from amanda.org - i.e. 2.4.2p2 > Next try the following (From the 2.5.0 docs, i must update the 2.4.2 docs :-)) > Solaris with sst kernel module, which is not any longer needed in solaris 2.8. > See in the contrib/sst directory > The configuration on solaris 2.8 with the sgen driver is done by creating > the file /kernel/drv/sgen.conf > This file should contain at the beginning the following > device-type-config-list="changer","sequential" > This will force the driver to attach only to the devices with type > either changer (the robot) and sequential (the tape). > Next you must tell the driver on which id it should check for devices > (in this example tape on id 5, robot on id 6), > name="sgen" class="scsi" target=5 lun=0; > name="sgen" class="scsi" target=6 lun=0; > This will create the 2 device files > /dev/scsi/sequential/c0t5d0 (scsitapedev option in chg-scsi.conf) > /dev/scsi/changer/c0t6d0(changer option in chg-scsi.conf) > So the complete sgen.conf looks like: > device-type-config-list="changer","sequential > name="sgen" class="scsi" target=5 lun=0; > name="sgen" class="scsi" target=6 lun=0; > Now you must create the chg-scsi.conf file, take a look in the examples > directory for an starting point. To enable chg-scsi you need the > following in amanda.conf > tpchanger "chg-scsi"# the tape-changer glue script > tapedev "0" > changerfile "path_to_your_config/chg-scsi.conf" > Now change to your config directory (where amanda.conf is in) and > try to call there chg-scsi > path_to_chg-scsi/chg-scsi -info > If you get an result you can try > path_to_chg-scsi/chg-scsi -reset > and see if the first tape is loaded. > Try this an report back success/failures :-) thanks a lot - i got a big step further - i now get the changer recognized by solaris and basic communication with it seems to work but it still does not work completely ok - here some details: chg-scsi.cfg: number_configs 1 eject 1 # Tapedrives need an eject command sleep 60 # Seconds to wait until the tape gets ready cleanmax10 # How many times could a cleaning tape get used changerdev /dev/scsi/changer/c2t4d1 # # Next comes the data for drive 0 # config 0 drivenum0 dev /dev/rmt/1cbn# the device that is used for the tapedrive 0 (BSD type, no rewind, no compression) startuse0 # The slots associated with the drive 0 enduse 4 # statfile/usr/local/amanda/etc/amanda/fptsys/tape0-slot # The file where the actual slot is stored cleancart 5 # the slot where the cleaningcartridge for drive 0 is located cleanfile /usr/local/amanda/etc/amanda/fptsys/tape0-clean # The file where the cleanings are recorded usagecount /usr/local/amanda/etc/amanda/fptsys/totaltime tapestatus /usr/local/amanda/etc/amanda/fptsys/tape0-status #labelfile /usr/local/amanda/etc/amanda/fptsys/labelfile # Use this if you have an barcode reader tapeident C1553A changeridentC1553A #scsitapedev/dev/scsi/sequential/c2t4d0 [amanda@fptapp02 fptsys]$ ../../../libexec/chg-scsi -status all Ident = C1553A, type = HP Auto Loader [C1553A] Ident = EXB-10e, type = Exabyte Robot [EXB-10e]og[215] Ident = generic, type = Generic driver tape/robot [generic] Address Type Status From --- 002 STE Empty -001 003 STE Full -001 004 STE Full -001 005 STE Full -001 006 STE Full -001 007 STE Full -001 001 DTE Full 0002 Sense Status from robot: # START DecodeExtSense Extended Sense # START DecodeSense 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 Read/Write Retry Counter00 Fault Sympton Code 00 DecodeModeSense : Disconnect/Reconnecss 0 Number of ImportExport Elements0 First Data Transfer Element Address 1 Number of Data Transfer Elements 1 DecodeModeSense : MT can store data cartridges 0 DecodeModeSense : ST can store data cartridges 1 DecodeModeSense : IE can store da
several incremental backup on one tape, then full back up on weekend
Hi, I'm now trying to set up amanda-2.4.2p2 at Solaris 7 with DLT drives. The DLT drive doesn't have changer feature. I'd like to do something like: -- level 1 dump on Monday thru Thursday night without tape change -- 4 incremental back up jobs at one tape -- weekly full dump on another one tape -- 5 weeks cycle, so that total 10 tapes How should I set "dumpcycle", "runspercycle" and "tapecycle" keywords in amanda.conf file? And any requirements? Thanks any response, Yoshi Yoshiaki Ueda Cognex Corproation
Re: disk vs tape sizes
[EMAIL PROTECTED] wrote: > > am i correct that amanda will not dump a disk that has an > estimate larger than the tape size, correct? Partially. amanda cannot split dumps larger than tape size. amanda _can_ split tar archives. > i presume this is > because amanda has no way of reliably predicting whether or not > the disk will fit on the disk *after* compression, which of > course, it may be able to do quite easily. can this be circum- > vented by applying your average compression factor to the size > specified in the amanda.conf file (ie, change 2000 mb -> 4000 mb > for a factor of 2:1)? basically, i can't get certain large fs's > backed up because amanda doesn't think they'll fit (which is the > simplistic, but safe stance). No. > there isn't anything else i can do about the situation, is > there? i am using a DLT4000 drive with DLT-IV tapes labelled as > '40-80 GB with compression', but realistically, they can fit > 17ish gigs of data. so, what i am proposing is lying to amanda > about how large the disk is so i can fit a 30 GB fs on the tape, > considering that amanda should compress the filesystem before > dumping to tape, right? > > i know this sounds sketchy at best, but do i have another option > (save buying new hardware or partitioning the filesystems into > smaller ones?) DLT1 drives give you the full 40GB uncompressed. They come pretty cheap, too (compared to DLT8000). If you want to stay with your drive, I'd define chuck size less than your minimum tape size, and apply chg-manual (the manual tape changer routine). HTH -Christoph Sold
Re: disk vs tape sizes
>using linux (deb potato). ... Sorry. I thought I saw something about Solaris in your E-mail. Anyway, on Linux, I think it's done with the "mt" command, something like "mt -f /dev/nst0 compress off" (or it might be "datcompression"). Take a look at the man page. >-c John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
several incremental backup on one tape, then full back up on weekend
Hi, I'm now trying to set up amanda-2.4.2p2 at Solaris 7 with DLT drives. The DLT drive doesn't have changer feature. I'd like to do something like: -- level 1 dump on Monday thru Thursday night without tape change -- 4 incremental back up jobs at one tape -- weekly full dump on another one tape -- 5 weeks cycle, so that total 10 tapes How should I set "dumpcycle", "runspercycle" and "tapecycle" keywords in amanda.conf file? And any requirements? Thanks any response, Yoshi Yoshiaki Ueda Cognex Corproation
Re: "index tee broken pipe" problem again
>... I haven't touched something since weeks. Yeah, yeah, yeah. We've all heard that story before :-). >Here is, what amanda report says: >? sendbackup: index tee cannot write [Broken pipe] What else was in the Amanda report, in particular about this disk or from taper? This typically means the backup was going along OK and the tape server side shut down for some reason, such as running out of holding disk space or running out of tape. The "index tee cannot write" is just a symptom of something else going on. >Gaby John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: problem after changing amanda server IP address
>after changing ip address of my amanda server got following error : > >server1 / lev 0 FAILED [Request to server1 timed out.] >... If Christoph's idea about hosts.allow/hosts.deny does not help (and that's the first thing I thought of, too), look in the FAQ at www.amanda.org for this message and the corresponding amcheck "selfcheck request timed out. Host down?" There is a lengthy list of things to look for on the client to find out why it's not talking any more. BTW, "amcheck -c " will be easier for you to work on this problem with. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] P.S. Please turn off "send as HTML" in your mail program. It's just a waste of bandwidth.
Re: tar + solaris 2.6
>i'am using Solaris 2.6 + Amanda 2.4.2p2. The backup server is on >linux. > >When i'am trying to backup a partition (around 5.5 Gigs) using >tar (gnutar 1.3.19) for cross-platform backup, i just get a time >out and tar seem to run forever. What kind of timeout? In other words, what is the exact error you're getting? Also, I'm not 100% clear. Is the file system being backed up on the Solaris machine and you're sending that over to the Linux box, or is it the other way around? Put a different way, where's the tape drive? Do you have software compression enabled? On the client or the server? >For the others partitions, i don't have the problem ... Other partitions on that same client, or on other machines? >Yannick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: FAILURE AND STRANGE DUMP SUMMARY:
>I do a special configuration with only the host that I'm having a >problem with (atalante). >and amanda success to do this. >So i'm kind of puzzled about it. That could just mean whatever made ufsdump upset doesn't happen to be active at the moment. > -atalante is the "backup client host" and the "Tape Server Host" in the >same time OK. That's a normal situation. > - I don't really understand how you guys are nominating the clients and >the servers Yeah, that confuses people, and I agree the terminology could easily be considered "backward". But it is the way it is and to start calling things by the other names would only make matters worse. > I thought that amanda was composed of > -many serverS on each host where we would like to > backup data from Those are called "Amanda clients". > -one client orchestrating the download and where we can found > the programs amdump And that's called the "Amanda server". > - Is there a way to force the planner to not do a level 0 on a host Use "strategy nofull" or "strategy incronly" in the dumptype. But read about them in the amanda(8) man page. > - Amrmtape: considering I'm using a configuration for many times and >that > I would like to do some changes on it. I thought that I can launch an >amdump > and if the result failed , I have just to launch an amrmtape to discard >the > last amdump and to have all the databases at the same point that before >the tests > (if I do the amrmtapes on all tapes used during the tests) That should be correct. Why? Is it not working? You might also consider backing up (e.g. with GNU tar by hand) the curinfo database and tapelist files yourself before a test run, and then just restore them to start again. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: SKSP1 AMFLUSH MAIL REPORT FOR August 2, 2001
>> tunkki /usr/home lev 2 FAILED [out of tape] >> taper: FATAL syncpipe_get: r: unexpected EOF > >I've gotten this on two tapes now and various other errors since I >upgraded to 2.5 (CVS) branch in hope of getting the file target to work. You've got to be nuts to run the 2.5 branch of code. :-). Calling it experimental or alpha quality would be overly generous. While doing some work in there last week I found numerous bugs. Unless you're planning on debugging it yourself (and feeding the patches back), you should probably stay away from it. That "FATAL syncpipe_get" is a good indication of this. It indicates a protocol error between the two halves of taper. That's a no-no. >> taper: tape sksp_018 kb 1654208 fm 5 writing file: No space left on device As Christoph said, this, and the "out of tape" message, mean exactly what they say -- Amanda got an error back from the OS that indicated it had reached end of tape. Note the "kb 1654208". That says taper had written ~1.6 GBytes when it got the error. What kind of tape drive and tapes are you using? What kind of capacity do you expect to be getting? What do you have your tapetype length set to? >... I had another report (should've >quoted that) on the same flush that said tape used was 23% or so. That "23%" is nothing more than the amount of data taper **successfully** wrote (i.e. it would not include the last image it was working on if it hit an error) compared to the length parameter from the tapetype in amanda.conf. Since you can set the tapetype value to anything you want (i.e. lie :-), you can make that percentage say anything. In other words, Amanda does not magically know (e.g. by asking the drive) that 23% of the physical tape was actually used. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: disk vs tape sizes
[EMAIL PROTECTED] writes: >>... If you have a changer and runtapes > 1 ... > >i change tapes manually, and amanda should ignore this value, i >believe. Probably true. You could use chg-manual to have a "manual" tape changer which would let you set runtapes > 1, but that's probably not what you are doing (yet). >so amanda is indeed doing what i proposed--calculating an >'effective' tape size by appling the average compresion ratio to >the tapesize specified in the amanda.conf file? Yup. >i don't believe i am using hardware compression, and if i were, >i wouldn't know how to disable it :( You can look at the front panel lights while a backup is running to see if hardware compression is being used. If it is, and you are also trying to use software compression, one or the other should be disabled. It's pretty easy to disable hardware compression with Solaris. It's all in the device name. You're probably using /dev/rmt/0cn (the number might be different, it's the 'c' that matters) or /dev/rmt/0mn. Just change that to /dev/rmt/0ln and it should stop. >it's a DLT4000 and the tapes are C5141F's. I don't recognize that tape type, but a DLT4000 is incapable of doing 40-80 GBytes. I'm sure you're at the 20-40 range (actually, just the 20 value if you turn off hardware compression). >the number came from running tapetype. also, the taper reported >roughly (somewhat larger) the same size when it hit EOT OK, that's good in one sense -- they are consistent. But it's also one more indication you probably have hardware compression going on. Tapetype should have seen closer to 20 GBytes. >that was a typo. i meant to say that i was proposing to lie to >amanda about how large the *tape* was... you should be able to >do that, right? ... I do every day :-). That's how you use hardware compression (and not software). You crank up the tapetype length by roughly the amount you think the hardware will be able to compress by. >the other issue is that i have been running this troublesome >backup at the same priority, and it is on a client with far more >backups than any other, and always reports its estimates dead >last (i am assuming this is because the estimates are collected >and sent out in one packet ... That's correct, but I don't know what the time the estimates complete has to do with anything. Planner has to wait for **all** the clients to respond before building the schedule, and no dumping happens until the schedule is given to driver. >... the issue is that even if there >is space, everything is at the same priority, so the other >(ready) clients start filling up the tape, and the large disk >runs last. ... >is there some way i can force the large disk to backup first? ... This gets somewhat involved, so grab a drink and get comfortable before proceeding :-). The schedule planner generates includes an estimated time it will take to dump which is based on the estimated size and the historical speed of backups from that client (Amanda keeps actual dump times for the last several backups just like it does software compression ratios). If you look at your amdump.NN file for the "GENERATING SCHEDULE" section, find the first (if there are two) colon separated datestamp (e.g. "2001:8:1:4:47:18"). The number after that is the estimated size (in KBytes). The number after that is the estimated dump time (in seconds). Dumper reads the schedule and sorts it by estimated dump time. Now a couple of other things come into play. If you have three or fewer dumpers (inparallel <= 3), they take entries from the front of the queue (the shortest estimated dump time). If you have more than three dumpers (inparallel > 3), the first three dumpers take items from the front of the queue and the rest of the dumpers take items from the end of the queue (longest estimated dump time). So if you have inparallel > 3 and the "large disk" is at or near the end of the estimated time list, one of the dumpers should be assigned to it at the start of the run. However (you knew there had to be a problem, right? :-), there are several other criteria that will prevent a backup from being assigned to a dumper. The most obvious is that it won't fit in the holding disk, either because it's just plain too big, or its size in conjunction with what's already running would overcommit. Other things, like network use, other backups running on that client (maxdumps), etc, can also hold up a backup. My guess is the image is too large for the holding disk, which brings up the next phase of driver. After all the backups have been processed that can go through the holding disk, it may still have items left over. These are handled, one by one, from the front (shortest time) of the queue. >actually, i am under the impression that the >priority value does not apply like this, but to incrementals >without a tape... Correct. >i can only think of using the 'starttime' option to hold all the >other disks until the large disk has beg
Re: amanda + tape changer + solaris 8
>i am using the latest source tarball from amanda.org - i.e. 2.4.2p2 You may want to get the amanda-242-branch CVS source instead. It includes the chg-scsi that Thomas (the other Thomas :-) is more used to working with, and has certainly enhanced beyond what comes with the tarball you're working from. There are a couple of FAQ items at www.amanda.org about how to get the CVS sources and build them. Only the server would need to be upgraded, not the clients. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: combined amflush & amdump
>Unfortunately, amflush is designed to be run manually and to a >separate tape, and amdump leaves the older dumps in the holding space >untouched even if there's the right tape in the drive. > >Do you have any suggestions to this situation? Two possibilities come to mind: 1) Get enough holding disk space that you can do the level 0 dumps into there so amflush will take care of it as well as the incrementals. or: 2) Look back through the amanda-hackers mailing list archive for "autoflush" where I proposed and we discussed how to do what you want. Then spend a month or so coding it up and submit it for inclusion with Amanda. I know. Probably not what you wanted to hear. :-) > -frank John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
No Subject
unsubscribe [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Script for tape usage statistics
Hi, This little script can be used to keep track of number of tape usages. I use it with recent GNU tools on a Linux machine. Multiple skript calls per configuration and day do no harm thanks to "uniq" and file time comparison. The calling user needs write access to the config dir in /etc/amanda/. I looked at amgetconf to find the configuration directory but could not find the right entry in amanda.conf. What about adding the output of this skript to the daily mail? At the moment I have to add it to the cron job and might miss "amflush"'es. Please feel free to modify the script. May it save you from worn out tapes at restore time. Johannes Niess P.S: Keep an eye on line endings for the commands. #! /bin/sh # Made by Johannes Niess (mail: [EMAIL PROTECTED]) if test -z $1 ; then echo "Amanda-tapestats reports the number of times the tape list entry has been updated. The skript has to be run at least once after each update. Usage: amanda-tapestats ";exit;fi if test /etc/amanda/$1/tapelist.long -ot /etc/amanda/$1/tapelist; then echo "Amanda tape usage count"; cut -d " " -f 1,2 /etc/amanda/$1/tapelist*|sort|uniq >tapelist.$ && mv tapelist.$ /etc/amanda/$1/tapelist.long; cut -f 2 -d " " /etc/amanda/$1/tapelist.long |sort|uniq -c|sort -rn > /etc/amanda/$1/tapecount && cat /etc/amanda/$1/tapecount; fi
Re: problem after changing amanda server IP address
hi, > jcarreiro schrieb: > > hi, > > i have linux debian 2.2r3 and amanda 2.2.4-?? > > > after changing ip address of my amanda server got following error : > > server1 / lev 0 FAILED [Request to server1 timed out.] > server2 /archive lev 0 FAILED [Request to server2 timed out.] > > > DNS FQDN unchanged ... forward & reverse lookups updated with the new > ip.. perhaps old Ip-adress in hosts.allow/hosts.deny ? > any idea ? > thx 4 help. > > > >
Re: SKSP1 AMFLUSH MAIL REPORT FOR August 2, 2001
Harri Haataja wrote: > > On Thu, 2 Aug 2001, Amanda backup user wrote: > > > The dumps were flushed to tape sksp_018. > > *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. > > Some dumps may have been left in the holding disk. > > Run amflush again to flush them to tape. > > The next tape Amanda expects to use is: sksp_019. > > > > FAILURE AND STRANGE DUMP SUMMARY: > > tunkki /usr/home lev 2 FAILED [out of tape] > > taper: FATAL syncpipe_get: r: unexpected EOF The error message says it all: there was more data to backup than will fit onto your tape. > I've gotten this on two tapes now and various other errors since I > upgraded to 2.5 (CVS) branch in hope of getting the file target to work. > > Can you give some direct tip as to why this is happening or is there > something I should know about this version change? > > > STATISTICS: > > [snip] > > > > NOTES: > > taper: tape sksp_018 kb 1654208 fm 5 writing file: No space left on device > > amflush: /home/amanda/hold/20010731/tunkki._usr_home.2: taper error, leaving >file on disk > > amflush: /home/amanda/hold/20010731/shaft._var.0: taper error, leaving file on >disk > > amflush: /home/amanda/hold/20010731/shaft._usr.0: taper error, leaving file on >disk > > amflush: Could not rmdir /home/amanda/hold/20010731. Check for cruft. > > Yes: either buy yourself bigger backup media, or subdivide your backup volumes. eventlually, utilize the manual changer to backup onto more than one tape. HTH -Christoph Sold
tar + solaris 2.6
Hello, i'am using Solaris 2.6 + Amanda 2.4.2p2. The backup server is on linux. When i'am trying to backup a partition (around 5.5 Gigs) using tar (gnutar 1.3.19) for cross-platform backup, i just get a time out and tar seem to run forever. For the others partitions, i don't have the problem, and the backup run very well (the partition are less than 1.7 gig). I set the etimeout in amanda.conf to 1800. Any hint or help will be appreciated. Thank you Yannick
Re: DLT8000, IRIX, Indy
* Brian Cuttler <[EMAIL PROTECTED]> (Thu, Aug 02, 2001 at 11:13:44AM -0400) > Gerhard, > In order to run the DLT8000 on irix (pre-6.5.12) I did modify > the device tables, changed the device recognition string but > didn't mess with the parameters so the DLT8000 was treated as > a 7000. > Mods where to the /var/sysgen/master.d/scsi file. > SGI suggested I might do this under 6.5.12 rather than using > the new TS drivers. > Will have to see what they come up with. Surprised to hear that > they may not support the DLT8000 on the older hardware, thought > it was an across the board thing and the vendor that sold us > the drive certainly claimed... well, salesmen. ;-) Well, it might be supported (in fact Im still hugely surprised it's not) but the docs I have, give no clue as to how to do it ;( Ah well, a 2 week holliday coming up in about 5 hours ... ;) Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Global Technical SupportFax +31-10.280.1511 Jason Geosystems BV (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: disk vs tape sizes
i am *really* sorry if there is another very similar message that got sent to the list... i am having serious problems with my web-based email system... >>am i correct that amanda will not dump a disk that has an >>estimate larger than the tape size, correct? ... > >No, that's not quite correct. If you have a changer and runtapes > 1, >it will go ahead and dump things bigger than a single tape. i change tapes manually, and amanda should ignore this value, i believe. >>i presume this is >>because amanda has no way of reliably predicting whether or not >>the disk will fit on the disk *after* compression, which of >>course, it may be able to do quite easily. ... > >Amanda keeps historical information on (software) compression it gets >for each file system and applies that to the estimates. > >If Amanda is telling you things won't fit, they probably won't fit. so amanda is indeed doing what i proposed--calculating an 'effective' tape size by appling the average compresion ratio to the tapesize specified in the amanda.conf file? >>there isn't anything else i can do about the situation, is >>there? i am using a DLT4000 drive with DLT-IV tapes labelled as >>'40-80 GB with compression' ... > >Whoa, there. First of all, this sounds like you have both hardware >and software compression enabled. That's a bad idea. Compressing >things twice usually ends up expanding them. i don't believe i am using hardware compression, and if i were, i wouldn't know how to disable it :( >Second, those tapes don't hold 40-80 GBytes in a DLT4000. In a DLT8000 >drive, yes, but in a DLT4000 the numbers are 20-40 GBytes. > >Damned marketing people ... :-) it's a DLT4000 and the tapes are C5141F's. >>but realistically, they can fit 17ish gigs of data. ... > >Where did that number come from? If it came from the NOTES section >of your Amanda E-mail and the "taper: tape ... kb" lines, that's an >accurate report of what taper had written before it banged into EOT >(assuming it did). the number came from running tapetype. also, the taper reported roughly (somewhat larger) the same size when it hit EOT >Turning off hardware compression will probably get you nearer 20 GBytes >if you continue to use software compression. see above :( >>so, what i am proposing is lying to amanda >>about how large the disk is ... > >You can't lie to Amanda about the disk size. It asks the OS how much >free space there is and will never attempt to use more than that. that was a typo. i meant to say that i was proposing to lie to amanda about how large the *tape* was... you should be able to do that, right? (even though it wouldn't be a good idea if amanda already calculates the effective tape size from average compression ratios) >>so i can fit a 30 GB fs on the tape, >>considering that amanda should compress the filesystem before >>dumping to tape, right? > >Is the 30 GBytes the amount of data on the file system (i.e. the backup >image size without compression)? You'd better find out if that will >compress down to < 20 GBytes before going any further. Based on what type >of data is in the file system, you may get more or less than that (i.e. >if it's full of JPEG images, they are already compressed and you won't get >much more, but if it's all source it will compress a lot more than 50%). unfortunately, i assumed that it would, and did not check it. this is not correct (i know), but it *is* mostly code and text alike. the other issue is that i have been running this troublesome backup at the same priority, and it is on a client with far more backups than any other, and always reports its estimates dead last (i am assuming this is because the estimates are collected and sent out in one packet, which may not be the case, but would correspond to the behavior). the issue is that even if there is space, everything is at the same priority, so the other (ready) clients start filling up the tape, and the large disk runs last. actually, i am under the impression that the priority value does not apply like this, but to incrementals without a tape... is there some way i can force the large disk to backup first? i can only think of using the 'starttime' option to hold all the other disks until the large disk has begun actually dumping to tape (which would be a guestimate). thanks everyone, -c __ Get Your FREE FlashMail Address now at http://www.flashmail.com It's Free, Easy, & Fun !!!
combined amflush & amdump
Hi! I have quite small number of quite huge and expensive tapes (6 * LTO 100GB). My plan is to let amdump write level 1-n dumps to the holding space on weekdays and insert the next tape only during the weekend dump which would have enough space to flush the holding space *and* to run the regular dump even with lots of level 0 dumps. Unfortunately, amflush is designed to be run manually and to a separate tape, and amdump leaves the older dumps in the holding space untouched even if there's the right tape in the drive. Do you have any suggestions to this situation? -frank
Re: DLT8000, IRIX, Indy
Gerhard, In order to run the DLT8000 on irix (pre-6.5.12) I did modify the device tables, changed the device recognition string but didn't mess with the parameters so the DLT8000 was treated as a 7000. Mods where to the /var/sysgen/master.d/scsi file. SGI suggested I might do this under 6.5.12 rather than using the new TS drivers. Will have to see what they come up with. Surprised to hear that they may not support the DLT8000 on the older hardware, thought it was an across the board thing and the vendor that sold us the drive certainly claimed... well, salesmen. ;-) thanks, Brian > I said I'd check this in the docs that came wth out DLT8000. > There's a couple of pages about hooking up a DLT to an IRIX box, but upon > closer reading the book only offers instructions for DLT devices upto a > DLT7000 not for a DLT8000 ... ;( > > > Kind regards, > -- > Gerhard den Hollander Phone +31-10.280.1515 > Global Technical SupportFax +31-10.280.1511 > Jason Geosystems BV (When calling please note: we are in GMT+1) > > [EMAIL PROTECTED] POBox 1573 > visit us at http://www.jasongeo.com 3000 BN Rotterdam > JASON...#1 in Reservoir CharacterizationThe Netherlands > > This e-mail and any attachment is/are intended solely for the named > addressee(s) and may contain information that is confidential and privileged. >If you are not the intended recipient, we request that you do not > disseminate, forward, distribute or copy this e-mail message. > If you have received this e-mail message in error, please notify us >immediately by telephone and destroy the original message.
