백업 및 DR 서비스 복원 작업은 백업 이미지를 소스에 복원하여 소스에 있는 모든 데이터를 덮어씁니다.
시스템 제한사항 및 해결 방법
루트 파티션을 마운트 해제할 수 없으므로 논리 볼륨 관리자 (LVM) 스냅샷으로 백업된 루트 파티션의 시스템 데이터베이스는 복원 작업에 사용할 수 없습니다. 이 경우 표준 마운트에서 동일한 호스트로 수동으로 복원해야 합니다.
사용자의 다운타임을 줄이면서 볼륨 수준 데이터베이스 이미지를 복구하려면 즉시 복구를 위해 다른 유형의 데이터베이스 마운트 및 마이그레이션을 참고하세요.
여러 인스턴스가 동일한 볼륨 또는 파일 시스템을 공유하는 경우 소스로 다시 복원하는 기능은 지원되지 않습니다. 이러한 애플리케이션을 복원하려면 이미지를 호스트에 마운트하고 볼륨 기반 백업 이미지에서 소스로 단일 데이터베이스 복원에 설명된 절차에 따라 단일 데이터베이스 복구를 실행합니다.
백업되는 프로덕션 볼륨 아래에 중첩된 마운트 지점이 있는 경우 프로덕션 볼륨이 사용 중이어서 마운트 해제할 수 없으므로 소스로 복원 및 이전 작업이 실패합니다.
이 절차에서는 소스 데이터 영역의 물리적 복구를 사용합니다. 소스로 복구하려면 다음 안내를 따르세요.
앱 관리자 애플리케이션 목록에서 보호된 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 액세스를 선택합니다. 관리형 백업 계획 상태 필터를 사용하여 보호된 데이터베이스만 표시합니다.
스냅샷 이미지를 선택하고 복원을 클릭합니다.
마운트 및 이전이 아닌 기존을 선택합니다.
소스 애플리케이션이 데이터베이스 로그 백업을 사용 설정한 스냅샷 정책으로 보호되고 이미지에서 로그를 사용할 수 있는 경우 롤 포워드 시간 섹션에서 다음 옵션을 변경하여 로그를 사용하여 특정 시점으로 롤 포워드할 수 있습니다.
날짜 필드에는 데이터베이스 트랜잭션 로그를 적용하여 데이터베이스를 앞으로 롤아웃할 수 있는 모든 날짜가 포함됩니다. 데이터베이스를 롤포워드해야 하는 날짜를 선택합니다.
시간 필드에는 선택한 날짜에 데이터베이스를 롤포워드할 수 있는 모든 시간을 보여주는 슬라이더가 포함되어 있습니다. 가능한 가장 최근 날짜를 선택한 다음 슬라이더를 가장 오른쪽 위치로 이동하면 복원 작업이 사용 가능한 모든 로그에 적용됩니다. 가능한 한 가장 빠른 날짜를 선택하고 슬라이더를 맨 왼쪽 위치로 이동하면 복원 작업에 로그가 적용되지 않습니다.
사용자 시간 또는 호스트 시간을 사용하여 롤 포워드를 지정할 수 있습니다.
사용자 시간은 현재 사용자의 현지 시간을 기준으로 합니다.
호스트 시간은 복원할 데이터를 호스팅하는 시스템에 상대적입니다.
복구된 로그를 적용하려면 복구를 사용하여 복원을 사용 설정합니다.
제출을 클릭합니다.
```sh ALTER DBSPACE IQ_SYSTEM_LOG RENAME /pitr_log_location SET OPTION PUBLIC.IQ_POINT_IN_TIME_RECOVERY_LOGGING = 'ON'```
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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'"]]
