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
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 de 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 y DR, sigue estos procedimientos.

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.
  Nota: Si utiliza Pacemaker HADR, consulte Configurar snapshots compatibles con Pacemaker para IBM Db2 HADR.

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

1. Crea un usuario de respaldo:

   create user actuser;

2. Proporciona privilegios para la copia de seguridad:

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

3. 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

1. Crea un usuario de respaldo:

   create user actuser;

2. Proporciona privilegios para la copia de seguridad:

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

3. 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 presupone 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 estos pasos como usuario 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>'
  2go
  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 and 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 residir 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.

Nota: Es posible que los trabajos de detección y copia de seguridad de SAP ASE dejen de responder debido a un problema conocido con sp_spaceused. Los motivos y la solución para los procedimientos sp_spaceused de larga duración se explican en la nota de SAP "2443782 - execute sp_spaceused takes too long - SAP ASE".

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.