Servidor de cópias de segurança remoto vs armazenamento de objetos na cloud para cópias de segurança de VMs domésticas

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Um servidor de cópias de segurança remoto é normalmente o melhor destino para VMs domésticas quando pretende restauros completos rápidos, tarefas incrementais frequentes, comportamento previsível do repositório e controlo sobre toda a infraestrutura de recuperação. O armazenamento de objetos na cloud é normalmente mais indicado quando a separação geográfica e a remoção de um segundo servidor da sua lista de manutenção são mais importantes do que o controlo local. A decisão depende do tamanho do restauro, da largura de banda de carregamento, do comportamento da recuperação do armazenamento de objetos, dos requisitos de imutabilidade e da quantidade de infraestrutura que está disposto a operar fora do local.

Defina a tarefa de recuperação da VM antes de escolher o destino

Uma cópia de segurança de uma VM não é apenas uma pasta de documentos. A recuperação de um hipervisor doméstico que falhou pode exigir imagens de disco, configuração da VM, metadados do convidado, material de encriptação, notas de rede e capacidade de processamento suficiente para reconstruir várias VMs de grandes dimensões pela ordem correta.

A Proxmox documenta que a sua integração de cópias de segurança pode criar cópias de segurança agendadas de máquinas virtuais e contentores, enquanto o Proxmox Backup Server acrescenta uma infraestrutura de cópias de segurança deduplicada. Assim, a escolha do destino passa a fazer parte de um fluxo de recuperação integral de VMs, e não apenas de um sistema genérico de armazenamento de ficheiros.

Defina primeiro o resultado controlado: quantos terabytes têm de ser recuperados, quanto tempo pode passar até a primeira VM crítica arrancar e se a perda total do local faz parte do modelo de ameaças. Essas respostas determinam se um servidor acessível ou um armazenamento de objetos operado por um fornecedor resolve a restrição mais difícil.

Um servidor de cópias de segurança remoto é a melhor opção quando os grandes restauros têm de começar imediatamente

Um servidor situado noutro local de confiança pode manter o formato das cópias de segurança online e pronto para restauro, sem esperar que uma camada de arquivo seja reidratada. Se a ligação entre os locais for suficientemente rápida, pode também suportar incrementais frequentes e verificação do repositório utilizando as mesmas ferramentas do laboratório doméstico principal.

Este modelo dá-lhe controlo direto sobre a cache, os caminhos de rede, a retenção, a substituição de discos e o software do repositório. É especialmente útil quando prevê restaurar VMs completas em vez de apenas alguns ficheiros, porque o destino de recuperação pode permanecer continuamente acessível.

O custo oculto é que a “cópia de segurança fora do local” passa a ser outro servidor que lhe pertence. Alguém tem de garantir energia, rede, espaço físico, atualizações, monitorização, substituição de unidades e um plano de recuperação para o próprio nó remoto. Esta opção só é atrativa se esse trabalho operacional proporcionar uma verdadeira vantagem de RTO.

O armazenamento de objetos na cloud é a melhor opção quando eliminar o segundo local é a prioridade

O armazenamento de objetos substitui o equipamento remoto, os discos, a UPS e a dependência da rede doméstica por um serviço de armazenamento gerido pelo fornecedor. Isto pode criar uma separação geográfica clara sem pedir a um amigo ou familiar que aloje uma segunda máquina.

O Amazon S3 suporta políticas de ciclo de vida que movem ou eliminam objetos de cópia de segurança, enquanto outros fornecedores de objetos disponibilizam mecanismos semelhantes. O ganho operacional importante não está na lista de funcionalidades de um fornecedor específico; está no facto de a substituição de suportes e a manutenção do hardware de armazenamento deixarem de ser tarefas suas.

O armazenamento de objetos na cloud é mais adequado quando o restauro é raro, o carregamento através da WAN é aceitável e a aplicação de cópias de segurança consegue utilizar o fornecedor de forma segura. Torna-se menos atrativo quando os restauros completos de vários terabytes são críticos em termos de tempo ou quando a recuperação pelo fornecedor e o comportamento da transferência de rede dominam a janela de recuperação.

A classe de recuperação pode alterar o RTO da cloud antes mesmo de começar a transferência

Nem todos os objetos na cloud podem ser lidos instantaneamente. As classes de arquivo de baixo custo podem exigir um pedido de restauro antes de os dados ficarem disponíveis, pelo que “armazenado na cloud” não significa automaticamente “pronto para ser transmitido de volta agora”.

