Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yea any time I'm using a raid setup (as opposed to a cluster or other more intelligent system like zfs) I insist that there be at least one hot spare and a cold one ready. And never let anyone convince you a raid is a backup


Hot and cold spares are rather wasteful. Just RAID1 and then use software (i.e. ceph) to make that redundant across multiple enclosures and ultimately, geographic zones/DC's.


That strikes me as a bit contradictory, since I would consider RAID1 (plus the redundancy across enclosures) to be the equivalent to even "hotter"[1] spares. Unlike the hot (warm) and cold spares for the RAID5/6, all the drives in the RAID1 are continuously in use, which means they're subject to wear-related failures [2].

If you're getting performance benefits from the RAID1, then the extra drives may not be wasted, but that's a separate topic.

[1] Which I argue is a misnomer. To me, "warm spare" makes more sense, since it's powered up but not actively synced in any way. Some systems, configurably, even spin down such spares.

[2] As I mentioned in https://news.ycombinator.com/item?id=17855632 some failures are power-on/spun-up related, which makes the availability of a truly cold spare even more beneficial.


Depends on your RPO and RTO tbqh, if you have the budget to do that in software you are either fairly small or able to implement changes without the business yanking your chain and many are willing to just pay more for their storage layer than re-architect existing apps.


As someone looking to backup a few terabytes of photos and videos, where I do have them on a raid, what constitutes an actual backup?


An actual backup, would be a copy of said photos and vidoes on:

- An external Drive. (which is only connected to copy files)

- An external cloud service.

- Another computer that you have.

You should probably do a couple of these.

I personally backup home computers (using borg) to a home server, that server has a 2.5 2TB external HDD connected to it (2 other 2.5 external drives are kept outside of the house). A backup of important files from the nas (including the computer backups) gets copied over to the external drive nightly. Weekly the drives gets rotated.

The really important stuff is also backed up offsite on a daily basis.


My general rule is that there are at least 3 copies in different physical locations, at least 2 of which are not within "tornado distance" of each other.

The way to think about backup and DR is "what would it take to destroy all of this?" and keep making the answer more and more extreme until it is so horrible that if it actually happens you won't care about what you lost.

PS: Also always remember that a backup you don't test isn't actually a backup.


Basically like others said, there's some kind of physical separation. That way if the machine were to explode or you loose too many drives in the array you still have a copy of them. RAID protects you from a hardware failure (to some extent), a backup protects you from hardware failure, software failure, and human failure (or it should anyway). The idea is that if the cannonical version of things gets destroyed somehow the backup is available to rebuild, so it can't be alive in the same machine as the cannonical one (except maybe when doing the backup itself).

The other "rule" that many people follow is 2 is 1 and 1 is none. The idea is that anything that isn't backed up isn't protected and can't be relied upon to exist.

A cloud service like backblaze, google drive, amazon cloud drive, etc. is a good secondary backup for a lot of people even if it'll take you a month or two to get your data there to begin with.


> or other more intelligent system like zfs

I thought zfs was not incompatible with RAID. How else would you run it out of curiosity?


When using ZFS on top of external RAID hardware or software, instead of using the builtin RAID-Z feature, many unique crash-safe and data-corruption prevention features provided by ZFS are lost. The best practice is avoiding using other RAID mechanisms when possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: