2 Chapter 18. AMANDA WISHLIST
3 Prev Part IV. Various Information Next
5 -------------------------------------------------------------------------------
7 Chapter 18. AMANDA WISHLIST
19 <martinea@iro.umontreal.ca>
23 XML-conversion; Additions and Updates
29 Refer to http://www.amanda.org/docs/wishlist.html for the current version of
31 This is a major update.
32 These are items that we are planning to address, OR which we would like to see
33 happen sometime in the future.
34 They appear in random order.
35 Of course, we aren't promising to deliver anything.
36 This document can be found at http://www.amanda.org/docs/wishlist.html.
37 You may find more up-to-date information at http://www.amanda.org/ongoing.php.
38 If you have any ideas about any of the following, please send an e-mail note to
39 mailto://amanda-users@amanda.org or mailto://amanda-hackers@amanda.org.
40 Jean-Louis Martineau, Stefan G. Weichinger,
44 * Samba: Ports to non-Unix platforms, specifically Macs and PCs. The hooks are
45 in the AMANDA protocol to support non-dump backup programs, but no-one has
46 volunteered to implement the client side. sgw: Mac OS X is able to run the
47 client, so only the PC is left, and I suggest that we should go the SAMBA-
48 way, I think. Samba is working well, is documented and developed further, so
49 I think this will be a stable path to go and support. And people don't need
50 to compile/install anything on their Win-boxes, just add a user and shares
54 * Samba: Samba should be treated as a different backup program, not as GNUTAR,
55 because it cannot handle dump-style incrementals.
58 * Samba: multiple exclusion-patterns. Since Samba 3.0.3 smbclient supports the
59 usage of multiple exclude-patterns. This would enable AMANDA to exclude more
60 than one pattern per SMB-share, allowing to exclude pagefile.sys AND the
61 registry-files, for example.
64 * Instead of hard-coding the interface with tape devices in AMANDA, there
65 should be a higher level interface that allowed different storage devices to
66 be used. AMANDA should also be able to retain backups in disk, even after
67 they are taped, for faster restore of recently backed up data. It should also
68 be possible to store a single backup in multiple tapes, for redundancy.
71 * We need a better protocol between the driver and dumpers. setup terminated
72 (to not start to dump on the same host at the same time). driver should ask
73 periodicaly if the dumper is still alive (in case the dumper hang).
76 * image span / multiple tape. John Stange <building@nap.edu> is working on it.
77 His patch will very likely go into a development-branch.
80 * retry failed backups in a single run. If backup fails because of active
81 filesystems or lack of memory, AMANDA could throw the failed backup away and
82 run it again, instead of trying it again in the next run only.
85 * Support for client-initiated backups might be interesting, but the server
86 would have to keep listening for clients backup requests for a configurable
87 period of time. This could be used to back up secure hosts, for instance.
90 * Backups to remote tape devices (i.e., not in the main AMANDA server), as well
91 as to remote filesystems should be supported.
94 * multi-tape : AMANDA should be able to write to many tape at the same time.
95 Need some criteria to select which dump should go on which tape? By level,
99 * A way to tell if some dump must be done before/after some other. (eg. DLE X
100 must be started after DLE Y is started/dumped/taped).
103 * Write to tape and holding disk in parallel (For dump to tape), the dump to
104 tape could be started first, while doing some dump to holding disk.
107 * Autoflush to tape while doing estimate.
110 * Keep files on holding disk after taped, that will permit faster recovery
111 because they will be from holding disk, these dump will be erase when the
112 same is needed for newer dump.
119 This script writes to disks which can be accessed in a parallel way (contrary
120 to the serial access to tapes). This could enable AMANDA to do writes and
121 reads to several vtapes in parallel (e.g. doing an amrestore while the
122 regular amdump is running).
123 It would be helpful to have a script which generates the needed directory-
124 structure for a given chg-disk configuration. This script should test for
125 valid settings (using amgetconf to get the values out of amanda.conf), create
126 the necessary slot-directories and label the new vtapes by using amlabel.
127 (there are drafts available already)
130 * amrecover should be able to set and "rewind" the correct vtape. Currently it
131 is necessary to do this manually in another tty.
134 * It should be possible to re-generate databases and indexes from tapes.
137 * AMANDA could append meta-data like databases and indexes to tape, so that
138 each tape contains its own current indexes and everything to rebuild the
142 * AMANDA should install man-pages for installed programs only.
145 * We should provide for client-side configuration files, to specify default
146 tape server, index server, and perhaps even pathnames to some programs.
149 * It should be possible to configure whether amidxtaped should decompress the
150 dump stream or not (so amrecover could decompress it locally).
154 It should read degraded schedule and write which are delayed.
155 It should print number of byte written to tape for the current flush.
156 The taper should write a file with a byte count for the current files (every
157 GB) and amstatus could read it.
158 It could report the expected time before the dump finishes.
161 * amverify/ amverifyrun:
162 It should look at the log file and compare the result.
166 should cd, add, remove, ... with a path with glob or regex (cd o*/linux)
167 find [file] # where is that file in the current DLE? (I don't know the path)
168 when [file] # when was this file dumped?
169 parsing accept '\': cd HP890\ Color
174 A new script to kill all process on client and server
177 * Convert datestamp to timestamp everywhere, that will permit many run a day,
178 and be able to recover them easily. it's already done for holding disk.
179 (That's a big job, AMANDA use the datestamp sometimes as INT, sometime as
180 CHAR*, converting every thing to CHAR* is probably not very difficult, what
181 will be difficult will be to stay compatible with the old datestamp.)
184 * Enhance the protocol between client-server to allow white-space and any
185 character in DLE/exclude/include.
188 * More tools in amadmin. The administrator should be able to look at the
189 database in various ways. Adding / deleting / moving disks and hosts should
190 be done through amadmin instead of editing the disklist directly. This will
191 allow AMANDA to do some sanity checks for the operators, to make sure
192 permissions are set up right, etc.
193 Suggested by Chris Jones <cjones@honors.montana.edu>.
196 * You should be able to force full dumps for nights other than tonight. Rather
197 than one command at a time on the command line, amadmin could be a little
198 shell with a help facility (ala ckermit or gnuplot, if you've seen those).
201 * A tape-verify pass after the AMANDA run (we already have one, but it doesn't
202 work with dump as well as it does with GNU tar). Perhaps taper could
203 calculate a CRC for each file and store that in the database, to be checked
207 * More sophisticated tape management. Should AMANDA track tapes globally,
208 counting the number of times tapes were used, and recommending retirement for
209 tapes at the appropriate time?
212 * Automatically notice that external dumps have been done. Sendsize could also
213 notice if a filesystem was dumped externally from AMANDA. Right now the
214 planner assumes that the incrementals it is doing are relative to the full
215 dumps it is doing. If someone does a full dump of one of its filesystems (and
216 writes /etc/dumpdates) outside of AMANDA, data could be lost. Sun's Backup-
217 Copilot handles this well. We should too.
220 * What if we made the "length" in a tapetype definition always be the "no
221 compression" value? Then change the dumptype "compress" option to accept
222 "hardware" as another type (ala "client" and "server") and let planner do its
223 normal thing with that information (including "comprate", which at the
224 current default of 50% is the usual first guess for hardware compression).
225 This would make setting the tape length value less confusing, and make the
226 amtapetype program easier to run. You could even get more accurate planning
227 than what is currently available by setting the comprate to what you know the
228 data is like on a dumptype by dumptype basis. Suggested by John R. Jackson
229 <jrj@gandalf.cc.purdue.edu>.
232 * The way to specify the schedule should be redesigned, all those strategy
233 (standard, nofull, noinc, incronly, force-full) and options (skip-full, skip-
235 We should have two options, one for full dump and one for incrementals.
236 full [AUTOMATIC | SKIP | NOTIFY | FORCE | FIXED]
237 incr [NONE | BUMP | NOBUMP]
238 with the following values:
239 AUTOMATIC: follow AMANDA scheduling (allow promoted and delayed)
240 SKIP : full dump are done externally on an fixed schedule, dump nothing when
241 a full is due (like skip-full).
242 NOTIFY : full dumps are done externally, but are notified with the NOTIFY
243 command ( amadmin <conf> notify <host> <disk>).
244 FORCE : full dumps are done only with the FORCE_FULL command.
245 FIXED : do full dumps on a fixed schedule (like skip-incr).
246 NONE : don't do incremental dumps.
247 BUMP : allow incremental dumps to bump.
248 NOBUMP : do not allow incremental dumps to bump.
251 * Remove all compiled options that can be moved to a (the?) configuration file.
252 (eg. GNU tar path, if configure can't find it, AMANDA should be able to use
253 GNU tar if the path is specified on a client config file) Many people would
254 like this, it would maybe also bring us closer to the possibility of working
259 There is pretty much going on with the AMANDA-docs. The docs have been
260 converted to Docbook/XML and form the new module xml-docs in the AMANDA-CVS-
262 The FAQ-O-Matic could be replaced by a Wiki. Suggested by Harlan Stenn
263 <Harlan.Stenn@pfcs.com>.
264 The xml-docs need more formatting and reviewing.
265 The tapetypes from the FOM should go into the XML-docs.
266 The docs would benefit from adding some illustrations.
268 The WISHLIST should get shortened.
269 -------------------------------------------------------------------------------
272 Chapter 17. Collection of the top ten Home Chapter 19. AMANDA Survey Results
273 AMANDA questions. And answers.
projects / debian / amanda / blob