> > > How are you doing the 2 tapes per day? > > > > I lie to amanda, and tell here there's one tape of size > > 80Gb, and run amflush manually each day when I get into > > the office. If I were running 1 > > *This* is your problem. What is your reserve set to, and how > much holding disk space do you have?
Holding disk /tmp/amanda/dump: 57492036 KB disk space available, that's plenty. > When amanda hits EOT unexpectedly, it goes into "degraded" > mode. By default, amanda "reserves" 100% of the holding > disk space for degraded mode backups, which are incrementals > only. If you set reserve to a low number, then you free > space for full backups in degraded mode. > > So, amanda was probably going into degraded mode every night > and didn't have any space for level 0s. Thus the "can't > incremental new disk" and "dumps too big" messages. That's a good explanation. I checked my amanda.conf file: # reserve 30 # percent so it's reserving 100% by default. > Also, are you using software or hardware compression? > Depending on your data, you should be able to get more > than 40GB on DLT8K tapes... Yes, I was trying to get it to *work* first, then tweak for optimization. I can definitely up that -- I'm using hardware compression (drawbacks) because if I don't, it runs for 12 hours doing all the gzipping... > > tape per day with a 4 week tape cycle, and I'm actually > > generating more than 40Gb per day of level 1, then there > > will be no space left ever to do the level 0 dumps, > > right? > > If amanda estimates that any dump (whether full or > incremental) is bigger than a tape, it will tell you > that, won't dump the disk, and will do everything > else that it can. Some lies are ok to tell amanda, > this one isn't. > > As I see it, you've got a couple of options: > > 1) Set runtapes to two and use chg-manual. Not optimal, as > I don't think you can run amdump out of CRON as it needs you > to tell it when you've put in the next tape. A big drawback. :( > 2) Split up any partitions with large incrementals > using tar so that you're sure every disklist > entry will fit on a tape. By that do you mean "make sure the size as reported by /usr/bin/du is less than 20Gb"? That's what I do, via a script. So I make sure it fits on *half* a tape, to leave the other half for daily incrementals. But what happens when nearly every day, the daily incrementals are, say, 30Gb? > There may be others, as well. But that's a big, bad lie > you're telling amanda there. You could try cranking > your reserve down if you want to continue your lying > ways. I'll try cranking it down to 10%, and wait a few days to see what she does. Then maybe I should switch (back) to dumpcycle 4 weeks runspercycle 20 tapecycle 22 tapes runtapes 1 I think I had a problem with that before. Yes I remember now, I had a disklist entry that was larger than my tape, and amanda *wasn't* telling me, and when it got to level 9 there was a bug that caused amdump to crash. But perhaps that's fixed now. My script that checks for large disks is fixed, anyway. Bart -- Bart Brashers MFG Inc. Air Quality Meteorologist 19203 36th Ave W Suite 101 [EMAIL PROTECTED] Lynnwood WA 98036-5707 http://www.mfgenv.com 425.921.4000 Fax: 425.921.4040
