Cuatro formas de deduplicar con jdupes: CoW, enlaces simbólicos, enlaces duros y borrado

Guía de jdupes -B, -l, -L y -d desde la perspectiva del sistema de archivos, con su semántica, límites de seguridad, métodos de verificación y medidas para evitar pérdidas de datos.

jdupes Una vez que encuentre archivos duplicados, puede tratarlos de cuatro maneras completamente diferentes:

  • -B --dedupe: permite que archivos duplicados compartan bloques de datos subyacentes;
  • -l --link-soft: Reemplazar copias duplicadas con enlaces simbólicos relativos;
  • -L --link-hard: Reemplazar copias duplicadas con enlaces duros;
  • -d --delete: Selecciona de forma interactiva archivos para conservar y elimina las copias restantes.

Estas cuatro opciones pueden reducir los datos duplicados, pero no pueden entenderse simplemente como cuatro “eliminar archivos duplicados” escritos de diferentes maneras.

Cambian objetos en diferentes niveles: bloques de datos, inodos, referencias de ruta o entradas de directorio.

Al tomar una decisión equivocada, lo más problemático a menudo no es que se informe de un error en el acto, sino que unos meses más tarde un programa modifica, mueve o elimina un archivo, sólo para descubrir que otras rutas también están afectadas.

Este artículo comienza con las especificaciones y el comportamiento del sistema de archivos para explicar las diferencias reales, los escenarios aplicables, las restricciones y los métodos de verificación de los cuatro modos.

Recordatorio especial: jdupes -d es una operación que eliminará archivos. No escriba el mismo directorio repetidamente en la línea de comando y no use -d con -s o --symlinks sin comprender completamente el comportamiento transversal de enlaces simbólicos.

Comparación rápida: diferencias clave entre los cuatro métodos

Opciones Resultados del procesamiento Si se conserva la ruta ¿El inodo es independiente? ¿Las modificaciones posteriores se afectan entre sí? Principales limitaciones
-B --dedupe Compartir el mismo bloque de datos físicos mantener todo Normalmente no se ve afectado, CoW se desprende al escribir. El sistema de archivos debe admitir interfaces de deduplicación o clonación.
-l --link-soft La copia se convierte en un enlace simbólico relativo. El nombre de la ruta permanece, pero el tipo se convierte en enlace simbólico. propio inodo del enlace simbólico, el contenido proviene del objetivo Modificar el contenido al que apunta el enlace modificará el archivo de destino El destino puede convertirse en un enlace roto después de moverlo o eliminarlo.
-L --link-hard Varias rutas que apuntan al mismo inodo. mantener todo No Afectará, porque es esencialmente el mismo archivo. No se pueden cruzar sistemas de archivos, la semántica de la aplicación puede cambiar
-d --delete Eliminar copias no seleccionadas para retención Mantener solo rutas seleccionadas no aplicable No habrá ningún vínculo, pero la ruta eliminada desaparecerá por completo. Elegir el incorrecto perderá directamente la ruta y los metadatos.

Si solo recuerdas una frase, puedes juzgarla así:

  • Quiere que cada archivo permanezca independiente y que el sistema de archivos admita CoW: dé prioridad a -B;
  • Existe una necesidad explícita de múltiples nombres de archivos que colectivamente representen el mismo archivo: considere -L;
  • Quiere explícitamente que algunas rutas sean solo referencias a otro archivo: considere -l;
  • Confirme que la ruta redundante no tiene valor de conservación: utilice únicamente -d.

¿Cómo confirma jdupes que dos archivos son iguales?

Aunque los métodos de procesamiento son diferentes, el proceso anterior de identificación de archivos duplicados es el mismo.

Según el manual oficial de jdupes, el proceso de coincidencia predeterminado incluye:

  1. Comparar tamaños de archivos;
  2. Comparar hashes de archivos parciales;
  3. Comparar hashes de archivos completos;
  4. Finalmente, se realiza una comparación byte a byte.

Sólo los archivos que pasen estas etapas ingresarán a la misma colección de archivos duplicados.

Por lo tanto, el modo predeterminado no es “si los nombres de los archivos son iguales, incluso si están duplicados”, ni es “si los hash son iguales, realice la operación inmediatamente”.

Sin opciones de acción, jdupes solo imprime conjuntos de archivos duplicados de forma predeterminada:

1
jdupes -r /srv/data

