add info about using kerberized rsh to the manual

resolve symlinks using something like sl from camel book when searching for executablews

proxy backups (WU)

appendable tape (WU)

named tapes (WU, for use with appendable tapes)

consider variable levels, ala amanda?

different tape pool schemes (ala conversations with pat)

how to deal with tape lengths (WU)
    add-tapes defines
    default set in global.defs
    add option to all-backups to search for free tapes >= SIZE

add option to check-backups to ignore certain chains

how to deal with rewriting 10gb tapes at 5gb? use different tape
devices! (send to john)

create groups of file systems that should *not* be done together
(cause they are on the same disk, or whatever).  change all-bu so that
you can give it multiple drives, and it will do all things in parallel
(unless marked not to) to as many tapes as are available.

separate info about writing to tapes from all-backups - should just
pass that through to the thing that actually does the work (hmm,
though it needs to find free tapes and junk, bother).

types of tape devices
    manual
    drop through stacker
    jukebox
    multiple drives mascerading as a jukebox or stacker

General
	It would be nice to have a meta-all-backups that did some sort
	of scheduling, which could make guesses about what backups to
	start and so on.

	Deal with end of tape somehow.  Maybe use the DeeJay approach,
	create a special backend that can deal with multiple tapes, end
	of tape detection and so on transparently, so that you can use
	dump, tar, cpio with multiple tapes and real EOT detection.
	This should work with tape rollover as well as stackers and
	jukeboxes. (WU)

	Add support for tape stackers and jukeboxes (WU).

	Incorporate tape cleaning schedule in check-backups somehow?

	Add blocksize parameter for dd to use (fix for AIX systems).

add-tape
	ought to be a way to add N random tapes (rather than having to
	specify n-m)  

all-backups
	copy whole backup database to tape at end of each run

	recovery from reboots - if server running do-backups is
	booted, all-backups hangs forever (rsh screwed up).  this may
	be a problem with rsh - crops up elsewhere also.

	sort errors to the top of mail output? Or should we separate 
	the errors from the rest (somehow) and mail them to two separate
	lists?

	deal with parallel messages better in mail output?

	It would be cool if there were a way to scan a run for backups
	that failed, producing a list of chain, level, host and file
	systems, and pass that to all-backups to catch them up.   Maybe
	use a checklist as in Amanda.

	Add a way to do dumps that aren't recorded for restores in the
	database (and which do not update tardates or dumpdates).

show run
	host lists are often too long, and should be wrapped on the
	screen

move-tape
	would be nice to integrate it more closely with offsite, so 
	that it can keep you from moving tapes to the wrong offsite
	location. 

parallel backups
	deal with case where parallel incr backup fails from lack of
	space - mark as 'redo live', let all-backups do it straight
	onto tape at end of the whole mess. 

	Improve the copy to tape mechanism, make it faster.

backup-dump
	dump probably can't deal with level #'s > 9, maybe we should add
	limits to the stuff that reads backup.config?

	when we skip backups due to .chain problems, ought to note fact in 
	status in per host bu db.

backup-report
	create an ascii version?

getback
	It would be cool to be able to interactively search for a good
	backup sequence.  The program could give its best shot, and
	you could eliminate backups for whatever reason (like this
	one's offsite, or that one's on a tape that's lost) and have
	it deal.

	It would also be nice if it had a way of finding a backup
	sequence in multiple chains that "covers" the time elapsed
	between the full save and now, even if you couldn't use it for a
	real deleting style restore.

	Add ability to load several drives with tapes so that a full or
	interactive restore can run start to finish with no human
	assistance.  Should do some sort of locking so that restores on
	several file systems can proceed in parallel on the same host.

tape-check
	Make it more persistant.

Code
	use packages
	
	document expected globals

	Count arrays with @foo instead of $#foo in case $[ changes.

installation
	installation checking script

new facilities
	write an analysis program - coverage ok, how many tapes needed?

	write an assessment program that tells, for each file system,
	where "up to date" sets of backups can be found (eg, do I have
	an complete and up to date set for host X stored offsite
	somewhere?)

	more error checking - tapes w/o types, ids with wrong formats, 
	stuff that contains bad characters

	Ought to construct dumpdates and eliminate tardates and use
	data from the backup database instead.  Otherwise, duplication
	of data can lead to problems - if we do a level 2, then reuse
	that tape, the database will not contain that level 2 backup,
	but dumpdates or tardates will retain it, and the next level 9
	will be done as though the level 2 were still around.  If we
	recreate things from the database and use that as the final
	authority, this problem would disappear.  It would also make
	things somewhat simpler, since we would never need to read
	dumpdates/tardates, just write a fake one.

	Ought to reconsider what's in global.defs and move some of that
	stuff to backup.config (like the online repositories and default
	keep values).

	It would be nice if you could type a ? at any prompt and get
	a list of available choices.
