Servidor de almacenamiento de respaldo con ZFS

Soy todo hombre de TI en una pequeña empresa. Quiero diseñar una nueva infraestructura que incluya un nuevo servidor y un servidor de respaldo separado con una política de respaldo de toda la compañía.

Lo más importante en la empresa es el SQL Server y sus bases de datos. Hay 10 bases de datos, pero solo 2 de ellas son realmente importantes. El primero de 8GB, principalmente datos de texto y números. El segundo, de unos 300 GB con un crecimiento de 16 GB / mes, contiene archivos PDF y GIF.

Para guardar el almacenamiento, la política de copia de seguridad actual consiste en una copia de seguridad completa por semana y 6 diferenciales. Creo que son unos 350 GB por semana, 1,4 TB por mes.

Después de leer los artículos sobre corrupción silenciosa de datos, decidí probar ZFS con la edición Nexenta Community.

Mi pregunta: ¿ZFS con deduplicación es bueno para almacenar archivos de respaldo en términos de confiabilidad o debería pensar en alguna copia de respaldo en cinta u otra cosa?

EDITAR: Sé que en este momento no podemos predecir el rendimiento, la relación de deduplicación, etc., pero quiero saber si es una buena idea.

Ciertamente, ZFS es lo suficientemente estable como para hacer este tipo de cosas, hay muchas plataformas de producción muy grandes de alto perfil y confiables basadas completamente en ZFS y Nexenta.

Dicho esto, siempre me gusta tener copias de seguridad basadas en disco en el sitio, como la que está sugiriendo, y copias de seguridad en disco extraíble o en cinta que salen fuera del sitio diariamente para proteger contra incendios / terremotos / Cthulhu, etc.

Entonces mi respuesta es sí, está bien, pero elegiría ambas opciones si puedes.

(suponiendo que se refiera al uso de deduplicación dentro de ZFS frente a su software de copia de seguridad)

Yo no recomendaría el uso de ZFS nativo deduplicación para su sistema de seguridad a menos que el diseño de su sistema de almacenamiento específicamente para él.

Usar deduplicación en ZFS es extremadamente intensivo en RAM. Dado que la deduplicación ocurre en tiempo real a medida que los datos se transmiten / escriben en el grupo de almacenamiento, hay una tabla mantenida en la memoria que realiza un seguimiento de los bloques de datos. Esta es la tabla DDT . Si su servidor de almacenamiento ZFS no tiene suficiente RAM para acomodar esta tabla, el rendimiento sufrirá enormemente. Nexenta te avisará cuando la mesa crezca más allá de cierto umbral, pero para entonces, ya es demasiado tarde. Esto se puede aumentar mediante el uso de un dispositivo L2ARC (caché de lectura), pero muchos de los primeros usuarios de ZFS cayeron en esta trampa.

Ver:

ZFS: la destrucción del conjunto de datos o zvol deduplicado detiene el servidor. ¿Cómo recuperarse?

ZFS: impacto de la falla del dispositivo de caché L2ARC (Nexenta)

Cuando digo que el requisito de RAM es alto para usar deduplicación, estimaría las necesidades de RAM y L2ARC para el conjunto de datos que está describiendo en 64GB + RAM y 200GB + L2ARC. Esa no es una inversión menor. Mantener muchos archivos del sistema de Windows y documentos de imagen que no se volverán a leer llenará ese DDT muy rápidamente. Es posible que la recompensa no valga la pena el trabajo de ingeniería que debe realizarse por adelantado.

Una mejor idea es usar la compresión en el zpool, posiblemente aprovechando las capacidades de gzip para los tipos de datos más comprimibles. La deduplicación no valdrá la pena, ya que hay un golpe cuando necesita eliminar datos deduplicados (debe hacer referencia al DDT).

Además, ¿cómo presentará el almacenamiento a su software de respaldo? ¿Qué paquete de software de respaldo usarás? En entornos Windows, presento ZFS como almacenamiento en bloque para Backup Exec sobre iSCSI. Nunca encontré que las características de ZFS CIFS fueran lo suficientemente robustas y preferí las ventajas de un dispositivo con formato nativo.

Además, aquí hay un excelente recurso ZFS para ideas de diseño. Cosas sobre ZFS que nadie te dijo

Un sistema operativo alternativo es OpenIndiana, que es igual de bueno y recibe actualizaciones más frecuentes algunas veces.

Otra opción es configurar un segundo servidor ZFS con un grupo de almacenamiento más pequeño (potencialmente) con compresión habilitada. Puede usar este segundo dispositivo para copias de seguridad estáticas. Por lo tanto, puede prescindir de la memoria caché de lectura y tampoco necesita cantidades tontas de CPU / RAM para manejarlo.

Ejecutamos una configuración como esta donde trabajo:

• Servidor de almacenamiento principal OpenIndiana [ principal ] con seis discos de 2TB en un grupo RaidZ1 de tres conjuntos de pares duplicados. Esto, al tiempo que reduce su espacio de almacenamiento disponible, lo convierte en un grupo de almacenamiento rápido y con redundancia múltiple.
• Un servidor de almacenamiento secundario [ copia de seguridad ] también ejecuta OpenIndiana con una configuración similar de discos que sirve únicamente como dispositivo de copia de seguridad.
• main tiene un script que se ejecuta desde un trabajo cron que captura instantáneas / tank / [conjunto de datos] regularmente durante el transcurso del día
• Todas las tardes, se ejecuta otro trabajo cron que empuja las instantáneas del día a través de la red para hacer una copia de seguridad . Una vez que se realiza la sincronización inicial de todas sus instantáneas (un procedimiento de una sola vez), la naturaleza incremental de las instantáneas significa que los cambios se envían a su dispositivo de respaldo muy rápidamente.

Tengo un resumen rápido sobre cómo configurar ZFS enviar / recibir aquí: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/