{"id":21498,"date":"2026-09-27T22:09:37","date_gmt":"2026-09-27T14:09:37","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21498"},"modified":"2026-09-27T22:09:43","modified_gmt":"2026-09-27T14:09:43","password":"","slug":"vmm-backup-google-drive-cloud-sync","status":"publish","type":"docs","link":"https:\/\/synopower.club\/pt\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"Backup do VMM para o Google Drive: Exporta\u00e7\u00e3o agendada, sincroniza\u00e7\u00e3o na nuvem e um \u00fanico script de renomea\u00e7\u00e3o."},"content":{"rendered":"

Um backup VMM que reside apenas no mesmo NAS que a m\u00e1quina virtual n\u00e3o \u00e9 realmente um backup. Se esse servidor falhar, ambas as c\u00f3pias falham junto. Este armazenamento \u00e9 executado como um convidado Virtual DSM no Synology Virtual Machine Manager, e nosso backup VMM externo \u00e9 constru\u00eddo a partir de duas ferramentas gratuitas que acompanham o DSM: exporta\u00e7\u00e3o agendada no Virtual Machine Manager e sincroniza\u00e7\u00e3o na nuvem com o Google Drive. A configura\u00e7\u00e3o levou uma tarde. Descobrir por que ele havia parado de funcionar silenciosamente levou mais tempo, e essa parte \u00e9 a raz\u00e3o pela qual este artigo de Introdu\u00e7\u00e3o \u00e0 Hospedagem NAS existe. Abaixo est\u00e1 a configura\u00e7\u00e3o que funciona, a peculiaridade do nome do arquivo que a quebra, o pequeno script que a corrige e o que uma auditoria de nossas pr\u00f3prias exporta\u00e7\u00f5es revelou.<\/p>\n\n\n\n

\n

Ponto SynoPower Club:<\/strong> Todo engenheiro de suporte tem uma hist\u00f3ria sobre o cliente cujos backups funcionaram perfeitamente por um ano e depois n\u00e3o restauraram nada. Eu n\u00e3o esperava escrever uma sobre a nossa pr\u00f3pria empresa. Nosso trabalho de backup do VMM parecia perfeitamente saud\u00e1vel na interface, mas um host havia acumulado um terabyte de arquivos exportados que nunca conseguia limpar, e o outro n\u00e3o havia gerado um \u00fanico arquivo em treze dias. Nada estava oculto. Estava tudo em um log que ningu\u00e9m l\u00ea. A corre\u00e7\u00e3o levou uma hora; a li\u00e7\u00e3o \u00e9 verificar se os arquivos realmente existem onde voc\u00ea pensa que est\u00e3o, de acordo com uma programa\u00e7\u00e3o, como qualquer outra tarefa.<\/p>\n<\/blockquote>\n\n\n\n

O que um backup completo do VMM precisa<\/h2>\n\n\n\n

O Virtual Machine Manager oferece tr\u00eas camadas de prote\u00e7\u00e3o, e cada uma delas cobre uma falha diferente. Um bom plano de backup de VMM utiliza mais de uma.<\/p>\n\n\n\n

Camada<\/th>Onde a c\u00f3pia est\u00e1 localizada<\/th>Contra o que protege<\/th><\/tr><\/thead>
Instant\u00e2neos<\/td>Mesmo volume que o convidado<\/td>Uma atualiza\u00e7\u00e3o com problemas ou um erro no sistema operacional convidado.<\/td><\/tr>
Replica\u00e7\u00e3o (VMM Pro)<\/td>Outro NAS no cluster<\/td>Um NAS apresentou falha, com recupera\u00e7\u00e3o r\u00e1pida no outro host.<\/td><\/tr>
Exporta\u00e7\u00e3o agendada + Sincroniza\u00e7\u00e3o na nuvem<\/td>Uma conta na nuvem fora do site<\/td>Perda total do site: inc\u00eandio, roubo, ransomware na rede local (LAN).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

J\u00e1 replicamos seis convidados para um anfitri\u00e3o em espera, conforme descrito em nosso artigo sobre o assunto. cluster de m\u00e1quinas virtuais Synology de tr\u00eas n\u00f3s<\/a>. A replica\u00e7\u00e3o mant\u00e9m uma c\u00f3pia dentro do sistema. A camada de exporta\u00e7\u00e3o \u00e9 respons\u00e1vel por manter uma c\u00f3pia fora dele.<\/p>\n\n\n\n

