La tarea de configurar el cronjobs para sistemas operativos ESX de VMware no es muy diferente a los demás sistemas operativos Linux, pero en VMware ESXi por el contrario, hay que tener francamente en cuenta por que los cambios realizados no persisten cuando reiniciamos el sistema VMware.

Una vez tenemos descargado ghettoVCB de http://communities.vmware.com/docs/DOC-8760 , lo único que tenemos que hacer es un upload a un datastore de VMware en el que queramos alojar el script ghettoVCB.

Podemos acceder con Putty a la consola de nuestro sistema ESXi, desde aquí podréis ir a descargar directamente a la web oficial el programa Putty, A Free Telnet/SSH Client

Y algunos os preguntaréis ¿Cómo abrir el puerto ssh en VMware ESXi?, pues ahí está.

Ejecutamos Putty, y le ponemos la IP del host VMware donde vamos a conectarnos, usuario y contraseña.

Y vamos a suponer lo siguiente:

/vmfs/volumes/datastore2/backup

Será el sitio donde pondremos el script ghettoVCB y el archivo “machines” donde especificaremos las vm que queremos efectuar copia

/vmfs/volumes/datastore3/logs

Será el sitio donde pondremos los logs que genere el script de ghettoVCB

Vamos a programar cronjobs para ghettoVCB

Vamos a:

vi /var/spool/cron/crontabs/root

Y añadimos al final del archivo lo siguiente:

~ # 0 21 * * * /vmfs/volumes/datastore2/backup/ghettoVCB.sh -f /vmfs/volumes/datastore2/backup/machines > /vmfs/volumes/datastore3/logs/ghettoVCB-backup-$(date +\%s).log

Donde pone 21 le ponemos la hora a la que queramos hacer el backup.

Salimos grabando del comando vi con ESC y tecleamos

:wq!

Eliminaremos la anterior programación de CRONJOBS de la siguiente manera:

~ # kill $(cat /var/run/crond.pid)
~ # busybox crond

Y luego editaremos el rc.local y nos encontraremos lo siguiente (en verde) y le añadiremos (lo azul), ejecutando:

~ # vi /etc/rc.local

~ # cat /etc/rc.local
#! /bin/ash
export PATH=/sbin:/bin

#execute all service retgistered in /etc/rc.local.d
if [http:// -d /etc/rc.local.d |http:// -d /etc/rc.local.d ]; then
   for filename in `find /etc/rc.local.d/ | sort`
      do
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 21 * * * /vmfs/volumes/datastore2/backup/ghettoVCB.sh -f /vmfs/volumes/datastore2/backup/machines > /vmfs/volumes/datastore3/logs/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond


Salimos grabando del comando vi con ESC :wq!

Para asegurarnos que el CRONJOB se creará después de reiniciar físicamente el HOST ejecutaremos lo siguiente:

~ # /sbin/auto-backup.sh

Y nos aparecerá algo como esto que pongo más abajo en naranja

config implicitly loaded
local.tgz
etc/vmware/vmkiscsid/vmkiscsid.db
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/opt/vmware/vpxa/vpxa.cfg
etc/opt/vmware/vpxa/dasConfig.xml
etc/sysconfig/network
etc/vmware/hostd/authorization.xml
etc/vmware/hostd/hostsvc.xml
etc/vmware/hostd/pools.xml
etc/vmware/hostd/vmAutoStart.xml
etc/vmware/hostd/vmInventory.xml
etc/vmware/hostd/proxy.xml
etc/vmware/ssl/rui.crt
etc/vmware/ssl/rui.key
etc/vmware/vmkiscsid/initiatorname.iscsi
etc/vmware/vmkiscsid/iscsid.conf
etc/vmware/vmware.lic
etc/vmware/config
etc/vmware/dvsdata.db
etc/vmware/esx.conf
etc/vmware/license.cfg
etc/vmware/locker.conf
etc/vmware/snmp.xml
etc/group
etc/hosts
etc/inetd.conf
etc/rc.local
etc/chkconfig.db
etc/ntp.conf
etc/passwd
etc/random-seed
etc/resolv.conf
etc/shadow
etc/sfcb/repository/root/interop/cim_indicationfilter.idx
etc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx
etc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx
etc/sfcb/repository/root/interop/cim_indicationsubscription.idx
Binary files /etc/vmware/dvsdata.db and /tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db differ
config implicitly loaded
Saving current state in /bootbank
Clock updated.
Time: 20:40:36   Date: 08/14/2009   UTC


Y ya está configurado cronjobs para que cuando se reinicie nuestro host VMware ESXi, se puedan efectuar las copias de seguridad con el script ghettoVCB

Como programar tarea ghettoVCB en Cronjobs para VMware ESXi

Somos muchos los que utilizamos ghettoVCB por la patilla en productos ESX y ESXi de VMware, este maravilloso script que nos hace la vida tan cómoda, imagino que en todos los niveles, desde los que tenemos entornos virtualizados no muy complejos hasta los que ya no lo son tanto. Por otro lado también somos muchos los que hemos sufrido sus pequeñeces pero eso no tiene realmente gran importancia si lo comparamos con el tesón, motivación y sobre todo ganas de compartir su conocimiento técnico de William Lam para que podamos estar tranquilos con nuestras copias de seguridad de vm’s en VMware.

De verdad, nosotros personalmente, estamos muy agradecidos, por que si no fuera por gente como William Lam y en este caso ghettoVCB, la virtualización de entornos pequeñitos no sería posible ya que los costes de los programas de copias de seguridad para VMware son para pequeñas empresas prohibitibos. Por esto, queremos dar las gracias a William Lam por hacer de ghettoVCB más que un simple script de código.

Agradecimientos a William Lam por todo su trabajo en el Script de ghettoVCB

Esta sería otra manera de programar una copia de seguridad en ghettoVCB.sh con la aplicación Plink.exe. En los enlaces podemos pinchar para descargar este software. También podremos descargar el archivo template para que ghettoVCB.sh pueda llamar a las VMs que queremos efectuar copia de seguridad.

Primero de todo deberemos de habilitar el puerto 22 de ssh en nuestro ESXi.

Descargaremos este software y lo pondremos en una carpeta en nuestra máquina de Windows Lanzadera. Llamémosla “Lanzadera”

Configuraremos ghettoVCB.sh (destino de copia, que historial de copias queremos, etc) y prepararemos el archivo template como si estuviera puesto en un servidor ESXi.

Una vez está preparada desde el VI CLient(ESXi v3.5) o VSphere Client (ESXi v4.0) crearemos en algún datastore del servidor ESXi una carpeta que por ejemplo se llame “backup”, y subiremos el archivo ghettoVCB.sh y el archivo_template donde ya habremos puesto los nombres de las VMs virtuales a copiar.

Una vez subido los archivos al datastore, crearemos un archivo con extensión .bat en el equipo con Windows, que lo podremos llamar como queramos.

Y en su interior indicaremos los siguiente:

Sintaxi:

plink -ssh -pw nuestro_password  usuario_poder@ipservidor_esxi  /ruta_archivo.sh/archivo.sh

Ejemplo práctico:

plink -ssh -pw Pass root@172.26.0.250 /vmfs/volumes/datastore1/backup/ghettoVCB.sh

Donde Pass será nuestro password del root en el host ESXi.

Guardaremos el archivo.bat y lo podemos ejecutar, veremos que se lanza el Plink.exe y comienza a hacer la copia de seguridad con ghettoVCB

Y ya para rematarlo, podremos incluir en nuestro Programador de tareas el trabajo.

Y listo

 Programar una copia de seguridad de ghettoVCB.sh con Plink.exe

ghettoVCB.sh – alternativa gratuita para hacer copias de seguridad para la máquina virtual ESX (i) 3,5 y 4,0 +

Artículo sacado de http://communities.vmware.com/docs/DOC-8760 y traducido por Google Translator

VERSIÓN 47 Publicado

Creado en: Nov 17, 2008 7:04 PM por lamw — Última modificación: Nov 25, 2009 2:39 PM por lamw

Tabla de Contenidos:

• �
  • Descripción
  • Características
  • Requisitos
  • Configuración
  • Configuraciones
  • Uso
  • Ejemplo de ejecución de
    • Copia de seguridad de máquinas virtuales almacenadas en una lista de
    • Copia de seguridad de máquinas virtuales utilizando las diferentes políticas de copia de seguridad de
    • Modo de depuración de copia de seguridad
    • Dry Run Mode
  • Habilitar la compresión de las copias de seguridad
  • Restaurar copias de seguridad (ghettoVCB-restore.sh)
  • Cronjob FAQ
  • Preguntas frecuentes
  • Enlaces de interés
  • Change Log

Descripción:

Este script realiza copias de seguridad de las máquinas virtuales que residen en ESX (i) + 3.5/4.0 servidores utilizando una metodología similar a la VMware VCB herramienta. El script toma imágenes de las máquinas virtuales en vivo, apoya la VMDK maestro (s) y luego una vez finalizada, se elimina la instantánea hasta que la próxima copia de seguridad. La única salvedad es que utiliza los recursos disponibles para la consola de servicio del servidor ESX ejecutando las copias de seguridad en vez de seguir el método tradicional de descarga de copias de seguridad de la máquina virtual a través de un proxy de VCB.

Este script ha sido probado en 3.5/4.0 ESX y ESXi 3.5/4.0 y apoya a los medios de copia de seguridad siguientes: Almacenamiento local, SAN y NFS. El guión no es interactiva y puede ser configurado para funcionar a través de crontab. Actualmente, este script acepta un archivo de texto que enumera los nombres de pantalla de la máquina virtual (s) que deben ser respaldados. Además, se puede especificar una carpeta que contiene archivos de configuración en una base por VM para el control granular sobre políticas de backup.

Además, para los entornos de ESX que no tienen almacenes de datos persistentes NFS designadas para copias de seguridad, la secuencia de comandos ofrece la posibilidad de que se conecte automáticamente al servidor ESX a un NFS exportado carpeta y luego al término de copia de seguridad, desconecte del servidor ESX. La conexión se establece mediante la creación de un enlace de NFS almacén de datos que permite monolítico (o grosor) VMDK copias de seguridad en lugar de utilizar la habitual * nix comando mount que requiere romper los archivos en el formato VMDK 2gbsparse para copia de seguridad. Habilitación de este modo se explica por sí mismo y, evidentemente, será por lo que cuando la secuencia de comandos de edición (Nota: VM_BACKUP_VOLUME variable se ignora si ENABLE_NON_PERSISTENT_NFS = 1 ).

En su configuración actual, la secuencia de comandos permitirá un máximo de 3 copias de seguridad exclusivo de la máquina virtual antes de que pueda sobrescribir las copias de seguridad anteriores, lo que sin embargo, puede ser modificado para ajustarse a los procedimientos en caso necesario. Por favor, ser diligente en la ejecución del script en una prueba o ensayo medio ambiente antes de utilizarlo en la producción en vivo de máquinas virtuales, lo que las funciones de script y dentro de nuestro ambiente, pero existe la posibilidad de que no puede encajar bien en otros ambientes.

Características

• Soporte para disco VMDK múltiples (s) de copia de seguridad por VM
• Sólo VMDK válido (s) presentado a la máquina virtual será respaldado
• En línea una copia de seguridad de VM (s) de
• Posibilidad de apagar guestOS e iniciar el proceso de copia de seguridad y el poder en VM después con la opción de tiempo de espera hardpower
• Permitir espacios en VM (s) de la lista de copia de seguridad (no se recomienda y no como una mejor práctica)
• Asegúrese de que proceso de eliminación instantánea completa antes de continuar en la próxima copia de seguridad de VM
• VM (s) que inicialmente contienen instantáneas no será una copia de seguridad y será ignorado
• La capacidad de especificar el número de rotaciones de copia de seguridad de VM
• Salida de copia de seguridad de VMDK (s) en cualquiera de ZEROEDTHICK (comportamiento por defecto) o 2GB escasa o THIN o EAGERZEROEDTHICK formato
• Soporte para discos SCSI e IDE
• No persistentes de copia de seguridad de NFS
• Apoyo plenamente VMDK (s) almacenados en almacenes de datos múltiples
• Capacidad de comprimir las copias de seguridad (soporte experimental)
• Capacidad de configurar las diferentes políticas de copia de seguridad VM ¡NUEVO!
• Posibilidad de incluir / excluir VMDK específico (s) por máquina virtual (VM instalación individual requiere la política de copia de seguridad) ¡NUEVO!
• Posibilidad de configurar el registro de salida a archivo ¡NUEVO!
• Conciencia de disco independiente (ignorará VMDK) ¡NUEVO!
• Las variables de tiempo de espera de nuevo para apagar y creaciones de instantáneas ¡NUEVO!
• Posibilidad de configurar las instantáneas con la memoria y / o inactividad opciones ¡NUEVO!
• Capacidad de disco de formato adaptador de configurar ¡NUEVO!
• De información de depuración adicional que incluye la ejecución en seco ¡NUEVO!
• Soporte para las máquinas virtuales con tanto virtuales / RDM física (pRDM serán ignoradas y no una copia de seguridad) ¡NUEVO!

Requisitos:

• Máquinas virtuales se ejecutan en ESX (i) + 3.5/4.0
• SSH para acceso a la consola ESX / ESXi de acogida

Instalación:

1) Descarga ghettoVCB.sh ya sea a su sistema de ESX o ESXi

