Watch at EaseHistorias. Respuestas. Perspectiva.

Guías de tecnología · GUÍA PRÁCTICA

Rsync código 24: audita los archivos desaparecidos antes de ignorar el aviso

El 24 indica que archivos de origen desaparecieron durante la transferencia. Conserva rutas y estado original, decide si importaban y verifica una repetición con origen estable antes de cambiar la automatización. Un envoltorio no convierte omisiones en una copia completa.

Ilustración editorial original de conservar rutas y estado rsync, clasificar omisiones y verificar repetición y datos.
Ilustración conceptual original: verifica rutas omitidas antes de aceptar el código 24. Watch at Ease

El código de salida 24 de rsync es una transferencia parcial por archivos de origen desaparecidos. Es distinto del 23, que indica transferencia parcial por otros errores. Que un archivo desaparezca después de detectarlo puede ser actividad normal, pero el estado no determina si era un bloqueo desechable o la única copia de datos importantes.

1. Conserva la ejecución antes de filtrar el aviso

Guarda stdout y stderr, hora, ambas versiones de rsync, raíces exactas de origen y destino, convención de barra final, filtros y opciones de borrado. Captura el estado real inmediatamente al terminar rsync; otro comando o una tubería puede devolverte el del registrador. Conserva las rutas desaparecidas con el identificador del respaldo.

En el siguiente intento controlado, --itemize-changes muestra cambios previstos o reales y --log-file=FILE conserva actividad. No supongas que ese registro sustituye stderr. Empieza por una ruta: ¿fue borrada, renombrada, inaccesible o existe en otra vista del origen? No destruyas la única prueba útil con un filtro amplio de avisos.

2. Decide qué omisiones son aceptables

Pregunta al responsable de la aplicación o los datos qué contienen las rutas. Un bloqueo o temporal conocido como desechable puede estar fuera del respaldo; un mensaje, documento o estado esencial no lo es porque su carpeta esté activa. Documenta una exclusión estrecha y revisada solo si la política permite perder ese contenido. Excluir todas las carpetas tmp o sufijos de bloqueo puede ocultar requisitos reales.

Un issue de Back In Time de 2023 muestra una instantánea real cancelada tras el 24. Su mantenedor informó que integró un cambio para registrarlo como información, manteniendo otros errores como errores. Es política de un producto, no prueba de omisiones inofensivas para todos. Si rutas importantes y estables desaparecen repetidamente, o hay errores de montaje e I/O, investiga el origen antes de normalizar el estado.

3. Repite con un origen verificable

Antes de repetir un comando con borrados, usa las mismas raíces y filtros revisados con --dry-run --itemize-changes para inspeccionar cambios, especialmente eliminaciones. La simulación no copia ni repara omisiones anteriores. Reduce cambios del origen mediante una ventana planificada de quietud o un procedimiento de instantáneas admitido por la aplicación; rsync sobre una aplicación activa no crea por sí solo un respaldo consistente de un momento.

Tras una repetición real aprobada, compara contenido requerido y documenta cada ruta importante. La comprobación rápida predeterminada usa tamaño y fecha de modificación; --checksum selecciona mediante sumas del contenido a costa de leer datos. No estabiliza un origen cambiante y es distinto de la verificación normal de reconstrucción de archivos transferidos. Comprueba contenido restaurado representativo o la prueba documentada de restauración de la aplicación, no solo un estado cero.

4. Cambia solo la política justificada

El envoltorio de la FAQ oficial convierte exactamente 24 en 0 y conserva otros estados. Adóptalo solo tras documentar omisiones esperadas y resultados aceptables, dejando el 24 original en registros o monitorización. No uses || true para convertir todo fallo en éxito. Una omisión crítica sin explicar sigue siendo incompleta para tu objetivo aunque el envoltorio devuelva cero.

Dos opciones de nombre parecido hacen otra cosa. --ignore-missing-args suprime el error de un argumento de origen solicitado que falta en la primera búsqueda; el manual dice que no afecta a archivos detectados y luego desaparecidos. --ignore-errors permite continuar --delete pese a errores I/O. Ninguna restaura archivos omitidos. Completar significa datos requeridos presentes y utilizables, omisiones explicadas y otros fallos visibles, no simplemente ausencia del aviso.

Ilustración original que distingue envoltorio de estado, argumentos inicialmente ausentes y borrado pese a errores I/O.
Ilustración conceptual original: las tres políticas difieren; ninguna prueba integridad ni restaura omisiones. Watch at Ease