Slashdot Mirror

← Back to Stories (view on slashdot.org)

Server Failure Destroys Sidekick Users' Backup Data

Posted by timothy on from the oh-well-enough-said dept.

Expanding on the T-Mobile data loss mentioned in an update to an earlier story, reader stigmato writes "T-Mobile's popular Sidekick brand of devices and their users are facing a data loss crisis. According to the T-Mobile community forums, Microsoft/Danger has suffered a catastrophic server failure that has resulted in the loss of all personal data not stored on the phones. They are advising users not to turn off their phones, reset them or let the batteries die in them for fear of losing what data remains on the devices. Microsoft/Danger has stated that they cannot recover the data but are still trying. Already people are clamoring for a lawsuit. Should we continue to trust cloud computing content providers with our personal information? Perhaps they should have used ZFS or btrfs for their servers."

5 of 304 comments (clear)

  1. "they should have used ZFS or btrfs" by Manip · · Score: 5, Insightful

    This seems a rather silly point to make. I know this is Slashdot and we have to suggest Open Source alternatives but throwing out random file systems as a suggestion to fix poor management and HARDWARE issues is some place between ignorant and silly.

    Perhaps they should have had at least mirrored or stripped raid, with an off-site backup every week or so?

    1. Re:"they should have used ZFS or btrfs" by sopssa · · Score: 5, Insightful

      Exactly, this can be a software bug too and that could possibly easily destroy or corrupt backup data too. I really doubt this service was ran without backups.

      The type of filesystem has nothing to do with this.

    2. Re:"they should have used ZFS or btrfs" by Znork · · Score: 5, Insightful

      I really doubt this service was ran without backups.

      Knowing 'enterprise' backups I'd bet there was at least a backup client installed and running. However, I'm equally sure that the backups were, at best, tested once in a disaster recovery exercise and were otherwise never verified.

      Further, responsibility would probably be shared between a storage department, a server operations department and an application management department, neatly ensuring that no single person or function is in the position to even know what data is supposed to be backed up, what limitations there are to ensure consistency (cold/hot/inc/etc), to monitor that that's actually what does happen and that it keeps happening as the application and server configuration evolves.

      Backups of dubious value do not seem to be a rarity in enterprise settings.

    3. Re:"they should have used ZFS or btrfs" by petes_PoV · · Score: 5, Insightful
      It's not a backup unless you can prove it will restore. Until then it's just a waste of tape, or disk, and time

      The point about backups is not to tick the box saying "taken backup?" but to provide your business / customers / whatever with a reliable last resort for restoring almost all their data. If you don't have 100% certainty that it will work, you don't have a backup.

      --
      politicians are like babies' nappies: they should both be changed regularly and for the same reasons
  2. Re:Backups? by TheSunborn · · Score: 5, Insightful

    Or this was really a software error, and the backup servers in an other datacenter, just copied the faulty data/delete command.

    They should really be far to big to have all their data stored in a single datacenter with no offsite backup. (Or they should have an entry on thedailywtf.com)