Actualización de ESX 4.0 a 4,0 U1 puede fallar o dar tiempo de espera agotado y dejar la máquina en un estado inservible si se utiliza HP Systems Insight Management Agent.

Para evitar esta cuestión antes de actualizar lea Artículo de la KB (ID 1016070).

ESX 4.0 Update 1 Error KB (ID 1016070)

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

Información extraída de la web de VMware. La información es una traducción automática. La siguiente tabla compara VMware ESX / ESXi 3.5 con el recientemente lanzado Microsoft Hyper-V y el hipervisor muestra cómo la tecnología Hyper-V se presentan importantes limitaciones en todos los aspectos críticos de un hipervisor:

Características	VMware ESX / ESXi 3.5	Microsoft Hyper-V RTM	Comparación hipervisores
Thin expresamente construida Arquitectura
Huella en el disco Pequeños			Hyper-V es totalmente dependiente de un SO de propósito general (Windows 2008). Mejor de Microsoft huella en el disco caso es 2.6GB (Hyper-V + Server Core), que es más de 80x veces más grande que ESXi’s (32MB). Hyper-V + Windows Server 2008 es aún mayor con una huella de aproximadamente 10 GB. El gran tamaño de ambas opciones se crea un blanco más fácil para los ataques a la seguridad y la sobrecarga de rendimiento cada vez mayor. Además, los parches para Windows Server 2008 / Server Core afectará a los clientes la tecnología Hyper-V.VMware ESXi en cambio es un hipervisor en pleno funcionamiento en la huella de un 32 MB de disco, lo que reduce el riesgo de tiempo de inactividad y aumenta la fiabilidad.
Independencia del sistema operativo			Hyper-V depende de Windows 2008 y, en consecuencia, favorecer a los clientes de Windows cuando se trata de hacer pleno uso de los recursos de hardware disponibles: Hyper-V apoyo a las operativos invitados de Windows se limita sólo a Novell SUSE Hyper-V apoyo a la 4-VSMP formas está limitada a Windows Server 2008. Para Windows 2003, Hyper-V sólo admite un máximo de 2-vías VSMP VMware ESX / ESXi está optimizado para la virtualización, ofrece la apoyo más amplio OS (5 versiones de Windows, 9 versiones de Linux, NetWare y Solaris) y permite que todos los sistemas operativos de apoyo a los resultados de manera óptima utilización de los recursos disponibles (4-VSMP forma está disponible en todos los sistemas operativos de servidor compatible)
Conductores endurecido			Windows 2008 es un sistema operativo de propósito general que se basa en los controladores de dispositivos genéricos construidas por terceros que no están diseñados para la virtualización. Este hecho aumenta drásticamente la probabilidad de problemas de rendimiento, el tiempo de inactividad relacionados con parches de conductor, y los fallos del sistema, a pesar de que los conductores pasar por el proceso de certificación de Microsoft. Los controladores de Windows ya pasar por la certificación de Microsoft hoy en día y todavía existen problemas de controladores.Por otra parte, VMware colabora estrechamente con IHV para probar y optimizar sus drivers para su uso con ESX / ESXi para garantizar, la fiabilidad y el rendimiento general cuando se ejecuta simultáneamente las cargas de trabajo virtualizadas.
Eficiencia de recursos
La gestión de memoria avanzada			La gestión de memoria del sistema es en la mayoría de los casos el factor dominante que determina el número de máquinas virtuales simultáneas que se pueden ejecutar en una máquina física. Hyper-V no puede cometer más de la memoria de acogida porque no es no es compatible con las características tales como la transparencia que comparten la memoria de página y globos de memoria para recuperar la memoria física de inactividad. En consecuencia Hyper-V ofrece una menor densidad de la máquina virtual, y la proporción de bajas en comparación con la consolidación de servidores VMware ESX / ESXi.VMware ESX / ESXi apoya plenamente overcommit de memoria, lo que permite altas tasas de densidad de VM al tiempo que ofrece un rendimiento consistente. Los clientes de VMware utiliza regularmente overcommit de memoria en sus centros de datos de producción a un ritmo de 1,5 X a 2,5 veces sin ningún tipo de impacto notable a los usuarios finales.
Gestión avanzada de almacenamiento			Hyper-V utiliza el sistema de archivos NTFS para el almacenamiento. NTFS no es un sistema de archivos en clúster. Por lo tanto, Hyper-V no ofrece soporte nativo para discos virtuales compartidos y la migración en vivo. Hyper-V de la falta de un sistema de archivos en clúster significa que con la migración rápida de Microsoft (basados en la agrupación de acogida) todas las máquinas virtuales en un LUN se migrará al mismo tiempo. Para evitar este resultado no deseado, el usuario debe asignar una VM por LUN, que crea una pesadilla de almacenamiento. La única otra opción es la compra de un tercero en el sistema de archivos en cluster de concesión de licencias adicionales y gastos de apoyo.VMware ESX / ESXi viene con VMFS, un sistema de archivos en clúster diseñado específicamente para la virtualización. VMFS apoya plenamente la migración en vivo, y permite a varias máquinas virtuales para compartir un único LUN y todavía emigran / conmutación por error de máquinas virtuales individuales.
Gestión avanzada de redes			Hyper-V no es compatible con NIC física nativo trabajo en equipo, en lugar que requiere de 3 controladores de hardware independientes (Intel, Broadcom). Esta limitación impide que Hyper-V de proporcionar fuera de la protección de la caja, independiente del hardware de un fallo de la NIC. Además, la tecnología Hyper-V para los conductores NIC apoyo no se virtualización consciente, no pueden ser controlados desde el hipervisor, y se deben cargar en la partición de los padres.VMware ESX / ESXi apoya plenamente NIC trabajo en equipo, resultando en una sencilla, completa de la solución de cuadro de conmutación por error de la NIC.
Performance Acceleration
Escalabilidad I / O			Hyper-V utiliza un “controlador indirecto” modelo que mantiene todos los controladores de dispositivo en una instancia de Windows 2008 almacena en la partición de los padres de Hyper-V y se basa en el sistema operativo de propósito general para manejar la E / S de tráfico. Este diseño de los cuellos de botella de E / S, como todo lo que resultados peticiones E / S debe viajar a través de Windows Server 2008 (o Server Core), que no está optimizado para la virtualización. El resultado es problemas de escalabilidad cuando se ejecuta muchas máquinas virtuales bajo carga. Este problema se limita la escalabilidad ratios de consolidación.VMware ESX / ESXi emplea un modelo de controlador directo con un planificador construyó específicamente para manejar las demandas de múltiples cargas de trabajo de alto. Esto da lugar a la escalabilidad de las relaciones más altas, mientras que la densidad de VM con la entrega consistente y de alto rendimiento.
Distributed Resource Allocation			Hyper-V carece de muchas capacidades para distribuir de manera óptima los recursos de hardware., Con base en tiempo real las condiciones de carga de trabajo. A diferencia de ESX / ESXi, Hyper-V no es compatible con: El tráfico de red para la configuración de equilibrio de carga Storage I / O se asegura de que el establecimiento de prioridades para máquinas virtuales crítica prioridad de acceso a dispositivos de almacenamiento La priorización de intercambio de memoria (inflamación de la memoria) VMware ESX / ESXi tiene una solución probada para la distribución de los recursos de hardware, que incluye soporte completo para el tráfico de la configuración de la red, I / O el establecimiento de prioridades, y globos de memoria para la gestión de memoria y el establecimiento de prioridades.
Apoyo para las Tecnologías de Mejora del Rendimiento			Hyper-V carece de apoyo de varias tecnologías que mejoran el rendimiento, tales como: AMD RVI (tablas anidadas página), incluido en la última versión de la CPU AMD Barcelona Páginas de memoria grande, que permite mejorar el rendimiento cuando la virtualización de bases de datos VMware ESX / ESXi es compatible con las tablas de páginas y páginas anidadas grandes cantidades de memoria y por lo tanto capaz de un rendimiento superior, incluso en los entornos más exigentes. Aplicaciones de misión crítica e intensivos, como una base de datos de Oracle se desempeñan mejor en un entorno virtual de VMware.
Soporte Linux virtualizado			Hyper-V es compatible con la “vieja manera” de hacer Linux para la virtualización, donde los administradores mantienen dos núcleos, uno para la física y otro para las máquinas virtuales. Este adicionales de mantenimiento mayor complejidad y los costes de gestión.Por otra parte, VMware ESX / ESXi apoya para Linux-a través de la virtualización paravirt_ops / VMI (Virtual Machine Interface) – la nueva industria aceptado forma de para-virtualizar Linux. Esta nueva forma no requiere de los administradores de TI para mantener y apoyar los núcleos separados para máquinas físicas y virtuales – es todo en un solo núcleo. En la actualidad, SLES 10, y Ubuntu 7 todo paravirt-ops/VMI apoyo.
Avanzadas características de virtualización
La tecnología de seguridad virtual de			Hyper-V no ofrece dedicada capacidades de los proveedores de seguridad para ampliar sus capacidades de seguridad para entornos virtualizados.VMsafe, Una característica de las próximas VMware ESX / ESXi, permitirá un rico ecosistema de soluciones de seguridad de terceras partes para los entornos virtualizados. VMsafe es una tecnología de seguridad virtual que proporciona una visibilidad de grano fino de los recursos de máquina virtual, que permite supervisar todos los aspectos de la ejecución del sistema y detener los virus antes indetectable, rootkits y malware antes de que se puede infectar un sistema.

VMware ESX – ESXi 3.5 vs. Microsoft Hyper-V

Abrir puerto SSH en ESXi

Pues muy sencillo.

Pinchamos ALT + F1 y nos saldrá una pantalla donde escribiremos a ciegas UNSUPPORTED

Nos pedirá usuario y password de nuestra consola de ESXi

Ejecutaremos:

vi /etc/inetd.conf

Nos abrirá el fichero de configuración y buscaremos una linea en la que hay #ssh y le quitaremos la almohadilla

Guardaremos presionando :wq!

Y reiniciamos nuestro ESXi

Ya podemos acceder por SSH a nuestro ESXi

Abrir puerto SSH en ESXi

Cuando al arrancar nuestra máquina ESXi y nos aparece este error, si nos pinchamos en un dedo, creo que no nos sacan sangre.

Kernel: vmkerkel.gz bootUUID=7b0...............................
Loading vmkernel.gz
Module: binmod.tgz
Loading binmod.tgz
Module: environ.tgz
Loading environ.tgz
Module: cim.tgz
Loading cim.tgz
Module: oem.tgz
Loading oem.tgz
Module: license.tgz
Loading license.tgz
Module: state.tgz
Loading state.tgz
PANIC: Error while reading file: -3, state.tgz
boot:

(sólo puedes darle al Intro, y se reinicia el Hypervisor)

