public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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