Windows 7: RAID or Mirror Across Computers?

Where to put the data ... hmm.  I had a home network with two computers running Windows 7.  If the data I needed to work with was on one computer and it went down or had one of those frequent Microsoft maintenance or service interruption needs, I couldn't get to it from the other computer.  But if I put the data on a server, then (a) I had to buy and maintain the server, cables, routers, etc., (b) I had slower access times, (c) the data would then be unavailable to *both* machines (unless I wanted to swap out one or more hard drives) if the server went down, and (d) I had found that, if I accidentally corrupted or deleted the wrong file, a server might not be willing to undelete it.  Not a big deal, assuming you had good backup, but there were painful exceptions.

So it occurred to me:  can you put the data on one computer, so that it can function as a standalone, and also put the data on the other computer, so that it is a standalone too, but then have a constant RAID or mirror arrangement between the computers, so that whatever you do with the data on one computer is immediately duplicated on the other computer?  That way, you've got local speed, no server, and redundancy during downtime on either machine.  Basically, two-way mirroring:  when a file is modified, it checks the other computer, and the two of them figure out which version is newer, and it overwrites the older version on the other machine as well.  All you need is a router, if that.

I figured possibly everybody else already knew the answer to this.  But since I didn't, I started with a search.  Only six hits.  It looked like the concept of "RAID between computers" was a nonstarter.  Alright, a different search.  Wow, "mirror between computers" produced 13 hits.  But, OK, not to complain, it seemed most of those hits were for TreeNetCopy.  Take it out of the equation, and the search produced only five hits.  So TreeNetCopy seemed to provide the path forward.  But it didn't look like CNET, PCMag, or other big-name sites had reviewed it.  I went to the product's home website and found out why:  it was for systems using Windows NT or Windows 2000.

Apparently mirror and RAID were not the concepts I wanted.  How about incremental backup?  You couldn't have it running constantly; it would have to finish one scan of the system's files before it could start on the next one.  So maybe you'd set it to run every 15 or 30 minutes, or however a scan would take to finish, across the network connection.  This wouldn't be nearly as good as software that would detect and propagate changes as soon as they were made, but I wasn't seeing how to find anything like that.  With a 15- or 30-minute delay, you couldn't have someone being able to open the file on computer B as soon as someone else updated it on computer A, unless possibly if you had a script that would somehow be able to run the incremental backup manually for a given folder by just maybe choosing a right-click context menu option.

Alright, a different approach.  I had been using Beyond Compare, a file comparison tool.  It still looked like one of the more capable file comparison tools, so how about using it?  As I was thinking about that possibility, I realized that I didn't like the idea of having to do a right-click or other manual update.  The computer could crash before I got around to that, and then I wouldn't have the current data in the parallel folder on the other computer, and therefore really couldn't just keep right on working where I left off.  I had only used Beyond Compare as a manual comparison tool, where I would start it up and it would run for a while and compare directories and then show me what needed to be mirrored to my backup drive, and then I would click the buttons necessary to do that.  I knew it was possible to write scripts to automate some of this, but it seemed unlikely that scripts would help Beyond Compare remain up-to-the-minute on all of the file changes made on the system.  Most likely, I could set up scripts to run in some frequently used folders, and maybe even to automate the mirroring of those folders, but other folders would be left out in the cold.  Possibly I could have multiple scripts doing comparisons of more- and less-frequently used folders on different schedules, so as to increase the likelihood that most folders would be mirrored relatively often.  But with enough scripts running simultaneous file comparisons, I'd start to take a performance hit.

