Esta página foi traduzida pela API Cloud Translation.

Prepare outras bases de dados autogeridas para o serviço de cópia de segurança e recuperação de desastres

Antes de poder fazer uma cópia de segurança das seguintes instâncias e dados de bases de dados autogeridas, tem de adicionar o servidor de base de dados como anfitrião ao serviço de cópia de segurança e recuperação de desastres. Para que isto funcione, a maioria das bases de dados requer algumas definições e outros passos de preparação. Os procedimentos nesta página destinam-se à maioria das bases de dados autogeridas:

Para	Reveja	Em seguida, use
IBM Db2	Cópia de segurança e RD para o IBM Db2	Pré-requisitos da base de dados Db2
MariaDB	Cópia de segurança e RD para o MariaDB	Pré-requisitos da base de dados MariaDB
MySQL	Cópia de segurança e RD para o MySQL	Pré-requisitos da base de dados MySQL
PostgreSQL	Cópia de segurança e RD para o PostgreSQL	Pré-requisitos da base de dados PostgreSQL
SAP ASE	Cópia de segurança e RD para SAP ASE	Pré-requisitos da base de dados SAP ASE
SAP IQ	Cópia de segurança e RD para SAP IQ	Pré-requisitos da base de dados SAP IQ
SAP MaxDB	Cópia de segurança e RD para SAP MaxDB	Pré-requisitos da base de dados SAP MaxDB
SAP HANA	Cópia de segurança e RD para SAP HANA	Prepare bases de dados SAP HANA para a cópia de segurança
Microsoft SQL Server	Cópia de segurança e RD para o SQL Server	Prepare bases de dados do SQL Server para o serviço de cópia de segurança e recuperação de desastres
Oracle	Cópia de segurança e RD para Oracle	Pré-requisitos para fazer uma cópia de segurança de uma base de dados Oracle e das páginas seguintes

Para todas as outras bases de dados suportadas pelo Backup and DR, siga os passos abaixo.

Pré-requisitos da base de dados Db2

Cada base de dados tem de usar o modo de armazenamento automático. Caso contrário, apenas são descobertas instâncias.
Cada base de dados tem de estar no modo de registo de arquivo e LOGARCHMETH1 tem de estar definido como disco local. Para saber se a base de dados está no modo circular ou no modo de registo de arquivo, execute o comando db2 get db cfg for <database name>| grep LOGARCHMETH1
Se a base de dados estiver no modo circular, altere o registo para o modo de arquivo antes de continuar. Para definir o parâmetro LOGARCHMETH1, use o seguinte:
db2 update db cfg for <dbname> LOGARCHMETH1 using 'DISK:<location>'
Para a base de dados de espera HADR, a opção Leituras em espera tem de estar ativada, ou seja, o parâmetro DB2_HADR_ROS tem de estar definido como ON.

Nota: a localização de cópia de segurança de registos de terceiros não é suportada. A localização da cópia de segurança do registo (LOGARCHMETH1) tem de estar definida como disco local para que a cópia de segurança e a recuperação sejam bem-sucedidas.

Pré-requisitos da base de dados MariaDB

A base de dados MariaDB tem de estar localizada no LVM e não pode ser o volume de arranque. Execute mysql -e "select @@datadir" para obter o caminho dos dados da base de dados.
O volume LVM a partir do qual os volumes do MariaDB são aprovisionados deve ter, pelo menos, 20% de espaço livre.
Instale o agente de cópia de segurança e RD no servidor MariaDB.
Crie um utilizador de cópia de segurança com os privilégios Reload, Select, Lock tables e Super ou Replication client. Tem de configurar um nome de utilizador e uma palavra-passe de cópia de segurança com a configuração do anfitrião.

