Performanceof a Parallel Network BackupManager Jamesda Silva, Olafur Guðmundsson,Døniel Mossé - Departmentof ComputerScience, University of Maryland ABSTRACT

The adventof inexpensivemulti-gigabyte tape driveshas madepossible the completely automatedbackup of many dozensof networkedworkstations to a single tape. One pioblem that arises with this schemeis that many computerscannot backup theiì disks óver the network at more than a f¡action of the tape'srated speed. Thus, running overnightbackups sequentiallycan takewell into the next day. . W9 havedeveloped a parallelbackup manager named Amanda that solvesthis problem by runninga numberof backupsin parallelto a holding disk, then using a multi-bufier copy schemeto transfer the backupsto the tape at the full rated tape speed. Amanda usis accurateestimates of current backup sizes as well as historical information about backup ratesso as to schedulebackups in parallelwithout swampingthe networkor overrunningthä holdingdisk or tape. Locally,we useAmanda to back up 11.5gigabytes of datain over 230 filesystemson more than 100 workstations,using a single 2 gigabyte8mm tape drive, taking two to three hourseach night. This paperdiscusses the architectureand perfórmanceof Amãnda.

Bacþround/ very well; evencomputer-literate users just don't do backups Until a few years ago, the backup medium of on a regularbasis. choice for most large sites was the A common solution that most sites have 'J..14" 9 track reel-to-reel tape, while cartrìdge tapes were adoptedis a datalessworkstation model, in which all (andstill are)popular with smallersystems. Storage user data is stored on file serverswith small local capacitiesfor 9-track and cartridgetapes vary from disks to hold temporary files and frequently used about 40 to 200 Megabytes.These tape systemsare binaries, or even a diskless workstation model, often of smaller capacity than the disk subsystems where the workstationshave no disks at all[1]. they are backing up, requiring an operatorto feed Thesenetwork organizations require fast file servers multiple tapesinto the drive for a full backupof the with large disks,and generateheavy network traffic. disks. Our department,on the other hand,has always This problem has had a big influenceon site useddatafull workstations,where all user data, tem- systemadministration. Sites with only a few large porary files and some binaries, are stored on the timesharingsystems or file serverscan anangeback- workstations. File servers only provide shared ups by operatorsat scheduledtimes, but the coordi- binaries.This allows the use of smaller"filesewers, nation of backupsof a large numberof workstations with smallerdisks. A big advantageof this modelis on a network is more difficult. Requiringusers to political; userstend to want their own disks with do their own backupsto cartridgetapes doesn't work their own dataon their own desks.They don't want to deal with a central authority for spaceor CpU cycles,or be at the whim of somefile serverin the basement. @ parrby contractDASc6o- 87--0066from the U. S. Army SttategicDefense Since most file writes are local, performance can be betteras we avoid Çommlndto the Departmentof ComputerScience and by the expensivesynchronous RomeI¡bs andthe DefenseAdvanced Research projecti NFS file writes and network traffic is lower. With Agency under contract F30602-90.C.0010to the the datafull model we are able to have each UMIACS,both at theUniversity of Maryland.The views, fileserversupport over 40 machinesif needed,while opinions,and/or findings contained in thisreport are those in datalessand disklessenvironments only special- of the author(s)and should not be interpretedas ized fileserverscan support more than 20 worksta- representing the offrcial policies,either expressedor tions. The big disadvantageis the difficulty of implied,of the Department of Defense,DARPA RL, or managingand backing up all the datafull worksta- the U.S. Government, unlessso designatedby other uons. officialdocumentation. facilities were provided in partby NSFgranr CCR-8811954

'92 Summer USENIX - June 8-June12,1992 - SanAntonio, TX 217 Performanceof a Parallel Network Backup Manager da Silva. ...

The anival of inexpensive gigabyte Digital able to keepthe tapewriting and disk readingsimul- Audio Tape (DAT) and 8mm tape technologyhas taneously. Once put*,tphas decided which files to changedthe situation drastically. Affordable disks back up, it producesdata at a very steadyrate for are now smaller than affordabletape drives, allow- the durationof the backup. We have measuredthe ing the backupof many disks onto a single gigabyte dump rates over the network for various computer tape. It is now possibleto back up all the worksta- æchitectures;some typical valuesfor full dumpsare tion disks at a site over the network onto a single shown in Table 1. These numberswill dependon 8mm tape. disk speedsand compressionrates as well as archi- Now that the spaceproblem is solved,the new tecture,so your mileagewill vary. problem is time. Backing up workstationsone at a To get more data onto backuptapes, it is often time over the network to tape is simply too slow, advantageousto compressthe backupdata. Table 1 Many workstationscannot produce dump data as also showsthe resultingdump rateswhen the dump quickly as tapescan write[2]. For example,typical output is run throughthe UNIX coMpREssprogram dump rates (both full and incremental)on our net- before being sent over the network. The effective work rangebetween about SVo to 70Voof the rated dump rate column is the originøl dump size divided 246l

218 Summer'92 USENIX- June8.June 12,1992 - SanAntonio, TX da Silva,... Performanceof a Parallel Network Backup Manager within [Vo. Achieving Rated Tape Speed Like most backup systems,DUMr does have We measuredthe transferrates to tape by someproblems correctlybacking up filesystemsthat repeatedlywriting a memorybuffer on a systemwith are being modified while the backupis occuring[4]. no load,that is, writirig in a tight loop as fast as the Some sites instead use file-orientedprograms, like (OS) and tape would allow. TARor cPIo, but theseprograms have their own set Achieving that same rate when transfening dump of problems[S]. image files from the disk to the tape requiressomè sort of multi-buffer Performanceof GigabyteTape Drives techniqueto keepthe tapewrit- ing andthe disk readingat the sametime. Thereare The two competinggigabyte-class tape techno- severalways to do this. logies are the 8mm Exabyte CartridgeTãpe drives Usingjust traditionalUNIX pipesfor synchron- and the 4mm DAT drives. ization, multiple processescan do the I/O, where _ The ExabyteEXB-8200 [3] is ratedto hold up each processreads from the disk and takes turns to 2500megabytes of data,and stream at 246l(Bli. writing to the tape (this is the approachused by According to our own measurements,we get 2200 DUMP). If the OS allows shared memory, two MB on our tapes,and a transferrate of 238 KB/s. processes,a readerand a writer, can sharea pool of We havemeasured the filemarksize to be 2130KB, buffers. Or, if the OS supports asynchronous andit takesabout 10 secondsto write. input/output,both readsand writes can be outstand- Many vendorssell DAT tape drives. We have ing with a singleprocess. on handa DEC TLZ04 CassetteTape Drive[6]. We We have implementedthese techniquesand do not ¡un Amandaon this drive,but we measured find that,when properly tuned, they can achievethe some of its characteristicsfor comparison. The samerate transferringlarge disk files as when writ- driveis ratedto hold 1.2 gigabytes,and transfer data ing a memorybuffer in a tight loop. The numberof at 183 KB/s. Accordingto our measurements,we readerprocesses or metnorybuffers needed is system get 1245MB on our tapes,and a transferrate of,L73 dependent,and is more than might be expectedin KB/s. theory. The sibling processescan produceor con- sumemany buffers before the othersget a time-slice,

SI"AVEHOSTS IVIASTERHOST

BackuPO.," -:¡' ControlMessages -Ð

Figure 1 - A¡chitecturalComponents of Amanda

