Cette page a été traduite par l'API Cloud Translation.

Préparer d'autres bases de données autogérées pour le service Backup and DR

Avant de pouvoir sauvegarder les instances de base de données et les données autogérées suivantes, vous devez ajouter le serveur de base de données en tant qu'hôte au service Backup and DR. Pour que cela fonctionne, la plupart des bases de données nécessitent certains paramètres et d'autres étapes de préparation. Les procédures de cette page s'appliquent à la plupart des bases de données autogérées:

Pour	Examiner	Utilisez ensuite
IBM Db2	Sauvegarde et reprise après sinistre pour IBM Db2	Conditions préalables pour la base de données Db2
MariaDB	Sauvegarde et reprise après sinistre pour MariaDB	Conditions préalables pour la base de données MariaDB
MySQL	Sauvegarde et reprise après sinistre pour MySQL	Conditions préalables pour la base de données MySQL
PostgreSQL	Sauvegarde et reprise après sinistre pour PostgreSQL	Conditions préalables pour la base de données PostgreSQL
SAP ASE	Sauvegarde et reprise après sinistre pour SAP ASE	Conditions préalables pour la base de données SAP ASE
SAP IQ	Sauvegarde et reprise après sinistre pour SAP IQ	Conditions préalables pour la base de données SAP IQ
SAP MaxDB	Sauvegarde et reprise après sinistre pour SAP MaxDB	Conditions préalables pour la base de données SAP MaxDB
SAP HANA	Sauvegarde et reprise après sinistre pour SAP HANA	Préparer les bases de données SAP HANA à la sauvegarde
Microsoft SQL Server	Sauvegarde et reprise après sinistre pour SQL Server	Préparer des bases de données SQL Server pour le service Backup and DR
Oracle	Sauvegarde et reprise après sinistre pour Oracle	Conditions préalables pour sauvegarder une base de données Oracle et les pages suivantes

Pour toutes les autres bases de données compatibles avec Backup and DR, suivez les étapes ci-dessous.

Conditions préalables pour la base de données Db2

Chaque base de données doit utiliser le mode de stockage automatique, sinon seules les instances sont détectées.
Chaque base de données doit être en mode journal d'archivage, et LOGARCHMETH1 doit être défini sur le disque local. Pour savoir si la base de données est en mode circulaire ou en mode journal d'archivage, exécutez la commande db2 get db cfg for <database name>| grep LOGARCHMETH1.
Si la base de données est en mode circulaire, définissez la journalisation sur le mode d'archivage avant de continuer. Pour définir le paramètre LOGARCHMETH1, utilisez la commande suivante:
db2 update db cfg for <dbname> LOGARCHMETH1 using 'DISK:<location>'
Pour la base de données de secours HADR, l'option lectures en mode de secours doit être activée, c'est-à-dire que le paramètre DB2_HADR_ROS doit être défini sur ON.

Remarque :L'emplacement de sauvegarde des journaux tiers n'est pas accepté. L'emplacement de la sauvegarde des journaux (LOGARCHMETH1) doit être défini sur disque local pour que la sauvegarde et la récupération réussissent.

Conditions préalables pour la base de données MariaDB

La base de données MariaDB doit se trouver sous LVM et ne doit pas être le volume de démarrage. Exécutez mysql -e "select @@datadir" pour obtenir le chemin d'accès aux données de la base de données.
Le volume LVM à partir duquel les volumes MariaDB sont provisionnés doit disposer d'au moins 20% d'espace libre.
Installez l'agent Backup and DR sur le serveur MariaDB.
Créez un utilisateur de sauvegarde avec les droits Reload, Select, Lock tables et Super ou Replication client. Un nom d'utilisateur et un mot de passe de sauvegarde doivent être configurés avec la configuration de l'hôte.

