Làm thế nào để gỡ lỗi này? Vấn đề này đã bất ngờ xuất hiện trong vài ngày qua. Tất cả các bản sao lưu của một trang web bị hỏng.

Nếu bản sao lưu chỉ còn lại tar, không có vấn đề gì, nhưng ngay sau đó tar được nén gzhoặc xztôi không thể giải nén chúng.

Có rất nhiều đĩa miễn phí

Local disk space    2.68 TB total / 2.26 TB free / 432.46 GB used

lỗi

tar: Skipping to next header[===============================>                                                    ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================>                                                ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
 878MiB 0:00:58 [15.1MiB/s] [===================================>                                                ] 44%

Và tại sao nó nói Skipping to next header? Nó chưa bao giờ làm điều đó trước đây. Một cái gì đó là sai lầm khủng khiếp một số các tập tin.

Có khoảng 15k tệp pdf, jpg hoặc png trong các thư mục.

chỉ huy

pv $backup_file | tar -izxf - -C $import_dir

Phải có một số dữ liệu làm hỏng việc nén.

Tôi cũng đã thử kiểm tra sức khỏe của ổ cứng bằng cách này:

# getting the drives
lsblk -dpno name

smartctl -H /dev/sda
smartctl -H /dev/sdb

Trên cả hai ổ đĩa tôi nhận được điều này:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Làm cách nào tôi có thể tìm ra tệp nào đang làm hỏng tar.gz? Tôi chỉ muốn xóa chúng.

cập nhật

Hiện đã sao chép tất cả các tệp sang máy chủ khác và tôi có cùng một vấn đề. Tôi có thể tar mọi thứ và giải nén nó mà không gặp vấn đề gì, nhưng ngay sau khi tôi muốn nén các tệp, tôi không thể giải nén chúng (gz / xz).

Tệp của bạn bị cắt ngắn hoặc bị hỏng, vì vậy xzkhông thể đi đến cuối dữ liệu. tarphàn nàn vì kho lưu trữ dừng ở giữa, điều này hợp lý vì xzkhông quản lý để đọc toàn bộ dữ liệu.

Chạy các lệnh sau để kiểm tra xem sự cố ở đâu:

cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null

Nếu catphàn nàn thì tập tin bị hỏng trên đĩa và hệ điều hành đã phát hiện ra tham nhũng. Kiểm tra nhật ký kernel để biết thêm thông tin; thường thì đĩa cần được thay thế vào thời điểm này. Nếu chỉ xzphàn nàn thì HĐH đã không phát hiện ra bất kỳ tham nhũng nào nhưng tệp vẫn không hợp lệ (bị hỏng hoặc bị cắt bớt). Dù bằng cách nào, bạn sẽ không thể khôi phục tệp này. Bạn sẽ cần lấy lại từ bản sao lưu ngoại tuyến của mình.

Tôi không thấy bất kỳ đề cập nào về cách các tập tin tar bị hỏng được tạo ra?

Bạn nói rằng đó là bản sao lưu từ một trang web, nhưng các vấn đề bạn đang thể hiện là tất cả khi khôi phục / giải nén, do đó (nguồn) là nơi bạn cần đặt nỗ lực xử lý sự cố.

Nếu các tệp không thể được giải nén sau khi di chuyển bản sao lưu sang máy / vị trí khác, chúng phải được tạo ra bị lỗi hoặc bị hỏng khi vận chuyển.

Để xác định nguồn gốc của lỗi:

• tự tạo bản sao lưu trên máy chủ web (không có pvvà không có -i)
• kiểm tra thủ công bản sao lưu trên máy chủ web (không có pvvà không có -i)

Nếu không có vấn đề được tìm thấy cho đến nay:

• sao chép bản sao lưu từ máy chủ web
• kiểm tra bản sao lưu được sao chép trên máy đích (không có pvvà không có -i)

Nếu không có vấn đề nào được tìm thấy cho đến nay, tập lệnh sao lưu không tạo ra kho lưu trữ giống như cách bạn đã làm khi thực hiện bằng tay (và có lẽ nên được sửa đổi để làm những gì bạn đã làm thủ công).

Ngoài ra, đảm bảo sử dụng các đường dẫn tuyệt đối của tất cả các lệnh liên quan. Nếu bạn có một lỗi xấu $PATHvà / hoặc $LD_LIBRARY_PATHbiến và một kẻ xâm nhập trong hệ thống, bạn có thể đang sử dụng các nhị phân trojan, điều này có thể gây ra tác dụng phụ không chủ ý.

Tất nhiên nó cũng có thể là tarcác phiên bản không tương thích có liên quan, trừ khi cả hai hệ thống đều là debian. Bạn có thể thử buộc POSIX -mode ở cả hai bên.

Bạn đang sử dụng cờ -iở dạng dài --ignore-zeros. Đây là lý do tại sao tar không phàn nàn về các tập tin bị hỏng. Vì vậy, nếu bạn muốn gỡ lỗi tệp tar của mình, chỉ cần xóa -itùy chọn và bạn sẽ nhận được danh sách các tệp bị hỏng.

Ngoài ra còn có 2 cách khác để tìm các tệp bị hỏng trên unix (nói chung). Tôi trích dẫn một câu trả lời trong một câu hỏi khác.

rsync có thể được sử dụng để sao chép các thư mục và có khả năng khởi động lại bản sao từ thời điểm nó bị chấm dứt nếu có bất kỳ lỗi nào khiến rsync bị chết.

Sử dụng --dry-runtùy chọn của rsync, bạn có thể thấy những gì sẽ được sao chép mà không thực sự sao chép bất cứ điều gì. Các tùy chọn --statsvà --progresscũng sẽ hữu ích. và --human-readablehoặc -hdễ đọc hơn.

ví dụ

rsync --dry-run -avh --stats --proceed / path / to / src / / path / to / Destination /

Tôi không chắc nếu rsync được cài đặt theo mặc định trên Mac OS X, nhưng tôi đã sử dụng nó trên máy Mac nên tôi biết nó chắc chắn có sẵn.

Để kiểm tra nhanh và bẩn về việc các tệp trong thư mục con có thể được đọc hay không, bạn có thể sử dụng grep -r XXX /path/to/directory/ > /dev/null. Chế độ tìm kiếm regrec không thành vấn đề, vì dù sao đầu ra cũng bị loại bỏ.

STDOUT đang được chuyển hướng đến / dev / null, vì vậy bạn sẽ chỉ thấy lỗi.

Lý do duy nhất tôi chọn grep ở đây là vì -Rtùy chọn đệ quy của nó . Có nhiều lệnh khác có thể được sử dụng thay vì grep ở đây và thậm chí nhiều hơn nếu được sử dụng với find.

Như tài liệu tham khảo: Tìm tập tin bị hỏng

Dòng lý luận trong câu trả lời của @MattBianco là những gì tôi sẽ làm theo phương pháp để giải quyết vấn đề cụ thể này.

Các khối không biểu thị EOF, nhưng điều đó phụ thuộc vào hệ số chặn (mặc định là hằng số được biên dịch, thường là 20). Tar --compare| --diffxuất hiện để thực thi với --ignore-zeros( -i) ngầm.

Do sự phức tạp thêm của pv, tôi nghi ngờ tar -iđang gây ra vấn đề xz, nhìn vào người đàn ông tar về yếu tố chặn tôi đề nghị loại bỏ trước tiên-i

Sau đó, nếu điều đó không giúp đỡ, thay thế bằng:

--read-full-records --blocking-factor=300

Nếu bạn chỉ đang đọc cái này có "tar: Một khối không đơn độc tại N" , và không làm gì cả thì hãy thử --ignore-zeros.