Come eseguire il debug di questo? Questo problema è improvvisamente apparso negli ultimi due giorni. Tutti i backup di un sito Web sono danneggiati.

Se il backup viene lasciato come tar, non ci sono problemi, ma non appena il tar viene compresso gzo xznon riesco a decomprimerli.

C'è molto disco libero

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

errore

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%

E perché dice Skipping to next header? Non l'ha mai fatto prima. Qualcosa di terribilmente sbagliato in alcuni file.

Ci sono circa 15k file pdf, jpg o png nelle directory.

comando

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

Ci devono essere alcuni dati che corrompono la compressione.

Ho anche provato a controllare lo stato dell'HDD facendo questo:

# getting the drives
lsblk -dpno name

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

Su entrambe le unità ottengo questo:

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

Come posso sapere quali file stanno danneggiando tar.gz? Voglio solo cancellarli.

aggiornare

Ora ho copiato tutti i file su un altro server e ho lo stesso identico problema. Posso tarare tutto ed estrarlo senza problemi, ma appena voglio comprimere i file, non riesco a decomprimerli (gz / xz).

Il tuo file è troncato o danneggiato, quindi xznon puoi arrivare alla fine dei dati. tarsi lamenta perché l'archivio si interrompe nel mezzo, il che è logico poiché xznon è riuscito a leggere tutti i dati.

Esegui i seguenti comandi per verificare dove si trova il problema:

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

Se si catlamenta, il file è danneggiato sul disco e il sistema operativo ha rilevato il danneggiamento. Controllare i log del kernel per ulteriori informazioni; di solito il disco deve essere sostituito a questo punto. Se solo si xzlamenta, il sistema operativo non ha rilevato alcun danneggiamento ma il file non è tuttavia valido (danneggiato o troncato). Ad ogni modo, non sarai in grado di recuperare questo file. Dovrai recuperarlo dai tuoi backup offline.

Non vedo alcuna menzione di come vengono creati i file tar danneggiati?

Dici che si tratta di backup da un sito web, ma i problemi che stai mostrando sono tutti relativi al ripristino / al disimballaggio, quindi lì (l'origine) è dove devi mettere lo sforzo di risoluzione dei problemi.

Se i file non possono essere decompressi dopo aver spostato il backup in un'altra macchina / posizione, devono essere creati difettosi o interrotti durante il trasporto.

Per individuare l'origine dell'errore:

• creare manualmente un backup sul server Web (senza pve senza -i)
• testare manualmente il backup sul server Web (senza pve senza -i)

Se nessun problema riscontrato finora:

• copia il backup dal web server
• testare il backup copiato sul computer di destinazione (senza pve senza -i)

Se non sono stati riscontrati problemi finora, lo script di backup non crea l'archivio nello stesso modo in cui lo hai fatto manualmente (e probabilmente dovrebbe essere modificato per fare ciò che hai fatto manualmente).

Inoltre, assicurati di utilizzare i percorsi assoluti di tutti i comandi coinvolti. Se si dispone di una variabile errata $PATHe / o $LD_LIBRARY_PATHvariabile e di un intruso nel sistema, è possibile che si stiano utilizzando file binari di tipo trojan che potrebbero causare effetti collaterali involontari.

Naturalmente potrebbero essere tarcoinvolte anche versioni incompatibili , a meno che entrambi i sistemi non siano debian. Potresti provare a forzare la modalità POSIX su entrambi i lati.

Stai usando la bandiera -iche nella sua forma lunga è --ignore-zeros. Questo è il motivo per cui tar non si lamenta dei file danneggiati. Quindi, se vuoi eseguire il debug del tuo file tar, basta rimuovere l' -iopzione e otterrai l'elenco dei file danneggiati.

Esistono anche altri 2 modi per trovare file danneggiati su unix (in generale). Cito una risposta fornita in un'altra domanda.

rsync può essere usato per copiare le directory ed è in grado di riavviare la copia dal punto in cui è stata terminata se un errore fa morire rsync.

Usando l' --dry-runopzione rsync puoi vedere cosa verrebbe copiato senza effettivamente copiare nulla. Le opzioni --statse --progresssarebbero anche utili. ed --human-readableo -hè più facile da leggere.

per esempio

rsync --dry-run -avh --stats --progress / path / to / src / / path / to / destination /

Non sono sicuro che rsync sia installato per impostazione predefinita su Mac OS X, ma l'ho usato su Mac quindi so che è sicuramente disponibile.

Per un controllo rapido se i file in una sottodirectory possono essere letti o meno, è possibile utilizzare grep -r XXX /path/to/directory/ > /dev/null. La ricerca regexp non ha importanza, perché l'output viene comunque scartato.

STDOUT viene reindirizzato su / dev / null, quindi vedrai solo errori.

L'unica ragione per cui ho scelto grep qui è stata la sua -Ropzione di ricorsione. Ci sono molti altri comandi che potrebbero essere usati al posto di grep qui, e ancora di più se usati con find.

Come riferimento: ricerca di file danneggiati

La linea di ragionamento nella risposta di @MattBianco è ciò che seguirei metodicamente per risolvere questo particolare problema.

I blocchi azzerati indicano EOF, ma dipende dal fattore di blocco (il valore predefinito è una costante compilata, in genere 20). Tar --compare| --diffsembra eseguire implicitamente con --ignore-zeros( -i).

Data l'ulteriore complicazione di pv, ho il sospetto che tar -istia causando problemi xz, guardando tar man sul fattore di blocco che suggerirei prima di rimuovere-i

Quindi se ciò non aiuta, sostituendo con:

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

Se stai leggendo questo dopo aver cercato su Google "tar: un blocco zero solitario su N" e non stai eseguendo il piping di nulla, allora prova --ignore-zeros.