Pour créer l'utilisateur de sauvegarde, procédez comme suit:
```
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;
```
Remarque :Si plusieurs instances MariaDB s'exécutent sur un serveur, le nom d'utilisateur et le mot de passe de sauvegarde doivent être communs à toutes les instances MariaDB exécutées sur ce serveur.
La journalisation binaire MariaDB log_bin doit être activée pour effectuer des sauvegardes de journaux. Pour configurer l'option de journalisation binaire, arrêtez le serveur MariaDB et modifiez le fichier de configuration my.cnf ou my.ini. Dans la section [mysqld] du fichier de configuration, ajoutez l'option log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```
L'utilisateur mysql doit être défini sur /bin/bash dans le fichier /etc/passwd

Conditions préalables pour les bases de données MySQL

La base de données MySQL doit se trouver sous LVM et ne pas être le volume de démarrage. Exécutez mysql -e "select @@datadir" pour obtenir le chemin d'accès aux données de la base de données.
Pour un résultat optimal, le volume LVM à partir duquel les volumes MySQL sont provisionnés doit disposer d'au moins 20% d'espace libre.
Installer l'agent de sauvegarde et de DR sur l'hôte du serveur MySQL
Assurez-vous que l'instance MySQL est opérationnelle
Le propriétaire de la base de données MySQL (utilisateur de l'OS) doit être autorisé à se connecter. Par exemple, l'utilisateur de l'OS de la base de données doit disposer d'un shell fonctionnel tel que /bin/bash.

Commande permettant d'activer l'utilisateur de l'OS: usermod -s /bin/bash mysql
L'instance MySQL doit disposer d'un utilisateur de sauvegarde de base de données pouvant se connecter à partir de localhost. Exemple: create user actuser'@'localhost identified by 'mypassword';

Remarque :Si plusieurs instances MySQL s'exécutent sur un serveur, le nom d'utilisateur et le mot de passe de la sauvegarde de la base de données doivent être communs à toutes les instances MySQL exécutées sur ce serveur.

Privilège requis pour l'utilisateur de sauvegarde de base de données en cas de sauvegarde et de récupération d'instantanés au niveau du 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;

Les autorisations suivantes sont requises pour l'utilisateur de la sauvegarde de la base de données en cas de sauvegarde et de récupération complètes et incrémentielles (traditionnelles basées sur des fichiers) :
```
GRANT ALL ON *.* TO 'actuser'@'localhost';
SHOW GRANTS FOR CURRENT_USER;
```
Une base de données définie par l'utilisateur doit être présente, à l'exception des bases de données système (information_schema, mysql, performance_schema ou sys).
La journalisation binaire MySQL (log_bin) doit être activée pour effectuer une sauvegarde des journaux. Pour configurer l'option de journal binaire, arrêtez le serveur MySQL et modifiez le fichier de configuration (my.cnf ou my.ini). Dans la section [mysqld] du fichier de configuration, ajoutez l'option log-bin.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```

Conditions préalables pour la base de données PostgreSQL

Cette section contient des informations sur les conditions préalables à la base de données PostgreSQL.

Protéger PostgreSQL du nœud principal

Créez un utilisateur de sauvegarde:

create user actuser;

Accordez des droits de sauvegarde:

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

Le mode d'archivage PostgreSQL (archive_mode) doit être défini sur "ON" pour effectuer des sauvegardes de journaux. Pour configurer l'option de mode de journalisation d'archive, mettez à jour le fichier postgresql.conf dans le répertoire de données de l'instance, puis rechargez PostgreSQL.
```
archive_mode = on
 // Command to reload PostgreSQL
 pg_ctl reload -D <Postgres_datadir_path>
``
```

Exemple : pg_ctl reload -D /pgdata

Protéger PostgreSQL à l'aide d'un nœud de secours

Créez un utilisateur de sauvegarde:

create user actuser;

Accordez des droits de sauvegarde:

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

Configuration du mode d'archivage PostgreSQL (WAL) sur le nœud de secours:

Créez le répertoire dans lequel vous souhaitez conserver les WAL.
L'exemple suppose que /pglog est le répertoire. Exécutez les étapes suivantes en tant qu'utilisateur racine.
```
mkdir /pglog
chown -R postgres:postgres /pglog
```
Configurez les paramètres d'archivage.
L'exemple suppose que $PGDATA est /pgdata/11/data. Exécutez les étapes ci-dessous en tant qu'utilisateur postgres.
Ajoutez ou mettez à jour les paramètres dans le fichier /pgdata/11/data/postgresql.conf.
```
 wal_level = replica
 archive_mode = always
 archive_command = 'test ! -f /pglog/%f && cp %p /pglog/%f'
```
Redémarrez PostgreSQL:
```
 /usr/pgsql-11/bin/pg_ctl stop -D /pgdata/11/data
 /usr/pgsql-11/bin/pg_ctl start -D /pgdata/11/data
```
Ajoutez ou mettez à jour l'entrée dans pg_hba.conf sur le principal pour accepter la connexion de la base de données à partir du standby.
```
host postgres <db-user> <standby-ip/32> <connection method>
```
Exemple : host postgres postgres 10.128.0.29/32 trust

