Ejecuto un sitio web donde se almacenan alrededor de 10 millones de archivos (portadas de libros) en 3 niveles de subdirectorios, que van desde [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Esto lleva a alrededor de 2400 archivos por directorio, lo cual es muy rápido cuando necesitamos recuperar un archivo. Además, esta es una práctica sugerida por muchas preguntas .

Sin embargo, cuando necesito hacer una copia de seguridad de estos archivos, me toma muchos días solo navegar por los directorios 4k que contienen archivos de 10m.

Entonces, me pregunto si podría almacenar estos archivos en un contenedor (o en contenedores 4k), que actuarían exactamente como un sistema de archivos (¿algún tipo de contenedor ext3 / 4 montado?). Supongo que esto sería casi tan eficiente como acceder directamente a un archivo en el sistema de archivos, y esto tendría la gran ventaja de ser copiado a otro servidor de manera muy eficiente.

¿Alguna sugerencia sobre cómo hacer esto mejor? ¿O alguna alternativa viable (noSQL, ...)?

Opciones para acceder rápidamente y realizar copias de seguridad de millones de archivos

Pedir prestado a personas con problemas similares

Esto se parece mucho a un tipo de problema más fácil que enfrentan los servidores de noticias USENET y los servidores proxy de almacenamiento en caché: cientos de millones de archivos pequeños a los que se accede aleatoriamente. Es posible que desee tomar una pista de ellos (excepto que normalmente no tienen que hacer copias de seguridad).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Obviamente, la naturaleza cíclica del sistema de archivos de noticias cíclicas es irrelevante para usted, pero el concepto de nivel inferior de tener múltiples archivos / dispositivos de disco con imágenes empaquetadas y un índice rápido de la información que proporciona el usuario para buscar la información de ubicación es muy apropiado.

Sistemas de archivos dedicados

Por supuesto, estos son conceptos similares a los que hablaban las personas al crear un sistema de archivos en un archivo y montarlo sobre un bucle invertido, excepto que puede escribir su propio código del sistema de archivos. Por supuesto, dado que usted dijo que su sistema era principalmente de lectura, en realidad podría dedicar una partición de disco (o partición lvm para flexibilidad en el dimensionamiento) para este único propósito. Cuando desee realizar una copia de seguridad, monte el sistema de archivos de solo lectura y luego haga una copia de los bits de partición.

LVM

Mencioné LVM arriba como útil para permitir el tamaño dinámico de una partición para que no necesite hacer una copia de seguridad de mucho espacio vacío. Pero, por supuesto, LVM tiene otras características que podrían ser muy aplicables. Específicamente, la funcionalidad de "instantánea" que le permite congelar un sistema de archivos en un momento dado. Cualquier accidente rm -rfo lo que sea no perturbaría la instantánea. Dependiendo exactamente de lo que intente hacer, eso podría ser suficiente para sus necesidades de copias de seguridad.

RAID-1

Estoy seguro de que ya está familiarizado con RAID y probablemente ya lo use para la confiabilidad, pero RAID-1 también se puede usar para copias de seguridad, al menos si está usando RAID de software (puede usarlo con RAID de hardware, pero eso en realidad le brinda una confiabilidad menor porque puede requerir el mismo modelo / controlador de revisión para leer). El concepto es que cree un grupo RAID-1 con un disco más del que realmente necesita conectado para sus necesidades normales de confiabilidad (por ejemplo, un tercer disco si usa el software RAID-1 con dos discos, o tal vez un disco grande y un hardware) RAID5 con discos más pequeños con un software RAID-1 en la parte superior del hardware RAID-5). Cuando llegue el momento de hacer una copia de seguridad, instale un disco, solicite a mdadm que agregue ese disco al grupo de incursiones, espere hasta que indique que está completo, opcionalmente solicite un exfoliante de verificación y luego retire el disco. Por supuesto,

Puede montar un sistema de archivos virtual utilizando el administrador de bucle invertido, pero si bien esto aceleraría su proceso de copia de seguridad, podría afectar las operaciones normales.

Otra alternativa es hacer una copia de seguridad de todo el dispositivo usando dd. Por ejemplo, dd if=/dev/my_device of=/path/to/backup.dd.

