Toralf wrote: >What exactly controls the order of which file systems are dumped by >Amanda? ...
Atmospheric conditions over my house. :-) Seriously, this is a fairly complicated area. The schedule planner comes up with is sorted by the estimated time it will take to do the disk. That, in turn, is figured out based on the estimated size of the image and the average of the last three full or incremental backups (depending on what type of backup is done this time). The number of dumpers working for driver is based on your inparallel amanda.conf value. The default is 10, so we'll work with that for the moment. The first thing driver works on are images that will fit in the holding disk. The first three (LITTLE_DUMPERS in the driver source) dumpers work from the head of the sorted list, i.e. from the "short" end. The last seven (inparallel - LITTLE_DUMPERS, e.g. 10 - 3) dumpers work from the "big" end. After everything has been processed that can go through the holding disk, driver goes into direct to tape mode where a single dumper is involved writing the image directly to taper. These entries are taken from what remains of the list and come from the "small" end. Now, while multiple dumpers are working through the holding disk, any number of things may cause a candidate dump to be deferred. For instance, there might be five dumps from a single client at the head of the list. But if maxdumps is set to the default of 1, only the first entry will be started. The other four will have to wait until it finishes. However, driver keeps going through the list and may start a backup from some other client that is not strictly next in the list, but is able to be started. There are about a dozen restrictions that can cause a dump to be skipped and looked at later, such as maxdumps, a spindle contention, not enough holding disk space, no free dumpers, not enough bandwidth and so on. Note that if inparallel is set very small, things act much differently. If it is three or less, all of the dumpers will be working from the small end of the queue. If set to four, three will work from the small end and only one from the large end. And so on. The above all applies to 2.4.2p2 (and before). At 2.4.3, you have fine grain control over which dumpers are assigned to what via the new "dumporder" amanda.conf keyword. Dumpers may be assigned based on estimated size, time or speed and from either end of the queue. >- Toralf Dave wrote: >... it would be very useful if I could tell >it to write the latest backups of, say, the NFS server's /home and the >partition that holds the company's primary database first ... The schedule is passed from planner to driver via a normal Unix shell pipeline in the amdump script. You could insert a filter of your own to fake the estimated time field down to zero to trick driver into doing important things first. Or, at 2.4.3, we could probably add a new dumporder flag to do things by priority, or something like that. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
