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