© Josep Ros. Con la tecnología de Blogger.

Backup en ESXi

Mi querido amigo Aitor Enzunza me mandó hace unas semanas este impagable correo con una propuesta de backup para ESXi. Gracias crack! eres una pasada de tio, lástima que yo sea tan puñeteramente hetero :-)

Egunon,

Bujcando, bujcando he dado con este excelente hilo en el que se discute como hacer backups de máquinas en ESXi a través de scripts. Es bastante largo y complicado de leer, pero como yo ahora mismo tengo tiempo con mi pata chula pues me he hecho un intensivo. Me gustaría compartirlo contigo porque me parece interesante y además te va a ahorrar unas cuantas horas de lectura.

http://communities.vmware.com/thread/164134?tstart=0&start=0

El nombre es un poco engañoso porque, aunque inicialmente era para backup de esxi a güinflous, al final degenera en un montón de escenarios posibles.

Te adjunto en un fichero comprimido todos los scripts que ha colgado la gente en ese hilo pero ordenados, explicados y referenciados a los posts en los que aparecen. Hay alguno que no incluyo porque se menciona explicitamente en el foro que han ido quedando obsoletos.

Todos se basan en lo siguiente, para poder hacer backup de las vm estando encendidas (no obstante, con algunos scripts es posible apagar la vm antes de hacer el backup):

1.- Se copia el vmx
2.- Se hace un snapshot de la vm, con lo que se "libera" el disco para poder copiarlo, haciendo que la vm siga corriendo pero guarde los cambios en el snapshot)
3.- De una u otra manera se copian los vmdk
4.- Se deshace el snapshot

(El tema de copiar el vmx antes del snapshot es porque al hacer la instantanea, se cambia la referencia del disco en el vmx, con lo que si copiaramos el vmx despues del snapshot, estaría haciendo referencia a un disco que no vamos a copiar, el del snapshot precisamente. Esto, aunque no es una catastrofe, nos obligaria a editar el vmx antes de restaurar una de esas copias)

En principio son para copiar las vms de un datastore a otro de los que haya configurados en los hosts esxi, pero algunos scripts "se traen" los ficheros a local con scp

Los hay para llamarlos desde güinflous; los hay para llamarlos desde linux; y los hay para llamarlos desde el propio host esxi, lo que a priori parece una mamonada, pero no lo es tanto porque asi podemos hacer uso de los vmkfstools, que por lo visto dan mucho mejor rendimiento al copiar los vmdks. Además el uso de scp (es decir, una copia a través de ssh) desde el propio esxi tiene dos problemas: uno es la evidente sobrecarga tanto de la red como de la cpu en la transferencia de datos por hacerla cifrada y/o comprimida; la otra es el tener que copiar las claves permitidas en el host esxi (vamos, configurar el cliente ssh para
que pueda hacerse la copia automaticamente sin introducir credenciales en la consola), Lo mas complejo de esto ultimo es que al reiniciar el esxi se borran estos ficheros, con lo que hay que reimportarlos

Esto último tiene solucion, que consistiria en guardar en un datastore los ficheros de las claves permitidas y escribit un script en el esxi que le diga que importe esas claves en el arranque (en los rc iniciales). También hay quien sugiere comprimirlos y meterlos en el oem.tgz del esxi, en vez de en red, y aplicar el mismo procedimiento de cargarlos en el inicio. Personalmente creo que es mucho lio para poca o ninguna ganancia, habiendo soluciones mejores, para la transferencia, I
mean.

Como conclusiones que he sacado yo personalmente, decir que:

1) Al escribir de esxi a nfs el rendimiento en la transferencia de datos debe ser bastante malo (de ahí que algunos de los scripts escribam en un datastore local al esxi primero y lo transfieran en trocitos de 2GB después al datastore nfs). Aparentemente esto se soluciona con el flag de async activado en el export de la unidad nfs.

