¿Cómo reflejar sistemas de archivos con millones de enlaces duros?

Tenemos un gran problema en este momento: necesitamos reflejar un sistema de archivos para uno de nuestros clientes. Eso no suele ser realmente un problema, pero aquí está:

En este sistema de archivos hay una carpeta con millones de enlaces duros (¡sí! ¡MILLONES!). rsyncrequiere más de 4 días para crear la lista de archivos.

Utilizamos las siguientes rsyncopciones:

rsync -Havz --progress serverA:/data/cms /data/

¿Alguien tiene una idea de cómo acelerar este rsync o usar alternativas? No podríamos usarlo ddya que el disco de destino es más pequeño que la fuente.

ACTUALIZACIÓN: Como el sistema de archivos original ext3lo intentaremos dumpy restore. Te mantendré al día

— Thomas Berger
fuente

Difícil. Encoge el sistema de archivos fuente primero, luego dd?

— Bittrance

Respuestas:

Debe actualizar ambos lados a rsync 3. Desde el registro de cambios:

- A new incremental-recursion algorithm is now used when rsync is talking
  to another 3.x version.  This starts the transfer going more quickly
  (before all the files have been found), and requires much less memory.
  See the --recursive option in the manpage for some restrictions.

Han pasado más de 2 años desde que se lanzó rsync 3.0.0, pero, desafortunadamente, la mayoría de las distribuciones empresariales se basan en códigos anteriores a eso, lo que significa que probablemente esté usando rsync 2.6.

Como referencia (si alguien más tiene este problema), si ya está ejecutando rsync 3, entonces está utilizando opciones que son incompatibles con la recursividad incremental. Desde la página del manual:

    Some options require rsync to know the full file list, so  these
    options  disable the incremental recursion mode.  These include:
    --delete-before,   --delete-after,    --prune-empty-dirs,    and
    --delay-updates.

Además, nuevamente, ambos lados deben estar ejecutando rsync 3 para que la recursividad incremental sea compatible.

— Steven Pritchard
fuente

Pritchard, gracias por ese trasero, pero las partes incrementales no son un problema, ambos lados usan rsync> 3.0. Si usamos rsync sin -H, tenemos una gran mejora de velocidad, pero eso no es lo que necesitamos.

— Thomas Berger

Ay. Sí, en ese caso, es posible que desee buscar opciones para acelerar el acceso al sistema de archivos (como cambiar a ext4 si está usando ext3), cambiar a discos más rápidos o niveles RAID (si eso es incluso una opción), etc. Desafortunadamente, usted podría estar en un punto donde el sistema de archivos simplemente no puede ser lo suficientemente rápido y las copias de seguridad a nivel de bloque pueden ser su única opción. Tuve este problema al intentar sincronizar un grupo de BackupPC de un servidor a otro.

— Steven Pritchard

Hemos usado ext * dump ahora. Funciona bien, y el lado de restauración ni siquiera tiene que ser ext *.

Hemos realizado una copia de seguridad fuera de línea, desmontando el dispositivo y utilizado dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Aquí las últimas líneas que pudo ver tamaño, tiempo, velocidad y los últimos números de inodo:

DUMP: dumping regular inode 47169535
DUMP: dumping regular inode 47169536
DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011
DUMP: Volume 1 54393520 blocks (53118.67MB)
DUMP: Volume 1 took 4:16:43
DUMP: Volume 1 transfer rate: 3531 kB/s
DUMP: 54393520 blocks (53118.67MB)
DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec
DUMP: Date of this level  dump: Wed Jun 29 01:24:29 2011
DUMP: Date this dump completed:  Wed Jun 29 05:42:57 2011
DUMP: Average transfer rate: 3531 kB/s
DUMP: DUMP IS DONE

— Thomas Berger
fuente

No sé si esto sigue siendo cierto, pero el volcado solía tener algunos problemas si el sistema de archivos está en uso en el momento del volcado. Dado que su objetivo es la velocidad supongo que ya se haya desactivado todos los demás el acceso a la misma, pero sólo en caso .. Háganos saber cómo vas

— Superbob

Puede usar LVM y tomar instantáneas del volumen, luego sincronizar la instantánea como respaldo.

Alternativamente, puede combinar esto con la otra respuesta y usarlo dump en el volumen de la instantánea , para evitar tener que desconectar el volumen original.

— Osito de peluche
fuente

Cualquier cosa que funcione a nivel de bloque, no a nivel de sistema de archivos, probablemente sería una gran mejora.

— Marcin

Como puede ver en mi pregunta, tengo que duplicar a través de la red, no local. Además, LVM NO es un espejo, es solo, como dijiste, una instantánea.

— Thomas Berger

@Thomas Berger: Pensé que luego copiarías la instantánea (usando rsync) a través de la red. ¿Y cómo define exactamente espejo , si una instantánea LVM no es una?

— Teddy

Eso todavía tiene el mismo problema: tomaría días. En estos días habría un gran dalta (no es que lo necesitemos), por lo que tenemos que reservar suficiente espacio y no tenemos ese espacio. Y un espejo es una copia independiente de la fuente. Tenemos que copiar los datos desde la producción hasta el desarrollo para el cliente.

— Thomas Berger

@Thomas Berger: Originalmente quise decir que sincronizarías el volumen real de la instantánea, no el sistema de archivos de la instantánea. Sin embargo, ahora creo que la solución de instantánea + volcado es mejor.

— Teddy