Los diferentes conjuntos están separados por líneas en blanco.

Antes de utilizar -B, -l, -L o -d, debe ejecutar un análisis de solo lectura para confirmar que el rango de ruta y los resultados coincidentes son los esperados.

No pase por alto la verificación final en aras de la velocidad

-Q --quick omite la confirmación byte por byte y se basa únicamente en el resultado del hash.

El manual oficial lo señala claramente como un riesgo de pérdida de datos.

-T --partial-only es más riesgoso porque solo coincide con un hash parcial al principio del archivo.

Al realizar la eliminación, vinculación o deduplicación CoW, estas dos opciones no deben incluirse aleatoriamente para reducir el tiempo de análisis.

Todos los ejemplos siguientes de este artículo utilizan el proceso de confirmación completo predeterminado.

-B --dedupe: conservar archivos independientes y compartir bloques de datos

Los comandos básicos son los siguientes:

1
jdupes -r -B /srv/data

-B solicitará al sistema de archivos que realice una deduplicación de bajo nivel en archivos duplicados.

El manual oficial se refiere a este proceso como copia en escritura, CoW, clonación o deduplicación por reflink.

Desde el nivel del directorio, los nombres de los archivos originales todavía están ahí.

Desde el nivel de inodo, siguen siendo archivos separados.

Desde el nivel del bloque de datos, el mismo contenido puede hacer referencia al mismo conjunto de bloques físicos, reduciendo así el espacio real ocupado.

Estructura CoW después de la deduplicación

Supongamos que hay dos archivos idénticos:

1
2
/srv/data/a.iso -> inode 1001 -> 数据块 A、B、C
/srv/data/b.iso -> inode 2002 -> 数据块 A、B、C

Las dos rutas corresponden a diferentes inodos, pero la misma extensión comparte el bloque de datos subyacente.

Si parte de b.iso se modifica posteriormente, un sistema de archivos habilitado para CoW asignará nuevos bloques para las secciones modificadas:

1
2
/srv/data/a.iso -> inode 1001 -> 数据块 A、B、C
/srv/data/b.iso -> inode 2002 -> 数据块 A、X、C

Los segmentos no modificados permanecen compartidos, mientras que las escrituras se separan.

Ésta es la diferencia más crítica entre -B y los enlaces duros.

Por qué es adecuado para archivos que aún pueden modificarse

Cuando se utilizan enlaces duros, varias rutas son en realidad el mismo inodo.

El programa escribe contenido en el lugar a través de cualquier ruta y el contenido visto por otras rutas también cambiará.

Cuando se utiliza la deduplicación CoW, los archivos siguen siendo independientes.

Siempre que el sistema de archivos implemente CoW correctamente, modificar un archivo no cambiará otro archivo simultáneamente.

Por lo tanto, los siguientes escenarios son generalmente más adecuados para -B:

  • Múltiples imágenes de máquinas virtuales;
  • Directorios de respaldo para múltiples versiones;
  • Copias de fotografías o secuencias de vídeo;
  • Paquetes de instalación duplicados en repositorios de software;
  • Archivos con el mismo contenido pero diferentes ciclos de vida.

Requisitos del sistema de archivos para -B

-B No es jdupes el que recomprime o mueve el contenido del archivo.

Se basa en la misma interfaz de clonación o deduplicación de segmentos proporcionada por el sistema operativo y el sistema de archivos.

Los objetos de soporte enumerados en el manual oficial incluyen:

  • Btrfs;
  • XFS con función reflink habilitada;
  • APFS de Apple.

Su funcionamiento depende del kernel, el entorno de montaje, las funciones de compilación de jdupes y los parámetros de formato del sistema de archivos.

Para XFS, no basta con ver que el tipo de sistema de archivos sea XFS; la capacidad de reflink debe estar habilitada cuando se crea el sistema de archivos.

Puede verificar el tipo de sistema de archivos primero:

1
findmnt -T /srv/data

XFS puede ver más información del sistema de archivos:

1
xfs_info /srv/data

No asuma que se han publicado todos los datos duplicados sólo porque el comando no informa un error obvio.

Cómo verificar los resultados de la deduplicación de CoW

Primero asegúrese de que los archivos todavía tengan inodos diferentes:

1
2
3
stat -c '%n inode=%i size=%s blocks=%b' \
  /srv/data/a.iso \
  /srv/data/b.iso

Esto es de esperar si los dos inodos son diferentes.