'92 Summer USENIX - June 8.June LZ, LggZ- SanAntonio, TX 219 Performanceof a Parallel Network Backup Manager da Silva,... becauseof coarsescheduling granularity, read-ahead fast as possible,then deleted. Any dumps that are on the disþ andbuffering in the tapedrive. too big for the holding disk are dumpedsequentially Small files neverreach the rated speedbecause to tapeafter all otherfilesystems have been dumped. there is not enoughdata in the files to causethe tape When there is a tape problem, Amanda will run drive to streamefficiently. The time to write small incrementalsof all filesystemsto the holding disk, files is dominatedby the filemarkwrite time. which can thenbe flushedto tapewhen the operators anive the nextmorning'and conect the problem. Amanda The filesystemscan also be compressedbefore Amanda is a batch orientedbackup manager, being transferred,which resultsin abouta 40Vo-60Vo invoked eachnight throughcRoN on the masterhost reduction in ouput size. When dumping several to back up a list of filasystemsfrom acrossthe net- filesystems in parallel, compression does not work on slave hoststo a multi-gigabytetape drive. adverselyaffect the total Amandarun time. In fact, the reductionin output The original version of Amanda executed size reducesthe total time because remote dumps to the tape drive one after another thereis lessdata to write onto tape. accordingto a dump list. It took care of handling The componentsand data flow of Amanda are failed and timed out dumps, mailing a status and shown in Figure 1. Amanda runs in two distinct eror report to the operators,and preparingthe next phases. The frrst phase,called PLANNER,manages night's dump list. We ran this system for over a the overall backup schedule. It is responsiblefor year at threesites here at the Universityof Mary- keeping the schedulebalanced and for assigning Iand. dump levels for each filesystem for the cunent Amanda IIANNER While we liked the reporting, enor handling, run. outputsits dump list to the secondphase, called DRvER. and schedulemanagement features of our backup DRwERexecutes all the dumps, manager,it was too slow to handleall our worksta- decidingwhat order to run the dumps, andwhat order write tions in a single night's run. It was taking con- to themto tape. sistently seven or eight hours to back up only PI-A,NNERuses accurate estimates of backup 600-900MB each night. Occasionallysomething sizes along with historical data on previous dumps would go wrong and dumpswould run until noon the (including backup rates and compressionratios, to next day. assigna dumplevel to eachfilesystem). If the setof backupsto be We solved this problem by completely done is too large for the tape, some full dumps are delayed redesigningthe system to run enough dumps in for one night. If cunent backupsare too small parallel so that the cumulative dump rate matches relative to other nights in the backupcycle, the tape speed. We can run the dumpsin parallel somefull backupsoriginally scheduled for the following while writing them to tape sequentiallyif we use a night are moved forward. In this way the backup schedule disk as a buffer to hold the dump data while the expands,contracts, and balancesout automaticallv parallel dumpsare running. This disk is called the as needed. holding disk. Once a dump is finished, the dump image is copiedfrom the holding disk to the tapeas

From: bin0cs.UMD.EDU Subject: CSDAMANDA MAIL REPORTFOR March 28, Lgg2 To: csd-amanda0cs.UMD.EDU These dumps were to tape VOL1.5. Tonight's dumps should go onto tape VOL1 or a new tape. SÎATISTTCS: lotaI Full Daily

DumpTime (hrs:min) 2254 lz25 r!L5 (0:14 taper idle) Output Size (meg) 1438.1 1070.9 367.2 Original Size (rneg) 2L65.6 L476 .4 689.2 Àvg CompressedSize (8) 62,4 70.2 44.0 Filesystems Dumped 236 LI 219 Avg DumpRate (k/s) 40.1 51.8 24.I Avg Tp Write Rate (k/s) L52.9 2t4.9 83.1

Figure 2: First Pageof an AmandaMail Report

'92 220 Summer USENIX - June 8-June12, L992- SanAntonio, TX da Silva,... Performanceof a ParallelNetwork BackupManager