Lacking a better option, I did a search to learn more about Beyond Compare scripts.  The search came up with a number of interesting concepts, right there among the top ten hits.  One was the concept of automated synchronization.  Duh!  Of course.  Synchronization was the Windows term for what I wanted.  So I did a search for that, dropping Beyond Compare for the moment.  But the only thing that came of it was the discovery of Super Flexible File Synchronizer, which cost $60 for a two-year license (unless, for some bizarre reason, I would think that I could do without the pro version's ability to copy ZIP files!).  It did look like it might have some advantages over Beyond Compare, such as the ability to detect that I had moved a folder, so that it could just repeat the move rather than delete the folder from one location and create it in another (which might involve a lot of copying, if it was a large folder).  It had very good ratings on CNET.  I could download and try it out free for 30 days.  But it was ultimately still a backup program, running on a schedule, not a mirroring program, so I was still basically working with the same scenario:  design a set of backup scripts, profiles, or whatever, and set them to run at different frequencies, backing up what I would consider the most heavily used folders most frequently.

TopTenReviews ranked Super Flexible File Synchronizer eighth in its list of sync programs.  Their comparison page had a number of relevant criteria, including the ability to do bidirectional sync, to mirror files, and to operate across a network.  It actually looked like their number two program, GoodSync ($19.95), had better features for my purposes than their number one choice, Syncables 360 ($39.95).  Their review of GoodSync made it sound good indeed.  They said it couldn't sync or merge Microsoft Outlook files, which was OK because I was using Thunderbird.  (Later, I encountered a review by a user who said s/he was using it for this purpose, so I assumed they had updated the program.)  They said that working over networks could be complicated.  I wasn't sure if they meant that as a generic remark that would be relevant to all kinds of work over networks.  They seemed to rank it number two rather than one because it "lacks some of the advanced features professional users expect."  CNET's review likewise ranked it number two, but in the category of "file management."  I wasn't sure what they considered the number one program; their webpage didn't indicate which criterion they used for that ranking.  But GoodSync was the most frequently downloaded program during the prior week.  GoodSync's awards webpage mostly listed awards and positive reviews that were at least a couple of years old.  So apparently it had been created and was now coasting.  I did a search among its many reviews on CNET, looking for more info about using it on a network.  Unfortunately, CNET's links to specific reviews weren't working for me at that point, so I wasn't able to get details, but what I was able to read from the summary results was positive with the exception of one person for whom GoodSync did not work well.

There were hardware options.  SyncSharp offered a device that would synchronize via USB.  It sounded similar to The Tornado and to the Windows 7 Easy Transfer option.  I didn't want an additional device, and since ethernet was faster and was already in place, I didn't want to use USB.  For purposes of speed and also capacity, not to mention reducing dependency on external data sources, I was obviously not going to be interested in a cloud (i.e., web-based) solution, even if I had found one that offered constant, continuous, real-time synchronization.

It turned out that CNET had another category, for "data transfer & sync software."  As with some other CNET searches, I looked at the top 30 both in terms of downloads last week and user ratings.  Setting aside those that were for special purposes (e.g., Blackberry, Outlook), and focusing on those that were for Windows 7, I found that only two were free:  CopyTo Synchronizer, which had only two votes and which I therefore deemed insufficiently tested, and Microsoft Live Mesh, which had only one vote but which I was willing to assume was better developed.  The nonfree alternatives that came up in this search included BeyondSync, ViceVersa Pro, Easy Computer Sync, and Syncables 360 Premium.  I reduced this set to Live Mesh, Beyond Sync, and ViceVersa.  A search for further information on Live Mesh suggested it was web-based, more like DropBox, leaving me to focus on the other two.  A search led back to a TopTenReviews comparison -- it may have been the same one as before, but a couple of weeks had passed by thie time -- naming GoodSync (above) as No. 2, ViceVersa as No. 5, and BeyondSync as No. 10.  Of the ten, the ones offering bidirectional sync, network synchronizing, and Windows 7 support were these three plus Syncables 360, SugarSync, Laplink, and Super Flexible.  Most of the same names also appeared in a CEOWorld review.  I eliminated SugarSync as another cloud solution.  The TopTen review for Beyond Sync made it sound unappealing.  A dotTech review echoed that. 

I ran a search looking for comparisons of Syncables against the others that also sounded good for bidirectional synchronization.  A couple of reviews alerted me to the feature, evidently present in GoodSync but not all others, of being able to see which changes would overwrite.  I began to get a sense that Syncables was more of a glossy product, designed for people who wanted simple and trouble-free synchronization without necessarily having an option to scrutinize every step of what was happening.  Having been burned by the occasional backup program that would not save (and would also not tell me that it was not saving) files of a certain kind, or nested too deep, or had an umlauted character in their filenames, or were otherwise secretly exempt from what I thought was happening, I had become more inclined to use transparent software.  At least until I gained a lot of trust and experience with a program, I wanted to see what it was doing.  So this feature of GoodSync appealed to me.  I noticed, also, that a review described Liuxz Sync as being "of most use to users that need to carryout real time synchronizations over a network or between hard drives."  As I continued to look at other opinions, ViceVersa still sounded relatively good too.

On this basis, I decided to start with GoodSync, as described in a separate post.  After some days of using it, and comparing its results against an external backup drive via manual comparisons using Beyond Compare (as described in more detail in that other post), I concluded that GoodSync was a good product for this purpose.  I set its sync rules so as to check most frequently those partitions in which I was most likely to make changes.  For practical purposes, I could change files on one computer and I would see those changes on the other computer when I went looking for them.

In short, I wound up using GoodSync to synchronize files on two computers on a home network.  The files were generally available on the other computer within minutes.  I did this without using a server.  That is, the files were available locally on each computer, so that I could keep right on working if the other one went down.  I arranged backup via external drive, and I occasionally checked that external drive against the internal drive manually using Beyond Compare.  I had better performance than on a network, and was not very vulnerable to network problems; presumably I could have set up the same arrangement via crossover cable, without even having a router.  This really felt like a solution that I had been seeking for years.

Ubuntu Do-It-Yourself Network Attached Storage (DIY NAS): A Preliminary Look

I had just done an enormous amount of work in an unsuccessful attempt to get a Synology DS109 network attached storage (NAS) device to work in my Ubuntu 10.04 system.  It was an expensive unit, on my budget, even if it was near the bottom of Synology's line of products, so I was hoping for good things from it.  But I was not able to figure out why it wasn't connecting with my computer.  So while waiting for a reply from Synology's tech support, I did a search for do-it-yourself (DIY) alternatives.  This post describes a bit of what I found.

What I was hoping to find, in a DIY alternative, may be summarized in this excerpt from the previous post:

I decided to go ahead with the Synology project for now; I could return or sell the device if it really wasn't what I wanted.  I probably could have assembled another computer at equal or lower cost, with far greater potential storage capacity, with more RAID options, with a more powerful processor (for e.g., checksum calculations) if needed, with what might prove to be more options in the choice of software packages and commands to manage and adjust it, and with more flexible hardware troubleshooting options (i.e., more than just fix it or replace it) in the event of malfunction.  Its drawbacks would include time and expense for software and hardware selection, learning, installation, maintenance, and troubleshooting; physical space requirements; power consumption; and noise and heat generation.

If the Synology unit had been easy to use, I wouldn't have been able to generate that list of potential advantages of a DIY alternative.  I accumulated that list during the process of writing up the hassles I was having.  So now it was a question of how true those observations really were.

One thing for sure:  if I had taken seriously the idea of building a NAS myself at the outset, I would not have bought the Synology unit.  I did, in fact, have an old computer sitting around, one that I rarely used, mostly just for troubleshooting random hardware problems.  I was willing to convert it to another function. So, right there, I did have much of the hardware that I would need.  Its case design would accommodate a number of drives, if I decided to build a RAID NAS that would require that.

That took care of some of the objections to a DIY NAS.  What about space, noise, heat, and power?  There was no comparison:  the Synology was such a cool, quiet, sleek little thing compared to that whole computer case and its monitor and keyboard.  Even if I put the peripherals in a drawer and managed the server remotely (assuming that was possible), there was still the noise from its fans and power supply.  The trade-up in expandability and flexibility (with e.g., RAID) would come at a cost.  And that was the real question:  did I want the additional capabilities badly enough to accept the drawbacks?

Then again, it occurred to me that I didn't absolutely have to have the server remain on constantly.  Couldn't it hibernate during slack periods?  For noise reduction, couldn't I park it in a closet?  This seemed like something worth experimenting with.

What about hardware hassles?  I could probably just plug in the drives and, optionally, a RAID controller and be done.  The Synology unit did not have a RAID option, and it did not come with a drive.  The DIY NAS would have more things that could fail, but failures did not happen often, and with an optional RAID setup it would be better equipped to absorb them.  In terms of hardware, the DIY NAS was the winner.

And software?  The Synology software package had a nice GUI that, for all its good looks, had managed to confuse me and had thus failed to deliver a working solution.  If the Synology people came through on my tech support request, I would be ahead of the game there; but my request had been so broad and confused that I doubted they would be able to help much.  If it was a matter of devoting another five or ten hours, I was leaning toward trying something new, rather than beating my head against the wall with more efforts to understand the Synology software.

I decided, though, that I had probably better take a closer look at the software I would be using.  Ubuntu came with software RAID, and I had already had a bit of experience with that.  But what about NAS -- what software would I use for that?  I had gotten the impression that NFS was a good alternative to Samba for a Linux network -- simpler and faster, but possibly not as secure and apparently not as good for interfacing with Windows machines.  The Synology unit used NFS.  But this didn't really answer the question.  What software -- really, what operating system -- would I use to manage the DIY NAS?  Sources cited on the Wikipedia page for FreeNAS made it sound like a great solution.  It was apparently UNIX-based, and thus was some kind of cousin to Ubuntu, but it seemed I would have to invest some additional time to learn FreeNAS.  Ubuntu Server seemed like a more familiar, better-supported, and more flexible alternative.  Openfiler was another possibility.  A lot of people swore by Windows Home Server; I just didn't want to pay $100 for the privilege of going back in the direction of relying completely on Microsoft software.  Going in a different direction, there also seemed to be routers with hard drive connections, though I wasn't fond of the USB connection offered by the one I saw.

Those thoughts led to a thread that made me ask whether I wanted an NAS or a home server.  The tradeoffs described above were echoed in another thread I found, but now the discussion had mutated a bit.  If I was going to use a computer as an NAS, it seemed I might as well make it a home server.  In fact, that's probably how I had been thinking of it anyway:  a machine that could do whatever a computer could do, including RAID as well as NAS.

By this point, a couple of things had happened.  I had downloaded a copy of Ubuntu Server and had decided to try setting it up on that old computer, to see how easy it would make things for me in terms of network storage and RAID options.  I had read enough webpages to persuade me that setting up a home server could be somewhat time-consuming and thus would ideally be approached, for my purposes, as a longer-term project:  install the operating system, tinker with the hardware, and gradually move toward comfort with its maintenance and other requirements.  And I had heard back from the Synology people via email, not once, but twice in the space of three hours in the evening, East Coast time.  They were offering to set up a TeamViewer session with me for the next day.  So my working plan, at this point, was to get the Synology going, if I could do so the next day.

Installing RAID 0 in Ubuntu 10.04 (Lucid Lynx)

In a previous post, I was working toward having a dual-boot Windows XP and Ubuntu 10.04 system, with a RAID 0 array for at least the Ubuntu installation.  Here, I describe the process I went through to set up that array.  I had previously had a WinXP/Ubuntu dual-boot system on a single Western Digital Velociraptor drive; the main change here is adapting that to the RAID scenario, and seeing whether this would be faster.

I started with a very helpful video by amzertech.  (Actually, two videos.)  I have provided a detailed description of the process (below).  To summarize, I had to boot the alternate Ubuntu CD and use it to install root ("/") and swap partitions on each drive in a RAID format, along with a /boot partition on one drive.

Troubleshooting

It all seemed to go pretty smoothly, and certainly other people seemed to have had good luck with that video.  But when I was done and I tried to boot the system without the CD, I got "error:  no such disk" and then a "grub rescue" prompt.  And in the FastBuild Utility discussed in the previous post, I was no longer seeing two drives configured into one logical disk set; they were back to being two separate JBOD ("just a bunch (or a box) of disks") drives.  So it seemed that what I had done previously was not necessary.

After digging around in a search, I found a post where they said the problem got solved for them by undoing the BIOS edits I described in the previous post.  So I rebooted, hit Del, went into the BIOS > Integrated Peripherals and set the OnChip SATA Controller to Disabled.  This greyed out the other two items that I had changed and put them back into their previous settings.  I saved and rebooted.

This time, I got "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER."  A search led to a Tom's Hardware thread where they advised, among other things, adjusting the boot order in the BIOS.  So I tried setting the hard drive to boot first, instead of the CDROM drive.  But I got the same error again on reboot.  That thread contained many other suggestions:  update your motherboard's BIOS, make sure all cables are firmly connected, disconnect all other drives, use other software (e.g., Disk Boot Manager), check that the jumpers on your hard drives are set correctly (at least if you're using PATA drives, which I wasn't), fiddle with BIOS settings, etc.

The BIOS update was a possible solution, but I began instead by rearranging cables a couple of times.  My goal there was to match up the hard drive on which I had installed the /boot sector (I didn't know which of the two it was) with the lowest-numbered SATA connector on my motherboard (i.e., SATAII0 as distinct from SATAII1, SATAII2, etc.).  But that didn't do it either; still the DISK BOOT FAILURE message.  I also tried going back into the BIOS and setting Hard Drive as the first, second, and third boot options.

Following some other suggestions, I went back into BIOS and enabled the OnChip SATA Controller as Native IDE type (even though they were SATA drives).  This gave me a new error:  "MBR Error 1.  Press any key to boot from floppy."  I tried reversing the cables, in case I had the drives in the wrong order.  And that did it.  Success!  Ubuntu booted.  I restarted the computer, set the BIOS back to boot first from USB, second from CDROM, and third from hard drive (as it had been previously), and thus verified that the solution seemed to be as follows:  set BIOS to Native IDE type, and make sure the drive with the /boot partition is connected to the first SATA connector on the motherboard.

Assessment

In Ubuntu, I went into Synaptic and installed GParted.  I took a look at what had happened.  I had used two 640GB drives for my RAID 0 array.  In an earlier time, this would have been extravagant.  By now, however, prices on such drives were in the basement.  But I did still wonder if I could use the rest of these drives for some other purpose.  I had allocated an absurdly large 100GB space (50GB per drive) for my root partition -- leaving a total of more than 1TB unused!

So now, in GParted, I saw three drives:  md0, sda, and sdb.  md0 was a net 93GB, with no further information.  sda essentially had the partitions I had set up in the RAID setup process:  the root partition, the /boot partition, the swap partition, and about 540GB left over.  sdb had its own matching root and swap partitions, though they were labeled as having an "unknown" file system, and a matching 540GB unallocated.

More RAID Partitions

Could I use that 1TB of unused space?  I wouldn't have put my data there -- RAID 0 had twice the risk of data loss, in the sense that either drive's failure would take down the array -- but there were some other possibilities.  In particular, I could store my VMware virtual machines (VMs) there, as long as I kept backup copies elsewhere; they would run faster on the RAID array.  And I also wanted to set up a separate /home partition.  But should I have created these partitions while I was going through the initial RAID setup?  And could I store anything on just one hard drive or the other, or did everything on these two drives have to be set up in a RAID format now?

I decided not to research the option of storing things on just one drive or the other at this point.  Apparently it was possible, and could even be done after the fact from within Windows XP.  Since there would be a lot of completely unneeded empty room left over after this RAID installation, I would just let it sit on the drives as unformatted space for the time being.  But for the VMs and anything else (video editing files?) that might call for the performance of RAID 0, I decided that I did want to make use of some of that space.  And I wanted it to be in separate partitions, for backup purposes, not part of the Ubuntu RAID installation mentioned above.  I figured the contents of these partitions would change more frequently and would require a different backup schedule than what the root program installation would need.

RAID 0 Setup:  Detailed Description

So now that I had my BIOS and my drives and everything else in order (above), I restarted the process of setting up the RAID 0 array, and this time I took notes.  I booted the alternate CD and went into Install Ubuntu.  I went through the initial setup options (language, keyboard, etc.).  When it got to the partitioning screen, I chose Manual.  Now I saw that, actually, I didn't have to undo what I had already done.  The 100GB RAID 0 device I had already set up would be just fine.  I could just arrow down to the FREE SPACE items and add stuff there.

So I did that.  For each of the two drives (sda and sdb, on my system), I selected FREE SPACE and hit Enter > Create a new partition > 50 GB (giving me 100GB total) > Continue > Logical > Beginning > "Use as" > "physical volume for RAID."  Then I chose "Done setting up the partition."  Then, back in the Partition Disks screen, arrow up and hit Enter at "Configure software RAID" > Yes.  Next, Create MD device > select the two items shown as 49999MB (i.e., about 50GB) > Continue > Finish.  This put me back at the Partition Disks screen again, but this time I had a new RAID 0 device of 100GB.  I selected that device, hit Enter > Use as > Ext3 (more reliable than Ext4) > Enter.  I set the mount point to /home and the mount options to relatime and labeled it UHOME.  Then I selected and hit Enter on "Done setting up the partition."  I repeated this process, starting by selecting FREE SPACE, and created another pair of 200GB logical partitions that I labeled as RAIDSPACE and set it to mount as /media/RAIDSPACE.  My VMs would go on a folder in this partition.  I still had 700GB left over, but at least I had made a stab at converting some of that unallocated space to a useful form.

I noticed, in this process, that my previous root partition was no longer set as root.  I configured it again.  Now, when I went to Configure software RAID, it seemed that Ubuntu was going to be reinstalled there.  I went ahead with that.  With those changes made in the Partition Disks screen, I arrowed down and selected "Finish partitioning and write changes to disk" and hit Enter.  It gave me an option of formatting the root partition, but since I had already installed Ubuntu there, I didn't want to do that.  This put me into an empty blue screen for a while, but then it began installing the base system.  So maybe I should have let it format the root partition after all.  It went through the installation process and then told me that this seemed to be the only operating system on this computer and asked if it was OK to install the GRUB boot loader to the master boot record.  I said yes.

When it was done, it went into Ubuntu.  I reinstalled GParted and took another look.  It looked like I might have done something wrong.  The only md device was md0, the 93GB partition from before.  It did show the UHOME and RAIDSPACE partitions on sda, with matching Unknown partitions on sdb, all with RAID flags next to them.  Nautilus showed RAIDSPACE as a legitimate partition with 348GB free (19 GB used already!).  But no, everything seemed OK.

Bringing Stuff Over to the New Installation

I shut down the machine, connected a disk containing files from my previous system drive, booted with a live CD, and copied some things over. Specifically, I installed a third hard drive and, while booted with the live CD, used GParted and Nautilus to prepare a partition on it and then copy over all of the files from my previous machine's Windows XP installation.  I tried to copy the /home partition from my previous installation, to replace the contents of the /home partition in the RAID array, but the array was not accessible from a live CD boot.  So I copied the previous /home folder to that newly installed third hard drive.  (I knew that the previous system drive was bootable, so I would not start the system from a hard drive (i.e., without a live CD) while that one was connected, lest it screw up my new installation.)  I got an error message for just one file, a Google Earth file:  "Can't copy special file."  A "special file," according to Andreas Henriksson, was something like a pipe, device node, or socket.  I would be reinstalling Google Earth anyway, so this was no problem.

When those copy operations were done, I disconnected the previous drive and rebooted from the hard drive, this time with an external USB drive connected.  The external drive contained my previous fstab and some other materials that I needed now, as I began to work through the Ubuntu post-installation adjustment process described in another post.

The first step of that process required some adjustment for the RAID situation.  The /home partition in the RAID array wasn't available via live CD.  So I tried the technique of commenting out the regular fstab line for /home and replacing it with a reference to /dev/md2 (where the home partition was to be) and /home_tmp (instead of home).  I typed "sudo mkdir /home_tmp" and then rebooted.  Now, if all went well, the system would think its /home folder was in /home_tmp.  On reboot, I typed "sudo Nautilus," went into /home (not /home_tmp), deleted its "ray" folder (my username), and replaced it with a copy of the "ray" folder from my previous installation.  Then I typed "sudo gedit /etc/fstab," deleted the line referring to /home_tmp, and rebooted.  Then, in sudo Nautilus I deleted /home_tmp and rebooted once more.  All was good:  my settings from the previous setup were back.

I proceeded through the remaining steps to configure my new Ubuntu installation, as described in that other post.  The RAIDSPACE partition was not available to me as a normal user, but I wanted it to be, so I typed "sudo nautilus," right-clicked on RAIDSPACE, and changed its permissions.  Then I copied my VMS from the external drive to a VMS folder in RAIDSPACE.  I was getting an error message on reboot, "Ubuntu is running in low-graphics mode," when it did not seem to be.  Also, I noticed that the GRUB menu was no longer remembering the operating system that it had last used; it was defaulting to Ubuntu in every case.  I was not the only one who had this problem in RAID.  But otherwise, the previous post pretty much covered the adjustments required to get my system back to normal.

As mentioned above, I had copied over the Windows XP files from what used to be my system drive to the third hard drive now installed in this computer.  When I ran "sudo update-grub" to consolidate the changes I had made to the GRUB2 menu while making those adjustments, it said, "Found Microsoft Windows XP Professional on /dev/sdc1."  GParted said that sdc1 was the right place -- it was the NTFS partition to which I had copied those files.  I wondered if just copying WinXP files from one drive to another in Ubuntu was sufficient to create a working WinXP installation in the new location.  So now I rebooted and, in the GRUB2 menu, I chose Windows XP.  And, what do you know, it worked!  Just like that.  No GRUB errors or anything.  I had to adjust a few settings in WinXP, but for the most part things were in good shape.

The Acid Test

So that seemed to pretty much wrap up the process of converting my dual-boot WinXP/Ubuntu system from a single hard drive to a RAID 0 array.  I was sure there would be other changes to come, but it was time for the acid test:  I wanted to see how VMware Workstation performed in the RAID 0 environment.  It had been dragging, functioning very slowly for a long time, in the computer that this one was going to replace.  It had run more quickly on this replacement computer in the single hard drive setup.  No doubt the Velociraptor helped.  But how did it do in the dual drive array?

Let me say, first of all, that the general startup process in Ubuntu was darn snappy.  I noticed it right away.  Boom! my startup programs all came to life pretty smartly.  Inside VMware Workstation, likewise, performance seemed faster than it had been in native WinXP on the Velociraptor.  I was sure there would be much additional learning, but this had been a real step forward.

Ubuntu 10.04: Creating a Separate Home Partition

I was reinstalling Ubuntu 10.04. In the previous installations, I had gone with the default approach. In particular, I had kept the /home folder in the root ("/") partition. That meant some extra work to save and/or recreate my user settings. This time around, I decided to create a separate /home partition to store those settings. This post describes that effort.

As I looked into this idea, I noticed that some guides to this process were a bit vague about key details, and other guides admitted that it could be complicated and it didn't work for everyone.  So I decided the safest bet was to start with the Ubuntu Community Documentation webpage.  For the partitioning, I rebooted with an Ubuntu Live CD and went into System > Administration > GParted.  To figure out how big to make the partition, I mounted the partition containing my Ubuntu installation and then went into Applications > Accessories > Disk Usage Analyzer and drilled down until I got to my /home partition, which was under /media.  Its name was a long string of random numbers and letters, something like 4bas83ng-gabbdd-adbg-fb37abd.  (It's a unique identifier, different for each computer and device.)  The /home partition for me, with almost all of my data elsewhere, was only about 120MB.  I decided on 1GB, to be on the safe side, and called it "home."  When GParted was done, I shut it down, exited the Live CD, and rebooted Ubuntu normally (i.e., without the Live CD).  Then I went into Applications > Accessories > Terminal, and typed "sudo blkid" to find the UUID for the new 1GB partition.  Following the Community Documentation, I then followed the advice to make a backup of fstab by typing these two lines:

sudo cp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)
cmp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)

