4 These are items that we are planning to address, OR which we would
5 like to see happen sometime in the future. They appear in vaguely
6 decreasing order of priority and feasibility. Of course, we aren't
7 promising to deliver anything, but it's a reasonable bet that at least
8 the first few things will get done.
10 You may find more up-to-date information in the Amanda Ongoing
11 Projects page, http://www.amanda.org/ongoing.html.
13 If you have any ideas about any of the following, please send an
14 e-mail note to amanda-users@amanda.org or amanda-hackers@amanda.org.
16 * Setting tapecycle to infinity (which is reasonable for archive
17 configurations) will cause planner to crash, because it will try to
18 allocate a huge memory block. The current workaround is to use a
19 finite tapecycle; a correct fix would involve dynamically growing the
20 structure allocated by planner as needed.
22 * amcheck and amadmin should check whether the user that invoked it is
23 the user configured to run amanda.
25 * Amanda should be able to retry failed backups in a single run. So,
26 if backup fails because of active filesystems or lack of memory,
27 amanda could throw the failed backup away and run it again, instead of
28 trying it again in the next run only.
30 * SAMBA should be treated as a different backup program, not as
31 GNUTAR, because it cannot handle dump-style incrementals (as of
32 samba-1.9.17p5). We should be able to back up subdirectories of
33 shares (using the -D switch). It should be possible to specify the
34 samba user, instead of assuming user `backup'. /etc/amandapass could
35 be specified (in a backward-compatible way) as follows:
37 // password [-U default_user] [[-W] default_workgroup]
38 //hostname password [-U default_user] [[-W] default_workgroup]
39 //hostname/sharename[/subdir] password [-U default_user] [[-W] default_workgroup | -W-]
44 //win-srv XXXX -U srv-backup
45 //win-srv/F$ XXXX -U backup
46 //other XXXX -U amanda -W-
48 would be equivalent to:
50 //win-client1/C$ XXXX -W Win32-LAB
51 //win-client2/C$ XXXX -W Win32-LAB
52 //win-srv/C$ XXXX -U srv-backup -W Win32-LAB
53 //win-srv/D$ XXXX -U srv-backup -W Win32-LAB
54 //win-srv/F$ XXXX -U backup -W Win32-LAB
55 //other/C$ XXXX -U amanda (no domain specified)
57 * When a disk is configured to skip-incr, it will present no estimate
58 errors every day except the day it is scheduled for a full dump.
59 Besides, it will never be promoted, because no estimate is requested
60 on such days. Maybe we should request a full estimate anyway, and
61 skip incrementals after analysis takes place.
63 * It should be possible to re-generate databases and indexes from
66 * amanda should install man-pages for installed programs only.
68 * we should provide for client-side configuration files, to specify
69 default tape server, index server, and perhaps even pathnames to some
72 * amidxtaped should be able to deal with tape changers, and it should
73 check whether it has the appropriate tape before reading any backup
74 files from it. It should also be possible to configure whether
75 amidxtaped should decompress the dump stream or not (so amrecover
76 could decompress it locally). Suggested by Chris Jones
77 <cjones@honors.montana.edu>
79 * Ports to non-Unix platforms, specifically Macs and PCs. The hooks
80 are in the Amanda protocol to support non-dump backup programs, but
81 no-one has volunteered to implement the client side. Sorry, I'm not a
84 * More tools in Amadmin. The administrator should be able to look at
85 the database in various ways. Adding / deleting / moving disks and
86 hosts should be done through amadmin instead of editing the disklist
87 directly. This will allow Amanda to do some sanity checks for the
88 operators, to make sure permissions are set up right, etc.
89 You should be able to force full dumps for nights other than
90 tonight. Rather than one command at a time on the command line,
91 amadmin could be a little shell with a help facility (ala ckermit or
92 gnuplot, if you've seen those).
94 * A tape-verify pass after the Amanda run (we already have one, but it
95 doesn't work with dump as well as it does with GNU tar). Perhaps
96 taper could calculate a CRC for each file and store that in the
97 database, to be checked by the verifier.
99 * More sophisticated tape management. Should Amanda track tapes
100 globally, counting the number of times tapes were used, and
101 recommending retirement for tapes at the appropriate time? I'm not
102 convinced, but I'm interested in the subject. What do you think? How
103 does your site deal with this?
105 * Automatically notice that disks have moved around. This is a
106 nice-to-have but don't hold your breath. It would be nice if planner
107 (via sendsize) would notice and optionally add/delete filesystems as
108 they appear/disappear from the fstab.
110 * Automatically notice that external dumps have been done. Sendsize
111 could also notice if a filesystem was dumped externally to Amanda.
112 Right now the planner assumes that the incrementals it is doing are
113 relative to the full dumps it is doing. If someone does a full dump
114 of one of its filesystems (and writes /etc/dumpdates) outside of
115 Amanda, data could be lost. I think Sun's Backup-Copilot handles this
118 * Support for client-initiated backups might be interesting, but the
119 server would have to keep listening for clients backup requests for a
120 configurable period of time. This could be used to back up secure
123 * Backups to remote tape devices (i.e., not in the main amanda
124 server), as well as to filesystems, should be supported. Instead of
125 hard-coding the interface with tape devices in amanda, there should be
126 a higher level interface that allowed different storage devices to be
127 used. Amanda should also be able to retain backups in disk, even
128 after they are taped, for faster restore of recently backed up data.
129 It should also be possible to store a single backup in multiple tapes,
132 * We need a better protocol between the driver and dumpers.
133 - setup terminated (to not start to dump onn the same host at the
135 - dumper should ask for holding space if the dump is larger that
136 estimated. It is needed if we want to write a dump on multiple
138 - driver should ask periodicaly if the dumper is still alive (in case
141 * From: "John R. Jackson" <jrj@gandalf.cc.purdue.edu>
142 Here's an idea for someone to think about. What if we made the
143 "length" in a tapetype definition always be the "no compression"
144 value? Then change the dumptype "compress" option to accept
145 "hardware" as another type (ala "client" and "server") and let planner
146 do its normal thing with that information (including "comprate", which
147 at the current default of 50% is the usual first guess for hardware
149 This would make setting the tape length value less confusing, and
150 make the tapetype program easier to run. You could even get more
151 accurate planning than what is currently available by setting the
152 comprate to what you know the data is like on a dumptype by dumptype
155 * We could have an autoflush flag to tell amdump to automatically
156 flush the contents of the holding disk to tape. We'd have to figure
157 out a way to tell planner to take that space into account.
159 * Insert your favorite feature here, and send us e-mail telling about
160 what you'd like to see! Of course, we can't please everyone, and
161 can't implement everything, but we are very interested in how other
162 sites operate so that we can find common ground and learn from each
projects / debian / amanda / blob