On Wed, Jul 12, 2006 at 04:30:12PM +0200, Ronan KERYELL wrote: > We run AMANDA for many years with the same taper and the time comes with > more and more users until one tape per day is sometimes not enough. :-/ > > We don't have any changer and often one tape is enough. So I would like a > mode where AMANDA would decide it is not possible to have everything on > one tape *but* would not stop dumping and would go on on the holding > disk. Then the autoflush mode would flush everything the day after or a > manual flush could be done on a separate tape. > > The problem is that when AMANDA notices that there is not enough space on > tape, it stops with messages such as: > minou.info.enstb.org /var lev 0 FAILED > [dumps too big, 180301 KB, but no incremental estimate] > minou.info.enstb.org /home lev 0 FAILED > [dumps too big, 3309778 KB, but no incremental estimate] > pei.info.enstb.org /mnt/bonbonne/subversion_backups lev 0 FAILED > [dumps too big, 1414910 KB, but cannot incremental dump new disk] > minou.info.enstb.org /export/bouteille lev 2 FAILED > [dumps way too big, 4632849 KB, must skip incremental dumps] > > I'd like to have incremental and even level 0 dumps on the holding disk, > where I have a lot of space. > > I've played recently with > maxdumpsize -1 # Maximum number of bytes the planner will > schedule > # for a run (default: runtapes * tape_length). > but it doesn't help since it says it can decide to dump more than a tape > but it fails later with the same messages than above. > > So, is there an obvious way to deal with the not-so-frequent overrun we > encounter? > > If not, what about adding a new strategy with a mode such as: > dump-on-holding-disk-if-degraded-mode yes > Should not be to difficult to implement. > > I will try also to play with the reserve keyword next night with, for > example, reserve 50 % for full backups. > > reserve number > Default: 100. The part of holding-disk space that > should be reserved for incremental backups if no tape > is available, expressed as a percentage of the > available holding-disk space (0-100). By default, when > there is no tape to write to, degraded mode > (incremental) backups will be performed to the holding > disk. If full backups should also be allowed in this > case, the amount of holding disk space reserved for > incrementals should be lowered. > > But if it works, why this static allocation between incremental and full > backups? > > Another approach: what about also a mode with runtapes > 1 without any > changer, assuming that the user will use amflush later? >
Close but no applause :( To get amanda to properly plan a day's dumps it will have to know it has additional capacity, otherwise it will try to restrict the dumps to what will fit a single tape. Thus, you are correct that increasing runtapes is needed. However, with a runtape > 1 you need a changer. And there just happens to be a changer script for changer-less drives. It is called chg-manual. So read through that script and configure it as your "changer". I suspect you will be able to daily put in 1 new tape. Yesterday's holding disk leftovers will go onto the tape first. I'm not certain, but I think that tape will still be considered as part of yesterdays' dump and today's files may not go onto it. An alternative is to artificially claim a larger tape capacity than the real capacity. Amanda will hit EOT and end the day's dumping and taping. Anything remaining will autoflush to tomorrows tape. Occasionally, will a little too much for each day accumulating on the holding disk, you will have to amflush to tape those dumps. You also should, as you mention, alter your reserve value. You will not want to go into any "degraded mode" situation without some space available for level 0 dumps. BTW your phrasing "reserve xx% for full backups" is slightly off. The distinction is space that can be used for any level backup and space that can be used only for incrementals. It is the latter, incremental only, that you reserve (defaulting to 100% in degraded mode). The rest can be used for any levels until reaching the reserve %. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