Sin embargo, es posible que la cantidad de bloques mostrados por stat no exprese de manera directa y precisa la sección compartida.

Los diferentes sistemas de archivos pueden contar los bloques compartidos de manera diferente.

También puede comparar el espacio libre del sistema de archivos antes y después de la deduplicación:

1
df -h /srv/data

Para Btrfs, puede utilizar herramientas específicas del sistema de archivos para observar la asignación de espacio:

1
btrfs filesystem usage /srv/data

Las pruebas deben utilizar muestras descartables, modificar uno de los archivos y luego verificar que el hash del otro archivo no haya cambiado.

Limitaciones de -B

La deduplicación de CoW no equivale a “coste cero”.

Las secciones compartidas requieren que el sistema de archivos mantenga relaciones de referencia.

Las escrituras posteriores desencadenan nuevas asignaciones de bloques y pueden generar fragmentación adicional.

Para datos escritos aleatoriamente de alta frecuencia, archivos de bases de datos o discos virtuales que cambian continuamente, primero se debe evaluar el impacto de la amplificación y fragmentación de la escritura.

Las instantáneas también pueden hacer que las estadísticas espaciales sean más complejas.

Después de eliminar un archivo en un directorio, el bloque compartido no se libera inmediatamente si otro archivo o instantánea todavía hace referencia a él.

Si se centra en escenarios de Btrfs y NAS, puede continuar consultando la práctica de deduplicación de Btrfs + jdupes CoW en el sitio.

Los comandos básicos son los siguientes:

1
jdupes -r -L /srv/data

-L reemplaza las otras copias en cada conjunto de archivos duplicados con enlaces duros que apuntan al primer inodo del archivo.

Después del procesamiento, los múltiples nombres de ruta aún existen, pero ya no son archivos separados.

Estructura después del enlace duro

Antes del procesamiento:

1
2
/srv/data/a.bin -> inode 1001 -> 数据块 A、B、C
/srv/data/b.bin -> inode 2002 -> 数据块 A、B、C

Después del procesamiento:

1
2
3
/srv/data/a.bin --+
                 +-> inode 1001 -> 数据块 A、B、C
/srv/data/b.bin --+

En este momento, a.bin y b.bin son dos entradas de directorio del mismo inodo.

No son sólo “contenido compartido”, sino el mismo archivo con dos nombres.

¿Qué sucede cuando modificas cualquier enlace duro?

Si el programa abre directamente b.bin y sobrescribe los bytes que contiene, el contenido leído por a.bin también cambiará.

Porque ambos caminos finalmente acceden al mismo inodo.

Los metadatos de inodo, como permisos de archivos, propietarios y marcas de tiempo, ya no son independientes entre sí.

Pero hay una excepción confusa:

Algunos editores no modifican el archivo en su lugar, sino que crean un archivo temporal y luego reemplazan la ruta original con un cambio de nombre.

Este método de guardado de “escribir un nuevo archivo y luego reemplazar” hará que la ruta reemplazada obtenga un nuevo inodo, liberando así la relación de enlace duro.

Por lo tanto, no se puede inferir que todas las aplicaciones se comportarán igual basándose en una sola prueba de edición.

Los enlaces duros no pueden cruzar sistemas de archivos

Los enlaces duros solo se pueden crear dentro del mismo sistema de archivos.

Incluso si ambos puntos de montaje usan ext4, tienen diferentes dispositivos o instancias de sistema de archivos, no se pueden realizar enlaces duros a través del límite.

Puede utilizar el siguiente comando para ver el número de dispositivo y el inodo:

1
2
3
stat -c '%n device=%d inode=%i links=%h' \
  /srv/data/a.bin \
  /srv/data/b.bin

Después de un procesamiento exitoso, el número de dispositivo y el inodo deben ser los mismos para ambas rutas y el número de enlaces generalmente aumentará.

También disponible:

1
ls -li /srv/data/a.bin /srv/data/b.bin

Eliminar una ruta de enlace duro no elimina inmediatamente el contenido

Al eliminar b.bin simplemente se elimina una de las entradas del directorio.

Mientras a.bin siga apuntando a ese inodo, los datos del archivo seguirán existiendo.

El sistema de archivos recuperará los objetos y bloques de datos correspondientes solo cuando se elimine el último enlace duro y no continúe ningún proceso para abrir el archivo.

Esto es completamente diferente del enlace simbólico “dejar un enlace roto después de que desaparece la ruta de destino”.

Cuándo conviene utilizar -L

Los enlaces duros son adecuados para escenarios donde la premisa es clara:

  • Los archivos se encuentran en el mismo sistema de archivos;
  • De hecho, múltiples caminos pueden considerarse el mismo objeto en términos comerciales;
  • Se espera que el archivo sea de solo lectura o el contenido ya no se modificará;
  • El software de copia de seguridad, sincronización, indexación y gestión de derechos maneja los enlaces duros correctamente;
  • No hay necesidad de metadatos de inodo separados para cada ruta.

Los ejemplos típicos incluyen el almacenamiento en caché de paquetes de solo lectura, copias de archivos inmutables y repositorios de medios controlados.

Cuándo no conviene utilizar -L

Úselo con precaución o evítelo en las siguientes situaciones:

  • La aplicación puede modificar una copia in situ;
  • Los archivos pertenecen a diferentes usuarios o políticas de permisos;
  • El software de respaldo puede expandir los enlaces duros en múltiples copias de datos;
  • Es posible que el software de sincronización no preserve las relaciones de vínculo físico;
  • Las aplicaciones dependen de la unicidad del inodo para identificar archivos;
  • Los archivos abarcan múltiples sistemas de archivos o puntos de montaje de red.

Si dos rutas tienen el mismo contenido ahora pero diferentes responsabilidades en el futuro, tener el mismo contenido no significa que deban convertirse en el mismo inodo.

Los comandos básicos son los siguientes:

1
jdupes -r -l /srv/data

-l mantiene el primer archivo de cada grupo y reemplaza otros archivos duplicados con enlaces simbólicos relativos que apuntan a él.

Supongamos que antes del procesamiento hay:

1
2
/srv/data/original/report.pdf
/srv/data/archive/report-copy.pdf

Después del procesamiento, la segunda ruta puede comportarse como una relación similar:

1
/srv/data/archive/report-copy.pdf -> ../original/report.pdf

La ruta relativa real está determinada por la ubicación del directorio.

¿Qué significa un enlace simbólico relativo?

Los enlaces simbólicos contienen el texto de la ruta de destino, no el nombre adicional del inodo de destino.

El punto de partida para analizar enlaces relativos es el directorio donde se encuentra el enlace simbólico, no el directorio de trabajo actual cuando se ejecuta el comando.

Por lo tanto, al mover un árbol de directorios cuya estructura interna permanece sin cambios, los enlaces simbólicos relativos normalmente seguirán funcionando.

Sin embargo, mover sólo el enlace, o sólo el destino, puede invalidar la relación.

Diferencias de comportamiento entre enlaces simbólicos y enlaces duros

Los enlaces simbólicos pueden abarcar sistemas de archivos.

Los enlaces duros generalmente no pueden abarcar sistemas de archivos.

Los enlaces simbólicos tienen su propio tipo de archivo e inodo.

Un enlace duro es simplemente otro nombre para el mismo inodo de archivo normal.

Después de eliminar o cambiar el nombre del destino del vínculo suave, el vínculo puede romperse.

Cuando elimina el nombre de un enlace duro, el contenido permanece accesible siempre que haya otros enlaces duros.

Los enlaces simbólicos pueden apuntar a directorios; Las acciones de jdupes analizadas en este artículo tienen como objetivo colecciones de archivos duplicados.

Los enlaces simbólicos cambian los tipos de archivos

Antes de ejecutar -l, ambas rutas eran archivos normales.

Después de la ejecución, una de ellas sigue siendo un archivo normal y las otras rutas se convierten en enlaces simbólicos.

Esto afecta a algunas aplicaciones:

  • Las políticas de seguridad pueden negar el seguimiento de enlaces simbólicos;
  • Es posible que el contenedor o la zona de pruebas no vean el destino del enlace;
  • El servicio web podrá denegar el acceso a la ruta a la que apunta el enlace;
  • El software de copia de seguridad sólo puede realizar una copia de seguridad del enlace en sí;
  • Los programas de monitoreo de archivos pueden generar diferentes eventos para enlaces y destinos;
  • En última instancia, las comprobaciones de permisos recaen en la ruta de destino y su directorio principal.

Por lo tanto, “el archivo aún se puede abrir” no significa que se haya verificado la compatibilidad de la aplicación.

Cómo verificar enlaces simbólicos