A AWS documenta janelas de recuperação que variam entre minutos e muitas horas para as camadas de arquivo. Se um repositório de VMs for colocado numa classe de arquivo, esse tempo de espera faz parte do RTO, antes mesmo de ser contabilizado o tempo de transferência através da Internet.

Utilize armazenamento imediatamente acessível para os pontos de recuperação que têm de arrancar rapidamente e arquive apenas as gerações cujo RTO permita atrasos. Se precisar simultaneamente do baixo custo de armazenamento de um arquivo profundo e da velocidade de um servidor remoto pronto a utilizar, os requisitos entram em conflito e devem ser divididos por camadas.

A imutabilidade e a separação das credenciais podem inverter a opção mais segura

Um servidor remoto que utilize as mesmas credenciais de administrador do laboratório principal pode ser mais fácil de gerir, mas também mais fácil de destruir a partir do mesmo plano de controlo comprometido. O armazenamento de objetos na cloud pode criar uma barreira mais forte se os bloqueios de retenção e as credenciais limitadas forem configurados corretamente.

A Backblaze documenta o Object Lock para restringir a eliminação ou modificação durante a retenção, juntamente com controlos do ciclo de vida. O valor resulta de uma barreira de retenção aplicada de forma independente, e não da palavra “cloud”.

Um servidor remoto também pode alcançar uma separação forte através de repositórios apenas para anexação, contas distintas, restrições de firewall e credenciais de recuperação offline. Escolha a arquitetura cujo isolamento consiga realmente comprovar num cenário em que o sistema principal esteja comprometido.

A economia do armazenamento de objetos e as políticas de rede são importantes à medida que o repositório cresce

A cloud elimina a compra de unidades, mas introduz dimensões de faturação do fornecedor, como capacidade armazenada, operações, classe de armazenamento e, por vezes, recuperação ou saída de dados. Um servidor remoto transfere mais custos iniciais para o hardware, os discos, a energia e o trabalho de substituição.

A Cloudflare R2 publica as dimensões de faturação do armazenamento e dos pedidos, ilustrando por que motivo o armazenamento de objetos deve ser modelado como um serviço contínuo e não como uma compra única de discos. Não fixe o preço atual do fornecedor numa arquitetura que irá conservar anos de histórico de VMs.

O servidor remoto torna-se mais atrativo à medida que aumentam o volume de restauros e os acessos repetidos, desde que o local e o hardware permaneçam fiáveis. A cloud torna-se mais atrativa quando o repositório é maioritariamente de escrita única, raramente restaurado, e o valor de evitar outro sistema físico é elevado.

Testar o restauro é mais importante do que o rótulo do destino da cópia de segurança

Um servidor remoto pode falhar silenciosamente devido a discos defeituosos, credenciais desatualizadas, sincronização interrompida ou metadados de VM em falta. O armazenamento de objetos na cloud pode falhar operacionalmente devido a credenciais expiradas, software de repositório incompatível, chaves de encriptação esquecidas ou pressupostos de recuperação que nunca foram testados.

A documentação do Restic recomenda utilizar o restauro de um instantâneo completo em vez do acesso apenas para consulta durante recuperações de grandes dimensões. O princípio aplica-se independentemente do destino: execute um verdadeiro exercício de recuperação de uma VM, em vez de se limitar a listar o repositório.

A comparação de recuperação do ZimaSpace sobre as dependências de recuperação do anfitrião no armazenamento virtualizado é um complemento útil. Deixe de comparar destinos assim que uma arquitetura cumprir o RTO testado, o requisito de isolamento e o orçamento de manutenção, com um caminho de restauro documentado.

Escolha o destino que torna banal o pior restauro aceitável

Escolha um servidor de cópias de segurança remoto quando os grandes restauros de VMs tiverem de começar sem o atraso de um arquivo do fornecedor, valorizar uma integração estreita com a infraestrutura de cópias de segurança e estiver disposto a manter um segundo sistema físico e um segundo local.

Escolha o armazenamento de objetos na cloud quando a separação geográfica e a eliminação da manutenção de hardware remoto forem mais importantes do que o controlo máximo, e quando o volume de restauro previsto se adequar ao modelo de acesso do fornecedor e à sua ligação à Internet.

Para VMs domésticas críticas, pode justificar-se uma solução híbrida: pontos de recuperação recentes num servidor remoto pronto a utilizar e gerações imutáveis mais antigas no armazenamento de objetos. Acrescente essa complexidade apenas quando as duas camadas protegerem requisitos de RTO ou de falha genuinamente diferentes.

Comparações de Produtos

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.