jik@athena.mit.edu (Jonathan I. Kamens) (04/29/91)
In article <563@appserv.Eng.Sun.COM>, lm@slovax.Eng.Sun.COM (Larry McVoy) writes: |> Most of this sort of thing goes away when you have a hierarchical file system |> that saves the last days files as /yesterday. AFS does this (or, it can do this, if you configure your AFS setup to do daily clones of volumes that should be backed up daily). The big win with how AFS does it is that it makes hard links to files rather than actually copying them, and then only does copying of the cloned files when you change the (in essence, it's copy-on-write for files). The result is that the clone volume takes up very little extra space on the disk, but accidentally changed or removed files can be recovered. Now, for those of you who are saying, "What, AFS keeps file backups on the same partition as the master copy? What if the disk crashes," I'll point out that AFS has *another* function, called "backup" rather than "clone," which actually backs up a volume to another disk. It can even be another disk on another machine in another building. In fact, there can be *several* backup sites on several different machines and/or partitions. And it only takes one command to do the backup. And you can configure things so that when you reference files in a read-only volume, it will randomly pick one of the backup volumes to get the file from (or, in more recent code, pick a volume on the local subnet if there is one, or a volume randomly from another subnet if not), thus distributing the load over the available backup volumes. Obviously, you can see that I think AFS does do some things right. I won't go into the problems I think it has. :-) -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710