Como probablemente sepa, su problema es la localidad. Una búsqueda de disco típica tarda unos 10 ms. Entonces, simplemente llamar a "stat" (o open ()) en 10 millones de archivos colocados al azar requiere 10 millones de búsquedas, o alrededor de 100000 segundos, o 30 horas.

Por lo tanto, debe colocar sus archivos en contenedores más grandes, de modo que el número relevante sea el ancho de banda de su unidad (50-100 MB / seg para un solo disco, generalmente) en lugar de su tiempo de búsqueda. También para que pueda lanzar un RAID, lo que le permite aumentar el ancho de banda (pero no reducir el tiempo de búsqueda).

Probablemente no le estoy diciendo nada que no sepa, pero mi punto es que su idea de "contenedor" definitivamente resolverá el problema, y ​​casi cualquier contenedor funcionará. Las monturas de bucle invertido probablemente funcionarán tan bien como cualquier otra cosa.

Hay un par de opciones. Lo más simple, y debería funcionar con todos los sistemas de archivos de Linux, es ddcopiar toda la partición ( /dev/sdb3o /dev/mapper/Data-ImageVol) en una sola imagen y archivar esa imagen. En caso de restaurar archivos singulares, loopback monta la imagen ( mount -o loop /usr/path/to/file /mountpoint) y copia los archivos que necesitas. Para una restauración de partición completa, puede invertir la dirección del ddcomando inicial , pero realmente necesita una partición de tamaño idéntico.

A juzgar por su caso de uso, supongo que las restauraciones de archivos individuales son un evento muy poco frecuente, si es que alguna vez ocurren. Es por eso que una copia de seguridad basada en imágenes realmente tiene sentido aquí. Si necesita realizar restauraciones individuales con más frecuencia, será mucho más conveniente utilizar instantáneas LVM por etapas; pero aún necesita hacer una copia de seguridad basada en imágenes para esos desastres críticos de "perdimos todo" Las restauraciones basadas en imágenes tienden a ir mucho más rápido que las restauraciones basadas en alquitrán simplemente porque solo está restaurando bloques, no está incurriendo en una gran cantidad de operaciones de metadatos con cada fopen / fclose, y también puede ser una operación de disco altamente secuencial para aumenta más la velocidad.

Alternativamente, como el video de Google @casey mencionó a la mitad, XFS es un gran sistema de archivos (si es complejo). Una de las mejores utilidades con XFS es la xfsdumputilidad, que volcará un sistema de archivos completo en un solo archivo, y generalmente lo hace más rápido de lo que tarpuede. Es una utilidad específica del sistema de archivos, por lo que puede aprovechar las funciones internas de fs de una manera que tar no puede.

Te sugiero que primero intentes actualizar a EXT4, si aún no lo estás ejecutando.

Google ha investigado mucho por qué EXT4 es una buena idea .

Después de eso, debe considerar la implementación de una arquitectura de sistema de archivos distribuido. Por ejemplo:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

Tal vez una respuesta simplista, pero mi primer pensamiento fue usar algo como GridFS que se basa en MongoDB . Muchos de los controladores de idioma principal lo admiten de inmediato, por lo que debería poder cambiarlo con las secciones de lectura de archivos de su código. Además, puede hacer que sus rutas de directorio existentes sean las claves de estos archivos.

Un problema que puede tener es que Mongo tiende a disminuir bastante rápido si está buscando desde el disco todo el tiempo. Con 10 millones de archivos, espero que la mayoría de sus datos estén en el disco. Los fragmentos de archivos en GridFS son de 4 MB, según recuerdo, por lo que si sus archivos son más grandes que eso, realizará varias operaciones costosas para obtener un archivo. Creo que la clave sería fragmentar sus archivos en función de su estructura de directorio ya ordenada para que pueda tener varias instancias de Mongo ejecutándose en varios cuadros para aligerar la carga. Sin embargo, tampoco sé cuáles son sus requisitos de rendimiento, por lo que podría estar pensando demasiado.

¿Cuál es el beneficio de todo esto? Rendimiento que coincide bastante bien con las lecturas de disco si se hace correctamente. Además, Mongo viene con varias excelentes formas integradas para hacer una copia de seguridad de toda la franja de datos en una instancia de base de datos rápidamente, e incluso con la base de datos aún en ejecución.

