백업에 사용하는 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
백업을 더욱 강력하게 만들고 미디어 성능 저하로 인한 오류로 인한 데이터 손실을 방지하는 훌륭한 도구라고 말하고 싶습니다. 오늘날의 하드 드라이브는 계속해서 증가하는 멀티 테라바이트 용량을 달성하기 위해 점점 더 높은 비트 밀도를 사용하고 있으므로 안전을 위해 백업에 여분의 중복성을 추가하는 것이 확실히 가치가 있다고 생각합니다.
마지막으로 비슷한 기능을 가진 또 다른 도구 vdmfec
는 par2
(매뉴얼 페이지) 그러나 완전히 다르게 작동합니다. 파일을 보관 par2
해야 하는 경우 split
이 도구가 더 적합한 도구일 수 있습니다. 이 도구는 par2
여러 개의 작은 파일로 분할된 대용량 파일(예: USENET 바이너리 그룹에 게시하기 위해)에 ECC를 추가하기 위해 개발되었기 때문입니다.