stage.tgz contiene todos los archivos de configuración de nuestro server ESXi

Este error se produce por que hay algo en la configuración de ESXi que no tiene nada que ver con lo que es realmente. El ESXi se cabrea y nos escupe este pedazo de error. Yo padecí este error y además con la mala suerte de que teníamos todo ya listo, configurado, traspasado y en producción y en último momento un cambio de disco duro en un HP Proliant ML380 G5 me dejó el rostro pálido.

Buscando por internet encontré no muchos sitios donde hablaban de este error, al principio ninguno con solución, imagino que era la tensión de esta situación. Hasta que encontré que decía simplemente que no nos preocupásemos y que simplemente que reinstalásemos la instalación de ESXi.

Pues así hice, reinstalé el ESXi y lo único que tuve que hacer luego fue ir a los datastore y pincha en el VMX de la máquina con el botón de la derecha y decirle “Add to Inventory”.

Suerte!!!

VMware ESXi: error while reading file: -3 state.tgz

 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

Un amigo mio ha pasado este link y es la solución perfecta para redimensionar el tamaño de una partición de VMware ESX al tamaño que necesitemos.

No os lo perdáis en:

http://www.virtualizacionesx.com/reducir-el-tamano-de-una-particion-vmware/

Con la información contenida en este link, ya no tendremos tanto miedo a las intocables particiones de VMware

Gracias por el aporte

Redimensionar discos virtuales 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