Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Mit dem Wiederherstellungsvorgang des Sicherungs- und Notfallwiederherstellungsdienstes wird ein Sicherungs-Image an der Quelle wiederhergestellt und alle dort vorhandenen Daten werden überschrieben.
Systemeinschränkungen und Problemumgehungen
Systemdatenbanken auf einer Root-Partition, die als LVM-Snapshots (Logical Volume Manager) gesichert wurden, können nicht bei einem Wiederherstellungsvorgang verwendet werden, da die Root-Partition nicht getrennt werden kann. Diese müssen manuell von einem Standard-Mount wieder auf demselben Host wiederhergestellt werden.
Informationen zum Wiederherstellen eines Datenbank-Images auf Volumeebene mit kürzerer Ausfallzeit für Nutzer finden Sie unter Andere Arten von Datenbanken für die sofortige Wiederherstellung bereitstellen und migrieren.
Die Wiederherstellung an der Quelle wird nicht unterstützt, wenn mehrere Instanzen dasselbe Volume oder Dateisystem verwenden. Um solche Anwendungen wiederherzustellen, müssen Sie das Image auf dem Host bereitstellen und die Wiederherstellung einer einzelnen Datenbank mithilfe der Schritte ausführen, die unter Einzelne Datenbank aus einem volumebasierten Sicherungs-Image an der Quelle wiederherstellen beschrieben sind.
Wenn es verschachtelte Bereitstellungspunkte unter den gesicherten Produktionsvolumes gibt, schlägt die Wiederherstellung und Migration zurück zur Quelle fehl, da die Produktionsvolumes belegt sind und nicht bereitgestellt werden können.
Datenbanken aus einem Sicherungs-Image auf Volumeebene an der Quelle wiederherstellen
Bei diesem Verfahren wird die physische Wiederherstellung des Quelldatenbereichs verwendet. So stellen Sie die ursprüngliche Version wieder her:
Klicken Sie in der Liste App-Manager-Anwendungen mit der rechten Maustaste auf die geschützte Datenbank und wählen Sie Zugriff aus. Verwenden Sie den Statusfilter Verwalteter Sicherungsplan, um nur geschützte Datenbanken anzuzeigen.
Wählen Sie ein Snapshot-Bild aus und klicken Sie auf Wiederherstellen.
Wählen Sie Traditional (Traditionell) aus, nicht „Mount and migrate“ (Binden und migrieren).
Wenn die Quellanwendung durch eine Snapshot-Richtlinie geschützt ist, für die Datenbankprotokollsicherungen aktiviert sind, und Protokolle mit dem Image verfügbar sind, können Sie sie verwenden, um die Zeit auf einen bestimmten Zeitpunkt vorzuspulen. Ändern Sie dazu die folgenden Optionen im Bereich Zeit vorspulen:
Das Datumsfeld enthält alle möglichen Datumsangaben, zu denen die Datenbank durch Anwenden von Datenbanktransaktionsprotokollen fortgesetzt werden kann. Wählen Sie das Datum aus, auf das die Datenbank fortgesetzt werden soll.
Das Zeitfeld enthält einen Schieberegler mit allen möglichen Uhrzeiten am ausgewählten Datum, zu denen die Datenbank vor- oder zurückgerollt werden kann. Wenn Sie das späteste mögliche Datum auswählen und den Schieberegler dann ganz nach rechts bewegen, wird der Wiederherstellungsjob auf alle verfügbaren Protokolle angewendet. Wenn Sie das früheste mögliche Datum auswählen und den Schieberegler ganz nach links bewegen, werden beim Wiederherstellungsjob keine Protokolle angewendet.
Sie können festlegen, dass die Zeit entweder mithilfe der Nutzerzeit oder der Hostzeit vorwärtsgerollt wird.
Nutzerzeit bezieht sich auf die Ortszeit des aktuellen Nutzers.
Die Hostzeit bezieht sich auf das System, auf dem die wiederherzustellenden Daten gehostet werden.
Aktivieren Sie Mit Wiederherstellung wiederherstellen, um wiederhergestellte Protokolle anzuwenden.
Klicken Sie auf Senden.
```sh ALTER DBSPACE IQ_SYSTEM_LOG RENAME /pitr_log_location SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = 'ON'```
Einzelne Datenbank aus einem volumenbasierten Sicherungs-Image an der Quelle wiederherstellen
So stellen Sie ein einzelnes Db2- oder SAP ASE-Sicherungs-Image an der Quelle wieder her:
Klicken Sie in der Liste App Manager Applications (App-Manager-Anwendungen) mit der rechten Maustaste auf die geschützte Datenbank und wählen Sie Access (Zugriff) aus.
Wählen Sie den neuesten Snapshot aus, den Sie wiederherstellen möchten, und klicken Sie auf Bestätigen.
Deaktivieren Sie unter Anwendungsoptionen die Option Neue virtuelle Anwendung erstellen.
Geben Sie unter Zuordnungsoptionen den Speicherort des Bereitstellungspunkts an.
Mit /mymount wird die Datenbanksicherung beispielsweise an diesem Speicherort bereitgestellt.
Die Protokollsicherung wird unter /mymount_archivelog bereitgestellt.
Klicken Sie auf Senden.
Auf der Seite Monitor>Jobs sehen Sie, wann der Bereitstellungsjob abgeschlossen ist.
Melden Sie sich nach Abschluss des Jobs als Root-Nutzer am Datenbankserver an. Ändern Sie auf dem Server das Verzeichnis in /act/custom_apps/<var>database type</var>/restore.
Rufen Sie die JobID des Bereitstellungspunkts von /var/act/log/UDSAgent.log ab.
Führen Sie den folgenden Befehl aus, um den JobID zu ermitteln:
grep"mount -t "/var/act/log/UDSAgent.log|grep-w"<var>mountpoint from step 4</var>"|tail-1
Stellen Sie eine Verbindung zur SAP ASE-Datenbank her und prüfen Sie die Daten.
Rufen Sie das Image noch einmal in der Verwaltungskonsole auf und trennen Sie den Bereitstellungspunkt der Datenbank und löschen Sie ihn.
Dateibasiertes Sicherungs-Image vom Typ „Vollständig + Inkrementell“ in der Quelle wiederherstellen
Dabei werden die Quelldaten überschrieben.
So stellen Sie die Quelldatenbank aus einem dateibasierten Sicherungs-Image wieder her:
Klicken Sie in der Liste App Manager Applications (App-Manager-Anwendungen) mit der rechten Maustaste auf die geschützte Datenbank und wählen Sie Access (Zugriff) aus.
Wählen Sie ein Snapshot-Bild aus und klicken Sie auf Wiederherstellen.
Wählen Sie Traditional (Traditionell) aus, nicht „Mount and migrate“ (Binden und migrieren).
Wählen Sie mit Elemente auswählen eine oder mehrere Datenbanken aus, die wiederhergestellt werden sollen.
Aktivieren Sie Mit Wiederherstellung wiederherstellen, um alle wiederhergestellten Protokolle anzuwenden.
Klicken Sie auf Senden. Dadurch wird die physische Wiederherstellung der Quelldatenbank mithilfe der Wiederherstellungs-API der Datenbank gestartet.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThe Restore operation in the Backup and DR Service overwrites existing data on the source with the data from a selected backup image.\u003c/p\u003e\n"],["\u003cp\u003eRestoring system databases on a root partition backed up as LVM snapshots directly is not supported, requiring manual restore and recovery.\u003c/p\u003e\n"],["\u003cp\u003eRestoring to the source is not supported if multiple instances use the same volume or file systems, requiring mounting the image to perform a single database recovery.\u003c/p\u003e\n"],["\u003cp\u003eTo restore a database to its source from a volume-level backup, users can select the "Traditional" restore option, choosing whether or not to roll forward to a specific point in time using available transaction logs, or choose a mount and migrate method for a single database.\u003c/p\u003e\n"],["\u003cp\u003eWhen performing a file-based restore, users must select the "Traditional" method and choose which databases they would like to restore, and can enable the "Restore With Recovery" option to apply all recovered logs.\u003c/p\u003e\n"]]],[],null,["# Restore other database types back to the source\n\nThe Backup and DR Service **Restore** operation restores a backup image to the source,\noverwriting whatever data exists there.\n\nSystem limitations and workarounds\n----------------------------------\n\n- System databases on a root partition backed up as logical volume manager (LVM)\n snapshots cannot be used in a restore operation because the\n root partition cannot be unmounted. These require manual restore and recovery\n from a standard mount back to the same host. \n\n To recover a volume-level database image with less downtime for users, see\n [Mount and migrate other types of databases for instant recovery](/backup-disaster-recovery/docs/restore-data/otherdb-mount-and-migrate).\n\n- Restoring back to the source is not supported if multiple instances share\n the same volume or file systems. To restore such applications, mount the image\n to the host and use the procedure to perform single database recovery\n detailed in\n [Restore a single database from a volume-based backup image to the source](#volume-based).\n\n- If there are nested mount points under the production volumes being backed\n up, then restore and migrate operations back to the source fails because the\n production volumes are busy and cannot be unmounted.\n\n- To restore /backup-disaster-recovery/docs/restore-data/otherdb-restore\n\nRestore databases from a volume-level backup image to the source\n----------------------------------------------------------------\n\nThis procedure uses physical recovery of the source data area. To recover\nback to the source, follow these instructions:\n\n1. From the **App Manager Applications** list, right-click the\n protected database and select **Access** . Use the\n **Managed Backup Plan** status filter to show only protected databases.\n\n2. Select a snapshot image and click **Restore**.\n\n3. Select **Traditional**---not mount and migrate.\n\n4. If the source application is protected by a snapshot policy that has\n enabled database log backups, and logs are available with the image,\n you can use them to roll forward to a specific point in time by changing\n these options in the **Roll Forward Time** section:\n\n - The date field contains all possible dates that the database can be rolled forward to---through the application of database transaction logs. Select which date you need the database to be rolled forward to.\n - The time field contains a slider showing all possible times on the selected date that the database can be rolled forward to. If you select the latest possible date and then move the slider to the right most position, the restore job applies to all available logs. If you select the earliest possible date and move the slider to the left most position, the restore job applies no logs.\n - You can specify to roll forward using either **User Time** or **Host Time** . **User Time** is relative to the local time of the current user. **Host time** is relative to the system that hosts the data to be restored.\n5. Enable **Restore With Recovery** to apply recovered logs.\n\n6. Click **Submit**.\n\n**Note:** SAP IQ only. After the database has been restored, SAP IQ PITR (point-in-time recovery) logging must be set to ON to take a log backup. To configure the PITR log option, you need these SAP IQ API: \n\n ```sh\n ALTER DBSPACE IQ_SYSTEM_LOG RENAME /\u003cvar label=\"point-in-time recovery log location\" translate=\"no\"\u003epitr_log_location\u003c/var\u003e\n SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = 'ON'\n ```\n\nRestore a single database from a volume-based backup image to the source\n------------------------------------------------------------------------\n\nTo restore a single Db2 or SAP ASE backup image to its source, follow these\nsteps:\n\n1. From the **App Manager Applications** list, right-click the protected\n database and select **Access**.\n\n | **Note:** You can use the **Managed Backup Plan** status filter to show only protected databases.\n2. Select the latest snapshot to recover and click **Mount**.\n\n3. In the **Application Options** , disable **Create New Virtual Application**.\n\n4. In **Mapping Options**, provide the mount-point location.\n\n For example, using `/mymount` mounts the database backup under this location.\n The log backup is mounted under `/mymount_archivelog`.\n5. Click **Submit**.\n\n6. Check the **Monitor** \\\u003e **Jobs** page to see when the mount job\n is finished.\n\n7. When the job is finished, log into the database server as root. On the\n server, change directory to `/act/custom_apps/\u003cvar\u003edatabase type\u003c/var\u003e/restore`.\n\n8. Get the `JobID` of the mount from `/var/act/log/UDSAgent.log`.\n To find the `JobID`, run the following command:\n\n grep \"mount -t \" /var/act/log/UDSAgent.log | grep -w \"\u003cvar\u003emountpoint from step 4\u003c/var\u003e\"|tail -1\n\n For example: \n\n grep \"mount -t \" /var/act/log/UDSAgent.log | grep -w \"/db2mnt\" |tail -1\n 2019-11-18 23:59:19.740 GEN-INFO \\[22488\\] **Job_0404207** Spawning cmd: mount -t ext4 /dev/act403764_DBDump_1574101677612/act_staging_vol /db2mnt 2\u003e&1\n\n9. `ARCHIVELOG_MNT` is `\u003cvar\u003emountpoint provided in step 4\u003c/var\u003e_archivelog`.\n\n10. From the target host command line as root, run the script:\n\n### IBM Db2\n\nScript: `act_db2_lvm_customdb_recovery.sh`\n\nArguments to the script: \n\n SOURCE_INSTANCE = \u003cvar\u003eDb2 Instance name\u003c/var\u003e\n DB_NAME=\u003cvar\u003eDb2 Database name to be recovered(Single)\u003c/var\u003e\n TARGET_MNT = \u003cvar\u003eDb2 Database image mountpoint name\u003c/var\u003e\n ARCHIVELOG_MNT= \u003cvar\u003eArchive Log backup mount point name\u003c/var\u003e\n UNTIL_TIME = \u003cvar\u003eRecovery Time(Format: \"YYYY-MM-DD-HH.MI.SS\")\u003c/var\u003e\n JOBID = \u003cvar\u003eDatabase mount Job name\u003c/var\u003e\n\nConnect to the Db2 instance and confirm that the databases are recovered\nand online. \n\n db2 connect to \u003cvar\u003edbname\u003c/var\u003e\n db2 select db_status FROM SYSIBMADM.SNAPDB\n\n### SAP ASE\n\nRun the script act_sybase_lvm_customdb_recovery.sh with these arguments. \n\n ./act_sybase_lvm_customdb_recovery.sh OSUSER=sybase\n TARGET_SYBASE_SQLD=/home/sybase/Sybase16Home/OCS-16_0 TARGET_MNT_PNT=/sngRst\n TARGET_SERVER_NAME=ASE1 TARGET_DB_USER=sa STRIPEON=4 TARGET_DBUSER_PASSWD=sybase\n SRC_DBNAME=CU1 LOG_BKP_MNTPT=/sngRst_archivelog UNTIL_TIME=\"2019-11-07 20:31:27\"\n BEGIN_TIME=\"2019-11-07 19:31:27\" JOBID=\"Job_2677627\"\n\nArguments to the script \n\n OSUSER = SAP Ase OS owner name\n TARGET_SYBASE_SQLD = SAP ASE iSQL path on the target recovery host\n TARGET_MNT_PNT = SAP ASE Instance image mountpoint name\n TARGET_SERVER_NAME = SAP ASE data server name on the target recovery host\n TARGET_DB_USER = SAP ASE Instance username on the target recovery host\n TARGET_DBUSER_PASSWD = SAP ASE Instance user password on the target recovery host\n SRC_DBNAME = SAP ASE Database name to be recovered (Single)\n LOG_BKP_MNTPT = SAP ASE Log image mountpoint name\n BEGIN_TIME= Backup begin time (Format: \"YYYY-MM-DD HH24:MI:SS\")\n UNTIL_TIME = Point in time to recover the database (Format: \"YYYY-MM-DD HH24:MI:SS\")\n JOBID = Database mount Job name\n\nConnect to the SAP ASE database and verify the data.\n\n1. In the management console, access the image again and **Unmount+Delete** the database mount point.\n\nRestore a file-based Full+Incremental backup image to the source\n----------------------------------------------------------------\n\n| **Note:** SAP ASE databases protected with Full+Incremental based backup must have the same character set or sort order for both the source and target databases for a successful restore. For details refer to [SAP Note: 1860413 - How to change character set or sort order of SAP ASE](https://userapps.support.sap.com/sap/support/knowledge/en/1860413).\n\nThis procedure overwrites the source data.\nTo restore the source database from a file-based backup image, follow\nthis procedure:\n\n1. From the **App Manager Applications** list, right-click the protected\n database and select **Access**.\n\n | **Note:** You can use the **Managed Backup Plan** status filter to show only protected databases.\n2. Select a snapshot image and click **Restore**.\n\n3. Select **Traditional**---not mount and migrate.\n\n4. Use **Select Items** to choose one or more databases to restore.\n\n5. Enable **Restore With Recovery** to apply all recovered logs.\n\n6. Click **Submit**. This starts the source database physical\n recovery using the database's recovery API.\n\n**Note:** SAP IQ only. After the database has been restored, SAP IQ PITR logging must be set to ON to take a log backup. To configure the PITR log option, you need these SAP IQ API: \n\n ALTER DBSPACE IQ_SYSTEM_LOG RENAME '/\u003cvar\u003epitr_log_location\u003c/var\u003e'\n SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = 'ON'"]]
