Backup do VMM para o Google Drive: Exportação agendada, sincronização na nuvem e um único script de renomeação.

Um backup VMM que reside apenas no mesmo NAS que a máquina virtual não é realmente um backup. Se esse servidor falhar, ambas as cópias falham junto. Este armazenamento é executado como um convidado Virtual DSM no Synology Virtual Machine Manager, e nosso backup VMM externo é construído a partir de duas ferramentas gratuitas que acompanham o DSM: exportação agendada no Virtual Machine Manager e sincronização na nuvem com o Google Drive. A configuração levou uma tarde. Descobrir por que ele havia parado de funcionar silenciosamente levou mais tempo, e essa parte é a razão pela qual este artigo de Introdução à Hospedagem NAS existe. Abaixo está a configuração 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óprias exportações revelou.

Ponto SynoPower Club: Todo engenheiro de suporte tem uma história sobre o cliente cujos backups funcionaram perfeitamente por um ano e depois não restauraram nada. Eu não esperava escrever uma sobre a nossa própria empresa. Nosso trabalho de backup do VMM parecia perfeitamente saudável na interface, mas um host havia acumulado um terabyte de arquivos exportados que nunca conseguia limpar, e o outro não havia gerado um único arquivo em treze dias. Nada estava oculto. Estava tudo em um log que ninguém lê. A correção levou uma hora; a lição é verificar se os arquivos realmente existem onde você pensa que estão, de acordo com uma programação, como qualquer outra tarefa.

O que um backup completo do VMM precisa #

O Virtual Machine Manager oferece três camadas de proteção, e cada uma delas cobre uma falha diferente. Um bom plano de backup de VMM utiliza mais de uma.

Camada	Onde a cópia está localizada	Contra o que protege
Instantâneos	Mesmo volume que o convidado	Uma atualização com problemas ou um erro no sistema operacional convidado.
Replicação (VMM Pro)	Outro NAS no cluster	Um NAS apresentou falha, com recuperação rápida no outro host.
Exportação agendada + Sincronização na nuvem	Uma conta na nuvem fora do site	Perda total do site: incêndio, roubo, ransomware na rede local (LAN).

Já replicamos seis convidados para um anfitrião em espera, conforme descrito em nosso artigo sobre o assunto. cluster de máquinas virtuais Synology de três nós. A replicação mantém uma cópia dentro do sistema. A camada de exportação é responsável por manter uma cópia fora dele.

Como funciona a exportação agendada do VMM #

Para um backup de VMM, a exportação agendada grava uma cópia completa da máquina virtual, incluindo discos e configuração, como um único arquivo OVA em uma pasta compartilhada. Você escolhe a pasta de destino, o modo de exportação, a frequência (diária, semanal ou mensal) e quantos dos arquivos mais recentes deseja manter. As exportações são executadas enquanto a máquina virtual está em execução.

Duas regras são fáceis de passar despercebidas. Primeiro, a exportação é configurada e gravada no host onde o convidado está localizado. armazenar O que importa é onde o sistema está sendo executado, não onde ele está localizado. Em um cluster, um sistema convidado pode estar em execução em um NAS enquanto seus discos estão em outro, e o Virtual Machine Manager desabilita a opção de exportação agendada no host incorreto. Em segundo lugar, o agendamento usa o relógio do host de armazenamento.

A caixa de diálogo também mostra o estado consistente. Sem a ferramenta Guest Tool Synology instalada no sistema convidado, as exportações são consistentes em caso de falha, o mesmo estado de quando o cabo de alimentação é desconectado. Isso é adequado para a maioria das cargas de trabalho, e a instalação da Guest Tool atualiza o sistema para um estado consistente com o sistema de arquivos.

Por que a Sincronização na Nuvem ignora arquivos de backup do VMM? #

O próximo passo óbvio seria direcionar o Cloud Sync para a pasta de exportação e deixar que ele enviasse tudo para o Google Drive. Fizemos exatamente isso, e os arquivos de backup do VMM nunca chegaram.

O motivo é o nome do arquivo. O Virtual Machine Manager nomeia cada exportação com um carimbo de data/hora que contém dois pontos:

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova

O Cloud Sync não carregou esses nomes para o nosso Google Drive, então todas as exportações permaneceram locais. O arquivo é válido; o problema está no caractere. Como o formato do carimbo de data/hora da exportação não pode ser alterado no Virtual Machine Manager, a correção precisa ser feita entre a exportação e o upload.

Curiosamente, apenas as exportações agendadas contêm o registro de data e hora. Uma exportação manual feita a partir do mesmo menu é salva simplesmente com o nome do convidado, como por exemplo: spc_4C8G.ova, E o Cloud Sync faz o upload sem problemas. É por isso que um teste manual rápido pode fazer com que toda a cadeia pareça estar funcionando corretamente, enquanto a programação noturna nunca chega à nuvem.

Como configurar um backup do VMM para o Google Drive em 4 etapas #

Esta é a configuração de backup VMM em funcionamento em cada host que armazena máquinas virtuais. Ela requer o Virtual Machine Manager, o Cloud Sync e uma conta do Google; nenhum deles requer o VMM Pro.

O script de renomeação por trás do nosso backup do VMM #

O script é o único componente personalizado da cadeia de backup do VMM e realiza duas funções. Ele renomeia cada exportação concluída, substituindo os dois pontos por hífens, e mantém apenas as cópias mais recentes de cada máquina virtual na pasta de exportação. Ele só altera arquivos que não foram modificados nos últimos quinze minutos, portanto, nunca renomeia uma exportação que ainda está sendo gravada.

#!/bin/bash # vm-export-cloud.sh - torna as exportações do VMM carregáveis pelo Cloud Sync. # # Exportações de nomes do VMM " -AAAA-MM-DD HH:MM:SS- .ova". O Cloud Sync não fará upload de nomes que contenham ":", o que também significa que ele nunca altera uma exportação que ainda esteja sendo gravada. Assim que uma exportação for concluída, ela será renomeada no local, com ":" substituído por "-", para que o Cloud Sync a reconheça e, em seguida, mantenha apenas as exportações renomeadas mais recentes por convidado. (O próprio sistema de retenção do VMM não consegue mais visualizar arquivos renomeados, portanto, a retenção é 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ção 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ção) $*"; fi; } [ -d "$DIR" ] || { say "ERRO: pasta de exportação ausente: $DIR"; exit 1; } # 1. renomear exportações 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ções renomeadas mais recentes por convidado (o carimbo de data/hora está 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ém do $KEEP mais recente): $old" run rm -f -- "$DIR/$old" done say "concluído: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exporta em $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

Execute o comando sem o último argumento primeiro. Nesse modo, ele apenas imprime o que seria renomeado e excluído. Assim que a saída estiver correta, agende a execução com o argumento adicional que fará com que ela execute a ação desejada. Nossa tarefa do Agendador de Tarefas é executada a cada hora como root com um comando como este, uma tarefa por pasta de exportação:

bash /volume1/@vm-export-cloud/vm-export-cloud.sh "/volume3/VM_BK_Export" 3 --apply

Um efeito colateral útil da regra dos dois pontos: o Cloud Sync não consegue enviar um arquivo exportado até que o script o renomeie, e o script só renomeia arquivos finalizados. Arquivos exportados parcialmente gravados nunca chegam à nuvem.

Por que o script lida com a retenção de backups do VMM? #

O Virtual Machine Manager possui sua própria configuração de retenção, que funciona registrando cada exportação criada. Assim que o script renomeia um arquivo, o Virtual Machine Manager deixa de reconhecê-lo e nunca o exclui. Portanto, a retenção passa a ser gerenciada pelo script, que contabiliza as cópias por convidado a partir do carimbo de data/hora no nome do arquivo.

Na seção de Sincronização na Nuvem, uma única caixa de seleção define o que acontece no Google Drive. A sua redação é fácil de ser mal interpretada: Não remova arquivos da pasta de destino quando eles forem removidos da pasta de origem.. Deixe desmarcado e o Google Drive espelhará o NAS, mantendo as mesmas três cópias. Marque e a nuvem manterá todos os arquivos exportados já enviados, o que é a opção mais segura contra ransomware, mas o armazenamento cresce até que você o limpe manualmente.

O que revelou uma auditoria das nossas próprias exportações #

Antes dessa configuração, nosso backup do VMM estava em execução em ambos os hosts de produção por cerca de um mês. A verificação dos arquivos, em vez do painel de controle, revelou três falhas distintas.

• A retenção foi interrompida silenciosamente em um dos hosts. O pequeno banco de dados que o Virtual Machine Manager usa para rastrear exportações não pôde ser criado na pasta de exportação, então cada execução registrava um erro e nenhuma exportação antiga era excluída. Um host acumulou um terabyte de arquivos OVA e atingiu a capacidade máxima do 97%.
• O maior cliente parou de exportar. A exportação de 84 GB não cabia mais no espaço disponível, então falhou por três dias seguidos sem que percebêssemos qualquer alerta.
• Três horários que não levam a lugar nenhum. Uma alteração nas configurações deixou três agendamentos de exportação com um destino vazio. A partir desse dia, o sistema registrou um nome de compartilhamento inválido a cada minuto, mais de 20.000 vezes, e nada foi exportado, incluindo o agendamento para esta loja.

Nada disso se manifestou como uma falha de backup do VMM em uso normal. As máquinas virtuais funcionavam, a loja recebia pedidos e a replicação mantinha uma cópia no host de espera. A camada de exportação, a única cópia externa, simplesmente parou. Agora verificamos as pastas de exportação e a lista de uploads do Cloud Sync após cada alteração no agendamento.

Planejamento de largura de banda e armazenamento para um backup VMM #

Cada exportação de backup do VMM é uma cópia completa, não incremental, portanto, ajuste o tamanho dos arquivos antes de escolher um agendamento. Nossos clientes variam de um pequeno site de 5 GB a um site de parceiro de 84 GB, e a exportação da própria loja tem cerca de 7 GB. Em todos os clientes, um agendamento diário resulta em uploads bem acima de 100 GB por dia.

O Google Drive permite que cada usuário faça upload de 750 GB em 24 horas, com arquivos de até 5 TB, então o limite raramente é o problema. O tempo de upload e o armazenamento em nuvem são. Manter três cópias de cada máquina virtual na nuvem exige três vezes o total diário de espaço no Drive, e ainda mais se a nuvem mantiver todas as cópias. Para máquinas virtuais grandes e com poucas alterações, uma exportação semanal costuma ser suficiente, especialmente quando a replicação já cobre a recuperação diária.

Por que criamos backups nas ferramentas Synology #

Tudo nesta cadeia de backup VMM é fornecido com o DSM. O Virtual Machine Manager exporta as máquinas virtuais, o Cloud Sync as carrega, o Agendador de Tarefas executa o script e as mesmas unidades NAS armazenam nossos arquivos e executam o serviço de armazenamento. Não há necessidade de licenciar um agente de backup por máquina virtual nem manter um servidor de backup separado.

Os componentes pelos quais pagamos são aqueles que adicionam proteção entre os hosts: um Licença VMM Pro para replicação para o servidor de espera, e Licenças Virtual DSM para os convidados extras da DSM. Se você está decidindo qual edição precisa, nosso Comparação entre Virtual Machine Manager e VMM Pro cobre isso.

Limitações e ressalvas do backup do VMM #

Uma exportação é uma cópia completa em um determinado momento. Sem a Ferramenta de Convidado, ela é consistente em caso de falha, portanto, os bancos de dados dentro da máquina virtual são recuperados da mesma forma que seriam após uma queda de energia. Teste a restauração da sua máquina virtual mais importante pelo menos uma vez.

Restaurar um backup do VMM da nuvem significa primeiro baixar o arquivo inteiro. Uma exportação de 84 GB leva horas em uma conexão de escritório típica, portanto, a cópia na nuvem serve para desastres, não para erros do dia a dia. Snapshots e replicação resolvem esses problemas muito mais rapidamente.

O Cloud Sync pode criptografar arquivos antes do upload, e recomendamos ativá-lo para convidados que armazenam dados de clientes. Guarde a senha de criptografia em um local que não dependa do NAS que você está protegendo.

Por fim, o script de renomeação depende do formato do nome de exportação. Se uma futura atualização do Virtual Machine Manager alterar esse formato, o script deixará de corresponder aos arquivos. O modo de teste é a maneira mais rápida de confirmar se o script ainda reconhece suas exportações após uma atualização.

Perguntas frequentes #

Referências e tutoriais em vídeo #

• Máquina virtual em Virtual Machine Manager, o artigo do centro de conhecimento que aborda a exportação.
• Ajuda da Sincronização na Nuvem, incluindo a direção da sincronização e as configurações da tarefa.
• Limites de armazenamento e upload do Google Drive, com limite diário de upload de 750 GB.
• Documento técnico do VMM Synology, sobre camadas de proteção de dados para máquinas virtuais.
• Agendador de tarefas no DSM, para executar o script de renomeação como uma tarefa agendada.

Vídeos sobre as ferramentas desta cadeia: Cloud Sync e exportação e migração de máquinas virtuais em um NAS Synology.

Deseja adicionar replicação entre hosts além da sua cópia remota? Obtenha um Licença VMM Pro, Ou leia como o restante deste site funciona. nossa série Hospedagem NAS 101.