Para criar o utilizador de cópia de segurança, faça o seguinte:
```
create user actuser identified by 'actpasswd';
GRANT SELECT on *.* TO actuser;
GRANT RELOAD on *.* TO actuser;
GRANT LOCK TABLES on *.* TO actuser;
GRANT SUPER on *.* TO actuser;
GRANT REPLICATION CLIENT on *.* to actuser;
SHOW GRANTS FOR CURRENT_USER;
```
Nota: se existirem várias instâncias do MariaDB em execução num servidor, o nome de utilizador e a palavra-passe da cópia de segurança têm de ser comuns a todas as instâncias do MariaDB em execução nesse servidor.
O registo binário do MariaDB log_bin tem de estar ativado para fazer cópias de segurança de registos. Para configurar a opção de registo binário, encerre o servidor MariaDB e edite o ficheiro de configuração my.cnf ou my.ini. Na secção [mysqld] do ficheiro de configuração, adicione a opção log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```
O utilizador do MySQL tem de estar definido como /bin/bash no ficheiro /etc/passwd

Pré-requisitos da base de dados MySQL

A base de dados MySQL tem de estar localizada no LVM e não pode ser o volume de arranque. Execute mysql -e "select @@datadir" para obter o caminho dos dados da base de dados.
Para obter os melhores resultados, o volume LVM a partir do qual os volumes MySQL são aprovisionados deve ter, pelo menos, 20% de espaço livre.
Instale o agente do Backup and DR no anfitrião do servidor MySQL
Certifique-se de que a instância do MySQL está em funcionamento
O proprietário da base de dados do MySQL (utilizador do SO) tem de ter autorização para iniciar sessão. Por exemplo, o utilizador do SO da base de dados deve ter um shell funcional, como /bin/bash.

Comando para ativar o utilizador do SO: usermod -s /bin/bash mysql
A instância do MySQL deve ter um utilizador de cópia de segurança da base de dados que se possa ligar a partir de localhost. Exemplo: create user actuser'@'localhost identified by 'mypassword';

Nota: se existirem várias instâncias do MySQL em execução num servidor, o nome de utilizador e a palavra-passe da cópia de segurança da base de dados têm de ser comuns a todas as instâncias do MySQL em execução nesse servidor.

Privilégio necessário para o utilizador de cópia de segurança da base de dados em caso de cópia de segurança e recuperação de instantâneos ao nível do volume:

GRANT SELECT on *.* TO actuser;
GRANT RELOAD on *.* TO actuser;
GRANT LOCK TABLES on *.* TO actuser;
GRANT SUPER on *.* TO actuser;
GRANT REPLICATION CLIENT on *.* to actuser;
SHOW GRANTS FOR CURRENT_USER;

Os seguintes privilégios são necessários para o utilizador da cópia de segurança da base de dados em caso de cópia de segurança e recuperação tradicionais baseadas em ficheiros:
```
GRANT ALL ON *.* TO 'actuser'@'localhost';
SHOW GRANTS FOR CURRENT_USER;
```
Tem de existir uma base de dados definida pelo utilizador que não seja uma base de dados do sistema: information_schema, mysql, performance_schema ou sys.
O registo binário do MySQL (log_bin) tem de estar ativado para fazer uma cópia de segurança do registo. Para configurar a opção de registo binário, encerre o servidor MySQL e edite o ficheiro de configuração: my.cnf ou my.ini. Na secção [mysqld] do ficheiro de configuração, adicione a opção log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```

Pré-requisitos da base de dados PostgreSQL

Esta secção inclui informações acerca dos pré-requisitos da base de dados PostgreSQL.

Proteja o PostgreSQL a partir do nó principal

Crie um utilizador alternativo:

create user actuser;

Conceda privilégios para a cópia de segurança:

alter user actuser with superuser;
alter user actuser with Replication;

O modo de arquivo do PostgreSQL (archive_mode) tem de estar definido como ON para fazer cópias de segurança de registos. Para configurar a opção de modo de registo de arquivo, atualize o ficheiro postgresql.conf no diretório de dados da instância e recarregue o PostgreSQL.
```
archive_mode = on
 // Command to reload PostgreSQL
 pg_ctl reload -D <Postgres_datadir_path>
``
```

Exemplo: pg_ctl reload -D /pgdata

Proteja o PostgreSQL a partir de um nó em espera

Crie um utilizador alternativo:

create user actuser;

Conceda privilégios para a cópia de segurança:

alter user actuser with superuser;
alter user actuser with Replication;

Modo de arquivo do PostgreSQL: configuração do WAL no nó de espera:

Crie o diretório onde quer manter os WALs.
O exemplo pressupõe que /pglog é o diretório. Execute os seguintes passos como utilizador root.
```
mkdir /pglog
chown -R postgres:postgres /pglog
```
Configure os parâmetros para o arquivo.
O exemplo pressupõe que $PGDATA é /pgdata/11/data. Execute os passos abaixo como utilizador do postgres.
Adicione ou atualize os parâmetros no ficheiro /pgdata/11/data/postgresql.conf
```
 wal_level = replica
 archive_mode = always
 archive_command = 'test ! -f /pglog/%f && cp %p /pglog/%f'
```
Reinicie o PostgreSQL:
```
 /usr/pgsql-11/bin/pg_ctl stop -D /pgdata/11/data
 /usr/pgsql-11/bin/pg_ctl start -D /pgdata/11/data
```
Adicione ou atualize a entrada em pg_hba.conf na base de dados principal para aceitar a ligação da base de dados a partir da base de dados em espera.
```
host postgres <db-user> <standby-ip/32> <connection method>
```
Exemplo: host postgres postgres 10.128.0.29/32 trust

