Esta página se ha traducido con Cloud Translation API.

Preparar otras bases de datos autogestionadas para el servicio de copia de seguridad y recuperación tras fallos

Para poder crear copias de seguridad de las siguientes instancias y datos de bases de datos autogestionadas, debes añadir el servidor de bases de datos como host al servicio Backup and DR. Para que esto funcione, la mayoría de las bases de datos requieren algunos ajustes y otros pasos de preparación. Los procedimientos de esta página se aplican a la mayoría de las bases de datos autogestionadas:

Para	Revisar	Después, usa la
IBM Db2	Backup y DR para IBM Db2	Requisitos previos de la base de datos Db2
MariaDB	Copia de seguridad y recuperación ante desastres de MariaDB	Requisitos previos de la base de datos MariaDB
MySQL	Copia de seguridad y recuperación ante desastres de MySQL	Requisitos previos de la base de datos MySQL
PostgreSQL	Backup y DR para PostgreSQL	Requisitos previos de la base de datos PostgreSQL
SAP ASE	Copia de seguridad y recuperación ante desastres para SAP ASE	Requisitos previos de la base de datos SAP ASE
SAP IQ	Copia de seguridad y recuperación ante desastres para SAP IQ	Requisitos previos de la base de datos SAP IQ
SAP MaxDB	Backup y recuperación ante desastres para SAP MaxDB	Requisitos previos de la base de datos SAP MaxDB
SAP HANA	Backup y DR para SAP HANA	Preparar bases de datos SAP HANA para la copia de seguridad
Microsoft SQL Server	Copia de seguridad y recuperación ante desastres para SQL Server	Preparar bases de datos de SQL Server para el servicio de Backup y DR
Oracle	Backup y DR para Oracle	Requisitos previos para crear copias de seguridad de una base de datos de Oracle y sus páginas siguientes

Para todas las demás bases de datos compatibles con Backup and DR, sigue los pasos que se indican a continuación.

Requisitos previos de la base de datos Db2

Cada base de datos debe usar el modo de almacenamiento automático. De lo contrario, solo se detectarán las instancias.
Cada base de datos debe estar en modalidad de registro de archivado y LOGARCHMETH1 debe estar definido como disco local. Para saber si la base de datos está en modo circular o en modo de registro de archivo, ejecuta el comando db2 get db cfg for <database name>| grep LOGARCHMETH1.
Si la base de datos está en modo circular, cambia el registro al modo de archivo antes de continuar. Para definir el parámetro LOGARCHMETH1, usa lo siguiente:
db2 update db cfg for <dbname> LOGARCHMETH1 using 'DISK:<location>'
En el caso de las bases de datos de espera de alta disponibilidad y recuperación ante desastres, la opción Lecturas en espera debe estar habilitada, es decir, el parámetro DB2_HADR_ROS debe tener el valor ON.

Nota: No se admite la ubicación de copia de seguridad de los registros de terceros. La ubicación de la copia de seguridad del registro (LOGARCHMETH1) debe ser disco local para que la copia de seguridad y la recuperación se realicen correctamente.

Requisitos de la base de datos MariaDB

La base de datos MariaDB debe estar en LVM y no puede ser el volumen de arranque. Ejecuta mysql -e "select @@datadir" para obtener la ruta de datos de la base de datos.
El volumen de LVM desde el que se aprovisionan los volúmenes de MariaDB debe tener al menos un 20% de espacio libre.
Instala el agente de copias de seguridad y recuperación ante desastres en el servidor MariaDB.
Crea un usuario de copia de seguridad con los privilegios Reload, Select, Lock tables y Super o Replication client. Se debe configurar un nombre de usuario y una contraseña de copia de seguridad con la configuración del host.

Para crear el usuario de copia de seguridad, sigue estos pasos:
```
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: Si hay varias instancias de MariaDB ejecutándose en un servidor, el nombre de usuario y la contraseña de la copia de seguridad deben ser comunes a todas las instancias de MariaDB que se ejecuten en ese servidor.
El registro binario de MariaDB log_bin debe estar activado para crear copias de seguridad de los registros. Para configurar la opción de registro binario, cierra el servidor MariaDB y edita el archivo de configuración my.cnf o my.ini. En la sección [mysqld] del archivo de configuración, añade la opción log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```
El usuario de MySQL debe tener el valor /bin/bash en el archivo /etc/passwd.

