Hi, thanks for replying. John R. Jackson writes: > Could you give some more detail? First, what version of Amanda? Second, > did Amanda go through all six tapes? The way you have it set up above, > assuming one tape per day, it should have used the first five tapes > in the first week, then used the sixth tape at the start of the second > week, and only then gone back to the first tape (on the second day of > the second week).
The version string is Amanda-2.4.2p2. >>... So my amoverview for this partition looks like this: >> >>host /partition 1 1 1 2 3 > > Were there really only five entries on a line? When I run it, I get > the same number of entries as tapecycle is set to. The thing that happened was that on the very first run there was not enough room on tape to cover the whole lot in level 0 (this was expected), so the partition I refer to was dumped to the holding disk. Later I used amflush to write this to tape, so that's where the extra tape went. (And that is why there is missing a date in the amoverview, there is an extra space in the output). The day missing is the day the level 0 went to the holding disk. I guess that missed first run caused the only free tape to be used, and then I was out of tapes (and luck). > What happens if you run "amadmin <config> find <host> </partition>"? Results consistent with the output from amoverview. > The general suggestion is that you have at least twice as many tapes > as your dumpcycle. That way, even if the most recent level 0 is bad, > you have at least one more you can fall back on. I did this now (plus a few extras), and I clearly see that having a longer timespan of tapes gives a nice redundancy. When I first started test running Amanda, I didn't clearly see the concept of tapecycle, and I was pretty hung up on my idea of getting a _complete_ cycle to take offsite. Now I plan to take the most recently written half of the tape set offsite. And I do like seeing a number of level 0 backups on different tapes, as I know they do fail. Best, Reidar