Teste a geração do arquivo (como utilizador do postgres):
```
ls -l /pglog/
```
Execute este comando de mudança de registo:
```
 /usr/pgsql-11/bin/psql -h 10.128.0.28 -p5432 -c "select pg_switch_wal();"
 sleep 5 # log shipping may take some time depending on network
 ls -l /pglog/
```

Pré-requisitos da base de dados SAP ASE

Antes de começar, no servidor SAP ASE, conclua o seguinte:

Tem de criar uma conta de utilizador alternativa com privilégios alternativos, ou seja, oper_role ou sa_role. Tem de configurar um nome de utilizador e uma palavra-passe de cópia de segurança com a configuração do anfitrião. Crie o utilizador com ou sem uma palavra-passe para executar o comando quiesce na origem com sa_role/ou com privilégios de quiesce. Para criar o utilizador com uma palavra-passe, execute o seguinte:
```
isql -Usa -P<password> -S<SAP ASE_Server_Name>
1>sp_addlogin actuser, '<password>'
2>go
1>grant role sa_role to actuser
2>go
```
Para configurar o início de sessão do utilizador sem um requisito de palavra-passe, defina a palavra-passe como nula e, em seguida, execute o seguinte comando:
```
1>sp_configure "minimum password length", 0
2>go
1> sp_modifylogin actuser, "min passwd length",
"0"
2> go
3> exit
isql -Uactuser -P'<password>' -S<server_name>
> sp_password '<password>', NULL
>go
>sp_configure "minimum password length", 8
>go
```
Nota: se existirem várias instâncias do SAP ASE em execução num servidor, o nome de utilizador e a palavra-passe da cópia de segurança têm de ser comuns a todas as instâncias do SAP ASE em execução nesse servidor.
Instale o agente do Backup and DR no servidor SAP ASE.
Para ativar a cópia de segurança do registo de transações, Truncate on chkpt false tem de ser definida ao nível da base de dados para cada base de dados da instância do SAP ASE.
O seguinte é verdadeiro para as cópias de segurança do nível de volume:
- A instância do SAP ASE tem de residir no LVM e não pode ser o volume de arranque.
- O volume LVM a partir do qual os volumes SAP ASE são aprovisionados deve ter, pelo menos, 20% de espaço livre.

Pré-requisitos da base de dados SAP IQ

Antes de começar, reveja o seguinte no servidor SAP IQ:

O registo PITR do SAP IQ tem de estar ATIVADO para fazer uma cópia de segurança do registo. Para configurar a opção de registo PITR, precisa destas APIs SAP IQ:
- ALTER DBSPACE IQ_SYSTEM_LOG RENAME /<pitr_log_location>
- SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = ON`
Depois de ativar o registo PITR, é necessária uma cópia de segurança completa da base de dados.
A base de dados de utilidade tem de começar por especificar o nome de utilizador e a palavra-passe, e o nome da base de dados deve ser utility_db. Por exemplo: start_iq -n utility_db -su act,passwd
O nome de utilizador e a palavra-passe da cópia de segurança da base de dados devem ser os mesmos que o utility_db nome de utilizador e a palavra-passe, e tem de ter privilégios de DBA. Para criar o utilizador de cópia de segurança, por exemplo:
```
create user actuser identified by 'mypassword';
grant dba to actuser;
```
Nota: se existirem várias instâncias do SAP IQ em execução num servidor, o nome de utilizador/palavra-passe de cópia de segurança tem de ser comum a todas as instâncias do SAP IQ em execução nesse servidor.
- Instale o agente do Backup and DR no anfitrião do servidor SAP IQ.

Pré-requisitos da base de dados SAP MaxDB

Antes de começar, no servidor SAP MaxDB:

Se existirem várias instâncias do MaxDB em execução num servidor, o nome de utilizador e a palavra-passe da base de dados têm de ser comuns a todas as instâncias do MaxDB em execução nesse servidor.
A cópia de segurança do registo automático tem de estar ativada. Use o seguinte comando para ativar a cópia de segurança automática do registo:
```
dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> autolog_on
<autolog_backup_template_name>
```
Para ativar a cópia de segurança do registo automático, precisa de um modelo de cópia de segurança do registo automático.

Para criar um modelo de cópia de segurança, use o seguinte comando.

    dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> backup_template_create
    <BACKUP_TEMPLATE_NAME> to file  <FULL_PATH_WITH_FILE_NAME> content log

A área de substituição de registos tem de estar desativada para ativar a ativação da cópia de segurança automática de registos.

Para desativar a substituição de registos, use o seguinte comando:

    dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> db_execute SET LOG AUTO
    OVERWRITE OFF.

Instale o agente do Backup and DR no anfitrião do servidor SAP MaxDB.

O que se segue?

Depois de a base de dados estar preparada para a solução de cópia de segurança e recuperação de desastres, pode adicionar o anfitrião e descobrir as bases de dados.