Requisitos previos de la base de datos MySQL

La base de datos MySQL debe estar en LVM y no puede ser el volumen de arranque. Ejecuta mysql -e "select @@datadir" para obtener la ruta de datos de la base de datos.
Para obtener los mejores resultados, el volumen de LVM desde el que se aprovisionan los volúmenes de MySQL debe tener al menos un 20% de espacio libre.
Instalar el agente de Backup y DR en el host del servidor MySQL
Asegúrate de que la instancia de MySQL esté activa y en funcionamiento.
El propietario de la base de datos MySQL (usuario del SO) debe tener habilitada la opción de iniciar sesión. Por ejemplo, el usuario del SO de la base de datos debe tener un shell que funcione, como /bin/bash.

Comando para habilitar el usuario del SO: usermod -s /bin/bash mysql
La instancia de MySQL debe tener un usuario de copia de seguridad de la base de datos que pueda conectarse desde localhost. Ejemplo: create user actuser'@'localhost identified by 'mypassword';

Nota: Si hay varias instancias de MySQL ejecutándose en un servidor, el nombre de usuario y la contraseña de la copia de seguridad de la base de datos deben ser los mismos para todas las instancias de MySQL que se ejecuten en ese servidor.

Privilegio necesario para el usuario de copia de seguridad de la base de datos en caso de copia de seguridad y recuperación de instantáneas a nivel de volumen:

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;

Se requieren los siguientes privilegios para el usuario de copia de seguridad de la base de datos en caso de copia de seguridad y recuperación tradicionales basadas en archivos de tipo Completa e Incremental:
```
GRANT ALL ON *.* TO 'actuser'@'localhost';
SHOW GRANTS FOR CURRENT_USER;
```
Debe haber una base de datos definida por el usuario, además de las bases de datos del sistema: information_schema, mysql, performance_schema o sys.
El registro binario de MySQL (log_bin) debe estar activado para poder crear copias de seguridad de los registros. Para configurar la opción de registro binario, cierra el servidor MySQL y edita el archivo de configuración (my.cnf o my.ini). En la sección [mysqld] del archivo de configuración, añade la opción log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```

Requisitos previos de la base de datos PostgreSQL

En esta sección se incluye información sobre los requisitos previos de la base de datos PostgreSQL.

Proteger PostgreSQL desde el nodo principal

Crea un usuario de respaldo:

create user actuser;

Proporciona privilegios para la copia de seguridad:

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

El modo de archivo de PostgreSQL (archive_mode) debe estar activado para crear copias de seguridad de los registros. Para configurar la opción del modo de registro de archivo, actualiza el archivo postgresql.conf en el directorio de datos de la instancia y vuelve a cargar PostgreSQL.
```
archive_mode = on
 // Command to reload PostgreSQL
 pg_ctl reload -D <Postgres_datadir_path>
``
```

Ejemplo: pg_ctl reload -D /pgdata

Proteger PostgreSQL de un nodo de reserva

Crea un usuario de respaldo:

create user actuser;

Proporciona privilegios para la copia de seguridad:

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

Configuración del modo de archivo de PostgreSQL (WAL) en el nodo de espera:

Crea el directorio en el que queremos conservar los WALs.
En este ejemplo, se da por hecho que /pglog es el directorio. Sigue estos pasos como usuario root.
```
mkdir /pglog
chown -R postgres:postgres /pglog
```
Configura los parámetros de archivado.
En este ejemplo, se presupone que $PGDATA es /pgdata/11/data. Sigue los pasos que se indican a continuación como usuario de postgres.
Añade o actualiza los parámetros del archivo /pgdata/11/data/postgresql.conf.
```
 wal_level = replica
 archive_mode = always
 archive_command = 'test ! -f /pglog/%f && cp %p /pglog/%f'
```
Reinicia PostgreSQL:
```
 /usr/pgsql-11/bin/pg_ctl stop -D /pgdata/11/data
 /usr/pgsql-11/bin/pg_ctl start -D /pgdata/11/data
```
Añade o actualiza la entrada en pg_hba.conf en Primario para aceptar la conexión de la base de datos desde la instancia de espera.
```
host postgres <db-user> <standby-ip/32> <connection method>
```
Ejemplo: host postgres postgres 10.128.0.29/32 trust

Prueba la generación del archivo (como usuario de postgres):
```
ls -l /pglog/
```
Ejecuta este comando de cambio de registro:
```
 /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/
```

Requisitos previos de la base de datos SAP ASE

Antes de empezar, haz lo siguiente en el servidor SAP ASE:

Se debe crear una cuenta de usuario alternativa con el privilegio de copia de seguridad, ya sea oper_role o sa_role. Se debe configurar un nombre de usuario y una contraseña de copia de seguridad con la configuración del host. Crea el usuario con o sin contraseña para ejecutar el comando quiesce en la fuente con sa_role o con privilegios quiesce. Para crear el usuario con una contraseña, ejecuta lo siguiente:
```
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 el inicio de sesión del usuario sin necesidad de contraseña, establece la contraseña como nula y, a continuación, ejecuta el siguiente 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: Si hay varias instancias de SAP ASE ejecutándose en un servidor, el nombre de usuario y la contraseña de la copia de seguridad deben ser los mismos para todas las instancias de SAP ASE que se ejecuten en ese servidor.
Instala el agente de Backup y DR en el servidor SAP ASE.
Para habilitar la copia de seguridad del registro de transacciones, Truncate on chkpt false debe definirse a nivel de base de datos para cada base de datos de la instancia de SAP ASE.
Esto se aplica a las copias de seguridad a nivel de volumen:
- La instancia de SAP ASE debe estar en LVM y no puede ser el volumen de arranque.
- El volumen de LVM desde el que se aprovisionan los volúmenes de SAP ASE debe tener al menos un 20% de espacio libre.

Requisitos previos de la base de datos SAP IQ

Antes de empezar, revisa lo siguiente en el servidor SAP IQ:

El registro PITR de SAP IQ debe estar ACTIVADO para crear una copia de seguridad de los registros. Para configurar la opción de registro de PITR, necesitas estas APIs de SAP IQ:
- ALTER DBSPACE IQ_SYSTEM_LOG RENAME /<pitr_log_location>
- SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = ON`
Después de habilitar el registro de PITR, es necesario hacer una copia de seguridad completa de la base de datos.
La base de datos de la utilidad debe empezar especificando el nombre de usuario y la contraseña, y el nombre de la base de datos debe ser utility_db. Por ejemplo: start_iq -n utility_db -su act,passwd
El nombre de usuario y la contraseña de la copia de seguridad de la base de datos deben ser los mismos que el nombre de usuario y la contraseña de utility_db y debe tener privilegios de administrador de bases de datos. Para crear el usuario de copia de seguridad, por ejemplo:
```
create user actuser identified by 'mypassword';
grant dba to actuser;
```
Nota: Si hay varias instancias de SAP IQ ejecutándose en un servidor, el nombre de usuario y la contraseña de la copia de seguridad deben ser los mismos para todas las instancias de SAP IQ que se ejecuten en ese servidor.
- Instala el agente de Backup and DR en el host del servidor SAP IQ.

Requisitos previos de la base de datos SAP MaxDB

Antes de empezar, en el servidor SAP MaxDB:

Si hay varias instancias de MaxDB ejecutándose en un servidor, el nombre de usuario y la contraseña de la base de datos deben ser los mismos para todas las instancias de MaxDB que se ejecuten en ese servidor.
La copia de seguridad de registro automático debe estar habilitada. Usa el siguiente comando para habilitar la copia de seguridad automática de registros:
```
dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> autolog_on
<autolog_backup_template_name>
```
Para habilitar la copia de seguridad de registro automático, necesitas una plantilla de copia de seguridad de registro automático.

Para crear una plantilla de copia de seguridad, usa el siguiente comando.

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

El área de sobrescritura de registros debe estar desactivada para habilitar la copia de seguridad automática de registros.

Para desactivar la sobrescritura de registros, usa el siguiente comando:

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

Instala el agente de Backup and DR en el host del servidor SAP MaxDB.

Siguientes pasos

Una vez que la base de datos esté preparada para Backup and DR, puede añadir el host y detectar las bases de datos.