Repositorios Inmutables, tema abierto

Hola @HunterLAFR ! Seguimos las instrucciones de Veeam de no implementar Linux Hardened Repository en una máquina virtual. Algunas implementaciones fueron así y aconsejamos los customers a la adquisición de hardware dedicado para el LHR. Como es la forma más económica, he visto muchas implementaciones aquí en Brasil.

A continuación se muestra una vista del laboratorio que uso, donde se implementa LHR en una máquina virtual. En VBR Security & Compliance Analyzer, se muestra un mensaje advirtiendo que esta no es una buena práctica de seguridad.

Otra opción que estamos desarrollando es el uso de Object Storage inmutable, específicamente Object First. Esta es una solución que proporciona ventajas sobre LHR, como soporte del fabricante, escalabilidad, facilidad de uso/mantenimiento y costo atractivo. Sólo he visto lo uso de dispositivos de deduplicación en entornos/environments más grandes.

:-)

leduardoserrano wrote:

Hola @HunterLAFR ! Seguimos las instrucciones de Veeam de no implementar Linux Hardened Repository en una máquina virtual. Algunas implementaciones fueron así y aconsejamos los customers a la adquisición de hardware dedicado para el LHR. Como es la forma más económica, he visto muchas implementaciones aquí en Brasil.

A continuación se muestra una vista del laboratorio que uso, donde se implementa VHR en una máquina virtual. En VBR Security & Compliance Analyzer, se muestra un mensaje advirtiendo que esta no es una buena práctica de seguridad.

Otra opción que estamos desarrollando es el uso de Object Storage inmutable, específicamente Object First. Esta es una solución que proporciona ventajas sobre LHR, como soporte del fabricante, escalabilidad, facilidad de uso/mantenimiento y costo atractivo. Sólo he visto lo uso de dispositivos de deduplicación en entornos/environments más grandes.

:-)

 

Muchas gracias @leduardoserrano  por tus comentarios e información.

Yo he visto desplegados appliances virtuales “Inmutables” como Quantum Dxiv, HPE StoreOnce, etc, pero Virtual Appliances, y tener que deirles la cruda verdad que no es una buena practica.

En el caso de una VM con linux, y un volumen físico conectado a ella, lo he empleado en laboratorio, con buen resultado, pero como dices, y está demostrado, lo mejor es hardware dedicado.

Ootbi de Object First es una muy buena solucion, eso es, ofrece soporte software, hardwar ey mantenimeinto, siendo ademas certificado para uso con Veeam.

A ver si alguien más nos comparte sus impresiones y experiencias.

un saludo.

Ciertamente @HunterLAFR ! Acabamos de recibir un dispositivo Ootbi (Object First) para nuestro laboratorio. Realizaré la instalación, configuración y compartiré las impresiones con todos. Ya hemos realizado pruebas de concepto y el rendimiento obtenido fue muy bueno: alcanzamos los 1 GB/s per appliance prometidos en la hoja de datos. 😁

leduardoserrano wrote:

Ciertamente @HunterLAFR ! Acabamos de recibir un dispositivo Ootbi (Object First) para nuestro laboratorio. Realizaré la instalación, configuración y compartiré las impresiones con todos. Ya hemos realizado pruebas de concepto y el rendimiento obtenido fue muy bueno: alcanzamos los 1 GB/s per appliance prometidos en la hoja de datos. 😁

 

🤙

Fantástico!

Hola.

Mi opinión. Primero, lo que yo veo en mis clientes, que en general son de cierta entidad y siguen criterios estrictos. El motivo más evidente para poner un repositorio en un entorno virtual es el ahorro de costes, pero no conviene jugar con fuego.

Poner el backup, inmutable o no, de un entorno virtual en entorno virtual se ve nomalmente como mala idea. Si encima es el mismo entorno virtualizado mucho peor; como bien dices, la infraestructura vitrtual (sea un entorno o mas de uno) puede ser comprometida (y lo he visto en primera persona). El backup inmutable de un entorno virtual normalmente va a un dispositivo físico idealmente separado por aire.

Como alternativa, me gusta la idea de que el volumen sea servido directo desde una cabina SAN o un iSCSI, pero no lo he visto nunca, para ser sincero. Normalmente veo que las cabinas dan la capacidad a datastores y no directamente a VMs... el coste del TB de cabina SAN o NAS/iSCSI no suele ser bajo; y si fuera un iSCSI desde un servidor barato, ¿porque no poner directamente ese servidor como repositorio y mejorar mucho la seguridad?

Un repositorio virtualizado de backup puede que sí tenga más sentido si el origen de los datos es otro, y así conseguir buena economía; el ejemplo mas claro que veo a menudo es el ser destino de backup para Office365: una VM o un cluster de VMs on premise recibiendo backup de los datos que residen en la nube. Ese es la única circunstancia en que veo Artesca en VM como repositorio de backup. 

