> On Fri, Apr 26, 2002 at 12:40:15AM +1000, [EMAIL PROTECTED] wrote: > > If you are using HW compression you must lie to amanda.
Understood. I am leading her up the garden path as we speak. >The actual data > capacity is a guess. An educated guess, but still a guess. Yep. > Using SW compression (I recognize you don't wish to) amanda knows > how much she is sending to the tape and can use the given capacity > to anticipate the end of the tape without hitting it -- usually :) > > But with HW compression she only knows how much she sends, not what > part of the tape is used. But the human operator can make an "educated" > guess. First measure the actual capacity WITH HW COMPRESSION OFF! As I mentioned, compressed and uncompressed are reported near as dammit the same by tapetype. It should be using my disks, because that't what will be backed up. > > Then guess the effectiveness of the HW compressor, will it give 0.57 > as did gzip? Maybe better, maybe worse. Suppose you decide on 0.65. > Then take your measured capacity and divide by 0.65. Tell amanda > that is your tape capacity. Done. I have punted on 1500. We shall see. > > > Check your setting for gzip compression level. Amanda knows fast and best. > You likely are set to best, aka slowest :). You may find fast gives you > sufficient compression in 1/4th of the time. Nope, fast on a sparc 5 is still slow! Like everything else... > Or possibly two configs, run at different times, with the same tapes and > index dirs, ... I do that for archive tapeings, system vs. user data. > But I don't recycle those tapes. Don't know how it would work with the > tapes being reused. BTW running them at different times does not mean > two cron entries. Just have the cron entry invoke a shell script that > does amdump <config1> followed by amdump <config2> This is a little vexing. For mine, the specifiction of tape type could be moved to disklist, allowing hardware compression on local drives and remote compression for fast clients. Can't see why this is a different 'config' Perhaps this is just a question of semantics, but if I had several different tape drives I would rather have them all in one 'config' than one per. I'm wondering what the motivation was for this design decision. In any case, I already have 'two' tape drives: one compressed, one not. For instance, what if I wanted to put client systems (low priority, cheap tape, less cost, remote compression) onto dds or exa, and database servers onto compressed DLT? Why two configs--it's the same site. I can see how you would argue it the other way, but having to compile a whole other instance just to put in a different tape drive seems a bit like overkill. Or have I misunderstood how that works? I've only had the software three days... > > > The silly part is that amanda calls ufsdump, which supports tape spanning. > > How hard can it be to use something that's already there? > > Very! Yes, I can well appreciate the difficulty. However, if my disk usage goes above 1.5 gb on a single partition, I will have to go back to ufsdump. Or use something else. Ufsdump doesn't handle it all that well I know, because the problem of labelling related tapes etc. is simply ignored and left to external agencies e.g. pen and notepad. If you want to have single file recovery, the only solution I can readily see is preprocess a large file system into sets of directories small enough to fit on the tape, and tar up these lists. Devising algorithms to do this efficiently would be amusing I daresay. Variation on the truck loading problem perhaps? > > And don't forget, she doesn't call ufsdump. She calls ufsdump "on your syste > m". > It is dump, or xfsdump, or ext2dump, or ... on other people's systems. They > may or may not support tape spanning. Probably not the same way in any event > . I had of course forgotten about portability issues. > > Also, the ones I've used with tape spanning (rolled my own backup manager) > knew nothing about tape changers/libraries. They all expected an operator > to be able to do the change AND to type a specific response to let the > dump continue. Not easily automated. Damn straight. Tried it myself--haven't we all? :-) expect still won't change a tape for you... Thanks for your input Jon, it has helped. Chuck > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road (609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) >
