Làm thế nào để tôi có hiệu quả tạo và xác nhận tổng kiểm tra tập tin?


12

Tôi muốn có thể chụp và xác thực tổng kiểm tra cho các bộ sưu tập tệp quy mô lớn, thường được lồng trong một hệ thống phân cấp thư mục phức tạp.

Có phải mọi tập tin đều cần một tổng kiểm tra? Có cách nào để tận dụng cấu trúc thư mục hiện có để xác nhận chỉ một nút trong cây tệp và không nhất thiết phải là mọi tệp trong đó không?


Như các câu trả lời lưu ý, điều quan trọng là phải phân biệt các loại mối đe dọa mà bạn đang giảm thiểu và kiểm tra theo đó. Một câu trả lời tràn thư viện và thông tin khoa học trước đây mà tôi đã đóng góp có thể được quan tâm, mặc dù chủ yếu là về HDFS.
Andy Jackson

Câu trả lời:


13

Cách hiệu quả nhất để sử dụng tổng kiểm tra là làm cho máy tính làm tất cả. Sử dụng một hệ thống tệp như ZFS, tổng kiểm tra (thực tế nó sử dụng băm, mạnh hơn tổng kiểm tra) tất cả dữ liệu khi được ghi và xác minh chúng mỗi khi dữ liệu được đọc. Tất nhiên, nhược điểm là ZFS không biết khi xóa hoặc ghi đè tệp là một lỗi và khi hoạt động bình thường, nhưng vì ZFS sử dụng ngữ nghĩa sao chép trên ghi cho mọi thứ, bạn có thể sử dụng tính năng chụp nhanh để giảm thiểu rủi ro .

ZFS cũng có thể tự động khôi phục dữ liệu không kiểm tra băm bằng cách sử dụng bất kỳ dự phòng nào bạn đã thiết lập, cho dù là kiểu chẵn lẻ 5, nhân bản ổ đĩa hoặc sao chép (thêm thuộc tính copy = N vào bất kỳ hệ thống tệp ZFS nào và nó sẽ lưu trữ N bản sao của bất kỳ dữ liệu bạn viết). Nó cũng lưu trữ các giá trị băm trong cây Merkle, trong đó giá trị băm của tệp phụ thuộc vào giá trị băm của các khối, hàm băm của một mục nhập thư mục phụ thuộc vào giá trị băm của các tệp và thư mục chứa, băm của hệ thống tệp phụ thuộc trên hàm băm của thư mục gốc, v.v.

Bất kể bạn kết thúc với giải pháp nào, bạn sẽ luôn thấy rằng quá trình này bị giới hạn bởi tốc độ của các ổ đĩa chứ không phải bởi tốc độ của CPU.

Ngoài ra, đừng quên tính đến BER của đĩa của bạn. Rốt cuộc, chúng chỉ là những tấm gỉ quay. Ổ đĩa cấp độ người tiêu dùng có tỷ lệ lỗi 1 bit đọc không chính xác cho mỗi 10 ^ 14 bit đọc, hoạt động đến 1 bit trên mỗi 11 terabyte bạn đọc. Nếu bạn có bộ dữ liệu 11 terabyte và bạn tính băm của mỗi tệp trong đó, bạn sẽ tính toán một trong những tổng kiểm tra đó không chính xác và làm hỏng vĩnh viễn một khối của một trong các tệp trong bộ dữ liệu. Tuy nhiên, ZFS biết hàm băm của mọi khối được ghi vào mọi đĩa trong nhóm của bạn và do đó biết khối nào bị mất. Sau đó, nó có thể sử dụng dự phòng (chẵn lẻ, gương hoặc bản sao bổ sung) trong nhóm của bạn để viết lại dữ liệu trong khối đó với các giá trị chính xác.

Ben đưa ra một điểm tốt trong các ý kiến ​​tuy nhiên. ZFS không để lộ bất kỳ giá trị băm nào mà nó tính toán cho người dùng, do đó dữ liệu nhập hoặc rời khỏi hệ thống ZFS phải đi kèm với giá trị băm. Tôi thích cách Lưu trữ Internet thực hiện điều này với tệp xml đi kèm với mọi mục trong kho lưu trữ. Xem https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml làm ví dụ.


