Linux, OpenBSD, Windows Server Comparison: Windows Directory Structure Adversely Affects Reliability

• System Recovery

Compared to the registry, the poor Windows directory structure, has smaller but not insignificant reliability consequences. Any competent system administrator knows that system programs should be separated from application programs, data should be separated from programs, and user and application data should be separate from each other.

Though some UNIX directory names may seem odd, short and cryptic by today's long filename conventions, a look at any BSD directory structure will show these kinds of separations implemented. The program distinction is more between system installed and locally installed programs. System programs go in /bin, /sbin, /usr/bin and /usr/sbin. The bin directories are general purpose or user oriented while the sbin directories are more administrative. The /usr directories are less frequently used than their counterparts without /usr. Typically the /bin and /sbin directories have the essential programs likely to be needed in "single user mode" and these directories are normally part of the root ("/") filesystem that is first mounted.

Local programs normally go in /usr/local/bin or /usr/local/sbin at the choice of the administrator. An apps or other subdirectory could be added to /usr/local, if the administrator desired, for application programs as opposed to utilities. Significant applications often get their own subdirectory in /usr/local/ or /opt. /etc holds system configuration files and user specific configuration and data files go in the user's "home" directory under /home. /var holds variable system data, typically logs and queues. It's generally left up to the application or installer where to put application data. Other UNIXs may be somewhat less clean and simple but generally use a similar approach.

On Windows systems, except for "C:\Program Files" which is the default location for programs and their data that don't go into the system directory, everything else is, by default dumped into the system directory, "C:\WINNT" . WINNT looks like all the UNIX directories were mixed together and pseudo randomly poured into different locations in WINNT. Some older programs go directly in WINNT. The "real" system directory is system32 under WINNT. It may have thousands of system utilities and shared program files (which would be in a lib or share subdirectory on a UNIX system) as well as a variety of configuration files. The registry goes in config under system32. By default the IIS directory goes into system32.

The real gems are Profiles, and Web which go under WINNT and logfiles, repair, and spool which go under WINNT32. Profiles has all the individual user interface configuration options, i.e., everything for the desktop, program menu and task bar as well as browser cookies, history, and favorites or in other words, the most volatile and personal configuration data. Web is loaded with graphics related to "channels". Logfiles and spool are what you'd think, highly variable system data, and repair is a backup of the registry which is also a subdirectory of system32.

The jumble represented by the Windows directory structure does not have a large impact directly on reliability but it has a big impact on the ability to understand a system and even more so to recover a system after a failure. The Windows registry is a larger obstacle in this regards, but even if there were no registry, the Windows directory structure creates such a mixture of standard system utilities, system specific configuration files, hardware specific components, and user specific components that it is almost impossible to devise any system recovery strategy that allows one Windows install and configuration to be moved to a different hardware system.

In contrast, the hardware specific components of UNIX systems are few, isolated, and typically documented. With some planing, it is not difficult to develop backup and recovery procedures that allow a specific configuration to be reinstalled on virtually any hardware system of the same platform, requiring only adequate disk space be available.

System Recovery

For any Linux or OpenBSD machine I have that might fail, I should be able to perform a basic operating system install of the correct version on any available Intel compatible hardware, restore my latest full system backup over the standard install and follow with the most recent differential backup to have a system that is functionally identical to the replaced system. The basic install should take about 15 to 20 minutes.

The rest will depend on how much needs to be restored and the speed of the media. More or less standard Linux or OpenBSD re-installs, even with many optional components, should not take much over an hour unless the system to be restored has large amounts of application or user data. Such a process cannot be reliably performed on Windows systems unless essentially identical hardware is available, as documented at considerable length in my web page, The Stupidity of Windows NT Installs, Backups and System Recovery.

If you have good backups, then restoring a corrupted software, Windows NT system can be acceptably quick, depending in part on what service pack level the restore software requires: the amount of time it takes to do a basic system install, install the backup software and then perform a restore. (Of course UNIX systems don't' have a registry to corrupt in the first place, so actually restoring a system to fix a UNIX software failure is almost unheard of; you simply identify and fix the program that is causing the problem.) The restore time will depend on tape drive size, speed and capacity and thus could be minutes or hours. If you have a preinstalled alternate NT system to boot to, then you don't need to do an install. The alternate system would be a minimal OS install with necessary hardware drivers and the same backup software, installed to the same location, as the production system uses. Nothing else, even basic networking, not needed by the backup software needs to be included. You will need to know the administrator password on the alternate system, which suggests keeping it synchronized with the live system.

If you have a hardware failure on an NT server, you better have an identical replacement available. If the restore is to an alternate machine, everything down to slot locations and jumper settings needs to be identical. If NT can detect any differences between the hardware it's running on and the matching settings in the registry, there is simply no predicting whether NT will run on the substitute hardware or what steps may be necessary to get it to run. It may, but don't count on it. If it doesn't, you may be forced to reinstall and reconfigure every software component that was on the failed machine. In my long web page, The Stupidity of Windows NT Installs, Backups and System Recovery, towards the end, I suggest some strategies for mitigating problems, when you are forced to re- install an NT system on non identical hardware.

Hopefully this is any area where Windows 2000 has made significant improvements. Hardware compatibility was one of NT's weak areas. It's my understanding that 98 made significant improvements over 95. If 2000 can detect changed hardware and automatically adapt or lead a user through the necessary installation, it would be a huge improvement. I'd be interested in hearing any firsthand stories from readers, either good or bad on this.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.