¿Cómo depurar esto? Este problema ha aparecido repentinamente en los últimos días. Todas las copias de seguridad de un sitio web están dañadas.

Si la copia de seguridad se deja como tar, no hay problemas, pero tan pronto como el alquitrán se comprime gzo xzno puedo descomprimirlos.

Hay mucho disco libre

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

error

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%

¿Y por qué dice eso Skipping to next header? Nunca ha hecho eso antes. Algo está terriblemente mal en algunos de los archivos.

Hay alrededor de 15k archivos pdf, jpg o png en los directorios.

mando

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

Debe haber algunos datos que corrompan la compresión.

También he intentado verificar el estado del HDD haciendo esto:

# getting the drives
lsblk -dpno name

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

En ambas unidades obtengo esto:

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

¿Cómo puedo averiguar qué archivos están corrompiendo el tar.gz? Solo quiero eliminarlos.

actualizar

Ahora he copiado todos los archivos a otro servidor y tengo exactamente el mismo problema. Puedo tar todo y extraerlo sin problemas, pero tan pronto como quiero comprimir los archivos, no puedo descomprimirlos (gz / xz).

Su archivo está truncado o dañado, por xzlo que no puede llegar al final de los datos. tarse queja porque el archivo se detiene en el medio, lo cual es lógico ya xzque no logró leer todos los datos.

Ejecute los siguientes comandos para verificar dónde está el 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

Si se catqueja, el archivo está dañado en el disco y el sistema operativo detectó el daño. Consulte los registros del kernel para obtener más información; generalmente el disco necesita ser reemplazado en este punto. Si solo se xzqueja, el sistema operativo no detectó ningún daño, pero el archivo no es válido (dañado o truncado). De cualquier manera, no podrá recuperar este archivo. Deberá recuperarlo de sus copias de seguridad sin conexión.

¿No veo ninguna mención de cómo se crean los archivos tar rotos?

Dices que son copias de seguridad de un sitio web, pero los problemas que estás mostrando son todos al restaurar / desempaquetar, por lo que allí (la fuente) es donde debes poner el esfuerzo de resolución de problemas.

Si los archivos no pueden descomprimirse después de mover la copia de seguridad a otra máquina / ubicación, deben crearse defectuosos o interrumpirse en el transporte.

Para localizar la fuente del error:

• crear manualmente una copia de seguridad en el servidor web (sin pvy sin -i)
• probar manualmente la copia de seguridad en el servidor web (sin pvy sin -i)

Si no se han encontrado problemas hasta ahora:

• copia la copia de seguridad del servidor web
• probar la copia de seguridad copiada en la máquina de destino (sin pvy sin -i)

Si no se han encontrado problemas hasta ahora, el script de copia de seguridad no crea el archivo de la misma manera que lo hizo al hacerlo a mano (y probablemente debería modificarse para hacer lo que hizo manualmente).

Además, asegúrese de utilizar las rutas absolutas de todos los comandos involucrados. Si tiene un mal $PATHy / o $LD_LIBRARY_PATHvariable y un intruso en el sistema, puede estar usando binarios troyanos, lo que podría causar efectos secundarios no intencionales.

Por supuesto, también podrían ser tarversiones incompatibles , a menos que ambos sistemas sean debian. Puede intentar forzar el modo POSIX en ambos lados.

Estás usando la bandera -ique en su forma larga es --ignore-zeros. Es por eso que tar no se queja de los archivos que están dañados. Entonces, si desea depurar su archivo tar, simplemente elimine la -iopción y obtendrá la lista de archivos corruptos.

También hay otras 2 formas de encontrar archivos corruptos en Unix (en general). Cito una respuesta dada en otra pregunta.

rsync se puede usar para copiar directorios, y es capaz de reiniciar la copia desde el punto en que terminó si algún error causa la muerte de rsync.

Usando la --dry-runopción rsync puedes ver lo que se copiaría sin copiar nada. Las opciones --statsy --progresstambién serían útiles. y --human-readableo -hes más fácil de leer.

p.ej

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

No estoy seguro de si rsync está instalado de manera predeterminada en Mac OS X, pero lo he usado en Mac, así que sé que definitivamente está disponible.

Para una verificación rápida y sucia de si los archivos en un subdirectorio se pueden leer o no, puede usarlos grep -r XXX /path/to/directory/ > /dev/null. La expresión regular de búsqueda no importa, porque la salida se descarta de todos modos.

STDOUT se está redirigiendo a / dev / null, por lo que solo verá errores.

La única razón por la que elegí grep aquí fue por su -Ropción de recursión. Hay muchos otros comandos que podrían usarse en lugar de grep aquí, y aún más si se usan con find.

Como referencia: encontrar archivos corruptos

La línea de razonamiento en respuesta de @MattBianco es lo que seguiría metódicamente para resolver este problema en particular.

Los bloques puestos a cero indican EOF, pero eso depende del factor de bloqueo (el valor predeterminado es una constante compilada, generalmente 20). De Tar --compare| --diffparece ejecutarse con --ignore-zeros( -i) implícitamente.

Dada la complicación adicional de pv, sospecho que tar -iestá causando problemas xz, al mirar al hombre de alquitrán en el factor de bloqueo , sugeriría eliminar primero-i

Entonces, si eso no ayuda, reemplazar con:

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

Si solo está leyendo esto después de buscar en Google "alquitrán: un bloque cero solitario en N" , y no está canalizando nada, intente --ignore-zeros.