United breaks guitars? Microsoft erases customer data...

[unixronin]

Vaporware is exactly Microsoft’s core competency as a company.

Money quote from Dan Dilger's post on the ongoing Sidekick data-loss failure, and Microsoft's part in it. Datacenter failures happen, but a datacenter failure isn't the reason why Microsoft still hasn't been able to demonstrably recover any Sidekick user data.

Turns out the reason Microsoft hasn't been able to recover the data is the same as the data was lost in the first place: Microsoft managers, over the objections of Danger engineers, cancelled a pre-SAN-upgrade backup, two days into a six-day backup, because they didn't want to take the time to do it and Hitachi had assured them the backup was "safe". But Microsoft's servers have room for only one backup. So to START the new backup— the one they cancelled two days in — they had to delete the old one. So when the "safe" upgrade failed, there was no backup of the data.

Microsoft has been frantically trying to blame Hitachi, EMC, Sun, Oracle ... anyone but themselves. But the fact is, regardless of the cause of the failed SAN firmware update — which could be a Hitachi/EMC failure, but since no-one else has reported problems with it, is more likely a procedural error at Microsoft — the loss of the Sidekick data is because Microsoft erased its backup of the data, then couldn't be bothered to wait for a new one to complete. After all, it's only user data, right? So much for the safety of the cloud.

Now Microsoft is promising that they have, like, nearly all of most of some of the Sidekick user data recovered, well, nearly recovered, or at least, it'll be nearly recovered soon. Some of it. Maybe. They promised that they'd soon have ... a status update.  Any time now!

Dan Dilger suggests that the "recovered data" will turn out to be one more piece of vapor that Microsoft will turn its back on and walk away from once people's attention has been distracted elsewhere, and that if Microsoft does somehow manage to recover any significant fraction of the Sidekick user data, it'll be not so much due to any technical ability in Microsoft's part as a testament to the resilience of the underlying Sun/EMC/Oracle platform the Danger unit runs on.

I think he's probably on the mark. I predict a lawsuit from T-Mobile for failure to adhere to the Sidekick SLA, and I predict that Microsoft will, as quietly as it can, settle the suit and sweep it under the rug on conditions of non-disclosure, as it has so many times before.

(Article pointer via 7leaguebootdisk)

Comments

[ithildae]

A cogent example of the disdain Micro$oft has for it's customers. They simply cannot be bothered to provide reliable service.

[jhetley.livejournal.com]

And people wonder why I distrust "cloud computing" and "software as a service" . . .

[unixronin.livejournal.com]

Indeed.

One thing it says to me is that Microsoft's backup strategy for the Sidekick data was horribly inadequate. A single full backup every few months, with no incrementals in between, and no margin for error in the case of a backup failure, and the entire database treated as a single homogeneous all-or-nothing blob. Come on, people, these are beginner mistakes.

[perspicuity.livejournal.com]

aside from the other sidekick exploits that have occurred... compromised user data...

what will happen is every user will get a $7 credit for the inconvenience, and a coupon for a free Slusho!

maybe a couple people will get "reassigned"...

M$ might even pay for a second offsite backup ;) via, say, pirate bay ;) oiy.

now, i believe, like iphone, it's totally possible to backup your own device/cloud with a Clicky! but i'll guess most users would never do that.

#

[unixronin.livejournal.com]

now, i believe, like iphone, it's totally possible to backup your own device/cloud with a Clicky! but i'll guess most users would never do that.

Not with a Sidekick. They went to considerable lengths to prevent you from maintaining a local copy of your data. Even the desktop sync tool syncs back to the cloud. Apparently the only way to store any of your sidekick's data locally is to manually copy one item at a time.

[perspicuity.livejournal.com]

ah, that's very broken... very.

apple gave both... local for free... and a cloud for a yearly fee (discounted via amazon even; and the same service coorindates with all the apple-warez); in theory cool, i pracitce, one FBI phone call away from remotely stealing your data without you knowing anything.

#

[montieth.livejournal.com]

So they FORCE you into the cloud and then throw your data away. That's sweet. Is that a feature they like to advertise along with the iron clad security model?

[lonewolf545.livejournal.com]

I have to admit, I'm not a big fan of RAC, especially not without using proper cluster software to manage the disks, Oracle promotes using ASM for disk management, but a SAN hiccup can cause real problems with ASM. Not having a good backup before starting a SAN upgrade is a beginner's mistake.

[unixronin.livejournal.com]

Frankly, way back when, the first attempt to migrate Hotmail from Unix to Windows showed that Microsoft didn't "get" enterprise-scale computing, and nothing I have yet seen from Microsoft convinces me that they "get it" any better now.

[masgramondou.livejournal.com]

There is something ironic about how MSFT can cock up a backup that doesn't involve the use of their own OS and recovery tools.

As someone who just had a site outage (savethedragons.nu & friends) because of Microsoft's ASR recovery process apparently not supporting Microsoft dynamic disk partitions and so on I am completely unsurprised that Microsoft do not use their own OS for mission critical applications and large volumes of data. After all actually testing ASR with a dynamic disk of a few Tbytes would have shown the problem pretty quickly and shown that ASR violates the basic rule of disaster recovry - DO NOT WRITE ANYTHING TO DISK without explicit permission.

At this point I personally wouldn't trust Microsoft with my data or trust my data to any place where a microsoft product is a single point of failure in the chain.