Muito bom o artigo parabens !!

Fazia tempo que eu não logava aqui no site, mas tive que logar pra comentar, muito bom, estava precisando desse passo a passo já a algum tempo, parabéns..

Muito bom o artigo, eu faço pelo ovftools criei um script e também agendei no cron.
Lembro q na época foi muito díficil justamente pela falta de material sobre o assunto.

Agora uma dúvida, eu acho que não é suficiente simplesmente editar o cron pois o esxi tem uma parada que quando ele é reiniciado ele volta todas as configurações que estão fora da área da Storage.

Legal cara tá precisando mesmo... agora gerou uma dúvida caso eu queira fazer snapshot no proprio disco ex: VM_BACKUP_VOLUME="/vmfs/volumes/50d3332c-a9a61fac-9f3e-782bcb4e760d/CRM/SCRIPT" gera erro..


cat: can't open 'CRM': No such file or directory
2013-03-23 01:57:57 -- info: ###### Final status: ERROR: No VMs backed up! ######

esquilooo

Nos meus testes, todas as alterações que eu fazia nos arquivos de configuração do ESXi (fora da área de storage), quando reiniciamos o servidor, realmente voltava ao padrão dele, provavelmente por ser um produto fechado. Se vc reparar bem, eu criei uma VM para efetuar o "backup" chamada zBKP_Server-Ubuntu11.04_amd64 onde eu usei o CRON desta VM para startar o GhettoVCB via SSH. Essa é a ideia da solução :)

thiago.xaviers

Cara, não cheguei a testar o GhettoVCB no próprio disco do ESXi. Manualmente, tu consegui fazer snapshot no disco via vSphere Client.
Mas interessante esse teu comentário, vou testar e ver se apresenta esse erro q vc informou... posto resultado assim q possível.
Valeu...

Perfeito, entendi. Mas o backup é o próprio snapshot? E como faz pra restaurar? No esxi esse script é agendado como?

esquilooo

Sim, o backup é o snapshot. Ele leva todos os arquivos da VM para o caminho NFS (que você especificou) montado no ESXi.
Para restaurar é de forma manual, copia os arquivos da VM para o STORAGE do ESXi (ou outro servidor ESXi). Adiciona o VMX no inventário e quanto você startar a VM, ele vai perguntar se você moveu ou copiou a VM.
Se vc levar os arquivos para outro servidor ESXi, dá uma conferida nas PROPRIEDADES da VM antes de startar, principalmente no NETWORK ADAPTER (questão de MAC Address), para não ter erro...

Procedimento bem tranquilo de executar.

De novo: Não tem agendamento no ESXi... eu usei a VM "zBKP_Server-Ubuntu11.04_amd64"; Agendei no CRON da VM para executar um SSH no ESXi (com troca de chaves) e rodar o script;

CRON da VM: 30 21 * * * root ssh root@192.168.1.110 './vmfs/volumes/VM_Storage/scripts/ghettoVCB.sh -f /vmfs/volumes/VM_Storage/scripts/machines' > /dev/null

==> 21:30 usuário ROOT da VM "zBKP_Server-Ubuntu11.04_amd64" conecta via SSH no ESXi (192.168.1.110) e roda o comando './vmfs/volumes/... .../guettoVCB.sh -f /vmfs/vol ... ... ... ... ...'


Sacou?

O backup só faz com as VM desligadas não faz backup "a quente"?

013-06-19 15:24:33 -- info: Initiate backup for XWIN7

2013-06-19 15:24:33 -- info: ERROR: error in backing up of "/vmfs/volumes/datastore1/Windows 7 - ESXI/Windows 7 - ESXI.vmdk" for XWIN7
2013-06-19 15:24:33 -- info: Backup Duration: 0 Seconds
2013-06-19 15:24:33 -- info: ERROR: Unable to backup XWIN7 due to error in VMDK backup!


Datastore not found.

Datastore not found.

Datastore not found.

2013-06-19 15:24:39 -- info: Initiate backup for XCentOS63

2013-06-19 15:24:39 -- info: ERROR: error in backing up of "/vmfs/volumes/datastore1/CentOS - ESXI/CentOS - ESXI.vmdk" for XCentOS63
2013-06-19 15:24:39 -- info: Backup Duration: 0 Seconds
2013-06-19 15:24:39 -- info: ERROR: Unable to backup XCentOS63 due to error in VMDK backup!

Opa Wesllay...

Seguinte, o GhettoVCB faz backup das VMs quentes sim. Sem problemas! Inclusive utilizo este script em servidores de produção da forma como descrevo aqui neste artigo e tudo funciona 100%. No teu caso, dá uma olhada no caminho de destino que tu setou (tá certo e online/ativo???)... Esse tipo de erro acontecia quando eu errava o caminho de destino dentro do script (cuida os espaços nos nomes dos diretórios/arquivos).

Outra coisa importante: se tu tiver SNAPSHOTS das VMs que tu vai copiar, REMOVE TODAS antes de rodar o GhettoVCB. Dá erro no script se houver snapshots que não sejam tiradas pelo GhettoVCB. Descobri isso com o tempo, na prática.

Não conheço o teu cenário, mas espero ter ajudado.
Valeu...

Amigo bom dia,
Estou executando o script manualmente, porem esta apresentado o seguinte erro.

/vmfs/volumes/503f7ea7-142bf7aa-d887-d8d385dafd1c/scripts # ./ghettoVCB.sh -f machines
#
# ghettoVCB for ESX/ESXi 3.5, 4.x+ and 5.x
# Author: William Lam
# http://www.virtuallyghetto.com/
# Documentation: http://communities.vmware.com/docs/DOC-8760
# Created: 11/17/2008
Version 0ified: 2013_01_11
#
###############################################################################

Usage: ghettoVCB.sh [options]

OPTIONS:
-a Backup all VMs on host
-f List of VMs to backup
-m Name of VM to backup (overrides -f)
-c VM configuration directory for VM backups
-g Path to global ghettoVCB configuration file
-l File to output logging
-w ghettoVCB work directory (default: /tmp/ghettoVCB.work)
-d Debug level [info|debug|dryrun] (default: info)

(e.g.)

Backup VMs stored in a list
./ghettoVCB.sh -f vms_to_backup

Backup a single VM
./ghettoVCB.sh -m vm_to_backup

Backup all VMs residing on this host
./ghettoVCB.sh -a

Backup all VMs residing on this host except for the VMs in the exclusion list
./ghettoVCB.sh -a -e vm_exclusion_list

Backup VMs based on specific configuration located in directory
./ghettoVCB.sh -f vms_to_backup -c vm_backup_configs

Backup VMs using global ghettoVCB configuration file
./ghettoVCB.sh -f vms_to_backup -g /global/ghettoVCB.conf

Output will log to /tmp/ghettoVCB.log (consider logging to local or remote datastore to persist logs)
./ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log

Dry run (no backup will take place)
./ghettoVCB.sh -f vms_to_backup -d dryrun

./ghettoVCB.sh: line 653: syntax error: "fi" unexpected (expecting "then")

Alguma sugestão?

Grato,

Endrigo
ao rodar o script o erro apresentado e esse:
Tem como me ajudar?


./ghettoVCB.sh machines
Logging output to "/tmp/ghettoVCB-2013-07-23_19-22-17-3253013.log" ...
2013-07-23 19:22:17 -- info: ERROR: "" is not valid VM input file!
###############################################################################
#
# ghettoVCB for ESX/ESXi 3.5, 4.x+ and 5.x
# Author: William Lam
# http://www.virtuallyghetto.com/
# Documentation: http://communities.vmware.com/docs/DOC-8760
# Created: 11/17/2008
# Last modified: 2013_01_11 Version 0
#
###############################################################################

Usage: ghettoVCB.sh [options]

OPTIONS:
-a Backup all VMs on host
-f List of VMs to backup
-m Name of VM to backup (overrides -f)
-c VM configuration directory for VM backups
-g Path to global ghettoVCB configuration file
-l File to output logging
-w ghettoVCB work directory (default: /tmp/ghettoVCB.work)
-d Debug level [info|debug|dryrun] (default: info)

(e.g.)

Backup VMs stored in a list
./ghettoVCB.sh -f vms_to_backup

Backup a single VM
./ghettoVCB.sh -m vm_to_backup

Backup all VMs residing on this host
./ghettoVCB.sh -a

Backup all VMs residing on this host except for the VMs in the exclusion list
./ghettoVCB.sh -a -e vm_exclusion_list

Backup VMs based on specific configuration located in directory
./ghettoVCB.sh -f vms_to_backup -c vm_backup_configs

Backup VMs using global ghettoVCB configuration file
./ghettoVCB.sh -f vms_to_backup -g /global/ghettoVCB.conf

Output will log to /tmp/ghettoVCB.log (consider logging to local or remote datastore to persist logs)
./ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log

Dry run (no backup will take place)
./ghettoVCB.sh -f vms_to_backup -d dryrun

2013-07-23 19:22:17 -- info: ============================== ghettoVCB LOG START ==============================

2013-07-23 19:22:17 -- info: CONFIG - VERSION = 2013_01_11_0
2013-07-23 19:22:17 -- info: CONFIG - GHETTOVCB_PID = 3253013
2013-07-23 19:22:17 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/519601d6-2e8c3212-66ad-78e7d163056c
2013-07-23 19:22:17 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2013-07-23 19:22:17 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2013-07-23_19-22-17
2013-07-23 19:22:17 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2013-07-23 19:22:17 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2013-07-23 19:22:17 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2013-07-23 19:22:17 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2013-07-23 19:22:17 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2013-07-23 19:22:17 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2013-07-23 19:22:17 -- info: CONFIG - LOG_LEVEL = info
2013-07-23 19:22:17 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2013-07-23_19-22-17-3253013.log
2013-07-23 19:22:17 -- info: CONFIG - ENABLE_COMPRESSION = 0
2013-07-23 19:22:17 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2013-07-23 19:22:17 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2013-07-23 19:22:17 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2013-07-23 19:22:17 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2013-07-23 19:22:17 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2013-07-23 19:22:17 -- info: CONFIG - VM_STARTUP_ORDER =
2013-07-23 19:22:17 -- info: CONFIG - EMAIL_LOG = 0
2013-07-23 19:22:17 -- info:
cat: can't open '': No such file or directory
2013-07-23 19:22:18 -- info: ###### Final status: ERROR: No VMs backed up! ######

2013-07-23 19:22:18 -- info: ============================== ghettoVCB LOG END ================================

Opa... blz Itan? Você fez duas postagens...

Segundo o que você escreveu na ultima postagem, olha só o erro que tá apresentando: ==> 2013-07-23 19:22:17 -- info: ERROR: "" is not valid VM input file!

cat: can't open '': No such file or directory

O próprio script até te sugere exemplos de uso:

Backup VMs stored in a list
./ghettoVCB.sh -f vms_to_backup

Backup all VMs residing on this host except for the VMs in the exclusion list
./ghettoVCB.sh -a -e vm_exclusion_list

...entre outros.

Saca que o comando que tu rodou "./ghettoVCB.sh machines" falta o parâmetro "-f" sendo que o correto seria ./ghettoVCB.sh -f machines

Abaixo, um exemplo retirado de um servidor de produção que utilizo o script com agendamento no CRON: repare que eu especifico o caminho completo dos arquivos, tando o ghettoVCB.sh quando o caminho do machines após o parâmetro -f.

Ex. crontab: 01 00 * * 6 root ssh root@192.168.1.100 './vmfs/volumes/VMStorage/scripts/ghettoVCB.sh -f /vmfs/volumes/VMStorage/scripts/machines' > /dev/null

Importante também que as VMs não tenham SNAPSHOTs efetuadas manualmente. Se tiver, para as VMs, remove as snapshots e starta as VMs. Após, tu roda o script.

Espero ter ajudado.

SSH com chaves authorized_keys em ESXi Persistent
Fiz no 4.1 e testei 5.0

# cp .ssh/authorized_keys /bootbank/
# rm .ssh/authorized_keys
# ln -s /bootbank/authorized_keys .ssh/
# tar -C / -czf "/bootbank/ukey.tgz" ".ssh"
# vi /bootbank/boot.cfg
Colocar no final da linha modules ' --- ukey.tgz'
Exemplo:
kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz --- ukey.tgz
build=4.1.0-348481
updated=2
bootstate=0

Com isso pode reiniciar o ESXi que vai funcionar as chaves e pode adicionar mais chaves de boa.

Tem outra dica nos comentários no link abaixo que ainda não testei:
http://blogs.vmware.com/vsphere/2012/07/enabling-password-free-ssh-access-on-esxi-50.html

Olá amigo "ends"
Muito bom seu artigo funcionou comigo para o mesmo storage.
Estou usando esse método para fazer o backup das minhas VMs e para fazer a restauração no mesmo servidor caso de um problema é só copiar para o local de origem?

vlws,

Olá Juno.

Sim... essa é a ideia da solução. Se der problema, tu leva os arquivos manualmente do backup para o local de origem "/vmfs/volumes/datastore". Adiciona o VMX ao inventário e, quando tu iniciar a VM, responde se copiou ou moveu e tudo certo... VM no ar.

Esta até era uma dúvida do amigo tiago.xaviers. Eu já havia testado no mesmo DATASTORE com sucesso. Porém não tinha postado aqui o resultado.

Esse comentário das chaves que o amigo EACSFC postou, juntamente com o link é bem interessante.
Obrigado pela dica... vou ler com calma e fazer uns testes...

Valeu...

Uma situação interessante, que ocorreu em um servidor de produção com ESXi 5.1, que acho legal compartilhar com a galera da comunidade.

Problema: Devido a um problema elétrico em um no-break, um servidor de produção com ESXi 5.1 foi desligado bruscamente. Após a troca do no-break, fui acionado pela empresa para resolver um problema em uma VM de produção de Windows Server 2008 R2 Standard neste servidor, com Controlador de Domínio, DHCP, DNS, arquivos e tudo mais. Ou seja, uma das VMs principais da empresa.

A empresa não possuía rotinas de backup de suas máquinas virtuais. :/

Em verificação, notei que no inventário do vSphere Client o nome da VM estava como "unknown" e que o arquivo .vmx estava com 0KB.
Porém, os arquivos VMDK estavam com seu tamanho correto segundo o que o administrador da estrutura me informou. Como era uma situação critica, busquei a solução de contorno mais rápida, prática e adequada ao momento de "nervosismo" que eles passavam.

- Verifiquei o nome do diretório no /vmfs/volumes/w2008r2std e renomei para w2008r2-off
- Removi o unknown do inventário no vSphere Client
- Criei uma nova VM com o nome original "w2008r2std" com a mesma configuração de hardware (porém removi o Hard Disk)
- Copiei o VMDK (hard disk) da VM com problema no diretório da nova VM.
- Iniciei a VM.

A VM iniciou sem problemas, somente com o Windows indicando desligamento inadequado. Todos os serviços do W2K8 funcionando normalmente.

Não entrei no mérito do problema, do que houve, pois o momento pedia a situação de contorno mais rápida, visto que a empresa estava parada.

Resumindo: problema contornado em menos de 30 min. Isso serviu também para mostrar ao cliente o quanto é importante uma solução de backup bem alinhada, pois se minha ideia não surtisse efeito, a empresa teria um bom prejuízo.

Bom, na situação, não houve tempo para pesquisar o pq do erro.
Se alguém tiver uma ideia do que ocorreu com essa VM com a falta de energia, posta aqui o comentário.

Valeu...

PS: implementei a rotina de backup das VMs na estrutura da empresa.

Olá amigo Ends, obrigado pelas respostas,

Tenho uma outra dúvida:

Em algumas das minhas VMS tenho um ou dois snapshots delas e pelo que vi preciso remover a snapshot para pode fazer o backups correto?

E tenho como fazer o backup mesmo com os snapshots já criados?

Opa Juno. Blz?

As snapshots que você indicou no arquivo "machines" (que vai tirar cópia) NÃO PODEM TER SNAPSHOTs manuais.
Ou seja, você vai ter que excluir as snapshots antes de rodar o script.
No vSphere Client, na tela de SNAPSHOTs da sua VM, tem um botão DELETE ALL. Usa ele para excluir todas as imagens das VMs.
Pode ser necessário CONSOLIDAR a VM depois da exclusão... se for uma VM de produção, procura fazer fora do horário, para não atrapalhar a performance do servidor/usuários.

Mas é um procedimento tranquilo e sem problemas.

Qualquer coisa, dá um toque.
Abraço.

Olá.
Tenho no meu ambiente alguns servidores rodando o VMWARE ESXi 5.0.
Utilizo o ghetto.sh sem problemas, gravando os backups em servidores NFS ou Storages Soho (Iomega) para armazenamento.
Meu problema é na hora de restaurar... Consigo rodar as máquinas de backup a partir da unidade NFS sem problemas... Mas quando preciso copiar a máquina virtual para o servidor, esse procedimento demora MUITO... O que eu queria era fazer com que o ghetto.sh gravasse diretamente em outro servidor VMWARE, direto em seu datastore local. Conhece alguma maneira de instalar o serviço de NFS Server no ESXi?
Obrigado!
Parabéns pelo post!

Olá albertojuniorhc.

Cara, quando eu iniciei os meus estudos, também me surgiu essa ideia, tentar fazer o ghetto gravar as VMs direto em outro ESXi (de backup, por exemplo). Seria o ideal.
Mas nesse caso, creio que só com ferramentas da VMWARE mesmo ($$$)... ou outras ferramentas pagas, como o VEEAM BACKUP (http://www.veeam.com/pt/vmware-esx-backup.html), devem ter essa função; Em todos os meus testes, não achei uma forma de conseguir compartilhar um DATASTORE via NFS p/add em outro servidor ESXi. Pode ser que tenha de forma "gratuita", mas eu desconheço.

Olá Amigo Ends,

Estou com um problema, quando faço a cópia das VMs via scp para o datastorage ele copia o HD inteiro provisionado, fiz backup com o ghettoVCB e percebi que em uma máquina no backup está com 13GB e ao copiar via scp ela ficou com 159GB, tem como fazer isso com o ghettoVCB-restore para copiar a VM com os mesmo 13GB?

OBS. Fiz o backup com o ghettoVCB com o disco em thin,
OBS1. quando copiei as VMs via scp da primeira vez fiquei sem espaço no datastorage e não consegui copiar as VMs.

Olá Amigo
Ends,

Tudo resolvido com o ghettoVCB-restore.sh, eu apenas configurei o restore com o thin.

Vlws,

Olá Tudo bem ?
Quando eu gero um backup ele sempre copia todo conteudo, por exeplo eu tenho uma máquina com 750 GB, e ocupado 120GB , como eu faço para copiar somente 120GB para o backup ? Pelo que eu tentei ele copiou os 750GB.

Opa XJC. Tudo bem?

Creio que esta questão do backup levar "todo o disco" (espaço total da VM) está relacionado ao provisionamento do disco quando você criou a VM. Para levar somente os 120GB, o disco tem que ser "dinamicamente alocado" (expressão utilizada no Oracle Virtual Box, que condiz bem com a tua pergunta). Porém, no servidor que você restaura a VM, tens que ter os 750GB livres.

Falando sinceramente, eu não testei este tipo de situação, até porque hoje em dia em projetos de servidores virtualizados, geralmente utilizo 2 ou mais discos acima de 2TB (por segurança) ou Storage NAS/SAN com iSCSI no ESXi. O espaço acaba não se tornando um problema nestas estruturas.

Posta o resultado dos teus testes aqui para acompanharmos.
Boa sorte.

OBS: Dá uma lida nos posts do JUNO, acima do teu. Situação semelhante a tua.

Bom dia,

Gostaria de agradecer ao autor do Post.

Realmente era a solução que eu precisava.

Post muito bem explicado e meus backps de VMs estão em pleno vapor.

Muito obrigado.

Não consigo adicionar o NAS na VM, segue o erro.


( Call "HostDatastoreSystem.CreateNasDatastore" for object "ha-datastoresystem" on ESXi "192.168.3.103" failed.
NFS mount 192.168.3.101:/vms failed: The NFS server does not support MOUNT version 3 over TCP. ).

Se alguém puder ajudar, agradeço.

Obrigado.

Galera, segue abaixo explicação que copiei do forum da VMWARE sobre a diferença entre Thick Provision Lazy Zeroed; Thick Provision Eager Zeroed; Thin Provision. https://communities.vmware.com/message/2405343 (por Richardson Porto https://communities.vmware.com/people/rcporto).

É interessante prestarmos atenção na hora da criação das VMs, pois isso vai influenciar direto na cópia com o GhettoVCB (tamanho e tempo de cópia).

-----------------------

Discos Thick são discos totalmente alocados no datastore, ou seja, se você criar um disco Thick com 20GB, ele irá ocupar 20GB do seu datastore, a diferença entre o Thick Lazy Zeroead e Eager Zeroed, é que no Lazy não são escritos zero em todos os blocos do disco, já o Eager ele escreve zero em todos os blocos do disco.

Já o disco Think é um tipo de disco que aloca apenas o espaço que é gravado pelo sistema operacional do Guest, por exemplo, se você criar um disco de 20GB para uma VM, inicialmente ele irá ocupar apenas alguns KB/MB no datastore, porém no momento que você começar a gravar dados no mesmo através do sistema operacional, o tamanho dele pode chegar até o limite de 20GB.

Aplicações:
Thick Provision Lazy Zeroed: opção padrão para praticamente todas as aplicações, exceto as que requerem o Eager Zeroed;
Thick Provision Eager Zeroed: normalmente utilizado por VM que irão utilizar a funcionalidade Fault Tolerance do VMware, ou se for utilizar a funcionalidade do Microsoft Failover Cluster dentro das máquinas virtuais;
Thin Provision: normalmente utilizado quando se deseja provisionar mais espaço que o total de espaço físico disponível, porém pode causar problemas se todas as VMs utilizarem todo o espaço disponível do datastore.

Fiz o tutorial e funcionou tudo OK!

Porém começou a dar este erro, segue log:


2015-06-09 07:15:41 -- info: ============================== ghettoVCB LOG START ==============================

2015-06-09 07:15:41 -- info: CONFIG - VERSION = 2015_05_06_1
2015-06-09 07:15:41 -- info: CONFIG - GHETTOVCB_PID = 13705805
2015-06-09 07:15:41 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/freenas/backup176
2015-06-09 07:15:41 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 5
2015-06-09 07:15:41 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2015-06-09_07-15-40
2015-06-09 07:15:41 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2015-06-09 07:15:41 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2015-06-09 07:15:41 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2015-06-09 07:15:41 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2015-06-09 07:15:41 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2015-06-09 07:15:41 -- info: CONFIG - SNAPSHOT_TIMEOUT = 25
2015-06-09 07:15:41 -- info: CONFIG - LOG_LEVEL = info
2015-06-09 07:15:41 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2015-06-09_07-15-40-13705805.log
2015-06-09 07:15:41 -- info: CONFIG - ENABLE_COMPRESSION = 0
2015-06-09 07:15:41 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2015-06-09 07:15:41 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2015-06-09 07:15:41 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2015-06-09 07:15:41 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2015-06-09 07:15:41 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2015-06-09 07:15:41 -- info: CONFIG - VM_STARTUP_ORDER =
2015-06-09 07:15:41 -- info: CONFIG - RSYNC_LINK = 0
2015-06-09 07:15:41 -- info: CONFIG - EMAIL_LOG = 0
2015-06-09 07:15:41 -- info:
2015-06-09 07:15:44 -- info: Snapshot found for Thor, backup will not take place

2015-06-09 07:15:44 -- info: ###### Final status: ERROR: All VMs failed! ######

2015-06-09 07:15:44 -- info: ============================== ghettoVCB LOG END ================================


Tem alguma sugestão?

Obrigado.

Opa, Quanto a duvida no post acima já consegui resolver, Obrigado.

Bom dia Pessoal,

Primeiramente, parabéns pelo tutorial, muito intuito e bem explicado!!!

Tenho um server ESXi 5.0 com algumas máquinas virtuias em ambiente de teste rodando, porém, quero virtualizar meu servidor de banco de dados e o de arquivos, ambos, win server 2008. Hoje realizo backup destes servidores pelo próprio backup do windows, a minha pergunta é: Utilizando o ghetto backup nas máquinas virtuais eu consigo restaurar apenas arquivos deletados erroneamente ou só consigo restaurar os snapshots das máquinas completas?

É a primeira vez que vou trabalhar com virtualização para produção, logo, não tenho muita experiência, se alguém puder me ajudar, agradeço rs.
.

Bom dia alansouza91

Olha só, tu restaura as snapshot completa da máquina virtual. O ghetto gera os arquivos .vmx, .vmdk e o STATUS.OK se tudo correr bem.

Porém, os .vmdk são dos discos virtuais. Os arquivos do sistema operacional e demais dados estão ali dentro. Tu pode abrir esses .vmdk manualmente e explorar eles. Pode copiar na mão os arquivos que tu necessita, no caso de precisar de algum arquivo específico, não precisa subir a VM para poder acessar os arquivos. É uma vantagem. Ainda mais se tu armazenar essas snapshots "de backup" em um NAS/Storage. Não sei qual a tua estrutura.

Qual é o banco de dados que tu quer virtualizar? Dependendo do tamanho da estrutura, não é uma boa prática. Tenho clientes com BD virtualizado (Oracle XE, SQL Sever e outros de menor porte), mas nada absurdamente monstruoso. Funciona super bem e sem problemas, mas como te falei, depende do porte. No meu caso nunca tive problemas.

alansouza91

Como tu falou que não está ambientado com virtualização, olha só: tu pode fazer um teste. Usa o VMWare Converter para converter teus servidores físicos em servidores Virtuais. Se tudo correr bem, tu sobe as VMs convertidas em outra máquina e brinca bastante (testa performance) antes de colocar essa tua ideia em produção. Geralmente faço isso para não correr riscos.

Achei um link que mostra como utilizar o VMWare Converter: http://www.impacta.com.br/blog/2014/08/18/como-migrar-servidores-fisicos-com-windows-server-2003-par...

Qualquer coisa, só postar aqui.
Boa sorte.

Ends,

Só hoje voltei a entrar no fórum, pensei que ninguém tinha respondido hehe

Muito bom, eram dessas informações que estava precisando, ontem virtualizei os dois server, para fazer um teste, pelo VM converter, a principio funcionou de boa, até configurei as portas usb's para fazer backup do servidor pelo próprio windows para Hd's externos, e assim ter uma redundância de backups, depois que implantar a estrutura do ghettoVCB.

Obs.: Meu server de dados hoje tem no máximo uns 400 Gb, separei um disco iscsi de 1 Tb, pra essa máquina no ESXi.

Vou começar a agora a instalar o guettoVCB, só me tira uma dúvida, se eu criar a maquina ubuntu esxi, esta também vai ser backupeada pelo guettoVCB ?

Obrigado, pela ajudar brother!!!

Boa tarde alansouza91

Claro, sem problemas. Qualquer VM do inventário que tu colocar no arquivo "machines" será copiada pelo Ghetto. Inclusive a do Ubuntu. Só fica atento que o nome das VMs tem que ser iguais aos que estão no inventário do Vsphere Client. Evita caracteres especiais nos nomes das VMs (@, #, +, etc...).

Tu deve ter o cuidado também na hora de criar as VMs, referente aos discos. Isso influência muito no tempo de cópia das VMs.

Olha os comentários mais acima onde falo sobre Thick Provision Lazy Zeroed (opção que uso).

Boa sorte.
Abraço.

Bom dia Ends,

Consegui concluir o laboratório, tudo funcionando, só estou estranho uma coisa, demorou mais de 5 hrs para criar o snapshot de uma VM de 40 GB, demora assim mesmo? E qual aplicação uso para manusear os arquivos .vmdk, porquê os que tentei retornam a mensagem "arquivo não suportado" ?

Boa Tarde
Cara perfeito, explicação excelente e funcional 1000%.
Grande Abraço

Olá, pessoal!
Muito boa essa dica do GhettoVCB, porém, a snapshot demora demais... Uma VM de 50GB, que levaria menos de um minuto pra fazer snapshot manualmente, com ele, ficam horas... e nem copia todos os arquivos... ou estou fazendo alguma coisa errada...
Estou tentando configura-lo para usar com o Bacula... mas está dificil...