(Note:  shell commands are case-sensitive, and punctuation is important.)  The second line was almost identical to the first, so I didn't actually retype it; I just hit the Up arrow key and then the Home key and edited the first few characters, and then hit Enter.  Now I was ready to edit fstab:  "sudo gedit /etc/fstab."  I added a line for the new home partition.

At about this time, I got distracted and strayed from the advice on the Community Documentation page at this point.  I ran into problems.  For reference purposes, the following section describes some error messages and other steps I took while trying to fix things.  After the following section, this post describes how I got back on track.

********************************************

DETOUR:  IF YOU HAVE FOLLOWED ME HERE, YOU ARE NOW LOST

********************************************

One of the first things that went wrong, aside from entering the wrong commands, was that I rebooted somewhere in the middle of the process, so Ubuntu read the fstab and assumed that my /home folder was on that new partition -- but I had not yet copied anything there, so the bootup froze.  So I had to reboot with the Live CD again, go into GParted, and delete that new home partition.  Then I rebooted without the CD, went back into GParted, recreated it, and did the copying step ("sudo rsync" etc., above).   Except that it didn't work.  I ran out of space.  Apparently I had not correctly calculated the necessary size of the new /home partition.  I went back into GParted and tried again.  This time I took the overkill approach:  30GB for /home.  (I had the extra space lying around, so why not?)  After a lot of fooling around with "sudo mkdir" this and "sudo umount" that, I did reach a point at which I had the right /dev/sd?? mounted at /media/home, and then the rsync command worked.  Then, as instructed, I renamed the old /home folder so that it wouldn't be detected as my /home folder:

