this post was submitted on 14 May 2024
187 points (98.4% liked)

PC Gaming

8205 readers
539 users here now

For PC gaming news and discussion. PCGamingWiki

Rules:

  1. Be Respectful.
  2. No Spam or Porn.
  3. No Advertising.
  4. No Memes.
  5. No Tech Support.
  6. No questions about buying/building computers.
  7. No game suggestions, friend requests, surveys, or begging.
  8. No Let's Plays, streams, highlight reels/montages, random videos or shorts.
  9. No off-topic posts/comments.
  10. Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)

founded 1 year ago
MODERATORS
(page 2) 33 comments
sorted by: hot top controversial new old
[–] SplashJackson@lemmy.ca 1 points 3 months ago

Slaps roof, you can fit so much Christina Model porn in here

[–] meteokr@community.adiquaints.moe 0 points 4 months ago* (last edited 4 months ago) (11 children)

TL:DR; Bigger drives reduces the risk of data loss overtime. Please backup your data. RAID is not a backup.

As drives get bigger and bigger, the emotionally risk you feel when you fill them up is real. However, that is not the best way to think about it. Drives will inevitably fail, and drives are easily replaced commodities, their failure should be expected, and handled appropriately. RAID is not a backup, and does not reduce your risk of drive failure. RAID creates a safer environment for your data when a drive fails. How you should think about RAID is as if you are replacing a failed drive in advance, not as a reduction of risk of the drive failing.

To illustrate my point, we have Y of data to store. I can either split the data across X number drives, or store it all on a single drive. Which is safer? A single drive is objectively safer, given the same failure rate. So we have two cases for this situation. In both cases, this imaginary drive fails 10% of the time. The exact amount doesn't matter so long as they are reasonably close.

Case A: You have 1 drive holding all your data. There is a 1/10 chance it fails. Your risk is 10%.

Case B: You have X drives holding all your data. Each drive has a 1/10 chance of failing. so a 1−(9/10​)^X chance any of the drives fail. For all of X, your rate of failure is higher than 1/10. For two drives you have 19% chance of failure, three drives is 27%.

In all cases your rate of failure increases the more drives you add to hold your data. Please do not become confused by what RAID does for this illustration. RAID will not prevent drive failures. RAID allows you to, in essence, "pre-fail" a drive in advance. A drive will fail, and some RAID configurations(1,5,6) will replace the functionality of the failed drive until you can replace the "real" failed drive. RAID did not prevent your drive failure, it only moved the time the failure happened to be convenient for the user. A RAID1 array with a failed drive is still a failed drive that needs to be replaced, and still needs to be restored from backup/re-striped.

Let's take the cases of no RAID vs RAID1.

Case A: You have 1 drive holding all your data. When the drives fails, you stop your work, and replace the drive immediately.

Case RAID1: You have 1 drive holding all your data. You continue working because you've been very busy. You replace the drive when you have some downtime a week later.

In Case A, you had lost productivity because the drive failed at an inconvenient time, in the RAID1 case you could schedule the drive replacement for a later date when you had some spare time, huge improvement in the user experience. But wait! I said in the case of RAID1 only one of the drives was holding my data, should I have said 2 drives were? Yes, in a literal sense the RAID1 holds a copy of the data in the second drive. However, RAID is not a backup, it is a system to schedule the time of drive failures. Your backup of the RAID array is what holds a real second copy of your data, not your mirrored drive, because RAID is not a backup. Your second drive was still present in Case A, it was just replaced after the failure occurred, rather than before the first one failed.

Be safe with your data. please make backups, and verify you can restore from them regularly. RAID is not a backup.

[–] Toribor@corndog.social 3 points 4 months ago* (last edited 4 months ago) (1 children)

You're assuming that the failure rate for drives are all the same though. Aren't the failure rates for new high capacity drives typically higher?

[–] meteokr@community.adiquaints.moe 1 points 4 months ago

Yes their failure rates are usually a bit higher, but usually less than the increase in rate from using more than one disk instead. A bit of math can be done using Backblaze's disk failure rate data to get a reasonable approximation of the overall risk of failure.

[–] falkerie71@sh.itjust.works 1 points 4 months ago (2 children)

How should I go about verifying or rehearsing data restoration when my main computer is fine and don't have a spare to test with?

[–] Nomecks@lemmy.ca 2 points 4 months ago

Restore file -> md5sum against original -> delete -> repeat with another file.

Script it up!

[–] meteokr@community.adiquaints.moe 1 points 4 months ago

A simple way of doing it, is to just move some of the data somewhere else, and then restore that backup. If the contents are fine, then all is well, and if they aren't, then you can delete the broken restore, and move the files back where they were. Depending on how you are doing backups, some system have built in "dry-run" style tests were they can test themselves, but you should still verify the contents every so often.

[–] echodot@feddit.uk 0 points 4 months ago (1 children)

RAID is a backup, obviously It doesn't work if you store the backup on the computer that has the primary on it as well. Regardless of what solution you choose.

[–] lud@lemm.ee 3 points 3 months ago

No, RAID can be used for backup like having two or three different RAID arrays at different locations. But RAID itself isn't a backup. It's as the name implies redundancy instead of backup.

load more comments (8 replies)
load more comments
view more: ‹ prev next ›