Backblaze의 2026년 2분기 드라이브 통계
요약
본 글은 HDD의 신뢰성과 수명에 대한 경험적 통념(5년 주기 교체)을 비판하며, 기술 발전과 제품군 변화가 신뢰성 향상에 기여했음을 분석합니다. 또한, 대용량 데이터 저장 시 비용 효율적인 측면에서 HDD의 중요성을 강조하고 RAID 구성 및 성능 개선 방안에 대해 논합니다.
핵심 포인트
- HDD는 과거 대비 신뢰성이 크게 향상되었으며, 기술 발전과 제품군 변화가 원인입니다.
- 단순한 경험칙보다 SMART와 같은 진단 도구를 활용하는 것이 드라이브 상태 파악에 더 정확합니다.
- 10TB 이상의 대용량 데이터를 비용 효율적으로 저장할 때는 HDD가 여전히 가장 좋은 선택지입니다.
- RAID 구성 시 속도 개선을 위해 캐싱(Caching) 기법을 적용하여 성능을 보완할 수 있습니다.
2013년 Backblaze에서는 사용 기간 3년 3개월에 평균 고장률이 약 14%였고, 드라이브의 실용 수명은 대략 4년이었음. 2021년에는 약 14%의 고장률에 도달하는 시점이 7년 9개월로 늘었고, 실용 수명은 약 6년이었음.
그래서 고장 날 때 교체하는 방식을 택하지 않는다면, 5년마다 교체해야 안전하다는 경험칙이 꽤 안정적으로 자리 잡았음. 그런데 2025년에는 10년 3개월 된 드라이브의 고장률이 약 5%이고, 실용 수명도 약 10년에 달함. HDD를 이렇게 개선해 준 업계에 감사함!
이 수치가 곧 5년마다 교체해야 한다는 뜻은 아님. 출생 시 기대수명과 현재 나이에서의 기대여명을 구분해야 하는 것과 같음. 과거에도 성인이 된 사람이 무조건 서른에 죽는 건 아니었고, 출생 시 기대수명 개선에는 의료진의 손 씻기와 소아 질환 백신 등이 크게 기여했음. 제조 결함은 초기에 드러날 가능성이 높으므로, 멀쩡한 드라이브를 교체했다가 오히려 데이터를 날릴 제품을 들일 수도 있음. 이런 경험칙보다 SMART를 확인하는 편이 드라이브 상태를 훨씬 잘 파악할 수 있음.
신뢰성 향상이 꽤 놀라움. 2013년이면 이미 성숙한 기술이라고 생각했을 텐데, 구매하는 제품군이 달라진 것일 수도 있음. Backblaze는 예전에 저렴한 드라이브를 골랐지만, 대다수 사용자가 기본 저장장치로 SSD를 쓰면서 HDD 시장 자체가 더 신뢰성 높은 제품군으로 이동했을 가능성이 있음. 저품질 데스크톱용 HDD를 더는 대량으로 만들지 않는 식임.
1990년대 말과 2000년대 초에는 드라이브 고장이 정말 흔했음. 어린 시절에만 세 번쯤 겪었는데, 그 이후로는 치명적인 고장을 겪지 않았으니 정말 많이 발전한 셈임.
내 2.5인치 HDD들도 10년 넘게 살아 있음. 활발하게 쓰는 건 아니지만 그래도 대단함.
표 머리글과 본문이 따로 스크롤되는 화면은 이 링크를 열기 전까지 상상도 못 한 끔찍함임.
단순히 UI가 좀 이상한 줄 알았는데, 머리글 열과 본문 열이 더는 맞물리지 않으니 심각함.
올해 NAS의 하드 드라이브 두 개를 교체해야 했는데, 운 나쁜 복권에 당첨된 기분임. 쓰던 드라이브 가격은 두 배로 뛰었고, NVMe까지 고장 나는 건 아닌지 정말 두려웠음.
12TB 제품은 내가 샀을 때보다 여전히 저렴함. 더 싸면 좋겠지만, HDD 가격이 그렇게 나쁜 수준은 아님.
평소 사람이나 기업이 망하길 바라지는 않지만, 이번에는 이런 AI 쓰레기 양산 기계들이 처참하게 실패하길 바람. 실제로 쓸모 있는 일에 필요한 하드웨어를 정상적인 가격에 살 수 있어야 하고, 다시는 이렇게 시장을 뒤흔드는 어리석은 짓을 하지 말라는 교훈이 돼야 함.
HDD 용량은 계속 늘지만 읽기·쓰기 속도는 거의 그대로라는 점이 흥미로움. 이제 새 대용량 드라이브를 전부 읽는 데 며칠씩 걸릴 정도임.
고장 후 배열 재구축 시간이 너무 길어서 RAID에 이상적이지 않고, 장기 콜드 스토리지용으로도 썩 좋지 않은데 용도가 궁금함. 서버에서 하루 1TB씩 정기 백업하거나, 일정에 따라 영상을 삭제하므로 별도 백업에 크게 신경 쓰지 않는 CCTV에는 적합할 수도 있음.
10TB 이상을 중복 저장하려면 HDD가 여전히 유일하게 비용 효율적인 답임. 디스크가 네 개 이상이면 RAID 6이나 RAID 10으로 상당한 내고장성을 확보할 수 있음. RAID 10은 쓰기 성능도 높여 주지만, 내 생각에는 안정성이 조금 떨어지고 GB당 비용도 더 비쌈.
속도는 주로 회전수에 좌우되는데, 시장은 약간의 속도 향상을 위해 고장률 상승과 평균 고장 간격 감소를 감수하고 싶어 하지 않았음. 속도와 용량이 모두 필요하면 PrimoCache 같은 도구로 RAID 배열 앞에 SSD 한두 개를 캐시로 붙이면 됨.
재구축 시간이 너무 길다는 기준이 무엇이고, 왜 문제가 되는지 궁금함. 중요한 데이터는 ZFS raidz2에 보관하는데, 고장 난 드라이브 교체가 40분 걸리든 40시간 걸리든 내게는 큰 차이가 없음. 그동안에도 읽기·쓰기가 가능하고 중복성도 유지되므로 필요한 만큼 기다리면 됨.
비상용 외부 백업은 네트워크를 통해 restic으로 수행함. 최초 전체 복사에는 오래 걸렸지만, 이후 일일 백업은 최근 변경분만 담는 일종의 증분 백업이라 평소 데이터 변경량에서는 크기가 작음. 유지비가 낮아야 백업이 좋은 구상으로만 끝나지 않고 실제로 실행됨.
예산이 넉넉했다면 다른 방식을 골랐겠지만, 그렇더라도 드라이브 교체 시간에 왜 신경 써야 하는지 모르겠음.
가정용 서버는 하루 이틀 정도 유지보수 모드나 읽기 전용으로 돌려도 대개 괜찮음. 더 큰 규모에서는 노드 한두 개가 잠시 중단돼도 버틸 만큼 중복성을 확보함. 핵심 데이터가 수많은 TB에 달하는 기업이라면, 일부 계층에서 전체 백업 복원에 며칠이 걸리더라도 다계층 스토리지를 쓰는 것이 합리적임.
보관하면 좋지만 상시 백업할 만큼 중요하지는 않은 데이터가 상당히 많을 것임. 용량은 많이 차지해도 가끔 소량만 기록해서 증분 백업이 가능한 데이터도 있음. 내 NAS에 있는 데이터 대부분이 이런 종류임.
삼중 패리티 RAID나 삭제 코딩(erasure coding) 을 적용해 백업, 데이터 보관, 객체 스토리지에 쓰면 됨. HDD 수십~수백 개의 대역폭을 합치면 꽤 괜찮음.
기초 데이터는 매우 흥미롭지만 분석 방식은 부실해 보임. 평균 사용 기간 차이가 이 정도라면 고장률을 그대로 비교할 수 없음. 이번 분기의 고장률 대신 카플란–마이어 생존 곡선을 보여줘야 함.
데이터센터에 불이라도 난 게 아니라면, 동일한 드라이브의 1분기와 2분기 사이에 사용 기간 증가 외에는 큰 차이가 없을 것임. 내부적으로는 사용 기간을 통제해 공통적인 고장률 상승이 있는지 분석하겠지만, 여기서는 사용 기간 차이와 완전히 뒤섞인 모델별 고장률에 초점을 맞추고 있음.
NAS용으로 산 WD Red 6TB 두 개가 모두 2년 안에 고장 남. 내 경험상 유난히 나쁜 결과임. 다른 NAS 두 대를 15~20년 동안 사용하면서는 드라이브를 세 번밖에 교체하지 않았음.
하나는 같은 모델로 교환받았지만 별로 안심이 되지 않음. 다른 하나는 교환이 불가능해 1년 반 전 구매가인 198유로를 환불받았는데, 지금 똑같은 드라이브가 약 340유로라 가격 상승이 상당함. 두 번째 교체품은 Seagate로 골랐고, 잘 버텨주길 바람.
Backblaze 통계의 매력은 개별 체험담이 아니라 데이터를 제공한다는 데 있음.
6TB Red라면 저급 드라이브를 NAS용으로 표시해 팔았던 SMR 논란 무렵의 제품 아닌가? 다시 믿고 사볼 생각을 하기까지 개인적인 불매 기간이 아직 몇 년 남아 있음. 어느 제조사든 불량 생산분은 나올 수 있지만, 그건 고객에게 노골적으로 거짓말한 일이었음.
내 최악의 제품은 Amazon에서 산 Seagate IronWolf 8TB였음. 위험을 분산하려고 WD Red 8TB와 동시에 샀는데, WD는 약 6년 뒤인 지금도 작동하고 IronWolf는 1년 반도 못 버팀.
다행히 Amazon에서 전액 환불해 줘서 외장 케이스에서 적출한 WD Elements 12TB로 교체했고, 이 제품은 현재 약 5년째 작동 중임.
Backblaze가 호스트 관리형 SMR을 쓰지 않는 게 의외임. 속도를 위해 이미 순차 쓰기를 하고, 곧 수정·삭제될 가능성이 높은 데이터와 오래 유지될 데이터를 서로 다른 저장 계층에 둘 것으로 예상했음. 적어도 콜드 계층의 대용량 파일에는 SMR이 상당히 합리적일 것임.
아주 최근의 가격 변동 전까지는 Backblaze의 구매 규모에서 SMR의 비용 절감 효과가 크지 않았을 것임. 특히 성능 문제를 해결하기 위해 호스트 관리형 SMR용 소프트웨어를 별도로 개발하는 시간까지 고려하면 더욱 그럼.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기