Este artigo tem por objetivo, mostrar os passos para configuração de script de backup ghettoVCB.sh em um servidor virtual ESXi 5.0, utilizando também, agendamento para automatizar as tarefas de backup. Como encontrei pouco material referente às cópias quentes (ligadas) de máquinas virtuais, posto aqui a experiência que adquiri com este estudo/projeto.
Obs. 1: "Chewbacca" é o nome do Datastore compartilhado via NFS na rede com o diretório ".../zVMBackup_192.168.1.110", onde serão gravadas as 5 versões completas das snapshots.
Obs. 2: Será explicado mais adiante neste tutorial, como criar um servidor NFS e compartilhar como Datastore através do vSphere Client.
Concluído e salvo a edição do "ghettoVCB.sh", devemos criar um arquivo com a lista das VMs a serem copiadas pelo script do "ghettoVCB.sh".
Neste caso, criamos no mesmo caminho (/vmfs/volumes/VM_Storage/scripts) um arquivo chamado "machines", ao qual deverá ser colocado o nome das VMs exatamente como aparece no inventário do vSphere Client.
Ao verificarmos a figura anterior, na lista de VMs, são apresentadas quatro máquinas virtuais, porém, as VMs que serão copiadas neste exemplo, serão "MSWinXPsp3_x86", "Nexenta3.2.1_amd64" e "Ubuntu11.04_amd64", nesta ordem.
Excluiremos a máquina virtual "zBKP_Server-Ubuntu11.04_amd64" do procedimento de backup. Então, a escrita do arquivo será exatamente como exposto abaixo (cuidado com caracteres maiúsculos/minúsculos e espaços entre os nomes):
MSWinXPsp3_x86
Nexenta3.2.1_amd64
Ubuntu11.04_amd64
Salvo o arquivo "machines", devemos informar ao ESXi que o arquivo "ghettoVCB.sh" é um script executável. Para isso, damos permissão de execução ao arquivo com o comado:
# chmod +x ghettoVCB.sh
Pronto!
Caso você deseje efetuar backups manuais destas máquinas virtuais listadas no arquivo "machines", basta rodar o script dentro do servidor ESXi, através do comando:
# ./ghettoVCB.sh -f machines
* Lembrando que, neste exemplo, você deve estar no diretório criado /vmfs/volumes/VM_Storage/scripts/ para executar o comando com sucesso.
Os logs de status das snapshots ("STATUS.ok" ou "STATUS.error") ficam gravados dentro do caminho de destino da snapshot de cada máquina virtual, ou seja, neste exemplo, dentro da pasta de cada VM no dispositivo /vmfs/volumes/Chewbacca/zVMBackup_192.168.1.110.
Com isso, finalizamos a configuração do script "ghettoVCB.sh" para efetuar snapshots manuais de máquinas virtuas quentes, pré-definidas em um arquivo "machines", em um servidor ESXi 5.0.
[2] Comentário enviado por TheHawk em 21/03/2013 - 15:14h
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..
[3] Comentário enviado por esquilooo em 22/03/2013 - 10:32h
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.
[4] Comentário enviado por thiago.xaviers em 22/03/2013 - 22:58h
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! ######
[5] Comentário enviado por ends em 25/03/2013 - 23:10h
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 :)
[6] Comentário enviado por ends em 25/03/2013 - 23:19h
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...
[8] Comentário enviado por ends em 27/03/2013 - 18:23h
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;
==> 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 ... ... ... ... ...'
[9] Comentário enviado por wesllay em 19/06/2013 - 16:18h
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!
[10] Comentário enviado por ends em 21/06/2013 - 00:25h
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...
[11] Comentário enviado por itan em 23/07/2013 - 12:05h
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")
[12] Comentário enviado por itan em 23/07/2013 - 16:24h
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
[13] Comentário enviado por Ends em 23/07/2013 - 18:24h
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.
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.
[15] Comentário enviado por juno em 26/08/2013 - 12:32h
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?
[16] Comentário enviado por Ends em 28/08/2013 - 22:57h
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...
[17] Comentário enviado por Ends em 28/08/2013 - 23:42h
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.
[19] Comentário enviado por Ends em 04/09/2013 - 15:54h
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.
[20] Comentário enviado por albertojuniorhc em 10/09/2013 - 12:16h
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!
[21] Comentário enviado por ends em 10/09/2013 - 13:48h
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.
[22] Comentário enviado por juno em 01/11/2013 - 10:49h
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.
[24] Comentário enviado por xjc em 18/04/2014 - 01:28h
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.
[25] Comentário enviado por ends em 19/04/2014 - 03:59h
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.
[27] Comentário enviado por clzera em 12/11/2014 - 13:12h
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. ).
É 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.
[31] Comentário enviado por alansouza91 em 26/08/2015 - 11:05h
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.
.
[32] Comentário enviado por Ends em 26/08/2015 - 12:18h
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.
[33] Comentário enviado por Ends em 26/08/2015 - 12:30h
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.
[34] Comentário enviado por alansouza91 em 27/08/2015 - 15:58h
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 ?
[35] Comentário enviado por Ends em 28/08/2015 - 16:27h
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).
[36] Comentário enviado por alansouza91 em 03/09/2015 - 09:05h
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" ?
[38] Comentário enviado por nettux em 17/01/2024 - 09:25h
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...