In this article: Introduction, Prerequisites, How my file system is structured, Creating the repositories, Linking to the repositories, Recap, Common problems and fixes, Maintaining your repositories, Using this technique with ZenPhoto and other CMS systems, Additional resources, Comments and feedback

Introduction

WordPress is a wonderful blogging platform and, in certain situations, a good choice for a general content management system (CMS). It is easy to end up with several parallel installations of WordPress—one for each major topic you want to discuss. Everything works great at first, but after a while, the constant barrage of updates to the main application, various plug-ins, and the themes becomes something of a management nightmare. The more blogs you operate, the more time is spent maintaining the blogging environment and the less that is available to actually blog.

If you host your WordPress blog on a Linux-based server (BSD or most any other Unix-like operating system should be able to do this equally well) and you have “shell access”, I might have a way to ease your pain. In a nutshell, you will create a central repository containing every WordPress plug-in that you use in all of your blogs. You create a separate repository containing each of your themes. Next, you create symbolic links (think of them as shortcuts; more about them in just a moment) from each installation of WordPress to your central repositories. From that point on, you only have to update your plug-ins and themes once, and the change will take effect instantly across all your sites. It’s a very slick trick!

This trick works probably works well on many other CMS systems that use plug-ins and themes; I have started using it with my ZenPhoto installations, too. In addition to helping keep things updated, it also saves disk space since you are only maintaining a single copy of the files on your server.

I will provide step-by-step instructions and some quirks for which you need to be aware. One quick word of caution: mistakes, bugs, and goofs can also instantly affect all your sites, so be very careful as you work, take your time, and always backup your files and databases before you start.

Prerequisites

Before we get started, make sure that your system meets the following requirements:

• All of your WordPress installations should be hosted at the same Internet Service Provider, and they probably have to be on the same physical server (though not necessarily with some ISPs depending on how they configure things). If the server is something other than Linux or Unix-like system, they may even have to be on the same physical hard disk for this to work. Ideally, they should all be hosted under the same user account, but if not, they different accounts need to be in the same Unix security group and permissions have to be granted for the whole group, not just the owner (that’s beyond the scope of this article).
• You must have shell access to your server. This means that you can access a command prompt (a screen that looks like a DOS window) after you login, and you can type commands that directly affect your server. These instructions assume that your server is a Linux system, though FreeBSD and other Unix-like systems should all work similarly. While Mac OS has similar features, I think the commands are somewhat different, so you will need to adapt these instructions if your server is a Mac. Windows is finally getting to the point that this type of linking may soon be available, but as of Server 2003, this method will not work on a Windows server.
• It is also very helpful if you have some basic familiarity with your server’s shell and the structure of the file system on the server. These instructions are based on the way things are setup on my Internet Service Provider’s servers, and your ISP might do things a little differently. If you get lost or confused midway through the process, you will want to be experienced enough to figure out how to undo the things you did so far.
• If you need a program to connect to your shell account, I recommend PuTTY. It’s a little overwhelming with all the options it has, but you can pretty much ignore them, enter the address to your server, and hit connect. Voilà! You should see a prompt to enter your username and password. If your ISP supports it, I recommend connecting using SSH, which provides an encrypted connection for better security (though it’s beyond the scope of this article to explain exactly how you do that).
• I find that some things are easier to do using a good FTP program (I love Filezilla for this purpose), and other things have to be done using the shell. In particular, I like to create the central repositories by clicking and dragging files around in Filezilla rather than typing lots of commands in the shell.
• Your server has to support symbolic links (also known as “symlinks” or “soft links”). Under most Linux/Unix-like operating systems, you use the command ln -s to create the symlinks. To test if you have this command, type ln --help from the shell; you should see the help screen for the ln command. If you get an error and did not make a typo, your system may not support symlinks.

–Top–

How my file system is structured

Before I go in-depth with instructions, I’ll briefly explain how files are arranged on my ISP’s server. Your ISP hopefully arranges things for you in a similar manner.

When I login to my command shell and use the ls command (ls is short for “list”, which brings up a list of all the files in the current directory), I see a number of directories—one for each domain that we host (allogro.com, willmurray.name, etc.). The actual content of each website is contained within its directory (i.e., the directory “allogro.com” contains all the files for the allogro.com web site and the directory “willmurray.name” contains everyting for the willmurray.name site.

If I print the working directory (pwd), I see the full path from the root of the server (the top of the file system) all the way to my account’s home. In my case, the path is: /home/acanthus. Our sites are hosted with DreamHost, a very large ISP based in Los Angeles, California (some people hate them, but we have been extremely happy with them for over 3.5 years). In this case, the first slash is the root of the file system. home/ is the place that all the hosting customers’ accounts are stored. acanthus is the “home directory” of our account. The allogro.com and willmurray.name directories reside underneath the acanthus directory.

The home directory is a special place, because it is outside of any website and not directly accessible from the web. It’s a good place to store things that should not be peeked into by curious visitors or overzealous search spiders. In fact, unless DreamHost really screwed up or I created a link into the home directory, it would be a safe place to store passwords and other fairly sensitive information. It is also an ideal place to store our shared repositories for WordPress.

–Top–

Creating the repositories

Repository directories

You will want to start by creating your repositories someplace inaccessible to casual web visitors. If you have a home directory like I described above, that’s perfect and recommended. If not, you could create a new directory and try to protect it using .htaccess and robots.txt files along with other techniques to keep people out of it (though this is not a very secure method, and it could leave your repositories subject to attack).

Using Filezilla, I created a directory named shared (the full path is /home/acanthus/shared) to hold all the files that are shared between different web sites. Under that directory, I created two more directories: wp_plugins and wp_themes (that’s /home/acanthus/shared/wp_plugins and /home/acanthus/shared/wp_themes). In each case, I set the file attributes of these directories to give the owner full permissions (rwx) and the group and public permissions to read and execute (r-x, don’t want visitors to be able to make changes). (If you prefer numerical permissions, that’s 755.)

wp_plugins will become the home to all of your WordPress plug-ins. If you use certain plug-ins in one blog, but not in others, go ahead and add the plug-in to this repository. Within WordPress you will enable only the plug-ins you want to use; any that you don’t want to use should just remain disabled. wp_themes is the same deal, except that you store your themes there (that should be self-evident, I hope).

Best practices

Be sure to disable write access to plug-in and theme files and directories unless they specifically require it. For directories, only the owner should have write access (755). For files, you also want to disable the execute permission (644). Check the documentation for each plug-in to see if it needs write access. If your plug-in breaks or has errors about being denied access, you probably need to loosen the restrictions a bit on a directory or some files for the plug-in to function. Very few themes seem to need write access (only one that I’ve ever encountered).

I highly recommend that you grab fresh copies of each plug-in and theme that you plan to use. This way you won’t copy bugs over from existing installations and you are certain to have the latest (and hopefully bug-free) version of the software available. Alternately, you can use the shell to copy (cp) or move (mv) existing directories into your new repositories (though I don’t recommend doing so, and it can leave your site broken until you complete the whole change). You could also use Filezilla to download your plug-ins and themes directories from your current WordPress installation(s) and upload them (thus creating a copy) to your new repositories. If you have heavily customized a plug-in or theme, this may be your best option.

When I upload plug-ins, I usually change the directory name to include the version number. So, if you are uploading version 1.2 of the myplugin plug-in, I’d rename the directory to myplugin.1.2. Some plug-in authors do this for you automatically, while others try to make it easy for people to upgrade by keeping the directory names the same. In a shared repository, though, this can actually cause you problems. One caveat is that some plug-in authors hard-code their directory names in their plug-ins (shame on them!), and renaming the directory breaks the plug-in. In that case, you will either have to hack the plug-in to use the updated directory name, leave the directory name unchanged, or pester, er, petition the author to not hard code the directory name in future releases.

Why worry about version numbers that way? Well, I like to test new versions of plug-ins on a low-traffic blog before introducing them to one of the more active blogs. Remember that when you make a change in the repository, it immediately affects ALL of your blogs. So by overwriting a plug-in with a newer version, you are essentially upgrading all your blogs simultaneously. If there’s a glitch in the new plug-in, then all your blogs will be affected instead of just one. By uploading the plug-ins to different directories, you can disable and enable plug-ins on a per-blog basis. Then, once all your blogs are using the new version, you can safely delete the old version from your server to save space.

Most plug-ins also require you to disable them before you install the newer files, and then re-enable them after everything is in place. With a shared repository, that means you have to go to each blog and disable the old plug-in, then upload, and then go back to each blog to re-enable it. I prefer the flexibility of making changes one blog at a time if I want.

–Top–

Linking to the repositories

So now that you have your central repositories all setup with shiny new copies of all your plug-ins and themes, how do you use them? It’s pretty easy, even if the command you type is a little cryptic.

Note: I recommend starting and fully testing this on your lowest-activity blog first to get the hang of it and minimize downtime on your busiest blogs.

Preparing WordPress

Start by logging into WordPress and disabling all of your plug-ins (there is a link at the bottom of the page to disable all the plug-ins at once). This is important since the path to the plug-ins and even the versions might be different when we are finished than what is in use now.

Locate your repositories

After that is finished, login to your ISP’s shell prompt using PuTTY or your favorite program.

Print the working directory (pwd is the command to do this). If your ISP includes that information in the command prompt, so much the better! Otherwise, jot down the path to your home directory (the place you are when you first login). In my example, that will be /home/acanthus.

List the directory (ls is the basic command, though I find ls -lp to be a more useful view). Hopefully you will see your “shared/” directory (or whatever you named the directory that holds your repositories). Next, list your shared directory (ls -lp shared is the command I would use), and be sure that you can see your repositories within it.

Now I need to go to the wp-content directory of my WordPress installation. I would type cd allogro.com to change directories to the allogro.com site. I keep the blog under a directory named main, so next I would cd main. The wp-content is inside this directory, so I would cd wp-content. Note: I could have strung that all together into a single command (cd allogro.com/main/wp-content), but I usually prefer to go one level at a time so I don’t make mistakes.

Listing the directory (ls -lp) shows that I am, in fact, in the correct place, and there are folders named “plugins” and “themes” already here. That’s good! We need to rename those directories to get them out of the way of our new links. We do that by moving the directories to the same location with a different name (a fairly round-about way of doing it, but it works). Enter the commands mv plugins plugins.disabled and then mv themes themes.disabled. At some point in the future after everything is working, remember to come back and delete these disabled directories.

Create the symlinks

Now it is time to create the symlinks to your shared repositories. This is where you need to enter the full pathname to your folders, so start by verifying that you can see all your shared plug-ins: ls /home/acanthus/shared/wp_plugins (substitute your own path, of course). The command to create the symlink is almost identical: ln -s /home/acanthus/shared/wp_plugins plugins (again, substituting your own path).

Let me explain that carefully. ln -s is the command to create a symbolic link. Be sure to use lowercase letters, because uppercase will not work correctly. Also, be sure to include the “-s”, or the system will attempt to create a hard link instead of a symbolic link (which is not what you want), and will likely generate an error on most systems (unless you are logged in as “root” on your own server, and then you might cause yourself problems). Next, you give the full pathname to the target (the shared plug-ins repository). You technically could use relative paths (if you know how those work), but full paths seem to be more stable for plug-ins. The final part is the name of your new link. Since WordPress expects your plug-ins folder to be named plugins, that’s what we used.

If you did not get an error message, when you list the directory (ls -lp), you should see that the entry for plugins looks something like this: plugins -> /home/acanthus/shared/wp_plugins/ (with the file attributes set to give everyone full access as indicated by “lrwxrwxrwx”, but that’s not a problem since the permissions on the repository are what matter, not the ones on the symlink). This means you have successfully created a symlink to your repository folder. List the contents of that folder (ls plugins) and it should exactly match the contents of the repository, since they are actually the same folder just with a new link.

Now it’s time to link to your themes: ln -s /home/acanthus/shared/wp_themes themes (once again, substituting your own path for mine).

Configure and test WordPress

Go back to the administration area of your WordPress blog. Under presentation, you should see a list of all the themes you uploaded to the shared themes repository. If you do not see any difference, you might need to clear your browser’s cache and refresh the page. Simply select your desired theme to activate it. Even if your desired theme came up automatically, it might be a good idea to select a different theme momentarily, and the reselect your desired theme. This sometimes fixes weird problems I’ve encountered, so doing it right now rather than later makes sense. View the blog and make sure things look right.

You might have to reconfigure your widgets since you changed themes. Some widgets might not work or be available until you activate a related plug-in.

After you are sure your theme is working, go back to the plug-in administration for your blog and enable one or two plug-ins that you can use to easily verify your plug-in repository is working. If those two look good, you can enable one or two more plug-ins and then test them. Repeat until all the desired plug-ins are verified.

If after enabling a plugin you see warnings that a path could not be found, and if you renamed the plug-ins’ directories to include their version number, you might have to rename the plug-in directory back to its original name to get the plug-in to work again.

–Top–

Recap

These are the steps anytime you want to have WordPress use your shared repositories instead of a stand-alone installation. If you have followed my instructions all the way so far, then you will repeat the following steps for each of your remaining blogs. Again, I recommend working in order from the blog with the least traffic to the one with the most to minimize downtime for your visitors as you become familiar with the process.

This recap assumes that you have already created your shared repositories and just need to link to them now.

1. Disable all plug-ins in WordPress.
2. In the shell, navigate to the wp-content directory of your blog (e.g., cd willmurray.name/blog/wp-content; use your own pathname).
3. Rename the current plugins and themes directories (e.g., mv plugins plugins.disabled and mv themes themes.disabled).
4. Create the symlinks (e.g., ln -s /home/acanthus/shared/wp_plugins plugins ln -s /home/acanthus/shared/wp_themes themes; use your own pathnames)
5. In WordPress, activate your theme (if it’s already active, change to another one, then change back to your desired theme).
6. Reconfigure Widgets if necessary.
7. Activate one or two plug-ins at a time and test as you go

Note: After you have a plug-in working in one copy of your blog, it should work in all copies.

–Top–

Common problems and fixes

Redirect URLs generated by plug-ins to the correct subdirectory using .htaccess

Some of my blogs are at the root of the site (www.example.com/), while others are in subdirectories (www.example.com/blog or www.example.com/main). Some plug-ins assume that your site is at the root, and they do not work correctly otherwise. I have been able to fix this in most cases by adding a redirect in the root-level .htaccess file of sites where WordPress is not at the root, and redirect requests for /wp-content to the appropriate subdirectory (/blog/wp-content or /main/wp-content).

Relative paths leading outside the plugins directory cause problems

Some plug-ins use relative paths to files outside of the wp-content/plugins folder (i.e., they try to access a file in the main WordPress installation directory). Without editing the plug-in, there’s really no way to fix this problem. If you are up to hacking the plug-in, you could add a new variable at the top of your theme’s index.php file that gives the full pathname to your local plugins directory (well, it’s actually the symlink to your shared repository, but WordPress doesn’t know that or care). For example, you could add the following to your index.php

< ?php $SHARED_PLUGINS="/home/acanthus/allogro.com/main/wp-content/plugins/"; ?>

Then go though the plug-in files and add the $SHARED_PLUGINS variable in front of each reference to a relative path. Example:

/* Old code:
require_once('../../wp-example.php);
New code: */
require_once($SHARED_PLUGINS . '../../wp-example.php);


–Top–

Maintaining your repositories

The whole point of this exercise was to make it much easier to keep your plug-ins and themes updated across multiple sites. (Oh yeah! That’s why I just went through all of this.) Here’s how easy it is to update everything nearly instantly…

When you are in the plug-ins administration area and notice that a plug-in has an available update, go fetch it, extract it, and rename the directory to include the version number of the release. Upload the plug-in to your repository using FTP. Refresh the plug-ins administration page. You should see both the old version of the plug-in (still active) and the new version (not yet active). Disable the old version. Enable the new version. Test.

If something broke, it’s probably because the plug-in has its directory name hard-coded within it (not a good thing for several reasons). You will have to disable the plug-in in ALL your blogs, then replace the old version with the newer version as instructed by the author. Then you can enable the plugin in each blog. Not as elegant, but still only one upload to worry about.

When you are happy that everything worked, go to your other blogs whenever you want, and disable the old version and enable the new version. There’s no extra uploading to do. If you need to tweak a plug-in for any reason, you only have to do it once, and the tweak takes effect instantly on all of your blogs.

–Top–

Using this technique with ZenPhoto and other CMS systems

The basic principles are the same no matter what system you use. The only challenges are (1) how self-contained plug-ins are (if they frequently look for files outside of the plugins folder, then there is a high chance it won’t work), and (2) how spread-out the files are (the more spread out, the more symlinks you have to create and maintain).

With ZenPhoto, I wanted to add my own CSS file to the default theme. I had to symlink directly to my new CSS file (same process, except you enter the full path and filename, not just the pathname) from within the styles directory of the theme. Again, it’s the same philosophy, but a little more work. But, when I make a change in that one style sheet, the three sites that share that sheet are all updated instantly. Very cool.

–Top–

Additional resources

Articles:

• “Symbolic link.” Wikipedia, The Free Encyclopedia. 6 Mar 2008, 18:31 UTC. Wikimedia Foundation, Inc. 10 Mar 2008 <http://en.wikipedia.org/w/index.php?title=Symbolic_link&oldid=196335114>.

Content management systems:

• WordPress is a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability
• ZenPhoto, a simpler web photo gallery

Software tools:

• FileZilla, the free FTP client
• PuTTY: a free telnet/ssh client

Service providers:

• DreamHost Internet service provider
• Sacramento Online Services for sensible domain name and e-mail prices

–Top–

Comments and feedback

I would appreciate any feedback that you might have. If I left any steps out, or if I could have explained something more clearly, please let me know.

If you use the technique, please leave me a comment. You are also welcome to link to one of your sites that use it.

If you are a plug-in author who has updated your plug-in to work more gracefully with this technique, please let us know!

–Top–

RAID is a method of storing data on multiple hard disks. Through the “magic” of the disk array, all of the individual disks appear as a single disk to the operating system. Large arrays can be split into smaller logical disks, that can be any size up to the total amount of disk space. Depending on exactly how the data is spread across the multiple disks determines the relative speed and security of the data on the disks.

Back in the old days when large (750MB) hard disks were relatively expensive (say $1200 US) and smaller disks (100MB) were relatively inexpensive (maybe $130), somebody figured out that it could be possible to link several of the inexpensive disks together to roughly equal the capacity of a single larger disk. The complete package was called a disk array, and the method of storing the data on the disks was called RAID, for Redundant Array of Inexpensive Disks.

Today, the relative price difference between an 80GB and a 160GB or even a 400GB hard drive is not so great; however, RAID is still very much a part of life with computers—especially with servers. Obviously there is more to RAID than just a cost savings. (RAID now stands for Redundant Array of Independent Devices, which indicates the drift away from price being the motivating factor in choosing a RAID solution.) In fact, by the time you factor in the additional hardware to create and manage the array, RAID usually costs more than non-RAID solutions. So why do we use it? The answers are speed and reliability.

Imagine for a moment that you were an engineer creating the first RAID system (I’d say “RAID Array”, which is the common term, but that’s redundant like saying PIN Number). You design the system so that when someone saves data to the array, it starts filling up the first disk in the array first. Then, when the person saves more data than will fit on the first disk, the system automatically stores the next data on the next disk. This process continues, until eventually you fill up the third and fourth disks. That’s the concept anyway, though the actual implementation (below) is a little different. This fast and expandable solution is known as RAID-0 (also known as disk striping with no parity; more about striping and parity in a moment) and is still used commonly today. It is the RAID solution with what is generally considered the best performance.Array controllers make use of the fact that each disk can write data to the disk at the same time another disk is busy. So the controller breaks the data up into smaller chunks (called stripes), and sends one stripe to disk 1. While disk 1 is busy storing the first stripe, the controller sends the next stripe of data to disk #2. While disks 1 and 2 are writing their data, the controller sends another stripe to disk #3 (if there is one), and so on. Eventually it runs out of disks in the array, so it starts back over with disk 1 again. Using this method, all of the disk space is available for use.

What happens if disk #2 unexpectedly fails? Since data is spread across all the disks, if even one of them becomes damaged (or the controller), the entire array becomes unusable. That’s the down side of RAID-0.

Back to the drawing board you go. What if we spend more money—twice as much to be exact— and build two arrays that contain exactly the same information? That way if one of the arrays dies, the other array will continue to run until we can replace the failed disk. This solution became known as RAID-1 (disk mirroring). Because it is basically two identical RAID-0 arrays, it offers exactly the same performance with the best fault-tolerance (i.e., it is both fast and able to protect against failures). Unfortunately, it’s also usually the most expensive RAID solution. While each half of the mirror can utilize all its disk space, half of the total storage capacity is lost due to the mirroring (an array with 360GB of total storage would only hold 180GB of usable data; the other 180GB would be a duplicate copy of the first 180GB). Note: If a single controller manages both mirrors, it is possible that both arrays could end up with identically bad data if the controller goes bad. Some people use two separate but compatible controllers to reduce this slight risk.

Okay. That sounds like a workable solution, but it’s too expensive for large arrays. You figure that the data really wouldn’t need to be duplicated if there was just some way to (a) detect errors and (b) recover from errors when they are found. Your solution is to calculate and store a checksum of all the data that’s saved. A checksum is just a fancy word for a process that detects errors that can be used to recover from them when they are found. Naturally it doesn’t do a lot of good to store the checksum alongside the actual data. If the data and the checksum were on the same disk, and if the disk went bad, then you would be no better off than with RAID-0.

RAID-2 (hamming code error correction), RAID-3 (virtual disk blocks), RAID-4 (dedicated parity disk), and RAID-5 (striped parity) are all variations on this theme of storing the data along with a checksum on multiple disks (writing with parity is the term). RAID-2 is no longer used, and RAID-3 and RAID-4 are not used except in certain uncommon situations. RAID-5 has emerged the clear winner in this parity slugfest.

RAID-5 combines the striping from RAID-0 with error checking. When the controller sends a stripe of data to disk 1, it will send a stripe of parity data to a different disk in the array. It is very smart about where it sends the data, so that if any one disk in the array fails, the entire array can keep right on running. Many arrays allow for hot swapping the failed disk while the server is running. Then, once a replacement disk is inserted, the array restores the lost data onto the new drive automatically by combing the remaining good data with the parity information. Naturally, the array becomes unrecoverable if more than one disk goes bad (which is why you want to swap out bad disks as quickly as possible) or if the controller goes bad.

RAID-5 (striping with parity) does have a bit more overhead than RAID-0 (striping without parity). All that parity takes a little time to write to disk (making RAID-5 a bit slower than RAID-0 or RAID-1) and a little extra space (generally 1 extra disk than would be required for RAID-0).

So how many disks do you need?

For RAID-0, the answer is two (any less than two, and you wouldn’t have an array—just a regular hard disk with an expensive controller that probably would complain about needing another disk). The two disks also need to be the same size. Many controllers will accept differently sized disks, but the smallest disk in the array will determine the capacity of the entire array. So, if you have an array with one 80GB disk and one 400GB disk, the maximum usable space in the array would be only 160GB (what a waste!).

For RAID-1 you need twice as many disks as you want to use for storage. For example, if you want 400 GB of usable data, you need to purchase TWO 400GB disks. Or, you might be able to purchase FOUR 200GB disks and have the array configure two disks in RAID-0 (striping without parity) and then use RAID-1 (mirroring) to duplicate the striped sets. This is actually referred to as RAID-10. RAID-10 is actually just a combination of RAID-1 and RAID-0. Depending on the controller, you should be able to create striped disks that are mirrored (RAID-0+1) or mirrors that are striped across multiple disks (RAID-1+0).

For RAID-5 you need at least 3 disks. The first two disks stripe the data, and the third disk stripes the parity. (Actually with RAID-5 the parity stripe rotates between all the disks, but it’s easier to think of it as one disk holding the parity information. Incidentally, RAID-4 uses one dedicated disk for parity just as I described.) RAID-5 is nice because after the initial investment in three disks, you can add additional disks to the array and utilize them fully (well, up to the size of the smallest disk in the array) without losing any more overhead for parity.

Just like with RAID-10, there are a few RAID-5 permutations available. RAID-50 (or RAID-5+0) consists of a series of RAID-5 groups striped in RAID-0 fashion to improve the RAID-5 performance without reducing data protection. There is also RAID-53 (or RAID-5+3) which combines striping (in RAID-0 style) with RAID-3’s virtual disk blocks (something I won’t delve into). This offers higher performance than RAID-3 but at much higher cost.

You may see the term RAID-1+5 when ordering a server. This usually indicates the first two drives in the server are configured for mirroring (RAID-1), and the remaining drives in the system (at least 3) are configured for striping with parity (RAID-5). This is common for Microsoft Windows-based servers. The operating system and other applications are stored in the mirror. Data, which usually benefits from the multiple simultaneous-writing features of striping, are stored in the RAID-5 portion of the array.

There are other RAID configurations available, but they are not widely supported at this time. Some worth noting are:

• RAID-6: This type is similar to RAID-5 but includes a second parity scheme that is distributed across different drives and thus offers extremely high fault- and drive-failure tolerance.
• RAID-7: This type includes a real-time embedded operating system as a controller, caching via a high-speed bus, and other characteristics of a stand-alone computer.
• RAID-S: This is an alternate, proprietary method for parity RAID from EMC Symmetrix. It appears to be similar to RAID-5 with some performance enhancements as well as the enhancements that come from having a high-speed disk cache on the disk array.

Finally, another term that you frequently hear along with RAID is JBOD. Remember back to the example of the first array you designed? You created an array of disks that filled up sequentially—when disk 1 was full, things spilled over onto disk 2, and so on. That type of an array (no striping, no parity) is considered Just a Bunch Of Disks, or JBOD. They don’t make a whole lot of sense in most cases, but people still use them. They do not have the speed of striping, and naturally there’s no fault-tolerance. They are just a bunch of disks available for sequential storage of data, much like magnetic tape or an optical disk. In fact, using them as an interface between another sequential storage medium is one of the few things they do pretty well.

Throughout this article, I’ve used the term controller. The controller can either be a piece of hardware or some software running on the server. Software controllers are generally a poor option for most situations because the operating system and CPU of the computer have to process and manage all the data flowing to and from the disks. Mirroring is usually faster in this situation than striping, and adding parity to the mix bogs things down even more. Hardware controllers are much lower in price than they used to be, and should always be considered an important component in a server. Many server-class motherboards now offer RAID (at least RAID-0, RAID-1, and JBOD) support built-in. Even many higher-end desktop motherboards offer RAID support for SATA (Serial ATA) drives.

Summary
The three types of RAID you are most likely to encounter or care about are RAID-0, RAID-1, and RAID-5.

RAID-0 is fastest performer and the least expensive option, but it offers no protection against faults. It’s great for situations where you need a lot of speed and fault-tolerance is not very important. You might find it used for storing cached or temporary information that needs to be retrieved quickly, but is harmless if lost.

RAID-1 is just as fast as RAID-0, but because it requires twice the disks as RAID-0, it’s usually the most expensive option. If one half of the mirror has a problem, the good half takes over (temporarily becoming a RAID-0 array) until the bad half can be replaced. Regeneration of the mirror after a failure is usually pretty fast, and it may even be automatic.

RAID-5 is slower than RAID-1 because it has to write extra parity data to a disk in the array, but it only requires one extra disk total, no matter how large the array grows. Many controllers allow for hot swapping of bad disks, and like RAID-1, regeneration of the array is usually fast and automatic.

Innovative engineers have figured out ways to combine various RAID methods to improve performance or tweak other measurements, but most are based on some combination of these three methods (e.g., RAID-10 actually being RAID-0+1 or RAID-1+0).

RAID-1+5 is a little different. It uses RAID-1 (mirroring) for the first two drives in a server, and the operating system and applications are generally stored there. The remaining three or more disks use RAID-5 for storing data, since striping generally works well for storing frequently changing data.

RAID controllers are a built-in option on many server and higher-end desktop PC motherboards. If you have that option and your budget is tight, use it! Otherwise, spend the money for a better hardware RAID controller for more options and better performance. Software-based RAID is an option is most server operating systems, but performance is generally much worse than with hardware RAID, but may still be a better option than doing without RAID completely.

Some information was taken from WhatIs.com’s definition of RAID.

A client asked: Do I need a surge protector? If the power goes out sometime, what happens w/ the computer?

A surge protector is very important for protecting computers and other electronic equipment from damaging electrical spikes and surges. Fortunately this client already had one. Read the rest of the comments I wrote to her explaining the difference and dispelling the confusion surrounding surge protection and uninterruptible power supplies:

Perhaps you were thinking of an uninterruptible power supply (”UPS”, not to be confused with the brown trucks, of course). There are essentially two types of UPSes. One keeps a battery charged, and if it detects that the power goes out, then it switches over to the battery. It usually takes a few milliseconds to switch over. That may sound very fast to a human, but when computers operate in the millisecond (or faster) range, it can seem like quite a while. The second type of UPS has an Automatic Voltage Regulator (AVR) that charges a battery to continually run the computer. When the power goes out, the battery stops charging, but the equipment never feels a disruption. Your computer receives a continuous supply of pristine electricity. Naturally the second type costs a bit more.

UPSes are rated in VA’s (volt-amps) and Joules. Basically with VA’s, the bigger the number the longer your equipment will run during a power outage. Joules are more commonly touted with surge protectors, but they apply to UPSes, too. Again, the bigger the number, the better the protection against spikes and surges—even nearby lightning strikes in high-end ones.

One thing you generally don’t want to do is plug a surge protector into a UPS—at least into a low-end UPS. A normal electrical current cycles smoothly like an ocean wave from high to low and back again. Output from low-end UPSes (even ones with AVRs) usually produce electrical currents shaped more like square speed bumps. Square waves do not hurt your electronics, but they can cause problems if you plug a surge protector into a square-wave output UPS.

To summarize:

1. [The client has] a pretty darn good surge protector, so [the client is] protected from spikes and surges.
2. [The client is] not protected from sags and brown-outs (minor and major dips in the power), and certainly [the client is] not protected from power failures.
3. Bad power (especially spikes and full-power failures) cause the majority of computer data corruption. Data being written to a disk as the power spikes can be garbled. Drives writing to a disk during an outage, though rare, can write gibberish across the surface of the disk as they spin down (it happened to a computer I used to work on).
4. A UPS of any type will help protect you from complete power outages. UPSes with AVR will also effectively filter out sags and brownouts because the computer is always running on the battery. Non-AVR UPSes kick in when power drops below a certain point (some brown-outs are enough; some aren’t), and there’s always a slight delay, so you ever so slightly risk some data loss (it really depends on how sensitive your particular computer is to low-voltage situations—some are touchy; some don’t seem to notice).
5. It is okay to plug a UPS into a surge protector, but you should never plug a surge protector into a UPS unless the UPS produces pure sine-wave output (which consumer-grade UPSes will not).
6. Only critical devices (computer and monitor in [the client’s] case; possibly the printer) should be plugged into the battery powered part of the UPS. Other peripherals (notably speakers, laser printers, and anything non-critical) should be plugged into the non-battery protected part of the UPS or a regular surge protector. That way, you might lose your audio (speakers powered off), but you have maximum run-time for safely shutting down your computer and monitor.
7. Paying a little more for a UPS which can communicate to your PC and tell it to shut down if the power goes out can be very helpful if you aren’t home when the power goes out.

Preventive Maintenance Helps Safeguard Data
Most of our clients find the information stored on the hard disk is much more important than the hardware that stores the data. Taking steps to protect this information makes sense. That is what preventive maintenance is all about.
Preventive Maintenance Improves Security
Regular virus and spyware scanning is critical to keeping your data safe. Security patches and software updates are released several times each month for a variety of software. Some notify you, but others do not. All are important if you wish to stay protected. System and security logs give a wealth of information about the state of the equipment and the network. By checking the logs, we often spot potential problems early and avoid emergencies by fixing problems before they become noticeable.
Preventive Maintenance Improves Performance
Some aspects of computer systems degrade in performance over time. This has even given rise to the colorful term of “Windows rot“. Preventive maintenance helps improve the overall speed of system and network performance in these respects.
Preventive Maintenance Saves Money
You’ve heard the old adage “an ounce of prevention is worth a pound of cure.” It may be trite, but it’s also true. Avoiding problems saves you money in the long run, compared with laying out cash for new components or repair jobs. Emergency repair procedures can consume your IT budget at alarming rates. Most preventive maintenance procedures are quite simple, compared to troubleshooting and emergency repair procedures. This saves you much time (and stress!).