Hola, Este paso curioso me llegó, dado que un amigo me pidió ayuda con un tema, un servidor, el cual necesita una copia del mismo para hacer una auditoría, solo de las unidades de disco.
Lo primero que me vino a la cabeza fue, restaurar la vm desde un backup, y ya de ahí coger los vmdks pertinentes y hacer lo que sea.
De ahí, otra idea, si es un servidor virtual, restaurar los ficheros de vm, no el contenido, no? Este parece ser el paso más sencillo y adecuado, siendo una vm.
Pero luego, dándole vueltas, caí en la cuenta, y si es físico? cómo podríamos hacerlo? Por qué no mejor coger y pedirle a veeam directamente los vmdks?
Veeam no solo nos «convierte» o «entrega vmdks (vmware), sino también puede ser vhd (Hyper-V o Azure) o vhdx (Hyper-V).
Vamos a verlo con unos sencillos pantallazos, por si a más de uno le puede ser útil:
Hola, en un post anterior vimos la funcionalidad Backup Move en VBR 12, una maravilla.
Ahora bien, me he encontrado con un pequeño error, el cual no me permitía mover los backups de un repo a otro, en concreto, de un repo local a un repo S3 en Wasabi (immutable).
Tal y como podemos leer en el error, se trata de nuestra configuración de la tarea, la cual tiene puesto un Synthetic Full los sábados, y no le ha gustado nada.
Lo cambiamos a Active full, realizamos un Full, y ya nos permitirá hacer el cambio de Repo.
Pequeño detalle a tener en cuenta a la hora de querer hacer nuestros movimientos. Ojo con el espacio disponible, ya que un Active Full ocupa, y según tengamos nuestros recursos disponibles, podemos tener problemas.
Detalle también a tener en cuenta a la hora de crear nuestras tareas en el inicio, si prevemos que haremos este tipo de movimientos, conviene tenerlo preparado.
En esta ocasión vamos a ver, en sencillos pasos, como configurar una tera de Copy Job de una maquina virtual de nuestro entorno, a otro datastore, bien de un VBR ó de un servidor ESXi que tengamos registrado en nuestro VBR Server.
No lo confundamos con un Backup Copy Job, que es algo totalmente diferente, Esta tarea está enfocada en copiar los archivos de la maquina, no los backups o resultados.
No veo muy implementada o nombrada esta funcionalidad, yo la he empleado para hacer copias de maquinas virtuales, directamente al destino donde las quería tener, con un mecanismo de control, «garantizando» que la copia se había realizado correctamente, o para casos que queremos tener dicha copia, de ultima frontera, dado que el destino es un ESXi y se puede «registrar» la vm rápidamente y encenderla.
Como último detalle, decir que es un Copy, por tanto, no mantiene registro de diferentes ejecuciones, sino que tendremos disponibles los archivos de la última copia OK ejecutada.
Vamos a ver los pantallazos y el ejemplo:
Ahora vemos la otra opción, como destino, un repositorio de Veeam, en este caso, el Local repo de nuestro VBR Server
Como habéis visto, una manera muy efectiva de copiar una vm para luego hacer diferentes cosas con ella, registrarla en un ESXi, tener los archivos en un repositorio o servidor, o para mover una maquina virtual de un host a otro, si no tenemos opción de HA, o de Réplicas, o simplemente mantener una copia de nuestra/s máquinas en un repositorio diferente, sin estar en formato vbr, sino directamente como vm de ESXi en este caso.
La entrada de hoy va dirigida a una funcionalidad que me encanta de Veeam B&R V12, Se trata de «Move Backup», el cual nos va a ayudar a mover nuestros backups de un repositorio a otro, de manera automática, modificando la tarea a la cual estaba asignado, sin ningún esfuerzo o problema.
Muy útil cuado debemos mover los backup debido a un cambio de almacenamiento, bien sea por ampliación, mantenimiento o cambio de modelo, sin perder nuestra cadena de backups o configuraciones, o tener ur crear una tarea nueva.
Vamos a ver unos pantallazos e intentaré descubrir el proceso, para que veáis las diferencias y utilidad.
Listo, como veis, ya no sale el backup listado en el repo en red, solamente en el nuevo destino y la tarea modificada por veeam, por tanto, sin cambios en cadenas de backup ni configuraciones!.
Ahora, volvemos a haver el move, para volver a tener los backups como al principio:
Listo!
Un proceso muy sencillo y útil, como hemos dicho antes, para hacer cambios de infraestructura de almacenamiento, reparaciones o migraciones.
Hi everyone! I wanted to write today about a tool that happily surprised me and now has made my life easier, related to VPN and connectivity, its called Tailscale
The main slogan says :
Secure remote access to shared resources
Tailscale connects your team’s devices and development environments for easy access to remote resources.
I’ll try to put it on my own words, in my use case, I’ve been using it at the beginning to connect to my Home Lab remotely from my house to my “Jump Station” over RDP, then, I started to use some advanced features:
VPN Access to a single client
VPN to Remote Site, to access other devices not capable to install the Client
Proxy / Traffic router when Im out of the house or in a untrusted network
Web central console for configurations, users creation and management.
Easy to use client for Linux, Windows, Android, OSX, iOS, etc.
The client is very neat, clean and easy to use, also the documentation is great! Im gong to post a few screenshots and will make a future entry with an example setup.
The “Free” version comes with great features to start using it, as I said, in my case, at my home lab,
One of the positive things for me, is that I dont need to setup a firewall + opening ports for connecting from / to my hose / homelab, the Iphone / Ipad client works “like a champ” and I can access all I need, and secure my traffic navigating from my home when needed.
En la entrada anterior, hemos visto cómo crear una réplica en Veeam B&R V12 Ahora, os enseñaré brevemente cómo podemos lanzar esa réplica a producción en caso de necesidad, y también comentaremos diferentes casos de uso.
Vamos!
Vamos a explicar brevemente las dos funciones que más utilizo Failover now -> Veeam ejecutará la réplica en el host que tenemos definido, modo de uso normal en caso de perdida, parada, etc de nuestra producción. Planned failover -> Realiza un apagado seguro del origen, y ejecuta la réplica, sin perdida de datos, sí con parada en el power off y power on. Se puede emplear para testar nuestras réplicas, o para ejecutar una maquina en otro host, si no se dispone de vMotion o similares.
En nuestro ejemplo, vamos a simular una «caída» de producción, por tanto, Failover now… y seguimos.
Estas últimas opciones, tras tener la máquina corriendo en réplica, son: Permanent failover: la réplica se quedará como vm siempre Undo failover, se quitan todos los cambios en la réplica, y se apaga. Failback to production: los cambios realizados en la vm réplica, se pasan a la vm de producción, y se apaga la réplica, para arrancar la «original!».
Estos casos son, si perdimos el almacenamiento o la maquina origen, será mejor un Permanent Failover, pero si lo que perdimos fue conectividad a nuestra cabina, al volver a tenerla, podemos hacer un Failback to production, que se lleve los cambios, y seguiremos como siempre.
Ejecutamos nuestro Failback to production, para volver las cosas a como estaban, con los cambios producidos en la réplica, pasando todo a producción y seguimos trabajando como antes.
Como paso final, tras el cambio de la replica a producción, debemos hacer un Commit, para que finalice el proceso, se vuelquen todos los datos, y volvamos al status de maquina en prod, y réplica de la misma.
Acompáñanos en esta sesión de la mano de Jose Maria, Señor Systems Engineer en Veeam, en la cual hablaremos principalmente en cómo proteger nuestras cargas de trabajo en Kubernetes con Kasten 10, Así como una breve introducción a la comunidad, DEMO!
Una gran característica incluida en Veeam Backup & Replication es la posibilidad que tenemos de hacer réplicas, es decir, copias de nuestras máquinas virtuales en el estado cuando se hizo, preparada para ser arrancada cuando la necesitemos.
Es una gran función, tanto para seguridad, como para recuperación ante desastres y pruebas en nuestras máquinas.
En esta pequeña entrada nos vamos a centrar en la creación de la tarea de réplica.
Comenzamos:
Como veis, como es una copia de una vm, debe estar asociada a todo esto para poder encenderse.
Como comentario final, decirte que, aunque las réplicas son «buenísimas» e increméntales, no debemos nunca confundirlas con un backup.
Para mi, una réplica es una protección ante desastres, y un aliado a la hora de migrar / procesar vms en un entorno virtualizado.