Presentación del Webinar de Object First: Mejorando la Seguridad de Veeam Backup & Recovery
Josep Ros – 0:07
Bienvenidos. Soy Josep Ros, CEO de Encora. Os doy la bienvenida al Webinar sobre Object First. Estamos muy felices de que estéis aquí y de hablar de la solución Object First.
Hoy discutiremos cómo la solución Object First es una herramienta esencial para la gestión de datos en las empresas modernas y por qué es importante para la seguridad de las copias de seguridad.
Object First ofrece no solo una solución de almacenamiento, sino también una forma de asegurar que la información está siempre disponible y segura. Esto es crucial para todas las empresas que utilizan Veeam Backup & Replication.
La integración de Object First con Veeam Backup & Replication es fundamental para lograr una estrategia de backup robusta y efectiva, especialmente en entornos donde la seguridad de los datos es una prioridad.
Appliance de backup inmutable para Veeam Backup & Replication
Vamos a hablar de un complemento maravilloso para Veeam Backup & Replication. Es importante que todos los clientes de Encora comprendan cómo mejorar la fiabilidad de nuestras copias de seguridad. La Unión Europea exige cada vez más que se cumplan estándares como ISO27001 y NIS2, especialmente en sectores como la banca y seguros el tema de DORA, donde la protección del entorno de Veeam Backup & Replication es crucial para evitar accesos no autorizados.
En este webinar, profundizaremos en cómo Object First puede ayudar a mejorar la seguridad y fiabilidad de Veeam Backup & Replication.
0:53
Van a acompañarnos hoy: Rubén Cuesta que es nuestro responsable de preventa, Miquel Mariano, que es nuestro responsable de infraestructuras y de Object First tenemos la suerte hoy de tener a Miguel Tena, gracias, Miguel, por participar. Es un gran experto del producto. Nos va a contar cómo funciona. Es un hardware que complementa el software, que es Veeam Backup & Replication. Gracias a todos. Gracias al equipo de Object First por todo su apoyo y adelante, vamos a empezar ya. Rubén Cuesta adelante, por favor.
Object First es la solución que garantiza la inmutabilidad de los datos y la protección contra amenazas externas. Esto resulta en una mayor tranquilidad para las empresas, asegurando que la información esté siempre disponible y segura.
Además, la facilidad de uso de Object First permite a los equipos de TI implementar y gestionar la solución sin complicaciones, liberando recursos para otras tareas críticas.
Rubén Cuesta. 1:24
Bueno nada. Muchas gracias, Josep. Bienvenidos a todos. Una suerte poder contar con vosotros en una jornada como hoy, va a ser la primera de varias sesiones que vamos a hacer con este fabricante Object First. Como decía Josep, es un complemento perfecto, ideal para Veeam Backup & Replication. De hecho es un hardware, un Apliance inmutable de backup que solo funciona con Veeam Backup & Replication. Si hay clientes que tienen otras soluciones de backup, pues no aplica.
1:50
Como hay una base enorme de clientes en todo el mundo y también en España, pues creemos que va a ser una punta de lanza para poder mejorar la seguridad de los sistemas de información y la protección de los backups de nuestros clientes. Por eso queríamos que conocierais el producto y los modelos que tiene.
Queríamos que conocierais el producto Object First debido a su impacto en la seguridad de los backups. Object First es clave para la protección de nuestras copias de seguridad.
Object First ofrece un enfoque innovador y efectivo para garantizar que los backups sean inmutables y seguros.
Y yo creo que nada más. Vamos, le voy a dar paso a Miguel, que es preventa de Object First y nos va a contar un poco, pues las bondades de los productos de Object First, de estos apliance hardware y un poco. ¿Cuál es la motivación? ¿Por qué surge? ¿de dónde surge? ¿Quiénes han creado esta empresa? Así que nada, Miguel todo tuyo.
Object Fist: ootbi presentación del producto.
Miquel Tena 2:46
Muchas gracias, Rubén. Gracias. Gracias, Josep, Miquel, gracias a ti también por compartir esta charla conmigo.
La solución Object First permite una integración fluida con Veeam Backup & Replication, proporcionando copias de seguridad fiables y seguras.
La experiencia de utilizar Object First es excepcional, y su integración con Veeam Backup & Replication permite un flujo de trabajo continuo en la gestión de backups y recuperación de datos.
Una de las características más destacadas de Object First es su enfoque en la inmutabilidad de los datos, asegurando que las copias de seguridad no pueden ser alteradas o eliminadas.
Os voy a explicar hoy lo que lo que comentaba Rubén sobre nuestra solución. La solución de Object First. Os compartiré pantalla. Dividimos la sesión en dos partes que las podéis interrumpir en el momento que queráis, por favor, hacerme preguntas cuando consideréis y si preferís hacerlo al final, si preferís hacerlo durante la presentación encantado de recibirlas y contestar.
Entonces, la idea de hoy es hacer esta presentación, posicionar el producto, explicaros los orígenes, las funcionalidades, el porfolio de la solución, y poder mostraros también en una pequeña demo. Por decir lo poco que cuesta instalar la solución y lo fácil que es de integrar con Veeam Backup & Replication. Y luego toda la operativa cuando tenemos el producto desplegado y desarrollado para, aprovechar las funcionalidades avanzadas de Veeam que ya estáis utilizando en vuestros entornos.
3:49
Cuando se utiliza junto con Veeam Backup & Replication, Object First proporciona la tranquilidad de que todos los datos críticos están protegidos y siempre accesibles.
Con Object First, las empresas pueden estar seguras de que sus datos están protegidos y disponibles. Además, incluso en caso de un ataque cibernético o un fallo del sistema, la inmutabilidad de los datos garantiza su seguridad.
La solución Object First está diseñada para integrarse de manera fluida con Veeam Backup & Replication, optimizando así el proceso de respaldo y recuperación de datos en tiempo real.
Que mejor compañía y plataforma que hacer este webinar con vosotros con los compañeros de Encora y que gracias, antes que nada, por la posibilidad, que no lo he dicho.
Con Object First, las empresas pueden confiar en que sus datos están protegidos contra ataques maliciosos y siempre disponibles para su recuperación.
Object First: Los retos del storage para backup en la actualidad.
La experiencia de usar Object First es fluida, facilitando la integración con Veeam Backup & Replication y maximizando la eficiencia operativa.
Object First es crucial para mantener la integridad y disponibilidad de los datos en entornos críticos.
Object First ha sido desarrollado por los creadores de Veeam Backup & Replication, asegurando una calidad excepcional y una sólida experiencia en el sector.
En conclusión, Object First es fundamental para mantener la integridad y disponibilidad de los datos en entornos críticos.
Ootbi es un appliance de backup inmutable específicamente diseñado para integrarse con Veeam Backup & Replication, garantizando una seguridad robusta para las copias de seguridad.
Ootbi
4:04
La idea de hoy: presentaros Object First ¿de acuerdo? En Object First, tenemos un producto que se llama Ootbi que es el acrónimo de out of the box immutability. Es un appliance hardware, un appliance de backup inmutable específicamente diseñado para trabajar e integrarse con Veeam Backup & Replication.
No existe la posibilidad de desplegarlo en una appliance virtual. Esto es parte de la seguridad de nuestro producto, que sea un sistema auto contenido o una caja cerrada y está específicamente diseñado para integrarse con Veeam Backup & Replication,
NIS2
Con Object First, la inmutabilidad de los datos está garantizada, lo que representa una gran ventaja frente a otros sistemas de backup, esto nos permite ayudar a garantizar la NIS2 en nuestra empresa.
De los fundadores de Veeam Backup & Replication
Sobre esto veremos el porqué, cuál es el motivo y el principal motivo son los orígenes de la solución. ¿Quiénes son los fundadores de Object First? Pues los fundadores de Object First, no sé si estos nombres os suenan: Ratmir Timashev y Andrei Baronov son las personas que fundaron Veeam, una empresa que era nueva.
Empezaba como nueva a día de hoy. Tiene una base instalada increíble. Está desplegada en un gran número de empresas. Vosotros lo sabéis. Veeam se fundó en el 2006, por Ratmir y Andrei que lo hicieron, en 2020 la empresa Veeam fue vendida un fondo de inversión americano.
5:27
Y a partir de ese momento, Ratmir y Andrei, que son personas con motivaciones y con preocupación, por lo que serían los entornos de backup porque han estado vinculados gran parte de su vida a ello, pues, durante su etapa en Veeam, se dieron cuenta de que Veeam es un producto que funciona a nivel global en las empresas.
Que no únicamente funciona con entornos de visualización como al inicio, sino que fue añadiendo cargas de trabajo, integraciones con diferentes entornos, pero siempre ha sido una solución agnóstica en lo que se refería a los repositorios de Backup. Esto, lo sabéis, es una solución que permite almacenar backups en diferentes tipos de tecnologías.
La arquitectura de Object First permite una segmentación eficiente del software y hardware, asegurando que el acceso no autorizado sea prácticamente imposible y refuerza la seguridad de las copias de seguridad.
Appliance de backup Inmutable
¿Cuál fue su idea? Pues vamos a llevar a cabo… Pues lo que podría hacer una empresa en la que definamos y diseñamos una solución, una solución que sea el mejor almacenamiento para guardar de forma segura las copias de Veeam, que esta solución sea a prueba de ransomware y que sea inmutable aut-of-the-box.
Que el cliente, que el integrador no tenga que no requiera de un conocimiento avanzado para desplegar, integrar lo que sería la solución y que esté basado en los principios de Zero Trust Data Resilence: Resilencia de datos de confianza cero.
Estas eran las principales premisas que Ratmir y Andrei se plantearon a la hora de fundar la compañía.
Por si no os suenan, estos principios de decir otras data Resilient están basados en los principios genéricos del zero trust en los que sabemos que, pues estos principios lo que dicen es que en algún momento vamos a tener que asumir incumplimiento ya no es únicamente necesario poner medidas de seguridad perimetrales.
Object First. Principios del Zero Trust Data Resilience. (ZTDR)
Sino que en nuestro entorno también tenemos que poner el mayor número de medidas que hagan una segmentación de ese entorno para minimizar la superficie de ataque y el radio de exposición, cuando tenemos una amenaza. Vamos a verificar explícitamente cualquier tipo de interacción con nuestro entorno.
07:14
Vamos a utilizar servicios de multifactor de autenticación. Servicios de gestión de identidades y accesos. Y también vamos a interactuar con este entorno de la manera más segura posible. ¿Cómo? Dotando a los servicios, aplicaciones, dispositivos que tengan que interactuar con el entorno de accesos con privilegios mínimos. Para que cada usuario o dispositivo hay una aplicación únicamente que pueda hacer aquello que debe hacer y nada más. Ningún privilegio adicional.
Estos principios del zero trust se alinean con los con los entornos de backup y restauración de datos a través del principio de Zero Trust Data Resilence (ZTDR). ¿Cómo lo aplicamos nosotros o cómo la aplica Object First a su solución. Haciendo una segmentación del software de backup y el almacenamiento de backup como comentábamos nosotros somos un repositorio de backups de Veeam.
El segmentar, aunque tengamos una integración muy estrecha con Veeam, lo trataremos más adelante, no hay ningún componente de Veeam, ningún agente, ningún data mover, instalado dentro del appliance. Por tanto, un compromiso de lo que sería el software de backup no va a implicar en ningún momento que los datos o que el sistema Ootbi se vea comprometido o perjudicado por esta segmentación 100% de las capas.
8:28
Seguimos las buenas prácticas de Veeam con las múltiples zonas de resilencia, esto es: 3:2:1:1:0:
- 3 copias de los datos
- 2 tipos de medios distintos
- 1 de las copias off side
- El 1 adicional de la copia inmutable o archive, en este caso inmutable.
- Y el cero adicional de todas las funcionalidades añadidas de que Veeam ofrece para garantizar que los backups no están infectados, no están comprometidos y que la hora de restaurar lo que restauremos va a hacer un dato que no esté comprometido y que no nos va a perjudicar al resto del entorno.
Lo que comentaba el uno adicional que también añadimos es esta inmutabilidad. Nosotros en el primer nivel de backup, porque nos posicionamos como un primer repositorio de backup, un primary tier de los backups, porque no únicamente somos una solución que ofrece seguridad, sino que ofrece un alto rendimiento por la integración que tenemos con Veeam, pues garantizamos la inmutabilidad en este primer nivel de backup.
Si queremos un segundo nivel de backup en Ootbi pues también perfectamente compatible y garantizando esta inmutabilidad.
Object First. Resiliencia de datos de confianza cero (ZTDR)
9:38
¿Cómo veríamos esto en un entorno, cliente aterrizado a lo que sería una plataforma IT de un cliente?
Pues como veis, decíamos que por los principios de zero trust, vamos a tener que asumir incumplimiento. Vemos que tenemos un entorno productivo, heterogéneo, servicios físicos, virtuales, cargas de trabajo en la nube… Todas aquellas cargas de trabajo en este caso que Veeam Backup & Replication, de las cuales, puede hacer backup.
La plataforma software, como comentábamos, es Veeam Backup & Replication, pues todos sus diferentes elementos, el Veeam Backup & Replication Server, todA la parte de proxys y el resto de los servidores necesarios para priorizar la operativa y en los repositorios de backup.
En este caso, un primer nivel de backup en ootbi, en un data center primario y un segundo nivel de backup para cumplir con este primer 1 de las copias offsite que puede ser un Ootbi. Puede ser un Ootbi instalado en un proveedor de servicios en el data center de un proveedor de servicios o puede ser cualquier servicio de nube pública de almacenamiento de objetos, por ejemplo, AWS, Azure o el propio servicio de Veeam Data Cloud como ejemplo.
Object First. Los clientes de Veeam necesitan almacenamiento seguro, simple y potente.
10:47
Como vemos las superficies de ataque, pues en el entorno productivo son muy extensas, muchos protocolos de acceso, muchos usuarios y muchos agentes interactuando con este entorno. Lo mismo en lo que se refiere al software de backup, muchos protocolos de comunicación.
¿Que es lo que hacemos nosotros? nos comunicamos con Veeam a través de la API S3. Con esto lo que hacemos es disminuir al máximo lo que sería la superficie de ataque.
Por tanto, añadimos este nivel de seguridad y de integración, porque al final nos integramos a nivel de API, y garantizamos que no haya diversos caminos para acceder al sistema, sino que únicamente a través de API S3.
Reducimos al máximo la superficie de ataque, tanto en el primer nivel de backup. Como con el segundo nivel de backup, si también añadimos Ootbi s lo que sería el entorno y a esta segunda copia.
11:41
¿Lo que nos encontramos a día de hoy en las plataformas que tenemos instaladas?. Pues que a lo largo del tiempo hemos ido utilizando sistemas, muchas veces sistemas reaprovechados. Sistemas que a veces no son del nivel Enterprise que el resto del entorno tiene.
Al final estamos, definiendo arquitecturas productivas con servidores muy potentes con procesadores Intel muy potentes. Con sistemas de almacenamiento productivos también muy potentes con discos SSD, con discos NMVe con discos con conectividad a 10, 25 G.
Y, al final, en el entorno de backup, estamos destinando una pequeña NAS con cuatro discos de 20 TB a 5.200 rpm sin garantías de lo que sería, pues, el rendimiento de la solución, la escalabilidad de la solución y la seguridad de la solución.
Por tanto, los entornos actuales, ya sea una cabina productiva, aprovechada o, para un entorno de backup, pues no acostumbran a ser los seguros, potentes y simples que debería ser una solución que almacene los backups.
Opciones de almacenamiento local para cliente de Veeam Backup & Replication
Object First. Opciones de almacenamiento local para cliente de Veeam.
En el ecosistema actual, las soluciones que nos encontramos a día de hoy, pues, por poner tres ejemplos:
- Estaríamos hablando de sistemas Direct Data Storage: un pool de discos atachado directamente a lo que sería el servidor de Veeam Backup & Replication. Una cabina NAS conectada a la red y presentada a través de algún protocolo de ficheros para conectarlo a lo que sería el servidor de Veeam.
- Apliances de duplicación que son una buena solución también, pero tienen un propósito bastante concreto. Ahora veremos cuál es y
- Hardener Linux repository que también es una solución que en ciertas ocasiones garantiza lo que sería la inmutabilidad. Pero que requiere de conocimiento.
13:28
Por destacar algunos puntos o un concepto en común entre todos estos elementos: Ninguno de ellos está hardenizado por defecto. Ninguno de ellos es seguro out off the box y ninguno de ellos está específicamente diseñado para integrarse con Veeam.
Por tanto, estas soluciones tienen sus puntos fuertes y sus puntos débiles, pero hay algo común: ni específicamente diseñados para trabajar con Veeam, ni inmutables por defecto. Este out of the box, de sacar de la caja y que el sistema sea inmutable es únicamente en la parte que ootbi. No lo cumplirían estos sistemas.
Entrando en detalle en las soluciones DAS. El punto débil aquí sería la seguridad. Esta inmutabilidad que en muchos casos no podemos garantizar. En algunos casos se pueden habilitar ciertos servicios de inmutabilidad, pero siempre teniendo un acceso root, siempre tienen un acceso a la raíz vamos a poder deshabilitar y borrar los datos que existen en el sistema. Son sistemas simples y potentes, pero la seguridad aquí sería el punto débil.
Las empresas que implementan Object First junto con Veeam Backup & Replication están mejor preparadas para enfrentar los desafíos del entorno digital actual, ya que aseguran la integridad y disponibilidad de los datos.
En conclusión, Object First y Veeam son aliados clave para cualquier empresa que busque una solución de respaldo sólida y confiable.
Appliances de deduplicación para Veeam Backup & Replication
En lo que se refiere a los appliances de deduplicación, pues en la seguridad también se puede habilitar y deshabilitar en mayor medida. Siempre hay que hardenizar, hay que trabajar para inmutabilizar estos sistemas. Muchas veces a través de línea de comandos y añadiendo licencias adicionales a lo que sería la solución.
La simplicidad, pues no es simple porque requiere conocimientos de los protocolos propietarios, algunos fabricantes, pues disponen de algunos protocolos propietarios para hacer estas integraciones y estos servicios de inmutabilidad y el punto débil, lo que vemos un poco más débil en estas soluciones sería la potencia, el rendimiento.
15:08
¿Qué pasa cuando tenemos que, almacenar backups en el sistema? Pues que hay un preproceso de deduplicación que hace el sistema para optimizar el espacio ocupado. ¿Qué pasa cuando tenemos que restaurar los datos? Que hay un proceso de rehidratación que también, pues requiere de tiempo en muchas ocasiones.
En conclusión, Object First y Veeam Backup & Replication son aliados clave para cualquier empresa que busque una solución de respaldo sólida y confiable.
Cuando necesitamos restaurar datos, incluso necesitamos no únicamente restaurar un fichero o una máquina virtual o un disco de una máquina virtual en concreto, sino que lo que queremos es restaurar la máquina virtual completa o levantar la máquina virtual completa desde el propio repositorio de backup. Esto desde un appliance de duplicación. Se puede dilatar hasta horas, en vez de minutos o segundos, que es lo que debería ser.
Además, con Object First, la operativa de backup se vuelve más eficiente y menos susceptible a amenazas externas.
Por tanto, el rendimiento, pues es un poco limitado, si bien deduplication appliance es una solución muy adecuada para backups de largo retención para un segundo nivel de backup, cuando tenemos que cumplir con ciertas normativas o la empresa nos requiere, pues, almacenar backups de larga retención, años, etc.
Con la implementación de Object First, las empresas pueden confiar en que sus datos están protegidos contra ataques maliciosos.
Es evidente que la colaboración entre Object First y Veeam Backup & Replication representa una ventaja competitiva en la gestión de datos y la seguridad de la información.
Object First es crucial para mantener la integridad y disponibilidad de los datos en entornos críticos.
La experiencia de usar Object First es fluida, facilitando la integración con Veeam Backup & Replication y maximizando la eficiencia operativa.
Hardener Linux Repository para Veeam
16:22
En cuanto a hardener Linux repository pues también es una solución que últimamente, pues se está implantando bastante. Veeam Backup & Replication. También está trabajando en simplificar lo que sería la implantación del servicio, pero siempre va a acabar siendo una solución DYI (do yourself) con un soporte limitado.
Con un hardware por detrás pues que debe cumplir ciertos requerimientos tanto a nivel del RAID de los discos, de las controladoras, de los procesadores de lo que sería el sistema y sobre todo, va a requerir un mantenimiento y un tiempo de aplicar esa hardenización y mantener actualizada esa hardenización si no, estamos perdidos.
Al final acaba siendo un sistema que tampoco es sencillo. Requiere conocimientos de administración de Linux. Por tanto, la simplicidad tenemos aquí una X y la potencia pues claro, si el servidor es muy potente, la solución va a ser potente.
Object First: ootbi es el mejor almacenamiento para Veeam
17:13
En resumen, Object First no solo complementa Veeam Backup & Replication, sino que es un componente esencial para las empresas que buscan seguridad y fiabilidad.
Como avanzábamos inicialmente Veeam Backup & Replication siempre es el software de backup. Posicionamos Ootbi como un primer nivel de backup, porque no únicamente garantizamos la inmutabilidad y la seguridad de los datos, sino que garantizamos que los backup se realizan muy rápidamente y la restauración también es muy rápida.
En resumen, Object First no solo complementa Veeam Backup & Replication, sino que es un componente esencial para las empresas que buscan seguridad y fiabilidad.
Luego vemos unas cifras que son a día de unas cifras de powerpoint, pero están basadas en las implantaciones que tenemos desplegadas de Ootbi. Por tanto Ootbi es un primer nivel de backup para almacenar esos backups.
Inicialmente de corta retención, esos backups que vamos a utilizar para restaurar los datos más actualizados en el tiempo. Podemos siempre añadir un segundo nivel de backup. Como comentábamos puede ser Ootbi o puede ser cualquier otro servicio que soporte Veeam.
En este caso y en esta aquí veis las flechitas, siempre siempre es Veeam Backup & Replication quien hace la orquestación. Siempre es Veeam Backup & Replication quien hace la copia y el uploading de datos a través de la configuración de Scale & Backup Repository a través de la configuración de backup copy jobs.
18:18
Ootbi no hace replicación hardware a nivel S3. Nosotros no hacemos esta replicación de los datos simplemente porque para seguir el proceso de soporte de Veeam Backup & Replication, queremos que Veeam Backup & Replication siempre sea consciente de todas las copias que hay en nuestro entorno, tanto a las primarias como las secundarias. Por tanto, delegamos en Veeam toda la operativa de copia y de los datos.
Como comentábamos un segundo nivel de backup, podemos tener Ootbi o podemos tener un servicio en nube. Si hacemos backup copy jobs, podemos tener un appliance de duplicación. Podemos hacer un dispositivo de cintas para tener esta larga retención y las copias offline, o sea, cualquier tipo de repositorio que Veeam soporte.
Ootbi: seguro, simple y potente.
19:08
Como comentábamos también: nuestros pilares fundacionales, la seguridad, la simplicidad y la potencia. Haré un pequeño resumen aquí porque tenemos unas slides donde entraremos en detalle.
Seguro: Lista para usar out of the box. Este es el principal mensaje. Sacamos de la caja, arrancamos, conectamos a la alimentación, conectamos los puertos de red del puesto de gestión y el sistema es inmutable por defecto, luego vemos cómo. Acceso cero acciones destructivas. Esto tiene que ver con el que no tenemos un acceso al root.
No existe un acceso al root. Esto es muy importante y muy diferencial respecto a otras soluciones. En 15 minutos tenemos la solución desplegada, no requiere de experiencia de adicional en administración de un nuevo sistema.
Simple. Si conocemos Veeam Backup & Replication, tenemos el 90 y cinco por ciento del trabajo hecho, porque en OOTBI únicamente vamos a tener que configurar un par de direcciones IP, un par de nombres, integrar con Veeam Backup & Replication, par de alta el repositorio: add new repo en la consola en la consola de Veeam. Y a partir de ahí, todo el trabajo es débil crear un bucket, crear unas claves S3. Veréis que es super sencillo y muy similar a otras soluciones de almacenamiento de objetos.
20:14
Potente. ¿En que nos basamos? En nuestro rendimiento. La ingesta de datos puede llegar en un clúster de hasta cuatro nodos. Hago referencia ahora y la haré más adelante.
Somos una solución Scale-out. Nuestra solución está basada en appliances cerrados. No se pueden añadir discos en el appliance, no se pueden cambiar los discos de appliance o añadir bandejas, sino que nuestra solución escala añadiendo nodos al cluster.
El clúster más grande puede ser a día de hoy de cuatro de cuatro nodos, obviamente podemos crecer más. Veremos cómo. Pero con un clúster de cuatro nodos en este caso, con los cuatro nodos más grandes de nuestro portfolio, llegaríamos hasta 8 Gbps en escrituras en el sistema y sobre todo, muy importante, certificados para usar Instant Veeam Recovery.
Al final por nodo, podemos levantar hasta 20 sesiones concurrentes de Instant Recovery y levantar hasta 20 máquinas virtuales de forma instantánea desde lo que sería nuestro appliance inmutable.
Ootbi es seguro
21:08
En cuanto a la seguridad de Ootbi. Lo primero aquí: inmutabilidad S3 out of the box. Otra vez, volvemos out of the box para almacenamiento de objetos S3, y al utilizar el Object Lock en este caso, en modalidad compliance. No hay posibilidad de activar el modo governance. Por defecto modalidad compliance: los objetos no se pueden modificar, cifrar, borrar etcétera, por tanto, máximo nivel de seguridad.
El siguiente punto repositorio de almacenamiento hardenizado sin acceso para realizar acciones destructivas, no existe acceso al root. No existe acceso al sistema operativo, al backend. Por tanto, no podemos hacer un reseteo del sistema. No existe esta posibilidad. Por tanto, estas acciones peligrosas las evitamos.
La seguridad de Ootbi ha sido verificada por NCC Group
22:19
Cómo comentábamos: separamos la capa de software y la capa de hardware y esta seguridad que yo se os estoy vendiendo aquí, yo estoy explicando desde esta slide, es testeada por terceros. En este caso, nosotros colaboramos con la empresa NCC Group, una empresa de hackers éticos que nos realiza pen testing a nuestra solución a diferentes niveles. A nivel hardware, a nivel de la API S3. A nivel del software de Object First. Facilitamos a esta empresa. De hecho, hicimos una colaboración de 60 días.
Se realizaron dos tandas de pen testings una de 30 días, primera de 30 días, una segunda de 30 días. Al final de la primera de pruebas de 30 días se detectaron, 20 vulnerabilidades de diferente nivel de criticidad. Todas ellas fueron solventadas.
Volvimos a facilitar el appliance con las claves de administración con parte del código puente del sistema para facilitar el trabajo de hackeo de lo que sería los trabajadores, los Hackers éticos de NCC Group.
Al final de este segundo período de pruebas se comprobó que todas las vulnerabilidades, o posibles vulnerabilidades identificadas se habían solventado y la conclusión del informe que es público podéis descargar de nuestra página web.
Lo que dice es que, aunque un tercero sin permisos fuera de la organización acceda al sistema con las credenciales de administrador, no va a poder borrar los backups que hay almacenados en Ootbi, por tanto, se garantiza la inmutabilidad de los backups de los objetos almacenados en él.
Ootbi es simple.
23:47
En cuanto a la simplicidad, pues súper fácil, lo que comentábamos: 15 minutos para instalar y configurar accedemos a través de un access user interface. Os lo enseñaré que podemos acceder a través de un puerto de gestión IPMI o conectándonos en local al sistema, conectando un teclado y un monitor.
Nos adaptamos a los parámetros estándar de Veeam Backup & Replication, el tamaño de bloque de un megabyte. No tenemos que hacer más grande este tamaño de bloque. Por tanto, vamos a ser más eficientes en lo que sería la ocupación del espacio. Esto es muy importante porque nuestra solución Ootbi no deduplica. No deduplica y no comprime. Dejamos también esa tarea a de cara a Veeam.
Object First representa el futuro de la protección de datos, asegurando que cada copia de seguridad esté siempre a salvo.
Veeam es quien hace la de duplicación y compresión de los datos en origen a nivel de proxy porque lo hacemos porque no queremos tener la penalización en el rendimiento tanto en las escrituras como en las restauraciones.
Por tanto, no tenemos que deshidratar y rehidratar el dato para recuperarlo, por tanto, deduplicación y compresión la realiza Veeam.
Nosotros optimizamos, alineándonos con los parámetros estándar de Veeam Backup & Replication, a nivel de tamaño de bloque en este caso.
24:56
Y muy importante también, la escalabilidad lineal y el equilibrio automático del cluster. Cuando añadimos un nodo al cluster, los buckets que hemos configurado Ootbi los escala entre todos los nodos del cluster y los objetos que hay dentro de los backups que hay almacenados. Se distribuyen para aprovechar el máximo rendimiento de la solución.
Esto lo podemos hacer porque tenemos un nivel de integración muy elevado con Veeam Backup & Replication. Veremos que la funcionalidad que utilizamos de Veeam a nivel de integración será Smart Object Storage API. Esta es la manera en la cual Ootbi habla con Veeam Backup & Replication, y permite llegar a estos puntos de rendimiento que comentábamos y los cuales are incapié en la siguiente slide.
Ootbi es potente.
25:42
Como comentaba anteriormente por nodo, podemos llegar hasta dos 2 GB/s en lo que sería ingesta. Esto es alrededor de 7,6 TB/h. Por tanto, un rendimiento muy elevado. Velocidades de recuperación y restauración de hasta 800 MB/s. Hasta 20 sesiones concurrentes de Instant Recovery por nodo.
Por tanto, en un cluster de cuatro nodos hasta 80 máquinas virtuales en Instant Recovery. Sin cuellos de botella debido a bases de datos intermedias, no las tenemos y sin políticas de tráfico complejas para la configuración, ya que la conexión con Veeam se realiza a través de la API S3.
Object First tiene una alianza Certified Partner Alliance con Veeam.
26:23
¡Importante! Este ADN común con Veeam nos garantiza este nivel de certificación. Somos un Certified Partner Alliance de Veeam. Almacenamiento, un repositorio de almacenamiento de objetos con inmutabilidad garantizada, utilizando Secures Token Services de Veeam y gestión de identidades y accesos de Veeam también. Y sobre todo y muy importante, y somos el único fabricante que soporta al 100% Smart Object Storage API.
Este Smart Object Storage API es una funcionalidad que lo que hace es facilitar la comunicación entre Veeam Backup & Replication y el almacenamiento de objetos. Esta comunicación puede ser lo más fluida posible cuando tenemos el 100% soportada, la funcionalidad, que es nuestro caso.
El primer nivel de integración sería CapacityInfo. Veeam es consciente de la capacidad disponible y usable ocupada que hay en los buckets.
27:15
El siguiente nivel de integración que es el que nos facilita y el que nos proporciona el rendimiento elevado sería la capacidad en sí de SmartEntity.
¿Esto qué quiere decir? Nos facilita tres cositas:
- Es que Veeam Backup & Replication pueda escribir directamente en la caché de nuestros nodos. Cuando hablemos de la arquitectura del nodo, veréis que cada nodo tiene una cache NVMe. Ootbi expone la cache directamente a Veeam. Por tanto, la ingesta de datos es acelerada, es lo más rápida posible.
- Almacenamos los backups en forma de SmartEntity, si estamos haciendo el backup de una máquina virtual. Por ejemplo, una SmartEntity sería una cadena de backup que sería el backup full más los diferentes incrementales y los puntos de restauración JFS, si los tenemos habilitados, estas SmartEntity siempre se almacenan en un nodo en concreto.
Nunca se rompen y se distribuyen entre distintos nodos, con lo cual lo que hacemos es que la ingesta de los datos sea lo más inteligente posible. Siempre el siguiente backup incremental irá destinado al nodo donde está el resto de las SmartEntity y a la hora de restaurar los datos, estos backup estarán almacenados forma de objetos, pero en forma inteligente. - Otra cosa importante, somos una solución Clusterizable y con balanceo de carga. Cada appliance tiene un par de puertos de 10G o de 25 G cada uno con su IP. Si tenemos un clúster de cuatro nodos al final, vamos a tener ocho puertos usables para ingerir y para restaurar datos.
Smart Object Storage API también lo que nos va a hacer es redistribuir de forma inteligente la ingesta de los backups con granularidad, pues a nivel de máquina virtual también, aunque un job incluya 10, 20, 30 máquinas virtuales, la granularidad será a nivel de máquina y se distribuirán los backups entre los diferentes puertos del clúster de Ootbi.
28:40
Smart Object Storage API (SOSAPI) es una funcionalidad que tiene un roadmap que cada vez va integrando más cargas de trabajo a día de hoy, todas las plataformas de virtualización como VMware, Hiper-V, Nutanix, Red Hat o Promox están soportadas. Por tanto, podemos garantizar este rendimiento.
También el almacenamiento de objetos y sistemas de ficheros. Lo que no tenemos soportado a día de hoy, por ejemplo por Smart Object Storage API, sería el Veeam para 365.
Por tanto podemos seguir siendo un repositorio y de almacenamiento de objetos para este tipo de cargas de trabajo, pero no vamos a ser tan rápidos, digamos, aunque normalmente para plataformas de 365, el cuello de botella es la WAN, es Internet, no tanto el target de backup. Que se os quedáis con el mensaje de que, pues podemos seguir almacenando backups de Microsoft 365, pero no seremos tan rápidos en este caso.
Object First Smart Entities
30:00
Esto sería un esquemita de cómo funciona Smart Object Storage API, que es lo que os venía explicando. Veeam Backup & Replication procesa los datos, habremos dado de alta el bucket o los buckets dentro de nuestro cluster de Ootbi a través de un IP de servicio. Los backups van a distribuirse entre los diferentes nodos del cluster. Van a hacer un bypass de las tarjetas de red y van a aterrizar directamente en la caché de los nodos. Por tanto, aceleramos las escrituras.
El backup de una máquina virtual se va a almacenar en forma de Smart Entity. Por tanto, por ejemplo, pues para la máquina virtual File Server, pues a lo mejor la Smart Entity están el nodo uno. En este caso para la máquina virtual de Veeam One en el nodo dos, y siempre va a ser autocontenida, nunca se va a distribuir entre diferentes nodos para facilitar lo que sería la restauración.
Y siempre vamos a utilizar al máximo todos los puertos, con una estrategia de round robin se irán distribuyendo los backups de las máquinas virtuales entre los diferentes nodos para aprovechar la eficiencia.
¿Cómo funciona Ootbi?
31.00
A nivel de escalabilidad, como comentábamos, somos una solución Scale Out. La comunicación siempre se realiza a través de Smart Object Storage API, tanto a nivel de gestión como a nivel de transferencia de datos.
Si tenemos un único nodo, crearíamos los buckets sobre ese nodo. Todos los backups se enviarían al bucket o a los buckets configurados. Por nodo podemos llegar hasta 200 buckets. Si añadimos un nodo adicional, el backup auto escala, los backups se redistribuyen.
Si veis aquí arriba, cada vez que añadimos un nodo, en este caso, es un ejemplo de un nodo de 432 TB, añadiremos no únicamente capacidad, sino que también añadiremos rendimiento a la solución.
Siempre con el auto auto escalado y la redistribución y sin necesidad de configuraciones complicadas a nivel de Veeam. Añadir un nodo al cluster será estos 10, 15 minutos adicionales de básicamente Add Node To The Cluster de Ootbi, sin tener que hacer nada más a nivel de Veeam, de hecho.
Immutability for Everyone
32:00
Nuestro portfolio. Appliances de diferente capacidad. Siempre hablamos de capacidad usable capacidad neta después de haber aplicado el formateo, el RAID y el disco de Hot Spare, tendremos estas capacidades para asignar a Veeam. Desde 20 TB, pasando por 40, 64, 128, 192 hasta el nodo más grande, que es de 432 TB.
Como comentábamos el clúster de Ootbi, a día de hoy, puede llegar hasta cuatro nodos. Esto nos daría hasta 1,7 PB, alrededor de 1,7 PB por clúster.
¿Cómo llegamos a los 7 PB en un único repositorio? Aunque muchas veces también es interesante crear diferentes repositorios y redistribuir backups.
Pues llegamos utilizando Scale Out Backup Repository. Digamos que podríamos crear un performance tier de cuatro extends cada uno de los extends con un cluster de Ootbi y de esta manera llegaríamos a los 7 PB. Por tanto, la escalabilidad no sería realmente un problema en nuestra solución tampoco.
Object First ootbi ¿Qué hay en la caja?
32:55
¿Qué hay en cada uno de los appliances? Pues en el appliance os voy a poner de hecho, dejad que os comparta la página web.
Como veis aquí, está basado en un appliance de dos U. Si quitamos este frontal, lo que veríamos es un servidor de nuestros partners hardware Supermicro o Dell. A día de hoy el nodo de 432 TB es el único nodo que es de fabricante DELL. El resto a día de hoy son Supermicro.
El appliance con número de discos en función del appliance que sea, pues, más o menos discos siempre con una caché NVMe. Discos rotacionales configurados en RAID 6 más Hot Spare, para lo que sería el almacenamiento de datos y darnos esta capacidad de 20, 40, 64 etc TB.
33:47
Por la parte de detrás. Las fuentes de alimentación redundantes. Ranura para los dos discos, SSD de sistema operativo. El puerto de gestión IPMI. El puerto VGA y los USB.
Y también muy importante, todos los appliances entre los nodos entre el nodo de 20 y 192 TB vienen con dos tarjetas NIC. Una de ellas con dos puertos de 10 GB base T.
La otra de ellas con dos puertos de 10G SFP+. Habilitamos una u otra en función del tipo de red del cliente. Si está basada en cobre, pues los puertos se retan 45 si está basada en fibra pues los puertos SFP+. Los transceivers no vienen incluidos en la tarjeta. Hay que añadirlos aparte.
Object First preguntas y respuestas.
34:33
Miquel Mariano:
Hemos dicho que los nodos no se pueden configurar. Es decir, tú pides un nodo de 20 TB o de 40 TB o del tamaño que sea, pero no puedes elegir ni qué discos ni cuántos discos ni qué tarjetas, sino que ya viene todo dentro de eso es esa caja, ¿verdad?
Miguel Tena:
Eso es. Es una caja cerrada. Al final, el appliance de 20 TB. Pues el appliance de dos U que te viene pues, por ejemplo, con sus nueve discos de 4 TB cada uno configurados en RAID 6 más Hot Spare, los discos de sistema operativo, la cache NMVe, pero es una caja cerrada.
Estos no se podrían cambiar. Para para ampliar la solución lo que hay que hacer es añadir un nodo adicional y puede ser de cualquier tipo.
O sea si hemos empezado por el nodo de 20 TB luego podemos comprar el segundo de 432 TB un mix tener no de la manera de cada un nodo de cada tamaño dentro del mismo clúster.
Eso es, sin ningún tipo de problemas. Todos son compatibles, independientemente del fabricante o del vendor hardware que haya por detrás, e indiferentemente de la capacidad o del tipo de appliance.
35:39
Rubén Cuesta
Justo ahora mismo nos hacen una pregunta en el chat a este aspecto que dice:
«El hecho de añadir Nodos de diferentes tamaños, ¿influye en algo?»
Estamos justo diciéndolo ahora que se puede mezclar en un mismo cluster, nodos de diferente tamaño, pero ¿alguna consideración Miguel, a la hora de balancear las máquinas virtuales?
Lógicamente una configuración de cuatro nodos de 20 TB vas a poder tener los nodos exactamente igual de balanceados. Si tú tienes un nodo de 20 TB y un nodo de 60. Pues lógicamente no puedes tener distribuidas de forma equitativa los backups entre los dos nodos, pero sí que puedes tener distribuidos esos backups entre los dos.
36:23
Miguel
Eso es, de hecho, toda esta operativa la hace Smart Object Storage API. El escalado de los buckets y la distribución de los backups entre los nodos la hace, Ootbi y Veeam con esta funcionalidad.
Por tanto, a nivel de usuario, obviamente los nodos van a ser distintos. Vas a tener más backups almacenados en un nodo de 432 que en el nodo de 20. Pero la solución lo que va a hacer va a hacer el auto escalado y la distribución de los backups en función de la capacidad disponible en cada uno de los nodos.
36:55
Rubén
Y en términos de rendimiento, en principio, no hay ninguna diferencia porque los nodos salvo el más grande que tiene interfaces de red a 25 GB, el resto tiene 10 GB con la caché NVMe con el rendimiento es igual a nivel de escritura y a nivel de lectura en un nodo de 20 o en un nodo de 60.
37:13
Miguel
Eso es. Del nodo de 20 al nodo de 192 en todos vamos a tener por nodo de un rendimiento en escrituras de 1 GB/s y 600-800 MB/s en lo que sería restauraciones.
En el nodo de 432 TB es el único que duplica este rendimiento: 2 GB/s gigabits por segundo y hasta 1,2-1,6 TB/s en lo que sería restauraciones.
Entonces es sencillo. La arquitectura sería la de un servidor que conocéis toda la vida con sus fuentes de alimentación, sus procesadores, sus discos de sistema operativo, su controladora RAID, sus discos, su caché NVME.
Por tanto, sencillez también a la hora de la arquitectura de lo que sería el sistema, ¿de acuerdo?
Rubén
Para que comentásemos ahora que nos preguntaba Félix Pablo, si tuviéramos alguna copia fallida almacenada, si esa copia se podría borrar o tendríamos que esperar a que llegue a que finalice la retención.
Miguel
Vale, tenemos que esperar a que finalice la retención. Nosotros marcamos os lo enseñaré en la demo un período de inmutabilidad, la integración es 100% con Veeam. Por tanto, el período de inmutabilidad lo gestionamos y lo administramos desde Veeam.
38:27
Ese número de días lo veremos, cómo se define cuando añadimos un nuevo repositorio. Y sí, hay que esperar a que finalice ese período de retención.
Si marcamos un período de retención de 15 días, pues los backups son inmutables durante esos 15 días más el período que añade Veeam adicional de block generation, que son 10 días adicionales para soluciones compatibles en S3, y tendríamos que esperar ese tiempo, sí.
Rubén
Que eso, lógicamente al final, Miguel, redunda en que la solución de verdad es inmutable y no se puede modificar. Como no tenemos un acceso root comparado con un repositorio hardened Linux en el que, si podíamos elevarnos como root, poder quitar el atributo de mutabilidad y poder borrar los ficheros de backup antes de que expirase aquí no. Y de verdad ni nosotros ni un hacker podría ser capaz de borrar algo antes de que llegue, antes de que finalice la retención.
Miguel
Eso es, eso es. Así es. Es la parte buena de nuestra solución. O sea, la inmutabilidad es real. Por tanto, no se pueden borrar esos backups hasta que expire el período de inmutabilidad.
Rubén
Pues, si quieres, eso, empiezo con la demo y así que vean un poco como es el entorno.
Miguel
Claro que sí.
Object First Demo de Ootbi
39:46
Mira, lo primero que haremos es lo que os comentaba al inicio. ¿que vamos a hacer?. O sea, vamos a un par de personillas ahí y media o 15 minutos para sacar de la caja. Enrrancamos, conectamos a la alimentación, conectamos los puertos de red, el puerto de gestión, o le conectamos un teclado y un monitor.
¿Que es lo que veríamos? Pues os voy a enseñar la consola texto. Esta parte de dos minutos, la tengo grabada, que es donde vamos a empezar con lo que sería la configuración de red.
Mira, aquí os pongo las diferentes opciones que tenemos. Obviamente, cuando empezamos lo que vamos a hacer es Setup New Cluster. Aunque tengamos un único nodo, es un cluster para nosotros.
Podemos empezar por un nodo. No hay ningún problema. Entonces hacemos Setup New Cluster, añadimos, elegimos esta opción y lo que comentamos, cada nodo de cada nodo vamos a utilizar un par de puertos de 10 G cada uno, sean Base T o de 25 G en nodo más grande, sean Base T o sean SPF+, los puertos de 10 G.
40:47
¿Que vamos a hacer? Asignar una dirección IP para cada uno de esos puertos. En este caso, estamos utilizando la 172.16.4.60.
Definimos el resto de parámetros de red, submáscara, default gateway, DNS principal y alternativo en caso de existir, hacemos lo mismo para el siguiente puerto.
Los dos puertos se utilizan en forma activo-activo. No se configura un trunck LACP entre los dos puertos porque queremos utilizar Smart Object Storage API y poder enviar backups de forma alterna o de forma eficiente entre los dos puertos y que sea Smart Object Storage API, quien decida cuál es el puerto más efectivo para hacer la ingesta de ese backup.
Una vez hemos configurado la IP de los dos puertos de 10 G, lo que hacemos. Es poner un nombre al nodo. En este caso le vamos Ootbi01. ¿DE acuerdo? y enter.
Y lo que vamos a hacer va a ser bueno, aplicar lo que va a hacer el nuevo automáticamente, aplicar estos parámetros de red configurados.
41:46
Importante: el sistema podemos habilitar la telemetría si el sistema de telemetría para intercomunicar con nuestros sistemas para la parte de soporte y también para la parte de alertas update etc, etc.
Si hubiese un update disponible el sistema nos preguntaría si queremos actualizar el software en ese momento. No aparece aquí el box, pero lo que haríamos es darle ok, actualizaríamos el software y tendríamos el software actualizado desde inicio.
Veremos que durante el proceso y la administración y durante el tiempo de vida del sistema también es muy sencillo hacerlo.
Ponemos un nombre al cluster. Hemos puesto un nombre al nodo. En este caso lo llamamos Ootbi bastante sencillo y una IP de servicio. Esta es la IP que vamos a utilizar para conectar el repo con Veeam.
En este caso la IP 172.16.4.70, que será una IP virtual On TOP de la ips de los puertos de 10 G.
Definimos un password para acceder a la web user interface que os lo enseñaré ahora.
Esto serían los dos minutos y medio necesarios para configurar los parámetros de red del sistema.
Miquel Mariano.
Este usuario Object First es el único usuario que tendremos para acceder a la plataforma. No hay un usuario de línea de comandos. No hay ninguna puerta para entrar que no sea. La interfaz con este usuario, ¿verdad?
43:02
Miguel Tena
Eso es. Existen otros usuarios con menos privilegios O sea, pero podemos definir diferentes usuarios en la web user interface. Este es el usuario por defecto, el usuario Object First.
Luego podemos definir usuario administrador hardware, usuarios con permisos para crear un bucket por si hay eh, diferentes usuarios en lo que la administración del entorno de backup. Usuario únicamente de visualización. Si tenemos gente que está en la parte de soporte interno.
Pero no hay ningún usuario que tenga privilegios.
Miquel Mariano.
Hablamos siempre de usuarios de Ootbi, nunca de sistema operativo operativo para acceder a las tripas de la solución.
Miguel Tena
Eso, solo de Ootbi, correcto.
Entonces, con este usuario o con estos usuarios, lo que haríamos acceder a la web user interface con la contraseña. Yo tengo aquí mi usuario creado con la contraseña creada en el paso anterior que si he tecleado bien, pues debería funcionar. Y aquí entramos en la web user interface.
Esto es la máxima complicación de del sistema que, como veis, pues es bastante sencillo: dashboard, información general, eh, monitoring.
Aquí tenemos diferentes parámetros de rendimiento de throutpot, tanto a nivel de API S3 como de disco como de uso de CPU, operaciones de la API, uso de storage. Diferentes gráficas que podemos ver online o podemos hacer también, pues, a nivel diario, semanal o mensual.
44:32
Cuando accedemos por primera vez a la web user interface de Ootbi lo que tenemos que hacer es básicamente lo que queremos es configurarlo como repositorio.
Para configurarlo como repositorio lo que haríamos es crear un bucket y crear unas claves S3. Tendríamos un wizard aquí que nos iría iluminando los pasos de lo que tenemos que ir haciendo. Lo primero: por ejemplo, crear las claves S3.
Como veis aquí, tengo unas cuantas creadas… para crear una nueva. Pues sería darle a un botón de create key, poner el password si tuviésemos el multifactor de autenticación activado también el multifactor de autenticación. Este es el password que hemos utilizado para acceder al web user interface. Lo mismo. Si se te ha creado bien, pues, por ejemplo, copiaría. Me lo copio, por ejemplo, aquí en un blog de notas, tanto el access ID como el secret access key.
Aquí las mantengo. De acuerdo, creamos un bucked. Por ejemplo, vamos a hacer crear bucked como veis aquí también tenemos, unos cuantos hay cinco pantallitas con buckeds creados para crear un bucked nuevo. Simplemente, create bucket y ponerle un nombre, mtmtest08, por ejemplo.
45:53
Todo en verde que cumpla la normativa. Muy importante. El versioning está habilitado por defecto. Esto lo que es característica indispensable para que los objetos sean almacenados dentro del bucket sean inmutables. Por tanto, el cheque está habilitado por defecto.
Si queremos un entorno eh, de pruebas, pues lo podemos deshabilitar, pero en un entorno productivo, lo dejamos habilitado.
Y sería pues, darle a create.
Miquel Mariano:
Una vez creado, no se puede deshabilitar
Miguel Tena
Una vez creado, no se puede deshabilitar, exacto. Cuando hemos empezado a escribir alguna cosilla ahí, ¿vale?
Cuando lo damos de alta, como mira, vamos a hacer la prueba. Por ejemplo, tengo el versioning habilitada. Pero yo no he escrito nada aún en este bucket que era el mtmtest08. Vamos. Pues no se como le he llamado. Bueno, vamos a intentar este. Lo tengo. Vamos a crear otro porque me olvido del nombre. Y tengo la lista. Super larga testmtm…
Josep Ros
Pónle Encora hombre 🙂
46:59
Miguel Tena
jejeje vamos. Test Encora y versioning habilitado, create
Vale versioning inhabilitada. Test está en, lo tengo aquí, como veis back up data y que se tres data pero y cero en este momento, como, no tengo nada dentro, lo podría borrar. Vale, si yo hago delete bucket pues, podría borrarlo aquí. Me permitiría borrarlo.
Pero por ejemplo, este testmtm06 que aquí ya lo he dado de alta como repo en Veeam. Por tanto, empezaba a tener he creado un folder ahí adentro. Aunque no tenga backup, lo voy a intentar borrar.
Vale. Y aquí ya me da el error en el momento en que lo doy de alta como repo, aunque no tenga backups y más cuando tengo backups, pues desde ese momento ya no podemos borrar el bucket, ¿de acuerdo?
48:12
Entonces, por ejemplo, lo que haríamos ahora hemos creado un bucket. Hemos creado unas claves S3. Quizás utilizo alguna de las que ya tengo. Me iría a la consola de Veeam, vamos a ver. Si le da la gana. Vamos a añadir un rep backup infra. Vamos a ir aquí, backup repository. Bueno, como veis, todos estos buckets azules son buckets que ya tenemos dados de alta en el Veeam de laboratorio. Añadimos un nuevo repositorio object storage compatible S3.
Le pondríamos un nombre a este a este nuevo repo. Y aquí lo que se nos va a pedir es un service point, un IP de servicio y unas credenciales, ¿de acuerdo?
La IP de servicio es la que hemos configurado en la text user interface y la podemos encontrar en el dashboard de la web user interface. La tenemos por aquí, esta acabada en 4.70, un copy paste fácil.
La región es algo que viene del estándar S3 lo podemos dejar por defecto. Podemos poner el nombre que nos apetezca. Y aquí, pues utilizaríamos alguna de las claves S3 creadas. Vale, yo estaba por creada también hace unos días, le doy next y entonces ahora ya me estaría conectando al cluster de Ootbi.
49:31
Y ahí ya podría hacer un brownse de los buckets que tenemos creados dentro del sistema y empezar bueno y darlo de alta como repo.
Pues, por ejemplo, podría elegir cualquiera. mtmtest08. Aquí hay una funcionalidad nueva de la versión tres, el automatic bucket creation enabled. Esto les es útil a los fabricantes que no disponen de Smart Object Storage API por la creación, eh, de buckets automática.
Nosotros lo deshabilitamos porque no lo necesitamos. En este caso, mtmtest08, brownse. Lo que tendríamos que hacer es crear un new folder. Pondríamos un nombre, daríamos ok.
Y aquí es donde podríamos limitar cuanto ese bucket puede auto escalar o no. Si queremos limitarlo, normalmente no lo limitamos, pero lo podemos hacer.
Y aquí muy importante también lo que comentábamos aquí es donde marcamos tantos días de backup inmutables: 7, 30, 90 días.
En función del número de días que queremos que los backups sean inmutables al igual que de la retención que queramos marcar en el job de backup, pues vamos a ocupar más o menos espacio. Pero aquí es donde marcamos la parte de lo que sería, pues retención inmutabilidad de los backups.
51:03
¡Ay! Aquí no debería haber hecho esto porque he puesto 30 días. Ya no lo voy a poder borrar. Voy, voy a ir atrás. No lo voy a dar de alta porque sino aquí toda es lo que decíamos. Esto más cuidado, le daría cancelar al final.
Definimos Mount Server, básicamente para tener toda la parte de restauraciones definidas, la caché etc. Review, Apply y Summary, y sería, tendríamos un nuevo bucket aquí creado dado de alta a llegar al final. Y sería un nuevo bucket al cual ya podríamos ir enviando, backups.
¿Alguno que tengamos creado?. Pues, por ejemplo, aquí tenemos algún job, que apunta a uno de los buckets. Este job, pues tiene cuatro máquinas virtuales, por ejemplo, un Domain Controler, un Filer, este servidor de Kasten y Veeam One.
51:47
Vamos al object storage del repositorio. Aquí tenemos los backups de estas máquinas. Intento borrar un backup del Veeam One. El backup se hizo ayer, Delete From Disk, Delete Machine From Backup, vamos a hacer un yes. Y entonces, obviamente Veeam va a empezar el job de lo que sería el borrado, lo va a intentar hacer.
Y al final, lo que nos tiene que dar es un error. No se han podido borrar estos backups o este backup que me estás pidiendo que borre porque el sistema lo tiene marcado como inmutable durante un periodo de x dias.
En este caso, pues, por ejemplo, durante 14 días hasta el 14 de julio, es un poco más de estos 14 días por los 10 días adicionales que añade Veeam de la inmutabilidad por generation. Pero pues aquí no podemos borrar los backups. Entonces, pues habría finalizado este job con error.
Josep
52:45
Oye, Miguel, llevamos ya casi una hora yo pararía, porque esto es infinito, vale. Y haremos otros ya un poco más avanzados, ¿vale?
Yo creo que tenemos muy claro que es un componente hardware que no tiene sentido si no tenemos Veeam Backup & Replication en nuestra empresa, ¿no?.
Tenemos que tener Veeam Backup & Replication para complementarlo con Object First. Quitar todo lo que tengamos de nases de esas baratitas o de cabinas viejas o historias de estas ¿no? y poner nuestro nuestro equipo.
Me gustaría, decir que, porque hay una pregunta en el aire de esto, ¿cuánto vale?, Hemos hablado ahí con la jefa. Y podemos decir a partir de 20.000 euros podemos tener, esta solución.
Luego, evidentemente, todos los que queráis saber precios nos mandáis presupuesto, hablaréis con Miquel o con Rubén. Vemos exactamente el tamaño que tenemos que tener. Yo, esto de los siete PB que has dicho y me viene un poco justo. Hago muchas, muchas fotos ¿Sabes?
Miguel Tena
Sí! Suele pasar, suele pasar. A mi también.
Josep Ros
Y nada super contento de todo lo que has contado que lo haces súper fácil.
Rubén Cuesta
Cualquiera que quiera ahora mismo pues se puede quitar el micrófono y puede preguntar también.
Durante la inscripción al webinar hubo una persona que nos escribió, lo pego ahora en el chat, para decir si podíamos explicar pues como se realizaría la recuperación del entorno en caso de un virus o problemas en el CPD on premise ¿vale?, entonces Miguel, Miquel si podéis contestar…
Miguel Tena
54:26
Aquí. Pues, si queréis, contesto super fácil también. O sea, como decíamos, segmentación de software y segmentación del hardware. Hay un compromiso en el software. Por ejemplo, vamos a poner que se revientan el Veeam backup & replication.
Tenemos nuestros backups, como comentábamos, almacenados en los buckets, backups inmutables.
No han podido ser borrados. Lo que deberíamos hacer, pues, deberíamos tener algún recurso, obviamente, para desplegar una nueva máquina virtual, una nueva máquina virtual con el Veeam backup & replication, a la cual le presentaríamos un bucket el cual ya existen backups, se marcaría la opción de ya hay backups en este bucket.
Se haría un rescan de este bucket, se importarían esos backups y se podrían empezar a restaurar esos backups de ese nuevo servidor de Veeam Backup & Replication. ¿De acuerdo? Entonces ahí tendríamos una posibilidad.
Si ha habido una situación, por ejemplo, en la que no se ha comprometido el software de Veeam Backup en Replication, pero las máquinas virtuales productivas, pues han sido borradas, por lo que sea.
¿Que es lo que suele pasar al final? el ransomware ataca primero, borra, cifra los backups y luego la parte productiva. Cuando vas al backup, ya no lo tienes.
Pues en nuestro caso nos sucede. En nuestro caso lo que podríamos hacer es poder utilizar un Instant Veeam Recovery y poder levantar las máquinas virtuales desde el propio repositorio de Ootbi.
Por tanto, podríamos empezar a trabajar desde Ootbi también. Y luego cuando tuviésemos solucionado o los recursos provisionados necesarios en el entorno con el almacenamiento productivo, proceder con storage vmotion, por ejemplo, y mover las máquinas a productivo.
56:02
Por lo tanto lo que hacemos ahí es optimizar las recuperaciones y las restauraciones.
Miquel Mariano
Yo allí añadiría otra casuística. En caso de que tengamos una contingencia grave en nuestro CPD que perdamos también el appliance de Object First, la solución pasaría por tener configurado, pues, esa regla del 3:2:1, ¿no?
De tener un backup offsite, de tener un backup copy, pues ya sea en otro Ootbi o en otro repositorio, y poder empezar a recuperar los sistemas fuera de tu Datacenter.
Entonces, ahí está el ejercicio de preparar bien esos escenarios, este plan de contingencia para que cuando pase, al menos saber por dónde tirar.
Miguel Tena
Totalmente.
Josep Ros
56:48
Genial. ¿Alguna preguntita más, chicos? Si no cerramos, ya que serán las 11 y seguro que tenéis otras cosas que hacer. Super agradecido a todos por estar aquí.
A vuestra disposición, ya sabéis: preventa@encora.es para cualquier consulta que tengáis de precios, características, etcétera, y nada todos los que tengáis Veeam, os recomendamos encarecidamente que pongáis esta solución porque es la felicidad y la tranquilidad.
¡Que paséis feliz verano!
Un abrazo muy grande desde Mallorca. Cuidados mucho. Chao chao.
(Varios)
Gracias a todos. Gracias. Gracias.
Pide tu demo gratuita y tu consultoría sobre Object First
Si te gustó este contenido y estás interesado en hablar con expertos de Object First y obtener una demo y un estudio en tu compañía de cómo mejorar Veeam Backup & Replication con un Appliance de backup Inmutable como O1, escríbemos a hola@encora.es y te ayudaremos.
5 datos clave de Object First:
- Object First es la solución ideal para todos aquellos que buscan un respaldo seguro y eficiente para Veeam Backup & Replication.
- Object First asegura que todos vuestros datos están siempre protegidos y disponibles, siendo una parte esencial de la infraestructura moderna de respaldo y garantizando la NIS2.
- Object First es la solución ideal para todos aquellos que buscan un respaldo seguro y eficiente.
- Object First asegura que todos vuestros datos están siempre protegidos y disponibles.
- Object First es una parte esencial de la infraestructura moderna de respaldo.
