☰

error

tag-icon • tag-icon debian tar corruption
error

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

Si la copia de seguridad se deja simplemente como tar, no hay problemas, pero en cuanto se comprime el tar 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 Skipping to next header? Nunca antes lo había hecho. Algo anda terriblemente mal en algunos de los archivos.

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

dominio

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

Debe haber algunos datos que corrompen la compresión.

También intenté verificar el estado del disco duro haciendo esto:

# getting the drives
lsblk -dpno name

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

En ambas unidades me sale esto:

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

¿Cómo puedo saber qué archivos están dañando tar.gz? Solo quiero borrarlos.

actualizar

Ahora copié todos los archivos a otro servidor y tengo exactamente el mismo problema. Puedo tar todo y extraerlo sin problemas, pero en cuanto quiero comprimir los archivos, no puedo descomprimirlos (gz/xz).

Respuesta1

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

Ejecute los siguientes comandos para comprobar 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 catse queja, entonces el archivo está dañado en el disco y el sistema operativo detectó la corrupción. Consulte los registros del kernel para obtener más información; normalmente es necesario reemplazar el disco en este punto. Si solo xzse queja, entonces el sistema operativo no detectó ningún daño, pero el archivo no es válido (ya sea dañado o truncado). De cualquier manera, no podrá recuperar este archivo. Deberá recuperarlo de sus copias de seguridad fuera de línea.

Respuesta2

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

Usted dice que son copias de seguridad de un sitio web, pero los problemas que muestra se deben a la restauración/descompresión, por lo que allí (la fuente) es donde debe esforzarse en solucionar el problema.

Si los archivos no se pueden descomprimir después de mover la copia de seguridad a otra máquina/ubicación, deben haber sido creados defectuosos o rotos durante 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 el momento:

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

Si no se han encontrado problemas hasta el momento, el script de copia de seguridad no crea el archivo de la misma manera que lo hizo manualmente (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 problema $PATHy/o $LD_LIBRARY_PATHvariable y un intruso en el sistema, es posible que esté utilizando archivos binarios troyanos, lo que podría provocar efectos secundarios no intencionados.

Por supuesto, también podría ser incompatibletar tratarse de versiones incompatibles, a menos que ambos sistemas sean Debian. Podrías intentar forzarPOSIX-modo en ambos lados.

Respuesta3

Estás usando la bandera -ique en su forma larga es --ignore-zeros. Es por eso que tar no se queja de los archivos corruptos. 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 utilizar para copiar directorios y es capaz de reiniciar la copia desde el punto en el que terminó si algún error hace que rsync muera.

Usando la opción de rsync --dry-runpuedes 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 /ruta/al/src/ /ruta/al/destino/

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

Para comprobar de forma rápida y sencilla si los archivos de un subdirectorio se pueden leer o no, puede utilizar 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 está siendo redirigido 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 recursividad. 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

Respuesta4

La línea de razonamiento en respuesta de @MattBianco es la que yo seguiría metódicamente pararesolvereste tema en particular.

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

Dada la complicación adicional pv, sospecho tar -ique está causando problemas al xzmirarhombre alquitrán en el factor de bloqueoYo sugeriría primero eliminar-i

Entonces, si eso no ayuda, reemplácelo con:

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

Si recién estás leyendo esto después de haber buscado en Google"alquitrán: un bloque cero solitario en N", y no estás canalizando nada, entonces inténtalo --ignore-zeros.

información relacionada