Vea el texto de destino guardado por el enlace:

1
readlink /srv/data/archive/report-copy.pdf

Analiza el objetivo final:

1
realpath /srv/data/archive/report-copy.pdf

Compruebe si hay enlaces rotos en el árbol del directorio:

1
find /srv/data -xtype l -print

find -xtype l encontrará enlaces simbólicos que el objetivo final no puede resolver.

Antes del uso oficial, también se deben probar operaciones como mover archivos de destino, mover directorios de nivel superior, realizar copias de seguridad y recuperación y leer aplicaciones.

Cuándo conviene utilizar -l

Los enlaces simbólicos son adecuados para escenarios en los que “la relación de referencia es inherentemente razonable”:

  • Quiere especificar explícitamente una copia autorizada;
  • Otras rutas son inherentemente sólo rutas de entrada o de compatibilidad;
  • Requiere referencias entre sistemas de archivos;
  • Las aplicaciones admiten explícitamente enlaces simbólicos;
  • Capaz de garantizar el ciclo de vida de la ruta objetivo.

Los enlaces simbólicos generalmente no son ideales si el árbol de directorios se divide, sincroniza o empaqueta por separado con frecuencia.

-d --delete: seleccione elementos para conservar, elimine las copias restantes

Los comandos básicos son los siguientes:

1
jdupes -r -d /srv/data

-d solicita al usuario que seleccione qué rutas conservar para cada conjunto de archivos duplicados y luego elimina las rutas restantes.

Este es el más intuitivo de los cuatro métodos y el más irreversible.

-B, -L y -l conservarán la entrada de ruta original en una forma determinada.

-d en realidad elimina las entradas del directorio de archivos no reservados.

Eliminar contenido duplicado no significa que no haya pérdida de información

El hecho de que el contenido de los dos archivos sea exactamente el mismo no significa que las dos rutas no tengan valor.

Diferentes caminos pueden expresar cosas diferentes:

  • clasificación de directorios;
  • Semántica del nombre de archivo;
  • proyecto al que pertenece;
  • contexto de control de acceso;
  • Política de retención de copias de seguridad;
  • relaciones de indexación de aplicaciones;
  • Flujo de trabajo del usuario.

jdupes determina si el contenido del archivo está duplicado y no determinará qué entrada del directorio tiene relevancia operativa para usted.

Por lo tanto, es necesario revisar tanto el contenido como la ruta antes de eliminarlo.

Riesgo crítico 1: no especificar el mismo directorio más de una vez

No lo ejecutes así:

1
jdupes -d /srv/data /srv/data

También evite pasar el mismo árbol de directorios dos veces usando diferentes métodos de escritura, por ejemplo:

1
2
cd /srv
jdupes -d data /srv/data

La documentación oficial advierte: cuando se especifica el mismo directorio varias veces, el mismo archivo puede aparecer en la colección como un “duplicado de sí mismo”.

Si un usuario conserva un elemento de visualización en esta colección confusa pero elimina otro elemento de visualización que representa el mismo archivo real, se pueden perder datos.

Todas las rutas de entrada deben normalizarse antes de la ejecución y confirmarse que no tengan duplicados, alias o superposiciones inesperadas.

Puedes comprobar la ruta real primero:

1
2
realpath /srv/data
realpath ./data

También esté atento a los montajes de enlaces, los directorios de enlaces simbólicos y las asignaciones de contenedores para permitir que el mismo contenido sea recorrido desde múltiples entradas.

Riesgo crítico 2: combinar -d con -s

-s o --symlinks seguirán el directorio de enlaces simbólicos.

Cuando se usa junto con -d, la lista interactiva puede mostrar tanto la ruta relacionada con el enlace simbólico como el archivo real al que apunta.

El manual oficial establece que los usuarios pueden conservar por error un enlace simbólico pero eliminar el archivo al que apunta.

El resultado es que parece conservarse una ruta, pero en realidad sólo quedan enlaces que no pueden llegar al objetivo.

No utilice el siguiente comando salvo que haya identificado y verificado por completo las relaciones de enlaces simbólicos:

1
jdupes -r -s -d /srv/data

Un enfoque más seguro es no seguir primero los enlaces simbólicos, sino comprobar el directorio real y la estructura de enlaces por separado.

-N --no-prompt convertirá la eliminación en una operación automática

-N, cuando se utiliza con --delete, conserva automáticamente el primer archivo de cada grupo y elimina los archivos restantes.

