On Friday 16 November 2018 08:43:05 Chris Nighswonger wrote: > 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.
For me, that ought to be /usr/local/lib/amanda/planner, but its not there? ? There is a /usr/local/lib/amanda but libamanda-3.3.6.so libamandad.la libamar.so libamdevice-3.4.3.so libamglue.la libamxfer-3.3.7p1.so libndmjob.a libamanda-3.3.7p1.so libamandad.so libamclient-3.3.6.so libamdevice-3.5.1.so libamglue.so libamxfer-3.4.3.so libndmjob.la libamanda-3.4.3.so libamanda.la libamclient-3.3.7p1.so libamdevice.a libamserver-3.3.6.so libamxfer-3.5.1.so libndmjob.so libamanda-3.5.1.so libamanda.so libamclient-3.4.3.so libamdevice.la libamserver-3.3.7p1.so libamxfer.a libndmlib-3.3.6.so libamanda.a libamar-3.3.6.so libamclient-3.5.1.so libamdevice.so libamserver-3.4.3.so libamxfer.la libndmlib-3.3.7p1.so libamandad-3.3.6.so libamar-3.3.7p1.so libamclient.a libamglue-3.3.6.so libamserver-3.5.1.so libamxfer.so libndmlib-3.4.3.so libamandad-3.3.7p1.so libamar-3.4.3.so libamclient.la libamglue-3.3.7p1.so libamserver.a libndmjob-3.3.6.so libndmlib-3.5.1.so libamandad-3.4.3.so libamar-3.5.1.so libamclient.so libamglue-3.4.3.so libamserver.la libndmjob-3.3.7p1.so libndmlib.a libamandad-3.5.1.so libamar.a libamdevice-3.3.6.so libamglue-3.5.1.so libamserver.so libndmjob-3.4.3.so libndmlib.la libamandad.a libamar.la libamdevice-3.3.7p1.so libamglue.a libamxfer-3.3.6.so libndmjob-3.5.1.so libndmlib.so Thats all thats there > 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. Copyright 2018 by Maurice E. Heskett -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
