일반적으로 복잡한 디렉터리 계층 구조 내에 중첩된 대규모 파일 컬렉션에 대한 체크섬을 캡처하고 유효성을 검사할 수 있기를 원합니다.
모든 단일 파일에 체크섬이 필요합니까? 기존 디렉터리 구조를 활용하여 파일 트리의 노드만 유효성을 검사하고 모든 파일이 반드시 유효성을 검사할 수 있는 방법이 있습니까?
답변1
체크섬을 사용하는 가장 효율적인 방법은 컴퓨터가 모든 작업을 수행하도록 하는 것입니다. 모든 데이터를 기록할 때 체크섬(실제로는 체크섬보다 강력한 해시를 사용함)을 계산하고 데이터를 읽을 때마다 이를 확인하는 ZFS와 같은 파일 시스템을 사용합니다. 물론 파일을 삭제하거나 덮어쓰는 것이 실수인지, 정상 작동인지 ZFS가 알 수 없다는 단점이 있지만 ZFS는 모든 것에 대해 쓰기 시 복사 의미 체계를 사용하기 때문에 스냅샷 기능을 사용하여 위험을 완화할 수 있습니다. .
ZFS는 또한 raid5 스타일 패리티, 드라이브 미러 또는 중복 복사본 등 사용자가 설정한 중복성을 사용하여 해시 검사에 실패한 데이터를 자동으로 복원할 수 있습니다. ZFS 파일 시스템에 Copy=N 속성을 추가하면 N 복사본이 저장됩니다. 귀하가 작성한 모든 데이터). 또한 파일의 해시 값은 블록의 해시에 따라 달라지고, 디렉터리 항목의 해시는 포함된 파일 및 디렉터리의 해시 값에 따라 달라지며, 파일 시스템의 해시는 Merkle 트리에 해시를 저장합니다. 루트 디렉토리의 해시 등
어떤 솔루션을 선택하든 프로세스는 CPU 속도가 아닌 디스크 속도에 의해 제한된다는 사실을 변함없이 발견하게 될 것입니다.
또한 디스크의 BER을 고려하는 것을 잊지 마십시오. 결국 그것들은 회전하는 녹의 단순한 판일 뿐입니다. 소비자 수준 드라이브의 오류율은 10^14비트 읽기마다 잘못 읽힌 비트 1이며, 이는 읽은 11테라바이트당 1비트에 해당합니다. 11테라바이트 데이터 세트가 있고 그 안에 있는 모든 파일의 해시를 계산하는 경우 체크섬 중 하나가 잘못 계산되어 데이터 세트에 있는 파일 중 하나의 블록이 영구적으로 손상됩니다. 그러나 ZFS는 풀의 모든 디스크에 쓴 모든 블록의 해시를 알고 있으므로 어떤 블록이 손실되었는지도 알 수 있습니다. 그런 다음 풀의 중복성(패리티, 미러 또는 추가 복사본)을 사용하여 해당 블록의 데이터를 올바른 값으로 다시 쓸 수 있습니다. 이러한 안전 기능은 zfs send 또는 receive를 사용하여 기본 시스템에서 백업으로 데이터를 복사할 때도 적용됩니다.
그러나 Ben은 댓글에서 좋은 점을 제시합니다. ZFS는 계산하는 해시 값을 사용자에게 공개하지 않으므로 ZFS 시스템에 들어오거나 나가는 데이터에는 해시가 함께 제공되어야 합니다. 나는 Internet Archive가 아카이브의 모든 항목과 함께 제공되는 xml 파일을 사용하여 이를 수행하는 방식을 좋아합니다. 보다https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml예로서.
답변2
어쩌면 지금이 이야기를 꺼내기에 좋은 때일 수도 있습니다백잇. 이는 디지털 개체의 보관, 장기 보존 및 전송을 위한 매우 간단하면서도 강력한 파일 패키징 형식입니다. 사용자로는 의회 도서관과 캘리포니아 디지털 도서관이 있습니다.
BagIt 도구(여러 프로그래밍 언어로 존재함)는 파일을 특정 디렉터리 구조에 넣고 체크섬/해싱을 수행합니다. 그게 전부입니다.
추신: 물론 BagIt 도구는 포함된 체크섬/해시와 비교하여 가방을 확인할 수도 있으며 일부 메타데이터를 가방에 추가할 수도 있습니다. 하지만 그것은 가방만큼 복잡합니다.
답변3
각 파일에 대해 체크섬을 생성합니다. 체크섬은 매우 작으며 전체 디렉토리에 대한 체크섬을 생성하려면 모든 파일도 처리해야 합니다(적어도 디렉토리 항목에서만 생성되는 디렉토리 체크섬에 대해 말하지 않는 경우 - 데이터가 없는지 확인하기 위해 체크섬도 만들 것입니다) 삭제됩니다.)
전체 아카이브에 대해 하나의 체크섬이 있다고 가정합니다. 데이터가 손상되었다는 것을 알지만 이것이 단 하나의 파일인지, 더 중요한 것은 그 중 어떤 파일인지 알 수 없습니다. 별도의 체크섬을 사용하면 더 많은 유연성을 얻을 수 있습니다. 손상된 단일 파일을 감지하고 다른 백업의 파일에서 교체할 수 있습니다(따라서 다른 파일이 손상될 수 있음).
그렇게 하면 데이터가 살아남을 가능성이 높아집니다.
답변4
답변을 검토했으며 ZFS를 사용하여 데이터 계층 오류를 처리한다는 아이디어가 마음에 들지만 실수로든 악의적으로든 파일이 변경되는 문제는 여전히 남아 있습니다. 이 경우 ZFS는 사용자를 보호하지 않으며 다른 사람이 언급한 것처럼 외부 검증을 위해 다른 곳에 저장할 사용자가 볼 수 있는 "해시"를 제공하지 않습니다.
시스템 실행 파일을 모니터링하고 공격 후 변경되지 않았는지 확인하는 데 광범위하게 사용된 TripWire라는 Linux 애플리케이션이 있습니다. 해당 프로젝트는 현재 폐기된 것으로 보이지만 AIDE (Advanced Intrusion Detection Environment)ServerFault에서 권장되는 새로운 프로젝트가 있습니다 .
https://serverfault.com/questions/62539/tripwire-and-alternatives
설치하면 사용자가 구성할 수 있는 매 x분마다 실행되며 지정한 모든 폴더에서 파일 변경 사항을 확인합니다. 모든 파일 해시를 계산하려면 한 번 실행해야 하며 그 후에는 현재 파일과 비교하여 모든 해시를 확인하고 여전히 동일한지 확인해야 합니다. 사용할 해시 유형 또는 해시 조합(SHA-256보다 약한 것은 권장하지 않음), 사용할 파일 속성(내용, 크기, 수정된 타임스탬프 등), 확인 빈도를 지정할 수 있습니다. 해시 데이터베이스 등을 저장하는 방법/위치
어떤 사람들은 이것이 과잉이라고 생각할 수도 있지만 OP의 요구 사항에 따라 그가 저장하고 있는 데이터가 특정 시점 이후에도 동일하게 유지된다는 점에서 OP의 요구 사항에 따라 더 안심할 수 있습니다.