Por ejemplo:

1
jdupes -r -d -N /srv/data

Esta no es una “confirmación de omisión” ordinaria, sino que convierte directamente “quién es el primer elemento” en una estrategia de retención.

Si realmente necesita automatización, primero debe comprender:

  • -o name ordena por nombre de archivo de forma predeterminada;
  • -o time se puede ordenar por hora de modificación;
  • -i invertirá la clasificación;
  • -O --param-order dará prioridad a preservar el impacto del orden de los parámetros de la línea de comando en el conjunto de resultados.

Antes de la eliminación automática, se debe realizar un análisis de solo lectura con la misma ruta, clasificación y opciones de recursividad y los resultados se deben guardar para su auditoría.

Para datos sin una copia de seguridad confiable, no se recomienda utilizar -d -N directamente.

Efecto de los cuatro modos sobre permisos y metadatos

De forma predeterminada, el objetivo principal de jdupes es detectar contenido duplicado.

Pero los archivos con el mismo contenido pueden tener diferentes propietarios, grupos o bits de permiso.

-p --permissions puede requerir que los archivos con diferentes propietarios, grupos y permisos no se traten como duplicados:

1
jdupes -r -p /srv/data

Esto es especialmente importante para -L.

Después de la vinculación física, varias rutas comparten metadatos de inodo y es imposible mantener sus diferentes propietarios y bits de permiso.

Para -d, la ruta que se elija conservar también determinará qué metadatos de archivo se dejarán finalmente.

Para -l, el acceso al contenido está controlado en última instancia mediante permisos de recorrido de ruta y archivo de destino.

Para -B, los inodos del archivo siguen siendo independientes, por lo que sus respectivos permisos y la mayoría de los metadatos pueden seguir existiendo de forma independiente.

Si también depende de ACL, atributos extendidos, etiquetas SELinux o capacidades de archivos, se debe realizar una verificación adicional utilizando las herramientas correspondientes.

La simple comparación de los bits de permisos tradicionales no significa que todos los metadatos extendidos se hayan incorporado a los juicios comerciales.

Elección entre varios sistemas de archivos

Al escanear varios puntos de montaje, puede unirse:

1
jdupes -r -1 /srv/data /mnt/archive

-1 --one-file-system impide la coincidencia entre sistemas de archivos o dispositivos.

Esto puede reducir la probabilidad de que acciones posteriores encuentren el límite de capacidades.

Las diferencias entre los cuatro modos en los sistemas de archivos son las siguientes:

  • -B se basa en la interfaz del sistema de archivos y las capacidades del segmento compartido, lo que generalmente requiere que el objetivo esté dentro del rango de compatibilidad;
  • -L No se puede crear un vínculo físico entre sistemas de archivos;
  • -l puede guardar referencias de ruta en todos los sistemas de archivos, pero el enlace no está disponible cuando falta el montaje de destino;
  • -d Puede eliminar copias en diferentes sistemas de archivos, pero debe confirmar que el almacenamiento donde se encuentran los elementos retenidos esté disponible a largo plazo.

Por ejemplo, eliminar la copia local y conservar sólo la copia en un disco duro extraíble o en un montaje de red temporal puede ser técnicamente exitoso, pero desde el punto de vista empresarial es muy peligroso.

Un procedimiento de ejecución seguro

No agregue opciones de acción directamente al directorio de producción.

Se recomienda ejecutar en el siguiente orden.

Paso 1: Confirme que la copia de seguridad o la instantánea sean recuperables

La existencia de una instantánea no significa que pueda restaurarse.

Confirma al menos:

  • La instantánea cubre todos los directorios escaneados esta vez;
  • El tiempo de creación de la instantánea es anterior a la operación de deduplicación;
  • Las instantáneas no comparten el mismo dominio de error que el directorio de producción;
  • Formas conocidas de recuperar archivos individuales y directorios completos;
  • Las operaciones de recuperación están sujetas a pruebas puntuales.

Los enlaces duros y los enlaces simbólicos también requieren confirmación de que la herramienta de copia de seguridad conserva la semántica del enlace.

Paso 2: Confirme que la ruta de entrada no se repita

Enumere cada directorio a escanear:

1
2
realpath /srv/data/project-a
realpath /srv/data/project-b

