Here's a bunch of storage related stuff I learned this month, including experience with my new 1TB SSD
Ever have a bad week? Thought so. We all do. Such weeks can also be an opportunity to learn a thing or two, and to make use of those data disaster preparations. Thought I'd take a moment to re-cap my recent stories, to share a few lessons learned. You know, the hard way.
1) It doesn't feel good when your daily automated backup server VM won't boot because of a missing C: drive
Safest approach is to be sure to have the VM you care about powered up at the time of associated VM disk cleanup operations. That'd make mishaps like losing your Windows Server 2012 R2 Essentials C: drive less likely. Of course, I was able to restore the VM from a backup image that Essentials does twice daily to a separate drive. I created a video of the process, not sure if I'll have time to produce and publish it, let me know if you're interested.
After the restore, I had a 160GB disk, with the rest of the 750GB virtual drive (thin provisioned) blank. This mean the automated twice daily backups of the server itself were failing, because of a volume shadow copy error. Simply had to use Disk Manager to extend the C: drive dynamically, and backups resumed functioning as normal. This turned out to be a demonstration of just how important testing, retesting, and monitoring are, when properly caring for a server, particularly one that just experienced near-death.
- thin provisioning don't work (bad things happen)
- pre-allocating the space works (although nobody would recommend it), as I mentioned back in Feb 2014 here
- and a specific sequence of actions to allow the virtual C: drive to be resized (crazy, backup first!)
- not a good idea on VMware Workstation Technology Preview (even crazier, that's a beta I'm using, but living and learning on the leading edge is possible, because it's all backed up)
Not documented anywhere, other than warnings to not do it. I hope to publish a summary of the somewhat convoluted process, that works, having tested it several times already.
for moving from my OCZ Vertex 4 to my tiny new Samsung 840 EVO 1TB mSATA SSD. I was a bit concerned when it warned me to close my apps to avoid files in use not getting copied. Not exactly easy these days, but I did close Office 2013 apps and my browsers. Despite the warning, all my stuff did seem to move over just fine, except for the huge Microsoft Office Outlook 2013PST files, and the windows.edb indexing database (which I had admittedly encrypted). No problem, all those files get automatically reconstructed. For me, that was an overnight, background operation.
When used with a MyDigitalSSD mSATA to 2.5" SATA caddy. But that caddy seems to prevent Samsung Magician Authentication from working, which also prevents Drive Encryption. Still looking into that one. But not before a full backup is restored to a a test VM, to absolutely verify it's valid.
Why the caddy? Well, I cannot use my mSATA slot in my primary workstation, my ThinkPad W520, since that slot is SATA2 only, and will have a noticeably impact performance. See also my article about storage interface speeds here.
I have found that older SATA2 laptops get a big speed boost from the RAM Disk like Samsung RAPID Mode, coupled with an affordable Samsung 840 EVO-Series 256GB SSD. Would I be similarly impressed with RAPID Mode on a SATA3 equipped systems like my tZilla W520 laptop? Figuring that out now, but it sure does benchmark nicely, seen below.
Recently experiencing a double disk failure on my 5 drive LSI 9265-8i RAID5 with CCPro 2.0 enabled wasn't good. It's one thing to say that I knew that already, but it was quite another when I actually saw what happened, all in just a few days time. Moral of the story is to not disable the RAID card's horrible screeching alarm, and to always have a spare 1.5TB on hand.
6) One of my two Mediasonic 4 Bay RAID eSATA/USB 3.0 enclosures is hurting, time to clone ~3TB of data
Mediasonic HFR2-SU3S2 PRORAID 4 Bay 3.5" SATA Hard Drive Enclosure - USB 3.0 & eSATA - versatile and affordable, see the short looping video below of the in-progress ESXi 5.5 VM clone operation going on right now below. The RAID 5 enclosure in the foreground has one drive gone bad, indicated by the red H at top left. No data lost, but just one drive from complete loss of all 5.6TB of data. Each enclosure is eSATA-attached (at SATA2 speed) to vZilla, formatted VMFS5 to host the VM.
Trouble with animated GIF? See identical YouTube clip.
I like the idea of having the flexibility to use them in a NAS, in a RAID, or individually. See also my related Google+ post. We'll see.
That means it can't pass the drives through as normal SATA-attached devices. Well, not easily anyway. Even creating individual RAID0 arrays from each drive didn't always work, even on the latest firmware. Perhaps it's time to rethink how vZilla storage is laid out. Still working on that.