2) Cambiar los permisos de la secuencia de comandos para asegurarse de que puede ser ejecutado:

[root @ Himalaya ~] # chmod + x ghettoVCB.sh

Configuraciones:

Las siguientes variables deben ser definidas en el script o en la política de VM de copia de seguridad antes de la ejecución.

Definir el almacén de datos de copia de seguridad y la carpeta en la que se almacenan las copias de seguridad (si la carpeta no existe, se creará automáticamente): = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS

Definir el formato de disco de copia de seguridad (zeroedthick, eagerzeroedthick, delgado, y 2gbsparse están disponibles):
DISK_BACKUP_FORMAT = delgada

Definición de la rotación de copia de seguridad por VM:
VM_BACKUP_ROTATION_COUNT = 3

Definir si la VM está apagado o no antes de la copia de seguridad (1 = activar, 0 = desactivado):

Nota: VM (s) que están apagados no requerirá snapshoting
POWER_VM_DOWN_BEFORE_BACKUP = 0

Definir si la máquina virtual puede ser difícil de apagado cuando “POWER_VM_DOWN_BEFORE_BACKUP” está habilitada y VM no se han instalado las herramientas de VMware
ENABLE_HARD_POWER_OFF = 0

Si “ENABLE_HARD_POWER_OFF” está habilitado, entonces se define el número de (60 segundos) iteraciones de la secuencia de comandos antes de que la ejecución de un poder de desactivación cuando:
ITER_TO_WAIT_SHUTDOWN = 3

El número (60 segundos) iteraciones de la secuencia de comandos esperar cuando apagar la máquina virtual y le dará e ignoran la máquina virtual de particular para copia de seguridad:
POWER_DOWN_TIMEOUT = 5

El número (60 segundos) iteraciones de la secuencia de comandos esperar la hora de tomar una instantánea de una máquina virtual y le dará e ignoran la máquina virtual de particular para copia de seguridad:

El valor por defecto debería ser suficiente
SNAPSHOT_TIMEOUT = 15

Definir si debe o no habilitar la compresión (1 = activar, 0 = desactivado):
ENABLE_COMPRESSION = 0

Definir el tipo de adaptador para copia de seguridad de VMDK (BusLogic y lsilogic están disponibles):
ADAPTER_FORMAT = BusLogic

Definir si la memoria de la máquina virtual se quebró y si quiescing está habilitado (1 = activar, 0 = desactivado):

Nota: Por defecto, ambos son personas de movilidad reducida
VM_SNAPSHOT_MEMORY = 0 VM_SNAPSHOT_QUIESCE = 0

* Definición de VMDK (s) de copia de seguridad de una máquina virtual particular, ya sea una lista de vmdks o “todos”
VMDK_FILES_TO_BACKUP = "myvmdk.vmdk"

Asegúrese de que usted no edita pasado esta sección:
########################## NO MODIFIQUE EL PASADO DE ESTA LÍNEA ################## ########

Uso:

[root @ Himalaya ~] #. / ghettoVCB.sh ################################################## ############################# # GhettoVCB # para ESX / ESXi 3.5 y 4.x + # Autor: William Lam # Http://www.engineering.ucsb.edu/ ~ / duonglt vmware / # Creado: 11/17/2008 # Última modificación: 11/14/2009 # ################################################## ############################# Uso:. / GhettoVCB.sh-f [VM_BACKUP_UP_LIST]-c [VM_CONFIG_DIR]-l [log_file] OPCIONES:    -F Lista de máquinas virtuales para copia de seguridad    -c directorio de configuración de copias de seguridad de VM    -L a la salida del archivo de registro    el nivel de depuración-d [info | | depuración dryrun] (por defecto: info) (por ejemplo) Copia de seguridad de máquinas virtuales almacenadas en una lista de         . / ghettoVCB.sh-f vms_to_backup Copia de seguridad de máquinas virtuales basadas en la configuración específica situada en el directorio de         . / ghettoVCB.sh vms_to_backup-f-c vm_backup_configs Salida de registro en / tmp / ghettoVCB.log         . / ghettoVCB.sh vms_to_backup-f-l / tmp / ghettoVCB.log Marcha en seco (no copia de seguridad se llevará a cabo)         . / f-ghettoVCB.sh vms_to_backup-d dryrun

La entrada a este script es un archivo que contiene el nombre de pantalla de la máquina virtual (s) separados por un salto de línea. Al crear este archivo en un sistema non-Linux/UNIX, puede introducir el carácter ^ M, que puede hacer que el script para miss-se comportan. Para garantizar que esto no ocurra, plesae crear el archivo en el ESX / ESXi de acogida.

Aquí está una muestra de lo que el archivo se vería así:

[root @ Himalaya ~] vms_to_backup # cat VCAP VIMA VMA-2

Ejemplo de ejecución:

• Copia de seguridad de máquinas virtuales almacenadas en una lista de
• Copia de seguridad de máquinas virtuales basadas en las diferentes políticas de copia de seguridad de VM
• Modo de depuración
• Dry Run Mode

Copia de seguridad de máquinas virtuales almacenadas en una lista de

• Verbosidad Log: info (por defecto)
• Salida de registro: stdout (por defecto)

[root @ Himalaya ~] #. / ghettoVCB.sh-f vms_to_backup 2009-11-12 06:14:10 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:14:10 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:14:10 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:14:10 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:14:10 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:14:10 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:14:10 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:14:10 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:14:10 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:14:10 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:14:10 - info: config - log_level = info 2009-11-12 06:14:10 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:14:10 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:14:10 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:14:10 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:14:15 - info: Iniciar la copia de seguridad para VCAP Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_1.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP-0.vmdk' ... Clon: 100% hecho. 2009-11-12 06:15:15 - Información: Duración de copia de seguridad: 60 segundos 2009-11-12 06:15:15 - info: copia de seguridad con éxito para VCAP! 2009-11-12 06:15:17 - info: Iniciar la copia de seguridad para VIMA 2009-11-12 06:15:17 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-12" para VIMA Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-12 06:16:40 - info: instantánea Eliminación de VIMA ... 2009-11-12 06:16:43 - Información: Duración de copia de seguridad: 1,43 minutos 2009-11-12 06:16:43 - info: copia de seguridad con éxito para VIMA! 2009-11-12 06:16:47 - info: Iniciar la copia de seguridad para VMA-2 Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-12 06:18:14 - Información: Duración de copia de seguridad: 1,45 minutos 2009-11-12 06:18:14 - info: copia de seguridad con éxito para VMA-2! 2009-11-12 06:18:14 - info: ============================== ghettoVCB LOG FIN === =============================

Copia de seguridad de máquinas virtuales basadas en las diferentes políticas de copia de seguridad de VM y registro de salida a / tmp / ghettoVCB.log

• Verbosidad Log: info (por defecto)
• Registra el resultado: / tmp / ghettoVCB.log (por defecto)

1. Crear carpeta para almacenar las diferentes políticas de VM de copia de seguridad (puede tener cualquier nombre):
[root @ Himalaya ~] # mkdir backup_config

2. Crear copia de seguridad de las diferentes políticas de máquina virtual para cada máquina virtual que asegurar que cada archivo se llama exactamente como el nombre de pantalla de la máquina virtual se copia de seguridad (uso de la plantilla proporcionada para crear duplicados “):
[root @ Himalaya backup_config] ghettoVCB # cp-vm_backup_configuration_template VCAP [root @ Himalaya backup_config] ghettoVCB # cp-vm_backup_configuration_template VIMA

Listado de la política de máquina virtual de directorio de configuración de copia de seguridad de copia de seguridad de
[root @ Himalaya backup_config] # ls ghettoVCB-vm_backup_configuration_template VCAP VIMA

La política de copia de seguridad de “VCAP” (copia de seguridad VMDKs sólo 2 específicos)
[root @ Himalaya backup_config] # cat VCAP = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS DISK_BACKUP_FORMAT = delgada VM_BACKUP_ROTATION_COUNT = 3 POWER_VM_DOWN_BEFORE_BACKUP = 0 ENABLE_HARD_POWER_OFF = 0 ITER_TO_WAIT_SHUTDOWN = 4 POWER_DOWN_TIMEOUT = 5 SNAPSHOT_TIMEOUT = 15 ENABLE_COMPRESSION = 0 ADAPTER_FORMAT = BusLogic VM_SNAPSHOT_MEMORY = 0 VM_SNAPSHOT_QUIESCE = 0 VMDK_FILES_TO_BACKUP = "VCAP.vmdk, VCAP_2.vmdk"

La política de copia de seguridad de VM “VIMA” (copia de seguridad de todos los VMDKs encontrados)
[root @ Himalaya backup_config] # cat VIMA = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS DISK_BACKUP_FORMAT = delgada VM_BACKUP_ROTATION_COUNT = 3 POWER_VM_DOWN_BEFORE_BACKUP = 0 ENABLE_HARD_POWER_OFF = 0 ITER_TO_WAIT_SHUTDOWN = 4 POWER_DOWN_TIMEOUT = 5 SNAPSHOT_TIMEOUT = 15 ENABLE_COMPRESSION = 0 ADAPTER_FORMAT = BusLogic VM_SNAPSHOT_MEMORY = 1 VM_SNAPSHOT_QUIESCE = 0 VMDK_FILES_TO_BACKUP = "todos"

Nota: Al especificar la opción-c (individual VM modo la política de copia de seguridad), si una máquina virtual aparece en la lista de copia de seguridad, pero NO tener una política de copia de seguridad correspondiente, la máquina virtual se complementará con la configuración predeterminada encuentra dentro de la secuencia de comandos ghettoVCB.sh.

Ejecución de copia de seguridad
[root @ Himalaya ~] #. / f-ghettoVCB.sh vms_to_backup-c backup_config-l / tmp / ghettoVCB.log Registro de salida a "/ tmp / ghettoVCB.log" ... Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho.

Nota: Al especificar la opción-l (registro de salida de archivo), vmkfstools copia también se registra la salida estándar. Esto se hace principalmente para fines de depuración.

Registro de salida de copia de seguridad de
[root @ Himalaya ~] # cat / tmp / ghettoVCB.log 2009-11-12 06:26:53 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:26:56 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-12 06:26:56 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:26:56 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:26:56 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:26:56 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:26:56 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:26:56 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:26:56 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:26:56 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:26:56 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:26:56 - info: config - log_level = info 2009-11-12 06:26:56 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:26:56 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:26:56 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:26:56 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-12 06:26:58 - info: Iniciar la copia de seguridad para VCAP Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. 2009-11-12 06:26:59 - Información: Duración de copia de seguridad: 1 segundos 2009-11-12 06:26:59 - info: copia de seguridad con éxito para VCAP! 2009-11-12 06:26:59 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-12 06:26:59 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:26:59 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:26:59 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:26:59 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:26:59 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:26:59 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:26:59 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:26:59 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:26:59 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:26:59 - info: config - log_level = info 2009-11-12 06:26:59 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:26:59 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-12 06:26:59 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:26:59 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:27:02 - info: Iniciar la copia de seguridad para VIMA 2009-11-12 06:27:02 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-12" para VIMA Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-12 06:29:28 - info: instantánea Eliminación de VIMA ... 2009-11-12 06:29:31 - Información: Duración de copia de seguridad: 2,48 minutos 2009-11-12 06:29:31 - info: copia de seguridad con éxito para VIMA! 2009-11-12 06:29:31 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:29:31 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:29:31 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:29:31 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:29:31 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:29:31 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:29:31 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:29:31 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:29:31 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:29:31 - info: config - log_level = info 2009-11-12 06:29:31 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:29:31 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:29:31 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:29:31 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:29:35 - info: Iniciar la copia de seguridad para VMA-2 Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-12 06:31:05 - Información: Duración de copia de seguridad: 1,50 minutos 2009-11-12 06:31:05 - info: copia de seguridad con éxito para VMA-2! 2009-11-12 06:31:05 - info: ============================== ghettoVCB LOG FIN === =============================

El modo de depuración de copia de seguridad

• Verbosidad Log: depuración
• Salida de registro: stdout

[root @ Himalaya ~] #. / ghettoVCB.sh vms_to_backup-f-c-d backup_config depuración 2009-11-13 19:51:47 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-13 19:51:47 - debug: Build Host: VMware ESX 4.0.0 construir-164009 2009-11-13 19:51:47 - debug: HOSTNAME: himalaya.primp-industries.com 2009-11-13 19:51:51 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-13 19:51:51 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:51:51 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:51:51 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:51:51 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:51:51 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:51:51 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:51:51 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-13 19:51:51 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:51:51 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:51:51 - info: config - log_level = debug 2009-11-13 19:51:51 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:51:51 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-13 19:51:51 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:51:51 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-13 19:51:52 - info: Iniciar la copia de seguridad para VCAP 2009-11-13 19:51:52 - debug: findVMDK () - En busca de VMDK: "VCAP_2.vmdk" para copia de seguridad 2009-11-13 19:51:52 - debug: findVMDK () - Encontrado VMDK! - "VCAP_2.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP_1.vmdk" para copia de seguridad 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP.vmdk" para copia de seguridad 2009-11-13 19:51:53 - debug: findVMDK () - Encontrado VMDK! - "VCAP.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP-0.vmdk" para copia de seguridad 2009-11-13 19:51:54 - Información: Duración de copia de seguridad: 2 segundos 2009-11-13 19:51:54 - info: copia de seguridad con éxito para VCAP! 2009-11-13 19:51:54 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-13 19:51:54 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:51:54 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:51:54 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:51:54 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:51:54 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:51:54 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:51:54 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-13 19:51:54 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:51:54 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:51:54 - info: config - log_level = debug 2009-11-13 19:51:54 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:51:54 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-13 19:51:54 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:51:54 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-13 19:51:56 - info: Iniciar la copia de seguridad para VIMA 2009-11-13 19:51:56 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-13" para VIMA 2009-11-13 19:51:58 - debug: Lugar para ghettoVCB instantánea "instantánea-2009-11-13" que se cree 2009-11-13 19:51:58 - debug: tiempo de espera de instantáneas establece en: 900 segundos 2009-11-13 19:52:01 - debug: Lugar para la creación de instantáneas para ser completada - Iteración: 0 - dormir para 60secs (Duración: 0 segundos) 2009-11-13 19:53:03 - debug: findVMDK () - En busca de VMDK: "VIMA.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-13 19:54:27 - info: instantánea Eliminación de VIMA ... 2009-11-13 19:54:32 - Información: Duración de copia de seguridad: 2,60 minutos 2009-11-13 19:54:32 - info: copia de seguridad con éxito para VIMA! 2009-11-13 19:54:32 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:54:32 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:54:32 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:54:32 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:54:32 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:54:32 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:54:32 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-13 19:54:32 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:54:32 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:54:32 - info: config - log_level = debug 2009-11-13 19:54:32 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:54:32 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-13 19:54:32 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:54:32 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-13 19:54:35 - info: Iniciar la copia de seguridad para VMA-2 2009-11-13 19:54:35 - debug: findVMDK () - En busca de VMDK: "VMA-2.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-13 19:56:10 - Información: Duración de copia de seguridad: 1,58 minutos 2009-11-13 19:56:10 - info: copia de seguridad con éxito para VMA-2! 2009-11-13 19:56:10 - info: ============================== ghettoVCB LOG FIN === =============================

Dry Run Mode (no copia de seguridad se llevará a cabo)

• Verbosidad Log: drymode
• Salida de registro: stdout

[root @ Himalaya ~] #. / ghettoVCB.sh vms_to_backup-f-c-d backup_config dryrun 2009-11-12 06:32:57 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:33:01 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VCAP 2009-11-12 06:33:01 - dryrun: VM_ID: 2784 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP 2009-11-12 06:33:01 - dryrun: VMX_CONF: VCAP / VCAP.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SATA.RE4 GP: Almacenamiento 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:01 - dryrun: VCAP_2.vmdk 2009-11-12 06:33:01 - dryrun: VCAP_1.vmdk 2009-11-12 06:33:01 - dryrun: VCAP.vmdk 2009-11-12 06:33:01 - dryrun: VCAP-0.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VIMA 2009-11-12 06:33:01 - dryrun: VM_ID: 4064 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA 2009-11-12 06:33:01 - dryrun: VMX_CONF: VIMA / VIMA.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SAS.Savvio 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:01 - dryrun: VIMA.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VMA-2 2009-11-12 06:33:01 - dryrun: VM_ID: 4960 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2 2009-11-12 06:33:01 - dryrun: VMX_CONF: vMA-2/vMA-2.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SAS.Constellation 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:02 - dryrun: VMA-2.vmdk 2009-11-12 06:33:02 - dryrun: #################################### ########### 2009-11-12 06:33:02 - info: ============================== ghettoVCB LOG FIN === =============================

Habilitar la compresión para copias de seguridad:

Para hacer uso de esta función, modificar la variable de ENABLE_COMPRESSION 0 a 1. Tenga en cuenta, no se mezclan con las copias de seguridad sin comprimir las copias de seguridad comprimido. Asegúrese de que los directorios seleccionados para copias de seguridad no contienen las copias de seguridad con las versiones anteriores de ghettoVCB antes de habilitar y aplicar la función de copias de seguridad comprimidas.

Restaurar copias de seguridad (ghettoVCB-restore.sh):

Para recuperar una máquina virtual que ha sido procesado por ghettoVCB, por favor, eche un vistazo a este documento: Ghetto Tech Preview – ghettoVCB-restore.sh – Restauración de VM copia de seguridad desde ghettoVCB a ESX (i) 3,5 y 4,0 +

Cronjob Preguntas frecuentes:

Por favor tome un momento para leer sobre lo que es un “cronjob” y cómo crear uno, antes de continuar

La tarea de configurar cronjobs en el clásico servidores ESX (con Service Console) no es diferente de cronjobs tradicionales en los sistemas operativos * nix (este procedimiento se describe en el enlace anterior). Con ESXi Por otra parte, otros factores deben tenerse en cuenta al establecer cronjobs en el depósito limitada de la consola llamada Busybox porque los cambios realizados no pasan a través de un reinicio del sistema. El siguiente documento se resumen las medidas necesarias para garantizar que las configuraciones se guardan cronjob y presentar al momento de reiniciar el sistema.

Tarea: GhettoVCB.sh configurar para ejecutar una copia de seguridad de cinco días a la semana (lunes a viernes) a las 12AM (medianoche) todos los días y enviar el resultado a un archivo de registro único

Configurar en ESX:

1. Como root, usted instalar su cronjob mediante la emisión de:
[root @ Himalaya ~] # crontab-e

2. Añada la siguiente entrada:
0 0 * * 1-5 / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / ghettoVCB.sh / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / backuplist> / vmfs / volúmenes / dlgCore-NFS -bigboi.VM-Backups/ghettoVCB-backup- $ (date + \% s). log

3. Guardar y salir
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # crontab-e no crontab de root - usando una vacía crontab: crontab de instalar nuevos

4. Lista y verificar la cronjob que se acaba de crear:
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # crontab-l 0 0 * * 1-5 / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / ghettoVCB.sh / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / backuplist> / vmfs / volúmenes / dlgCore-NFS -bigboi.VM-Backups/ghettoVCB-backup- $ (date + \% s). log

Estás listo!

Configurar en ESXi:

1. Configuración de la cronjob añadiendo la siguiente línea a / var / spool / cron / crontab / root:

0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs/volumes/simplejack-local-storage/ghettoVCB-backup- $ (date + \% s). log

2. Matar a los crond actual (cron daemon) y luego reiniciar el crond para que los cambios surtan efecto:

El ESXi <3.5u3
kill $ (ps | grep crond | cut-f 1-d '')

El ESXi 3.5u3 +
~ # Kill $ (pidof crond) ~ # Crond

El ESXi 4.0
~ # Kill $ (/ cat var / run / crond.pid) ~ # Crond busybox

3. Ahora que el cronjob está listo para ir, usted necesita asegurarse de que este cronjob persistirá a través de un reinicio. Usted tendrá que añadir las dos líneas siguientes a la / etc / rc.local (asegurarse de que la entrada de cron coincide con lo que se ha definido anteriormente)

El ESXi 3.5
/ bin / kill $ (pidof crond) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root crond

El ESXi 4.0
/ bin / kill $ (/ cat var / run / crond.pid) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root / bin / busybox crond

Después, el archivo debe tener el siguiente aspecto:

~ # Cat / etc / rc.local #! / bin / ash export PATH = / sbin: / bin log () (    echo "$ 1"    init logger "$ 1" ) # ejecutar todos los servicios retgistered en / etc / rc.local.d si [http://-d / etc / rc.local.d | http://-d / etc / rc.local.d], y luego    el nombre de archivo para encontrar en `/ etc / rc.local.d / | ordenar`       hacer          if [-f $ fichero] & & [-x $ fichero]; a continuación,             registro "ejecutando $ fichero"             $ nombre_archivo          fi       hecho fi / bin / kill $ (/ cat var / run / crond.pid) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root / bin / busybox crond

Esto asegurará que el cronjob se vuelve a crear a un reinicio del sistema a través de un script de inicio

2. Para garantizar que esta se guarda en la configuración de ESXi, tenemos que iniciar manualmente una copia de seguridad ESXi ejecutando:
~ # / Sbin / auto-backup.sh configuración de carga implícitamente local.tgz / vmware etc / vmkiscsid / vmkiscsid.db etc / dropbear / dropbear_dss_host_key etc / dropbear / dropbear_rsa_host_key etc / opt / vmware / vpxa / vpxa.cfg etc / opt / vmware / vpxa / dasConfig.xml etc / sysconfig / network / vmware etc / hostD / authorization.xml / vmware etc / hostD / hostsvc.xml / vmware etc / hostD / pools.xml / vmware etc / hostD / vmAutoStart.xml / vmware etc / hostD / vmInventory.xml / vmware etc / hostD / proxy.xml / vmware etc / ssl / rui.crt / vmware etc / ssl / rui.key / vmware etc / vmkiscsid / initiatorname.iscsi / vmware etc / vmkiscsid / iscsid.conf etc / vmware / vmware.lic etc / vmware / config etc / vmware / dvsdata.db etc / vmware / esx.conf etc / vmware / license.cfg etc / vmware / locker.conf etc / vmware / snmp.xml etc / group etc / hosts etc / inetd.conf etc / rc.local etc / chkconfig.db etc / ntp.conf etc / passwd etc / random-seed etc / resolv.conf / etc / shadow etc / sfcb repositorio / root / interoperabilidad / cim_indicationfilter.idx etc / sfcb repositorio / root / interoperabilidad / cim_indicationhandlercimxml.idx etc / sfcb repositorio / root / interoperabilidad / cim_listenerdestinationcimxml.idx etc / sfcb repositorio / root / interoperabilidad / cim_indicationsubscription.idx Los archivos binarios / etc / vmware dvsdata.db y / tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db difieren configuración de carga implícitamente La economía del estado actual en / bootbank Reloj actualizada. Hora: 20:40:36 Fecha: 08/14/2009 UTC

Ahora usted está realmente listo!

Si sigues teniendo problemas para que el cronjob al trabajo, asegúrese de que haya especificado los parámetros correctos y no hay errores en el texto en cualquier parte de la sintaxis.

Asegúrese crond (demonio cron) se está ejecutando:

ESX:

[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # ps-ef | grep crond | grep-v grep 2625 1 0 raíz Ago13? 00:00:00 crond

ESXi:
~ # Ps | grep crond | grep-v grep 5196 5196 busybox crond

Asegúrese de que la fecha y hora de alojar su ESX (i) está configurado correctamente:

ESX (I):
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] Fecha # Vie Ago 14 23:44:47 PDT 2009

Nota: La atención cuidadosa debe tenerse en cuenta si más de una copia de seguridad se realiza por día. Ventanas de copia de seguridad debe ser escalonada para evitar la afirmación o la saturación de los recursos durante estos períodos.

Preguntas frecuentes:

1T: Soy X error al obtener al utilizar la secuencia de comandos o no estoy recibiendo ningún error, la copia de seguridad ni siquiera tienen lugar. ¡Oh, qué podría estar mal?
1A: Sírvase proporcionar toda la producción de una ejecución manual (modo de depuración y dryrun) o si está iniciando sesión en la salida \ (código \) etiquetas, una breve descripción de su entorno y el tipo de máquina virtual (s) que está tratando de copia de seguridad voy a tratar de brindar alguna ayuda.

2Q: Te he enviado mensajes privados o correo electrónico, pero no he recibido una respuesta? ¿Qué pasa?
2A: No acepto temas / bugs reportados a través de AM o por correo electrónico, voy a responder de nuevo, te permite acceder a publicar en el foro VMTN adecuada (que es lo que es para). Si los datos y resultados que usted está proporcionando es verdaderamente Senstive a su entorno de yo te escucharé, pero el 99,99% no lo está, así que por favor no messsage / correo electrónico directamente. Puedo hacer un seguimiento todos los foros que contienen mi script incluidos los foros VMTN normal y tratar de recuperar a su pregunta tan pronto como me sea posible y el tiempo lo permite. Por favor, sea paciente, no eres la única persona que utiliza el script (100.000 visitas), gracias.

3Q: ¿Puedo programar copias de seguridad que tendrá lugar cada hora, diario, mensual, anual?
3A: Sí, hacer una búsqueda en línea para crontab.

4T: Me gustaría cronjob de instalación de ESX (i) 3,5 o 4,0?
4A: Echa un vistazo a la sección de Preguntas Cronjob en este documento.

5Q: Quiero programar mi copia de seguridad en Windows, ¿cómo puedo hacer esto?
5A: Haga una búsqueda para plink. Asegúrese de que ha vinculado el programa de instalación de ssh entre su sistema Windows y ESX / ESXi de acogida.

6Q: Sólo tengo una gran ESXi único. Quiero realizar copias de seguridad y guardarlas en otro lugar. El problema es: no tengo NFS, iSCSI, ni FC SAN. ¿Qué puedo hacer?
6A: Usted puede utilizar el almacenamiento local para almacenar las copias de seguridad suponiendo que haya suficiente espacio en el almacén de datos de destino. Después, puede utilizar el programa scp (WinSCP / FastSCP) para transferir las copias de seguridad del host ESXi en el escritorio local.

7Q: Estoy furioso, la copia de seguridad está tomando demasiado tiempo. Mi almacén de datos es de tipo X?
7A: YMMV, eche un vistazo a la configuración de almacenamiento y asegurar que se ha optimizado.

8Q: Me di cuenta de que la rotación de copia de seguridad se produce después de una copia de seguridad. Yo no tengo suficiente espacio de almacenamiento local, se puede cambiar el proceso?
8A: Esto se hace para asegurar que usted tiene al menos una buena copia de seguridad en caso de que la nueva copia de seguridad falla. Si desea modificar la secuencia de comandos, es más que bienvenido a hacerlo.

9Q: ¿Cuál es la mejor configuración de almacenamiento de tipo X de almacén de datos?
9A: Los foros VMTN búsqueda, hay varias configuraciones para los diferentes tipos de almacenamiento, etc.

10Q: Quiero configurar un servidor NFS para ejecutar mis copias de seguridad. ¿Cuál es la mejor y debe ser virtual o físico?
10A: Por favor remitirse a la respuesta 7A. Por experiencia, hemos visto casos física de los servidores NFS para ser más rápido que sus contrapartes virtuales. Como siempre, tu caso es distinto.

11Q: He máquinas virtuales que se han instantáneas. Quiero de nuevo estas cosas, pero el guión no me deja hacerlo. ¿Cómo puedo solucionarlo?
11a: Instantáneas VM no están destinados a mantenerse por períodos largos. Cuando la copia de seguridad de una máquina virtual que contiene una instantánea, debe asegurarse de todas las instantáneas han sido cometidos antes de ejecutar una copia de seguridad. No se harán excepciones … nunca.

12Q: Me gustaría restaurar la copia de seguridad, ¿cuál es el mejor método?
12A: El proceso de restauración será único para cada entorno y debe ser determinado por la copia de seguridad o planes de recuperación. En un nivel superior tiene la opción de montar el almacén de datos de copia de seguridad y el registro de la máquina virtual en cuestión o una copia de la máquina virtual desde el almacén de datos de copia de seguridad a la ESX / ESXi de acogida. Este último se recomienda para que no se está ejecutando la vida VM en el almacén de datos de copia de seguridad o sin querer modificar su máquina virtual de copia de seguridad (s).

13Q: Cuando trato de ejecutar el script que recibe: “-bash:. / ghettoVCB.sh: Permission denied”, ¿Qué pasa?
13A: Es necesario cambiar el permiso en el guión sea ejecutable, chmod + x ghettoVCB.sh

14Q: ¿Dónde puedo descargar la última versión del guión?
14A: La última versión está disponible en esta página en la parte inferior.

15Q: Me gustaría sugerir / recomendar la característica X, ¿puedo conseguirlo? ¿Cuándo puedo conseguirlo? ¿Por qué no está aquí, ¿qué pasa?
15A: El objetivo general de este script es para proporcionar una solución de copia de seguridad en torno a máquinas virtuales VMware. Cualquier función adicional fuera de ese proceso se tendrán en cuenta en función de la cantidad de tiempo, el número de peticiones y la utilidad real en su conjunto a la comunidad más que a una persona.

16Q: ¿Cuáles son los diferentes tipos de copia de seguridad de los casos los usos que son compatibles con ghettoVCB?
16A: Live copia de seguridad 1) de la máquina virtual con el uso de una instantánea, y 2) de copias de seguridad de una máquina virtual sin una instantánea. Estos son los únicos dos casos de uso con el apoyo de la secuencia de comandos.

Enlaces de interés:

Detalle las instrucciones sobre cómo configurar / ghettoVCB programación en Windows (The Raj Perumal de Carreras Mundial sobre la Tecnología de blog):

Parte 1
Parte 2
Parte 3

Cambio de registro:

11/17/09 – Los siguientes mejoras y correcciones se han implementado en esta versión de ghettoVCB. Un especial agradecimiento a todos los probadores ghettoVCB BETA para proporcionar el tiempo y sus entornos para poner a prueba características y correcciones de la nueva secuencia de comandos!

Mejoras:

• Política de copia de seguridad individual VM
• Incluir / excluir VMDK específico (s)
• Registrar en archivo
• Las variables de tiempo de espera
• Memoria instantánea Configur / inactividad
• Adaptador de formato de
• Modo adicional de registro + dryrun
• Apoyo a la física / RDMS virtual

Correcciones:

• Disco independiente consciente

Adjuntos:

• ghettoVCB-vm_backup_configuration_template (380 bytes)
• ghettoVCB.sh (28,8 K)

 ghettoVCB.sh ESX(i) 3.5 y 4.0

 y que por esta razón no puede lanzar la copia ghettoVCB?

En algunas ocasiones nos puede pasar que al efectuar una copia de seguridad con ghettoVCB, no nos deje hacerla por que hay un SnapShot que anteriormente no se ha eliminado correctamente.

Tenemos una manera fácil de arreglarlo, y es eliminando el snapshot que generó ghettoVCB en VMware ESXi y volver a lanzar la copia.

¿Como se hace esto?

Pues muy sencillo.

Vamos a  VMware Infrastructure Client

 Pinchamos con el botón de la derecha sobre la máquina virtual que queramos gestionar los snapshots

Pinchamos sobre snapshot y luego sobre Snapshot Manager, nos sale una pantalla de gestión de snapshots, allí podremos borrar el snapshot que nos da fallo o todos los snapshots.

Una vez borrado es snapshot que nos da fallo, ya podemos correr la copia de seguridad con ghettoVCB.

Cómo eliminar un snapshot creado por ghettoVCB

He recibido una solicitud de como recuperar una máquina virtual de la copia de seguridad efectuada con ghettoVCB en otro datastore

Para recuperar una máquina virtual creada con ghettoVCB, simplemente tenemos que ir al VMware Infrastructure Client, pinchamos en Configuration, Storage, seleccionamos el Datastore en el que tenemos ubicado la copia de seguridad, y sobre el archivo vmx le damos con el botón de la derecha, y el primer item que nos sale es “Add to Inventory“, pinchamos aquí, y nos pedirá que nombre le queremos dar a la máquina, se lo damos y nos aparecerá la máquina en nuestro repositorio de máquinas virtuales. Ya podemos lanzar la máquina desde el Infrastructure.

Adjunto una imagen que vale más que todo el rollo de antes

Salvados por ghettoVCB

Recuperar Maquina Virtual creada con ghettoVCB

Backup en ESXi con Cron Persistente. 

• Creamos una carpeta llamada VMBACKUP en nuestro datastore por ejemplo el Datastore1.
• En esta carpeta copiamos el script ghettoVCB.sh (http://communities.vmware.com/docs/DOC-8760).
• Creamos el un archivo llamado VMBACKUP en el que incluimos el nombre de nuestras maquinas virtuales a copiar.
• Creamos un script propio llamado por ejemplo EsxBackup.sh que unicamente ha de lanzar el comando “./ghettoVCB.sh VMBACKUP” 
• Comprobamos que nuestro backup funciona ejecutandolo manualmente y  proseguimos: 
• Editamos el archivo  /etc/rc.local
• Añadimos las siguientes lineas:

• /bin/echo “0 4 * * * /vmfs/volumes/Datastore1/EsxBackup.sh” >> /var/spool/cron/crontabs/root
• /bin/busybox crond -b

• Ejecutamos auto-backup.sh esto copia nuestras modificaciones.
• Ejecutamos  /bin/busybox crond –b.
• Reiniciamos nuestro ESXi.

Comprobamos que ya tenemos nuestra linea de backup en la ruta /var/spool/cron/crontabs/root.

Y todo listo, ya están programadas nuestras copias con ghettoVCB

Cron Persistente en ESXi VMware

Hay que hacer mención de esta gran utilidad gratuita que nos brinda William Lan, con la cuál podemos efectuar backups de nuestras máquinas virtuales tanto en ESX 3.x como ESXi 3.x, y ahora ESX 4.0 sin tener que apagar la/las máquinas virtuales. Podemos efectuarlas sobre datastores que tengamos físicamente pinchados en el mismo equipo, también sobre cualquier  NAS de nuestra red.

Vamos allá. Primero descargamos ghettoVCB.sh

Lo ponemos en cualquier datastore tal y como se muestra en la imagen, el ponerlo en un datastore es para que cuando se tenga que reiniciar el servidor físico ESX i no se borre.

Vamos a hechar un vistazo al contenido del archivo ghettoVCB 

Editamos el archivo con el comando vi, y podemos parametrizar donde y cuando queremos hacer los backups con ghettoVCB

En nuestro caso, hemos hecho las pruebas lanzando el backup contra otro datastore que está en la misma máquina física, que lo hemos llamado datastore2 dentro de  un directorio creado que se llama copias.

En la linea de VM_BACKUP_VOLUME=/vmfs/volumes/datastore2/copias/ le indicamos en que datastore y directorio queremos efectuar la copia de seguridad.

En la linea de VM_BACKUP_ROTATION_COUNT=4  le indicaremos la rotación de las copias, es decir, cuando lleve 4 copias, creará la 5ª copia y una vez efectuado el backup borrará la más antigua, por lo que siempre tendremos las últimas 4 copias de seguridad.

Hemos de crear un archivo sin extension al cual le podemos poner el nombre que queramos,  y que contendrá los nombres de las máquinas virtuales que queremos copiar, tal y como mostramos en la imagen inferior.

Editamos el archivo con vi y veremos el contenido

Donde WIN2008 es la máquina virtual que queremos copiar, si hubieran más máquinas a querer copia con ghettoVCB, simplemente añadiremos el nombre de la máquina debajo de la primera y así sucesivamente.

Tenemos que dar permisos de ejecución al archivo ghettoVCB.sh, y lo haremos de la siguiente manera:

chmod +x ghettoVCB.sh

Ejecución del backup:

./ghettoVCB.sh [nombre_de_archivo_sin _extensión]

./ghettoVCB.sh win

En los siguientes enlaces: 

Cómo recuperar una maquina virtual creada por ghettoVCB:

http://www.xarcom.net/blog/index.php/recuperar-maquina-virtual-creada-con-ghettovcb/

Redimensionar discos virtuales VMware ESXi

http://www.xarcom.net/blog/index.php/reducir-el-tamano-de-una-particion-vmware/

Eliminar un snapshot de VMware Infrastructure Client

http://www.xarcom.net/blog/index.php/eliminiar-snapshot-de-vmware-esxi-por-ghettovcb/

Nos vemos

Efectuar backup con ghetthoVCB