2) Si lanzamos cualquiera de los scripts escritos para ejecutarse en el propio esxi desde una máquina central a través de un cliente ssh (en güinflows podeis usar plink, por ejemplo), podemos gestionar las labores de backup todas desde el mismo sitio (un servidor de backup), lo que reduce el esfuerzo (tiempo y organizacion) que hay que dedicar para asegurarse de que tenemos todos los backups bien configurados. Evidentemente podemos programar el lanzamiento de los backups (con cron o con las tareas programadas, por ejemplo) para hacerlos diariamente, semanalmente o cuando mas nos plazca.

3) El hecho de lanzarlo desde un sitio central hacia todos los esxi reparte el trabajo de backup en los host (es algo asi como un sistema de backup centralizado/distribuido, cen-dis) con las ventajas e inconvenientes que eso supone.

4) Otra ventaja de este planteamiento cen-dis, es que si hubiera un problema de comunicaciones en determinado momeno entre el jefe y los hosts, no se vería afectada la tarea de bakup, porque se está ejecutando de forma distribuida, es decir, ya lo he lanzado y ahora me olvido hasta que me notifique que ha terminado.

5) Comentar que para el caso de lanzar los scripts a través de ssh desde una maquina central, en alguno de los datastores del esxi (el de backup mismo) tenemos que tener accesibles los scripts que queramos ejecutar para que los host los puedan "coger" (realmente lo ven como un fichero más dentro de su estructura de carpetas y no saben donde está).

6) Da la sensación por lo leído y lo estudiado de las tripas de los scripts que el mas completo de ellos es el ghettoVCB (vamos el vcb cutre :D ), que sería del tipo "lo lanzo en el propio host esxi". Permite parametrizar bastantes cosillas tal cual lo tiene escrito el autor.

7) Para el caso de los scripts que implementan algún método de compresión tras la copia (gzip, por ejemplo, en el caso de los scripts para linux), decir que sólo tiene sentido en el caso de que la máquina que ejecuta el script (y por consiguiente la rutina de compresión) almacene localmente los ficheros de backup. Y digo localmente, no digo una maquina virtual que no sabemos donde vive exactamente en nuestras cabinas u openfilers o lo que sea; en el caso de máquinas virtuales, tenemos que saber a ciencia cierta que el almacenamiento es local y no san o nfs o whatever. El porqué de esto, es que si los backups están almacenados en algún sitio en la red, me tengo que traer los ficheros por la red, los tengo que comprimir y luego los tengo que escribir comprimidos otra vez en red (esto, además del primer viaje que han hecho los ficheros desde los hosts hasta la san). Evidentemente, asi a botepronto, esto triplicaría la ventana de backup (y no siempre podemos permitírnoslo, no?).

8) Como todo tiene pegas, no se puede tener snapshot previos para utilizar estos metodos. Algunos scripts fallarian, otros se saltan esas vm... Anyway, hay quien recomienda no tener un snapshot mas de unas horas, dicen que es una mala práctica... I don't know, tu que opinas?

Y aquí la URL donde están los scripts:

http://www.4shared.com/file/109566863/6da06dcb/backup_esxitar.html

Un besi
tor

12 comentarios:

Anónimo dijo...

Grande! Si pones el fichero con los scripts ordenados entonces ya... para el nobel.

Anónimo dijo...

"Te adjunto en un fichero comprimido todos los scripts que ha colgado la gente en ese hilo pero ordenados, explicados y referenciados a los posts en los que aparecen".
Si los gorrones como yo pudieramos tener acceso al susodicho fichero te estaríamos eternamente agradecidos, hasta me haría follower tipo Edans ...

tor dijo...

Por aclamación anonimar:

http://www.4shared.com/file/109566863/6da06dcb/backup_esxitar.html

Hala, que sus aproveche ;)

Un besi,

tor

Lukz dijo...

Hola capo, mi nombre es Lucas.
Hace rato descubrí tu blog, y no me canso de leer y leer sobre virtualización.

Y, como a todos, me llegó la hora de probar :-)

Instalé en uno de mis servidores, un ESX 3.5 U4 Free, para probarlo como alternativa al típico (en mi empresa) Windows 2003 Server + VMware 2.0 Server + robocopy.

