Jon LaBadie <[EMAIL PROTECTED]> writes: >> One thing I've never understood is: WHY does Amanda need to know the >> dumpcycle in days? If this feature has precedence over the tapecycle, it >> is broken. > > I love it when someone, new to a package, can't get it to work even when > hundreds of others are using it, says "it is broken".
Hum, I used Amanda since 1999 or so and never needed to look very closely at any other issues than this one. I missed that there was a runspercycle option, it had not been in my configuration I've been using for a long time, and I do not remove commentary. (sysconftool might be interesting for the next major Amanda version, it fills in new parameters into an existing configuration, leaving older options untouched.) There is an "if" attached. Let me reword: Amanda should NOT ONLY look at the dumpcycle, but also at the tape list, to find when level 0 dumps are due, because a time-based scheme cannot adjust to "one more in-between backup". Let's see what we have: 1. tapecycle. If you re-insert a tape earlier than tapecycle allows, the tape will not be touched. -> There is functionality in place that allows to protect a tape. 2. dumpcycle. Used to force level 0 dumps AFTER N DAYS. 3. runspercycle. The exact technical function is unclear, I presume it's needed to map dumpcycle to a tape count. 4. Amanda defaults runspercycle to dumpcycle, assuming daily backups are made, rather than looking at the tapeinfo. Why that? Let me see if I get this right: Amanda does not have an equivalent to tapecycle that protects existing level 0 dumps. Running additional in-between backups with too low a tape count (which can be >= tapecycle) endangers level 0 dumps, does it? Or is some internal runs-before-next-level-0 decreased by a manual in-between backup? Would amanda run a new level 0 dump for a particular file system immediately after a corresponding amrmtape? I have not seen Amanda do that yet. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
