Just to get this into the archives: Running '/usr/lib/amanda/planner backup_job' provides immediate insight into how the planner is thinking at that point-in-time.
On Thu, Nov 15, 2018 at 12:00 PM Chris Nighswonger < [email protected]> wrote: > I've extracted the comments from server-src/planner.c which describe > Amanda's logic in planning dumps. I found it quite informative and pretty > much fitting the behavior I've observed on my systems. I thought it might > be helpful for others. > > I've included it in the body of this email as well as an attached PDF. > > Kind regards, > Chris > > *Amanda Planner Comments as Found in server-src/planner.c**Note: This is a > raw extract of the comments with very minimal post-extraction processing.* > > *1. Networking Setup* > *2. Read in Configuration Information* > > All the Amanda configuration files are loaded before we begin. > *3. Send autoflush dumps left on the holding disks* > > This should give us something to do while we generate the new dump > schedule. > *4. Calculate Preliminary Dump Levels* > > Before we can get estimates from the remote slave hosts, we make a > first attempt at guessing what dump levels we will be dumping at based on the > *curinfo* database. > *5. Get Dump Size Estimates from Remote Client Hosts* > > Each host is queried (in parallel) for dump size information on all of > its disks, and the results gathered as they come in. > > Go out and get the dump estimates At this point, all disks with > estimates are in estq, and all the disks on hosts that didn't respond to our > inquiry are in failq. > *6. Analyze Dump Estimates* > > Each disk's estimates are looked at to determine what level it should > dump at, and to calculate the expected size and time taking historical dump > rates and compression ratios into account. The total expected size is > accumulated as well. > > At this point, all the disks are on schedq sorted by priority. The > total estimated size of the backups is in total_size. > *7. Delay Dumps if Schedule Too Big* > > If the generated schedule is too big to fit on the tape, we need to > delay some full dumps to make room. Incrementals will be done instead (except > for new or forced disks). > > In extreme cases, delaying all the full dumps is not even enough. If > so, some low-priority incrementals will be skipped completely until the dumps > fit on the tape. > *8. Promote Dumps if Schedule Too Small* > > Amanda attempts to balance the full dumps over the length of the dump > cycle. If this night's full dumps are too small relative to the other nights, > promote some high-priority full dumps that will be due for the next run, to > full dumps for tonight, taking care not to overflow the tape size. > > This doesn't work too well for small sites. For these we scan ahead > looking for nights that have an excessive number of dumps and promote one of > them. Amanda never delays full dumps just for the sake of balancing the > schedule, so it can take a full cycle to balance the schedule after a big > bump. > *9. Output Schedule* > > The schedule goes to stdout, presumably to driver. A copy is written on > stderr for the debug file. > >
