Backup heterogêneo: como proteger ambientes de TI mistos sem criar lacunas na recuperação

O que é backup heterogêneo?

O backup heterogêneo é uma estratégia que protege diferentes tipos de cargas de trabalho, incluindo servidores físicos, máquinas virtuais, bancos de dados, Kubernetes, aplicativos SaaS e cargas de trabalho na nuvem, sob políticas comuns de recuperação. Destinos comuns de recuperação não exigem métodos de backup idênticos.

Um backup bem-sucedido não garante uma recuperação bem-sucedida. O backup heterogêneo protege diferentes tipos de cargas de trabalho sob objetivos comuns de recuperação. Muitos ambientes de TI corporativos combinam vários sistemas operacionais, hipervisores, bancos de dados, serviços em nuvem e plataformas legadas. Especificamente, é possível encontrar empresas que executam suas operações em servidores Windows e Linux e utilizam máquinas virtuais VMware e Hyper-V. Além disso, essas empresas podem utilizar simultaneamente clusters do Kubernetes, cargas de trabalho na nuvem pública, aplicativos de software como serviço (SaaS), bancos de dados, sistemas de armazenamento conectados à rede e plataformas físicas mais antigas ou Unix, como os mainframes IBM System z (z/OS) e o IBM AIX no Power Systems (ou Oracle Solaris / HP-UX).

Ambientes mistos podem resultar de aquisições, migrações para a nuvem, modernização de aplicativos, retenção de sistemas legados e aquisição descentralizada de tecnologia. Assim, o desafio do backup é como garantir uma recuperação confiável entre sistemas associados a diferentes interfaces de processamento de aplicativos (APIs), mecanismos de consistência, identidades, metadados e modos de falha. Uma API representa regras que permitem que dois componentes de software se comuniquem com base em um conjunto de definições e protocolos.

Uma estratégia de backup heterogêneo utiliza uma arquitetura coordenada de proteção de dados para proteger vários sistemas operacionais, aplicativos, bancos de dados, hipervisores, plataformas de armazenamento e ambientes em nuvem.

A estratégia de backup heterogênea visa estabelecer resultados comuns de recuperação, como objetivos de ponto de recuperação (RPOs), objetivos de tempo de recuperação (RTOs), retenção, imutabilidade, controle de acesso e testes. Os testes de recuperação fazem parte do projeto do backup.

O RPO é a quantidade máxima aceitável de perda de dados que uma organização pode tolerar antes que os negócios sejam prejudicados. O RTO é o período máximo durante o qual uma empresa pode permanecer sem operações antes que a interrupção cause um impacto inaceitável.

Bancos de dados, máquinas virtuais e aplicativos Kubernetes podem compartilhar um RPO ao mesmo tempo em que utilizam diferentes mecanismos de proteção. É essencial padronizar os resultados de recuperação, em vez de forçar todas as cargas de trabalho a seguirem o mesmo processo de backup.

Simultaneamente, a estratégia ajuda a preservar os métodos específicos de cada carga de trabalho — como cargas de trabalho de bancos de dados e máquinas virtuais — necessários para alcançá-los.

É importante ressaltar que, se todas as tarefas em um painel estiverem verdes, isso não significa que uma empresa possa recuperar seus aplicativos. Um backup heterogêneo eficaz padroniza políticas e evidências, respeitando diferenças técnicas, como backups de bancos de dados consistentes com o aplicativo, com logs de transação para recuperação em um ponto no tempo, e backups de imagem no nível do hipervisor para recuperação completa de máquinas virtuais.

O que torna um ambiente de backup heterogêneo?

Um ambiente de backup é heterogêneo quando suas cargas de trabalho exigem métodos diferentes de backup ou recuperação e estão sujeitas a métodos de recuperação distintos. Ambientes de TI mistos exigem métodos de backup específicos para cada carga de trabalho.

Um ambiente misto pode incluir:

• macOS, servidores Unix, Linux, Windows físico
• Máquinas virtuais Proxmox, VMware, Nutanix, Hyper-V, máquina virtual baseada em kernel
• Volumes persistentes, clusters do Kubernetes, manifestos, segredos e metadados de aplicativos
• Bancos de dados (por exemplo, Microsoft SQL Server, Oracle, PostgreSQL, MySQL, SAP HANA, MongoDB)
• Por exemplo, dispositivos NAS e sistemas de arquivos
• Por exemplo, nuvem privada e cargas de trabalho menos comuns ou tecnicamente complexas
• Por exemplo, Salesforce e Microsoft 365
• Mainframes, aplicativos proprietários ou sistemas que não suportam um agente moderno

A infraestrutura representa uma camada. Existem diferentes requisitos de recuperação. Um banco de dados transacional pode perder dados. No entanto, um arquivo pode permitir um objetivo de ponto de recuperação (RPO) de 24 horas. O RPO representa o momento no tempo até o qual os dados devem ser recuperados após uma interrupção.

Para sistemas de manufatura que devem continuar operando durante interrupções na WAN, pode ser necessária uma infraestrutura de recuperação local, mesmo quando a rede de longa distância (WAN) estiver indisponível. Uma rede de longa distância é a tecnologia que conecta seus escritórios, data centers, aplicativos em nuvem e armazenamento em nuvem.

Os períodos de retenção dependem da jurisdição aplicável, do tipo de registro, do contrato e do regime regulatório. E talvez sejam necessários apenas alguns pontos de restauração para um ambiente de desenvolvimento de curta duração.

É por isso que “suporta muitas plataformas” é uma definição incompleta de backup heterogêneo. Uma plataforma pode receber dados de muitas fontes. A recuperação consistente com o aplicativo não é comum a todas as fontes. O mesmo se aplica à recuperação entre plataformas testada, à recuperação de configuração ou à restauração granular.

Por que cargas de trabalho diferentes precisam de métodos de backup diferentes?

Cargas de trabalho diferentes precisam de mecanismos de backup diferentes porque alcançam um estado recuperável de maneiras distintas. É útil padronizar diferentes cargas de trabalho, mas há riscos ocultos associados à uniformidade literal. As classes de carga de trabalho alcançam um estado recuperável de várias maneiras.

Um snapshot do hipervisor pode servir de base para o backup de VM quando o produto de backup também captura a configuração e o estado necessário do aplicativo. Uma API de backup nativa, logs de transação e coordenação de truncamento de logs podem ser necessários para um banco de dados. Um aplicativo Kubernetes pode precisar de dados persistentes e manifestos, recursos personalizados, segredos e informações de dependência.

Uma plataforma de software como serviço (SaaS) expõe apenas os objetos e interfaces de programação de aplicativos (APIs) que seu provedor permite. Uma API representa regras e protocolos, permitindo que diferentes programas de software se comuniquem entre si. Arquivos, estado do sistema e dados de recuperação bare-metal podem ser necessários para um servidor físico.

Cargas de trabalho que possuem um snapshot diário e uma política de retenção de 30 dias apresentam uma configuração consistente. No entanto, elas não têm necessariamente capacidade de recuperação. O sistema pode continuar sua operação sem dependências externas, como dependências de aplicativos do Kubernetes, configuração de identidade e chaves de criptografia. Isso também se refere à configuração de identidade ou a metadados nativos da nuvem. Além disso, o sistema pode não ser restaurado em uma região, cluster, hipervisor ou conta diferentes.

Cargas de trabalho que apresentam o mesmo nível de negócios devem atingir o mesmo resultado pretendido, mesmo que tenham mecanismos de backup diferentes. Por exemplo, uma política de Nível 1 pode exigir (Nível 1 é uma classificação ilustrativa, não uma definição universal do setor):

• Perda máxima de dados de 15 minutos
• Restauração do serviço em até duas horas
• Uma cópia imutável que não esteja dentro do perímetro de segurança de produção
• Testes de recuperação a serem realizados trimestralmente
• Evidências que comprovem que a recuperação das dependências de aplicativos seja realizada corretamente. Essas dependências podem incluir dependências de ordem de recuperação, bem como infraestrutura upstream e serviços de segurança.

Um banco de dados Oracle ou um aplicativo Kubernetes pode utilizar diferentes ferramentas ou plug-ins para cumprir essa política. Essas ferramentas ou plug-ins podem incluir o Oracle Recovery Manager e o plug-in Dell PowerProtect Data Manager. O controle segue um caminho padronizado. A implementação é otimizada para a carga de trabalho.

Como as equipes devem mapear as cargas de trabalho para o método de proteção correto?

Um projeto de backup heterogêneo deve se basear em um inventário orientado para a recuperação, em vez de uma lista de dispositivos. Via de regra, os inventários de infraestrutura identificam hosts e capacidade de armazenamento sem demonstrar os elementos de um serviço de negócios completo.

Comece mapeando os aplicativos para suas dependências de computação, dados, configuração, identidade, rede, certificados e serviços externos, como gateways/APIs de pagamento de terceiros e bancos de dados gerenciados externamente ou provedores de identidade SaaS.

Em seguida, classifique-os, levando em consideração seu impacto nos negócios. Por fim, defina seu Objetivo de Ponto de Recuperação (RPO) e Objetivo de Tempo de Recuperação (RTO), além do período de retenção.

Além disso, defina seus requisitos legais, como leis de soberania e residência de dados (por exemplo, o Regulamento Geral de Proteção de Dados) e Padrões de Retenção Obrigatórios (por exemplo, Lei de Portabilidade e Responsabilidade do Seguro Saúde), local de recuperação e responsável pelo serviço.

GDPR é a lei europeia de privacidade e segurança de dados. HIPAA estabelece padrões rigorosos para o gerenciamento, a transmissão e o armazenamento de informações de saúde protegidas.

Considere usar esta tabela como ponto de partida:

É importante ressaltar que nem todas as dependências são objetos de backup. Os itens a seguir, que fazem parte do plano de recuperação, podem exigir procedimentos separados de proteção ou recriação:

• Entradas do Sistema de Nomes de Domínio (DNS), como registros A ou AAAA e registros de nome canônico
• Repositórios de infraestrutura como código, por exemplo, repositórios do GitLab/GitHub (contendo scripts do Terraform ou Pulumi) e repositórios de modelos do Amazon Web Services CloudFormation
• Configuração de provedores de identidade
• Imagens de contêiner
• Servidores de licença, como o FlexNet Publisher (FlexLM) e o servidor Microsoft Key Management Services (KMS)
• Credenciais de API de terceiros, como segredos de cliente OAuth/tokens de atualização e chaves de API de gateway de pagamento

Um processo passo a passo para projetar um backup heterogêneo

1. Identifique as cargas de trabalho e atribua a responsabilidade

Combine a descoberta automatizada com entrevistas com os proprietários das aplicações, como varreduras de descoberta de infraestrutura (por exemplo, ServiceNow Discovery, Device42), questionários e entrevistas sobre continuidade de negócios.

Identifique sistemas não gerenciados, como servidores de TI não autorizados/sombra e VMs de sandbox/staging de desenvolvedores, além de contas na nuvem, como contas de assinatura ad hoc da AWS/Azure e espaços de trabalho de projetos do Google Cloud Platform (GCP).

Além disso, identifique namespaces do Kubernetes, como namespaces de staging e de ramos de recursos (por exemplo, staging-checkout, dev-payments), e locais remotos, como filiais/depósitos regionais e instalações de fabricação/computação de borda.

Além disso, identifique aplicativos SaaS, como plataformas de colaboração empresarial (por exemplo, Microsoft 365, Google Workspace) e plataformas herdadas, como mainframes legados/sistemas AS400 e ambientes de TI de subsidiárias adquiridas.

Designe um responsável técnico e um responsável de negócios para cada serviço protegido.

2. Defina níveis de recuperação antes de selecionar a tecnologia

Agrupe os serviços com base no impacto nos negócios. Atribua requisitos mensuráveis de RPO, RTO, retenção, local de recuperação e testes, como execuções automatizadas trimestrais em ambiente de teste de recuperação e simulações semestrais completas de failover.