Compruebe si ellos:

  • Apunte al mismo directorio real;
  • Un directorio contiene completamente otro directorio;
  • Ingrese nuevamente al mismo árbol de directorios a través de un enlace simbólico;
  • Los alias aparecen mediante montaje vinculado o montaje en red;
  • Duplicado debido a la expansión del comodín del shell.

Especialmente cuando se utiliza -d, primero se debe eliminar cualquier superposición poco clara.

Paso 3: realizar primero un análisis de solo lectura

1
jdupes -r /srv/data/project-a /srv/data/project-b

Guarde el resultado en un archivo de auditoría:

1
2
jdupes -r /srv/data/project-a /srv/data/project-b \
  > /tmp/jdupes-review.txt

La opción de acción no se utiliza aquí, por lo que solo se genera el conjunto de coincidencias.

Verifique grupo por grupo qué rutas deben preservar la semántica independiente y cuáles son simplemente copias redundantes.

Paso 4: verificar el comportamiento en un directorio de prueba pequeño

Cree un directorio de prueba descartable:

1
2
3
4
test_dir="$(mktemp -d)"
mkdir -p "$test_dir/a" "$test_dir/b"
printf 'jdupes test data\n' > "$test_dir/a/sample.txt"
cp "$test_dir/a/sample.txt" "$test_dir/b/sample.txt"

Primero mire el inodo y el hash:

1
2
stat -c '%n inode=%i links=%h' "$test_dir"/*/sample.txt
sha256sum "$test_dir"/*/sample.txt

Entonces prueba sólo una acción a la vez.

Pruebe enlaces duros:

