From: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!sri-unix!CHUQUI@MIT-MC Newsgroups: net.unix-wizards Title: Flames on system backups Article-I.D.: sri-arpa.814 Posted: Mon Mar 21 20:42:00 1983 Received: Wed Apr 6 03:29:53 1983 From: Charles F. Von Rospach Does anybody out there know of a decent backup system available for Unix? I have been trying to get soemthing running with dump and tar, and I am extremely disgusted with the quality of this software. My basic requirements would be (in relative order of preference): o Incremental backup capabilities o Multiple filesystems o Multiple volumes o Reasonably straightforward and easy restores on the file, directory, and system level (in that order). o Decent documentation o Decent handling of the mag tape device. o internal control of the tape libary, with volume number prompting o on-line backups The main problem I am having are because my filesystem structure is not what most Unix people would consider 'normal'. I currently have 8 mounted filesystems (includeing root and /usr), and some of them are fairly large. Before people tell me to change this, let me add that this cannot change because of the way some of the users have designed their software, and getting them to change is not reasonable. In attempting to get dump to work on this system in a reasonable way, I have found the following problems: o dump does not allow multiple filesystems on a tape. This means that I have to keep 8 sets of backups (with the associated 8 tape swaps per day) or figure out some way around this. At one time, I was writing to nrmt8 and doing forward and backward spaces to get to dump images on the tape, but restoration from this kind of tape was almost impossible. o dump does not recognize end of tape. It takes the given density and length of tape and estimates the number of bytes it can fit. When it figures it is close, it asks for a new volume. This creates a few problems. I have to run dump giving it what will be the smallest size tape it will see, or it aborts. If it hits end of tape, there is no way for me to get it to checkpoint at the last completed file before going to the next volume. IDumps estimates also seem a little wishful, since I am currently having to tell dump that my 2400 foot tapes are 1800 feet to keep it from running off the edge. o restorations on dump are painful. If I ned to restor a directory, I almost have to restore the full system onto a scratch partition and move it . I don't know that I will be able to keep that much spare disk around. Restoring a file into a file called by its inode number is simply ridiculous. o Dumps documentation, to put it lightly, easts it. Under diagnostics, it defines them as 'many, and varied'. That doesn't tell me what to expect, and it doesn't tell my non-programmer operators what to do when something goes wrong. That may seem cute to whomever wrote it, but in a commercial installation it just gets people like myself irate. o Dump also returns with non-standard exit codes. When dump exits normally, it does so with an exit code 1, instead of 0. This is also not documented. I have noticedin my experiments exit codes of 2, 3, 4, and 1. None of these are documented. If yopu are going to send a special exit code for some reason, PLEASE tell us what it is for. TAr is a little better because it allows me to save and restore across filesystems and by using filenames. It does not have incremental capabilities, and while I could front end it fairly easily, the overhead of 200 to 2000 'tar r ' calls on an 11/750 would be laughable. Also, since Tar doesn't support multiple volumes, I have another end of tape problem. Anyone out there have this problem and solve it already? Anyone out there want to justify some of these design 'features'? Maybe there is something I have missed, but Unix is the first system I have worked on that seems to have put almost no time in on such basic system requirements as system backups and print drivers (another flame altogether). chuck (chuqui at mit-mc)