Como funciona a exporta\u00e7\u00e3o agendada do VMM<\/h2>\n\n\n\n

Para um backup de VMM, a exporta\u00e7\u00e3o agendada grava uma c\u00f3pia completa da m\u00e1quina virtual, incluindo discos e configura\u00e7\u00e3o, como um \u00fanico arquivo OVA em uma pasta compartilhada. Voc\u00ea escolhe a pasta de destino, o modo de exporta\u00e7\u00e3o, a frequ\u00eancia (di\u00e1ria, semanal ou mensal) e quantos dos arquivos mais recentes deseja manter. As exporta\u00e7\u00f5es s\u00e3o executadas enquanto a m\u00e1quina virtual est\u00e1 em execu\u00e7\u00e3o.<\/p>\n\n\n\n

Duas regras s\u00e3o f\u00e1ceis de passar despercebidas. Primeiro, a exporta\u00e7\u00e3o \u00e9 configurada e gravada no host onde o convidado est\u00e1 localizado. armazenar<\/strong> O que importa \u00e9 onde o sistema est\u00e1 sendo executado, n\u00e3o onde ele est\u00e1 localizado. Em um cluster, um sistema convidado pode estar em execu\u00e7\u00e3o em um NAS enquanto seus discos est\u00e3o em outro, e o Virtual Machine Manager desabilita a op\u00e7\u00e3o de exporta\u00e7\u00e3o agendada no host incorreto. Em segundo lugar, o agendamento usa o rel\u00f3gio do host de armazenamento.<\/p>\n\n\n\n

\"Configura\u00e7\u00f5es
Nossas configura\u00e7\u00f5es de exporta\u00e7\u00e3o programadas: uma pasta compartilhada como destino, diariamente \u00e0s 08:00, mantendo os tr\u00eas arquivos mais recentes.<\/figcaption><\/figure>\n\n\n\n

A caixa de di\u00e1logo tamb\u00e9m mostra o estado consistente. Sem a ferramenta Guest Tool Synology instalada no sistema convidado, as exporta\u00e7\u00f5es s\u00e3o consistentes em caso de falha, o mesmo estado de quando o cabo de alimenta\u00e7\u00e3o \u00e9 desconectado. Isso \u00e9 adequado para a maioria das cargas de trabalho, e a instala\u00e7\u00e3o da Guest Tool atualiza o sistema para um estado consistente com o sistema de arquivos.<\/p>\n\n\n\n

Por que a Sincroniza\u00e7\u00e3o na Nuvem ignora arquivos de backup do VMM?<\/h2>\n\n\n\n

O pr\u00f3ximo passo \u00f3bvio seria direcionar o Cloud Sync para a pasta de exporta\u00e7\u00e3o e deixar que ele enviasse tudo para o Google Drive. Fizemos exatamente isso, e os arquivos de backup do VMM nunca chegaram.<\/p>\n\n\n\n

