+++ /dev/null
-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!
projects / debian / amanda / blobdiff