Virtualização com ESXi 5.5.0 - pfSense virtualizado + backup de VMs no FreeNAS via iSCSI
Este artigo tem por objetivo mostrar os passos de como montar um projeto de virtualização com um servidor físico instalado com VMWare ESXi 5.5.0 (hypervisor), implementando um firewall pfSense virtualizado, utilizando script ghettoVCB.sh para efetuar cópias de todas as VMs (quentes) do host com agendamento via máquina virtual do pfSense.
[ Hits: 25.564 ]
Por: Endrigo D. Rodriguez em 15/01/2016 | Blog: http://www.corbanet.com.br
Automatizando rotinas de backup de VMs via pfSense
Aproveitando a VM do pfSense instalada anteriormente, vamos utiliza-la para automatizar as rotinas de backup.
Para isso, precisamos instalar o serviço do CRON no pfSense.
Acesse a GUI de adminstração do pfSense através do browser digitando http://192.168.1.110 (admin/pfsense - se você ainda não alterou o usuário/senha padrão).
Siga os passos para instalação do serviço:
Como podemos observar na figura acima, o serviço do "Cron" no pfSense exibe uma tabela com minuto, hora, dia do mês, mês e dia da semana (nesta ordem).
Para adicionarmos a rotina de backup do ghettoVCB.sh ao "Cron", clicamos no botão "+" indicado no terceiro passo da figura acima e preenchemos os dados conforme o agendamento que necessitamos.
Ex.: caso o backup das VMs seja uma vez por semana, todo sábado, com início às 20h30, preenchemos da seguinte maneira.
No pfSense ficará assim:
Basta clicar no botão "SAVE" e a rotina do "Cron" estará programada no pfSense, sendo exibida na lista de agendamentos na ultima opção.
Duvidas de como funciona CRON?
De uma olhada no artigo do colega Ricardo Souza Silveira em:
Porém, esta rotina ainda não está funcional. Como estamos trabalhando com execução de comando via SSH, o pfSense irá estabelecer uma conexão SSH com o host ESXi. Toda conexão SSH necessita de autenticação (usuário que no caso será o "root" e senha ao qual não conseguimos especificar pelo "Cron").
Portanto, vamos trabalhar com autenticação através de troca de chaves entre o pfSense e o ESXi.
Digite o seguintes comandos em [2.2.5-RELEASE] [admin@firewall.localhost]/root:
# ssh-keygen
Onde todos os questionamentos devem ser deixados em branco, pressionando a tecla ENTER para manter o padrão.
# cat ~/.ssh/id_rsa.pub | ssh root@ip_servidor_esxi 'cat >> /etc/ssh/keys-root/authorized_keys'
Onde: "root@192.168.1.100" é o IP do servidor VMSRV (ESXi).
Efetuando o teste de conexão SSH via pfSense:
# ssh root@ip_servidor_esxi
Onde: "root@192.168.1.100" deverá efetuar acesso sem a solicitação de senha.
Obs. 1: no servidor ESXi, devemos nos certificar que a linha "AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys" esteja ATIVADA (sem comentários) dentro do arquivo de configuração /etc/ssh/sshd_config.
Obs. 2: podemos utilizar comandos de costume, como:
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@ip_servidor_esxi
Porém, a linha acima citada, deverá estar comentada para o funcionamento do SSH. Não indico este procedimento, pois ao reiniciarmos o servidor ESXi, a chave é perdida e o processo terá que ser efetuado novamente, não sendo uma prática eficaz neste caso.
Obs. 3: a cópia da chave pode ser feita manualmente, desde que seja inserida no diretório/arquivo correto do servidor ESXi (/etc/ssh/keys-root/authorized_keys).
Com estes passos efetuados, o agendamento programado no "Cron" do pfSense irá executar o comando SSH repassando os parâmetros especificados e executando o script sem problemas.
Feito estes procedimentos, a automatização da rotina de backup das VMs do host ESXi está completa e funcional.
Para isso, precisamos instalar o serviço do CRON no pfSense.
Acesse a GUI de adminstração do pfSense através do browser digitando http://192.168.1.110 (admin/pfsense - se você ainda não alterou o usuário/senha padrão).
Siga os passos para instalação do serviço:
- Clique no menu "System" opção "Packages"
- Clique na aba "Available Packages" que abrirá diretamente na sub-aba "All"
- Procure a opção "Cron" e clique no botão "+" para instalar o pacote
- Após finalizado a instalação, o serviço estará acessível clicando no menu "Services" opção "Cron"
Para adicionarmos a rotina de backup do ghettoVCB.sh ao "Cron", clicamos no botão "+" indicado no terceiro passo da figura acima e preenchemos os dados conforme o agendamento que necessitamos.
Ex.: caso o backup das VMs seja uma vez por semana, todo sábado, com início às 20h30, preenchemos da seguinte maneira.
30 20 * * 6 root ssh root@192.168.1.100 './vmfs/volumes/Datastore1/scripts/ghettoVCB.sh -f /vmfs/volumes/Datastore1/scripts/machines' >/dev/null
No pfSense ficará assim:
Duvidas de como funciona CRON?
De uma olhada no artigo do colega Ricardo Souza Silveira em:
Porém, esta rotina ainda não está funcional. Como estamos trabalhando com execução de comando via SSH, o pfSense irá estabelecer uma conexão SSH com o host ESXi. Toda conexão SSH necessita de autenticação (usuário que no caso será o "root" e senha ao qual não conseguimos especificar pelo "Cron").
Portanto, vamos trabalhar com autenticação através de troca de chaves entre o pfSense e o ESXi.
- Acesse o pfSense via ssh: #ssh admin@192.168.1.110 (utilize o PuTTY em máquinas Windows)
- Você será direcionado para o menu da console do pfSense. Pressione "8" para acessar a linha de comando
# ssh-keygen
Onde todos os questionamentos devem ser deixados em branco, pressionando a tecla ENTER para manter o padrão.
# cat ~/.ssh/id_rsa.pub | ssh root@ip_servidor_esxi 'cat >> /etc/ssh/keys-root/authorized_keys'
Onde: "root@192.168.1.100" é o IP do servidor VMSRV (ESXi).
Efetuando o teste de conexão SSH via pfSense:
# ssh root@ip_servidor_esxi
Onde: "root@192.168.1.100" deverá efetuar acesso sem a solicitação de senha.
Obs. 1: no servidor ESXi, devemos nos certificar que a linha "AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys" esteja ATIVADA (sem comentários) dentro do arquivo de configuração /etc/ssh/sshd_config.
Obs. 2: podemos utilizar comandos de costume, como:
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@ip_servidor_esxi
Porém, a linha acima citada, deverá estar comentada para o funcionamento do SSH. Não indico este procedimento, pois ao reiniciarmos o servidor ESXi, a chave é perdida e o processo terá que ser efetuado novamente, não sendo uma prática eficaz neste caso.
Obs. 3: a cópia da chave pode ser feita manualmente, desde que seja inserida no diretório/arquivo correto do servidor ESXi (/etc/ssh/keys-root/authorized_keys).
Com estes passos efetuados, o agendamento programado no "Cron" do pfSense irá executar o comando SSH repassando os parâmetros especificados e executando o script sem problemas.
Feito estes procedimentos, a automatização da rotina de backup das VMs do host ESXi está completa e funcional.
Páginas do artigo
1. Preliminares2. Visão geral
3. Configurando os adaptadores de redes no ESXi
4. Instalando e configurando o pfSense no ESXi
5. Configurando o iSCSI no FreeNAS e conectando no ESXi
6. Instalando e configurando o ghettoVCB.sh para cópias das VMs no FreeNAS
7. Automatizando rotinas de backup de VMs via pfSense
8. Considerações finais
Outros artigos deste autor
Minix 3.2.0 no ESXi 5.0 - Instalação usando o vSphere Client 5.0
Backup de máquinas virtuais no ESXi 5.0 com script ghettoVCB
Leitura recomendada
Backup em fita DAT com multivolume (LTO3)
Aumentando Resize (Tamanho) do HD Virtual VMDK - Debian 8 Jessie
Bacula 7.4.3 - Instalação e configuração
Já fez seu "BACKUP" hoje? Não? Então vamos conversar sobre isso
Empacotando Cliente Copy no Slackware - Como ganhar 20 GB de armazenamento em nuvem
Comentários
[1] Comentário enviado por azk em 15/01/2016 - 21:07h
excelente artigo, bastante detalhado...
good work bro!
excelente artigo, bastante detalhado...
good work bro!
[2] Comentário enviado por removido em 16/01/2016 - 13:37h
Bem interessante o artigo, favoritado.
------------------------------------------------------
KISS principle, RTFM and STFW = 42
Bem interessante o artigo, favoritado.
------------------------------------------------------
KISS principle, RTFM and STFW = 42
[3] Comentário enviado por smkbarbosa em 17/01/2016 - 16:20h
Vai servir de base para um estudo aqui. Obrigado :)
-------------------------------------------------------------------------------------------
Samuel Barbosa
Vai servir de base para um estudo aqui. Obrigado :)
-------------------------------------------------------------------------------------------
Samuel Barbosa
[4] Comentário enviado por MrcS em 17/01/2016 - 18:45h
Só lembrando que se for precisar de monitoramento, o Zabbix ja tem suporte nativo total desde a versão 2.4 pra monitorar ESXi/VMWare.. incluindo as vms. O template já vem pronto.
Só lembrando que se for precisar de monitoramento, o Zabbix ja tem suporte nativo total desde a versão 2.4 pra monitorar ESXi/VMWare.. incluindo as vms. O template já vem pronto.
[5] Comentário enviado por Ends em 18/01/2016 - 12:36h
Opa, tudo bem MrcS?
Tu sabe de algum material, algum link para me indicar sobre o Zabbix nesta parte de monitoramento do VMWare ESXi?
Interessante este template de monitoramento que você comentou.
Valeu.
Abraço.
Opa, tudo bem MrcS?
Tu sabe de algum material, algum link para me indicar sobre o Zabbix nesta parte de monitoramento do VMWare ESXi?
Interessante este template de monitoramento que você comentou.
Valeu.
Abraço.
[6] Comentário enviado por clzera em 25/01/2016 - 11:29h
Favoritado, esse Ends é o bicho! Sempre me ajuda com diversas questões. Abraços amigo!
Favoritado, esse Ends é o bicho! Sempre me ajuda com diversas questões. Abraços amigo!
[7] Comentário enviado por xclaudin em 01/02/2016 - 11:43h
Muito bom!
Este cenário é muito top!
Estou prestes a concluir um porém usando Citrix.
Citrix > PfSense > FreeNas
Tive (ainda estou tendo) muitos problemas com pfsense virtualizado no ambiente Xen.
Muito bom!
Este cenário é muito top!
Estou prestes a concluir um porém usando Citrix.
Citrix > PfSense > FreeNas
Tive (ainda estou tendo) muitos problemas com pfsense virtualizado no ambiente Xen.
[8] Comentário enviado por Ends em 02/02/2016 - 13:57h
Opa. Tudo bem xclaudin?
Cara, escreve aqui no VOL essa tua experiência com o Citrix virtualizando pfSense e usando FreeNAS.
Não estudei afundo o Xen Server ainda. Mas pretendo, assim que estiver com equipamentos "disponíveis" no laboratório.
O pfSense no ESXi, da forma que coloquei aqui no artigo, funciona super bem. Já estou usando a mais de ano em clientes e sem problemas.
Se pudermos ajudar, posta ai nos comentários.
Boa sorte.
Opa. Tudo bem xclaudin?
Cara, escreve aqui no VOL essa tua experiência com o Citrix virtualizando pfSense e usando FreeNAS.
Não estudei afundo o Xen Server ainda. Mas pretendo, assim que estiver com equipamentos "disponíveis" no laboratório.
O pfSense no ESXi, da forma que coloquei aqui no artigo, funciona super bem. Já estou usando a mais de ano em clientes e sem problemas.
Se pudermos ajudar, posta ai nos comentários.
Boa sorte.
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
[10] Comentário enviado por clzera em 24/02/2016 - 15:14h
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
[11] Comentário enviado por clzera em 24/02/2016 - 16:52h
[10] Comentário enviado por clzera em 24/02/2016 - 15:14h
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
Ends, já resolvi. Foi uma bobeira minha aqui, no script eu coloquei uma letra que não existe. rsss
Testando..... Qualquer novidade te aviso.
[10] Comentário enviado por clzera em 24/02/2016 - 15:14h
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
Ends, já resolvi. Foi uma bobeira minha aqui, no script eu coloquei uma letra que não existe. rsss
Testando..... Qualquer novidade te aviso.
[12] Comentário enviado por Ends em 24/02/2016 - 23:44h
[11] Comentário enviado por clzera em 24/02/2016 - 16:52h
[10] Comentário enviado por clzera em 24/02/2016 - 15:14h
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
Ends, já resolvi. Foi uma bobeira minha aqui, no script eu coloquei uma letra que não existe. rsss
Testando..... Qualquer novidade te aviso.
Pois é Marcelo. Tava olhando a mensagem... Datastore not found. Não estava encontrando o volume/caminho que você especificou no ghettoVCB.sh. O ideal é sempre fazer um teste manual do comando antes de agendar ele no CRON com os parâmetros ">/dev/null" para não ter saída de tela (que o CRON não permite).
Tudo certo então! Qualquer coisa, dá um toque ai.
Abraço...
[11] Comentário enviado por clzera em 24/02/2016 - 16:52h
[10] Comentário enviado por clzera em 24/02/2016 - 15:14h
[9] Comentário enviado por Ends em 02/02/2016 - 13:59h
E ai Marcelo (clzera)
Blz cara?
E os BOs nos clientes? Tudo resolvido?
Valeu brother.
Abração...
Fala Ends, blz cara? Ei os b.os estão sempre por ai né, por enquanto esta tudo ok! rsss
Estou implementando aqui no serviço esse esquema de bkp das vms, consegui fazer tudo haha, só que peguei 2 b.os que são os seguintes:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' >dev/null
No comando acima, acontece o seguinte:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines' > dev/null
dev/null: No such file or directory.
E se eu executar o comando sem o "> dev/null" o script inicia normal, mas da essa zika:
ssh root@192.168.1.172 './vmfs/volumes/datastore1/SCRIPTS/ghettoVCB.sh -f /vmfs/volumes/datastore1/SCRIPTS/machines'
Logging output to "/tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log" ...
2016-02-24 05:37:24 -- info: ============================== ghettoVCB LOG START ==============================
2016-02-24 05:37:24 -- info: CONFIG - VERSION = 2015_05_06_1
2016-02-24 05:37:24 -- info: CONFIG - GHETTOVCB_PID = 6462832
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/VMBackupsNAS/backups
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1
2016-02-24 05:37:24 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2016-02-24_05-37-24
2016-02-24 05:37:24 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2016-02-24 05:37:24 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2016-02-24 05:37:24 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2016-02-24 05:37:24 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2016-02-24 05:37:24 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2016-02-24 05:37:24 -- info: CONFIG - LOG_LEVEL = info
2016-02-24 05:37:24 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2016-02-24_05-37-24-6462832.log
2016-02-24 05:37:24 -- info: CONFIG - ENABLE_COMPRESSION = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2016-02-24 05:37:24 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2016-02-24 05:37:24 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2016-02-24 05:37:24 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2016-02-24 05:37:24 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - VM_STARTUP_ORDER =
2016-02-24 05:37:24 -- info: CONFIG - RSYNC_LINK = 0
2016-02-24 05:37:24 -- info: CONFIG - EMAIL_LOG = 0
2016-02-24 05:37:24 -- info:
Datastore not found.
Datastore not found.
Datastore not found.
mkdir: cannot create directory '/vmfs/volumes/VMBackupsNAS/': Operation not permitted
2016-02-24 05:37:26 -- info: Unable to create "/vmfs/volumes/VMBackupsNAS/backups/FIREWALL2"! - Ensure VM_BACKUP_VOLUME was defined correctly
Help novamente meu brother! kkkkkkkkkkkkkkk
Ends, já resolvi. Foi uma bobeira minha aqui, no script eu coloquei uma letra que não existe. rsss
Testando..... Qualquer novidade te aviso.
Pois é Marcelo. Tava olhando a mensagem... Datastore not found. Não estava encontrando o volume/caminho que você especificou no ghettoVCB.sh. O ideal é sempre fazer um teste manual do comando antes de agendar ele no CRON com os parâmetros ">/dev/null" para não ter saída de tela (que o CRON não permite).
Tudo certo então! Qualquer coisa, dá um toque ai.
Abraço...
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Máquina perereca - até onde é possível o uso de Linux?
Mitigação - O que é e quando é "seguro" desabilitar
Atualizar Debian Online de uma Versão para outra
A arte e a prática da Disciplina a longo prazo
Topgrade - Atualize seu sistema Linux inteiro com um único comando
Dicas
Como anda a saúde do disco rígido?
Reescalando a tela hd para fullhd com o xrandr
Tópicos
Debian 13 "trixie&... lançado! (2)
Rede Windows / Linux Mint- pastas e arquivos somente como leitura (4)
Agora temos uma assistente virtual no fórum!!! (252)
Top 10 do mês
-
Xerxes
1° lugar - 74.869 pts -
Fábio Berbert de Paula
2° lugar - 47.956 pts -
Buckminster
3° lugar - 19.839 pts -
Mauricio Ferrari
4° lugar - 16.315 pts -
Daniel Lara Souza
5° lugar - 15.032 pts -
Alberto Federman Neto.
6° lugar - 14.532 pts -
edps
7° lugar - 13.723 pts -
Andre (pinduvoz)
8° lugar - 13.522 pts -
Diego Mendes Rodrigues
9° lugar - 12.534 pts -
Sidnei Serra
10° lugar - 12.827 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
