Diese Seite wurde von der Cloud Translation API übersetzt.

Andere selbst verwaltete Datenbanken für den Sicherungs- und Notfallwiederherstellungsdienst vorbereiten

Bevor Sie die folgenden selbst verwalteten Datenbankinstanzen und ‑daten sichern können, müssen Sie den Datenbankserver dem Sicherungs- und Notfallwiederherstellungsdienst als Host hinzufügen. Damit dies funktioniert, sind bei den meisten Datenbanken einige Einstellungen und andere Vorbereitungsschritte erforderlich. Die Verfahren auf dieser Seite gelten für die meisten selbst verwalteten Datenbanken:

Für	Überprüfen	Verwenden Sie dann
IBM Db2	Sicherung und Notfallwiederherstellung für IBM Db2	Voraussetzungen für Db2-Datenbanken
MariaDB	Sicherung und Notfallwiederherstellung für MariaDB	Voraussetzungen für die MariaDB-Datenbank
MySQL	Sicherung und Notfallwiederherstellung für MySQL	Voraussetzungen für MySQL-Datenbanken
PostgreSQL	Sicherung und Notfallwiederherstellung für PostgreSQL	Voraussetzungen für PostgreSQL-Datenbanken
SAP ASE	Sicherung und Notfallwiederherstellung für SAP ASE	Voraussetzungen für SAP ASE-Datenbanken
SAP IQ	Sicherung und Notfallwiederherstellung für SAP IQ	Voraussetzungen für SAP IQ-Datenbanken
SAP MaxDB	Sicherung und Notfallwiederherstellung für SAP MaxDB	Voraussetzungen für SAP MaxDB-Datenbanken
SAP HANA	Sicherung und Notfallwiederherstellung für SAP HANA	SAP HANA-Datenbanken für die Sicherung vorbereiten
Microsoft SQL Server	Sicherung und Notfallwiederherstellung für SQL Server	SQL Server-Datenbanken für den Sicherungs- und Notfallwiederherstellungsdienst vorbereiten
Oracle	Backup und DR für Oracle	Voraussetzungen für die Sicherung einer Oracle-Datenbank und die folgenden Seiten

Bei allen anderen von Backup und DR unterstützten Datenbanken gehen Sie so vor:

Voraussetzungen für Db2-Datenbanken

Für jede Datenbank muss der automatische Speichermodus verwendet werden. Andernfalls werden nur Instanzen erkannt.
Jede Datenbank muss sich im Archivierungsprotokollmodus befinden und LOGARCHMETH1 muss auf „local disk“ (lokaler Datenträger) gesetzt sein. Führen Sie den Befehl db2 get db cfg for <database name>| grep LOGARCHMETH1 aus, um zu prüfen, ob sich die Datenbank im zyklischen Modus oder im Archivierungsprotokollmodus befindet.
Wenn sich die Datenbank im zyklischen Modus befindet, ändern Sie die Protokollierung in den Archivierungsmodus, bevor Sie fortfahren. So legen Sie den Parameter LOGARCHMETH1 fest:
db2 update db cfg for <dbname> LOGARCHMETH1 using 'DISK:<location>'
Für die HADR-Standby-Datenbank muss die Option Lesungen im Standby aktiviert sein. Das bedeutet, dass der Parameter DB2_HADR_ROS auf ON festgelegt sein muss.

Hinweis: Der Speicherort für die Protokollsicherung von Drittanbietern wird nicht unterstützt. Der Speicherort der Protokollsicherung (LOGARCHMETH1) muss auf lokaler Datenträger festgelegt sein, damit Sicherung und Wiederherstellung erfolgreich sind.

Voraussetzungen für MariaDB-Datenbanken

Die MariaDB-Datenbank muss sich unter LVM befinden und darf nicht das Bootvolume sein. Führen Sie mysql -e "select @@datadir" aus, um den Pfad zu den Datenbankdaten abzurufen.
Das LVM-Volume, von dem die MariaDB-Volumes bereitgestellt werden, sollte mindestens 20% freien Speicherplatz haben.
Installieren Sie den Sicherungs- und Notfallwiederherstellungs-Agenten auf dem MariaDB-Server.
Erstellen Sie einen Ersatznutzer mit den Berechtigungen Reload, Select, Lock tables und Super oder Replication client. Ein Ersatznutzername und ein Ersatzpasswort müssen mit der Hostkonfiguration konfiguriert werden.

So erstellen Sie den Nutzer für die Sicherung:
```
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;
```
Hinweis: Wenn auf einem Server mehrere MariaDB-Instanzen ausgeführt werden, müssen der Nutzername und das Passwort für die Sicherung für alle MariaDB-Instanzen auf diesem Server identisch sein.
Das binäre Logging von MariaDB log_bin muss aktiviert sein, um Protokollsicherungen zu erstellen. Wenn Sie die Option für das Binärprotokoll konfigurieren möchten, beenden Sie den MariaDB-Server und bearbeiten Sie die Konfigurationsdatei my.cnf oder my.ini. Fügen Sie in der Konfigurationsdatei im Abschnitt [mysqld] die Option „log-bin“ hinzu.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```
Der MySQL-Nutzer muss in der Datei „/etc/passwd“ auf „/bin/bash“ festgelegt sein.

Voraussetzungen für MySQL-Datenbanken

Die MySQL-Datenbank muss sich unter LVM befinden und darf nicht das Bootvolume sein. Führen Sie mysql -e "select @@datadir" aus, um den Pfad zu den Datenbankdaten abzurufen.
Die besten Ergebnisse erzielen Sie, wenn das LVM-Volume, von dem die MySQL-Volumes bereitgestellt werden, mindestens 20% freien Speicherplatz hat.
Sicherungs- und Notfallwiederherstellungs-Agent auf dem MySQL-Serverhost installieren
Prüfen, ob die MySQL-Instanz ausgeführt wird
Der Eigentümer der MySQL-Datenbank (OS-Nutzer) muss zur Anmeldung berechtigt sein. Der OS-Nutzer der Datenbank sollte beispielsweise eine funktionierende Shell wie /bin/bash haben.

Befehl zum Aktivieren des Betriebssystemnutzers: usermod -s /bin/bash mysql
Die MySQL-Instanz sollte einen Datenbank-Sicherungsnutzer haben, der eine Verbindung von localhost herstellen kann. Beispiel: create user actuser'@'localhost identified by 'mypassword';

Hinweis: Wenn auf einem Server mehrere MySQL-Instanzen ausgeführt werden, müssen der Nutzername und das Passwort für die Datenbanksicherung für alle MySQL-Instanzen auf diesem Server identisch sein.

Berechtigung, die für den Nutzer der Datenbanksicherung für die Sicherung und Wiederherstellung von Snapshots auf Volumeebene erforderlich ist:

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;

Für den Nutzer der Datenbanksicherung sind die folgenden Berechtigungen erforderlich, wenn eine vollständige und inkrementelle Sicherung und Wiederherstellung (dateibasierte traditionelle Sicherung) durchgeführt wird:
```
GRANT ALL ON *.* TO 'actuser'@'localhost';
SHOW GRANTS FOR CURRENT_USER;
```
Es muss eine benutzerdefinierte Datenbank vorhanden sein, die nicht zu den Systemdatenbanken information_schema, mysql, performance_schema oder sys gehört.
Das binäre Logging von MySQL (log_bin) muss aktiviert sein, um eine Protokollsicherung durchzuführen. Wenn Sie die Option für das binäre Protokoll konfigurieren möchten, beenden Sie den MySQL-Server und bearbeiten Sie die Konfigurationsdatei my.cnf oder my.ini. Fügen Sie in der Konfigurationsdatei im Abschnitt [mysqld] die Option „log-bin“ hinzu.
```
[mysqld]
log_bin = /log1/mysql3306/mysql3306-bin.0000
```

Voraussetzungen für PostgreSQL-Datenbanken

In diesem Abschnitt finden Sie Informationen zu den Voraussetzungen für PostgreSQL-Datenbanken.

PostgreSQL vor dem primären Knoten schützen

Erstellen Sie einen Sicherungsnutzer:

create user actuser;

Berechtigung für Sicherung gewähren:

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

Der PostgreSQL-Archivierungsmodus „archive_mode“ muss auf „ON“ (An) gesetzt sein, damit Protokollsicherungen erstellt werden können. Um die Option „Archivierungsprotokollmodus“ zu konfigurieren, aktualisieren Sie die Datei „postgresql.conf“ im Datenverzeichnis der Instanz und laden Sie PostgreSQL neu.
```
archive_mode = on
 // Command to reload PostgreSQL
 pg_ctl reload -D <Postgres_datadir_path>
``
```

Beispiel: pg_ctl reload -D /pgdata

PostgreSQL vor einem Standby-Knoten schützen

Erstellen Sie einen Nutzer für die Sicherung:

create user actuser;

Berechtigung für Sicherung gewähren:

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

PostgreSQL-Archivmodus – WAL – Einrichtung auf dem Standby-Knoten:

Erstellen Sie das Verzeichnis, in dem die WALs gespeichert werden sollen.
Im Beispiel ist /pglog das Verzeichnis. Führen Sie die folgenden Schritte als Root-Nutzer aus.
```
mkdir /pglog
chown -R postgres:postgres /pglog
```
Konfigurieren Sie die Parameter für die Archivierung.
In diesem Beispiel ist $PGDATA = /pgdata/11/data. Führen Sie die folgenden Schritte als postgres-Nutzer aus.
Parameter in der Datei /pgdata/11/data/postgresql.conf hinzufügen oder aktualisieren
```
 wal_level = replica
 archive_mode = always
 archive_command = 'test ! -f /pglog/%f && cp %p /pglog/%f'
```
Starten Sie PostgreSQL neu:
```
 /usr/pgsql-11/bin/pg_ctl stop -D /pgdata/11/data
 /usr/pgsql-11/bin/pg_ctl start -D /pgdata/11/data
```
Fügen Sie in der primären Datenbank einen Eintrag in pg_hba.conf hinzu oder aktualisieren Sie ihn, um die Datenbankverbindung vom Standby-Server zu akzeptieren.
```
host postgres <db-user> <standby-ip/32> <connection method>
```
Beispiel: host postgres postgres 10.128.0.29/32 trust

Archivgenerierung testen (als Postgres-Nutzer):
```
ls -l /pglog/
```
Führen Sie diesen Befehl zum Umschalten des Protokolls aus:
```
 /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/
```

Voraussetzungen für SAP ASE-Datenbanken

Führen Sie vor Beginn die folgenden Schritte auf dem SAP ASE-Server aus:

Es muss ein Nutzerkonto für die Sicherung mit der Berechtigung „Sicherung“ erstellt werden – entweder oper_role oder sa_role. Ein Ersatznutzername und ein Ersatzpasswort müssen mit der Hostkonfiguration konfiguriert werden. Erstellen Sie den Nutzer mit oder ohne Passwort, um den Befehl „quiesce“ mit der Rolle „sa_role“ oder mit Berechtigungen für „quiesce“ auf der Quelle auszuführen. Führen Sie folgenden Befehl aus, um den Nutzer mit einem Passwort zu erstellen:
```
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
```
Wenn Sie die Nutzeranmeldung ohne Passwortvoraussetzung konfigurieren möchten, setzen Sie das Passwort auf „null“ und führen Sie dann den folgenden Befehl aus:
```
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
```
Hinweis: Wenn auf einem Server mehrere SAP ASE-Instanzen ausgeführt werden, müssen der Nutzername und das Passwort für die Sicherung für alle SAP ASE-Instanzen auf diesem Server identisch sein.
Installieren Sie den Sicherungs- und Notfallwiederherstellungs-Agenten auf dem SAP ASE-Server.
Um die Sicherung des Transaktionslogs zu aktivieren, muss Truncate on chkpt false für jede Datenbank der SAP ASE-Instanz auf Datenbankebene festgelegt werden.
Für Sicherungen auf Volumeebene gilt Folgendes:
- Die SAP ASE-Instanz muss sich unter LVM befinden und darf nicht das Boot-Volume sein.
- Das LVM-Volume, von dem die SAP ASE-Volumes bereitgestellt werden, sollte mindestens 20% freien Speicherplatz haben.

Voraussetzungen für SAP IQ-Datenbanken

Prüfen Sie zuerst Folgendes auf dem SAP IQ-Server:

Die SAP IQ-PITR-Protokollierung muss aktiviert sein, damit eine Protokollsicherung erstellt werden kann. Zum Konfigurieren der PITR-Log-Option benötigen Sie die folgenden SAP IQ APIs:
- ALTER DBSPACE IQ_SYSTEM_LOG RENAME /<pitr_log_location>
- SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = ON`
Nachdem Sie die PITR-Protokollierung aktiviert haben, ist eine vollständige Datenbanksicherung erforderlich.
Zuerst müssen Sie den Nutzernamen und das Passwort für die Dienstdatenbank angeben. Der Datenbankname sollte utility_db sein. Beispiel: start_iq -n utility_db -su act,passwd
Der Nutzername und das Passwort für die Datenbanksicherung müssen mit dem Nutzernamen und Passwort für utility_db übereinstimmen und DBA-Berechtigungen haben. So erstellen Sie den Sicherungsnutzer:
```
create user actuser identified by 'mypassword';
grant dba to actuser;
```
Hinweis: Wenn auf einem Server mehrere SAP IQ-Instanzen ausgeführt werden, müssen der Sicherungsnutzername und das Sicherungspasswort für alle SAP IQ-Instanzen auf diesem Server identisch sein.
- Installieren Sie den Sicherungs- und Notfallwiederherstellungs-Agent auf dem SAP IQ-Serverhost.

Voraussetzungen für SAP MaxDB-Datenbanken

Führen Sie vor Beginn die folgenden Schritte auf dem SAP MaxDB-Server aus:

Wenn auf einem Server mehrere MaxDB-Instanzen ausgeführt werden, müssen der DB-Nutzername und das DB-Passwort für alle MaxDB-Instanzen auf diesem Server identisch sein.
Die automatische Sicherung muss aktiviert sein. Verwenden Sie den folgenden Befehl, um die automatische Protokollsicherung zu aktivieren:
```
dbmcli -d <DBSID> -u <DBM_USERNAME>,<DBM_PASSWD> autolog_on
<autolog_backup_template_name>
```
Zum Aktivieren der automatischen Protokollsicherung benötigen Sie eine entsprechende Vorlage.

Verwenden Sie den folgenden Befehl, um eine Sicherungsvorlage zu erstellen.

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

Der Bereich „Log Overwrite“ (Log-Überschreibung) muss deaktiviert sein, damit die automatische Sicherung von Protokollen aktiviert werden kann.

Verwenden Sie den folgenden Befehl, um das Überschreiben von Protokollen zu deaktivieren:

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

Installieren Sie den Sicherungs- und Notfallwiederherstellungs-Agenten auf dem SAP MaxDB-Serverhost.

Nächste Schritte

Nachdem die Datenbank für die Sicherung und Notfallwiederherstellung vorbereitet wurde, können Sie den Host hinzufügen und die Datenbanken ermitteln.