PL,ANNERgets its accuratedump size estimates A PerformanceExperiment from the slave hoststhemselves. A datagramis sent While Amanda's backup to the sENDslzpservice on every slave host in the managementfeatures are useful even without parallel dumping, network, requestingestimates for particular dump it is the parallelismthat givesa big win levels for each frlesystem.SENDsIZE runs DUMr to over othersolutions. To determine the effect parallelism had get eachneeded estimate, killing dump onceit out- on our backuptimes we conducted puts its estimatedsize. The estimatesare thensent an experiment. I¿te on Saturday night of SuperBowl weekend,when back in a datagramto rLANNERon the masterhost. the network and machineswere unusually we Dependingon the numberof requestsand the size of idle, ran Amanda repeatedlywith the maximum the filesystems,this proceduretakes about 2 to 5 number of DUMPERSallowed varying from L minutesper slavehost. However,PLá,NNER sends its to 11. We configuredAmanda to run all the dumps requestdatagrams to all the slave hosts frrst, then through COMPRESSon the host. waits for replies to come in. Therefor, the entire slave PLANNERphase takes about 5 minutes,regardless of PI-ANNERwas run once to generatethe list of whetherthere are 20 slavehosts or 1.20. filesystemsto be dumped. For this experiment,178 filesystemson 79 hosts (25 For filesystemsdoing incrementaldumps, esti- Sun3s,31 SPARCsta- tions,23 DECstations)were dumped. mates are requestedboth for the current level that The total size of the dumps, after the filesystem is dumping at, and the next higher compression,was 498 MB. There were 2l firl| level. If dumpingat the higher level would produce backupsaccounting for 404 MB, and 157 incrementalbackups, a muchsmaller dump, and if the filesystemhas been taking 94 MB. Geç ting the estimatesfrom all 79 slavehosts and dumpedat the currentlevel for at least two days,the mak- level is bumpedby rreNNrn. Automatic bumping ing its decisionstook nI-ANNER less than 5 minutes. providesa good tradeoff betweenincremental dump Our dump masterhost was a SPARCstation sizes and the desire to have fewer dump levels to IPC with 16 Megabytesof memory, an Exabyte restore. The usercontrols the bump threshold. EXB-8200tape drive, and a Fujitsu M2266 7.2 giga- byte disk drive, with Amanda PIANNERoutputs its decisionsand estimatesto configuredto use a maximum of 800 MB the second phase, called DRrvER. Staying within for its holding disk. In this experiment,only 403 user-specifiedconstraints on total networkbandwidth MB wereactually used. allowed, total holding disk spaceallowed, and max- Figure3 showsthe total run time of the experi- imum numberof dumpsin parallel allowed,DRTvER ment as a function of the number of putvtppRs runs as many dumpsas it can in parallelto the hold- allowed. The first curve shows the total time to ing disk. As dumps to the holding disk complete, completeall the backupsto tape. It dropsdrastically they are transfenedto the tape by the TAPERpro- becausethe tape can write backupdata at its full gram. TAPERconsists of both a disk readerand a speedconcunently vyith severaldumps that are run- tape writer process,with shared memory buffers ning to the holdingdisk at slowerspeeds. betweenthem. The readerand writer partsof reppR fill and drain buffen asynchronously. DRwERdirects a numberof DUMPERprograms, totalbackup tine L one for each dump that can run in parallel.ourrlpen taperidle taperread wait connects to the SENDDUMIprogram on the slave host, receivesthe desiredbackup image and puts it on the holding disk. seuonuMp parsesthe control e messageoutput of ¡uup for any 7" failures or error I messages(like readerrors on the slave'sdisk) and o DUMPERlogs theseproblems. Þ \ F¿ In addition to thesemain components,Amanda includesseveral other auxiliary programs. A report writer scansthe logs of the latest Amandarun and sendsa report to the operators(see Figure 2 for an example). Amanda tapes are labeled,and Amanda will not write to an unlabeled tape,or to a labeled 1 2 3 4 5 6 7 8 9 1011 tape that containsrecent dumps that should not be Pa¡allelism(#of simultaneousdumpers) overwritten. This preventssome common operator Figure 3: AmandaPerformance Experiment Results enors (such as forgetting to changethe tape) from causingloss of data. Insteadof failing completely, The secondcurve shows the amount of time Amanda will run incrementalsof all filesvstemsto TAPERis idle, waiting for dumps to finish before the holding disk, which can then be flushedto the transferringthem to tape. It is this idle time that is right tape when the operatorsarrive the next morn- responsiblefor the relatively long run times at low ing and conect the tapeproblem.

'92 Summer USENIX - June 8-June12,lgg2 - SanAntonio, TX 221 Performanceof a Parallel Network Backup Manager da Silva,...

levels of parallelism; there are not enough dumps This simple algorithm does very well most of ñnishing to keep TAIER busy. At 7 or more the time, but occasionallyfails to keep the tape DUMPERS,TAPER is kept busy virtually 700% of. the busy, slowing down the backup procedure. For time, so the curvelevels off. example,when pRIwR does not start a large dump Rememberthat TAPERconsists of both a reader soon enough,everything else will finish well before and writer process. The third curve in Figure 3 is this dump, leaving TAIER with nothing to do until the cumulativetime the writer processhad to wait the dumpfinishes. for a buffer to be read into memory. When the In order to evaluate the performanceof our multiple-buffercopy schemeis working, this time is algorithmsin a variety of environments,we imple- close to zelo - the writer always has a full buffer menteda trace-drivensimulator testbed. By plug- whenit needsone. However,when the readerhas to ging proposeddriver algorithmsinro our simulator contendwith manyDUMIERs for accessto the disk it we can easilymeasure the impact of any changes. can fall behindthe writer, causingthe TApERto slow The simulator uses performanceresults from our down, and the total dump time to increaseslightly. actual nightly runs. It is thus very accurate;it As the load on the masterhost increases, we observe matchesreal results to within minute 'l,Vo a or two, a generaldegradation of performance,caused by fac- which representsabout Enor,due to varioussys- tors such as tape write time and control message tem overheadsthat the simulatordoesn't account for. transfertimes which we did not measure directlv. We haveevaluated several algorithms using the OperationalExperience simulatorand havesettled on one that ordersthe list of dumpsby time, andplaces DUMIERs on both ends Runningnetwork backups in parallelhas been a of this sortedlist. The distributionof dump times big win for us. What usedto take us six or seven (seeFigure 4) is the key to keepingthe tapebusy. hours with sequentialdumps now takes approxi- Most dumpsare small incrementalsthat finish very mately75 minutes.This hasenabled us to adda// of quickly. Sinceour tapetakes ten secondsto write a the rest of our workstationdisks to the backupsys- filemark, the very smallest dumps can complete tem, taking over for usersthat were previouslysup- quicker than they can be written to tape. The first posedto be dumpingtheir disks to cartridgetapes incrementalto complete, usually from a quiet themselves.We are now backingup 11.5gigabytes filesystemon a fast machine,is done in 2 or 3 of data in over 230 filesystemson more ihãn 100 seconds.By the time the tapecan write the filemark workstations,in two to threehours. for this dump, the next two tiny dumps will be We have found that each night incremental finishedand will be ready to be written. In fact, dumps accountfor roughly 1,/3of the total output almost25Vo of the dumpstake less time than the size. We have also found that 500 MB of filemarks filemark write time, so, one or two DUMPERscan arewritten eachnight. Given thesetwo factorsand keepthe TArER busy for all the smallerdumps. a measuredtape size of.2200 MB, there is room for atout 1100 MB of compressedfull dumps each 10000 night. With ten nights in our backup cycle, and compressedsizes at about60Vo of the original sizes, o 6 we can back up 18000MB with our singleExabyte ûo 8mm drive. oo10tX) By thosecalculations, we still have room for tl about6 more gigabytesof data,at which point we R will be filling a 2 gigabyterape in about 4 hours ¿ 100 with Amanda,compared with about16 hoursdump- Ê ing directly to tape. More data can accomodated E after that point by lengthening rhe dump cycle to 910 morethan two weeksbetween level 0 dumps. o SimulatingAmanda Performance I Our initial DRIvERalgorithm to scheduledumps was very 020406080100 simple. It took the PLANNERoutput and Peræntile(ofall dump$ executeddumps on a first-fit basis,running which- Figure 4: DumpTime Distribution ever would not overflowthe holdingdisk, the total network bandwidth, or the number of nuvpgns. Less than 10Voof. the dumpstake more than 5 When a dump finished,it was put in a first in, first minutes. But of these,some can take a very long out (FIFO) queuefor writing ro tape. time, particularlyfull backupsof big disks on slow workstations. It only takes a handful of very long

'92 222 Summer USENIX - June 8-June12, Lgg2- SanAntonio, TX da Silva, ... Performanceof a Parallel Network Backup Manager

dumps to dominate the entire run time, so it is The increasein simulatedtime for the sequen- importantto start the longestdumps as soon as pos- tial_dumpesin the interval between5 and 20 nigirts sible. Since one or two DUMpERscan handle the is due to the steadyincrease in the number of-file majority of dumps startingat the short end,it makes systemsbeing dumped,as we added disks to our sense to concentrateall the rest of the DUMPERSon Amanda backups. Note that the current algorithm the long end of the dump time distribution,making shows very little fluctuation of the run timé. The certain some of the longer dumps are startedrighi peak observedon the 23rd night is due to a tape away and thus finish beforetareR goes-of idle. Ttris algorithm is based on a variation the first-fit decreasingbin-packing algorithm[7]. ) We also studied variations for the queue of finisheddumps waiting to be written to tape. As we 9]qTJgd, orderingthe queueby largest¡te ¡rst out (LFFO) 1t2 .+ _performssignificantly bertei than oúr origi- nal FIFO queue. Writing the largest file first then deleting it reduces the load on the holding disk t) quickly, makingroom for new dumps to run. H figgre 5 comparesthe run time, accordingto our simulator,of traditionalsequential dumping, our pnrv¡n initial algorithm, and our current aigoiithm, rúr executedwith actual dump data from 25 nights of dumpsat our site. The parallelalgorithms are not as t{ sensitiveto individual dump speedsas the sequential I þpkup procedure. The parallel dumpingof ieveral file systemsmakes it possibleto absorbIhe time for longer dumps while dumping several other smaller n or fastermachines. U 2N 300 400 500 600 700 800 900 1000 HoldingDisk Size (MB) Figure 6: Effect of Holding Disk Size

L4 Current Algorithm - InitialAlgorithm ----- 72 Sequential------

10 ? g 98 Þ t-{ =FI Íø crt Ê 4

0 57911 13 15 1.71.9 27 23 25 Night Figure 5: Run Times of VariousDRTvER Algorithms

'92 Summer USENIX- JuneB-June ]rZ,lgg2 - SanAntonio, TX tra Performanceof a Parallel Network Backup Manager da Silva,... failure that occurredthe night before (that night is Browdy and Jeff Webber provided early feedback. not shownin Figure 5), and thereforethe amountof Hary Mantakoshelped find workaroundsfor some datato dump on the 23rd almostdoubled. braindead versions of ruserok( ), and with other While we run with a large holding disk, fun porting adventures.Thanks to Staff World for Amandacan perform well with much smaller hold- torturetesting the software'serror handling features. ing disks. Figure 6 shows the total dump times, Congratulationsto Pete Cottrell for winning our accordingto the simulator, for 12 different nights namingcontest by comingup with Amanda. with the holding disk size varying from 200 MB to Iast, but certainlynot least,the authorswould 950 MB for each night. Even with holding disk like to thank Ann Gallagher,Vanessa Chernick, and sizes as small as 200 MB, Amanda performsmuch Kristen Tsapis,respectively, for their moral support betterthan sequentialdumps. andunderstanding. Conclusionsand Future Work References With Amanda,we have achievedperformance 1..Steve M. Romig,"Backup at Ohio State,Take close to optimal, that is, dumpingfilesystems as fast 2," Proceedingsof the Fourth Large Installa- as lile canwrite files to tape. This was donewith 7 tion SystemsAdminßtration Conference,pp. or 8 nuvpBns. We have studied and continue to I37-t4t,The UsenixAssociation, Oct 1990. examine different scheduling algorithms for the 2. Rob Kolstad, "A Next Step in Backup and DUMPERs,in orderto minimizethe time to complete RestoreTechnology," Proceedingsof the Fifth backups,while remainingwithin the resourcecon- Large Installation Systems Adminßtration straints. Our currentbottleneck is the tape speed, Conference,pp. 73-79,The UsenixAssociation, but we believe our algorithm is sound eiough to Sep1991. , addressdifferent constraints in a wide varietyof ins- 3. EXB-8200&mm Cartridge Tape Subsystem Pro- tallations. duct Specification,Exabyte Corporation, Jan We are curently consideringa prescheduler 1990. that determinesthe starttime of everydump before 4. SteveShumway, "Issues in On-line Backup," any dumpsare done. This scheme,if feasible,will Proceedingsof the Fifth Large Installation Sys- further reduce the number of puvpBns neededto temsAdminßtration Conference, pp. 81-87,The keepthe tapebusy, and will minimizethe amountof UsenixAssociation, Sep 1991. holding disk spaceneeded, by spreadingout the 5. ElizabethD. Zwicky, "Torture-testingBackup dumpsso that they are readyjust whentApen needs and A¡chive Programs:Things You Ought to them,and not before. Know But Probably Would Rather Not," Our futu¡e work will focus on generalizingthe Proceedingsof the Fifth Large Installation Sys- schedulingalgorithms to addressconstraints from temsAdminßtration Conference, pp. 181-190, incomingtechnologies, such as fastertape systems, The UsenixAssociation, Sep 1991. larger disk subsystems,larger scale in terms of 6, TLZ04 CassetteTape Drive, Digital Equipment numberand speed of machines,other backup subsys- Corporation,Apr 1990. temssuch as C?IOand GNU ren. 7. DonaldK. Friesen and Michael A. Langston, Regardlessof any futureimprovement, we have "Analysis of a CompoundBin PackingAlgo- already achieved our goal of backing up all our rithm," Journal of Discrete Mathematics,vol. workstationfilesystems to a single8mm tape over- 4, no. 1, pp.67-79,SIAM, February 1991.. nightwith no operatorintervention. SoftwareAvailability Author Information Jamesda Silvawas a high-schoolhacker in the Amanda is copyrightedby the University of '80s. Maryland, but is freely distributableunder terms early He receiveda NationalMerit Scholar- similar to thoseof the MIT XL1 or BerkeleyBSD shipfrom GeorgiaTech in 1983,but soonleft school copyrights.The sourcesare available for anonymous to work in the Real World. He was a Systems ftp from ftp.cs.umd.eduin the pub/amandadirec- Engineerfor ElectronicData Systems,writing appli- tory. cationsprograms first on the PC, then under UNIX. In 1987he escapedthe Real World and headedfor Acknowledgments the ivory to',¡/ersof the University of Maryland. He works there as a ResearchProgrammer for The authorswould like to thankPete Cottrell of the Sys- temsDesign and AnalysisGroup of Depart- the Departmentof ComputerScience, and Steve the CS ment, and is still lingeringin searchof those Miller and Charlie Amos of the Institute for last few AdvancedComputer providing undergraduatecredits. Jaimecan be reachedat Studies,for the com- [email protected]. putet facilitieson which we testedAmanda, and for puttingup with our early,buggy versions.Edwa¡d

224 Summer'92 USENIX - June 8.June12, L992- SanAntonio, TX da Silva,... Performanceof a Parallel Network Backup Manager

Ólafur Guðmundssonwas born in Reykjavík, Iceland. He graduatedfrom the University'oi lce- land in 1983with a B.S. in ComputerSciénce. He worked as a systemspro$ammer on VMS machines at the Universityof lcelandfrom 1983to 1984. In 1984he joined the graduateprogram of the Depart- ment of Computer Science at the University of Marylandwhere he had to learn somenew operating systems,most of them unpleasantmainframe sys- tems, until discoveringUÑI)l Ólafur obtained a Mastersdegree in 1987. Since then he has worked as a FacultyResearch Assistant in the Departmentof Computer Science at University of Malyland. In this position he has been primarily involved in research,development and implementationof a dis- tributed,hard-real-time operating system Maruti, but he has also worked on practical problemsin com- puter networksand operatingsystems. ólafur can be reachedat [email protected] [email protected] . DanielMossé was born in Rio de Janeiro,Bra- zil, when Brazil won a SoccerWorld Cup. He did Iis undergradin Brasilia, the capital, in Math, and got his MS from the Universityof Maryland,where he is cunentlya Ph.D.candidate, soon to graduate. He can be reached through e-mail at [email protected] range from anything interesting,to real-timeoperating systems, resource allocationand schedulingproblems, fault tolerance, anddatabases.

'92 - Summer USENIX JuneB.June lZ,lgg} - SanAntonio, TX 225