Não permita que a programação padrão de uma ferramenta se torne o requisito de negócios.

3. Identifique os dados e componentes de cada carga de trabalho que devem ser capturados em conjunto para criar um ponto de recuperação utilizável

Decida o que deve ser capturado para um ponto de recuperação utilizável. Por exemplo, considere capturar arquivos de dados e logs de um banco de dados.

Considere capturar VMs, bancos de dados, filas de mensagens ou recursos do Kubernetes para um aplicativo multicamadas. Registre ganchos de aplicativo, como ganchos de congelamento pré-snapshot e descongelamento pós-snapshot, e requisitos de sequenciamento, como dependências de inicialização ordenadas (Infraestrutura – Banco de Dados – Aplicativo – Front-end).

4. Adeque os métodos de proteção ao comportamento da carga de trabalho

Opte por proteção baseada em agente, sem agente, baseada em snapshot, baseada em API, nativa do banco de dados ou contínua. Para isso, é preciso levar em conta as necessidades da carga de trabalho, como acesso ao hipervisor/sistema operacional (SO), sobrecarga de recursos, volume de transações e taxas de alteração.

Utilize integrações nativas, como APIs de backup nativas do banco de dados — por exemplo, o Oracle Recovery Manager (RMAN) ou os gravadores do Microsoft SQL Volume Shadow Copy Service (VSS) —, sempre que elas ofereçam backups consistentes com o aplicativo, coordenação de logs de transações, backup incremental eficiente ou recuperação granular.

Além disso, utilize APIs de snapshot nativas de matrizes de armazenamento e da nuvem, como as APIs de snapshot do AWS Elastic Block Store (EBS) ou a integração com o NetApp ONTAP, sempre que elas aumentem a consistência, melhorem o gerenciamento de logs, proporcionem eficiência incremental ou permitam a recuperação granular.

5. Separe o controle de backup e o armazenamento da produção

Restrinja o acesso administrativo, exija autenticação multifatorial ao lidar com credenciais de backup compatíveis e isoladas, como provedores de identidade autônomos dedicados (por exemplo, diretório local separado/locatário Okta dedicado) e cofres de gerenciamento de acesso privilegiado (PAM) com acesso just-in-time (por exemplo, CyberArk, HashiCorp Vault).

Mantenha cópias imutáveis ou offline, como o bloqueio de objetos do S3 com armazenamento do tipo “write-once-read-many” (WORM) e cópias de armazenamento físico isoladas (por exemplo, fitas offline/redes de armazenamento isoladas).

Uma segunda cópia sob o controle do mesmo sistema de gerenciamento de identidade e acesso comprometido não oferece proteção independente contra o comprometimento desse sistema de identidade.

6. Projete caminhos de recuperação e backup

Determine o local onde as cargas de trabalho serão restauradas caso não haja a plataforma original. Verifique a capacidade da rede, cotas na nuvem, recursos de computação compatíveis, versões de software, chaves e habilidades.

Se você puder restaurar um backup apenas na plataforma de origem com falha, poderá acabar enfrentando uma dependência circular.

7. Teste cenários representativos de falha

Teste perda de VM, perda de cluster, exclusão granular, corrupção de banco de dados, ransomware, comprometimento de contas na nuvem e falhas associadas a locais. Avalie o RPO e o RTO reais. Não se limite a registrar apenas como a tarefa foi concluída.

Quais são os problemas mais comuns em backups heterogêneos?

Falhas comuns incluem cargas de trabalho ausentes, credenciais expiradas, dependências de aplicativos incompletas, acesso administrativo excessivo e recuperação entre plataformas não testada.

Dependências entre plataformas podem gerar falhas envolvendo identidade, autenticação, sequenciamento e compatibilidade de API. As falhas podem incluir desvios de identidade, acesso e autenticação entre plataformas, bem como incompatibilidades no sequenciamento de microsserviços e nos protocolos de API, entre plataformas suportadas, e não dentro delas.

Como novas cargas de trabalho criam lacunas na cobertura de backup?

Em ambientes com provisionamento frequente ou mudanças de configuração, a manutenção manual das políticas de backup pode deixar novas cargas de trabalho temporariamente desprotegidas. Políticas de backup mantidas manualmente podem incluir políticas de auditoria baseadas em planilhas e políticas estáticas de marcação/rotulagem sem aplicação automatizada.

Novas máquinas virtuais (VMs), bancos de dados, namespaces, locatários de SaaS ou contas na nuvem podem nunca ser incluídos.
Um ativo ainda pode permanecer visível por meio de um console após o vencimento de suas credenciais ou quando seu método de proteção diferir da política.

Portanto, você deve medir a cobertura continuamente. Ativos de produção identificados, como enumerações de inventário de APIs na nuvem e objetos de gerenciamento de hipervisores e clusters, devem ser identificados juntamente com os ativos protegidos.

Os ativos protegidos podem incluir registros ativos do catálogo de tarefas de backup e manifestos de snapshots concluídos. A conclusão da tarefa de backup comprova a captura de dados, não a capacidade de recuperação do aplicativo.

Além disso, destaque cargas de trabalho desconhecidas, excluídas e não conformes, como bancos de dados na nuvem órfãos/desprotegidos e credenciais obsoletas/com falha.

Adicionalmente, use tags e rótulos para automatizar a atribuição. As equipes devem manter metadados ausentes ou incorretos sob monitoramento como uma falha de controle.

Um backup bem-sucedido significa que um aplicativo é recuperável?

Como regra geral, o software de backup confirma que leu e armazenou os dados. Ele não pode comprovar automaticamente a disponibilidade de todas as dependências do aplicativo, como Active Directory/provedores de identidade, servidores de sistema de nomes de domínio (DNS), servidores externos de gerenciamento de chaves (KMS) e cofres de segredos. Além disso, não pode garantir automaticamente que o serviço restaurado funcionará.

Para garantir a recuperação, conte com verificações automatizadas de inicialização ou montagem, teste a integridade do banco de dados, faça varreduras em busca de malware, aplique validação no nível do aplicativo e obtenha a aceitação periódica do proprietário.

Serviços de alto impacto, como sistemas bancários centrais e de processamento de transações, além de plataformas de checkout e atendimento de pedidos de comércio eletrônico, também precisam de testes completos do fluxo de trabalho, e não apenas de testes restritos à infraestrutura.

Quais riscos de segurança o gerenciamento centralizado de backup gera?

Uma plataforma unificada pode reduzir o número de consoles, catálogos e sistemas de políticas gerenciados pelos administradores.

No entanto, ela também pode se tornar um alvo administrativo de alto valor. O efeito de uma violação pode se espalhar por todo o ambiente de TI.

Isso ocorre quando um sistema de gerenciamento central exclui políticas, expira cópias — como conjuntos de backups incrementais diários programados que ainda não foram replicados para um repositório externo ou isolado (air-gapped) — e instantâneos de retenção de longo prazo destinados ao arquivamento para conformidade regulatória que ainda não atingiram sua data de validade definida — e, em seguida, acessa todas as cargas de trabalho.

Considere separar funções para reduzir esse risco. Além disso, aplique acesso administrativo “just-in-time”, credenciais separadas, use bloqueios de retenção fixos, encaminhamento de auditoria e hosts de gerenciamento reforçados

Além disso, use domínios de segurança distintos, como contas da Amazon Web Services/assinaturas do Azure completamente isoladas e florestas do Active Directory locais isoladas ou com isolamento físico, para cópias secundárias, como buckets S3 WORM com bloqueio fixo de objetos e cartuchos de fita externos isolados fisicamente ou dispositivos de armazenamento isolados.

A visibilidade centralizada não deve significar autoridade centralizada irrestrita.

Como a deduplicação afeta os custos de armazenamento de backup?

Dados de cargas de trabalho mistas, como bancos de dados SQL transacionais misturados com compartilhamentos de arquivos brutos não compactados e imagens de infraestrutura de desktop virtual misturadas com armazenamento de mídia/vídeo, não são deduplicados da mesma forma.

Bancos de dados criptografados, mídias compactadas, discos virtuais com muitas alterações e dados em nuvem criptografados no lado do cliente podem apresentar baixas taxas de redução.

Embora a deduplicação global possa economizar capacidade, você também pode contar com ela para considerações de desempenho, domínio de falhas ou residência de dados, como infraestruturas dedicadas/segmentadas cujos componentes podem falhar em conjunto, além de pools de desempenho e isolamento geográfico e regulatório da residência de dados.

Os modelos de capacidade devem considerar taxas de alteração específicas da carga de trabalho, retenção, comportamento do backup completo, sobrecarga imutável, replicação, saída de dados e espaço de preparação para restauração. O planejamento de capacidade não deve se basear em uma única taxa de desduplicação para tipos de carga de trabalho substancialmente diferentes.

Por que a recuperação entre plataformas deve ser testada?

As organizações frequentemente dependem de backups para dar suporte à migração para a nuvem ou à recuperação em um hipervisor diferente. Na prática, a recuperação pode ser bloqueada por diferenças associadas a drivers, modos de inicialização, formatos de disco, estruturas de rede, identidade, recursos de serviços gerenciados e licenciamento de aplicativos.

Portanto, a recuperação para uma plataforma diferente deve ser vista como um caso de uso separado, exigindo suporte documentado e testes. Exportar dados não é equivalente a reconstruir um aplicativo operacional.

Você deve usar uma única plataforma de backup ou várias ferramentas especializadas?

Ambos os modelos podem funcionar. A escolha depende do suporte à carga de trabalho, dos requisitos de recuperação, dos limites de segurança, das habilidades operacionais e dos requisitos regulatórios

O backup heterogêneo está associado a duas abordagens comuns. Especificamente, as organizações podem usar uma plataforma unificada para proteger vários tipos de carga de trabalho sob um único catálogo e sistema de políticas.

Uma abordagem federada mantém produtos especializados e adiciona monitoramento, governança ou geração de relatórios compartilhados.

As organizações podem utilizar um modelo comum de governança mesmo quando diferentes cargas de trabalho exigem produtos de backup distintos. O uso de uma ferramenta especializada para bancos de dados ou mainframe pode ser justificado caso uma plataforma geral não ofereça consistência e não atenda aos requisitos de desempenho ou recuperação, como, por exemplo, clusters de aplicativos reais Oracle de alta taxa de transferência que exigem integração com o RMAN para recuperação em um ponto no tempo, além de cargas de trabalho em mainframe e sistemas operacionais legados (por exemplo, IBM z/OS ou AS/400).

No entanto, as organizações devem identificar lacunas e falhas, como cargas de trabalho especializadas não registradas ou desprotegidas, incompatibilidades na restauração entre plataformas e falhas de API. Além disso, isso se refere à conformidade com as políticas de retenção e às evidências de testes de recuperação associadas a todas as exceções relacionadas aos processos operacionais comuns.

Primeiro, teste as cargas de trabalho de ponta. Não se concentre apenas no ambiente de TI convencional do VMware ou do Windows. Em seguida, consolide ferramentas, como agentes de backup pontuais distintos que rodam separadamente em bancos de dados Oracle, clusters do Kubernetes e sistemas Unix legados que atualmente exigem consoles de gerenciamento individuais e contratos de licenciamento separados.

Depois, verifique se a plataforma candidata é capaz de restaurar metadados de aplicativos, permissões, logs e dependências.

Verifique se a plataforma candidata oferece suporte às versões implantadas. Descubra se a recuperação continua possível caso o plano de controle SaaS ou o serviço de licenciamento do fornecedor estejam indisponíveis.

Como avaliar se o backup heterogêneo está funcionando

A taxa de sucesso das tarefas de backup, por si só, não mede a capacidade de recuperação. É possível avaliar a proteção e a recuperação usando um quadro de indicadores mais abrangente:

