(e-mail address removed) (Bob) wrote in server.houston.rr.com:
I do not understand. I would expect a so-called "mirror" to be a
carbon copy of the disk being mirrored.
OK. I'm just trying to explain the issues you may run into with a mirrored
drive. If you don't want to read the long version, I'll sum it up here.
The short version is this: Backup software has more options than mirrored
disks. With a mirrored disk, you have only one recovery method, and either
it works or it doesn't. With backups, you have many more choices: what
gets backed up, how much, how often, how long, when, and where to. You can
have multiple choices for each. And this gives you multiple recovery
options.
Here is a typical recovery process for a mirrored drive and things to watch
out for. First you need to mount the mirrored drive to get anything off
it. For many controllers I've used, the drive will only mount in the
position where it was originally located. That is to say connected to the
same channel and position on the controller, same drive bay on the server.
That means pulling the current drive out, putting the old one back in. If
you want a combination of data, some from the old, some from the current,
you need to put stuff in a temporary third location, swap drives again,
then move it back to the final destination drive. Don't have a temporary
3rd storage location? You'll need to make one if you want to combine data
from both old and new drives.
During this time, it might not be possible to use the system, depending on
what apps you run. If it's something like a business system doing live data
capture, point of sale, ATM transactions, etc, you don't want to start
putting new data on top of an old database, when your current data is not
present. You end up with data in 2 locations, when you need it in one, and
may have no way of reconciling the transactions back into a single
database. So if you are a person with an app like this, you are basically
shut down until you complete the data swapping process I mentioned above.
Some individuals may not care. For others this downtime is not acceptable.
Also there is a risk that one of the disks might be accidently written to
during the process. It could be minor, it could wipe the disk.
Some controllers are smart enough allow you to put the drive in a different
bay. But that's only if the bay is configured for the same type of RAID
config. Even then, for the controllers I've used, it requires you to force
the controller to allow the drive to be connected where it was not
originally. I've seen server admins select the wrong menu choice in the
RAID controller and initialize the disk instead of force it to be
recognized. Ooops. There goes the backout.
But if you have a controller that can do this, and get the OS to see both
the current drive and the old drive at the same time, then you can use it
and pull files off it just like a backup, and not have to deal with the
temporary storage location that I mentioned above. Until you get to that
point though, the pulled drive is a very different beast from a "backup".
It only works in the system that created it, and it's an all or nothing
situation. Until it's mounted and working, you have the whole drive or you
have nothing. There are no other options. For some that's OK. For others
it's not.
I typically use mirrored drives all the time at work. I use it to "clone"
servers and also as a backout before making any OS or software updates to a
server. Before the change, a drive from every server gets pulled and
labled. Another drive gets put in it's place and mirrored up. Make the
changes. Do the testing. If the changes cause problems, revert to pulled
drive. If not, leave the servers for a week. Hold on to the pulled drives
for a week. Still no issues after a week? Release the pulled drives and
allow them to be reused.
But, we don't rely solely on pulled drives. Every server is built with a
disk image that gets backed up, and automated application installs. So
even if we lost the mirror, we can get the server back with an image and
re-installing the apps. On top of that, every server build is documented
on paper. So even if we lost the ghost image and app installs, we could
still rebuild it following the documentation to build it.
Now, most people don't need to do this at home, but believe it or not, some
do. For my friends that all ask for computer help, I make sure I only ever
rebuild their system once. At that point I do a disk image so that
whatever they might do in the future, I'll only have to restore that image,
not a full re-install. I burn multiple copies of the image on CDR. It
only saves me time down the road.
For my own computer, I already use disk images. But I also document my
base OS builds. Options chosen during OS install. Any BIOS changes needed.
Drivers and versions installed. Windows Updates installed. Any Windows or
Device / Network configs changed or tweaked. And the "Must Have" apps
installed. I burn all of this on to multiple DVDRs (Build Doc, OS
installs, Driver installs, App installs, Tweaks). So if one day I loose my
OS, I can restore from a ghost image on the other drive. If that's also
toast, I have a ghost image on DVDR. If that's toast, I have multiple
DVDRs with installs and docs. Several things would have to break before I
wouldn't be able to restore my PC. My important data gets backed up to
multiple locations so if one fails I have another place I can go to.
In defense of RAID, one big thing it it's favour is it's automatic (if it's
working right). It's not like a backup where the scheduler might fail for
whatever reason. It could fail for something as simple as an open file
that you wanted backed up. You know RAID is either working or it isn't.
Open files are not a problem for RAID. But they can be difficult to open
again if you don't close them before pulling the drive. Some databases
don't know how to re-open a db that wasn't properly closed. So often
people will shut database apps down before pulling a drive.
