
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.

* Support for Solaris 2.[5-6]*'s ufsdump -S switch (for estimates)
should be added.

* 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!

* A User's Manual.  We need to better document the installation and day to
day running of Amanda, including sections that help operators diagnose and
fix problems, and provide tips and techniques.

* 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
will only work if you only use GNU tar for your backups).  Amanda
finishes fast enough that we could read the tape back after the dumps
are done, to be sure all the files on it can be read.  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.

* 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!
