¿Cómo hace una copia de seguridad de un servidor de almacenamiento?

Estoy buscando implementar un servidor de almacenamiento muy grande para usarlo como NAS en vivo para varios otros servidores (todos basados ​​en Linux).

Por muy grande, quiero decir entre 4TB y 20TB de espacio utilizable (aunque es poco probable que lo hagamos en 20TB).

El servidor de almacenamiento será RAID 10 para la seguridad y el rendimiento de los datos, pero aún necesitaremos una solución de respaldo que incluya el respaldo fuera del sitio.

Mi pregunta es: ¿cómo hacer una copia de seguridad de esa cantidad de datos?

No es que solo pueda conectar un disco duro portátil y transferir los archivos. Actualmente no tenemos otros dispositivos con tanto espacio de almacenamiento.

¿Necesito presupuesto para un segundo servidor de almacenamiento externo o hay una solución mejor?

Hay muchas formas de manejar datos de ese tamaño. Mucho depende de su entorno y de cuánto dinero está dispuesto a gastar. En general, hay algunas estrategias generales para "quitar los datos del servidor":

• A través de Ethernet Como dice en la caja, los datos se transmiten a Some Where Else para su manejo. 20 TB tardarán mucho en copiar más de 1 GbE, pero se puede hacer. El hardware puede ayudar (como enlaces de 10 GbE o, en algunos casos, enlaces NIC).
• Sobre el subsistema de almacenamiento Si está en Fibre Channel, envíelo a otro dispositivo en la red FC. Si tiene SAS, envíelo a un dispositivo conectado a SAS. Generalmente más rápido que Ethernet.
• Envíelo a otra matriz de discos Envíelo a otro trozo de almacenamiento conectado al mismo servidor.

Esa es la vista de 100 km. Una vez que comienzas a hacer zoom, las cosas se fragmentan mucho más. Como ya se mencionó, LTO5 es una tecnología de cinta específica que está diseñada para este tipo de cargas de alta densidad. Otra matriz de almacenamiento idéntica es un buen objetivo, especialmente si puede usar algo como GlusterFS o DRBD para obtener los datos allí. Además, si necesita una rotación de respaldo o simplemente la capacidad de seguir ejecutándose en caso de que falle la matriz, esto afectará lo que haya colocado.

Una vez que se haya decidido por un método de visualización de 100Km, entrar en el software será la próxima gran tarea. Los factores que influyen en esto son lo que puede instalar en su servidor de almacenamiento en primer lugar (si es una NetApp, eso es una cosa, un servidor Linux con un montón de almacenamiento es otra cosa completamente diferente, como es un servidor de Windows con un montón de almacenamiento) , qué hardware elige (por ejemplo, no todos los paquetes de respaldo de FOSS manejan bien las bibliotecas de cintas) y qué tipo de retención de respaldo necesita.

Realmente necesita averiguar qué tipo de recuperación de desastres desea. La replicación en vivo simple es más fácil, pero no le permite restaurar desde la semana pasada solo ahora. Si la capacidad de restaurar desde la semana pasada es importante para usted, entonces necesita diseñar para ese tipo de cosas. Por ley (en los EE. UU. Y en otros lugares), algunos datos deben conservarse durante más de 7 años.

La replicación simple es la más fácil de hacer. Esto es lo que DRBD está diseñado para hacer. Una vez que se realiza la copia inicial, solo envía cambios. Los factores complicados aquí son la localidad de la red, si su segunda matriz no está cerca de la DRBD primaria puede no ser factible. Necesitará un segundo servidor de almacenamiento con al menos tanto espacio de almacenamiento como el primero.

Acerca de la copia de seguridad en cinta ...

LTO5 puede contener 1,5 TB de datos sin compresión. Alimentar a estos monstruos requiere una conexión en red muy rápida, que es Fibre Channel o 6Gb SAS. Dado que necesita hacer una copia de seguridad de más de 1.5TB en un golpe, debe buscar en los cargadores automáticos (aquí hay un ejemplo: enlace , un cargador automático de 24 unidades y 1 unidad de HP). Con el software que los admite, manejarán el cambio de cintas a mitad de la copia de seguridad por usted. Son grandiosos. Todavía tendrá que sacar las cintas para enviarlas fuera del sitio, pero es mucho mejor que quedarse toda la noche para cargar las cintas usted mismo cuando la copia de seguridad las requiera.

Si la cinta le da el heebiegeebies ' heredado, ew ', una Biblioteca de cintas virtuales puede ser más rápida (como esta de Quantum: enlace ). Estos pretenden ser bibliotecas de cintas para hacer una copia de seguridad del software mientras que en realidad almacenan cosas en el disco con técnicas robustas (esperas) de deduplicación. Los más elegantes incluso copiarán cintas virtuales en cintas reales para usted, si le gusta ese tipo de cosas, lo que puede ser muy útil para rotaciones fuera del sitio.

Si no quiere perder el tiempo incluso con cintas virtuales, pero aún desea hacer copias de seguridad directas en disco, necesitará una matriz de almacenamiento del tamaño suficiente para manejar esos 20 TB, además de la cantidad de datos de cambio de red que desee para mantener Los diferentes paquetes de respaldo manejan esto de manera diferente. Algunas tecnologías de desduplicación son realmente buenas, otras son hacky kludges. Personalmente, no conozco el estado de los paquetes de software de respaldo FOSS en esta área (he oído hablar de Bacula), pero pueden ser suficientes. Muchos paquetes de copias de seguridad comerciales tienen agentes locales que instala en servidores para realizar copias de seguridad con el fin de aumentar el rendimiento, que tiene muchos méritos.

