Amanda WISHLIST
---------------

These are items that we are planning to address, OR which we would
like to see happen sometime in the future.  They appear in vaguely
decreasing order of priority and feasibility.  Of course, we aren't
promising to deliver anything, but it's a reasonable bet that at least
the first few things will get done.

You may find more up-to-date information in the Amanda Ongoing
Projects page, http://www.amanda.org/ongoing.html.

If you have any ideas about any of the following, please send an
e-mail note to amanda-users@amanda.org or amanda-hackers@amanda.org.

* Setting tapecycle to infinity (which is reasonable for archive
configurations) will cause planner to crash, because it will try to
allocate a huge memory block.  The current workaround is to use a
finite tapecycle; a correct fix would involve dynamically growing the
structure allocated by planner as needed.

* amcheck and amadmin should check whether the user that invoked it is
the user configured to run amanda.

* Amanda should be able to retry failed backups in a single run.  So,
if backup fails because of active filesystems or lack of memory,
amanda could throw the failed backup away and run it again, instead of
trying it again in the next run only.

* SAMBA should be treated as a different backup program, not as
GNUTAR, because it cannot handle dump-style incrementals (as of
samba-1.9.17p5).  We should be able to back up subdirectories of
shares (using the -D switch).  It should be possible to specify the
samba user, instead of assuming user `backup'.  /etc/amandapass could
be specified (in a backward-compatible way) as follows:

// password [-U default_user] [[-W] default_workgroup]
//hostname password [-U default_user] [[-W] default_workgroup]
//hostname/sharename[/subdir] password [-U default_user] [[-W] default_workgroup | -W-]

So that:

// XXXX -W Win32-LAB
//win-srv XXXX -U srv-backup
//win-srv/F$ XXXX -U backup
//other XXXX -U amanda -W-

would be equivalent to:

//win-client1/C$ XXXX -W Win32-LAB
//win-client2/C$ XXXX -W Win32-LAB
//win-srv/C$ XXXX -U srv-backup -W Win32-LAB
//win-srv/D$ XXXX -U srv-backup -W Win32-LAB
//win-srv/F$ XXXX -U backup -W Win32-LAB
//other/C$ XXXX -U amanda  (no domain specified)

* When a disk is configured to skip-incr, it will present no estimate
errors every day except the day it is scheduled for a full dump.
Besides, it will never be promoted, because no estimate is requested
on such days.  Maybe we should request a full estimate anyway, and
skip incrementals after analysis takes place.

* It should be possible to re-generate databases and indexes from
tapes.

* amanda should install man-pages for installed programs only.

* we should provide for client-side configuration files, to specify
default tape server, index server, and perhaps even pathnames to some
programs.

* amidxtaped should be able to deal with tape changers, and it should
check whether it has the appropriate tape before reading any backup
files from it.  It should also be possible to configure whether
amidxtaped should decompress the dump stream or not (so amrecover
could decompress it locally).  Suggested by Chris Jones
<cjones@honors.montana.edu>

* Ports to non-Unix platforms, specifically Macs and PCs.  The hooks
are in the Amanda protocol to support non-dump backup programs, but
no-one has volunteered to implement the client side.  Sorry, I'm not a
Mac programmer!

* More tools in Amadmin.  The administrator should be able to look at
the database in various ways.  Adding / deleting / moving disks and
hosts should be done through amadmin instead of editing the disklist
directly.  This will allow Amanda to do some sanity checks for the
operators, to make sure permissions are set up right, etc.
  You should be able to force full dumps for nights other than
tonight.  Rather than one command at a time on the command line,
amadmin could be a little shell with a help facility (ala ckermit or
gnuplot, if you've seen those).

* A tape-verify pass after the Amanda run (we already have one, but it
doesn't work with dump as well as it does with GNU tar).  Perhaps
taper could calculate a CRC for each file and store that in the
database, to be checked by the verifier.

* More sophisticated tape management.  Should Amanda track tapes
globally, counting the number of times tapes were used, and
recommending retirement for tapes at the appropriate time?  I'm not
convinced, but I'm interested in the subject.  What do you think?  How
does your site deal with this?

* Automatically notice that disks have moved around.  This is a
nice-to-have but don't hold your breath.  It would be nice if planner
(via sendsize) would notice and optionally add/delete filesystems as
they appear/disappear from the fstab.

* Automatically notice that external dumps have been done.  Sendsize
could also notice if a filesystem was dumped externally to Amanda.
Right now the planner assumes that the incrementals it is doing are
relative to the full dumps it is doing.  If someone does a full dump
of one of its filesystems (and writes /etc/dumpdates) outside of
Amanda, data could be lost.  I think Sun's Backup-Copilot handles this
well.  We should too.

* Support for client-initiated backups might be interesting, but the
server would have to keep listening for clients backup requests for a
configurable period of time.  This could be used to back up secure
hosts, for instance.

* Backups to remote tape devices (i.e., not in the main amanda
server), as well as to filesystems, should be supported.  Instead of
hard-coding the interface with tape devices in amanda, there should be
a higher level interface that allowed different storage devices to be
used.  Amanda should also be able to retain backups in disk, even
after they are taped, for faster restore of recently backed up data.
It should also be possible to store a single backup in multiple tapes,
for redundancy.

* We need a better protocol between the driver and dumpers.
- setup terminated (to not start to dump onn the same host at the
  same time).
- dumper should ask for holding space if the dump is larger that
  estimated.  It is needed if we want to write a dump on multiple
  holding disks.
- driver should ask periodicaly if the dumper is still alive (in case       
  the dumper hang).

* From: "John R. Jackson" <jrj@gandalf.cc.purdue.edu>
Here's an idea for someone to think about.  What if we made the
"length" in a tapetype definition always be the "no compression"
value?  Then change the dumptype "compress" option to accept
"hardware" as another type (ala "client" and "server") and let planner
do its normal thing with that information (including "comprate", which
at the current default of 50% is the usual first guess for hardware
compression).
  This would make setting the tape length value less confusing, and
make the tapetype program easier to run.  You could even get more
accurate planning than what is currently available by setting the
comprate to what you know the data is like on a dumptype by dumptype
basis.

* We could have an autoflush flag to tell amdump to automatically
flush the contents of the holding disk to tape.  We'd have to figure
out a way to tell planner to take that space into account.

* Insert your favorite feature here, and send us e-mail telling about
what you'd like to see!  Of course, we can't please everyone, and
can't implement everything, but we are very interested in how other
sites operate so that we can find common ground and learn from each
other.  Thanks!
