Skip to content
Register

Drive upgrades: 8TB to 20TB, my RAID rebuild time tripled

Dedicated Servers by harbourops 4 replies 206 views
harbourops

Member OP

11 #1

Drive Upgrades: Capacity Expansion Impact on RAID Resilience

  • Previous configuration: 8TB drives, RAID-6, rebuild time ~18 hours
  • New configuration: 20TB drives, RAID-6, rebuild time ~54 hours
  • MTTDL concern: vulnerability window increased 3x without proportional URE improvement
  • Workload: mixed read/write, 40% utilization average

The rebuild duration itself creates a new failure domain. I am evaluating the following mitigations:

  • Hot-spare pre-positioning
  • Scheduled rebuild windows during low-activity periods
  • Consideration of RAID-10 for latency-sensitive clients

I rent dedicated boxes from Hetzner and this is what I am seeing on my own gear.

priya

Member

🇮🇳 netops ninja

#2

However, the MTTDL calculation itself must include the drive failure rate also, not only the rebuild time only. Kindly share your annualized failure rate assumptions also. Have you considered the erasure coding itself as an alternative to the RAID-6 only? Kindly do the needful and evaluate the Reed-Solomon configurations also for the large drive deployments.

bellaauc

Member

3-2-1 Believer

3 #3

Did you test your restore? I know its not the question but with 54 hour rebuild windows you NEED to think about this. 3-2-1 rule guys!!

  • 3 copies of data
  • 2 different media types
  • 1 offsite

Also consider if your backup window can even finish before the next one starts with 20TB drives. Been there!! Check your RPO and RTO before the raid math.

3-2-1 or you're already dead
RAJ

Member

#4

Guys any leads on providers offering managed backups with these big drives?? My clients are on KnownHost dedicated servers https://www.knownhost.com and thier backup addon pricing just doubled. Cant absorb this anymore also @bellaauc what backup panel do you recommend for 20TB+ per box?? Need something with incremental and compression

your margin is my opportunity
Nadia

Member

/dev/null enthusiast

2 #5

The cron script approach is just noise. I redirected the "rebuild during low activity" idea to /dev/null years ago. You cannot pipe human sleep schedules into drive mechanics. EOF.

| rebuild time is physics, not policy
| URE at 20TB is ~1 in 8 chance during rebuild
| your "low activity" window is a lie you tell yourself

I run zfs with scheduled scrubs and accept the risk. Everything else is just redirecting stderr to stdout.

/dev/null: full of good ideas

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft