Hacker News Reader

Comment by jwr | Hacker News Reader

Well, in my case the failures are obvious and objectively present. You can't really discuss expectations if your device just lost all your data due to filesystem corruption. You don't discuss "infallibility" if your device tells you:

Buffer I/O error on device sda1, logical block 422806282 scsi2 (0:0): rejecting I/O to dead device

SCSI error : <2 0 0 0> return code = 0x70000 end_request: I/O error, dev sda, sector 4533105544

HFS+-fs: WARN: Turning journaling back on even though Journalling was not on at mount. HFS+-fs: WARN: We may be setting the Journal bit on an unjournalled filesystem but it is OK.

So please don't soften the issue — it fails. It failed for me multiple times already and I expect it to fail again.

I guess it's OK to use a Drobo if you get another one as backup for the first one — but then, what's the point?

View on HN

> I guess it's OK to use a Drobo if you get another one as backup for the first one — but then, what's the point?

RAID is _not_ a backup. If you don't understand this, you'll never be satisfied with any RAIDish products.

It's true that RAID is not a backup, but backup strategies are rarely any good if they back up data "instantly", which is what redundancy provides. So you're stuck with a catch 22. If you back up instantly (without versioning), you may backup bad data. Boooo! If you backup, say, daily, you still stand to lose a days work when your array fails. Boooo!

RAID should increase reliability, not decrease it. Any RAID solution that results in a net increase in data loss is not a good solution.

That's a catch 22 that can be minimized or even avoided altogether. My main drobo backup is automatically versioned and backed up every 12 hours (to a single external drive, since I don't need to back up everything on my drobo). I've got older backups dating from like a week (work-related) to half a year or more old (for the important docs that don't change that I should keep around regardless...like old accounting/tax stuff) stashed around my home, online, and in a safe deposit box at my bank. And of course occasionally I test whether or not my backup is actually backing up the things I want and that I can successfully restore from it.

If I back up bad data, I have older but good data to recover from. If my drobo catastrophically fails, at the worst I've lost data that is probably not going to be difficult to replicate/replace because of how new it is. I don't have to start ripping my hair out at the idea of having lost an incredible amount of data ranging from irreplaceable photos of my life to work and more.

In the ideal case, raid should increase reliability, and they do, only for one definition of reliability. But freak accidents and poor design happen, and it's silly to rely only on a raid for reliability.

That's not a catch-22... You can do both backups and RAID.

This is why I love Time Machine

True. RAID is about reliability and performance, and it seems the Drobo isn't winning points there either.

Oh, I'm not claiming they don't ever fail...they do. It happens. I can read your errors for myself. However, redundancy doesn't mean that you avoid fs corruption altogether.

If my drobo fails, so be it, drobo sucks etc., but my data is my responsibility. I have backups in place to deal with the data loss. I'm not asking my drobo to be perfect, I'm just asking it to keep on working in case a drive starts to fail, but there's clearly many possibilities where drobo itself fails. If there's fs corruption going on, it's my responsibility even if it's the fault of the hardware. If there's something I deleted off my drobo by accident, it's my responsibility.

Now, if you were going on about the bad design and hacky nature of droboshare and the software drobo runs on, and data robotics' bad customer support, then sure...you have a point. We could all learn from your experience not to use droboshare. That's about it.

Reply on news.ycombinator.com