1
2
jdupes -L "$test_dir/a" "$test_dir/b"
stat -c '%n inode=%i links=%h' "$test_dir"/*/sample.txt

Para probar otras acciones, vuelva a crear una muestra limpia y no continúe superponiendo pruebas en archivos que ya están vinculados.

Paso 5: realice una acción a la vez

No apile cuatro modos de procesamiento en el mismo comando.

Divida lotes según las responsabilidades del directorio, por ejemplo:

1
jdupes -r -B /srv/data/mutable-archive
1
jdupes -r -L /srv/data/immutable-cache
1
jdupes -r -l /srv/data/compat-links
1
jdupes -r -d /srv/data/manual-review

Esto facilita la interpretación de los resultados, la verificación de los cambios y la recuperación.

Paso 6: verificar el resultado de la operación

Cualquiera que sea el método que elija, realice al menos estas comprobaciones:

1
jdupes -r /srv/data
1
find /srv/data -xtype l -print
1
df -h /srv/data

Luego agregue verificación según el modelo:

  • -B: Confirme que el inodo es independiente y que después de muestrear y modificar una copia, la otra permanece sin cambios;
  • -L: Confirme que los inodos sean los mismos y que el recuento de enlaces sea correcto;
  • -l: utilice readlink y realpath para confirmar el objetivo y comprobar si hay enlaces rotos;
  • -d: Confirme que la ruta reservada todavía existe según la lista de auditoría.

Finalmente, haga que la aplicación que realmente usa los archivos realice una prueba de lectura, índice, copia de seguridad o sincronización.

Elección según el caso de uso

Biblioteca multimedia y archivo fotográfico del NAS

Si la capa subyacente es Btrfs que admite la deduplicación y el archivo puede modificarse mediante un programa de administración de fotografías o de medios, evalúe primero -B.

Puede conservar la semántica de archivos independientes y reducir el riesgo de modificaciones vinculadas de enlaces duros.

-L también puede funcionar si el directorio es completamente de solo lectura y la aplicación maneja los enlaces duros correctamente.

Almacenamiento en caché de paquetes y artefactos de compilación

-L suele ser simple y eficiente cuando los artefactos de compilación inmutables están en el mismo sistema de archivos.

Sin embargo, se deben evitar los enlaces duros si la herramienta de compilación sobrescribe los archivos almacenados en caché en el lugar.

Para los cachés que se pueden regenerar en cualquier momento, también puede usar -d directamente, pero aún así debe asegurarse de que la eliminación no destruya el índice.

Directorios de copias de seguridad con varias versiones

Los catálogos de múltiples versiones requieren que cada versión mantenga una vista separada.

Cuando se admite CoW, -B generalmente se ajusta mejor a esta semántica que -L.

Los enlaces duros también se utilizan comúnmente para copias de seguridad incrementales, pero deben ser administrados sistemáticamente por el programa de copia de seguridad y no pueden reemplazarse temporalmente basándose en “el contenido actual es el mismo”.

Compatibilidad con rutas antiguas

Si es necesario acceder a un archivo autorizado desde varias rutas heredadas y el software admite enlaces simbólicos, puede elegir -l.

Esto equivale a decirle explícitamente al sistema que otras rutas son solo referencias.

La ruta de destino debe ser estable y estar cubierta por políticas de respaldo, contenedor y permisos.

Limpieza puntual de un directorio de descargas

Para confirmar que las copias duplicadas no tienen semántica de directorio y que hay copias de seguridad disponibles, utilice -d interactivo.

Escanee primero solo lectura y luego seleccione los elementos reservados grupo por grupo.

No salte directamente a -N solo para ahorrar algunas pulsaciones de teclas.

Errores frecuentes

Error 1: los cuatro modos ahorran exactamente el mismo espacio

incierto.

-d, -L y -l terminan con solo un archivo simple, pero aún con diferentes números y tipos de entradas de directorio u objetos de enlace.

Los ahorros reales de -B dependen de extensiones, tamaños de bloque, alineaciones, instantáneas y escrituras posteriores en el sistema de archivos que se compartan correctamente.

Error 2: un enlace duro es simplemente un enlace simbólico más fiable

Los dos tienen una semántica diferente y no pueden clasificarse simplemente por “confiabilidad”.

Los enlaces duros vinculan varios nombres al mismo inodo.

Los enlaces simbólicos contienen una ruta de destino que se puede resolver.

El primero no tiene el problema de “el enlace se rompe cuando se cambia el nombre de la ruta de destino”, mientras que el segundo puede cruzar sistemas de archivos y expresar claramente la relación de referencia.

Error 3: los archivos deduplicados mediante CoW se convierten en enlaces duros

No.

Los archivos después de la deduplicación CoW todavía tienen inodos independientes, pero comparten algunos o todos los bloques de datos.

Un enlace duro es el mismo archivo desde el nivel de inodo.

Esta diferencia se puede observar con ls -li o stat.

Error 4: si el contenido es idéntico, cualquiera de las copias puede borrarse con seguridad

El mismo contenido solo prueba que los bytes son iguales.

Las rutas, los nombres de los archivos, los permisos, las etiquetas, la propiedad empresarial y las políticas de copia de seguridad aún pueden diferir.

La selección de -d debe basarse en la semántica de la ruta, no solo en el contenido del archivo.

Error 5: los enlaces simbólicos relativos siempre son más portables

Los enlaces relativos sólo son portátiles si el enlace y el objetivo mantienen posiciones relativas.

Si copia solo uno de los subdirectorios, el enlace puede dejar de ser válido inmediatamente.

El empaquetado, la sincronización y el montaje del contenedor pueden cambiar la relación del directorio original.

Error 6: df debe mostrar más espacio libre inmediatamente después del borrado

incierto.

Es posible que el proceso aún abra el archivo o que se haga referencia a él mediante una instantánea, otro enlace duro o un recurso compartido de CoW.

La recuperación retrasada del sistema de archivos y los métodos de contabilidad de espacio también afectan los resultados observados.

Referencias

Recomendaciones finales

Si el sistema de archivos admite CoW y desea que el archivo pueda modificarse de forma independiente más adelante, -B --dedupe suele ser la opción menos intrusiva desde el punto de vista semántico de las cuatro opciones.

Si necesita explícitamente varias rutas al mismo archivo inmutable, todas en el mismo sistema de archivos, utilice -L --link-hard.

Si necesita establecer una relación de referencia de ruta clara y puede aceptar el riesgo de enlaces rotos después de que el objetivo se mueve, utilice -l --link-soft.

Si la ruta redundante en sí no tiene valor de conservación y ya existe un método de recuperación confiable, use -d --delete.

No importa cuál elijas, debes seguir los mismos principios:

Primero realice un escaneo de solo lectura, verifique la ruta, pruebe el comportamiento de la aplicación, luego ejecute la acción y finalmente verifique el sistema de archivos y los resultados operativos.

Nuevamente, para -d: no especifique el mismo directorio dos veces y no lo combine con -s o --symlinks sin verificar completamente la relación del enlace simbólico.

El espacio de almacenamiento guardado se puede recomprar, pero es posible que no se puedan reconstruir la semántica del directorio perdida y las copias únicas.