1
Bạn đánh bại tôi vào nó. Tôi cũng sẽ đề xuất một hệ thống dựa trên hàm băm. Băm từng tệp, băm băm tệp (+ băm thư mục con) cho hàm băm thư mục, v.v. Sự đánh đổi là CPU / IO so với xác suất lỗi. Checksum / CRC là giá rẻ nhưng xác suất lỗi tăng theo tỷ lệ. Vì vậy, thực hiện băm phổ biến nhưng chúng bắt đầu với xác suất lỗi thấp hơn nhiều.
The Diamond Z

3
Ngay cả khi bạn chạy một hệ thống tệp như ZFS (Btrfs cũng có chức năng tương tự, nhưng vẫn đang được phát triển mạnh và không được coi là sẵn sàng để sử dụng sản xuất tại thời điểm này), bạn sẽ cần thực hiện thao tác "chà" định kỳ để đảm bảo dữ liệu được đọc và xác minh đối với tổng kiểm tra hoặc băm. Chỉ cần tính toán tổng kiểm tra và sau đó không làm gì với chúng cho đến khi bạn cần truy cập vào dữ liệu có khả năng tệ hơn là vô giá trị.
một CVn

1
Vâng, đó là một điểm tốt. Lần chà cuối cùng của tôi đã sửa được 2 kilobyte dữ liệu bị hỏng. Đó là bốn khối nằm rải rác trên năm ổ đĩa! Thời gian bạn đọc giữa một dữ liệu cụ thể càng lâu, xác suất bạn sẽ tích lũy đủ lỗi trong một tệp sẽ không thể khôi phục được dữ liệu đó.

1
Chạy một không gian người dùng md5sum với khoảng 150 GB dữ liệu trên PC ở nhà của tôi mất khoảng 40 phút thời gian, hoàn toàn là I / O bị ràng buộc. Nhân rộng gấp 100 lần, chúng tôi nhận được 15 TB được kiểm tra trong bóng râm dưới ba ngày, trên phần cứng của người tiêu dùng. Tôi chắc chắn sẽ xem xét điều đó có thể thực hiện được ngay cả trên một kho lưu trữ lớn, với khoảng thời gian được chọn đúng.
một CVn

3
ZFS tính toán tổng kiểm tra cho các khối, không phải tệp hoặc dòng bit, không? Mặc dù ZFS giải quyết vấn đề tính toán, nhưng có vẻ như nó ít có khả năng kiểm tra được con người và không tạo ra dữ liệu cố định có thể mang theo bất kể hệ thống tập tin - điều cần thiết cho việc lưu trữ.

6

Tôi sẽ tạo tổng kiểm tra cho mỗi tập tin. Tổng kiểm tra rất nhỏ và việc tạo tổng kiểm tra cho toàn bộ thư mục cũng sẽ yêu cầu bạn xử lý mọi tệp (ít nhất là nếu bạn không nói về tổng kiểm tra thư mục, chỉ được thực hiện từ các mục trong thư mục - Tôi cũng sẽ thực hiện chúng để đảm bảo không có dữ liệu bị xóa).

Giả sử bạn có một tổng kiểm tra cho toàn bộ kho lưu trữ. Bạn biết dữ liệu bị hỏng, nhưng bạn không biết nếu đây chỉ là một tệp, và quan trọng hơn, đó là tệp nào. Có tổng kiểm tra riêng biệt cho phép bạn linh hoạt hơn. Bạn có thể phát hiện một tệp bị hỏng và thay thế nó từ tệp từ bản sao lưu khác (do đó, có thể có tệp khác bị hỏng).

Bằng cách đó, dữ liệu của bạn có nhiều khả năng sống sót.


Điều đó chắc chắn có ý nghĩa. Tôi chỉ đang tự hỏi những chiến lược nào tồn tại để xử lý kỳ tích tốn kém về mặt tính toán khi tạo và kiểm tra hàng trăm ngàn tổng kiểm tra.

4

Có lẽ đây là thời điểm tốt để đưa lên BagIt . Đây là một định dạng đóng gói tệp rất đơn giản nhưng mạnh mẽ dành cho việc lưu trữ, bảo quản lâu dài và chuyển các đối tượng kỹ thuật số. Người dùng bao gồm Thư viện Quốc hội và Thư viện Kỹ thuật số California.

