Saludos amigos, primer post fuerte de Septiembre, hoy os traigo un post muy entretenido sobre Veeam Backup and Replication sobre un Repositorio basado en AWS Storage Gateway, y como se me ha quedado un poco largo quiero dejaros aquí el menú para moveros más rápido:
- AWS Storage Gateway – vistazo rápido
- Desplegando el Virtual Appliance de AWS Storage Gateway en vSphere
- Configurando AWS Storage Gateway
- Crear File Share en Amazon S3
- Crear Repositorio en Veeam Backup and Replication
- Vistazo a un job de Backup Copy
- Vistazo a un job de Backup
- Monitorizando con Cloud Watch
AWS Storage Gateway – vistazo rápido
AWS Storage Gateway nos permite consumir ciertos recursos de Amazon Web Services de manera local mediante un virtual appliance que desplegamos en nuestra Infraestructura, de manera que nuestras VM ven el recursos como si fuera local, mientras que la información es replicada de manera encriptada y comprimida hacía el Cloud de Amazon.
AWS Storage Gateway nos permite crear diferentes recursos:
- File Share: Que es ni más ni menos que un NFS donde podemos conectar equipos que verán una unidad de red tradicional y allí almacenar ficheros.
- Volumes: Donde podemos consumir por iSCSI, volúmenes que podemos conectar a Windows, Linux, etc, y que serán replicados más tarde.
- Tapes: Unidades de cinta virtuales con las que podemos lanzar copias de seguridad con Veeam por ejemplo, como se de una cinta real se tratara, y conseguir así un almacenamiento más duradero como son las cintas, pero en Cloud.
A su vez, podemos guardar la información en tres diferentes tipos de almacenamiento en Amazon:
- Amazon S3, lo recomendado para ficheros o volúmenes que usamos de manera frecuente.
- Amazon Glacier, si lo que estamos guardando no es accedido de manera frecuente.
- Amazon EBS Snapshots.
Así es como quedaría nuestra Infraestructura de Veeam Backup and Replication con AWS Storage Gateway.
Desplegando el Virtual Appliance de AWS Storage Gateway en vSphere
Lo primero que haremos será irnos a la web de AWS Storage Gateway, seleccionar la región arriba a la derecha y presionar Get started.
En este caso seleccionaremos que queremos un File gateway.
Seleccionaremos la plataforma donde queremos desplegar el virtual appliance, en mi caso VMware ESXi. Antes de presionar Next, continuemos con el despliegue en vSphere.
En nuestro vSphere Client HTML5, o en nuestro vSphere Client Flash, haremos botón derecho en nuestro clúster y seleccionaremos deploy ovf template.
Seleccionaremos el fichero que acabamos de descargar y descomprimir y presionaremos Next.
Seleccionaremos un nombre para nuestra VM, y la carpeta donde queremos ubicarla.
Seleccionaremos el Host y demás pasos.
Veremos el progreso de despliegue
Y cuando termine podremos encender la VM
Una vez que la tenemos encendida, tenemos que anotar la IP ya que la usaremos en el siguiente paso de la configuración del AWS Storage Gateway.
Configurando AWS Storage Gateway
De vuelta a la configuración, introduciremos ahora la IP del AWS Storage Gateway VM, y presionaremos Connect to gateway.
Seleccionaremos la zona horaria del appliance, así como un nombre descriptivo para el gateway.
Ahora en nuestra VM de AWS Storage Gateway crearemos los discos de cache, podemos crear uno, o varios, además de alojarlos en el Datastore que queramos, si queremos mejor velocidad ubicarlo en disco rápido, si la velocidad no es problema, entonces en SATA.
Tener en cuenta que el disco de caché es usado hasta que la información se transfiere, por lo que hay que tener suficiente espacio para nuestras copias de las VM. 
Una vez hemos añadido los discos en nuestro appliance, podemos hacer click en Edit local disks.
Y seleccionar el disco que queremos y marcarlo como caché.
Pequeño truco: Login en el appliance
Si queremos configurar la IP estática dentro del AWS Storage Gateway o realizar otro tipo de operaciones, entraremos a la consola de la VM:
E introduciremos el usuario y password por defecto (podemos cambiar la pass desde el menú actions de AWS). User: sguser, y password por defecto: sgpassword
Crear File Share en Amazon S3
Una vez que tenemos ya el disco o discos de caché listos el siguiente paso es crear el File Share, lo podemos hacer presionando el botón que veis en la imagen:
En otra pestaña del navegador, crearemos un nuevo Bucket de S3:
Le llamaremos de una manera descriptiva, y si queremos editaremos el acceso, etc. En mi caso he presionado create sin más configuraciones adicionales.
De vuelta al asistente de AWS Storage Gateway, seleccionaremos el gateway que tenemos e introduciremos manualmente el nombre del bucket S3 que acabamos de crear. Podemos seleccionar en este momento si queremos que sea S3 Glacier o S3 normal. He seleccionado normal.
El siguiente paso nos permitirá configurar y filtrar un poco más el aspecto del server NFS que se configurará en el AWS Storage Gateway que tenemos localmente. (Se puede editar más tarde, por lo que no os preocupéis)
Si hacemos click en el File Share, tenemos el comando para conectar de manera muy cómoda este nuevo NFS en nuestro entorno local.
Crear Repositorio en Veeam Backup and Replication
Al ofrecer una unidad NFS únicamente, usaremos un repositorio de Linux para poder acceder a este NFS, en nuestro Veeam nos iremos hasta el asistente para crear un nuevo repositorio:
Seleccionaremos que sea de tipo Linux
Seleccionaremos el servidor, que ya tenía creado anteriormente, y le daremos a populate, veremos el punto de montaje de tengo con el NFS, lo seleccionaremos y haremos click en Next.
En el path to folder podemos editar si queremos donde se guardaran las copias, pero por defecto he dejado en la carpeta backups. Además siempre podemos jugar un poco con las configuraciones avanzadas, tareas simultáneas, etc.
Como mount server dejaremos este propio servidor de Veeam y haremos click en Next.
Si el resumen de la configuración está correcto, podemos presionar Apply.
Y veremos comenzar el proceso de configuración del Repositorio Linux.
Vistazo a un job de Backup Copy
Vamos a realizar una prueba con un trabajo de Backup Copy, vamos a irnos al asistente y seleccionar VMware:
Le pondremos un nombre descriptivo, y a la hora a la que queremos que empiece a copiar:
Le diremos que queremos seleccionar las VM desde un job 
Y por ejemplo seleccionaremos el trabajo de Infrastructure:
El trabajo tiene un peso de 235GB, pero las VM ocupan mucho menos.
Le diremos que queremos usar el Backup Repository que hemos creado anteriormente:
Para el Data Transfer seleccionaremos que sea directo, ya que no salimos a WAN.
Y podríamos también controlar cuando el trabajo puede enviar información y cuando no, ya que los trabajos de backup copy transmiten información de manera continua.
Si todo está bien, haremos click en Finish.
El trabajo comenzará a ejecutarse, y de nuevo, será copiado al repositorio basado en Linux que a su vez tiene el AWS Storage Gateway con la cache montado en NFS, por lo que la copia es dentro de nuestro Data Center.
Pasadas dos horas, el trabajo ha terminado correctamente y tenemos las dos VM copiadas a nuestro nuevo Repositorio, ha ocupado al final 91,8GB.
Lo bueno que tenemos usando AWS Storage Gateway, es que podremos realizar todas las operaciones de restaurar como si tuviéramos los discos de manera local, podemos restaurar la VM, solamente un disco, algunos ficheros, etc.
Vistazo a un job de Backup
No me extiendo en la configuración de un trabajo de copia de Veeam, ya que es lo de siempre, aquí el resultado de una copia full de una VM a este nuevo repositorio, ha tardado solamente 23 minutos y se han transferido 16GB.
Si vuelvo a lanzar el trabajo, para obtener la incremental, ésta ha tardado solamente dos minutos, se han copiado unos 368MB y ha ido mucho más rápido.
Si conectamos el AWS Storage Gateway NFS a una máquina Windows, podremos ver todos los ficheros como si estuvieran en una unidad de red, cuando en realidad están almacenados en Amazon S3.
Monitorizando con Cloud Watch
Muy interesante es ver con Cloud Watch el consumo de ancho de banda, o de escritura en disco, etc. Por ejemplo, éstas son las estadísticas del File Share, podemos ver cuantos bytes escribimos cuando realizamos el backup copy job, cuanto con el backup job full y cuanto con el backup job en incremental. Además la delgada línea púrpura es la constante sincronización entre la caché y Amazon S3, consumiendo alrededor de 1Mbps continuamente.
Estas son las estadísticas del AWS Storage Gateway, donde nos muestra el estado de la caché.
Esto es todo amigos, en futuras entradas veremos un tutorial de AWS Storage Gateway con Volumen por iSCSI y con Unidad de Cinta virtual también.
Si tenéis alguna duda con escalado de Amazon AWS Storage Gateway y Veeam os recomiendo escribir a mi amigo James
Hola Jorge
Antes de nada, enhorabuena por tu blog, realmente fantastico el trabajo aportado.
He estado configurando el entono que propones y me quedo atacado en un paso. Es un entorno VMware vSphere. Configuro la VM del AWS Gateway, almacenamiento, etc. Aunque, cuando en VEEAM intento configurar el repositorio en LINUX, en Server introduzco la IP del AWS , en el siguiente paso, me pide un usuario y pass para validarme en el servidor LINUX. Si la dejo en blanco no me deja continuar, si configuro user:sguser y password:sgpassword, me da el error “failed con logon 192.168.0.X. port:22 user: sguser, elevation to root: “no” autosudo:no……..”. Buscando por Internet no encuentro nada relacionado.
¿donde podra estar el error?
Un saludo y gracias
Nacho
Saludos Nacho, para ello lo que he hecho es poner una VM Linux, tonta, en medio, un ubuntu simple, con un punto de montaje NFS hacia ese AWS. Luego pongo a ese repositorio en Veeam y ya esta.
Un saludo
Hola Jorge
Gracias, he conseguido que funcionara un Backup copy de de VEEAM de una VM de 60 GB. Sin embargo veo lo siguiente
* el Backup copy se realizo correctamente
* Si monto por NFS el AWS en un Windows, en el explore veo los dos ficheros de VEEAM, ****.vbk y ****.vbm., el vbk con 60 GB de tamaño
* Sin embargo, si entro en el bucket S3 por navegador de Intenet, solo veo el fichero vbk aunque ocupa 30,1 MB. y lleva con ese tamaño varias horas.
En cloudwatch veo que la cache esta siendo utilizada en 60 GB. Por alguna razón no transfiere los datos de las cache del Storage Gateway al bucket S3. ¿Me falta algo por configurar para que lo transfiera?
Un saludo
Nacho
Gracias Jorge
Tengo una duda respecto al funcionamiento que la documentación de AWS SG no me aclara. Imaginemos que tengo un backup diario en una NAS con retenciones solo trimestrales durante 1 año y quiero hacer un backup copy en un AWS SG aunque con retenciones trimestrales, semestrales y anuales durante 5 años. Lógicamente, los backup copy ocuparan mucho mas que los backup normales. Mi duda es como funciona el uso de cache de AWS SG, si el disco de cache actua de pasarela para llevar la informacion a S3 y luego vaciarse una vez transferida la informacion a S3 o si el disco replica sincronamente su contenido a S3, de tal forma que el mismo contenido que hay en AWS SG esta tambien S3. Tiene su importancia ya que en el segundo caso, si los backup copy llegaran a tener Teras de informacion, habria que configurar discos de Teras en la VM.
Gracias por tu ayuda
Nacho
Saludos Nacho, la cache es solo para ayudarse localmente mientras se transfiere hacia Amazon S3 o SG, después de que se transfiere se borra pasado un tiempo de la cache, no es que se borre, es que se ha movido hacia AWS.
Voy a realizar unas pruebas y escribo una breve nota en el blog, coméntame tus impresiones.
Un saludo
Hola Jorge
He estado haciendo pruebas al respecto, y si bien es cierto que el disco de cache aumenta y reduce su espacio ocupado aunque minimamente +-20 Gb.(tengo un disco de 160 GB asignado) este nunca se vacía, se queda en unos 144 GB casi permenentemente de uso de 160 GB de cache. Sin embargo, si es cierto que parece que sube toda la información a AWS, ya que en AWS hay mas datos que el que existe en la cache (según cloudWatch) y que corresponde con el esacio que ocopan los Backup Copy.
Un saludo
Nacho
Asi es Nacho, me alegra que hayas podido realizar todas estas pruebas, yo las hcie tambien y documente lo mejor que pude. Es una opcion muy elegante usar el Storage Gateway de AWS, ademas de monitorizar con cloudwatch, etc, un avance muy grande.
Un saludo
Hola Jorge,
He seguido haciendo pruebas estas en producción con mis VM, en total ahora ocupan 1,6 TB en AWS S3 y la verdad, va de lujo. EL único problema que tengo y que supongo es debido a VEEAM es la facturación que me hace de trafico de salida AWS en concreto
“$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier” en el cual me dicen que se ha descargo de AWS 3,051.834 GB.
En CloudWatch, veo que se hacen descargas de información, supongo que será debido a que VEEAM debe comparar las copias diarias, aunque nunca 3 TB en todo un mes. En la configuración del repositorio no he marcado “Use per-V backup files”, ya que el tipo de licencia no me lo permite.
En la monitorización de tráfico del firewall tampoco veo que se genere ese tráfico de salida de AWS a mi entorno. Existe tráfico, aunque ni mucho menos esa cantidad
Como dato, según la factura de AWS el concepto de trafico de salida de AWS Storage Gateway EUW3-Uploaded-Bytes fue de 4,792.839 GB $0.01 per GB – first 12.2 TB / month data written by your gateway to AWS storage.
¿Te ha pasado algo similar?
Un saludo y gracias
Nacho
Excelente! Muy buena información. Desde el norte de Argentina muchas gracias
Buenas Jorge,
Excelente articulo. Me encuentro configurando el entorno siguiendo el tutorial pero cuando llego a la parte de los discos me da error. Me dice “No local disks found”, entiendo que no está pudiendo ver los 2 discos que tiene la VM.
Sabes como solucionar esto?.
Gracias.
Saludos Alex,
Yo use en el tutorial un Linux donde conecto el NFS los discos del Appliance, y pongo ese Linux en Veeam, lo hiciste asi?
Buenas Jorge,
Lo que no me detectaba era los discos de cache desde la web de AWS. Ya está solucionado solo había que reiniciar el Virtual Appliance.
Gracias.
Que chulo ! Ya me cuentas que tal el rendimiento y si estas contento, en Veeam 9.5 U4 vas a poder usar directamente Amazon S3, Microsoft Blob, etc.
Buenas Jorge,
Ya he hecho algunas pruebas y bueno, esperaba algo más de rendimiento. copiando una máquina de 100Gb 16Mb/s de media, entiendo que esto es depositando la en el Gateway local.
No se si tienes idea para mejorar el rendimiento.
Otra pregunta que me gustaría a ver si me puedes contestar, es si a la hora de ralizar una recuperación digamos un archivo dentro del vmdk, internamente se baja a local todo el vmdk y se habre y se extrae en local?.
Por otro lado que diferencia hay entre usar este sistema el Veeam cloud Connect.
Gracias.
Hola Jorge! Tienes algún tutorial para realizar esa tarea?
Que tarea Diego? Si esperas un poco mas en el siguiente Update 4 ya viene soporte para guardar backups en S3, Azure blob, etc.
Jorge estimado, tengo una situación algo similar, pero el arquitecto de soluciones me dice que es ineficiente tirar del storage gateway, que mejor grabar directamente en el s3 desde el VeeamBackup, que podrias recomendarme.
Saludos Johan,
Tu arquitecto tiene razón, este artículo es de 2017, y justo a principios de este año ya se anunció Cloud Tier/Capacity Tier, puedes ojearlo en el blog, esa es la manera de hacerlo.
Buenas Jorge,
He leído casi todos los artículos de Veeam que tienes en la web este fin de semana, y tengo una duda. Veo que con Capacity Tier de la nueva versión 9.5 U4 puedo subir a AWS las copias que tienen cadenas full + increméntales cerradas (hasta que se haga otra synthetic o full) o bien crear un trabajo GFS para que las copias semanales “full” o mensuales o anuales se suban al cloud.
Sin embargo, si quiero subir una tarea de copia semanal increméntal sin que haya copias sintéticas intermedias, es decir, con cadena abierta, ¿que puedo hacer?
El escenario es que si tengo un datacenter con máquinas con uso de disco de 200GB, si empleo el Capacity tier, cada semana voy a subir 200GB si tengo que cerrar la cadena (y esto según leo es haciendo una copia full o sintética que ocupa mucho) con lo que en 1 año (es la retención que queremos en el cloud), los costes de S3 van a ser considerables, mayores a 10-12TB. Sin embargo, con políticas increméntales continuas que usamos en local, en un año con 2TB es suficiente.
Entiendo que si empleo el AWS Storage Gateway a nivel de archivo, puedo subir cadenas no cerradas al actuar como un mero recurso de red que se sincroniza mediante el gateway con AWS. ¿Es correcto?
En el caso de cintas VTL, no me queda claro si también tienen que ser cadenas cerradas o puedo ir escribiendo en la nube las copias increméntales.
¿Me podrías orientar?
Muchas gracias por tu trabajo. El mejor blog de Veeam que he encontrado es el tuyo.
Saludos,
Por ahora no hay manera de subir incrementales solo. Capacity Tier usa un modo de partir los ficheros como hace con ReFS, tengo un excel para calcular, dime el total espacio de tus VMs y te digo mas o menos. Pero si tienes 200 GB, no vas a subir 200GB la proxima vez, solo los nuevos bloques. Puedes usar rps.dwin.me, y asegurarte que el check de ReFS está marcado para ver mas o menos el espacio, o te digo más la semana que viene
Buenas Jorge,
Las VM del clúster ocupan 360GB, de los cuales, utilizados realmente hay 125 GB (es el tamaño de la copia inicial). Pensaba que las copias sintéticas necesarias para cerrar la cadena activa tendrían como resultado la generación de otra full con otros consecuentes 125GB subidos a AWS…
Si no te he entendido mal, las futuras copias full o synthetic sólo ocuparían por los bloques nuevos, minimizando por tanto el espacio requerido en S3. ¿Es así?
De todas formas, como profesional de Veeam, ¿qué me recomendarías? Capacity Tier, el Storage Gateway con NFS (imagino que este sistema si me permitirá subir cadenas abiertas), o VTL con el Storage Gateway?
Gracias por tu tiempo.
Hola, muy util este articulo.
Dispongo de la versión 11 Bussines. Y esta no dispone de la opción TIER, con lo cual NO es posible usar AWS de forma fácil.
Y creo que Jorge debería puntualizar que sin la versión ENTERPRISE, ni la 10v4 ni la 11, no hacen copias a un bucket S3 de manera fácil.
Tambien perdí tiempo probando, en Amazon el producto “Veeam for AWS Free” me serviria, pero no ha sido a si. Solo veo que sirve para que tus EC2 u otros recursos hagan copias en amazon. Y/o descargar copias de AWS a tus servidores.
En mi caso adquirir la ENTREPRISE supone casi 2000€ de inversión. Para poder hacer almacenamiento TIER y no veo claro como VEEAM lo resuelve, creo que VEEAM va decidiendo qué ficheros antiguos rotar o llevar a S3. Si en VEEAM esto se viera claro o en su ayuda, no me hubiera importado hacer un upgrade. Pero no se puede hoy día tirar los €.
Genial el artículo de Jorge como todo el Blog.
He tenido que usar el AWS Gateway como se describe aquí, bajo VM, he tenido que entrar a esta especie d e Amazon Linux con el usuario admin y clave password, asignar IP y OJO, tenéis que asignar DNS y hacer el test de conectividad de RED, que eso me provocó frustración por que no lo cogia bien y el Gateway no salia a Internet. O bien usar DHCP.
Yo no he montado una máquina Linux intermedia (o eso me parece que han usado otros usuarios) y montado el recurso compartido que pasa a ofrecer el AWS Gateway.
Directamente en VEEAM le he dicho que es un recurso compartido, le he dado la ruta servidor_aws_gateway/nombre_recurso_compartido y he agregado el repositorio NFS y va genial.
Ya solo falta ver como van la tarificación en € con amazon. Jeje
Me gusta esta opción para tener copias de seguridad fuera y en zona europea.
Gracias Jorge por tu trabajo.