From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Cloning a system drive
Date: Sat, 6 Oct 2007 12:47:29 +0000 (UTC) [thread overview]
Message-ID: <pan.2007.10.06.12.47.28@cox.net> (raw)
In-Reply-To: 5bdc1c8b0710051943w4cd14241v795c599285891959@mail.gmail.com
"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0710051943w4cd14241v795c599285891959@mail.gmail.com, excerpted
below, on Fri, 05 Oct 2007 19:43:45 -0700:
> In my case I'm very noise sensitive. I do a lot of audio work and don't
> want additional hard drive noise in here. In my mind that rules out
> multi-drive RAID and I guess I don't see how any form of single-drive
> RAID helps if the issue is the drive doing bad.
Noise sensitive... go with lower RPM drives. Some Seagate 4200 or 5400
RPM drives may be good, and Seagate still has a 5 year warrantee while
many of the others are now one year.
Many drives are also adjustable for quietness vs. performance, if you
have the right hdparm or smartctl type utils to set them. I've not
bothered and it has been awhile since I read up on the details, so I'm a
bit fuzzy on them now, but many, particularly here in the US, would come
pre-set to the performance side. (In parts of the EU at least, I
understand there's some pretty strict regulations on workplace
environment including noise, and it's likely that some drives set for
performance in the US market come preset for toward quietness in that
market.)
Note that it's also possible to setup the drives in a separate external
enclosure and/or to house either that or the entire computer in another
room and run video and control cables. SATA/eSATA Five-drive external
enclosures, complete with their own power supply and fans, with hotplug
backplane (change out a bad drive while the system is in use), run $300
or so. Add another $100 and throw in a 5:1 SATA port multiplier so you
only run a single SATA/eSATA cable back to the computer. The computer
itself can then be much smaller/lighter/quieter, since it doesn't contain
the drives nor does it need to power them from its own power supply.
Another option: For RAID-1/mirroring, the ultimate in reliability since
the data is copied N-way, Linux makes it possible to declare some of the
devices write-mostly, and make them remote. The Linux RAID driver will
write to write-mostly devices as normal, mirroring the data to all
devices as usual, but will only read from the write-mostly devices if the
normal (non-write-mostly) devices in the array die or return errors.
This DRAMATICALLY increases mirroring flexibility, as provided you can
keep open a connection with enough bandwidth to maintain expected write-
rates, you can locate the write-mostly devices basically anywhere in the
world -- connected over the Internet or whatever if necessary. Want your
data automatically mirrored to your co-hosted server three states over,
to another in Australia, and another in Europe, thus ensuring the
ultimate in disaster recoverability? Not a problem! Connect them up
over the Internet and create write-mostly devices for them, and your data
will be auto-mirrored N-ways including to all those off-site backup
locations!
Of course, the same technology can be used to host a much-more-local
mirror as well, at the other end of the house or at your next-door-
neighbor's over Ethernet, or to your server located at work/home from the
other, over Internet. You get full data redundancy without requiring but
your single normal drive in your on-location computer.
If you combine write-mostly with a local but external SATA/eSATA solution
hosted in another room, even with heavy data needs, you can be as fully
redundant as you wish, with no drives at all in the computer itself, thus
lowering the weight/noise/power-requirements of the computer rather
drastically.
> Probably I'm not aware of all the value of doing all of that work. Maybe
> there would be significant reliability gains but it's a subject that is
> pretty far beyond me today.
That was my reaction too, plus the expense, until I had two drives in a
row go out in a year each, while my normal replace cycle would be more
like three years. That plus the now relatively low entry cost and
complexity, simple SATA drives and the kernel's own software RAID driver,
made actually possible what I hadn't even considered within my reach,
until that second drive overheated and I began doing research on a
suitable replacement with a bit more reliability. (The overheat killed
parts of the drive, basically the parts that it tried to read while
overheated, but I could still use the rest of it, including the second
copy of my data on the same drive, and was still operational on that, so
I had some time to research, but didn't want to press my luck...)
Basically, minimum cost now is the cost of the additional drive(s), as
long as your computer has spare SATA ports, drive bay space, and a power
supply sufficient to power the additional drives. Of course, for your
low noise needs, you may pay a bit more, but the cost is still only a few
hundred dollars total, reasonably comparable to that of getting a second
computer, not the thousands of dollars for Enterprise equipment one used
to think of in the context of RAID.
> I'm also has concerns that 1) the drive could go sooner than later
> causing me to have more work getting the system set up again
If your entire system is RAID-1/mirrored or RAID-10, and to a somewhat
lessor extent if it's RAID-1/5 or 1/6 mixed (as mine is, basically,
RAID-0 for the temp-only stuff, but that's not redundant and I know I'd
lose it if I lost a drive), particularly if you are running one of the
newer hot-plug SATA things, either internal or external, not only need
your system never even go down for a drive outage as you can replace it
with the system running, but getting out of degraded mode into full
redundancy protection once again can literally be as simple as turning
the lock and pushing the button to release the old drive in its tray,
taking it out of the tray and putting the new drive in, reloading and
relocking the tray complete with new drive in place, and running a couple
mdadm commands to tell the RAID driver to add it as a spare and
reinitialize. Then it's simply a matter of waiting the few hours of
still operational but degraded performance until the new drive is brought
online fully up to speed.
Restating in briefer form, simply push a button, slide out the old drive
and replace it with the new, tell mdadm it's now part of the RAID, and
wait thru a few hours of lower than normal performance until it's brought
online and the system is fully recovered.
No need to even reboot; it's all accomplished "live", with a couple of
button pushes and issuing a couple of commands, plus a few hours of
somewhat lower than normal performance as the new drive is brought up to
speed. That's it! More work? No, LESS work, by FAR!
While that is the simplest case, full RAID-1 mirroring, if you skimp and
go RAID-5 or RAID-6 due to cost, mixed with a RAID-1 for /boot and
perhaps a RAID-0/striped for speed for your temp stuff, you do add a few
more commands, mainly fdisk to set up the partitions for the mixed RAID
before you add the new disk to the RAID, you lose the temp stuff on the
RAID-0 and have to rebuild that, and you need to reboot after the fdisk,
but the copying over of your data remains fully automatic, and it's still
far less work than recovery from a single main disk going bad could every
be.
> and 2) if I do add some form of RAID that it will cause problems for
> the cloned Win XP installation being it isn't there now.
Well, if you use Linux-kernel RAID, of course you do lose the ability to
read it from MS, and even using hardware RAID, there's the eXPrivacy anti-
privacy activation hoops you have to go thru... You certainly do have a
point there!
Of course, that's one of the big reasons I left MS and switched to
Linux... that was a line I simply could not and would not cross. I simply
refused, and when MS insisted, as with any relationship where one partner
makes demands for something the other simply cannot and will not do, it
ends the relationship. Needless to say given no other choice, we parted
ways. So I have MS to thank for finally pushing me to Linux. Oh well,
their loss as I spent a decent amount of money on them, my ever so great
gain! =8^)
> And how does LVM work for Windows anyway? I thought that was a Linux
> thing?
It is... unless you are running one in a VM on the other, of course.
Then the host system supplies the devices and drivers. =8^)
> Maybe everything Duncan said is right, and I'll give it some thought,
> but my #1 worry is trying to make sure the system doesn't go down hard
> and leave me with a week's worth of work getting Humpty Dumpty back
> together again that I don't need right now.
Of course, you know I'd be dumping MS, but it's your system and your
choices to make. In any case, I'd certainly consider buying a separate
system to run MS on (or run it in a VM... you may actually be surprised
to find it runs faster in a VM than it does on the bare metal -- provided
you have sufficient memory, of course). Either your MS or Linux side is
likely sufficiently low demanding to run on what is now days a fairly
cheap system, even new, so the option shouldn't be more than a few
hundred dollars.
Actually, I intended for that to mainly convey the message that my
relatively basic new-drive transfer method, three steps partition/mkfs/
conventional-copy, has served me very well for many years and over a wide
variety of implementation details, including my new mixed RAID/LVM
setup. It was therefore intended to be less about the RAID/LVM, which
was supposed to be simply an incidental mention, and more about the
simple partition/mkfs/copy transfer method, but that's not how it turned
out, obviously. =8^?
In any case, if you are keeping eXPrivacy on there and want to continue
to run it on the bare metal and not in a VM, and if you need most of your
Linux side to be eXPrivacy accessible, that's going to limit your options
somewhat and the LVM/RAID stuff definitely won't be as practical as it
could arguably be if you were Linux-only. I still think the basic
partition/mkfs/conventional-copy method is simpler than most of the
others, tho, particularly since you don't have to worry about additional
software, and the repartitioning will allow you to better adapt to the
larger drive than straight imaging, or even using dd and then growing the
partitions.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-amd64@gentoo.org mailing list
next prev parent reply other threads:[~2007-10-06 13:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 20:58 [gentoo-amd64] Cloning a system drive Mark Knecht
2007-10-05 21:14 ` Dieter Ries
2007-10-05 22:46 ` Drake Donahue
2007-10-05 23:07 ` Mark Knecht
2007-10-06 1:00 ` Drake Donahue
2007-10-06 12:22 ` Dieter Ries
2007-10-06 1:53 ` [gentoo-amd64] " Duncan
2007-10-06 2:35 ` Richard Freeman
2007-10-06 2:43 ` Mark Knecht
2007-10-06 12:47 ` Duncan [this message]
2007-10-06 13:16 ` Mark Knecht
2007-10-07 3:58 ` Drake Donahue
2007-10-07 4:49 ` Peter Davoust
2007-10-07 9:33 ` Duncan
2007-10-07 18:34 ` Brian Litzinger
2007-10-08 9:17 ` Beso
2007-10-08 16:17 ` Brian Litzinger
2007-10-08 16:28 ` Mark Knecht
2007-10-08 16:43 ` Beso
2007-10-08 22:39 ` Peter Davoust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2007.10.06.12.47.28@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox