Backup e recuperação de mainframe: estratégias modernas para sistemas empresariais resilientes

Qual é o panorama atual do backup e da recuperação de desastres de mainframe?

Em um ambiente de TI – especialmente na área de TI corporativa –, o backup de mainframe continua sendo uma das disciplinas mais críticas e frequentemente subestimadas.

Transações financeiras, arquivos de seguros e programas governamentais estão se tornando cada vez mais dependentes de mainframes, o que significa que os riscos de inatividade do sistema também estão em níveis recordes. Uma solução de backup de mainframe deve ser capaz de atender a um tipo de demanda que o sistema de backup distribuído típico nunca foi projetado para oferecer.

Por que os mainframes ainda exigem abordagens especializadas de backup e recuperação?

Um mainframe não é meramente um servidor de grandes dimensões. Sua arquitetura foi construída em torno do conceito de disponibilidade contínua, enorme taxa de transferência de E/S e separação de cargas de trabalho – fatores que determinam o projeto e a execução de backups em um nível fundamental.

Um ambiente z/OS que gerencia milhares de transações por segundo não pode permitir as mesmas janelas de backup, os mesmos modelos de consistência e os mesmos procedimentos de recuperabilidade que os servidores de arquivos Linux utilizam.

Os sistemas de backup de mainframe precisam lidar com uma série de conceitos exclusivos da plataforma e que não existem em nenhum outro lugar – conjuntos de dados VSAM, catálogos z/OS, estruturas de acoplamento e ambientes sysplex –, todos os quais exigem seus próprios mecanismos. Fazer um backup de um cluster VSAM é muito diferente de fazer um backup de uma árvore de diretórios, enquanto restaurar um sysplex para um estado consistente envolve uma coordenação que vai muito além das capacidades de ferramentas genéricas de backup.

A escala também é uma questão por si só. Os mainframes gerenciam volumes de dados na escala de petabytes regularmente, com requisitos rigorosos de SLA que exigem que o processo de backup opere simultaneamente à produção sem qualquer impacto perceptível. Essa restrição, por si só, descarta um grande número de soluções prontas para uso.

Quais são as ameaças e modos de falha comuns em ambientes de mainframe?

Embora extremamente confiáveis por design, os mainframes não são invencíveis. Os tipos de falhas que podem colocar um ambiente de mainframe em risco são numerosos, e uma estratégia adequada de backup de mainframe deve levar todos eles em consideração:

• Falha de hardware – Degradação do subsistema de armazenamento, falhas de canal ou falhas do processador, que podem corromper ou tornar os dados inacessíveis mesmo sem uma interrupção total do sistema
• Erro humano – Exclusão acidental de conjuntos de dados, tarefas JCL mal configuradas ou atualizações errôneas de catálogos, que representam uma parcela significativa dos eventos de recuperação no mundo real
• Falhas de software e aplicativos – Bugs na lógica de processamento em lote ou no middleware que gravam dados incorretos, os quais podem não vir à tona até que os registros já tenham se propagado para as etapas posteriores
• Ransomware e ataques maliciosos – Um vetor de ameaça cada vez mais relevante, discutido em profundidade na seção a seguir
• Desastres no nível do local – Falta de energia, inundação ou falha na infraestrutura física que afeta todo um data center

Nenhuma ameaça se destaca em relação às outras. O failover de hardware não é suficiente sem o tratamento de dados logicamente corrompidos, e vice-versa, ao decidir a estratégia de backup do mainframe.

Como os requisitos comerciais modernos alteram as expectativas de backup e DR?

A definição de “recuperável” também mudou consideravelmente ao longo dos anos.

Uma meta de RTO de 4 horas pode ter sido razoável há uma década para várias cargas de trabalho. As equipes de continuidade de negócios atuais buscam um RTO de zero (ou muito próximo de zero) para aplicativos críticos, impulsionadas pelo comércio digital, redes de pagamento em tempo real e regulamentações que tratam interrupções significativas como uma violação de conformidade regulatória, em vez de um inconveniente operacional.

Muitas dessas expectativas já foram documentadas em estruturas regulatórias. Sob estruturas como DORA e PCI DSS, as organizações agora são obrigadas a definir formalmente e testar regularmente os objetivos de recuperação. A falha em estabelecer ou cumprir esses compromissos é tratada como uma falha de conformidade e abordada de acordo.

Para organizações que operam mainframes no centro de seus negócios, essa dimensão regulatória torna o planejamento de recuperação de desastres (DR) uma responsabilidade de governança, e não apenas técnica.

Por que as estratégias de backup de mainframe estão evoluindo na era das ameaças cibernéticas?

As ameaças cibernéticas modernas mudaram o que um backup de mainframe deve ser capaz de fazer. Os ambientes de mainframe há muito dependem de recursos de resiliência desenvolvidos especificamente para esse fim — espelhamento, cópia em um ponto no tempo e redundância em camadas — que eram altamente eficazes contra os modelos de ameaça para os quais foram projetados: falha de hardware, erro humano e desastres no nível do local.

Infelizmente, o surgimento de ransomware complexo e de ataques à cadeia de suprimentos introduziu uma nova classe de problemas em que os backups também são alvos. O surgimento de grupos de ransomware como o Conti — cujos manuais de ataque documentados listavam a identificação e destruição de backups como objetivo principal antes de acionar a criptografia — introduziu um modelo de ameaça para o qual as estratégias de backup corporativas não haviam sido projetadas.

Como o ransomware tem como alvo ambientes legados e de mainframe?

A suposição de que os mainframes são inerentemente protegidos contra ransomware em virtude de sua arquitetura tem sido historicamente amplamente difundida. No entanto, essa mesma suposição está sendo cada vez mais contestada à medida que os ambientes de mainframe se tornam mais profundamente integrados a sistemas abertos e infraestruturas distribuídas.

Os autores de ransomware modernos são calculistas e metódicos; eles escaneiam e mapeiam a infraestrutura antes de ativar uma carga útil, buscando especificamente repositórios e catálogos de backup para desativar quaisquer mecanismos de restauração antes de iniciar o processo de criptografia.

Os ambientes de mainframe apresentam um risco de exposição específico por meio de seus pontos de integração. Os sistemas z/OS se comunicam constantemente com redes distribuídas, camadas de armazenamento em nuvem e middleware de sistemas abertos (qualquer um dos quais pode atuar como um ponto de entrada). À medida que os ambientes de mainframe se tornam mais profundamente integrados à infraestrutura distribuída, a superfície de ataque se expande: o comprometimento de um sistema conectado poderia, em arquiteturas de rede suficientemente planas, fornecer um caminho para camadas de armazenamento compartilhadas nas quais residem conjuntos de dados de backup do mainframe.

Em muitas configurações, os catálogos de backup de mainframe e os conjuntos de dados de controle residem na mesma malha de armazenamento que os dados que protegem – o que significa que um invasor bem posicionado, ou um evento de corrupção que se propague pelo armazenamento compartilhado, poderia afetar ambos simultaneamente. Não é preciso pensar muito para chegar à conclusão de que um catálogo de backup que existe na mesma malha de armazenamento que os próprios dados poderia ser corrompido e destruído no mesmo incidente.

Essa situação específica precisa agora ser abordada pelas arquiteturas modernas de backup de mainframe.

Qual é o papel dos backups imutáveis e isolados fisicamente para mainframes?

Essas são as duas abordagens arquitetônicas predominantes no combate ao ransomware: imutabilidade e isolamento físico. Embora sejam dois dos conceitos predominantes discutidos em relação à solução para o ransomware, eles, na verdade, funcionam de maneiras diferentes.

As duas abordagens não são mutuamente exclusivas. Uma estratégia de backup de mainframe bem desenvolvida pode abranger ambas – uma cópia imutável para proporcionar recuperação em curto prazo em cenários de ataque lógico e uma cópia isolada fisicamente para recuperação definitiva em circunstâncias em que a imutabilidade no nível do armazenamento também tenha sido violada (por meio do uso de contas de administrador privilegiadas ou ataques direcionados diretamente à camada de armazenamento).

Quando a imutabilidade da camada de armazenamento ainda não é fornecida nativamente – como é o caso, por exemplo, do IBM DS8000 Safeguarded Copy e da estrutura Z Cyber Vault –, a implementação no z/OS requer uma integração cuidadosa com as ferramentas de backup existentes para garantir que as políticas de imutabilidade sejam aplicadas na camada de armazenamento, e não apenas na camada de aplicativos (onde elas podem ser potencialmente contornadas).

Como os princípios de confiança zero se aplicam às arquiteturas de backup de mainframe?

O z/OS incorporou muitos dos princípios agora associados à arquitetura de confiança zero — controles de acesso obrigatórios, separação estrita de funções e trilhas de auditoria abrangentes — muito antes de o termo entrar no discurso mainstream de segurança. Especificamente para o backup de mainframe, a questão não é tanto introduzir conceitos de zero-trust, mas sim garantir que as políticas RACF ou ACF2 sejam configuradas para aplicar esses princípios de forma consistente ao ambiente de backup, que às vezes é tratado como de menor risco do que a produção e pode acumular privilégios excessivos ao longo do tempo.

Quando se trata de backup de mainframe, o zero-trust implica que nenhum dispositivo, usuário ou processo (nem mesmo administradores de backup) seja considerado como tendo acesso implícito ou capacidade de gerenciar dados de backup. Em termos práticos, isso implicaria em separação estrita de funções, autenticação de dois fatores para o console de gerenciamento de backup e permissões estritas baseadas em funções, limitando quem tem permissão para excluir/modificar/desativar tarefas de backup.

No z/OS, isso se traduz em um projeto de políticas RACF ou ACF2 que restringe explicitamente o acesso ao catálogo de backup, combinado com alertas fora da banda para qualquer ação administrativa que afete as configurações de retenção ou as programações de backup. O ambiente de backup de mainframe deve ser tratado como um sistema crítico de segurança em si, de modo que tanto os ciclos de revisão de acesso quanto as trilhas de auditoria atendam aos mesmos padrões aplicados aos dados de produção.

Quais objetivos de recuperação devem orientar a estratégia de backup do mainframe?

Os objetivos de recuperação não devem ser definidos e depois ignorados, pois constituem a base de toda a arquitetura de backup de mainframe em termos contratuais. Todas as decisões além desse ponto (relativas à frequência dos backups, topologia de replicação, escolhas de camadas de armazenamento) devem derivar de RTOs e RPOs estabelecidos. As empresas que pulam essa etapa geralmente descobrem suas lacunas durante um evento de desastre real – o pior momento para isso acontecer.

Qual é a diferença entre RTO e RPO para cargas de trabalho de mainframe?

RTO e RPO são conceitos bem conhecidos de DR, mas seu efeito no contexto do mainframe é bastante significativo e pode ter significados bem diferentes das mesmas métricas em sistemas distribuídos.

O RPO (Recovery Point Objective), o intervalo de tempo máximo aceitável para perda de dados, é particularmente difícil para mainframes devido às relações entre as transações. Um mainframe processando transações de pagamento de alto volume pode facilmente ter milhões de registros por hora distribuídos por vários conjuntos de dados acoplados.

O RPO não é apenas um snapshot capturado repetidamente após um determinado período de tempo – ele implica a captura de todos os conjuntos de dados acoplados, catálogos e estruturas de acoplamento em um determinado momento.

O RTO (Recovery Time Objective), o tempo máximo alocado para operações de restauração, traz suas próprias complexidades em mainframes. Recuperar um ambiente z/OS não é equivalente a iniciar uma máquina virtual a partir de um instantâneo.

Na maioria das vezes, as empresas não percebem seu verdadeiro valor de RTO até realizarem um teste de recuperação – momento em que ninguém pode ignorar a diferença entre o prazo de recuperação previsto e o real.

Ambos os objetivos devem ser definidos por carga de trabalho, não por sistema. Um único mainframe pode hospedar aplicativos com tolerâncias muito diferentes para perda de dados e tempo de inatividade, que é exatamente o que a classificação por níveis de criticidade foi projetada para resolver.

Como os níveis de criticidade devem influenciar a frequência e a retenção de backups?

Nem todas as cargas de trabalho em execução em um mainframe devem — nem podem — ser protegidas da mesma forma. A classificação por nível de criticidade é o processo pelo qual a criticidade dos negócios se traduz em uma política prática de backup. Ela aloca recursos adequados para as cargas de trabalho nas quais se espera a janela de recuperação mais longa, evitando ao mesmo tempo o provisionamento excessivo de proteção para cargas de trabalho nas quais uma janela de recuperação mais ampla pode ser tolerada.

Um modelo prático de classificação por níveis normalmente opera em três níveis:

As atribuições de camadas devem ser orientadas por análises de impacto nos negócios, e não por conveniência técnica, e devem ser revisadas pelo menos anualmente – a criticidade da carga de trabalho muda à medida que as prioridades de negócios evoluem, e um conjunto de dados que era de Camada 2 no ano passado pode já ser considerado de Camada 1 hoje.

Como a conformidade e os SLAs afetam os objetivos de recuperação?

As estruturas de recuperação não apenas incentivam um planejamento de recuperação robusto, mas muitas agora exigem resultados concretos e testáveis.

• A regulamentação DORA exige que as entidades financeiras definam e testem as capacidades de recuperação em relação a métricas predefinidas
• O PCI DSS estabelece requisitos específicos de disponibilidade e integridade para sistemas que acessam dados de titulares de cartões
• A regra de disponibilidade da HIPAA estabelece obrigações para manter o acesso a PHI em circunstâncias específicas

O efeito prático é que as metas de recuperação de uma carga de trabalho regulamentada não estão mais sujeitas apenas a uma decisão interna. Sempre que os requisitos de SLA e regulatórios se sobrepõem, o requisito mais rigoroso é escolhido. Assim, a solução de backup de mainframe deve ser projetada, testada e documentada para atender tanto aos auditores externos quanto à satisfação interna.

Quais são as opções de backup no local para mainframes?

O backup de mainframe no local se baseia em três categorias distintas de tecnologia:

• Backup baseado em fita (físico e virtual)
• Backup de disco para disco
• Cópias pontuais

Cada uma dessas opções atende a diferentes necessidades de recuperação e restrições operacionais. Saber onde cada abordagem se encaixa é a base de qualquer estratégia de backup de mainframe bem projetada.

Como funcionam os backups baseados em DASD (emulação de fita, fitas virtuais) em mainframes?

O backup de Dispositivos de Armazenamento de Acesso Direto (DASD) faz parte dos ambientes de mainframe há muitos anos, mas a tecnologia em si mudou significativamente ao longo do tempo.

As Bibliotecas de Fitas Virtuais (VTLs) são amplamente utilizadas em ambientes de mainframe como uma camada de desempenho à frente da fita física, apresentando uma interface de fita ao z/OS enquanto gravam dados em um armazenamento baseado em disco antes de serem migrados para a fita física para retenção de longo prazo. Uma VTL se comporta como um dispositivo de fita física do ponto de vista do software do mainframe, mas grava os dados em um armazenamento baseado em disco.

Como resultado, um JCL ou script de automação escrito para backups em fita física pode ser reutilizado para backups em VTL com pouca ou nenhuma modificação, resultando em melhor desempenho sem a necessidade de alterar toda a infraestrutura de backup.

A fita física continua sendo o principal meio de backup na maioria dos ambientes de mainframe até hoje, com os VTLs atuando como um intermediário com desempenho otimizado que preserva as práticas operacionais baseadas em fita, ao mesmo tempo em que reduz o manuseio mecânico e melhora a taxa de transferência do backup.

Quando os backups de disco para disco devem ser preferidos em relação às soluções baseadas em fita?

A decisão de implementar backup de disco para disco ou em fita para seus mainframes não é apenas técnica, mas é frequentemente determinada por uma combinação de necessidades de recuperação, realidades de negócios e considerações econômicas.

O backup de disco para disco é a melhor opção quando:

• A velocidade de recuperação é uma prioridade – as restaurações baseadas em disco são concluídas em uma fração do tempo necessário para localizar, montar e ler um volume de fita, o que impacta diretamente o cumprimento do RTO
• As janelas de backup são apertadas – destinos em disco de alta taxa de transferência podem absorver dados de backup mais rapidamente do que a fita, reduzindo o risco de tarefas ultrapassarem a janela alocada
• São esperados testes de recuperação frequentes – as restaurações baseadas em fita introduzem uma sobrecarga operacional que desestimula testes regulares de DR, enquanto os destinos em disco tornam as restaurações de teste rotineiras
• É necessária uma recuperação granular – restaurar um único conjunto de dados ou um pequeno número de registros a partir do disco é significativamente mais prático do que procurar em volumes de fita para localizar dados específicos

A fita ainda é adequada para aplicações em que o armazenamento de longo prazo, o arquivamento regulatório ou o armazenamento externo tornam sua utilização economicamente viável. No entanto, para cargas de trabalho com requisitos de RTO rigorosos ou necessidades frequentes de testes de recuperação, o disco-para-disco pode oferecer uma vantagem operacional significativa como complemento ao backup primário baseado em fita.

Qual é o papel das tecnologias de snapshot e ponto no tempo no mainframe?

Os snapshots ocupam um lugar específico no panorama de backup de mainframe; eles não são uma alternativa ao backup, mas um complemento aos recursos de backup existentes. São particularmente valiosos nos casos em que as restrições convencionais da janela de backup ou as exigências de granularidade de recuperação excedem os recursos que as tarefas agendadas podem oferecer por si só.

No z/OS, as tecnologias de cópia pontual criam uma cópia dependente instantânea de um conjunto de dados ou volume sem interromper a E/S de produção – sendo o IBM FlashCopy a opção mais proeminente no mercado. As principais características que definem como essas tecnologias se encaixam em uma estratégia de backup de mainframe incluem:

• Requisitos de consistência – um snapshot de um único volume é simples, mas capturar uma imagem consistente em um ponto no tempo em vários volumes relacionados em um ambiente OLTP movimentado requer coordenação cuidadosa para evitar a captura de dados no meio de uma transação
• Granularidade de recuperação – os snapshots permitem uma recuperação rápida para um estado recente conhecido como bom, mas são normalmente retidos por períodos mais curtos do que as cópias de backup tradicionais, tornando-os inadequados como único mecanismo de recuperação
• Sobrecarga de armazenamento – cópias dependentes consomem capacidade de armazenamento adicional, e a relação entre os volumes de origem e destino deve ser gerenciada cuidadosamente para evitar impacto no desempenho de produção

Os snapshots, quando usados corretamente, funcionam como a camada de recuperação rápida em um projeto de backup de mainframe de várias camadas, onde podem lidar com cenários de recuperação frequentes e recentes, enquanto o backup tradicional lida com o armazenamento de longo prazo fora do local.

Quais arquiteturas de recuperação de desastres off-site e remotas estão disponíveis?

A arquitetura de DR fora do local é onde o backup de mainframe e o planejamento de continuidade de negócios estão mais interligados. As decisões específicas na arquitetura de DR fora do local – o modo de replicação, a topologia do local, a estratégia de armazenamento – influenciam não apenas o potencial de uma recuperação no nível do local, mas também sua velocidade e integridade em condições reais.

Como a replicação síncrona versus assíncrona afeta a capacidade de recuperação?

O modo de replicação é provavelmente uma das decisões arquitetônicas mais significativas para uma configuração de recuperação de desastres de mainframe, já que o modo de replicação especifica, na verdade, a quantidade mínima teórica de dados que as empresas podem perder durante qualquer cenário de failover.

Na maioria dos casos, essa não é uma escolha simples e binária. Muitos sistemas de mainframe utilizam replicação síncrona para um local secundário adjacente, atendendo às necessidades de continuidade de negócios, combinada com replicação assíncrona para um local terciário mais remoto, para cenários de desastres catastróficos. Dessa forma, eles conseguem aceitar um RPO maior devido à separação geográfica do backup, já que um link síncrono sobre uma grande distância simplesmente não seria prático.

Quais são as vantagens e desvantagens dos locais de DR ativo-ativo em comparação com os ativo-passivo?

A topologia do local – como o local secundário se relaciona com a produção durante operações normais – define tanto o perfil de custos quanto o comportamento de recuperação de toda a arquitetura de DR.

Uma configuração ativa-ativa executa as cargas de trabalho de produção em ambos os locais simultaneamente. A distribuição da carga de trabalho ocorre em todo o sysplex nesse caso. O principal benefício dessa arquitetura é que o failover não é um evento isolado, já que a capacidade já está disponível no local de DR, e a transição de operação degradada para operação plena é significativamente mais rápida do que em qualquer cenário de inicialização a frio. Os backups e a replicação para o mainframe são sempre utilizados, em vez de ficarem inativos, razão pela qual as falhas na postura de DR ocorrem durante as operações normais, e não em um desastre real.

Tanto o custo quanto a complexidade são as desvantagens aqui. O ativo-ativo requer infraestrutura completa de nível de produção em ambos os locais, com balanceamento contínuo da carga de trabalho e projeto cuidadoso de aplicativos para lidar com a consistência distribuída nas transações. Com isso em mente, o ativo-ativo pode introduzir mais riscos do que eliminar para organizações cujas cargas de trabalho de mainframe estão fortemente integradas entre si ou são difíceis de particionar.

Ambientes ativo-passivo mantêm um local de backup aquecido e inativo, reduzindo significativamente os gastos com hardware. Isso implica que as soluções de backup de mainframe que atendem a esse local manterão o ambiente passivo atualizado o suficiente para atender aos requisitos de RTO – um desafio que aumentará à medida que o nível de atualização entre o primário e o secundário divergir. O que não pode ser contornado no ativo-passivo é o fato de que o failover significa um período de transição real, e esse período precisa ser testado regularmente para confirmar se está dentro de limites aceitáveis.

Quando o armazenamento remoto em fita ou em nuvem é apropriado?

A fita – seja o armazenamento físico ou baseado em nuvem – continua sendo um elemento central da arquitetura de backup de mainframe, atendendo a requisitos que as alternativas baseadas em disco nem sempre conseguem cumprir, incluindo os requisitos de isolamento físico (air-gap) e retenção de mídia física explicitamente exigidos por estruturas como o PCI DSS. A fita continua sendo apropriada sob um conjunto definido de condições:

• Retenção regulatória de longo prazo – onde as exigências regulatórias requerem anos ou décadas de preservação de dados e o custo de manter esses dados em disco ou em armazenamento ativo na nuvem é proibitivo
• Requisitos de isolamento físico – onde políticas ou regulamentações exigem uma cópia dos dados de backup que esteja física ou logicamente desconectada de toda a infraestrutura acessível pela rede
• Cargas de trabalho de arquivamento acessadas com pouca frequência – onde a probabilidade de precisar restaurar é baixa o suficiente para que a latência de recuperação seja uma compensação aceitável pelo custo de armazenamento
• Proteção suplementar para camadas de backup ativas – onde a fita serve como uma cópia secundária dos backups baseados em disco, em vez de ser o mecanismo de recuperação primário

O que o armazenamento em fita não deve ser é a solução principal de backup de mainframe para qualquer carga de trabalho com um requisito de RTO significativo. A sobrecarga operacional de localizar, enviar e montar mídias físicas – ou recuperar e preparar fitas baseadas em nuvem – torna essa solução estruturalmente inadequada para cenários de recuperação sensíveis ao tempo.

Como a mobilidade de dados e a integração entre plataformas afetam a recuperação do mainframe?

A recuperação do mainframe não é realizada de forma isolada. A infraestrutura empresarial está hoje fortemente interconectada; os mecanismos de transação do mainframe alimentam bancos de dados distribuídos, aplicativos de sistemas abertos extraem dados do mainframe e os utilizam em tempo real, e camadas de API integram plataformas de maneira transparente e ambígua – criando muitas interdependências que muitas vezes não são consideradas no planejamento de recuperação de desastres.

Tratar o backup e a recuperação do mainframe como um exercício independente – restaurando conjuntos de dados, catálogos e subsistemas sem levar em conta a consistência dos sistemas distribuídos dependentes – quase certamente resultará em um mainframe tecnicamente recuperado, mas com o qual o restante do ambiente de negócios não poderá interagir de forma útil.

Como os dados do mainframe podem ser integrados com sistemas distribuídos e abertos para DR?

Em um cenário empresarial moderno, é incomum que as cargas de trabalho do mainframe sejam executadas em seus próprios ambientes isolados. Os mecanismos de transação do mainframe reportam-se a feeds de dados que alimentam aplicativos analíticos a jusante, enquanto os mecanismos de transação z/OS reportam-se a bancos de dados distribuídos que aplicativos habilitados para a web consomem em tempo real.

No caso de recuperação do mainframe, não se trata da capacidade de restaurar o mainframe, mas sim de saber se todo o sistema dependente pode ser trazido de volta a um estado de funcionamento consistente junto com ele. As técnicas de integração possíveis que suportam isso incluem tudo, desde a replicação de dados orientada por API até arquiteturas de compartilhamento de armazenamento, nas quais o mainframe e os sistemas distribuídos podem acessar os mesmos pools de dados.

A escolha certa depende enormemente da latência aceitável, do volume de dados e do grau de criticidade dos requisitos de consistência entre os dois sistemas. O elemento crucial para o processo de backup do mainframe é que esses pontos de integração sejam explicitamente mapeados e incluídos no planejamento de DR, em vez de serem tratados como problema de outra pessoa.

Que desafios surgem ao sincronizar cargas de trabalho de mainframe e não mainframe?

A sincronização entre plataformas é onde os planos de DR heterogêneos falham mais. Os desafios técnicos e operacionais são específicos o suficiente para merecer atenção especial:

• Desalinhamento de limites de transação – os sistemas de mainframe normalmente gerenciam transações com garantias ACID no nível do conjunto de dados, enquanto os sistemas distribuídos podem usar modelos de consistência diferentes, dificultando o estabelecimento de um único ponto de recuperação válido em ambos os ambientes simultaneamente
• Dependências de tempo – tarefas em lote que extraem dados do mainframe para processamento posterior criam dependências de tempo implícitas que raramente são documentadas formalmente, o que significa que uma recuperação que restaure o mainframe a um ponto anterior à última execução em lote pode deixar os sistemas distribuídos à frente do mainframe em termos de atualidade dos dados
• Consistência de catálogos e metadados – restaurar conjuntos de dados do mainframe sem as atualizações correspondentes nos armazenamentos de metadados distribuídos – ou vice-versa – pode deixar as aplicações em um estado em que elas fazem referência a dados que não existem ou que foram substituídos
• Compromissos divergentes de RTO e RPO – equipes de mainframe e distribuídas frequentemente operam sob SLAs separados, o que pode resultar em esforços de recuperação que restauram cada plataforma independentemente, sem coordenar a consistência pontual necessária para aplicativos que abrangem ambas

Esses também não são casos isolados. Falhas de sincronização podem ser uma das principais causas de uma recuperação que tecnicamente é bem-sucedida, mas falha funcionalmente em ambientes onde os sistemas que não são mainframes acessam os mesmos dados que os mainframes ou são operacionalmente dependentes deles.

Como os ambientes de backup heterogêneos melhoram a resiliência?

Um dos principais impulsos na TI corporativa é a padronização: usar uma plataforma de backup, um conjunto de ferramentas, um modelo operacional. Os ambientes de mainframe, por outro lado, são exatamente o lugar onde essa abordagem pode não ser a melhor opção.

Um ambiente de backup heterogêneo (onde soluções de backup nativas de mainframe operam ao lado de plataformas de sistemas abertos com pontos de integração definidos) pode melhorar a resiliência de maneiras que uma abordagem de fornecedor único nem sempre consegue igualar. Nem vulnerabilidades específicas de fornecedores nem falhas de produtos podem se propagar por todo o parque de backup. Um backup nativo de mainframe utiliza conceitos nativos da plataforma, como arquivos VSAM, os catálogos z/OS e a integridade do sysplex, que produtos de sistemas abertos geralmente não conseguem realizar ou não realizam bem, enquanto os produtos de sistemas abertos gerenciam os componentes distribuídos para os quais foram projetados.

Heterogeneidade não é sinônimo de fragmentação. Trata-se de especialização intencional com integração conhecida – não apenas a presença de múltiplas ferramentas não relacionadas lado a lado, mas uma arquitetura planejada que utiliza o que cada ferramenta faz de melhor.

Como os modelos de backup híbrido e integrado à nuvem podem ser aplicados a mainframes?

A integração com a nuvem evoluiu de uma consideração secundária para uma escolha arquitetônica dominante no backup de mainframes. Essa mudança é impulsionada principalmente por pressões econômicas, necessidades de flexibilidade geográfica e pelo amadurecimento das camadas de armazenamento em nuvem, que agora são projetadas para gerenciar a escala dos volumes de dados de mainframes desde o início.

Também seria justo dizer que, na prática, as opções disponíveis nesse espaço estão amplamente centradas no próprio ecossistema de produtos da IBM, dada a natureza proprietária das interfaces de armazenamento do z/OS.

Quais são as opções para integrar backups de mainframe com armazenamento em nuvem pública?

Existem várias maneiras pelas quais as soluções de backup de mainframe podem se integrar à nuvem pública. Cada abordagem tem características específicas e atenderá a diferentes tipos de necessidades de recuperação e níveis de volume de dados. As abordagens mais amplamente adotadas são:

• Nuvem como substituto da fita – os dados de backup são gravados em camadas de armazenamento de objetos, como AWS S3 ou Azure Blob, usando interfaces compatíveis com mainframe ou dispositivos de gateway que fazem a conversão entre formatos de backup z/OS e APIs de armazenamento em nuvem
• Nuvem como destino de backup secundário – tarefas de backup locais são replicadas para o armazenamento em nuvem como uma cópia secundária, oferecendo proteção fora do local sem substituir a infraestrutura de backup primária no local
• Bibliotecas de fitas virtuais baseadas em nuvem – soluções VTL com back-ends nativos de nuvem que apresentam uma interface de fita familiar ao z/OS enquanto gravam em armazenamento de objetos em nuvem escalável
• Arquiteturas de replicação híbrida – os dados do mainframe são replicados para instâncias de mainframe hospedadas na nuvem ou ambientes compatíveis, permitindo DR baseada na nuvem em vez de apenas armazenamento baseado na nuvem

O padrão de integração escolhido determina diretamente quais cenários de recuperação podem ser facilitados na camada de nuvem. Soluções apenas de armazenamento protegem contra falhas no local, mas não aceleram a recuperação, exigindo recursos de computação na nuvem em vez de apenas dados.

Como a orquestração de DR baseada em nuvem pode ser usada para a recuperação de mainframes?

Salvar cópias de backup na nuvem resolve o problema da preservação. No entanto, para recuperá-las rapidamente, você precisará de orquestração – fluxos de trabalho predefinidos que coordenam a série de ações que ocorrem desde o momento em que a decisão de failover é tomada até que o sistema mainframe esteja realmente em funcionamento.

A orquestração de recuperação de desastres (DR) baseada em nuvem para soluções de backup de mainframe pode incluir:

• Acionamento automatizado de failover – monitoramento de integridade que detecta falhas no site primário e inicia fluxos de trabalho de recuperação sem intervenção manual
• Sequenciamento de recuperação – manuais de procedimentos predefinidos que executam as etapas de IPL, recuperação de catálogo e reinicialização de aplicativos na ordem correta de dependências
• Provisionamento de ambiente – inicialização automatizada dos recursos de computação e armazenamento hospedados na nuvem necessários para receber e executar cargas de trabalho recuperadas
• Automação de testes – testes de DR programados e sem interrupção que validam os procedimentos de recuperação em relação aos dados de backup atuais, sem impactar a produção
• Coordenação de reversão – procedimentos gerenciados de failback que retornam as cargas de trabalho ao site primário assim que ele é restaurado, sem perda de dados ou lacunas de consistência

A maturidade dos recursos de orquestração disponíveis varia drasticamente entre os fornecedores. Nem todas as soluções oferecem suporte nativo a toda a gama de etapas de recuperação específicas do z/OS.

Quais são as considerações de segurança e desempenho ao combinar mainframes com backup em nuvem?

As implicações de estender o backup de mainframe para a nuvem vêm com uma série de nuances, por estar na encruzilhada de dois paradigmas de infraestrutura totalmente diferentes. É melhor examinar essas vantagens e desvantagens lado a lado:

Nem a segurança nem o desempenho podem ser tratados como um tema secundário nas arquiteturas de backup de mainframe na nuvem – pois comprometer qualquer um deles prejudicaria imediatamente o valor de toda a integração.

Quais softwares e ferramentas oferecem suporte ao backup e à recuperação de mainframe?

O panorama do software de backup de mainframe é relativamente restrito, mas sua complexidade é comparável à das soluções de backup distribuídas quando se trata de complexidade geral.

A lista de soluções disponíveis vai desde soluções nativas do Z/OS profundamente integradas até plataformas corporativas mais amplas com conectores de mainframe. Os participantes estabelecidos neste espaço – entre eles, o IBM DFSMS e o DFSMShsm, o CA Disk da Broadcom e o Backup for z/OS da Rocket Software – são abordados em detalhes abaixo, juntamente com as considerações arquitetônicas que se aplicam independentemente da escolha do produto.

A escolha correta varia muito dependendo do ambiente existente, dos requisitos de recuperação e do modelo operacional.

Como os padrões abertos e as APIs (por exemplo, APIs da IBM, REST) facilitam o uso de ferramentas de backup?

A natureza historicamente fechada das ferramentas de backup de mainframe está começando a evoluir na direção de modelos de integração mais abertos. A exposição das funções de gerenciamento do z/OS pela IBM por meio de APIs REST criou possibilidades para que várias integrações sejam desenvolvidas por fornecedores de backup ou desenvolvedores internos (algo que antes era impossível sem o uso de interfaces proprietárias).

A interoperabilidade é o benefício prático aqui. Soluções de backup de mainframe que suportam (fornecem ou utilizam) APIs padrão terão espaço em soluções mais amplas de orquestração de backup corporativo – fornecendo informações de status para ferramentas de monitoramento centralizadas, recebendo alterações de políticas de plataformas de gerenciamento unificadas ou direcionando o armazenamento em nuvem por meio de interfaces padrão de armazenamento de objetos.

A necessidade de especialistas em backup de mainframe não é eliminada completamente (aqueles com experiência em backup do z/OS), mas reduz o grau de separação entre os backups de mainframe e o restante do ambiente de backup corporativo.

Qual é o papel das ferramentas de automação e orquestração nos fluxos de trabalho de recuperação?

Procedimentos manuais de recuperação são um risco. Se runbooks complexos e com várias etapas forem executados sob pressão, a probabilidade de erro humano aumenta drasticamente, incluindo erros de sequenciamento, dependências não atendidas e outros atrasos.

A automação consegue eliminar todas essas questões por definição. As áreas em que a automação oferece o valor mais direto nos fluxos de trabalho de backup e recuperação de mainframe são:

• Agendamento de tarefas de backup e gerenciamento de dependências – garantindo que as tarefas sejam executadas na ordem correta, com etapas de pré e pós-processamento adequadas, sem intervenção manual
• Verificação do catálogo – verificações automatizadas que confirmam a integridade do catálogo de backup após cada tarefa, identificando problemas antes que se tornem surpresas no momento da recuperação
• Fluxos de trabalho de alertas e escalonamento – notificação imediata quando tarefas de backup falham, excedem seu intervalo de tempo ou produzem resultados inconsistentes, encaminhadas às equipes certas sem monitoramento manual
• Execução do roteiro de recuperação – execução sequencial e programada das etapas de recuperação que reduz a carga cognitiva sobre os operadores durante eventos de alto estresse e impõe a ordem correta de dependências

Uma cobertura de automação mais ampla leva à previsibilidade e testabilidade durante os processos de recuperação. Um fluxo de trabalho de recuperação que foi conduzido centenas de vezes automaticamente é significativamente mais confiável do que um fluxo de trabalho que existe apenas como um documento.

Quais produtos comerciais de backup estão disponíveis para z/OS e plataformas relacionadas?

O mercado comercial de soluções de backup para mainframe é dominado por um pequeno grupo de fornecedores especializados cujos produtos vêm evoluindo junto com o z/OS há muitos anos. Assim, todas essas soluções compartilham uma característica comum: são construídas com um entendimento nativo das estruturas do z/OS que plataformas de backup de uso geral não seriam capazes de replicar sem grandes compromissos.

As principais categorias de recursos que diferenciam os produtos de backup para mainframe uns dos outros incluem:

• Granularidade no nível do conjunto de dados – a capacidade de fazer backup, catalogar e restaurar conjuntos de dados individuais, em vez de volumes inteiros, o que é essencial para operações práticas de recuperação no dia a dia
• Reconhecimento de Sysplex – tratamento de estruturas de acoplamento e conjuntos de dados compartilhados em um sysplex paralelo sem lacunas de consistência
• Gerenciamento de catálogo – tratamento integrado do catálogo ICF, que é, por si só, uma dependência de recuperação que deve ser gerenciada com cuidado
• Compressão e desduplicação – redução em linha dos volumes de dados de backup, o que afeta diretamente os custos de armazenamento e a duração da janela de backup

Ao escolher uma solução de backup para mainframe, essas funcionalidades precisam ser ponderadas em relação à combinação de cargas de trabalho e às necessidades de recuperação do ambiente. Algumas das soluções comerciais de backup para mainframe mais amplamente implantadas incluem:

• IBM DFSMS e DFSMShsm – gerenciamento de armazenamento nativo do z/OS da IBM e gerenciador de armazenamento hierárquico
• Broadcom ACF2 e CA Disk – ferramentas de backup e restauração em nível de conjunto de dados há muito estabelecidas, com profunda integração com o z/OS e ampla adoção corporativa
• Rocket Backup for z/OS da Rocket Software – backup de conjuntos de dados de alto desempenho com forte compressão e recursos de gerenciamento de catálogo

Essas soluções não são diretamente intercambiáveis – cada uma apresenta pontos fortes diferentes em áreas como suporte a sysplex, integração com a nuvem e automação operacional, razão pela qual a avaliação de recursos em relação aos requisitos específicos do ambiente é mais importante do que apenas a reputação do fornecedor.

Como a segurança, a conformidade e a retenção são tratadas nos backups de mainframe?

Quais opções de criptografia e gerenciamento de chaves protegem os dados de backup em repouso e em trânsito?

A criptografia baseada em hardware está presente em ambientes de mainframe há décadas, com a família IBM Crypto Express e a criptografia de conjuntos de dados z/OS. É uma vantagem consolidada em relação a muitos ambientes distribuídos, que deve ser mantida assim que os dados de backup saem do ecossistema do mainframe. A criptografia de dados de backup de mainframe em repouso e em trânsito deve ser considerada um requisito e não um recurso opcional.

Em repouso, a criptografia de conjuntos de dados z/OS com AES-256 é realizada implicitamente na camada de armazenamento, de modo que a criptografia pode prosseguir sem quaisquer alterações no software de backup ou no código do aplicativo. Em trânsito, a transmissão para locais externos ou para a nuvem é protegida com criptografia TLS.

O gerenciamento de chaves é onde a complexidade aumenta na maioria dos casos. A criptografia é tão forte quanto as medidas de proteção aplicadas ao armazenamento de chaves. Em ambientes de backup de mainframe, essas chaves devem estar acessíveis durante a recuperação sem se tornarem uma vulnerabilidade em potencial.

A estrutura ICSF da IBM e os módulos de segurança de hardware fornecem a base para o gerenciamento de chaves corporativo no z/OS, mas as organizações que pretendem estender os backups para a nuvem ou destinos distribuídos precisariam garantir que ainda tenham controle sobre a custódia das chaves (em vez de delegar essa tarefa a um provedor terceirizado por padrão).

Quais recursos de auditoria e relatórios são necessários para a verificação de conformidade?

A verificação de conformidade para backup de mainframe não é satisfeita apenas com a implementação das políticas corretas – ela requer evidências comprováveis de que essas políticas estão sendo executadas de forma consistente e que as exceções são capturadas e tratadas. Os recursos de auditoria e relatórios que as soluções de backup de mainframe devem oferecer incluem:

• Registro de conclusão de tarefas – registros com data e hora de cada tarefa de backup, incluindo status de sucesso, falha e conclusão parcial, mantidos durante todo o período de conformidade relevante
• Relatórios de integridade do catálogo – verificação regular de que os catálogos de backup refletem com precisão os dados que indexam, com resultados documentados disponíveis para revisão de auditoria
• Auditoria de acesso e alterações – registros de todas as ações administrativas que afetam a configuração do backup, as configurações de retenção ou os próprios dados de backup, incluindo a identidade do responsável e o registro de data e hora
• Documentação de testes de recuperação – registros formais da execução de testes de DR, resultados e quaisquer lacunas identificadas, que os reguladores esperam cada vez mais ver como evidência de resiliência operacional
• Histórico de exceções e alertas – registros documentados de falhas de backup, janelas perdidas e violações de políticas, juntamente com evidências de como cada uma foi resolvida

Até mesmo a falta de funcionalidade de trilha de auditoria pode ser considerada uma falha de conformidade sob diversos marcos regulatórios; portanto, a infraestrutura de relatórios em torno do backup de mainframe não é uma conveniência de relatórios – é um componente da postura de conformidade.

Como as políticas de retenção devem atender às necessidades regulatórias e comerciais?

O projeto de políticas de retenção para backups de mainframe está na encruzilhada entre mandatos regulatórios, requisitos de recuperação de negócios e gestão de custos de armazenamento. Infelizmente, esses três requisitos raramente têm os mesmos objetivos – a regulamentação pode exigir retenção por 7 anos, os requisitos de recuperação de negócios são atendidos após 90 dias e os custos de armazenamento buscam o menor intervalo defensável possível.

O panorama regulatório estabelece limites mínimos inegociáveis para muitos ambientes de mainframe:

As políticas de retenção devem ser determinadas com base na classificação dos dados, e não por sistema. Um único mainframe pode hospedar dados sujeitos a várias políticas de retenção simultaneamente, e uma política de retenção genérica que aplique o requisito mais conservador a todos os conjuntos de dados desperdiça espaço de armazenamento e complica desnecessariamente o gerenciamento do ciclo de vida.

Como elaborar um roteiro para melhorar a maturidade do backup e da recuperação de desastres (DR) em mainframe?

Melhorar a maturidade do backup de mainframe raramente é um projeto único – trata-se de um programa de melhorias incrementais que visa alcançar uma posição de DR viável, testável e continuamente verificada. O roteiro que se organiza a partir daí começa com uma análise honesta da situação atual.

Quais perguntas de avaliação ajudam a determinar a maturidade atual e as lacunas?

Antes de priorizar melhorias, as organizações precisam de um panorama claro de sua postura atual em relação ao backup de mainframe. As seguintes perguntas formam a base dessa avaliação:

• Os objetivos de recuperação estão formalmente definidos? Devem existir metas documentadas de RTO e RPO para cada carga de trabalho de mainframe, mapeadas para níveis de criticidade – não presumidas ou herdadas de documentação legada que não tenha sido revisada recentemente.
• Quando foi realizado o último teste de recuperação completo? Uma estratégia de backup de mainframe que não tenha sido testada de ponta a ponta nos últimos 12 meses não pode ser considerada confiável – suposições não testadas se acumulam silenciosamente ao longo do tempo. No z/OS, de ponta a ponta significa incluir a sequência de IPL, a recuperação do catálogo ICF e os procedimentos de reinicialização do subsistema — não apenas verificar se os dados de backup existem.
• Os catálogos de backup são armazenados independentemente dos sistemas que protegem? A perda de catálogos durante um evento de recuperação é uma das causas mais comuns e evitáveis de falha na recuperação. No z/OS, isso inclui tanto o catálogo mestre do ICF quanto quaisquer catálogos de usuário, bem como conjuntos de dados de controle do DFSMShsm — todos os quais são dependências de recuperação por si só.
• Os dados de backup estão protegidos contra ameaças internas e ransomware? Políticas de imutabilidade, controles de acesso e procedimentos de isolamento físico devem ser documentados e verificáveis — não se deve presumir que existam apenas porque foram implementados em algum momento no passado. No z/OS, isso significa verificar especificamente a cobertura das políticas RACF ou ACF2 sobre conjuntos de dados e catálogos de backup, e não apenas sobre dados de produção.
• As dependências entre plataformas estão mapeadas? Todo sistema distribuído, API ou aplicativo downstream que dependa de dados de mainframe deve ser documentado, com sua relação de recuperação com o mainframe explicitamente definida.
• O ambiente de backup atende aos requisitos de conformidade atuais? Os períodos de retenção, os padrões de criptografia e os recursos de trilha de auditoria devem ser verificados em relação à estrutura regulatória atual – e não àquela que estava em vigor quando a política de backup foi redigida pela última vez.

Como as melhorias incrementais devem ser priorizadas (resultados rápidos vs. projetos de longo prazo)?

Nem todas as lacunas identificadas na avaliação podem ser resolvidas simultaneamente. Uma estrutura prática de priorização funciona da redução imediata de riscos até a melhoria arquitetônica de longo prazo:

1. Corrija primeiro a vulnerabilidade do catálogo – se os catálogos de backup não estiverem protegidos de forma independente, essa lacuna representa um risco existencial à recuperação que supera todas as outras melhorias em termos de urgência.
2. Estabeleça ou valide os objetivos de recuperação – sem metas documentadas de RTO e RPO, todas as melhorias subsequentes carecem de um padrão mensurável para o qual se trabalhar.
3. Implemente imutabilidade e controles de acesso – melhorias na resiliência contra ransomware têm alto impacto e são relativamente alcançáveis sem grandes mudanças arquitetônicas, tornando-as vitórias iniciais significativas.
4. Realize um teste de recuperação completo – antes de investir em novas ferramentas ou arquitetura, valide o que o ambiente atual pode realmente oferecer em condições reais de recuperação.
5. Resolva as lacunas de sincronização entre plataformas – uma vez que a postura de backup do mainframe esteja estabilizada, amplie o foco para dependências distribuídas e coordenação de recuperação entre as fronteiras das plataformas.
6. Avalie lacunas de ferramentas e automação – com uma visão clara dos requisitos de recuperação e dos recursos atuais, as decisões sobre ferramentas podem ser tomadas com base em critérios específicos e validados, em vez de nas alegações dos fornecedores.
7. Busque a validação contínua – a verificação automatizada de backup, os testes de DR programados e o acompanhamento contínuo de KPIs substituem as avaliações pontuais por uma visão continuamente atualizada da prontidão para DR.

Quais KPIs e métricas devem orientar a maturidade contínua do programa de DR?

Um programa de backup de mainframe que não é medido não é gerenciado. As métricas a seguir fornecem uma estrutura prática para acompanhar a maturidade da DR ao longo do tempo:

• Tempo de Recuperação Real vs. Objetivo – a diferença entre o tempo de recuperação testado e o RTO documentado, medida durante cada teste de DR e acompanhada como uma tendência ao longo do tempo.
• Ponto de recuperação real vs. objetivo – a janela de perda de dados real alcançada durante os testes de recuperação, comparada com o RPO documentado para cada camada de carga de trabalho.
• Taxa de sucesso das tarefas de backup – a porcentagem de tarefas de backup de mainframe agendadas concluídas com sucesso dentro de sua janela definida, acompanhada semanalmente e investigada quando fica abaixo de um limite acordado.
• Tempo médio para detectar falha de backup – a rapidez com que as falhas de backup são identificadas após ocorrerem, o que afeta diretamente por quanto tempo o ambiente opera com uma lacuna não detectada em sua proteção.
• Frequência de verificação da integridade do catálogo – com que frequência os catálogos de backup são verificados quanto à precisão e integridade, com os resultados documentados para fins de auditoria.
• Cobertura da coordenação de recuperação do Sysplex — a porcentagem de cargas de trabalho de Nível 1 para as quais as dependências de recuperação entre sistemas, incluindo estruturas de acoplamento e relações de conjuntos de dados compartilhados, são explicitamente documentadas e testadas.
• Frequência e cobertura dos testes de DR – o número de testes de DR realizados por ano e a porcentagem de cargas de trabalho de Nível 1 e Nível 2 incluídas em cada ciclo de teste.
• Tempo para corrigir lacunas identificadas – o tempo médio entre a identificação de uma lacuna – por meio de testes, auditoria ou monitoramento – e a implementação de uma correção validada.

Conclusão

O backup e a recuperação de mainframe não são um projeto que se resolve uma vez e nunca mais se toca. O cenário de ameaças evolui, os requisitos de negócios mudam, as estruturas regulatórias se tornam mais rígidas e os sistemas que dependem de dados de mainframe ficam cada vez mais interconectados com o tempo. A estratégia de backup de mainframe que era suficiente há três anos provavelmente apresenta várias lacunas hoje — não porque tenha falhado, mas porque o ambiente ao seu redor mudou enquanto a estratégia permaneceu a mesma.

As organizações que conseguem manter uma resiliência genuína de DR abordam o backup de mainframe como um programa contínuo, não como um projeto único. Objetivos de recuperação definidos, procedimentos testados, controles de segurança aplicados e políticas de retenção revisadas regularmente não são entregas pontuais, mas hábitos operacionais que determinam se a recuperação é possível quando realmente importa.

Perguntas frequentes

Os dados de backup de mainframe podem ser usados para apoiar iniciativas de análise ou data lake?

Os dados de backup de mainframe podem servir como fonte para iniciativas de análise, mas exigem um tratamento cuidadoso – os conjuntos de dados de backup são estruturados para recuperação, não para consultas, e normalmente precisam ser transformados antes de se tornarem úteis no contexto de um data lake. A abordagem mais prática é tratar o backup de mainframe como uma fonte de dados secundária que complementa os pipelines de extração de dados criados especificamente para esse fim, em vez de substituí-los. Organizações que tentam usar dados brutos de backup diretamente para análises frequentemente descobrem que a sobrecarga operacional da conversão de formato e da validação de consistência excede o valor dos dados em si.

Quais são os riscos de confiar exclusivamente na replicação para recuperação de desastres?

A replicação lida com falhas no nível do site de forma eficaz, mas não oferece proteção contra corrupção lógica – se dados incorretos forem gravados no site primário, a replicação propaga esses dados incorretos para o site secundário quase em tempo real. Uma estratégia de backup de mainframe baseada apenas em replicação não possui um ponto de recuperação anterior ao evento de corrupção, o que significa que erros lógicos, criptografia por ransomware e bugs de aplicativos que geram dados incorretos podem tornar ambos os sites igualmente inutilizáveis. A replicação deve ser uma camada de uma arquitetura de backup de mainframe mais ampla, não a estratégia completa.

Como as estratégias de backup de mainframe devem se adaptar aos requisitos de ESG e soberania de dados?

Os requisitos de soberania de dados — que determinam que certos dados permaneçam dentro de limites geográficos ou jurisdicionais específicos — restringem diretamente as opções de backup off-site e em nuvem disponíveis para ambientes de mainframe que operam em várias regiões. As soluções de backup de mainframe devem ser avaliadas em relação aos requisitos de soberania de cada jurisdição na qual a organização opera, e não apenas na localização do data center primário. As considerações de ESG acrescentam uma dimensão adicional, com o consumo de energia da infraestrutura de backup – particularmente grandes bibliotecas de fitas e replicação sempre ativa – tornando-se um fator nos relatórios de sustentabilidade para organizações com compromissos formais de ESG.