Helpful to know the overall world order context. I can live with it, especially now that I know and understand it.
There was a recent posting from someone using a SAN to for file-driver pure-disk backup. Just as disks are cheaper for small users they are also cheaper for large users. A SAN, combined with a WAN (perhaps less used at night), can provide geographic diversity for the backups. But I'll have to wait and see if this becomes popular at large sites. FWIW I understand Solaris 9 put a lot of effort into GUI, so that is a counter example suggesting that Sun feels that GUIs are useful to large installations. Probably what is happening is, if you spend several years writing and maintaining the source code for a program, you hardly need a GUI. All I was thinking with appending was that then you wouldn't even need the flip-flop script I recently posted but could just have a bone simple amanda.conf that pointed amanda at a single BFD (big disk) and let it rip until the disk was full. I guess what I'd envision, if anyone knows of it, is an open source Second Copy 2000 that runs on unix, has a GUI, stores in file system format for browsing/restore, and uses smbclient for windoze boxes. That said, I agree that amanda meets my needs. I like it. The support for windows clients seems a little light (e.g. no exclude lists (since smbclient requires gnutar)) and I would be surprised if the core developers develop for a windows-free enviroment but more power to them. -Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jon LaBadie Sent: Friday, June 21, 2002 11:18 AM To: [EMAIL PROTECTED] Subject: Re: 2.4.3 Tapeless file-driver pure-disk backups On Fri, Jun 21, 2002 at 10:00:58AM -0700, Steve Follmer wrote: > > I for one am glad that amanda has grown beyond its unix/tape roots to > support samba/windows and to support file: disk backups. This does not > have to be sacrificed, in adding even more robust support for file: > and also, some SWAT like GUI. And this would make amanda more useful > for more people, if the amanda community wants to go in that > direction. > > Though there will be conflicts; appending is bad on tape, good on > disk. Explicitly specifying incremental backups is bad for large > networks, but I would desire it for my small network. That said, > certainly there are windows and mac clients in the large > commercial/university installations that characterize the bulk of > amanda users. > > I admit that the majority of existing amanda users use tape, but its a > biased legacy sample. But let us not ignore the possible users > represented by the exponential growth in home networks, linux, and > cheap disks; a growing audience of users like myself, for whom disk > backup is better than none, who don't have the money to sink into a > tape system, and who don't see enough upside (what are the odds that 2 > drives in different machines will die on the same day) on changing and > labeling tapes and shipping them off to the abandoned limestone mine. Amanda was originally written by, and is currently maintained by, a surprisingly small total number of talented people. Their objective, as I understand it, is to provide quality backup services for their own use, not for ours. For the most part they do administer large sites that use tape. Wide-spread, increasing adoption of amanda on small systems is not a requirement of that objective. We small users are benefitors of their efforts. Changes we see as highly desireable, or immensely practical in our environments may be of little value in the environment of the amanda developers. As they are not developing a commercial product, increased "sales" is not an incentive. In fact, increased usage actually causes them to devote more of their freely given time to supporting the new users. This does not imply new features and niceties for small users do not make it into amanda. But the 'primary' use of amanda at large sites, as you indicate, can not be sacrificed. File: disk backups are one example, but be aware that it is a pretty recent addition to amanda and is probably undergoing teething pains. (I have not used it, so I say that from ignorance) You indicate two desireable features, GUI and appending. In general, GUI's are wonderful things for end-users/desktop environments. They hold fewer benefits for large installations. So any impetus and development effort on a GUI is unlikely to come from the traditional amanda developers. That does not mean you, or someone else with a similar desire, can't contribute their time freely and develop such an interface and contribute it to the project. Many would love to see that. Appending is a topic that comes up often (weekly? daily? :). As you seem to accept appending is bad for tape, it might only be used for disk file-based backups. I'm not at all sure why you feel appending is good for disks. Even if it is a good thing for file-based backups, you have to consider the effort of revising not just the backup software, but also the recovery and all the administrative software to handle this special case. The alternative, which has been adopted, is to make the disk "look like a tape". Thus no appending to disk file backups either. > I appreciate your advice about the autochanger and will explore that. It will probably meet your needs, just in a different way than you think is "right". jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