Si está satisfecho con un modelo de dispositivo para el almacenamiento de datos, tal vez podría considerar NexentaStor . Ejecuta ZFS en OpenSolaris bajo el capó, pero toda la administración es a través de una GUI web.

Hay un par de características que ayudarían con su problema.

• La versión Enterprise admite una forma de replicación remota basada en instantáneas que no requiere escaneo a través de todo el sistema de archivos.

• Si no le importa ensuciarse las manos, ZFS tiene un comando de diferencia ZFS muy útil que le indica de manera eficiente qué archivos se han agregado, modificado o eliminado desde la última instantánea, sin necesidad de escanear todo el sistema de archivos. Puede incorporar esto en su sistema de respaldo para reducir en gran medida el tiempo requerido para realizar respaldos incrementales.

Puede usar una dumputilidad estándar para hacer una copia de seguridad del sistema de archivos EXT4 con muchos archivos. Esta utilidad primero verifica qué bloques se usan en un sistema de archivos y luego los respalda en orden de disco, eliminando la mayoría de las búsquedas.

Hay una restoreutilidad correspondiente para restaurar las copias de seguridad creadas por dump.

Admite copias de seguridad incrementales utilizando niveles: archivos de copias de seguridad de nivel 1 modificados desde la última copia de seguridad de nivel 0 (completa), nivel 2: modificados desde la copia de seguridad de nivel 1, etc.

Para las copias de seguridad incrementales, una opción sería tener un segundo árbol en la sombra para las nuevas cubiertas. Es decir, tendría su árbol principal que se utiliza para todas las operaciones de lectura. También tendrías un newfiles/012345.....jpgdirectorio; Las carátulas recientemente agregadas crean un enlace duro aquí, así como en el árbol principal. Al realizar copias de seguridad, puede hacer una copia de seguridad del árbol principal ocasionalmente, pero haga una copia de seguridad del árbol (mucho más pequeño) con newfilesmucha más frecuencia.

Tenga en cuenta que para mantener el newfilesárbol pequeño, antes de realizar una nueva copia de seguridad del árbol principal, puede vaciar el árbol de archivos nuevos:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Una vez que haga esto, por supuesto, se compromete a producir una nueva copia de seguridad del árbol principal.

Agregar un poco de concurrencia generalmente ayuda.

Tengo un problema similar al tuyo; en mi caso, tengo que hacer una copia de seguridad de alrededor de 30 millones de archivos, la mayoría de ellos archivos HTML, PHP o JPEG. Para mí, BackupPC + rsync sobre ssh funciona bastante bien; la copia de seguridad completa demora alrededor de un día, pero los incrementales generalmente terminarán en un par de horas.

El truco consiste en agregar cada directorio de nivel principal (0, 1, 2 ... a, b, c ...) como un nuevo objetivo para copiar en BackupPC y dejar que realice la copia de seguridad en paralelo, de modo que haga una copia de seguridad de los directorios simultáneamente a / , b / , c / * y así sucesivamente. Dependiendo de su subsistema de disco, cualquier cosa entre dos procesos y alrededor de 10 procesos es probablemente la forma más rápida de realizar una copia de seguridad.

Las instantáneas LVM y la copia de seguridad a nivel de bloque también son una opción, pero con BackuPC y la copia de seguridad a nivel de archivo aún puede restaurar archivos o directorios individuales si es necesario.

Benjamín,

¡Creo que su problema puede abordarse en la cantidad de archivos por nivel de directorio!

¿El tiempo de acceso cambia en un factor significativo si almacena 20 000 archivos en un directorio?

¿También pensó en almacenar los metadatos del sistema de archivos en una unidad de acceso más rápida por separado? (Como un SSD).

En su lugar, recomendaría una buena base de datos relacional.

Usaría un PostgreSQL con, digamos, 256 tablas particionadas (cover_00, cover_01, ..., cover_ff) con datos de imagen como byteacolumna (binaria) con almacenamiento externo, con identificador de archivo como clave principal. La recuperación de una imagen sería rápida (gracias a un índice en la clave primaria), la integridad de los datos estaría garantizada (base de datos compatible con ACID), la copia de seguridad estaría en el orden del disco, por lo que no se buscaría demasiado.