Một công cụ BagIt (chúng tồn tại trong một số ngôn ngữ lập trình) đặt các tệp của bạn vào một cấu trúc thư mục nhất định và thực hiện kiểm tra / băm cho bạn. Đó là tất cả.

PS: Tất nhiên, các công cụ BagIt cũng có thể xác minh các túi dựa trên tổng kiểm tra / băm và bạn có thể thêm một số siêu dữ liệu vào túi. Nhưng đó là phức tạp như túi có được.


1

Câu trả lời này là sự kết hợp của @ lechlukasz và @ db48x , cũng kết hợp một số điểm được đưa ra trong các nhận xét cũng như một số suy nghĩ của riêng tôi.

Đường dẫn đơn giản chuyển tiếp là một cách tiếp cận kết hợp hệ thống tệp và siêu dữ liệu riêng biệt.

Bằng cách sử dụng một hệ thống tệp thực hiện băm và xác thực dữ liệu nhanh chóng, chẳng hạn như ZFS hoặc Btrfs (lưu ý rằng mặc dù đã có những tiến bộ lớn, Btrfs không được coi là sẵn sàng để sử dụng sản xuất tại thời điểm này), bạn có thể hợp lý chắc chắn rằng nếu dữ liệu có thể được đọc ra khỏi đĩa mà không bị lỗi hệ điều hành, thì dữ liệu đọc được ghi vào đĩa theo cách mà hệ thống tệp dự định. Bằng cách chạy các hoạt động "chà" định kỳ, tất cả dữ liệu được đọc và xác minh theo ý tưởng của hệ thống tệp về những gì nó cần phải có.

Tuy nhiên, điều đó chỉ bảo vệ chống tham nhũng trên đĩa (các khối không thể đọc được, lỗi ghi phần cứng hoàn toàn, ghi không hợp lệ làm hỏng các phần dữ liệu trực tiếp trên thiết bị khối, v.v.). Nó không bảo vệ chống lại lỗi phần mềm, hoạt động không chính xác của người dùng hoặc phần mềm độc hại hoạt động thông qua các cơ sở hệ điều hành dự định để làm việc với các tệp, giả sử rằng các cơ sở đó không có các lỗi đó.

Để bảo vệ chống lại cái sau, bạn cần một lớp bảo vệ khác. Kiểm tra dữ liệu hoặc băm dữ liệu từ quan điểm của ứng dụng người dùng sẽ giúp bảo vệ chống lại nhiều rủi ro nêu trên, nhưng cần được thực hiện riêng (như là một hành động xử lý tích hợp trong phần mềm hoặc là một quy trình hoàn toàn riêng biệt).

Với phần cứng ngày nay và những gì thiết thực để lưu trữ một lượng lớn dữ liệu (quay đĩa cứng đĩa trái ngược với đĩa / SSD trạng thái rắn), ngay cả các thuật toán băm phức tạp như SHA1 sẽ phần lớn bị ràng buộc I / O - đó là tốc độ tại đó dữ liệu được băm sẽ là một chức năng của tốc độ đọc của hệ thống lưu trữ, thay vì khả năng của bộ xử lý của máy tính để tính toán hàm băm. Tôi đã thực hiện một thử nghiệm với việc chạy quy trình băm MD5 trong không gian người dùng với khoảng 150 GB dữ liệu về năm 2012 là một PC tiêu dùng hạng trung và nó đã hoàn thành sau khi thực hiện đĩa về cơ bản mà không bị gián đoạn trong khoảng 40 phút. Nhân rộng những con số đó lên gấp 100 lần, bạn sẽ nhận được băm MD5 của bộ sưu tập 15 TB trong khoảng ba ngày trên cùng một phần cứng. Bằng cách thêm tốc độ truyền đọc (có thể dễ dàng thực hiện, ví dụ:Ví dụ, RAID 0 bị tước mà không có dự phòng, thường được sử dụng để đạt được hiệu suất đọc / ghi cao hơn có thể kết hợp với RAID 1 hình thành RAID 10 ), thời gian hoàn thành có thể được giảm xuống cho cùng một lượng dữ liệu.

