2009-05-17
One reason for Unix's permission checking timing
Unix has a slightly odd way of handling file access permissions, in that they're only checked when a file is opened, not every time that you attempt to do something with the file handle. While the choice is defensible, in many ways checking permissions on access would be more convenient, since it would enable things like immediately revoking access to files, and very few programs actually care about this.
(And these days, it would fit better into network filesystems, many of which operate this way anyways.)
Having said that, one reason that Unix as it currently stands pretty much has to have this approach is the issue of how terminals interact with setuid programs. Since your terminal is not accessible to other UIDs (except to root as a special case), a 'check on every access' environment would need some special mechanism so that a setuid program would still be able to print output and get input. This would also apply to any redirection that you wanted to do with setuid programs, which expands the problem even more.
(Current Unix systems actually have to have a workaround for network filesystems due to this. I believe that basically all of them save the UID and so on in effect when a file was opened with the kernel filehandle, and then the network filesystems carefully send that set of identification to the server, not the current process's current UID et al.)
(Disclaimer: I doubt that this issue is the reason Unix made this choice; it's more something that comes up once you've made the choice and designed your system accordingly.)
The crucial difference between online and offline backups
At one level, the difference between online backups and offline backups is that online backups are, well, online; you can make them and get at them without having to load tapes (or hard drives), connect your external USB hard drive, or whatever. There are two advantages of online backups; they involve little or no physical shuffling around of things, and they make for very rapid restores of data.
These advantages should not be understated. It's much easier to automate your backups and make sure that they happen all the time, even weekends and holidays and when you are insanely busy, if they don't require anyone to actually do anything physical. And making restores fast and easy keeps them from draining valuable staff time, especially if the most common restore request is for just a small amount of data.
(With large restores, most of the time can be taken up with writing data back to disk. But with small restores that write only a little bit of data to disk, almost all of the time goes to overhead instead, so reducing the overhead can make a drastic difference.)
However, the crucial difference between online backups and offline ones is that online backups can easily be destroyed, whether by accident or malice. By contrast, destroying offline backups takes actual physical work and is much harder to do by accident (although not impossible). It's thus a good idea to have at least some offline backups, just in case, even if online backups are so much more easy and convenient.