Google은 하드 드라이브 고장에 대한 철저한 연구를 통해 하드 드라이브의 상당 부분이 대량 사용 후 처음 3 개월 내에 고장난 것으로 나타났습니다.
동료들과 저는 테스트를 거치지 않은 새 드라이브에서 시간을 잃어 버릴 수있는 모든 새 하드 드라이브에 대해 번인 (burn-in) 프로세스를 구현할 수 있다고 생각합니다. 그러나 번인 (burn-in) 프로세스를 구현하기 전에 경험이 풍부한 다른 사람들로부터 통찰력을 얻고 자합니다.
- 하드 드라이브를 사용하기 전에 레코딩하는 것이 얼마나 중요합니까?
- 번인 프로세스는 어떻게 구현합니까?
- 하드 드라이브에 얼마나 오래 구울 수 있습니까?
- 드라이브에서 어떤 소프트웨어를 굽습니까?
- 번인 공정에 너무 많은 스트레스가 있습니까?
편집 : 비즈니스의 특성으로 인해 RAID를 대부분 사용하는 것은 불가능합니다. 우리는 전국에서 매우 자주 우편물을 배달하는 단일 드라이브에 의존해야합니다. 가능한 한 빨리 드라이브를 백업하지만 데이터를 백업 할 기회를 얻기 전에 여전히 여기 저기 오류가 발생합니다.
최신 정보
우리 회사는 한동안 번인 (burn-in) 프로세스를 구현했으며 매우 유용한 것으로 입증되었습니다. 재고가있는 모든 새 드라이브를 즉시 소각하여 보증 기간이 만료되기 전에 새 컴퓨터 시스템에 설치하기 전에 많은 오류를 찾을 수 있습니다. 드라이브가 제대로 작동하지 않는지 확인하는 것도 유용한 것으로 나타났습니다. 컴퓨터 중 하나에서 오류가 발생하고 하드 드라이브가 주요 용의자 인 경우 해당 드라이브에서 번인 프로세스를 다시 실행하고 RMA 프로세스를 시작하거나 던지기 전에 드라이브에서 실제로 문제가 있는지 확인하기 위해 오류를 확인합니다. 쓰레기통에.
번인 과정은 간단합니다. SATA 포트가 많은 지정된 Ubuntu 시스템이 있으며 각 드라이브에서 4 번의 패스로 읽기 / 쓰기 모드에서 불량 블록을 실행합니다. 작업을 단순화하기 위해 “모든 드라이브에서 데이터가 삭제됩니다”경고를 표시 한 다음 시스템 드라이브를 제외한 모든 드라이브에서 불량 블록을 실행하는 스크립트를 작성했습니다.
답변
하드 드라이브를 사용하기 전에 레코딩하는 것이 얼마나 중요합니까?
좋은 백업과 고 가용성 시스템이 있다면 그다지 많지 않습니다. 실패로부터 복원하는 것은 매우 쉬워야합니다.
번인 프로세스는 어떻게 구현합니까? 드라이브에서 어떤 소프트웨어를 굽습니까? 번인 공정에 너무 많은 스트레스가 있습니까?
일반적으로 드라이브 나 새 시스템에 대해 불량 블록 을 실행 합니다. 여분의 더미에서 컴퓨터를 부활시킬 때마다 실행합니다. 이와 같은 명령 ( badblocks -c 2048 -sw /dev/sde)은 실제로 다른 패턴 (0xaa, 0x55, 0xff, 0x00)으로 매번 4 번 모든 블록에 씁니다. 이 테스트는 많은 임의의 읽기 / 쓰기를 테스트하기 위해 아무 작업도하지 않지만 모든 블록을 쓰고 읽을 수 있음을 증명해야합니다.
벤치마킹 도구 인 bonnie ++ 또는 iometer 를 실행할 수도 있습니다. 이들은 드라이브에 약간의 스트레스를 주어야합니다. 드라이브를 최대로 늘려도 드라이브가 고장 나지 않아야합니다. 따라서 그들이 할 수있는 일을 보려고 할 수도 있습니다. 나는 이것을하지 않습니다. 나중에 설치 / 설정시 스토리지 시스템의 I / O 벤치 마크를 얻는 것이 성능 문제를보고있을 때 매우 유용 할 수 있습니다.
하드 드라이브에 얼마나 오래 구울 수 있습니까?
내 생각에는 한 번의 불량 차단만으로도 충분하지만, 나는 매우 강력한 백업 시스템을 가지고 있으며 내 HA 요구는 그다지 높지 않다고 생각합니다. 지원하는 대부분의 시스템에서 서비스를 복원하기 위해 가동 중지 시간을 줄 수 있습니다. 걱정되는 경우 다중 패스 설정이 필요하다고 생각되면 RAID, 백업 및 HA 설정이 양호해야합니다.
급한 경우 번인을 건너 뛸 수 있습니다. 내 백업과 RAID는 정상입니다.
답변
IMNSHO, 불량 드라이브를 제거하고 데이터를 “보호”하기 위해 번인 (burn-in) 프로세스에 의존해서는 안됩니다. 이 절차를 개발하고 구현하면 다른 곳에서 더 잘 사용할 수있는 시간이 걸리며 드라이브가 번인을 통과하더라도 몇 달 후에도 실패 할 수 있습니다.
데이터를 보호하려면 RAID 및 백업을 사용해야합니다. 일단 설치되면 드라이브에 대해 걱정하십시오. 좋은 RAID 컨트롤러와 스토리지 서브 시스템은 데이터를 자주 이동하고 모든 것이 양호하다는 ‘스크러빙’프로세스를 갖습니다.
일단 모든 것이 처리되면 디스크 스크러빙을 할 필요가 없지만, 다른 사람들이 언급했듯이 모든 것이 예상대로 작동하는지 확인하기 위해 시스템 부하 테스트를 수행하는 것은 아프지 않습니다. 개별 디스크에 대해서는 전혀 걱정하지 않습니다.
의견에서 언급했듯이 특정 사용 사례에 하드 드라이브를 사용하는 것은 의미가 없습니다. 배송하면 번인 할 때 데이터 오류가 발생하지 않을 가능성이 훨씬 높습니다.
테이프 미디어는 주변에 배송되도록 설계되었습니다. 단일 IBM TS1140 드라이브로 하드 드라이브보다 빠른 250MBps (또는 최대 650MBps 압축)를 얻을 수 있습니다. 또한 한 개의 카트리지로 최대 4TB (비 압축)를 제공 할 수 있습니다.
테이프를 사용하지 않으려면 SSD를 사용하십시오. HDD보다 훨씬 거칠게 취급 할 수 있으며 지금까지 모든 요구 사항을 충족합니다.
그 후, 귀하의 질문에 대한 답변은 다음과 같습니다.
- 하드 드라이브를 사용하기 전에 레코딩하는 것이 얼마나 중요합니까?
전혀. - 번인 프로세스는 어떻게 구현합니까?
- 하드 드라이브에 얼마나 오래 구울 수 있습니까?
하나 또는 두 개의 실행. - 드라이브에서 어떤 소프트웨어를 굽습니까?
의 간단한 실행 말,shred그리고badblocks할 것입니다. 나중에 SMART 데이터를 확인하십시오.
- 하드 드라이브에 얼마나 오래 구울 수 있습니까?
- 번인 공정에 너무 많은 스트레스가 있습니까?
너무 스트레스가 없습니다. 디스크를 터뜨리지 않고 디스크에 물건을 던질 수 있어야합니다.
답변
명확히하면 번인 프로세스가 당신에게 유용 할 것 같지 않습니다. 드라이브는 주로 열과 진동과 같은 기계적 요인으로 인해 고장납니다. 숨겨진 시한 폭탄 때문이 아닙니다 “번인 (burn-in)”프로세스는 다른 것만 큼 설치 환경을 테스트합니다. 일단 물건을 옮기면 시작한 곳으로 돌아갑니다.
그러나 여기 도움이 될만한 몇 가지 조언이 있습니다.
랩탑 드라이브는 일반적으로 데스크탑 드라이브보다 더 큰 충격과 진동을 견디도록 설계되었습니다. 데이터 복구 상점에서 일하는 친구들은 항상 이런 이유로 노트북 드라이브의 클라이언트에게 데이터를 배송합니다. 이 사실을 테스트 한 적은 없지만 일부 산업에서는 “공통 지식”인 것 같습니다.
플래시 드라이브 (예 : USB 썸 드라이브)는 찾을 수있는 모든 매체 중에서 가장 충격에 강합니다. 플래시 미디어를 사용하면 전송중인 데이터가 손실 될 가능성이 훨씬 줄어 듭니다.
윈체스터 드라이브를 배송 할 경우 사용하기 전에 표면 스캔을 수행하십시오. 또는 더 나은 방법으로 사용 하지 마십시오 . 대신, 특정 드라이브를 “배송”드라이브로 지정하여 모든 악용 사례를 볼 수 있지만 데이터 무결성에 의존하지는 않습니다. (즉, 운송을 위해 드라이브에 데이터를 복사, 운송 후 복사, 양면에 매우 많은 체크섬이 있습니다).
답변
프로세스가 잘못되었습니다. 레이드 배열을 사용해야합니다. 내가 일하는 곳에서 우리는 운반하기 위해 설계된 견고한 급습 어레이를 만들었습니다. 로켓 과학이 아닙니다. 큰 고무 진동 차단기를 사용하여 대형 인클로저에 드라이브를 충격으로 장착하면 신뢰성이 크게 향상됩니다. (Seagate constellation-es 드라이브는 300G 충격 등급으로 평가되었지만 2G 진동 만 작동하며 작동하지 않습니다. 운송 케이스는 드라이브를 진동으로 분리해야합니다. http://www.novibes.com/Products&productID=62 또는 http : //www.novibes.com/Products&productId=49 [part # 50178])
그러나 실제로 테스트 하드 드라이브에서 굽기를 원하므로 여기로 이동하십시오.
나는 하드 드라이브와 같은 시스템에서 일했고 몇 가지 문제를 발견했습니다.
고장을 일으키는 PCB의 수명주기 테스트를 가속화하기 위해 핫 / 콜드 사이클을 능가하는 것은 없습니다. (핫 콜드 사이클 작동이 훨씬 더 효과적이지만, 특히 HDD 뱅크에서 수행하기가 더 어렵습니다.)
한 번에 획득 할 수있는 드라이브 수에 대한 환경 챔버를 확보하십시오. (이것은 꽤 비싸고, 습격 어레이를 운반하는 것이 더 저렴할 것입니다.) 습도 제어 및 프로그래밍 가능한 램프가 필요한 테스트 챔버에서 건너 뛸 수 없습니다.
최소 저장 온도에서 최대 저장 온도까지 2 개의 반복 온도 램프로 프로그램하면 램프를 가파르게 만들어 하드 드라이브 제조업체의 애플리케이션 엔지니어를 화나게합니다. 12 시간 동안 3 번의 냉온 사이클로 인해 드라이브가 매우 빨리 고장 나게됩니다. 이와 같이 12 시간 이상 드라이브를 실행하십시오. 나중에 일이 있으면 놀랄 것입니다.
나는 이것을 생각하지 않았다 : 내가 일했던 한 곳에서 생산 엔지니어가 동일한 테스트 장비와 함께 더 많은 제품을 선적하기 위해 테스트를 받았지만 테스트 오류가 급증했지만 도착시 사망률이 실제로 떨어졌습니다. 제로.
답변
나는 기본적으로 “번인 (burn-in)에 신경 쓰지 말고 백업을 잘하라”는 모든 대답에 동의하지 않습니다.
항상 백업이 있어야하지만 시스템은 레코딩되지 않은 드라이브로 실행 중이기 때문에 어제 9 시간 (보통 10 시간 교대 근무)을 백업에서 복원하는 데 사용했습니다.
RAIDZ2 구성에는 6 개의 드라이브가 있으며 (ZFS는 RAID-6과 동일) 18 시간 동안 약 45 일 동안 실행 된 상자에서 3 개의 드라이브가 죽었습니다.
내가 찾은 최고의 솔루션은 특정 제조업체 (드라이브 앤 매치 안 함)에서 드라이브를 구입 한 다음 제공된 운동 도구를 실행하는 것입니다.
이 경우 Western Digital을 구입하고 부팅 가능한 ISO에서 DOS 기반 드라이브 진단을 사용합니다. 이를 실행하고 임의의 가비지를 전체 디스크에 쓰는 옵션을 실행 한 다음 짧은 SMART 테스트와 긴 SMART 테스트를 차례로 실행합니다. 일반적으로 모든 불량 섹터, 읽기 / 쓰기 재 할당 등을 제거하기에 충분합니다 …
나는 여전히 한 번에 8 개의 드라이브에 대해 실행할 수 있도록 ‘일괄 처리’할 적절한 방법을 찾으려고 노력하고 있습니다. Linux 또는 ‘badblocks’에서 ‘dd if = / dev / urandom of = / dev / whatever’를 사용할 수 있습니다.
편집 : 나는 그것을 ‘배치’하는 더 좋은 방법을 찾았습니다. 마지막으로 특정 요구를 해결하기 위해 네트워크에 PXE 부팅 서버를 설정하려고했고 Ultimate Boot CD를 PXE 부팅 할 수 있음을 알게되었습니다. 이제 드라이브 진단을 실행하기 위해 PXE로 부팅 할 수있는 몇 대의 정크 머신이 있습니다.
답변
하드 드라이브를 사용하기 전에 레코딩하는 것이 얼마나 중요합니까?
그것은 다릅니다.
중복성을 제공하는 RAID에서 사용하는 경우 (1, 5, 6, 10)? 하지 매우.
당신이 그것을 standaolone 사용하는 경우? 조금, 그러나 적어도 내 의견으로는 현명하게 실행하거나 모니터하기 위해 무언가를 실행하는 것이 좋습니다.
이것은 자연스럽게 ” 번인 프로세스를 어떻게 구현합니까? “에 대한 나의 대답으로 이어집니다 .
디스크를 “번인 (burn in)”하려고 시도하는 대신 중복 쌍으로 디스크를 실행하고 SMART와 같은 예측 모니터링을 사용하여 드라이브가 고장 나면 알려줍니다. 전체 번인 (실제로 전체 디스크를 사용)을 수행하는 데 필요한 추가 시간이 디스크 오류 및 스왑 아웃을 처리하는 것보다 훨씬 비쌉니다.
RAID와 좋은 백업을 결합하면 영아 사망률을 다룰 때 (또는 노후화 드라이브를 시작할 때 욕조 치료의 다른 쪽 끝)에도 데이터가 매우 안전해야합니다.
답변
Spinrite (grc.com)는 드라이브의 모든 데이터를 읽고 씁니다. 실패하지 않으려는 경우에도 새 드라이브를 사용하는 것이 좋습니다. 레벨 4 (일반적으로 현재 크기의 드라이브의 경우 며칠)에서 실행하는 데 시간이 오래 걸립니다. 또한 비파괴 적이라고 덧붙여 야합니다. 실제로 불량 스팟에 데이터가 있으면 이동하여 복구합니다. 물론 SSD에서는 절대로 실행하지 않습니다.