Bagaimana cara debug ini? Masalah ini tiba-tiba muncul dalam beberapa hari terakhir. Semua cadangan situs web rusak.

Jika cadangan dibiarkan begitu saja tar, tidak ada masalah, tetapi begitu tar dikompresi gzatau xzsaya tidak dapat mengompresnya.

Ada banyak disk gratis

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

kesalahan

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%

Dan mengapa dikatakan Skipping to next header? Belum pernah melakukan itu sebelumnya. Ada yang sangat salah pada beberapa file.

Ada sekitar 15 k file pdf, jpg, atau png di direktori.

perintah

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

Pasti ada beberapa data yang merusak kompresi.

Saya juga telah mencoba memeriksa kesehatan HDD dengan melakukan ini:

# getting the drives
lsblk -dpno name

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

Di kedua drive saya mendapatkan ini:

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

Bagaimana saya bisa mengetahui file mana yang merusak tar.gz? Saya hanya ingin menghapusnya.

memperbarui

Sekarang telah menyalin semua file ke server lain dan saya memiliki masalah yang sama persis. Saya bisa tar semuanya dan mengekstraknya tanpa masalah, tetapi begitu saya ingin mengompres file, saya tidak bisa membuka kompresi mereka (gz / xz).

File Anda terpotong atau rusak, jadi xztidak bisa sampai ke akhir data. tarmengeluh karena arsip berhenti di tengah, yang logis karena xztidak berhasil membaca seluruh data.

Jalankan perintah berikut untuk memeriksa di mana masalahnya:

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

Jika catmengeluh maka file rusak pada disk dan sistem operasi mendeteksi korupsi. Periksa log kernel untuk informasi lebih lanjut; biasanya disk perlu diganti pada saat ini. Jika hanya xzmengeluh maka OS tidak mendeteksi adanya kerusakan tetapi file tersebut tetap tidak valid (rusak atau terpotong). Bagaimanapun, Anda tidak akan dapat memulihkan file ini. Anda harus mendapatkannya kembali dari cadangan offline Anda.

Saya tidak melihat menyebutkan bagaimana file tar rusak dibuat?

Anda mengatakan itu cadangan dari situs web, tetapi masalah yang Anda tunjukkan adalah semua ketika memulihkan / membongkar, jadi ada (sumber) di mana Anda perlu melakukan upaya pemecahan masalah.

Jika file tidak dapat dikompresi setelah memindahkan cadangan ke komputer / lokasi lain, mereka harus dibuat salah, atau rusak dalam transportasi.

Untuk menemukan sumber kesalahan:

• secara manual membuat cadangan di server web (tanpa pvdan tanpa -i)
• menguji cadangan secara manual di server web (tanpa pvdan tanpa -i)

Jika tidak ada masalah yang ditemukan sejauh ini:

• salin cadangan dari server web
• uji cadangan yang disalin pada mesin target (tanpa pvdan tanpa -i)

Jika tidak ada masalah yang ditemukan sejauh ini, skrip cadangan tidak membuat arsip seperti yang Anda lakukan ketika melakukannya dengan tangan (dan mungkin harus dimodifikasi untuk melakukan apa yang Anda lakukan secara manual).

Juga, pastikan untuk menggunakan jalur absolut dari semua perintah yang terlibat. Jika Anda memiliki variabel buruk $PATHdan / atau $LD_LIBRARY_PATHpengganggu di sistem, Anda mungkin menggunakan binari trojan, yang dapat menyebabkan efek samping yang tidak disengaja.

Tentu saja bisa juga tarversi yang tidak kompatibel yang terlibat, kecuali kedua sistem debian. Anda bisa mencoba memaksa POSIX -mode di kedua sisi.

Anda menggunakan bendera -iyang dalam bentuk panjangnya --ignore-zeros. Inilah sebabnya mengapa tar tidak mengeluh tentang file yang rusak. Jadi, jika Anda ingin men-debug file tar Anda, hapus saja -iopsi dan Anda akan mendapatkan daftar file yang rusak.

Ada juga 2 cara lain untuk menemukan file yang rusak di unix (secara umum). Saya mengutip jawaban yang diberikan dalam pertanyaan lain.

rsync dapat digunakan untuk menyalin direktori, dan mampu memulai kembali salinan dari titik di mana ia dihentikan jika ada kesalahan yang menyebabkan rsync mati.

Menggunakan --dry-runopsi rsync Anda dapat melihat apa yang akan disalin tanpa benar-benar menyalin apa pun. The --statsdan --progresspilihan juga akan berguna. dan --human-readableatau -hlebih mudah dibaca.

misalnya

rsync --dry-run -avh --stats --progress / path / ke / src / / path / ke / tujuan /

Saya tidak yakin apakah rsync diinstal secara default pada Mac OS X, tetapi saya telah menggunakannya pada Mac jadi saya tahu pasti sudah tersedia.

Untuk pemeriksaan cepat dan kotor pada apakah file dalam subdirektori dapat dibaca atau tidak, Anda dapat menggunakan grep -r XXX /path/to/directory/ > /dev/null. Regexp pencarian tidak masalah, karena output tetap saja dibuang.

STDOUT sedang diarahkan ke / dev / null, jadi Anda hanya akan melihat kesalahan.

Satu-satunya alasan saya memilih grep di sini adalah karena -Ropsi rekursi. Ada banyak perintah lain yang bisa digunakan daripada grep di sini, dan bahkan lebih banyak lagi jika digunakan dengan find.

Sebagai referensi: Menemukan file yang rusak

Garis penalaran dalam jawaban oleh @MattBianco adalah apa yang saya ikuti secara metodis untuk menyelesaikan masalah khusus ini.

Blok nol menunjukkan EOF, tapi itu tergantung pada faktor blocking (defaultnya adalah konstanta yang dikompilasi, biasanya 20). Tar --compare| --difftampaknya mengeksekusi dengan --ignore-zeros( -i) secara implisit.

Mengingat kerumitan ekstra pv, saya curiga tar -imenyebabkan masalah xz, melihat tar man pada faktor pemblokiran yang saya sarankan untuk dihapus terlebih dahulu-i

Lalu jika itu tidak membantu, ganti dengan:

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

Jika Anda hanya membaca ini dengan googled "tar: A lone zero block at N" , dan tidak memipiskan apa pun, cobalah --ignore-zeros.