Testez la génération d'archives (en tant qu'utilisateur postgres):
```
ls -l /pglog/
```
Exécutez cette commande de bascule de journal:
```
 /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/
```

Conditions préalables pour la base de données SAP ASE

Avant de commencer, effectuez les opérations suivantes sur le serveur SAP ASE:

Vous devez créer un compte utilisateur de sauvegarde avec des droits de sauvegarde (oper_role ou sa_role). Un nom d'utilisateur et un mot de passe de sauvegarde doivent être configurés avec la configuration de l'hôte. Créez l'utilisateur avec ou sans mot de passe pour exécuter la commande de mise en veille sur la source avec le rôle sa_role/ou avec des droits de mise en veille. Pour créer l'utilisateur avec un mot de passe, exécutez la commande suivante:
```
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
```
Pour configurer la connexion de l'utilisateur sans mot de passe, définissez le mot de passe sur "null", puis exécutez la commande suivante:
```
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
```
Remarque :Si plusieurs instances SAP ASE s'exécutent sur un serveur, le nom d'utilisateur et le mot de passe de sauvegarde doivent être communs à toutes les instances SAP ASE exécutées sur ce serveur.
Installez l'agent de sauvegarde et de reprise après sinistre sur le serveur SAP ASE.
Pour activer la sauvegarde du journal des transactions, Truncate on chkpt false doit être défini au niveau de la base de données pour chaque base de données de l'instance SAP ASE.
Les sauvegardes au niveau du volume sont les suivantes:
- L'instance SAP ASE doit résider sous LVM et ne pas être le volume de démarrage.
- Le volume LVM à partir duquel les volumes SAP ASE sont provisionnés doit disposer d'au moins 20% d'espace libre.

Conditions préalables pour la base de données SAP IQ

Avant de commencer, vérifiez les points suivants sur le serveur SAP IQ:

La journalisation PITR SAP IQ doit être activée pour effectuer une sauvegarde de journal. Pour configurer l'option de journalisation PITR, vous avez besoin des API SAP IQ suivantes:
- ALTER DBSPACE IQ_SYSTEM_LOG RENAME /<pitr_log_location>
- SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = ON`
Après avoir activé la journalisation PITR, une sauvegarde complète de la base de données est nécessaire.
La base de données d'utilitaire doit commencer par spécifier le nom d'utilisateur et le mot de passe, et le nom de base de données doit être utility_db. Par exemple : start_iq -n utility_db -su act,passwd
Le nom d'utilisateur et le mot de passe de la sauvegarde de la base de données doivent être identiques à ceux de utility_db. Ils doivent également disposer de droits DBA. Pour créer l'utilisateur de sauvegarde, par exemple:
```
create user actuser identified by 'mypassword';
grant dba to actuser;
```
Remarque :Si plusieurs instances SAP IQ s'exécutent sur un serveur, le nom d'utilisateur/mot de passe de sauvegarde doit être commun à toutes les instances SAP IQ exécutées sur ce serveur.
- Installez l'agent de sauvegarde et de DR sur l'hôte du serveur SAP IQ.

Conditions préalables pour la base de données SAP MaxDB

Avant de commencer, sur le serveur SAP MaxDB:

Si plusieurs instances MaxDB s'exécutent sur un serveur, le nom d'utilisateur et le mot de passe de la base de données doivent être communs à toutes les instances MaxDB exécutées sur ce serveur.
La sauvegarde automatique des journaux doit être activée. Exécutez la commande suivante pour activer la sauvegarde automatique des journaux:
```
dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> autolog_on
<autolog_backup_template_name>
```
Pour activer la sauvegarde automatique, vous avez besoin d'un modèle de sauvegarde automatique.

Pour créer un modèle de sauvegarde, utilisez la commande suivante.

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

La zone "Écrasement des journaux" doit être désactivée pour activer la sauvegarde automatique des journaux.

Pour désactiver l'écrasement des journaux, utilisez la commande suivante:

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

Installez l'agent de sauvegarde et de reprise après sinistre sur l'hôte du serveur SAP MaxDB.

Étape suivante

Une fois la base de données préparée pour Backup and DR, vous pouvez ajouter l'hôte et découvrir les bases de données.