• Cobertura de ativos: porcentagem dos ativos de produção abrangidos, como infraestrutura em nuvem recém-provisionada, namespaces do Kubernetes e volumes persistentes, protegidos por uma política aprovada
• Conformidade com a política: porcentagem que atende aos requisitos de RPO, retenção, cópias e controles fixos, como bloqueio de objetos imutáveis (WORM) e cópias secundárias geográficas ou isoladas
• Validade do ponto de recuperação: porcentagem dos pontos de restauração amostrados que passam nas verificações de integridade e malware
• Recuperabilidade testada: porcentagem de aplicativos críticos, como sistemas de planejamento de recursos empresariais (ERP) (por exemplo, SAP, Oracle EBS) e portais de comércio eletrônico e gateways de pagamento voltados para o cliente, restaurados e validados dentro do período de teste exigido
• RPO e RTO observados: perda real de dados e tempo de recuperação decorrido durante testes ou incidentes, como o delta de restauração de um ponto no tempo do banco de dados (RPO observado) e o tempo de restauração completa e inicialização do aplicativo (RTO observado).
• Tempo de desvio de cobertura: por quanto tempo uma carga de trabalho nova ou alterada permanece fora de uma política aprovada
• Tempo de permanência da exceção: por quanto tempo cargas de trabalho não suportadas ou isentadas permanecem sem solução
• Capacidade de recuperação em um ambiente isolado após um comprometimento: se existem credenciais, redes, recursos de computação, chaves e procedimentos para recuperar fora do ambiente comprometido

A classe de carga de trabalho e o nível de negócios podem ajudar a segmentar métricas, como cargas de trabalho de nível 0/críticas à missão (por exemplo, sistema bancário central, IAM/Active Directory) e cargas de trabalho de nível 3/não críticas (por exemplo, ambientes internos de desenvolvimento/teste, compartilhamentos de arquivos de arquivamento). Uma taxa de sucesso de 98% pode ocultar falhas repetidas de alguns sistemas que geram a maior parte do risco para os negócios.

Como o Bacula Enterprise oferece suporte a ambientes de backup heterogêneos

O Bacula Enterprise foi projetado para proteger ambientes de TI heterogêneos sem forçar todas as cargas de trabalho a seguirem o mesmo método de backup. Em vez disso, as organizações podem gerenciar cargas de trabalho físicas, virtuais, em contêineres, de banco de dados, SaaS e em nuvem por meio de uma plataforma comum de backup e recuperação, utilizando integrações específicas para cada carga de trabalho quando necessário.

Isso é importante em ambientes mistos porque, conforme discutido acima, uma máquina virtual, um banco de dados transacional e um aplicativo Kubernetes podem compartilhar os mesmos objetivos de recuperação, embora exijam mecanismos completamente diferentes para criar um ponto de recuperação utilizável.

O Bacula Enterprise oferece suporte a esse modelo por meio de uma arquitetura modular e de uma ampla gama de plug-ins e integrações dedicadas. Os ambientes suportados incluem VMware, Hyper-V, Proxmox, Nutanix, KVM, Xen/XCP-ng, OpenStack, Libvirt, Azure VM e muitos outros, além de sistemas físicos Windows, Linux, macOS e Unix. O Bacula também oferece recursos dedicados para Kubernetes, Docker e Red Hat OpenShift.

Para cargas de trabalho de aplicativos e bancos de dados, o Bacula oferece integrações com tecnologias como Microsoft SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, SAP HANA, IBM DB2 e SAP ASE. Cargas de trabalho de SaaS, como Microsoft 365 e Google Workspace, também podem ser incorporadas ao ambiente mais amplo de backup.

O resultado é que as organizações podem aplicar políticas operacionais comuns sem reduzir o backup heterogêneo a uma abordagem de “mínimo denominador comum”. Por exemplo, os administradores podem definir centralmente agendas, políticas de retenção e de backup, utilizando proteção compatível com hipervisores para máquinas virtuais, métodos específicos para bancos de dados em sistemas transacionais e mecanismos compatíveis com o Kubernetes para aplicativos em contêineres.

