새로 산 외장 하드 드라이브를 믿지 마세요: 먼저 바이트 단위 H2testw 검사를 반드시 수행해야 하는 이유
좋든 싫든, 외부 드라이브는 자주 백업 대상이 됩니다. 대부분의 경우, 그것에는 별 문제가 없으며, 많은 상황에서 대부분의 외부 드라이브는 사용하는 데 전혀 지장이 없습니다.
하지만 새 외장 드라이브를 무조건 신뢰할 수는 없습니다. 보기에는 좋아 보여도 여전히 백업에는 완전한 위험 요소가 될 수 있습니다. 다행히 간단한 쓰기 후 읽기 검증 루틴을 통해 안정적인 드라이브를 다루고 있는지 확인할 수 있으며, SMART 상태 검사조차도 잡아내지 못하는 것들을 보여줄 수 있습니다.
벤치마크조차도 당신의 드라이브가 안전하다는 것을 증명하지 못하는 이유
그들이 그렇게 해주면 좋겠지만, 어떤 것들은 잡기 더 어렵다
많은 사람들이 내부 SSD든 외장 케이스 안에 있는 드라이브든 상관없이 드라이브 벤치마킹을 귀찮아합니다. 하지만 벤치마킹을 한다 하더라도 대부분 얻는 정보는 드라이브의 성능과 관련이 있을 뿐, 건강 상태와는 관련이 없습니다. 안정적인 벤치마크를 실행할 수 있다는 것은 물론 좋은 신호이지만, 그렇다고 해서 방금 전송한 파일이 온전히 도착했거나 일주일이나 이주 후에도 그대로 있을 것이라는 의미는 아닙니다.
대부분의 벤치마크는 비교적 작은 데이터 조각을 읽고 씁니다. 이들은 종종 드라이브의 같은 부분을 반복해서 접근하게 됩니다. 때때로, 이는 그들이 드라이브의 빠른 캐시 부분을 벗어나지 못한다는 것을 의미합니다.
더 중요한 것은, 일반적인 저장 장치 벤치마크를 사용해서 드라이브 전체 용량에 걸쳐 안전하게 읽기와 쓰기를 할 수 있는지 확인할 수 없다는 것입니다. 그리고 그 일부가 괜찮다고 해서 전체가 최상의 상태라는 보장은 없습니다.
가짜 또는 잘못 보고된 저장 용량을 가진 드라이브(그리고 네, 가짜 드라이브도 존재하며, 비록 USB 플래시 드라이브와 SD 카드에서 훨씬 더 흔하지만)는 벤치마크에서는 문제가 없어 보일 수 있지만, 그렇다고 해서 그것이 더 사용할 수 있다는 의미는 아닙니다.
백업 드라이브에 관해서는, 벤치마크는 정말 부차적입니다. 더 중요한 것은 그 장치가 당신의 파일을 안전하게 보관할 수 있는지 여부입니다.
귀하의 드라이브를 위태롭게 하는 취약한 연결고리
드라이브 자체일 수도 있고, 다른 무언가일 수도 있습니다
손상되었거나 누락된 데이터와 관련해서는 여러 가지 문제가 있을 수 있으며, 아래에서 제가 이야기할 테스트가 이 문제에 대한 일부를 밝힐 수 있습니다.
우선, 드라이브 자체가 문제일 수 있습니다. 평판이 좋은 드라이브조차도 가끔 불량품이 나올 수 있으며, Backblaze의 HDD 수명에 대한 정기 보고서에 따르면 초기 단계에서의 고장이 발생할 수 있으므로, 방금 구매했다고 해서 문제가 없다는 의미는 아닙니다.
외장 드라이브를 사용할 때는 다른 문제에 부딪힐 수도 있습니다. 약한 고리는 어디에나 있을 수 있습니다: 드라이브를 장치에 연결하는 케이블, 커넥터, 또는 내부 헤더에 있을 수 있습니다. 드라이브 자체는 완전히 문제가 없을 수도 있습니다. 벤치마크는 오래 실행되지 않기 때문에, 이러한 작은 문제들은 데이터 손실을 우연히 발견할 때까지, 종종 몇 주가 지난 후까지 감지되지 않을 수 있습니다.
실제로 도움이 되는 유일한 테스트는 너무나도 간단하다
지루하지만 간단하다
자, 제가 말하는 이 마법 같은 테스트가 무엇일까요? 간단합니다: 적절한 검증 테스트입니다.
이 유형의 테스트는 두 가지를 수행합니다. 먼저, 드라이브에 대량의 알려진 데이터를 씁니다. 목표는 속도가 극도로 느려지기 전에 가능한 한 많은 공간을 채우는 것입니다. 그 다음, 그 데이터를 모두 읽어들이면서 바이트 단위로 검증합니다. 목표는 돌아온 데이터가 처음 드라이브에 쓴 것과 동일한지 확인하는 것입니다. 만약 드라이브가 용량을 속이거나, 데이터를 손상시키거나, 연결이 끊기는 등의 방식으로 잘못 작동하면, 처리해야 할 큰 빨간 깃발이 생기는 것입니다.
분명히, 이것을 손으로 하는 것은 불가능하겠지만, 이를 쉽게 만들어주는 도구들이 존재합니다. Windows에서는 가장 간단한 옵션이 H2testw입니다. 외장 드라이브를 지정하고 사용 가능한 모든 공간을 사용하도록 명령하면 됩니다. 그러면 외장 드라이브가 가득 찰 때까지 테스트 드라이브를 마구 생성하고, 그 후에 이를 검증합니다.
이 작업을 드라이브에 데이터를 쓰기 전에 해야 하는 이유는 간단합니다. 첫째, 결함이 있는 드라이브에 데이터를 맡기고 싶지 않기 때문입니다. 둘째, 이 작업이 성공하려면 드라이브가 완전히 비어 있어야 합니다.
macOS 및 Linux 사용자는 F3 도구를 사용해 볼 수 있습니다. 작업 흐름은 비슷합니다: f3write를 실행하여 드라이브를 테스트 파일로 채운 다음 f3read를 실행하여 이를 검증합니다. H2testw보다 약간 더 직접적인 작업이지만, 같은 일을 수행합니다: 드라이브와 연결이 실제 용량에 걸쳐 지속적인 쓰기 및 지속적인 읽기를 처리하도록 강제하는 것입니다.
테스트를 할 때 드라이브가 전반적으로 어떻게 작동하는지 주의 깊게 살펴보세요. 드라이브가 연결이 끊기고 다시 연결된다면, 데이터 전송 경로상에 문제가 있거나 단순히 드라이브 자체가 고장일 수 있습니다. 다양한 고장 지점을 교체해 보고(케이블, 포트, 인클로저) 다시 테스트해 보세요. 문제가 계속 발생한다면, 사용을 피하는 것이 좋습니다.
결과가 실제로 말해주는 것
충분히 좋은 것이 진정으로 충분히 좋은 것일까?
테스트가 오류 없이, 연결 끊김 없이 완료된다면 기본적으로 문제 없는 상태입니다. 안전을 위해 SMART 건강 도구로 간단히 확인해보고(드라이브가 100% 건강 상태에서도 고장날 수 있음) 백업용으로 사용을 시작하세요.
만약 상황이 그렇게 좋지 않고 인증 오류가 발생하면 어떻게 될까요? 저에게는 그 드라이브를 백업용으로 사용하는 것은 단호한 ‘아니오’입니다. 단 한 개의 손상된 블록만으로도 심각한 혼란을 일으킬 수 있으므로, 안전한 것이 후회하는 것보다 낫습니다.
용량 불일치도 나쁜 소식입니다. 드라이브가 본질적으로 예상한 용량의 일부분만 보고하는 경우, 특정 지점을 지나면 데이터가 덮어써질 수 있다는 의미입니다. 본질적으로 데이터를 공허에 쓰는 것과 같으며, 다시 말하지만 ... 이상적이지 않습니다.
원 드라이브는 시작일 뿐, 백업이 아니다
테스트 결과가 모두 정상으로 나와도 하나의 드라이브만으로 모든 데이터를 관리하는 것은 신뢰하지 않는 것이 좋습니다. 3-2-1 규칙을 따라, 만약 어떤 것이 갑자기 고장 나더라도(외장 드라이브라고 해서 면역이 되는 것은 아니므로), 어떻게든 안전할 수 있도록 하세요.








