First goal has been achieved - the file system has backed up successfully when it is exclusively in the disklist.
Also, many thanks for the recommendation of Mammoth Tool. I downloaded it from the Exabyte Website and it actually confirmed that the EZ17 was NOT hardware compressing (unlike the helpful guy I phoned at Exabyte who told me that HW compression was on permanently for the EZ17. Regards Kenny -- Kenny MacPherson IT Manager DDI: +44 131 272 7091 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gene Heskett Sent: 06 June 2002 02:43 To: Kenny MacPherson; [EMAIL PROTECTED] Subject: Re: Can AMANDA only backup < 24GB partitions??? On Wednesday 05 June 2002 05:28 pm, Kenny MacPherson wrote: >Stephen, Jon, Lalo and Gene (and anyone else!) > >Thanks for the response. It's very helpful - I wasn't picking on > you Lalo but when I saw the 24GB quoted, alarm bells started > ringing, so it's good to here that my 55GB should be backup-able. > >As far as the holding disk goes, I only have 35GB disk, and I'm on > 32bit Sol 7. AMANDA is configured to use "chunks" of just under > 2GB each. > >The errors tend to be: > >FAILURE AND STRANGE DUMP SUMMARY: > toronto /home3 lev 0 FAILED [out of tape] You're walking on ground I haven't, at least on that sort of a scale. My system here is a CTL-96 Seagate drive but only a 4 slot magazine, so I have 3x about 3.7 gb tapes available. Wary of running an individual partition line in the disklist over the capacity of the tape, I've actually specified my /usr by each individual subdir which even keeps the downloads catchall under 3.7 gb. In this manner, I never ask amanda to span to the next tape, and I have sufficient tapes and days in the cycle that it can do 2 to 4 level 0's in each nightly run, getting it all at level 0 in just 3 or 4 days out of the 7 I allow. Amanda cannot span to the next tape with the leftover portion of a file, but will instead backup to the head (of I think that particular 2gb hunk, but it might be to that whole specified line in the disklist), load the next tape and try it again. In that event, a partition spec in the disklist thats larger than the holding area sounds like a recipe for trouble, and you should probably break the disklist up into smaller pieces by specifying it as subdirs, one per line. > taper: FATAL syncpipe_get: w: unexpected EOF > >or > >FAILURE AND STRANGE DUMP SUMMARY: > toronto /home3 lev 0 FAILED [data timeout] > toronto /home5 lev 0 FAILED [out of tape] > taper: FATAL syncpipe_get: w: unexpected EOF > toronto /home5 lev 0 FAILED ["data write: Broken pipe"] > toronto /home5 lev 0 FAILED [dump to tape failed] > >While this points the finger at the EZ17 library, The Mammoth 2 > drive inside it (AFAICT) should take upto 150GB on it 225m AME > tapes I use - the EZ17 is itself reckoned to do up to a 1TB but > that's probably by spanning 7 tapes together! > >The other possibility I consider is: may the point of failure be > when the holding disk hits 35GB, do the 2GB chunks waiting to get > "held" clash with the 2GB chunks coming off onto the tape? Thats a possibility I think. But since amanda does a decent job of multithreading, sometimes a re-arrangement of the order of the disklist can fix it so taper has enough writes to tape to stay ahead of it for a while. For this, amstatus /config/ while amdump is runnnig, can when it works can be quite educational. My copy seems to have some syntax gotcha's in it ATM, latest 2.4.3b3 snapshot. (Yeah, I have a little spare blood :-) >One thing I would love to do is turn the hardware compression off. > However, while the "standalone" Mammoth 2 drive has this option > in its LCD driven menu, there is no option in the LCD menu of the > EZ17! Is there somewhere I can do this at software level on my > Solaris 7 Ultra 2 (st.conf?) Thats a Solaris system? I'd first verify that you are using a device thats non-compression since I'm told Solaris controls the hardware compression via the device selection. However, if there are options in the menu's, or even hidden dip-switches, I'd certainly try to force the issue to get it turned off and then let amanda do it because it can do it better if you have the cpu horsepower. One thing I've run into with my puny little DDS-2 tapes is that once the tape has been written to with the compression on, its abominably difficult to get its auto-detected compression turned back off. Part of the problem in running hardware compression is that different filetypes will compress less, or more, than average, with the end result being that amanda gets badly blind-sided regarding it view of how much a tape can hold. With hardware compression off, and amanda doing oh, lets say gzip at its highest compression ratio, then amanda can keep track of every byte that goes to the tape *after* compression, thereby giving it a good indication of how much it can schedule for a given tape, and then it won't try to stuff two pounds of worms back in that one pound container like it seems to be trying to do now. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.96+% setiathome rank, not too shabby for a hillbilly Wolfson Microelectronics Ltd. http://www.wolfsonmicro.com t: +44 131 272-7000 f: +44 131 272-7001 Registered in Scotland 89839 This message may contain confidential or proprietary information. If you receive this message in error, please immediately delete it, destroy all copies of it and notify the sender. You must not use or disclose any part of this message if you are not the intended recipient. We may monitor all Email communication through our networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free. However, we cannot accept responsibility for any virus transmitted by us and recommend that you subject any incoming Email to your own virus checking procedures. Wolfson Microelectronics Limited is a company incorporated in Scotland having its Registered Office at 20 Bernard Terrace, Edinburgh EH8 9NX