O motivo \u00e9 o nome do arquivo. O Virtual Machine Manager nomeia cada exporta\u00e7\u00e3o com um carimbo de data\/hora que cont\u00e9m dois pontos:<\/p>\n\n\n\n

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova<\/code><\/pre>\n\n\n\n
O Cloud Sync n\u00e3o carregou esses nomes para o nosso Google Drive, ent\u00e3o todas as exporta\u00e7\u00f5es permaneceram locais. O arquivo \u00e9 v\u00e1lido; o problema est\u00e1 no caractere. Como o formato do carimbo de data\/hora da exporta\u00e7\u00e3o n\u00e3o pode ser alterado no Virtual Machine Manager, a corre\u00e7\u00e3o precisa ser feita entre a exporta\u00e7\u00e3o e o upload.<\/p>\n\n\n\n
Curiosamente, apenas as exporta\u00e7\u00f5es agendadas cont\u00eam o registro de data e hora. Uma exporta\u00e7\u00e3o manual feita a partir do mesmo menu \u00e9 salva simplesmente com o nome do convidado, como por exemplo: spc_4C8G.ova<\/code>, E o Cloud Sync faz o upload sem problemas. \u00c9 por isso que um teste manual r\u00e1pido pode fazer com que toda a cadeia pare\u00e7a estar funcionando corretamente, enquanto a programa\u00e7\u00e3o noturna nunca chega \u00e0 nuvem.<\/p>\n\n\n\n
Como configurar um backup do VMM para o Google Drive em 4 etapas<\/h2>\n\n\n\n
Esta \u00e9 a configura\u00e7\u00e3o de backup VMM em funcionamento em cada host que armazena m\u00e1quinas virtuais. Ela requer o Virtual Machine Manager, o Cloud Sync e uma conta do Google; nenhum deles requer o VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Agende a exporta\u00e7\u00e3o.<\/h3>\n
No host que armazena a m\u00e1quina virtual, abra o Virtual Machine Manager, selecione a m\u00e1quina virtual, escolha A\u00e7\u00e3o, Exportar, Agendado, selecione uma pasta compartilhada como destino e defina o hor\u00e1rio. Deixe a configura\u00e7\u00e3o de reten\u00e7\u00e3o com o n\u00famero de c\u00f3pias que voc\u00ea deseja manter localmente.<\/p>\n<\/div>\n<\/div>\n
\n
Criar tarefa de sincroniza\u00e7\u00e3o na nuvem<\/h3>\n
Na Sincroniza\u00e7\u00e3o na Nuvem, conecte o Google Drive e sincronize a pasta compartilhada exportada para uma pasta do Drive. Defina a dire\u00e7\u00e3o para enviar as altera\u00e7\u00f5es locais e marque a op\u00e7\u00e3o para n\u00e3o remover os arquivos no destino quando forem removidos na origem, caso queira que a nuvem mantenha c\u00f3pias antigas.<\/p>\n<\/div>\n<\/div>\n
\n
Adicione o script de renomea\u00e7\u00e3o<\/h3>\n
Salve o script deste artigo no NAS e crie uma tarefa no Agendador de Tarefas para execut\u00e1-lo como root a cada hora. Ele renomeia os arquivos exportados, removendo os dois pontos, e mant\u00e9m as c\u00f3pias mais recentes para cada m\u00e1quina virtual.<\/p>\n<\/div>\n<\/div>\n
\n
Verifique o primeiro envio<\/h3>\n
Ap\u00f3s a pr\u00f3xima exporta\u00e7\u00e3o, confirme se o arquivo renomeado aparece na pasta de exporta\u00e7\u00e3o, se o Cloud Sync o reporta como carregado e se o tamanho do arquivo no Google Drive corresponde ao original.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Configura\u00e7\u00f5es
Nossa tarefa de Sincroniza\u00e7\u00e3o na Nuvem: enviar apenas as altera\u00e7\u00f5es locais, com a op\u00e7\u00e3o marcada para que o Google Drive mantenha as exporta\u00e7\u00f5es depois que o NAS as excluir.<\/figcaption><\/figure>\n\n\n\n
O script de renomea\u00e7\u00e3o por tr\u00e1s do nosso backup do VMM<\/h2>\n\n\n\n
O script \u00e9 o \u00fanico componente personalizado da cadeia de backup do VMM e realiza duas fun\u00e7\u00f5es. Ele renomeia cada exporta\u00e7\u00e3o conclu\u00edda, substituindo os dois pontos por h\u00edfens, e mant\u00e9m apenas as c\u00f3pias mais recentes de cada m\u00e1quina virtual na pasta de exporta\u00e7\u00e3o. Ele s\u00f3 altera arquivos que n\u00e3o foram modificados nos \u00faltimos quinze minutos, portanto, nunca renomeia uma exporta\u00e7\u00e3o que ainda est\u00e1 sendo gravada.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - torna as exporta\u00e7\u00f5es do VMM carreg\u00e1veis pelo Cloud Sync. # # Exporta\u00e7\u00f5es de nomes do VMM " -AAAA-MM-DD HH:MM:SS- .ova". O Cloud Sync n\u00e3o far\u00e1 upload de nomes que contenham ":", o que tamb\u00e9m significa que ele nunca altera uma exporta\u00e7\u00e3o que ainda esteja sendo gravada. Assim que uma exporta\u00e7\u00e3o for conclu\u00edda, ela ser\u00e1 renomeada no local, com ":" substitu\u00eddo por "-", para que o Cloud Sync a reconhe\u00e7a e, em seguida, mantenha apenas as exporta\u00e7\u00f5es renomeadas mais recentes por convidado. (O pr\u00f3prio sistema de reten\u00e7\u00e3o do VMM n\u00e3o consegue mais visualizar arquivos renomeados, portanto, a reten\u00e7\u00e3o \u00e9 feita aqui.) Uso: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Sem --apply, ele apenas imprime o que faria. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 # uma exporta\u00e7\u00e3o finalizada permanece intocada por este longo tempo LOG="$(dirname "$(readlink -f "$0")")\/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (simula\u00e7\u00e3o) $*"; fi; } [ -d "$DIR" ] || { say "ERRO: pasta de exporta\u00e7\u00e3o ausente: $DIR"; exit 1; } # 1. renomear exporta\u00e7\u00f5es finalizadas find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | while IFS= read -r -d '' f; do if command -v fuser >\/dev\/null 2>&1 && fuser -s "$f" 2>\/dev\/null; then say "skip (em uso): $(basename "$f")"; continue fi new="$DIR\/$(basename "$f" | tr ':' '-')" say "rename: $(basename "$f") -> $(basename "$new")" run mv -n "$f" "$new" feito # 2. manter as exporta\u00e7\u00f5es renomeadas mais recentes por convidado (o carimbo de data\/hora est\u00e1 no nome) { find "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n' [ "$APPLY" = "--apply" ] || find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-' } | sort -u | sed -E 's\/^(.*)-([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2})-.*\\.ova$\/\\1\\t\\2\\t&\/' | awk -F'\\t' 'NF==3' | sort -t$'\\t' -k1,1 -k2,2r | awk -F'\\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | while IFS= read -r old; do say "excluir (al\u00e9m do $KEEP mais recente): $old" run rm -f -- "$DIR\/$old" done say "conclu\u00eddo: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exporta em $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')"\"<\/code><\/pre>\n\n\n\n
Execute o comando sem o \u00faltimo argumento primeiro. Nesse modo, ele apenas imprime o que seria renomeado e exclu\u00eddo. Assim que a sa\u00edda estiver correta, agende a execu\u00e7\u00e3o com o argumento adicional que far\u00e1 com que ela execute a a\u00e7\u00e3o desejada. Nossa tarefa do Agendador de Tarefas \u00e9 executada a cada hora como root com um comando como este, uma tarefa por pasta de exporta\u00e7\u00e3o:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh "\/volume3\/VM_BK_Export" 3 --apply<\/code><\/pre>\n\n\n\n
Um efeito colateral \u00fatil da regra dos dois pontos: o Cloud Sync n\u00e3o consegue enviar um arquivo exportado at\u00e9 que o script o renomeie, e o script s\u00f3 renomeia arquivos finalizados. Arquivos exportados parcialmente gravados nunca chegam \u00e0 nuvem.<\/p>\n\n\n\n
Por que o script lida com a reten\u00e7\u00e3o de backups do VMM?<\/h2>\n\n\n\n
O Virtual Machine Manager possui sua pr\u00f3pria configura\u00e7\u00e3o de reten\u00e7\u00e3o, que funciona registrando cada exporta\u00e7\u00e3o criada. Assim que o script renomeia um arquivo, o Virtual Machine Manager deixa de reconhec\u00ea-lo e nunca o exclui. Portanto, a reten\u00e7\u00e3o passa a ser gerenciada pelo script, que contabiliza as c\u00f3pias por convidado a partir do carimbo de data\/hora no nome do arquivo.<\/p>\n\n\n\n
Na se\u00e7\u00e3o de Sincroniza\u00e7\u00e3o na Nuvem, uma \u00fanica caixa de sele\u00e7\u00e3o define o que acontece no Google Drive. A sua reda\u00e7\u00e3o \u00e9 f\u00e1cil de ser mal interpretada: N\u00e3o remova arquivos da pasta de destino quando eles forem removidos da pasta de origem.<\/strong>. Deixe desmarcado e o Google Drive espelhar\u00e1 o NAS, mantendo as mesmas tr\u00eas c\u00f3pias. Marque e a nuvem manter\u00e1 todos os arquivos exportados j\u00e1 enviados, o que \u00e9 a op\u00e7\u00e3o mais segura contra ransomware, mas o armazenamento cresce at\u00e9 que voc\u00ea o limpe manualmente.<\/p>\n\n\n\n
O que revelou uma auditoria das nossas pr\u00f3prias exporta\u00e7\u00f5es<\/h2>\n\n\n\n
Antes dessa configura\u00e7\u00e3o, nosso backup do VMM estava em execu\u00e7\u00e3o em ambos os hosts de produ\u00e7\u00e3o por cerca de um m\u00eas. A verifica\u00e7\u00e3o dos arquivos, em vez do painel de controle, revelou tr\u00eas falhas distintas.<\/p>\n\n\n\n