--On Thursday, October 23, 2003 15:53:23 +0200 Toralf Lund <[EMAIL PROTECTED]> wrote:
> Paul Bijnens wrote: > >> Toralf Lund wrote: >> >>> I'm thinking about using more than one tape, i.e. set "runtapes" >>> parameter to a value > 1, for my updated archival setup. Is there >>> anything special I need to keep in mind when doing this? Also, how do >>> I set up runspercycle in this case? Is it the total number of tapes >>> runspercycle * runtapes, or just runspercycle? >> >> >> runspercycle does not need to be changed. The "runtapes" means that >> for each run up to that number of tapes may be used (note: not "must"). > >> You have to increase your tapecycle probably to cover the same >> dumpcycle(s), because you'll burn twice as much tapes for each run. >> (well, "burn", hopefully not litteraly). > > I'm still not sure I understand. If I have > > runspercycle 2 > > and > > runtapes 2 > > will amanda try to distribute the full dumps across 4 tapes, or just 2? Well, technically your data could be spread over up to four tapes, but you are only going to have one full backup of a single filesystem on one of the tapes (assuming no promotions were made) and not on the others. Increasing runtapes just gives amanda more room to write a single day's backups, but it is a maximum, so if all the scheduled backups fit on one tape then it won't use the second one until the next run. Frank > When I think about it, the first answer makes most sense, as the parameter otherwise > ought to have been called "tapespercycle". > >> >> The parameter "taperalgo largestfit" will help to fill the first >> tape(s) to 100%. (New since amanda 2.4.3.) > > I'm using that already. > >> >> This works better when also using: >> >> dumporder "SSSSSS" # as many S's as you have dumpers >> >> (or use "TTTTTT", which is a good approximation of SSSS, but optimises >> the total runtime of your backups better; I use TTTTT). >> >> For a complete explanation why this works better, see: >> >> >> http://groups.yahoo.com/group/amanda-users/message/46327 > > This is very helpful indeed. Thanks. > > I've been wondering how I might avoid having the largest image left on the holding > disk when the total size is only just larger than the tape (like you say, taperalgo > often doesn't help), but never noticed this parameter, or the message you are > referring to. > > -- > - Toralf > > -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