cd /
sudo mv /home /old_home

I rebooted and sat back to see what would happen.  I got this on the initial Ubuntu reboot screen:

The disk drive for /home is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery 

This called for some additional screwing around.  I wrote down what happened; but when I returned to this post after an absence of a few days, I observed that Blogger had decided that what I wrote was garbage, and deleted it.  Thanks, Blogger!  I believe the gist of it was that I had forgotten that the new home partition would have, of course, a new UUID.  So I had to change fstab to account for that.  I also wound up running the rsync command (above) from a Live CD boot, after mounting the root and /home partitions, in this format:

sudo rsync -axS --exclude='/*/.gvfs' /media/UBUNTU/home/. /media/home/.

where UBUNTU was the label of my Ubuntu (root) program partition.  After rsync ran successfully, this new home partition contained about 4GB of files.  Booting with an Ubuntu Live CD, I ran GParted and resized /home to 10GB.  I had to do a reboot or two to get past the error messages and complete this repartitioning process, as often happened with GParted.  I then tried to install Ubuntu, designating separate root ("/") and /home partitions.  I told the installer to format the root partition but not the home partition, where I was saving settings from the previous installation.  But while I was installing from the CD, the installation program disappeared.  This happened three times with two separate installation CDs.  But when I told the installer to just put everything in root (i.e., not to recognize a separate /home partition), it went ahead, and the installation process was complete.