Cuando hablamos de copias secundarias o terceras copias, había mas tolerancia/aceptación hasta hace relativamente poco hacia los entornos virtualizados. Pero al final el tema de la inmutabilidad es que se usa como protección frente a ransomware y la mentalidad se ha hecho más conservadora. Ya no se trata de usar el backup porque alguien torpe ha borrado unas carpetas, ahora es una defensa para una entidad que ha efectuado un ataque específicamente dirigido a hacer el mayor daño posible y a cerrar las puertas a la recuperación desde backup. Lo de la separación de backups sobre distintos medios, tecnología y todo eso ahora se toma más en serio. 

Luego lo que opino está bastante alineado con lo que veo:

Yo tengo el privilegio de poder aconsejar a mis clientes con libertad, dado que propongo es Artesca de Scality y es un software que funciona indistintamente sobre entorno físico o virtual, por lo que no tengo interés económico en una opción sobre la otra; pero el aislamiento que proporciona un entorno físico dedicado aporta un nivel de seguridad incomparable, para mí es la primera opción. Solamente si está justificado aconsejo repositorio en un entorno virtual, como excepción a la norma. 

También debo decir que los costes que puede representar por poner un ejemplo, un appliance de backup frente a un servidor estandar x86 son incomparables. La popularidad de soluciones basadas en Linux era precisamente su economía, pero tiene sus contrapartidas; convertir el mismo servidor con linux en un repositorio objeto permite quedarte con lo mejor de las dos cosas: gasto contenido, funcionaliades y seguridad (dejando aparte la posibilidad de escalar y otras ventajas...)

Un saludo!

Hola,

Nosotros ahora mismo tenemos un repositorio inmutable basado en un servidor físico con linux y bastionado según las recomendaciones de Veeam. El almacenamiento se lo proporcionamos con cabinas antiguas conectadas por FC, no compartidas con otros servicios. Ahora nos estamos planteando montar un repo inmutable scale out basado en CPHE con servidores de bajo coste llenos de discos grandes, apilados e ir extendiendo el cluster de CEPH a medida que se nos llene. Conseguimos un coste controlado y fácil de estimar, y al mismo tiempo lo tenemos todo on prem, que en caso de una catástrofe, lo que nos falta es depender de la disponibilidad de ancho de banda, latencias y demás para bajarnos varios TB de datos de una nube. Por otra parte, sigo creyendo que lo que dicen del Air Gap es una gran idea así que cada semana se vuelcan los últimos backups a cinta y se guardan en una caja de seguridad en otra ubicación. Más inmutable que eso no hay nada. Evidentemente todo tiene sus riesgos como que te pidan un backup de hace 10 años y n tengas dispositivo para leerlo, o que la cinta se dañe…. en fin, que en este negocio hay que ponerse los pantalones con cinturón y tirantes y aún así, alguna vez se te va a ver…...el calzoncillo

Un saludo

Es un ejemplo interesante @javichumellamo, muy funcional y yo diría que muy cabal. La idea de plantear un CEPH supongo que viene tras encontrar limitaciones en el servidor actual linux, que no podrá crecer mas y preferís pasar a algo mas versátil.

A priori es una estrategia de coste efectivo, sobre todo por reaprovechar recursos ya existentes, pero hay que contar también la carga de trabajo para los administradores: montar (y luego mantener, actualizar...) un repositorio CEPH requieren una cantidad de conocimiento y tiempo que tiene su equivalencia en dinero. Es el precio de dar un salto en funcionalidad y seguridad importante. 

Lo de las cintas y el haber tirado justo antes de necesitarlo el lector compatible es un clásico :) 

lo de la cinta me hace gracia…

me ha pasado, como a muchos, el tener guardado un servidor y un robot en un almacen,

y en el momento de necesitarlo, el servidor no arranca, el robot no funciona, las cintas están degradadas… era todo un reto.

Al final, el tiempo que empleabamos en ir migrando la info a cintas nuevas, modernas, o de mayor capacidad, se evaluó en llevar los backups de larga retención a una tecnología nueva, con un ciclo de vida mejor, y nosotros solamente consumir los repositorios, sin tener que preocuparnos de más cosas.

Siempre hay que “sacrificar” algo, y siempre se le puede buscar la “vuelta”
en este caso, los repositorios se conectaban antes de la tarea de backup, y se desconectaban al finalizar, 

quedando accesible solamente en la ventana de tiempo de las tareas.

un saludo.

Hola Luis,

esa es la razón de que pensemos en la opción CEPH, archivado de larga retención sin límites….aunque dé trabajo operarlo y mantenerlo, y que existan otras opciones más….. ‘operativas’.