Reclaiming Drives to Build a New RAID
07 January 2018
A couple years ago, I replaced my old spinner drives with matching SSDs. I left the old drives mounted but disconnected the cables. I’ve been watching my photo collection grow and consume about half my live storage, so I figured it was time to bring those slower spinning drives back online, so I can move my archive of old photos off my fast drives and get a little extra room.
I plugged in the first drive, and observed that it fortunately did not try to join the existing RAID arrays.
lsblk showed me a list of drives and partitions and how they were currently used, so I could confidently
cfdisk /dev/sda to wipe and recreate 1 primary partition on the drive as type
fd (Linux raid autodetect). I rebooted to see the new partition table, and then installed and did the second drive (
/dev/sdb in my case).
I setup the new drives in a mirror:
# create a new RAID1 mirror out of those new partitions:
mdadm --create /dev/md2 --level 1 --raid-devices=2 /dev/sda1 /dev/sdb1
# to ensure it's still called md2, and not md127 on reboot
# create a filesystem
mkfs -t ext4 /dev/md2
# mount it to copy
mount /dev/md2 /mnt/new
# migrate all my photos
rsync -av /home/john/Photos/ /mnt/new
After the initial migration, I tested it:
Checked that the array is there with the same name:
cat /proc/mdstat (It initially had not kept the name, and that’s when I learned to
Mounted the new array as
Checked that Digikam still works.
That looked good, so it’s time to make it permanent:
Unmounted the new filesystem
Deleted all the old contents of
Added the new array to the
/etc/fstab to mount it automatically
05 January 2016
I’ve moved the blog to a static site generated by JBake. The source for the content lives in my techblog project in Github, so I have a full versioning of my content for the small price of a git workflow.
I installed JBake using the familiar SDKMan that I already use to manage my Grails and Groovy installations. I initialized it with the Groovy templating engine and have started customizing the templates.
To make sure this thing is easy to update, I keep a local clone of the repo, so I can update it any time and push whenever I’m ready. I have a shell script scheduled to run on the server which basically does:
git merge | grep "Already" > /dev/null || jbake
That little bit of code only runs
jbake if the
git pull doesn’t say "Already up-to-date". That provided me a simple little "continuous integration" hook that polls git for changes to trigger the build. I’ll probably use this trick in other places.
I brought all my old content from my old database into the new platform using a quick little Groovy script to dump out an HTML file for each article including the header of metadata for JBake’s use. While most of these old articles will remain HTML, I intend to use AsciiDoctor format for all the new stuff.
I’ve been collecting a long list of (mostly technical) articles to write, but replacing the old platform kept trumping my attempts to write. Hopefully, this move can open the flood gates, and eventually, I’ll break out another instance of it for the photography blog. JBake should make it easy and interesting to continue the blogs.
Replacing a Drive in the Software RAID
13 December 2012
I realized upon trying to replace a drive in my Linux software RAID, that I had never previously documented this process.
The power failed a couple days ago, and sitting around for 10 hours not spinning was bad for my one Western Digital 500GB drive, so it never came back online, but the computer booted up just fine with 2 of the 3 drives. I ordered a new 1GB drive to replace it within 2 hours of the problem.
When the new drive arrived, I shutdown the computer, unplugged the failing SATA drive, and replaced it with the new one. Linux again booted up with only 2 drives active.
To ensure that the partitions matched, I did an
sfdisk -d /dev/sda | sfdisk /dev/sdb.
cfdisk was unhappy with the drive initially, but
fdisk was happy to read the table and write it back cleanly. Then I could open it again in
cfdisk and add one more primary partition to use the extra non-redundant 500G on the new drive.
With the partitions in place, it was time to insert the new partitions back into the RAID devices:
mdadm /dev/md0 --add /dev/sdb1,
mdadm /dev/md2 --add /dev/sdb5, etc, until all the drives were re-established. Watching
/proc/mdstat, I could see that the RAID started recovering the devices, and I could go to bed.
I did manage to do something wrong at one point, so a quick
mdadm /dev/md0 --fail /dev/sdb1 and
mdadm /dev/md0 --remove /dev/sdb1 allowed me to fail and remove a partition, fix it up, then add it back when I was done. All this could be done with the system up and running—that's pretty convenient.
27 October 2011
I've been happily kicking along in Gnome 2.x-whatever on my Debian and Ubuntu machines for quite sometime. When Ubuntu tried to push me over into Unity back in April, I gave it half a day, then reverted back to Gnome 2 for familiarity and more workspaces.
Well, it's October now, and Ubuntu made the push again, but this time, it also pushed Gnome up to 3.2, which is drastically different as well. With no solace in Gnome, I've had to just sort of try to figure out the Unity-way with no controls and their "it's for your own good" mentality. (It feels a lot like that other OS that I wiped off a Mac Book Pro.)
A couple more days passed, and my Debian unstable machine upgraded to Gnome 3.0, and my good ol' Gnome 2.x was gone. So I'm trying Unity on my Ubuntu netbook, and I'm trying Gnome 3.0 on my photo workstation/server. They're similar enough, but it's still disorienting bouncing between the 2 environments -- while Unity hasn't offered any absolute show-stoppers, I may land on Gnome for consistency. It might also be time to look into KDE or XFCE -- somehow, I think they probably still offer me all the knobs and buttons I've used previously to customize my desktop.
If I wanted to give up my choices, I could just run a Mac -- they have nice hardware and a Unixy OS.
All the Posts