From HOWTO.FAQ.DO-DONT (The following section is in its original form as written by Albert Fluegel, and is included in the software documentation under the file HOWTO.FAQ.DO.DONT).
A33: Admittedly i don't know much about amanda. Here's what i extracted
from an E-Mail-talk with someone, who had to report a comparison
between them (partially it's not very fair from both sides, but i
think everyone can take some clues from it and be motivated to ask
further questions), it starts with the issues from an amanda user's
view (> prefixes my comments on the items):
DESCRIPTION Amanda afbackup
Central scheduler which attempts to smooth the daily
backups depending on set constraints, can be interrogated. YES NO
> (afbackup does not implement any scheduler, backups can be
> started from a central place, afbackup does NOT force the
> types of a backup, e.g. make incremental backup, if there
> is not much space on tapes left)
Sends mail when a tape is missing or on error,
while in backup. YES YES
Pre-warns of a possible error condition (host not
responding, tape not present, disk full) before backup. YES PARTIALLY
> (afbackup implements a connection timeout for remote
> starts, an init-command for server startup and an
> init-media-command, that is called, whenever a media
> should be loaded, can be configured, that may test for
> problems in advance)
If no tape available, can dump to spool only. YES NO
> (No (disk) spool area is maintained. Backup media can
> be filesystems, thus also removable disks.)
Normally dumps in parallel to a spool disk, then to tape,
for efficiency. YES N/A
> (afbackup can dump in parallel to server, clientside
> protocol optimizer for efficiency, no spool area s.a.)
Supports autochanger in a simple way (can browse for a
tape, but will not remember the pack's content, this can
be a feature) YES YES
> (Don't know, what is meant here. Autochanger is supported
> in a simple way before 3.3, enhanced in 3.3, including a
> media database)
When using tar backups, indexes are generated which can be
used to get back the data. YES YES
> tar is not used (see below), indexes are maintained
An history of the backups is available, Amanda can decide
the restore sequence, e.g. if the last full dump is
not available, go back in history, using incremental
backups. YES Y/N
> (A before-date can be supplied, but no automatic
> walk-back in history)
Backup format can be simple tar. YES YES(discouraged!)
> I decided not to use the tar packing format as it lacks
> several features, that i consider absolutely necessary,
> most notably
> - per-file compression/preprocessing
> - command output packing
> - extended include/exclude
Amanda will interrogate the client and tell him to do a 0,
1 or other level backup, depending on spool size, backup
size, etc. YES manual
Can print tape's content labels. YES N/A
> The label of an afbackup tape does not contain tape
> contents. These are located in the index file(s). Those
> can be printed easily, also only a certain end user's
> files. This feature of amanda has in my opinion one of
> the heaviest limitations of amanda (filesystem size
> <= tape capacity) as consequence
Can print weekly tape content summary. YES N/A
Can print graphical summary of backup time. YES NO
Restorer through an intelligent command line. YES YES, also GUI
Backups can be stored and/or transmitted compressed. YES YES
> clientside compression is one of afbackup features.
> Thus transmitted data is already compressed.
Backups can be encrypted during transport or on disk. NO(1) BOTH
> ssh may be used to tunnel the connection, the contents
> of the stored files can be preprocessed in any arbitrary
> way, also encrypted
Can backup file system whose size is bigger than a tape. NO(2) YES
> Why not ?
Backups file system to tape if bigger than spool, or to
spool, or no backup. TAPE(3) N/A
> No spool area is maintained. To achieve good performance,
> ring buffers are created on client and server, client-/
> server-protocol tries to optimize throughput.
Can append to tape. NO(4) YES
> Normal append is supported since ever. As of version
> 3.2.6 full append mode is implemented, i.e. also, if
> an administrator has requested to write to another
> tape now, the current one will be appended to, if there
> is no space left on any available tape. Since 3.2.7
> there is also a variable append mode making the server
> append to any supplied tape having remaining space
> and not being in read-only state
Supports a tape verify option (just verifying the tape) YES NO
> Don't see the use of this.
Supports a data verify option (compare with fs). NO(5) YES
> (very pedantic)
Graphical, web or menu-based configuration. NO GUI,CL
> CL means: command line program
Graphical, web, menu-based or command line restore. CMD GUI,CL
Can restore individual file automatically to most recent. YES YES
Can restore individual file to specified date. ??? YES
Protects a client host from others reading its data. NO YES
> Client access can be restricted on cartridge set base
Supports disaster recovery. NO YES
mt and tar commands are easy to use to recover by hand,
with the printed weekly summary. YES YES
> No weekly summary, minimum restore info posted to admin.
> Manual recover is possible, explained in FAQ
License. BSD GPL
Can backup MS-WINDOWS data ? YES via SMB-mount
Now for the items from an afbackup preferring user's view (> prefixing
the comments of an amanda user, >> prefixing my thoughts on the comment):
End User Restore NO YES
> Amanda doesn't support end user restore
Data safety (client/server authentication through a
challenge-response, secret key required, real client-
server system, only server can access tape devices) NO YES
> Amanda does NOT have it, which makes it a problem.
> There ARE extensions, for example for using Kerberos
> (export problems), or ssh (other class of problems).
Database backup support (by saving arbitrary dump
command output) NO YES
> No, Amanda requests it to be sent to a file, first.
>> So e.g. for an online database backup a huge
>> temporary disk space is required
Raw device contents backup NO YES
Using full tape capacity NO YES
> No, Amanda insists on changing tape everyday (which
> makes sense for tape's security reason, but doesn't make
> too much sense if you waste a lot of precious storage
> --- Amanda counter-balances this with its intelligent
> scheduling algorithm).
Multi-Stream (several clients backup to a server in
parallel) optional YES? YES
> Multiple clients can backup to the spool, and then to
> tape. There is no tape multiplexing or anything like
> this.
Several servers per client can be configured, selected
by availability and load, transparent during restore NO YES
Per file preprocessing (for safety, if the whole stream
is e.g. compressed and a single bit is wrong during restore
all the rest is lost) NO YES
> Amanda compresses the whole backup if requested.
>> (AF's comment: crazy in my opinion)
Secure remote start option (not requiring trusted
superuser remote access) NO YES
> Backups are always started centrally. You can decide at
> which time the *whole* thing starts.
>> (AF's comment: also possible with afbackup, in a
>> secure fashion)
End user restore (already mentioned above) only of his
own files NO YES, also GRAPHICAL
Server and client can easily change (e.g. move tape to
other machine or restore to different client) Y/N YES
> Amanda stores the indexes on the server, so the client
> can easily change. However, the server can only change
> provided you restore the indexes.
Duplicate tapes (make clones) (also automatically) NO YES
> Not supported (you can make copies, but they won't be
> considered as though).
Store in filesystems, maybe removable disks NO YES
(may call it virtual cartridges)
Cartridges can be set to read-only mode ??? YES
> Probably no.
Maintain arbitrary cartridge sets (e.g. to switch daily,
weekly or for type or backup) YES YES
> Yes. Amanda's scheduler is probably better than afbackup's.
>> (AF's comment: i didn't speak of the scheduler here,
>> but of the option to combine tapes to sets with
>> common properties, e.g. access restrictions)
1.2 Amanda issues
(1) Support for security is low (a this time mainly based on host name
security, without encryption). Kerberos or ssh encryption are possible,
but not easy to set up/well tested, and have some exportation or
patent issues.
(2) Cannot backup a file system whose size is bigger than a tape, without
splitting the fs with regexps.
(3) Backups bigger than the spool size are dumped to tape, which is slower
and may cause tape trashing.
(4) Only if the tape is disabled, in that case the system dumps to spool,
and then a flush can be done. But cannot really *append* to a tape.
Authors say it's a feature: the tape is not used for more than one day,
this guarantees medium integrity, and the scheduler makes this
worthwhile.
(5) Verify option would have to be implemented.
1.2 afbackup issues
To be implemented in the next versions:
(1) Jukebox support (several tape devices sharing a set of tapes), coming
not too soon, depends on the time and support i get for ongoing
development by my employer and customers.
Not planned to be implemented:
- Maintaining a spool area on disk
- Distinguished scheduler for the backup system (crond is in place, so ...)