Kiểm tra truyền tệp qua mạng:
Có một máy chủ tệp MS và hai máy khách (để bộ nhớ đệm cục bộ có thể có tại máy khách không cản trở kết quả của bạn).
Trên máy khách số 1, tạo các tệp (có nội dung ngẫu nhiên?) và lưu chúng vào máy chủ. Đồng thời, tính toán tổng kiểm tra (ví dụ md5sum?)
Trên máy khách số 2, tải từng tệp một từ máy chủ và tính tổng kiểm tra. Bạn thực sự có thể chạy một công cụ tổng kiểm tra, chẳng hạn như md5sum, trên mỗi tệp trên một chia sẻ mạng được ánh xạ (từ máy khách số 2). Và, so sánh tổng kiểm tra với những gì máy nguồn đã tạo ra.
Đây chỉ là một ý tưởng cơ bản. Bạn sẽ cần thực hiện một số thao tác viết kịch bản để tự động kiểm tra và để chúng chạy trong khoảng một ngày cuối tuần. Và có lẽ nếu bitrot không xảy ra ngay lập tức và diễn ra trên các ổ đĩa, có lẽ kiểu kiểm tra nhanh này sẽ không tìm thấy gì.
Nếu bạn có một ví dụ cụ thể/sự cố hỏng dữ liệu, có cách nào để bạn có được tệp gốc và tệp bị hỏng, tệp đó phải giống hệt nhau không? Những tập tin đó có định dạng gì? Đây có phải là tệp văn bản có thể đọc được bằng máy (chẳng hạn như XML) hay tệp nhị phân nào đó không? Có lẽ nội dung có thể được so sánh, để xem chính xác tham nhũng trông như thế nào. Bản chất của tham nhũng có thể cung cấp thêm gợi ý về việc điều này có thể đến từ đâu.
Ngoài từ "diff" cổ điển hoạt động trên văn bản ASCII, tôi nhớ lại có các công cụ dành riêng cho so sánh nhị phân.
Ngoài ra, máy chủ lưu trữ có chạy sao lưu không? Chi tiết phụ thuộc vào sơ đồ sao lưu, nhưng vấn đề là nếu một bản sao lưu phía máy chủ cũ chứa một tệp lành mạnh và tệp hiện tại từ máy chủ bị hỏng, điều đó có thể thu hẹp vấn đề của bạn. Và để ngoại suy chủ đề sao lưu này, nếu thiết lập gặp sự cố với hỏng dữ liệu và không có sơ đồ sao lưu chống đạn, thì tổ chức của bạn cần thêm lý do gì để giải quyết vấn đề này?
Ngay cả khi bạn không còn tệp gốc lành mạnh nữa: nếu tệp bị hỏng cuối cùng bị một phần mềm phân tích cú pháp từ chối, thì sẽ rất tuyệt nếu bạn có được nhật ký gỡ lỗi chi tiết hơn, xem trình phân tích cú pháp tạm dừng ở đâu, tệp ở đâu không còn "được hình thành tốt" - nhưng tôi hiểu rằng trong phần mềm nguồn đóng hoạt động trên định dạng tệp đóng, bạn thường không có cơ hội đó.
Mọi người nói rằng đây chính xác là mục đích của phần cứng lưu trữ doanh nghiệp duy trì "siêu dữ liệu toàn vẹn" dọc theo "chuỗi tín hiệu" - tức là các phiên bản hiện đại của SCSI và các công nghệ kết nối có nguồn gốc (FC, SAS) và loại rỉ sét tương ứng, không chắc chắn nếu có SSD với khả năng đó. Thay vì cung cấp các gợi ý cụ thể, tôi khuyên bạn nên hỏi google về tính toàn vẹn của dữ liệu trong Linux. Rất có thể đây chính xác là thứ đã cắn bạn, ở cấp độ phần cứng.Bạn biết bao nhiêu về hệ thống con lưu trữ cơ bản của mình trong máy chủ?
Và, mặc dù đây là một cơ hội mong manh: nếu bạn thường gặp sự cố khi mở cũ tệp: phần mềm ứng dụng làm việc với các tệp có được cập nhật không? Đây có thể là trường hợp bản cập nhật ứng dụng phá vỡ khả năng tương thích với dữ liệu cũ không? Nếu bạn không có bản sao lưu của toàn bộ tệp, có lẽ bạn có thể sắp xếp chỉ nhận tổng kiểm tra được ghi chú ở đâu đó, cùng với tên tệp, kích thước và dấu thời gian, để xem liệu tệp được truy xuất 6 tháng sau giống hay khác?
Được lưu bởi một "thủ tục tải thủ công tẻ nhạt" - chính xác đó là gì?
Một số thuật toán khôi phục hoạt động trên tệp bị hỏng?
Hay chỉ truy xuất tệp gốc khỏe mạnh từ bản sao lưu cũ tương ứng?
Cả hai trường hợp đều có khả năng tìm hiểu thêm về bản chất của vấn đề: hoặc bạn sẽ có thể so sánh tệp bị hỏng với một tệp gốc tốt hoặc có thể tìm hiểu quy trình "khôi phục" thực sự làm gì trên tệp "bị hỏng" .
