SUMMARY: freeware archiving software

Date: Fri Jan 27 1995 - 09:50:45 CST


I asked about freeware software for managing an archive. All responses
pointed to Amanda and I append one which included the README.

Thanks to all who replied.


Forwarded message:
> From mario.battu@CSELT.STET.IT Thu Jan 26 10:23:15 1995
> Date: Thu, 26 Jan 1995 09:23:15 +0100
> From: mario.battu@CSELT.STET.IT (Mario Battu')
> Subject: Re: freeware archiving software?
> To:
> Message-Id: <>
> X-Envelope-To:
> Content-Transfer-Encoding: 7BIT
> Hi John,
> I use a PD software, `Amanda'. It is available at
> Following is the related README file. Hope it will help you.
> --------------------------------------------------------------------------------
> Amanda 2.1 README
> making our work-in-progress available so that people can evaluate it and
> track its development. We do use this software in production at our site,
> but do not consider this to be a finished release.
> This is a beta-test release of Amanda, the Advanced Maryland Automated
> Network Disk Archiver. Amanda is a backup system designed to archive many
> computers on a network to a single large-capacity tape drive. This release
> is currently in daily use at the University of Maryland @ College Park
> Computer Science Department, backing up all the disks on all the
> workstations in the department: currently over 28 gigabytes of data across
> 321 filesystems on more than 128 workstations, using a single 5 Gigabyte
> Exabyte EXB-8500. Here are some features of Amanda:
> * written in C, freely distributable.
> * built on top of standard backup software: BSD Unix dump/restore, and
> later GNU Tar and others.
> * will back up multiple machines in parallel to a holding disk, blasting
> finished dumps one by one to tape as fast as we can write files to
> tape. For example, a ~2 Gb 8mm tape on a ~240K/s interface to a host
> with a large holding disk can be filled by Amanda in under 4 hours.
> * does simple tape management: will not overwrite the wrong tape.
> * for a restore, tells you what tapes you need, and finds the proper
> backup image on the tape for you.
> * recovers gracefully from errors, including down or hung machines.
> * reports results, including all errors in detail, in email to operators.
> * will dynamically adjust backup schedule to keep within constraints: no
> more juggling by hand when adding disks and computers to network.
> * can compress dumps before sending over net.
> * can optionally syncronize with external backups, for those large
> timesharing computers where you want to do full dumps when the system
> is down in single-user mode (since BSD dump is not reliable on active
> filesystems): Amanda will still do your daily dumps.
> * lots of other options; Amanda is very configurable.
> There is still a lot of work to do on Amanda 2, particularly in the areas
> of user documentation, portability, and improvement of protocols and
> algorithms.
> Amanda requires a host that is mostly idle at night, with a large capacity
> tape drive (e.g. an EXABYTE or DAT tape). This becomes the "master host".
> All the computers you are going to dump are the "slave hosts". The master
> host can also be a slave host.
> Amanda works best with a large "holding disk" partition on the master host
> available to it for buffering dumps before writing to tape. The holding
> disk allows Amanda to run backups in parallel to the disk, only writing
> them to tape when the backup is finished. Note that the holding disk is
> not required: without it Amanda will run backups sequentially to the tape
> drive. Running it this way kills the great performance, but still allows
> you to take advantage of Amanda's other features.
> As a rule of thumb, for best performance the holding disk should be larger
> than the dump output from your largest disk partitions. For example, if
> you are backing up some full gigabyte disks that compress down to 500 MB,
> then you'll want 500 MB on your holding disk. On the other hand, if those
> gigabyte drives are partitioned into 500 MB filesystems, they'll probably
> compress down to 250 MB and you'll only need that much on your holding
> disk. Amanda will perform better with larger holding disks. We use 800 MB
> for our holding disk.
> Actually, Amanda will still work if you have full dumps that are larger
> than the holding disk: Amanda will send those dumps directly to tape one at
> a time. If you have many such dumps you will be limited by the dump speed
> of those machines.
> The Amanda slave side requires only a relatively vanilla Unix system with
> sockets and inetd. The slave side ports easily to System V OSes that have
> a socket library, inetd, and support the TCP/IP protocols.
> The master host side currently also requires the ndbm database library and
> the SYSVIPC shared memory calls. I hope in the near future to remove
> Amanda's dependence on some of these features.
> Our master host is a Sparcstation running SunOS 4.1.
> I've compiled Amanda 2.1 (and run the slave side) on the following:
> SPARCstation, Sun3 running SunOS 4.1
> DECstation running Ultrix 4.2
> 486/33 EISA AT running BSDI BSD/386 v1.0
> DEC 3000/4xx Alpha running DEC OSF/1 1.2
> Additionally, I've compiled but not run Amanda 2.1 on the following
> machines (I have accounts on these but not sysadm access):
> SGI IP20 running IRIX 4.0.5F
> SPARCstation running SunOS 5.1 (Solaris 2.1)
> In the past I have also run Amanda on the following, but no longer test
> these architectures:
> Sun3, Sun2 running SunOS 3.2
> DECstation, VAXstation running Ultrix 3.1
> VAXstation running Torek-hacked BSD 4.3 Reno
> NeXT cube, NeXTstation running NeXT Mach v2
> The file docs/INSTALL contains installation instructions.
> The User's Guide is not yet ready, but there are man pages: in particular
> read the amanda(8) man page. Also, there are sample config files in the
> example/ subdirectory.
> I maintain a mailing list for those interested in Amanda. The mailing list
> is `'. To get on the list, please send mail to
> `'. If you'd like to hear about bugs and
> fixes, future releases, and questions/answers about Amanda, please join the
> list.
> Please take a moment to send me a note if you evaluate this package, even
> if you decide you don't want to use it. Let me know what you liked or
> didn't like about it. And, if you find and/or fix any bugs, or make any
> improvements, please send them back to me.
> Thank you,
> James da Silva
> May 1993
> You can contact me via:
> e-mail: (preferred)
> phone: +1-301-405-2751
> fax: +1-301-405-6707
> USPS: Department of Computer Science
> A.V. Williams Building
> University of Maryland
> College Park, Maryland 20742
> -------------------------------------------------------------------------------
> Mario Battu' - CSELT - CM/TE
> Via Reiss Romoli 274 - 10148 Torino - Italy
> Tel: +39 11 2285218
> Fax: +39 11 2287140
> E-mail:

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:15 CDT