Bằng cách kết hợp cả hai, bạn sẽ có được cả hai thế giới tốt nhất: hệ thống tệp cho bạn đảm bảo rằng những gì bạn nhận được khi đọc tệp là những gì thực sự được viết và một quy trình kiểm tra độ cố định riêng biệt có thể chạy trên toàn bộ bộ sưu tập đảm bảo dữ liệu được lưu trữ vẫn khớp với những gì đã ăn vào kho lưu trữ. Bất kỳ sự không nhất quán nào giữa hai (hệ thống tệp cho biết tệp đều ổn, kiểm tra tính cố định cho biết là không) sẽ chỉ ra một tệp đã được sửa đổi bên ngoài chế độ hoạt động dự định của kho lưu trữ nhưng từ bên trong các cơ sở của hệ điều hành, nhắc nhở khôi phục từ phụ sao chép (sao lưu). Do đó, kiểm tra độ cố định có thể chạy trong khoảng thời gian dài hơn, điều này trở nên cần thiết cho kho lưu trữ rất lớn, nhưng mọi truy cập trực tuyến vẫn được đảm bảo không bị hỏng trên phần cứng nếu việc đọc thành công. Về nguyên tắc, phần mềm lưu trữ có thể dựa vào hệ thống tệp để báo cáo sự không nhất quán là lỗi đọc và thực hiện kiểm tra sửa lỗi riêng trong nền khi người dùng đang làm việc với tệp và hiển thị thông báo phù hợp cho biết tệp không khớp với những gì đã ăn. vào kho lưu trữ. Sử dụng một hệ thống tệp băm khối, một sơ đồ như vậy sẽ có tác động tối thiểu đến hiệu suất nhận thức trong khi vẫn đảm bảo rằng nội dung là chính xác.


1

Tôi đã trải qua các câu trả lời, và mặc dù tôi thích ý tưởng dựa vào ZFS để xử lý các lỗi của lớp dữ liệu, vẫn có vấn đề về các tệp bị thay đổi, do nhầm lẫn hoặc độc hại. ZFS sẽ không bảo vệ bạn trong trường hợp đó và giống như ai đó đã đề cập, nó sẽ không cung cấp cho bạn "hàm băm" có thể xem được của người dùng để lưu trữ ở một nơi khác để xác thực bên ngoài.

Có một ứng dụng Linux có tên TripWire được sử dụng rộng rãi để giám sát các hệ thống thực thi của hệ thống, để xác thực chúng chưa bị thay đổi sau một cuộc tấn công. Dự án đó dường như đã bị bỏ rơi, nhưng có một dự án mới được gọi AIDE (Advanced Intrusion Detection Environment), được đề xuất trên ServerFault:

/server/62539/tripwire-and-alternigin

Khi bạn cài đặt, nó sẽ chạy mỗi x phút, có thể định cấu hình người dùng và nó sẽ kiểm tra tất cả các thư mục bạn chỉ định để thay đổi trong các tệp. Nó cần phải chạy một lần để tính toán tất cả các giá trị băm của tệp và sau đó, nó sẽ kiểm tra tất cả các giá trị băm đối với tệp hiện tại và đảm bảo chúng vẫn giống nhau. Bạn có thể chỉ định loại băm hoặc kết hợp băm nào sẽ sử dụng (Tôi sẽ không đề xuất bất cứ thứ gì yếu hơn SHA-256), thuộc tính tệp nào sẽ sử dụng (nội dung, kích thước, dấu thời gian đã sửa đổi, v.v.), tần suất mà nó kiểm tra, Làm thế nào / nơi để lưu trữ cơ sở dữ liệu băm, vv

Một số người có thể xem xét mức độ quá mức này, nhưng tùy thuộc vào yêu cầu của OP, điều đó có thể giúp anh ta yên tâm hơn rằng dữ liệu anh ta lưu trữ sẽ giữ nguyên sau một thời gian nhất định.


0

Kho lưu trữ quốc gia Úc đã phát triển [Checksum Checker] ( http://checksumchecker.sourceforge.net/ ) được cung cấp miễn phí theo GPLv3.

Nó đọc tổng kiểm tra và thuật toán từ cơ sở dữ liệu, sau đó tính toán lại tổng kiểm tra cho tệp, so sánh hai giá trị và báo cáo nếu có lỗi. Nó hỗ trợ các thuật toán MD5, SHA1, SHA2, SHA256 và SHA512.

Phần mềm khác trong kho kỹ thuật số của họ [DPR] ( http://dpr.sourceforge.net/ ) tạo ra tổng kiểm tra ban đầu (cũng như thực hiện tất cả các hoạt động xử lý khác)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.