raid5와 같은 추가 ECC 데이터를 유지하지만 파일 시스템 내에서 단일 외부 드라이브의 내결함성을 만드는 파일 시스템이 있습니까?

raid5와 같은 추가 ECC 데이터를 유지하지만 파일 시스템 내에서 단일 외부 드라이브의 내결함성을 만드는 파일 시스템이 있습니까?

일반적으로 내결함성 또는 손상 복구 파일 시스템을 생성하려면 여러 드라이브와 raid 5 또는 raid 0 이외의 것을 사용합니다.

dar 등과 같은 내결함성 아카이브 파일을 만드는 방법도 여러 가지가 있습니다.

전원이 공급되지 않는 확장된 스토리지의 비트 부패로부터 단일 외부 SSD를 보다 안전하게 만드는 방법을 찾고 있습니다. 그렇지 않으면 드라이브를 일반 드라이브로 사용하고 문서가 필요할 때 다른 파일 시스템처럼 마운트하고 읽기/쓰기만 하면 됩니다. "내가 기분이 좋을 때"는 때로는 몇 년의 간격이 될 수 있습니다.

"일반"은 Windows 및 Mac에서 사용할 수 있다는 의미는 아닙니다. 그냥 리눅스.

답변1

첫째, 대부분의 최신 HDD에는 이미 내부 ECC 메커니즘(https://en.wikipedia.org/wiki/Hard_disk_drive#Error_rates_and_handling). RAID 5를 대체하지는 않지만 존재한다는 사실을 알게 되어 기쁩니다. 주로 #5, #187, #188, #197 및 #198과 같은 몇 가지 주요 SMART 속성을 적극적으로 모니터링하는 것이 좋습니다(https://www.backblaze.com/blog/hard-drive-smart-stats/).

파일 시스템의 경우, 귀하가 찾고 있는 것은 데이터 정리를 지원하는 FS인 것 같습니다(https://en.wikipedia.org/wiki/Data_scrubbing). ZFS는 이를 수행할 수 있습니다(https://docs.oracle.com/cd/E19253-01/819-5461/gbbxi/index.html)

[편집] 에서https://www.45drives.com/community/articles/zfs-best-practices/

ZFS 정리는 두려운 비트 부패를 처리하는 가장 좋은 방법입니다. ZFS는 블록을 읽을 때마다 해당 블록을 체크섬과 비교하고 필요한 경우 자동으로 복구합니다. 그러나 ZPool에 기록된 일부 데이터는 오랫동안 다시 읽히지 않을 수 있습니다.

다행히 이 데이터는 비트 부패로부터 자동으로 보호되지 않습니다. 이것이 우리가 데이터 정리를 하는 이유입니다. 가장 좋은 방법은 적어도 한 달에 한 번 스크럽을 계획하는 것입니다. 꼭 필요한 것은 아니지만 일부 사람들은 더 자주 또는 매주 스크럽을 원할 수도 있습니다. 정리 중에도 ZPool을 사용할 수 있지만 너무 집중적이지는 않지만 디스크의 일부 IO를 처리하므로 업무 외 시간이나 가동 중지 시간에 ZPool을 사용하도록 예약할 수 있습니다.

답변2

@체니스타언급하다ZFS하지만 더 낫거나 더 간단할 수 있는 다른 옵션도 있습니다(ZFS는무거운엘리베이터를 올바르게 사용하세요)

Btrfs와 ZFS는 이 작업을 수행할 수 있으며 다른 경우도 가능합니다.

  • BtrFS데이터 무결성을 보장하기 위해 다양한 해시 기능이 지원되며, 그 중 일부(예: SHA256)는 데이터 중복 제거에도 사용될 수 있습니다. 훌륭한 파일 시스템이지만 프로덕션 시스템의 경우 Ext4 등만큼 성숙하지는 않습니다.
  • XFS메타데이터에 대해 crc32 체크섬만 지원
  • 외부 4메타데이터의 crc32 체크섬만 지원되지만 활성화해야 합니다.Ext4 메타데이터 체크섬
  • ZFS다양한 해싱 알고리즘, 중복 제거 및 단일 디스크와 다중 디스크를 포함한 다중 데이터 중복 모드를 지원합니다. 학습 곡선이 약간 가파르지만 매우 성숙합니다.

DIY, 어쩌면 더 쉬울 수도 있어요

sha256모든 파일에 기록하고 해당 상태를 추적하며 문제에 대해 경고하는 자체 크론 작업 등을 갖는 것을 고려할 수도 있습니다 . 다음과 같은 곳에 고정 할 수도 있습니다 .외부 4사용하여확장된 속성다음과 같습니다. setfattr -n user.checksum -v "3baf9ebce4c664ca8d9e5f6314fb47fb" file.txt- 아니면 간단히 txt 파일로 어딘가에 저장하세요. 이를 통해 검사할 파일과 해당 동작을 완벽하게 제어할 수 있습니다. 파일을 가져와 복사한 다음 파일을 약간 손상시키고 무슨 일이 일어나는지 확인하여 이 메커니즘을 테스트할 수 있습니다. 비트를 삭제합니다(CLI에서는 수행하기 어렵습니다).

a=$(xxd -b -l 1 -seek 3 -p <original_important_file>);b=1;echo -e "\x$((${a}^${b}))" | dd of=<corrupted_important_file> bs=1 seek=3 count=1 conv=notrunc

나는 다음 소스에서 이 스크립트를 가져와 적용했습니다.@Kantium의 답변

관련 정보