LTO-5 jukebox? necesitaría en algún lugar entre tres y 15 cintas para respaldar esa matriz, que no es una cantidad locamente grande. El jukebox se encargará de cambiar las cintas por usted, y un buen software de copia de seguridad (p. Ej., Bacula) realizará un seguimiento de los archivos que hay en cada cinta.

También querrá considerar el tiempo requerido para hacer una copia de seguridad de un sistema de archivos tan grande, ya que es muy probable que el FS cambie durante ese período. Para obtener los mejores resultados, un sistema de archivos que admita instantáneas sería muy útil, por lo que puede tomar una instantánea y realizar copias de seguridad completas o incrementales en lugar de hacerlo en el sistema de archivos en vivo.

Probablemente debería considerar hacer una copia de seguridad en el disco , ya que la cinta llevará mucho tiempo y, al ser un acceso secuencial, las restauraciones tomarán una eternidad.

Definitivamente aproveche las copias de seguridad diferenciales o incrementales , solo copias de seguridad de los cambios, en cualquier frecuencia que tenga sentido para usted.

Probablemente la solución ideal sería tener un segundo servidor de tamaño similar en otra ubicación , donde se envían copias de seguridad incrementales regularmente, y eso podría cambiarse rápidamente si el servidor principal alguna vez muere. Sin embargo, otra opción sería usar unidades extraíbles en el lugar, que luego se sacan fuera del sitio para su almacenamiento.

Cuando se trata con esa cantidad de datos, también tiene sentido dividir sus copias de seguridad en trabajos de copia de seguridad más pequeños, y si no se pueden hacer copias de seguridad todos los días, escalone sus copias de seguridad para que la copia de seguridad A se realice un día, y establecer B el siguiente.

Siempre piense en el procedimiento de restauración . Nos picaron una vez cuando tuvimos que restaurar un archivo de un trabajo de copia de seguridad de varios cientos de conciertos, lo que tomó mucha memoria y mucho tiempo para reconstruir el índice de copia de seguridad y restaurarlo. Al final, no pudimos completarlo en un día, ¡y tuvimos que construir un servidor de restauración dedicado para permitir que nuestro servidor de respaldo principal continúe con sus trabajos nocturnos!

--adicional--

También debe estar pensando en las tecnologías de deduplicación , que pueden ahorrar grandes cantidades de espacio al no realizar copias de seguridad de la misma información varias veces, para múltiples usuarios. Muchas soluciones de respaldo o sistemas de archivos ofrecen deduplicación como parte de su funcionalidad.

Primero, enumere los riesgos contra los que está protegiendo. Algunos riesgos comunes:

• Desastre: Algo muy desafortunado le sucede a todo su sitio.
• Errores humanos (este es el que ocurre _todos_la_hora_):
  • Alguien decide ejercer la capacidad de "intercambio en caliente" de su servidor de almacenamiento de una manera no prevista por el fabricante.
  • Alguien ejecuta un proceso que corrompe silenciosamente los datos, que se respaldan de manera confiable durante un par de meses antes de que se note el problema.
  • Alguien elimina el importante informe que se debe entregar en una hora y que vale miles de dólares.

Luego evalúe el costo de las diversas soluciones para evitar riesgos, por ejemplo:

• Copia de seguridad en línea, fuera del sitio (espejo remoto): a salvo de desastres, algunos (pero no todos) errores humanos (todavía está en línea).
• Almacenamiento fuera de línea (cintas): a salvo de desastres, difícil de recuperar datos rápidamente.
• Copia de seguridad en línea en el sitio (espejo): a salvo de algún error humano, alguna falla de hardware, vulnerable a desastres.
• Copia de seguridad fuera de línea en el sitio (cintas en cambiador de cinta): a salvo de la mayoría de los errores humanos, la mayoría de las fallas de hardware.

Luego evalúe las estrategias de rotación (cuánto tiempo atrás desea poder recuperar, cuántos datos puede permitirse perder).

Luego, elija lo que valen sus datos.

Tengo un cliente con dos sistemas similares de 12 TB en dos edificios diferentes, conectados a 1 GB. Uno es el sistema de producción; se realiza una copia de seguridad incremental (con instantáneas diarias) a la otra con la gran utilidad rdiff-backup . rdiff-backup debe estar disponible en su repositorio de distribución estándar.

Copia de seguridad en línea, fuera del sitio (espejo remoto)

use rsync a través de ssh (solo cambios): la primera copia de seguridad debe realizarse localmente, pero después de esa copia de seguridad será muy fácil dependiendo de los cambios

si necesita mantener versiones con cambios rdiff-backup

http://www.nongnu.org/rdiff-backup/

El sistema de archivos btrfs en Linux suena prometedor, pero aún en desarrollo pesado

Eche un vistazo a su "contenido" real y con qué frecuencia cambia antes de planificar su estrategia. Muchas veces la gente simplemente graba los mismos datos una y otra vez semanalmente sin ninguna buena razón.

Las tecnologías de deduplicación de algunos proveedores pueden permitir que las instantáneas lo salven de las restauraciones de archivos individuales, pero siempre necesitará protección externa.