외부 SATA/IDE 하드 드라이브에 백업하기 위해 vdmfec를 사용할 가치가 있습니까?

외부 SATA/IDE 하드 드라이브에 백업하기 위해 vdmfec를 사용할 가치가 있습니까?

백업에 사용하는 SATA/IDE 하드 드라이브 인클로저가 있습니다. Windows 및 OS/X 컴퓨터와 공유할 수 있어야 하기 때문에 VFAT를 사용하여 드라이브를 포맷합니다.

백업 스크립트 파이프 출력프레드픽파일에 대한 오류 수정을 제공합니다. (일부 오래된 백업 파일이 손상되었음을 발견했을 때 이 작업을 시작했습니다.)

위의 예맨페이지1.44MB "플로피 디스크"를 말합니다.

그래서 제 질문은: 하드 드라이브와 함께 vdmfec를 사용할 가치가 있습니까? (최신 하드 드라이브에는 오류 수정 기능이 내장되어 있다고 들었기 때문에) 그렇다면 기본값과 다른 설정을 사용해야 합니까?

또한: vdmfec보다 더 나은 Linux용 디버깅 도구가 있습니까?

답변1

백업에 오류 수정 코드(ECC)를 추가하는 것은 확실히 좋은 일입니다. 데이터 중복의 형태로 견고성을 얻으려면 추가 공간을 희생해야 합니다.

vdmfec좋은 작은 도구처럼 보입니다. 기본적으로 블록 크기는 b=1024바이트로 가정하고 모든 K=14 입력 블록에 대해 N=18 블록을 씁니다. 즉, 기본적으로 출력 크기는 14블록마다 NK=4블록씩 증가하며 크기는 약 29% 증가합니다. 매개변수 K와 N을 사용하면 어느 정도 중복성을 얻을 수 있지만 대부분의 경우 기본값이 괜찮을 것 같습니다.

그러나 알아야 할 몇 가지 잠재적인 문제가 있습니다. 먼저 매뉴얼 페이지에 따르면 다음과 같습니다.

N, K 및 블록 크기 매개변수는 출력에 기록되지 않습니다. 디코더를 실행할 때 동일한 매개변수를 지정해야 합니다. (실제로 디코더는 유효하지 않은 K 값을 명시적으로 감지할 수 있지만, 잘못된 블록 크기나 N 값은 불량 블록 및 디코딩 실패를 초래합니다.)

따라서 각 백업에 사용되는 특정 매개변수를 기록해 두십시오. 항상 기본값을 사용하더라도 새 버전의 프로그램에서는 기본값이 변경될 수 있으므로 이러한 값을 명시적으로 기록해 두는 것이 좋습니다.

둘째, 매뉴얼 페이지에는 다음과 같이 나와 있습니다.

디코더는 검색할 수 없는 미디어(예: 파이프)에서 데이터를 읽을 수 있지만 버퍼 언더런을 감지하지 못하여 오류가 발생합니다. 또한 파이프에서 읽을 때는 전체 파일을 읽어야 합니다. N 블록 중 K 개의 양호한 블록만 읽어야 하므로 검색 가능한 스트림에서 데이터를 읽는 것이 더 빠릅니다.

이는 vdmfec백업을 생성할 때 명령 파이프라인의 끝에 백업을 배치하는 것이 가장 좋고 가장 안전하다는 것을 의미합니다. 예를 들어:

tar -cf - /data | gzip | vdmfec > /backups/data.tgz.vdm

vdmfec백업 시 인코딩을 마지막에 수행함으로써 vdmfec복원 시 검색 불가능한 파이프가 아닌 검색 가능한 파일에 대해 디코더를 사용할 수 있으므로 파이프 사용 시 발생할 수 있는 잠재적인 문제를 피할 수 있습니다. 예를 들어:

vdmfec_decode /backups/data.tgz.vdm | zcat | tar -xf -

전체적으로 이것은 vdmfec백업을 더욱 강력하게 만들고 미디어 성능 저하로 인한 오류로 인한 데이터 손실을 방지하는 훌륭한 도구라고 말하고 싶습니다. 오늘날의 하드 드라이브는 계속해서 증가하는 멀티 테라바이트 용량을 달성하기 위해 점점 더 높은 비트 밀도를 사용하고 있으므로 안전을 위해 백업에 여분의 중복성을 추가하는 것이 확실히 가치가 있다고 생각합니다.

마지막으로 비슷한 기능을 가진 또 다른 도구 vdmfecpar2(매뉴얼 페이지) 그러나 완전히 다르게 작동합니다. 파일을 보관 par2해야 하는 경우 split이 도구가 더 적합한 도구일 수 있습니다. 이 도구는 par2여러 개의 작은 파일로 분할된 대용량 파일(예: USENET 바이너리 그룹에 게시하기 위해)에 ECC를 추가하기 위해 개발되었기 때문입니다.

관련 정보