Al instalar el ESX free, ya me ahorré el windows 2003 host. Pero me las estoy viendo feas con los asuntos de backup.

Principalmente tengo 2 preguntas:

1) En muchos de tus post hablas de usar la herramienta de Symantec para realizar copias en caliente. No llegué a entender si la copia en caliente la corres desde el SO Host o del cliente (o sea, copiando el .vmdk o la unidad virtual desde adentro?)

2)Existe alguna forma de migrar esto a los ESXi? O sea, puedo llegar a hacer una copia en caliente desde los OS Guest, pero puedo hacer una copia en frío?

Me interesan mucho las copias en frio (1 vez al mes) por que tengo virtualizados varios servidores SQL y estos tienen mucho uso continuo.

Josep Ros dijo...

Hola Lucas,

Para hacer backup de ESXi free la cosa está jodida porque Veeam Backup ya no se vende para ese producto :-(

Léete el artículo que escribí sobre el tema:

http://josepros.blogspot.com/2009/08/vmware-esxi-free-y-veeam-backup.html

El backup Exec System Recovery se instala en el Windows anfitrión y hace copia de todos los guest pero claro, esto sólo es válido en Windows + VMware Server y no en Linux + VMware Server ni tampoco en ESXi.

Mi consejo es que o bien vayamos a Windows + Server + BESR o bien que se adquiera el Bundle de vSphere Essentials que vale unos 770€ + el Veeam Backup.

Saludos y gracias por leer mi blog!

Lukz dijo...

Lo leí, y te volví a preguntar con la esperanza de que conozcas otro tipo de solución... :-(

Pero, como mi edad me lo permite (20 años), soy bastante terco, y NECESITO encontrar una solución "rentable" a los backups bajo ESXi.

Encontré VRanger Pro, un soft que indica "compatibilidad con ESXi", todavía no lo llegué a probar.. vos sí?

Hoy estuve un poco trabado con otro tema, ¿cómo subir una .iso al datastore (lo tengo local en el ESXi, sobre un disco SATA)?
Supongo que es muy fácil, pero no pude dar con la tecla, o no investigué lo suficiente. Me podrías orientar por favor?


Muchas gracias por todo.
Un saludo, Lucas.

Josep Ros dijo...

Bueno, a falta de software de pago que haga backup de ESXi la solución de este post no está nada mal ¿no?

Para subir un archivo simplemente haces browse datastore en el disco y ya te aparecen dos botones de Upload y download, fácil!

Suerte con la solución del backup y ya comentarás algo, te lo agradeceré!

Saludos.

Pablo dijo...

hey! interesante post! tengo ganas de probar pero el link esta roto, existe la posibilidad de que lo puedas volver a subir?

saludos desde argentina

Josep Ros dijo...

Hola Pablo, lo he repasado y los dos links del artículos están activos.

Un abrazo!

Patxi dijo...

Buenas Josep!
Felicita a Aitor de mi parte. A mi me ha funcionado bien el ghettoVCB-enhance.
Eso si, he tenido que hacer algunos cambios en el script para que funcionase ;)

Un saludo y gracias por la recopilación!

tor dijo...

Jalonz,

Una cosilla, hace mucho que no uso 4shared asinque es posible que deje de funcionar el link donde están los scripts. Te paso otro link donde he subido el ficherito comprimido y es más probable que no deje de funcionar:

http://www.barracudanetworks.com/ns/products/backup_overview.php

Hala, un besi,

tor

tor dijo...

Buenax,

Estoy flipando. Acabo de mirar el link que te mandé para corregir el primero, y no sé que coño te he mandado...

El link donde está el comprimido con los scripts es el siguiente:

http://dl.dropbox.com/u/9152255/backup_esxi.tar.gz

Ahora sin. Un besi,

tor

Consulta Técnica

[Consulta Técnica][bleft]

Virtualización

[Virtualización][twocolumns]

Naturaleza

[Naturaleza][grids]