So now I apparently had to get Ubuntu to recognize my old /home partition in place of the new one that it had just installed.  I started Nautilus (i.e., Ubuntu's File Browser, from the Places > Computer menu pick), right-clicked on home, and saw that Mount was an option, implying that it was not yet mounted.  So that meant that, whatever I was doing with a /home folder right now, I would be doing to the newly installed one.  I went into Applications > Accessories > Terminal and typed the same commands as above:

cd /
sudo mv /home /old_home

That parked the new /home folder under the name /old_home, where it would still exist just in case, but would not operate.  Now I needed to tell Ubuntu to mount my saved /home partition at boot.  I typed "sudo blkid" and used the mouse (with right-clicks) to copy the UUID for home.  I typed "sudo gedit /etc/fstab" but this gave me never-ending error messages.  Oops.  Apparently gedit needed /home.  I killed that Terminal session, started a new one, reversed the mv command shown above (i.e., "sudo mv /old_home /home"), and tried gedit again.  This time it worked.  I noticed that fstab didn't list most of my drives, so I went to my main installation post and executed its steps related to ntfs-config.  I checked /home in Nautilus again and verified that the separate home partition was still not mounted.  Now I hoped that "sudo mv /home /old_home would put the newly installed home partition out of the way, and that my old one would operate.  But on reboot, I got several errors, one after another:

Could not update ICEauthority file /home/ray/.ICEauthority

There is a problem with the configuration server.
(/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)

Nautilus could not create the following required folders:  /home/ray/Desktop, /home/ray/.nautilus

The last one made me think that my /home partition was not being recognized.  But following the advice in a thread where they seemed to be discussing all of these messages, I didn't pursue that; instead, I rebooted with the Ubuntu alternative installation CD and chose the "Rescue a broken system" option and chose to "Execute a shell in the installer environment."  But this didn't seem to be the best route to a command-line option, so I bailed out.

(Note:  I also ran into a "udevadm" error during this process.  It did not appear to be due to this home partition effort, but there is a possibility that it was.)

****************************

END OF DETOUR

**************************** 

Eventually, I reinstalled Ubuntu, made my way back to the Community Documentation page, and tried again.  My entry in fstab now looked like this:

UUID=xxxxxxxx /media/home ext3 nodev,nosuid  0  2

I had already created /media/home and had done the rsync part from my previous installation (above), so now I tried these commands:

cd /
sudo mv /home /old_home
sudo mkdir -p /home/ray

where "ray" was my username.  Then I went back to fstab and changed it again to this:

UUID=xxxxxxxx /home ext3 nodev,nosuid  0  2 

and rebooted.  This time, rebooting went fine:  no error messages, and my desktop was back in its configured condition, with panels and buttons where I had put them before reinstalling.  Very nice.