Bugs:

    garbage in at jobs

    show - show -v tape should show run, chain, level, date.

    show - show -v run should display expiration times and comments.  

    show - show tape-summary complains about free tapes that are
    offsite.  This doesn't mesh well with location stuff

    dd_prog defined on calling system - bundle into pmt and call 
    it from there?

    -M ignored when used with -C?

To Do Soon:

    change default for backup-report to 14 days

    document sybase-helper, add support for multiple servers

    all-backups - print group list expansion

    show - Create a "show free-tapes" command.

    Change show run to optionally display stuff from $output_dir.

    manual - add extra info in the installation section about using this
    on short name file systems, avoiding symlinks, running as non-root,
    using GNU tar, individual use.

    getback - 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.

    document the deadman switch stuff, backup timeouts in the ref manual.

    documentation - add a list of the warnings and errors and their
    meanings as an appendix of the manual.  Convert the manual to
    texinfo?  

    docs - document at times

    docs - describe default tags (backups.5)

    docs - add sections "about tags", etc.

    check results of close_db

    show run - host lists are often too long, and should be wrapped.

Probably To Do Soon:

    all-backups - using "-" with the groups doesn't work [need to think
    more about this - what syntax, other ops that might be useful, etc]

    "norecord" option for all-backups.  Do a backup, but don't update 
    dumpdates and mark the database entries so that it won't be counted
    as a normal backup (check-backups will ignore it, getback will list
    it in pick mode but ignore it in the others).

    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.

    Add support for write-once tapes (don't rewrite tape labels, or skip
    past first label and relabel the tape?)

    Allow wildcards in backups file?  Seems like a bad idea.  What If
    I had "host:/foo* none" and added a /foo6 that I DID want to
    backup?  check-backups wouldn't complain about it if I used
    wildcards...

    all-backups should create a checklist at the start
    ($db_dir/checklist/$runid) and remove things as their backup complete
    successfully. 

    all-backups should have an option to replay a checklist file.  

    all-backups, do-backups should be rewritten (simplified) to generate
    checklist and use only that to do backups.  everything else falls out
    in the wash, I think.  This would be easiest with a centralized 
    /etc/backups.

    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).

    error routine: args determine message, host, whether to reboot or not.  
    can execute "exit_hook" routines for cleanup.  includes host name if 
    run from something within all-backups.  variable verbosity: show
    doesn't need error, warning labels, but all-backups does.

    some sort of config thing that prevents certain dumb things from 
    being done: parallel backups at level 0, level 2 or 9 in single
    user, etc. 

    need an rsh wrapper that can report the exit status of the remote
    command (through stderr or some such) so that we can determine when
    dd fails, when do_backups fails, and so on.

Later

    cleaning cartridges

    /etc/default/filesys for SCO unix.

    Proxy backups - 'phost:rhost/filesys proxy' or something like
    that.

    Use logical names for tapes, and add ability to append backups to a
    tape that's been used.  That way, one could assign the name
    "this_weeks_backups" to a free tape and use that all week (in append
    mode) for dailies.

    Make something that allows you to add expirations to backups (which
    supercede the normal expirations imposed by the chain,level keep
    values).  Maybe "set-expiration expiration run [host [buid...]]"

    Make something that allows you to add comments.  "set-comment
    comment run [host [buid...]]"

    Use newenv in wrapper

    Use packages in the code, document globals, count arrays with @foo
    instead of $#foo in case $[ changes.

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

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

    Incorporate tape cleaning schedule in check-backups somehow?

    Improve error handling yet more, add more error info to the database?

    all-backups - Set a limit on the max number of simultaneous dumps to
    avoid congestion in parallel mode.

    Copy whole backup database to tape at end of each run.

    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.

    Dee-Jay like facilities for multiple tape support.

    Support stackers and jukeboxes.

    copy-backup type for offsite storage

    Integrate move-tape with offsite stuff so that it can detect/handle
    errors better.

    allow compressed backups to tape

    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.

    getback - 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.

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

    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?)

    Improve disk to tape copy performance

Think About
----- -----

    Schedule schemes that can be applied to different file systems?

    Make tape-check more persistant?

    Ascii version of backup-report?
