Política de fim de vida de apoio técnico do serviço de cópia de segurança e RD
A Política de Fim de Vida de Apoio Técnico ("EOSL") do Backup and DR abrange o processo e os detalhes relativos ao fim do apoio técnico do Backup and DR para sistemas e software de terceiros, bem como software e hardware do Backup and DR.
O hardware e o software de terceiros incluem plataformas de hardware, sistemas operativos e software de aplicações protegidos por dispositivos de cópia de segurança/recuperação. Quando uma configuração de hardware, sistema operativo ou software de aplicação de terceiros atinge o EOSL do fornecedor, o apoio técnico do Backup and DR para essas configurações fica limitado à assistência comercialmente razoável.
A cópia de segurança e a recuperação de desastres não vão emitir mais correções rápidas nem atualizações para suportar sistemas de software e hardware que estejam além do fim da vida de apoio técnico dos respetivos fornecedores.
Protocolos de rede suportados
A cópia de segurança e a RD suportam a movimentação de dados através de:
Network Block Device (NBD): este modo de transporte é usado para fazer cópias de segurança de máquinas virtuais do Google Cloud VMware Engine.
NFS - A cópia de segurança e a recuperação de desastres suportam o NFS V3 (apenas) para capturar e apresentar dados nas seguintes configurações de implementação:
Apresentar quaisquer cópias de segurança aos anfitriões do Google Cloud VMware Engine através de um armazenamento de dados NFS
Apresentar um disco de preparação para a captura de dados baseada em agente numa VM do Compute Engine ou do Google Cloud VMware Engine
Ambientes suportados para cópias de segurança
O agente é suportado nestes ambientes.
Cópias de segurança baseadas em agentes
O agente de cópia de segurança e recuperação de desastres pode fazer cópias de segurança e recuperar bases de dados e sistemas de ficheiros suportados de sistemas operativos Microsoft Windows e Linux suportados nos seguintes ambientes.
Tipo de aplicação | Execução em instâncias do Compute Engine | Execução em VMs do Google Cloud VMware Engine |
---|---|---|
Bases de dados | Sim | Sim |
Sistemas de ficheiros | Sim | Sim |
Cópias de segurança sem agente
O serviço de cópias de segurança e recuperação de desastres suporta cópias de segurança de VMs nos seguintes ambientes sem necessitar de um agente na VM:
- Instâncias do Compute Engine e do Cloud SQL (tira partido das APIs de instantâneos do Persistent Disk)
- Bases de dados SAP HANA e IBM Db2 com cópias de segurança no disco persistente
- VMs do Google Cloud VMware Engine (tiram partido das APIs VMware vSphere Storage – Data Protection [anteriormente conhecidas como vStorage APIs for Data Protection ou VADP])
Compatibilidade de armazenamento de objetos para o OnVault
O OnVault suporta o seguinte Google Cloud armazenamento:
- Armazenamento padrão
- Nearline Storage
- Coldline Storage
- Armazenamento de arquivo
Virtualização de dados de aplicações com o agente de cópia de segurança e RD
O agente de cópia de segurança e RD (também conhecido como conetor) é um ficheiro executável simples que oferece as seguintes capacidades avançadas durante os processos de captura e recuperação de dados.
Descoberta de aplicações: o agente de cópia de segurança e recuperação de desastres permite a descoberta detalhada de bases de dados e sistemas de ficheiros configurados num anfitrião de produção
Integração de APIs: sempre que possível, os agentes de cópia de segurança e recuperação de desastres integram-se com as APIs/comandos específicos da aplicação para uma captura eficiente dos dados da aplicação
Alterar monitorização de blocos: em situações em que as aplicações de produção não têm uma monitorização de blocos de alterações incorporada, a solução de cópia de segurança e recuperação de desastres introduz a monitorização de blocos de alterações em plataformas selecionadas
Recuperação/montagem com reconhecimento de aplicações: os agentes de cópia de segurança e RD têm reconhecimento de aplicações incorporado. O agente de cópia de segurança e recuperação de desastres permite-lhe instanciar instâncias utilizáveis de aplicações durante as operações de montagem de recuperação, eliminando assim a necessidade de realizar ações com scripts manuais após a montagem.
Estrutura de captura de dados de aplicações genéricas (LVM): os agentes de cópia de segurança e recuperação de desastres fornecem uma estrutura genérica para capturar dados de qualquer aplicação em execução em sistemas operativos Linux suportados. Esta estrutura fornece hooks para chamar scripts personalizados para alcançar a captura de dados consistente da aplicação e a instanciação da aplicação a partir de dados de cópia de segurança.
Apoio técnico do Microsoft Windows Server
O agente de cópia de segurança e recuperação de desastres suporta os seguintes sistemas operativos Microsoft Windows.
Versão do Sistema Operativo | Apoio técnico básico de agentes para cópia de segurança e RD | Altere o suporte de bloqueio de monitorização para o SQL Server |
---|---|---|
Windows Server 2025 Datacenter | Sim | Sim |
Windows Server 2025 Datacenter Core | Sim | Sim |
Windows Server 2022 Datacenter | Sim | Sim |
Windows Server 2022 Datacenter Core | Sim | Sim |
Windows Server 2019 Datacenter | Sim | Sim |
Windows Server 2019 Datacenter Core | Sim | Sim |
Windows Server 2016 Datacenter | Sim | Sim |
Windows Server 2016 Datacenter Core | Sim | Sim |
Apoio técnico a sistemas operativos Linux
O agente de cópia de segurança e RD suporta os seguintes sistemas operativos Linux (x86).
O apoio técnico básico inclui apoio técnico para sistemas de ficheiros e bases de dados Oracle.
O suporte de monitorização de blocos de alterações (CBT) inclui a capacidade de cópia de segurança incremental permanente para outras bases de dados.
SO | Versão | Apoio técnico básico de agentes para cópia de segurança e RD | Altere o apoio técnico de bloqueio de acompanhamento | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|---|---|
RHEL1,4 | 8.4 | Sim | Sim | V11.0.1 |
8.5 | Sim | Sim | V11.0.1 | |
8.6 | Sim | Sim | V11.0.4 | |
8.7 | Sim | Sim | V11.0.5 | |
8,8 | Sim | Não | V11.0.8 | |
8.9 | Sim | Não | V11.0.9 | |
8.10 | Sim | Não | V11.0.15 | |
9,0 | Sim | Não | V11.0.4 | |
9.2 | Sim | Não | V11.0.8 | |
9.4 | Sim | Não | V11.0.15 | |
9.5 | Sim | Não | V11.0.15 | |
RHEL para SAP 1 | 8.4 | Sim | Sim | V11.0.1 |
8.6 | Sim | Sim | V11.0.4 | |
8,8 | Sim | Não | V11.0.8 | |
9,0 | Sim | Não | V11.0.8 | |
9.2 | Sim | Não | V11.0.8 | |
9.4 | Sim | Não | V11.0.15 | |
SLES 1, 3 | 12 SP5 | Sim | Sim | V11.0.1 |
15 SP2 | Sim | Sim | V11.0.1 | |
15 SP3 | Sim | Sim | V11.0.1 | |
15 SP4 | Sim | Sim | V11.0.4 | |
15 SP5 | Sim | Sim | V11.0.9 | |
15 SP6 | Sim | Sim | V11.0.13 | |
SLES para SAP 1, 3 | 12 SP5 | Sim | Sim | V11.0.1 |
15 SP2 | Sim | Sim | V11.0.1 | |
15 SP3 | Sim | Sim | V11.0.1 | |
15 SP4 | Sim | Sim | V11.0.4 | |
15 SP5 | Sim | Sim | V11.0.9 | |
Rocky Linux | 9.3 | Sim | Não | V11.0.9 |
Rocky Linux otimizado para Google Cloud | 9.3 | Sim | Não | V11.0.9 |
Ubuntu | 20.04 LTS | Sim | Não | V11.0.1 |
22.04 LTS | Sim | Não | V11.0.1 | |
Oracle Linux 1, 2 | 7,0-7,6 | Sim | Não | V11.0.1 |
7.7 | Sim | Não | V11.0.1 | |
7.8 | Sim | Não | V11.0.1 | |
7.9 | Sim | Não | V11.0.1 | |
8.0-8.1 | Sim | Não | V11.0.1 | |
8.2 | Sim | Não | V11.0.1 | |
8.3 | Sim | Não | V11.0.1 | |
8.4 | Sim | Não | V11.0.1 | |
8.5 | Sim | Não | V11.0.1 | |
8.6 | Sim | Não | V11.0.1 | |
8.7 | Sim | Não | V11.0.4 | |
8.85 | Sim | Não | V11.0.8 | |
9,0 | Sim | Não | V11.0.4 | |
9.15 | Sim | Não | V11.0.8 | |
9.25 | Sim | Não | V11.0.8 |
1 O Dynamic Multi Pathing (DMP) da Symantec (Veritas) NÃO é suportado.
2 Compatível apenas com VMs do Google Cloud VMware Engine e não com instâncias/VMs do Compute Engine
3 Durante a atualização "offline" do SuSE (atualização a partir de ISO), o instalador do SuSE não executa uma reconfiguração em pacotes externos, incluindo o módulo CBT e o DLKM. Como resultado, quando o sistema é iniciado com o kernel atualizado, o dlkm não consegue carregar porque os ficheiros de configuração antigos continuam a apontar para o módulo do kernel mais antigo. A atualização do SO a partir de ISO não é suportada.
O serviço de cópia de segurança e RD 4 não suporta o RHEL HA.
5 Suportado nas versões Red Hat Compatible Kernel (RHCK) e Unbreakable Enterprise Kernel (UEK).
Consulte a lista de kernels suportados.
Microsoft SQL Server
Os agentes de cópia de segurança e recuperação de desastres (DR) na versão 1.0.1 e posteriores suportam a captura de dados consistente com a base de dados (capturas instantâneas) do Microsoft SQL Server.
Versão do SQL Server | Versão do Windows Server |
---|---|
SQL Server 2022 autónomo | Windows Server 2025 |
Windows Server 2022 | |
Windows Server 2019 | |
Windows Server 2016 | |
SQL Server 2022 Web | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
Windows Server 2019 Datacenter | |
SQL Server 2022 Standard | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
Windows Server 2019 Datacenter | |
SQL Server 2022 Enterprise | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
Windows Server 2019 Datacenter | |
SQL Server 2019 Web | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
SQL Server 2019 autónomo | Windows Server 2025 |
SQL Server 2019 Standard | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
Windows Server 2019 Datacenter | |
SQL Server 2019 Enterprise | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
Windows Server 2019 Datacenter | |
SQL Server 2017 autónomo | Windows Server 2025 |
SQL Server 2017 Web | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter | |
SQL Server 2016 Web | Windows Server 2025 Datacenter |
Windows Server 2022 Datacenter |
IBM Db2
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O Db2 no Linux pode ser capturado ao nível do volume de forma incremental-forever com acesso instantâneo e criação de clones virtuais para a gestão de dados de teste (TDM). Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, o Db2 no Linux pode ser capturado alternativamente através de uma cópia de segurança completa + incremental. Isto usa a própria cópia de segurança baseada em despejos da base de dados.
Versões do IBM Db2 compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
10.5 | SLES 12 | V11.0.1 |
11.1.0 | SLES 12 | V11.0.1 |
11.5.0 | SLES 12 | V11.0.1 |
11.5.8.0 | RHEL 8.x SLES 12 e 15 |
V11.0.4 |
MariaDB
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O MariaDB no Linux pode ser capturado ao nível do volume de forma incremental-forever com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, pode capturar o MariaDB no Linux através de uma alternativa: uma cópia de segurança completa + incremental. Esta opção usa a própria cópia de segurança baseada em despejos da base de dados e, normalmente, é executada como uma cópia de segurança completa semanal e uma cópia de segurança incremental diária. A recuperação envolve a reconstrução dos incrementais com base na cópia de segurança completa mais recente.
Versões do MariaDB compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
10.3.9 | RHEL 8.1-8.5 | V11.0.1 |
10.4 | RHEL 8.1-8.5 | V11.0.1 |
10.5 | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
10.11 | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 |
MySQL
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O MySQL no Linux pode ser capturado ao nível do volume de forma incremental-forever com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, é possível capturar o MySQL no Linux através de uma alternativa: uma cópia de segurança completa + incremental. Esta opção usa a própria cópia de segurança baseada em despejos da base de dados e, normalmente, é executada como uma cópia de segurança completa semanal e uma cópia de segurança incremental diária. A recuperação implica a reconstrução dos incrementais com base na cópia de segurança completa mais recente.
Versões do MySQL compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
5.7 | RHEL 8.1-8.5 | V11.0.1 |
8.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 |
Oracle
Os agentes de cópia de segurança e DR permitem a captura de dados consistentes da base de dados de bases de dados Oracle. O Oracle tem de ser executado no modo ARCHIVELOG. A captura de dados suporta a captura de dados para discos de preparação formatados como sistemas de ficheiros ou apresentados como destinos de grupos de discos ASM.
A proteção da base de dados Oracle é a mesma para bases de dados executadas em servidores da Bare Metal Solution ou numa instância do Compute Engine.
Também é possível capturar dados de configurações do Oracle Non Active Data Guard e do Active Data Guard.
Família Oracle | Tipos de configuração | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|---|
Oracle 21c Todas as versões |
Autónomo | RHEL 8.4 Rocky Linux 8.7 Windows 2016 e 2019 |
V11.0.7 |
RAC | RHEL 8.4 Rocky Linux 8.7 Windows 2016 e 2019 |
V11.0.7 | |
Exadata 1 | RHEL 8.4 Rocky Linux 8.7 Windows 2016 e 2019 |
V11.0.7 | |
Non Active Data Guard 2 | RHEL 8.4 Rocky Linux 8.7 Windows 2016 e 2019 |
V11.0.7 | |
Active Data Guard 2 | RHEL 8.4 Rocky Linux 8.7 Windows 2016 e 2019 |
V11.0.7 | |
Oracle 19c 3 Todas as versões |
Autónomo | OEL 7.x, 8.x, 9.0 RHEL 8.x, SLES 12, 15 Windows 2016, 2019 RHEL 8.10 com kernel 4.18.0-553.40.1 RHEL 9.5 com kernel 5.14.0-503.23.1 |
V11.0.1 V11.0.15 |
Rocky Linux 8.7 | V11.0.7 | ||
RAC | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Rocky Linux 8.7 | V11.0.7 | ||
Exadata 1 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Rocky Linux 8.7 | V11.0.7 | ||
Non Active Data Guard 2 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Rocky Linux 8.7 | V11.0.7 | ||
Active Data Guard 2 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Rocky Linux 8.7 | V11.0.7 | ||
Oracle 18c 3 Todas as versões |
Autónomo | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 |
RAC | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Exadata 1 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Non Active Data Guard 2 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 | |
Active Data Guard 3 | OEL 7.x, 8.x, 9.0 RHEL 8.x SLES 12, 15 Windows 2016, 2019 |
V11.0.1 |
1 O sistema Oracle Exadata é suportado com iSCSI e NFS
2 A monitorização de blocos de alterações do RMAN da base de dados Oracle só está disponível no Active Data Guard
3 A captura de dados do Oracle 18c e posterior é ao nível do contentor (que inclui todas as PDBs). A montagem com reconhecimento de apps num destino está ao nível do contentor. Os PDBs virtuais num contentor existente são suportados através de scripts personalizados.
Métodos de captura e apresentação de dados suportados
O serviço de cópia de segurança e recuperação de desastres suporta vários métodos de captura e apresentação para bases de dados Oracle em várias configurações. Isto inclui operações de cópia de segurança, recuperação e montagem conscientes da app da base de dados Oracle com TDE (encriptação de dados transparente). Para bases de dados Oracle com TDE, a carteira para TDE pode ser capturada definindo a localização do ficheiro de configuração do Oracle como uma definição avançada para a app Oracle. As montagens conscientes da app para bases de dados com TDE requerem que a carteira seja copiada para a localização adequada no anfitrião de montagem.
Tenha também em atenção que o dNFS com o Oracle é suportado em sistemas operativos Linux.
Configuração da base de dados de produção | Formato de captura1 | Formato de apresentação |
---|---|---|
Ficheiros DB no ASM/RAC | Sistema de ficheiros (dispositivo de blocos) | Sistema de ficheiros autónomo |
Sistema de ficheiros (NFS) | Sistema de ficheiros autónomo (NFS) | |
Sistema de ficheiros (NFS) | Sistema de ficheiros RAC (NFS) | |
Grupo de discos ASM 3, 5 | ASM autónomo | |
Grupo de discos ASM 3, 5 | ASM RAC (um ou mais nós) | |
Ficheiros DB no sistema de ficheiros | Sistema de ficheiros (dispositivo de blocos) | Sistema de ficheiros autónomo |
Sistema de ficheiros (NFS) | Sistema de ficheiros autónomo (NFS) | |
Grupo de discos do ASM 3, 4 e 5 | ASM autónomo | |
Grupo de discos do ASM 3, 4 e 5 | ASM RAC (um ou mais nós) |
O formato de captura 1 é o formato resultante da cópia gerida pela cópia de segurança e RD.
3 A captura de ASM para ASM e a apresentação de cópias de segurança no formato ASM não são suportadas em sistemas operativos Windows
4 Instância do Oracle ASM necessária no sistema de origem para este método de captura
5 A combinação de disco ASM (formato de captura) não é suportada quando os dados são capturados através de NFS
Formatos de captura de dados suportados | Usar o sistema de ficheiros | Usar o grupo de discos do ASM |
---|---|---|
Suporte de cópias de segurança | Dados de HCC ou não HCC | |
Recuperação da Oracle com o RMAN | HCC ou não HCC | |
Suporte com reconhecimento de apps 1 | Exadata para não Exadata |
1 O acesso aos dados de cópias virtuais de dados comprimidos em HCC requer a descompressão dos dados antes do acesso
Apoio técnico do Oracle Exadata
O serviço de cópia de segurança e recuperação de desastres suporta as seguintes configurações do Oracle Exadata.
Versões da Exadata Database Machine: X4 e superior
Versões do Oracle: 18c e 19c
PostgreSQL
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O PostgreSQL no Linux pode ser capturado ao nível do volume de forma incremental-forever com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, é possível capturar o PostgreSQL no Linux através de uma alternativa: uma cópia de segurança completa + incremental. Esta ação usa o comando "pg_dump" da base de dados, que não suporta a cópia de segurança incremental. Por isso, cada cópia de segurança é uma cópia de segurança de despejo completo da base de dados.
Devido a limitações com o PostgreSQL, a recuperação de reversão não é suportada para a operação de restauro de cópias de segurança completas + incrementais.
Versões do PostgreSQL compatíveis | SO compatíveis | Versão mínima necessária do agente do serviço de cópia de segurança e RD |
---|---|---|
10.23 | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
11.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
12.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
13.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
14.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
15.x | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 | V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
16.x | RHEL 8.10 | V11.0.13-14 com correções |
SAP
O serviço de backup e recuperação de desastres suporta o SAP em todas as bases de dados suportadas neste documento.
SAP ASE (anteriormente Sybase ASE)
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O SAP ASE no Linux pode ser capturado ao nível do volume de forma incremental e permanente com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, pode capturar o SAP ASE no Linux através de uma alternativa: uma cópia de segurança completa + incremental. Esta opção usa a própria cópia de segurança baseada em despejos da base de dados e, normalmente, é executada como uma cópia de segurança completa semanal e uma cópia de segurança incremental diária. A recuperação implica a reconstrução dos incrementais com base na cópia de segurança completa mais recente.
Versões do SAP ASE compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
16.0.x | SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
SLES 15 SP4 | V11.0.4 | |
SLES 15 SP5 | V11.0.9 |
SAP HANA
O agente de cópias de segurança e RD suporta a captura do SAP HANA nas seguintes configurações.
Configuração suportada | API SAP HANA SavePoint 2 | SAP baseado em ficheiros (HDBSQL/Backint) 3 | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|---|---|
Expansão horizontal do HANA 2.0, armazenamento não partilhado | Sim (preferencial) 1 | Sim | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
Sim (preferencial) 1 | Sim | RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
Sim (preferencial) 1 | Sim | RHEL 8.7 | V11.0.5 | |
Sim (preferencial) 1 | Sim | RHEL 8.10 | V11.0.14, kernel 4.18.0-553.40.1 | |
Sim (preferencial) 1 | Sim | RHEL 9.2 | V11.0.14 com correções | |
Sim (preferencial) 1 | Sim | RHEL 9.5 | V11.0.14, kernel 5.14.0-503.23.1 | |
Sim (preferencial) 1 | Sim | SLES 15 SP5 | V11.0.9 | |
Expansão horizontal do HANA 2.0, armazenamento partilhado 4 | Não suportado | Sim | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
Não suportado | Sim | RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
Sim (preferencial) 1 | Sim | RHEL 8.7 | V11.0.5 | |
Sim (preferencial) 1 | Sim | SLES 15 SP5 | V11.0.9 | |
SAP HANA 2.0 autónomo ou HA (1+1) | Sim (preferencial) 1 | Sim | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
Sim (preferencial) 1 | Sim | RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
Sim (preferencial) 1 | Sim | RHEL 8.7 | V11.0.5 | |
Sim (preferencial) 1 | Sim | SLES 15 SP5 | V11.0.9 | |
Sistema de contentor único (HANA 1.0) 5 | Sim (preferido) | Sim | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
Sim (preferido) | Sim | RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
Sim (preferencial) 1 | Sim | RHEL 8.7 | V11.0.5 | |
Sim (preferencial) 1 | Sim | SLES 15 SP5 | V11.0.9 |
1 Requer o SAP HANA 2.0 SPS 04 ou posterior
2 A API SAP HANA SavePoint tira partido da CBT de cópia de segurança e recuperação de desastres e suporta a funcionalidade de montagem instantânea incremental e consciente da app com a opção de reversão de registos. O serviço de cópia de segurança e recuperação de desastres suporta CBT com HANA no RHEL 7.2 e posterior. Para uma lista completa das versões do RHEL qualificadas para CBT, consulte o artigo Suporte do sistema operativo Linux.
3 O modo SAP HANA Backint só suporta cópias de segurança completas semanais com cópias de segurança incrementais diárias. Suporta a recuperação do HANA através de comandos HANA HDBSQL/Backint. Além disso, a capacidade de montagem instantânea com reconhecimento de apps não é suportada com a API baseada em ficheiros HANA (HDBSQL/Backint)
4 Só suporta a opção de mapeamento de disco NFS de cópia de segurança e RD. O disco NFS é sempre mapeado para todos os nós do HANA
5 Suporta as opções de mapeamento de discos NFS e de blocos de RD e cópia de segurança
SAP MaxDB
O serviço de cópia de segurança e recuperação de desastres suporta os seguintes métodos de captura de dados:
O SAP MaxDB no Linux pode ser capturado ao nível do volume de forma incremental-forever com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Para os clientes que não usam o LVM ou que não podem usar a captura ao nível do volume, o MaxDB no Linux pode ser capturado alternativamente através de uma cópia de segurança completa + incremental. Esta opção usa a própria cópia de segurança baseada em despejos da base de dados e, normalmente, é executada como uma cópia de segurança completa semanal e uma cópia de segurança incremental diária. A recuperação implica a reconstrução dos incrementais com base na cópia de segurança completa mais recente.
Versões do SAP MaxDB compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
7.9.09 | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
7.9.10 | RHEL 8.1-8.5 | V11.0.1 |
RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
SLES 15 SP5 | V11.0.9 |
SAP IQ (anteriormente Sybase IQ)
O serviço de cópia de segurança e recuperação de desastres suporta a captura do SAP IQ ao nível do volume de forma incremental e permanente com acesso instantâneo e criação de clones virtuais para TDM. Esta opção tira partido do LVM do Linux e das capacidades de acompanhamento de blocos alterados do Backup and DR, e é a alternativa recomendada.
Versões do SAP IQ compatíveis | SO compatíveis | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|
SAP IQ 16.x (completo + incremental) | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
SAP IQ 16.x (LVM + CBT) | RHEL 8.1-8.5 SLES 12 SP5 SLES 15 SP3 |
V11.0.1 |
RHEL 8.6 SLES 15 SP4 |
V11.0.4 | |
RHEL 8.7 | V11.0.5 | |
SLES 15 SP5 | V11.0.9 |
Sistemas de ficheiros
Os agentes de cópia de segurança e recuperação de desastres descobrem cada volume num ponto de montagem de rede como uma aplicação protegível. Para cada uma destas aplicações descobertas, o agente do Backup and DR orquestra o processo de obtenção da consistência (através de instantâneos VSS/LVM), apresenta um disco de preparação que é formatado com um sistema de ficheiros do mesmo tipo que a origem ou um tipo de sistema de ficheiros compatível, conforme documentado aqui.
Sistema operativo | FS de origem | FS do disco de preparação | Versão mínima necessária do agente de cópia de segurança e RD |
---|---|---|---|
Windows | NTFS | NTFS | V11.0.1 |
SMB | NTFS | V11.0.1 | |
ReFS | ReFS | V11.0.1 | |
Linux1 | EXT2 | EXT2 ou NFS4 | V11.0.1 |
EXT3 | EXT3 ou NFS4 | V11.0.1 | |
EXT4 | EXT4 ou NFS4 | V11.0.1 | |
XFS | XFS ou NFS4 | V11.0.1 | |
ReiserFS | ReiserFS ou NFS4 | V11.0.1 | |
NFS | EXT3 ou NFS4 | V11.0.1 | |
BTRFS | EXT3 ou NFS4 | V11.0.1 |
1 O instantâneo do LVM é usado como origem, se estiver presente. A montagem de LVM no mesmo servidor é suportada
2 Apenas versões incorporadas
3 Encriptação não suportada
4 Apenas a V3 do protocolo NFS é suportada
Teste a gestão de dados com contentores
A cópia de segurança e a recuperação de desastres tiram partido dos volumes NFS para disponibilizar os dados das aplicações capturados como partilhas NFS para contentores. Isto permite a criação de clones virtuais de bases de dados suportadas que são acessíveis a partir do ambiente contentorizado.
Virtualização de dados para ambientes virtuais
A cópia de segurança e a RD suportam a virtualização de dados para ambientes virtuais através dos seguintes métodos:
Google Cloud VMware Engine
O serviço de cópia de segurança e recuperação de desastres suporta a captura de dados de máquinas virtuais VMware através de chamadas às APIs de armazenamento do VMware vSphere – Proteção de dados (anteriormente conhecidas como APIs vStorage para proteção de dados ou VADP) para capturar um servidor virtual completo. Especificamente, as chamadas API podem:
Realiza a monitorização de blocos de alterações: faz uma captura instantânea completa inicial de uma base de dados e, posteriormente, apenas captura instantâneas das alterações à base de dados, o que permite a estratégia de captura incremental permanente do Backup and DR.
Desativar aplicações: garante a consistência das aplicações durante a captura.
vCenter 1, 6 | 7.0, 7.0 U1, 7.0 U2, 7.0 U3, 8.0 7 |
---|---|
ESX Server 6 | 7.0, 7.0 U1, 7.0 U2 e 7.0 U3 |
Hardware virtual 2 | 7 a 15 e 17 a 19 |
SO convidado | Todos os SOs suportados pelo Google Cloud VMware Engine |
Desativar aplicações 3 | Sim, com base no VMware Tools |
Suporte do vSAN 4 | vSAN 7.0 U1, vSAN 7.0 U2, vSAN 7.0 U3 |
Alterar o acompanhamento de bloqueios5 | Tira partido das APIs de armazenamento do VMware vSphere – Proteção de dados (anteriormente conhecidas como APIs vStorage para proteção de dados ou VADP) |
1 Tira partido da versão 7.0 do VMware VDDK.
Os tipos de controlador NVME 2 (encontrados no ESX 7.0 e posterior) não são suportados. A versão 14 e posteriores do hardware virtual só são suportadas com o ESX 7.0 (e posteriores)
3 Capacidade aplicável a qualquer aplicação com um VSS Writer ou scripts pré e pós para conseguir uma captura consistente da aplicação.
4 Uma vez que o VMware vSAN não suporta funcionalidades de acesso ao dispositivo RDM, a montagem de uma VM não é suportada pelo Backup and DR quando usa RDMs. As operações de restauro e clonagem de VMs são suportadas. No entanto, a montagem de uma VM é suportada no Backup and DR quando usa o transporte NFS em vez do RDM.
5 Não suportado para discos apresentados a VMs de produção como pRDM.
6 A configuração do modo de transporte SAN para fazer uma cópia de segurança do disco de preparação (cópias de segurança baseadas em agentes) e a montagem e o restauro de cópias de segurança através do iSCSI não são suportados.
7 O VMware vCenter Server 8.0 é suportado no serviço de cópia de segurança e recuperação de desastres 11.0.15 e posterior.