O Bacula Enterprise também pode combinar essas cargas de trabalho com diferentes destinos de armazenamento de backup. Suas integrações incluem armazenamento em disco, fita e nuvem, bem como interfaces compatíveis com S3, Microsoft Azure, Google Cloud, Oracle Cloud e Amazon Glacier. Isso permite que as organizações projetem o armazenamento e a retenção de acordo com o nível da carga de trabalho, os requisitos de recuperação e as restrições de infraestrutura, em vez de se basearem apenas na plataforma de origem.

O gerenciamento centralizado é fornecido por meio do BWeb Management Suite, que pode ser usado para configurar, monitorar e analisar o ambiente de backup. Isso oferece aos administradores uma visão operacional comum entre diferentes tecnologias, mantendo os métodos especializados de backup e recuperação exigidos por cada carga de trabalho.

Para organizações que estejam considerando a consolidação de vários produtos de backup, essa amplitude de suporte pode reduzir o número de sistemas de backup separados que precisam ser operados. No entanto, a cobertura das cargas de trabalho ainda deve ser avaliada em relação às tecnologias e versões reais em uso. O objetivo não é simplesmente colocar todas as cargas de trabalho sob um único console, mas verificar se cada sistema crítico possui o método de backup adequado e um caminho de recuperação testado.

Perguntas frequentes

Como os sistemas legados não suportados devem ser incluídos em uma estratégia de backup heterogênea?

Inclua-os em um registro formal de exceções, destacando o responsável, o impacto nos negócios, o método de recuperação atual, os controles compensatórios e a data de desativação ou correção. Além disso, uma única estratégia de recuperação pode reger múltiplas tecnologias de backup.

Você pode utilizar medidas possíveis, como instantâneos no nível do armazenamento, dumps de banco de dados, exportações de arquivos, replicação ou isolamento. Além disso, teste todas as soluções alternativas. Lembre-se de que, mesmo que você copie dados proprietários inacessíveis, não será possível ter um backup utilizável.

Uma estratégia de backup está incompleta até que a recuperação seja testada.

Um único repositório imutável pode armazenar com segurança backups de todos os ambientes?

Um único repositório imutável pode simplificar a retenção e o gerenciamento de capacidade. Isso se aplica quando o repositório oferece a imutabilidade, a taxa de transferência, o isolamento e os controles regulatórios necessários.

No entanto, isso pode concentrar riscos operacionais e de segurança. Avalie a separação de locatários, chaves de criptografia, domínios administrativos, residência de dados, domínios de falha, taxa de transferência de recuperação e o efeito de uma interrupção no repositório.

Mesmo quando as organizações aplicam gerenciamento unificado, serviços críticos, como serviços de identidade e diretório (por exemplo, Active Directory/Entra ID, infraestrutura de chave pública) e sistemas centrais de processamento financeiro e de transações (por exemplo, SAP, sistema bancário central em mainframe), podem justificar cópias de backup separadas ou camadas de armazenamento com base na avaliação de riscos.

Com que frequência a recuperação heterogênea deve ser testada?

Utilize o nível de negócios e a taxa de mudança para determinar a frequência. Aplique validação automatizada para serviços críticos associados a cada backup. Não se esqueça dos exercícios programados de recuperação de aplicativos, como a simulação de transição completa de recuperação de desastres (DR) e a recuperação isolada em ambiente controlado contra ransomware.

Você pode testar cargas de trabalho de camadas inferiores com menos frequência. A frequência dos testes deve ser determinada com base no impacto nos negócios, nos requisitos regulatórios, na frequência de mudanças e nos objetivos de recuperação.

No entanto, é necessário testar uma amostra de todos os tipos de plataformas, processos e destinos relevantes utilizados para restaurar uma carga de trabalho. Repita os testes após grandes atualizações, migrações de dados, alterações de identidade ou mudanças na arquitetura. Avalie o sucesso da restauração, não apenas o sucesso do backup.