On Nov 8, 7:15 pm, "George K." <mrdel... RemoveThis @yahoo.com> wrote:
> CarbonCopy has an option to fix permissions before cloning. It was
> turned on.
>
> So if a software RAID makes my system HD less, not more stable, what
> approach should I take? My main reason for a spare is, it took me
> years and years to tweak the system HD into its current form. Its
> specialized work files took endless sessions to pick, assemble and
> refine from a pool of quarter a million. (The file list binder alone
> is 4" thick.) It's this intricate arrangement of work files, most of
> which OSX insists on keeping in various peculiar corners of its system
> drive, that make me want to create a spare as recreating this multi-
> year effort when the drive fails.
>
> (Of course, the idea of being able to just harness over and keep
> riding on a second drive if the first drive crashes has some allure to
> it too... :-)
Okay, you verified permissions before cloning, but did you very
permissions on your system once it was running from the mirrored drive
array? Some of the permissions will have changed due to the mirror,
and some permissions will have changed due to the larger hard drive
(at least, this is my "guess", as every time I've changed the size of
the hard drive being cloned to, permissions have had to be corrected).
Things you want to do:
1) Not loose an intricate arrangement of files and structures built up
over a period of years.
a. Back-up your documents frequently; given the volume of old
documents, you may want to do this as an incremental back-up.
b. Back-up your system and programs periodically; when there is a
change to your system or a program (i.e., new version), clone off a
copy you can recover from.
2) Make sure your back-up routine works.
a. I have seen major corporations lose years of expensive information
because they did not test to see if the back-up system they
implemented was actually capable of working.
b. Make sure you can keep up with your back-up strategy, i.e., you
need to have enough time to perform back-ups and space to store those
back-ups over time.
3) How frequently are changes made to:
a. Your operating system (including scripts added to the OS for added/
modified functioning)
b. Your programs (including scripts, palettes, suitcases, yada-yada)
c. Your data-sets (including get results, retained grep results from
currently available data, new pictures or pages, outputs retained from
modifying existing pictures or pages, etc. -- whatever it is you're
doing, how frequently does it change the non-operating system, non-
program data on your hard-drive into information? We're going to call
these your documents.)
4) Consider how frequently you merge data from your drives with other
repositories, CVS for instance, where other people may work on the
same over-all structure or even share specific tasks' details with
you? Do you need to synchronize with on-line (or off-line)
repositories?
Unix can make a hash of things if the system does not succeed in
copying all data from the storage and data I/O to the hard drive,
which is why most Unix systems that implement RAID not only use
hardware RAID controllers but use hardware RAID controllers which have
their own independent battery back-up, so that if power (for instance)
fails or the disk-write system fails, the data in the RAID
controller's cache remains there. People have thought about this
stuff, and through trial and error have got us where we are both in
philosophy and fine details; you might want to look at what's on the
market (RAID / data-storage), how it is supposed to work, and why it
is supposed to work that way--don't go nuts making a new job of it,
but maybe 20-or-30-minutes a day until you're comfortable with it.
My personal tip? Don't try to look at it from a bottom-up view, start
with a top-down view--look at the big servers, the big storage
arrays. Spend a couple sessions looking at the features offered by
one of SGI's big boxes, for instance, and work your way down their
catalog... then jump over to HP's corporate-server catalog... then
jump over to Dell's small-business catalog. By the time you've gotten
through those three vendors, you'll have a good idea of how this stuff
has scaled from large-to-small, and by the time you're in Dell's small-
business catalog, you'll actually be looking at hardware very
comparable to your dual-G5 tower. Expect along the way to spend a
session over at wikipedia learning what the terms you ran into last-
session mean, especially at first. Now you can look at what people
trying to take the bottom-up view are trying to do with their
products, and make a lot better guess as to whether it will suit your
needs in a cost-effective way.
Consider for a minute what you seem to have (Dual G5 with years of
carefully structured data accumulated to work just-so) and compare it
to the standards of dedicated mainframe systems, such as what got us
to the moon or keep track of our money in a bank. You're really not
far off in complexity data-wise, and G5's are actually adapted from
IBM's prior-generation mainframe CPU's (which is why the G6 was going
to be such a massive performer--and is, in non-Apple HPC use now); so
really, just look at what they would do to preserve data and data
integrity in the sort of environments your hardware and data would
customarily receive, rather than what the software-users typically do
in isolation. Scary, isn't it?
BTW, when you talk about a hard-drive crash, do you mean an
unrecoverable it's-not-rebooting software error (which is how I
usually take it from users), a hard-drive head-crash (which is how I
usually take it in the trade), or something else still? I once had a
Dell Precision workstation with a pair of faulty half-height high-RPM
SCSI drives...when powered on, it would start walking across the
carpeted floor it stood on, at 2-3 inches per minute. At another time
and another place, I administered a machine that ran a custom-written
program that addressed data to exactly the same space on the hard-disk
and would not accept any other space...so when that sector of the
drive went bad, Windows mapped around it, but the program wouldn't and
kept using it...so after a couple of days it made a sound for about 20
minutes, like a power drill going through an oak door...and
died...with three years of un-backed-up OSHA and IRS required reports
on that drive. A badly-timed audit could've been a real problem, while
that drive was off getting SQUIDed. Too bad the corp didn't listen to
me when I (as a temp) told them they needed to order back-up media.
They replaced their tape back-up drive with a DVD-RAM back-up drive,
and never bought DVD-RAMs or a back-up program. They had a drawer
full of really nice new high-capacity tapes and a reputable program,
but no drive to use them--for three years.
>> Stay informed about: Converting the Mac's System Drive into a RAID (OSX 10.4.10) 
FAQ
Search
Profile
Private Messages
Log in/Register/Password
