Option A: Restore In Place

Oracle

Audience

Public

Technology Integrations

Oracle

Source Type

Documentation

Use this procedure only with a formally approved outage, application-owner approval, a documented recovery plan, and a tested backout plan. This operation overwrites the original active database volumes.

Confirm the Restore Scope

Confirm all of the following before stopping the database:
- The selected snapshot is the intended Protection Group snapshot.
- Every database volume in the Protection Group will be restored together.
- The snapshot does not include clusterware OCR/voting volumes.
- Archived redo and recovery artifacts required by the selected recovery path are available.
- Application owners have stopped writes and approved the outage.
- A fallback decision and escalation path are documented.

Stop Database Resources

Run on one RAC node as the Oracle Database software owner.

srvctl status database -d <DB_UNIQUE_NAME>
srvctl stop database -d <DB_UNIQUE_NAME> -o immediate

Confirm all database instances and services are stopped before proceeding.

srvctl status service -d <DB_UNIQUE_NAME>
srvctl status database -d <DB_UNIQUE_NAME>

Dismount the Database ASM Disk Groups

Run as the Grid Infrastructure owner. Stop only database disk group resources that back the restored database, such as DATA, FRA, and REDO.
```
srvctl stop diskgroup -diskgroup DATA
srvctl stop diskgroup -diskgroup FRA
srvctl stop diskgroup -diskgroup REDO

srvctl status diskgroup -diskgroup DATA
srvctl status diskgroup -diskgroup FRA
srvctl status diskgroup -diskgroup REDO
```
Confirm the database disk groups are dismounted from every ASM instance before overwriting storage. Do not stop or dismount the Grid Infrastructure OCR/voting disk group.
Note: In Oracle 19c, and newer, Oracle officially updated the flags to be fully spelled out (e.g., -diskgroup instead of -g, and -node instead of -n). While the older short flags still work for backward compatibility.
Overwrite the Active Volumes from the Snapshot

Identify the volume snapshots that belong to the selected Protection Group snapshot. Copy each snapshot back to its matching active database volume. The following names are examples only; replace them with the exact source snapshot and destination volume names validated in the precheck.

Use the Everpure CLI, REST API, or SDK to identify the Protection Group snapshot. The examples use the Purity CLI.
```
# List all Protection Groups
purepgroup list 

# Optionally add –filter with a wildcard match on name for Protection Groups
purepgroup list --filter "name='*ORCL*'"

# List all snapshots for the selected Protection Group 
purepgroup listobj --type snap pg-prod-ORCL-rac

# List volumes in selected snapshot
purevol list --snap "pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z.*"
```
Record the selected snapshot name exactly. A Protection Group snapshot is commonly represented as a collection of volume snapshots using the same Protection Group snapshot suffix.
```
# Example: overwrite all database volumes from one coordinated PG snapshot
purevol copy --overwrite pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z.ora-data-01  ora-data-01
purevol copy --overwrite pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z.ora-fra-01   ora-fra-01
purevol copy --overwrite pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z.ora-redo-01  ora-redo-01
```
CAUTION:

The exact snapshot object naming varies by environment and Purity version. Verify every source-to-destination pair before executing an overwrite. Never overwrite a volume based only on a similar name.

Because the existing volumes retain their host mappings, SCSI LUN identity, or NVMe namespace presentation, a discovery rescan is usually not required after an in-place overwrite. However, always validate device health and multipath state before mounting ASM.
Validate Storage Presentation

On each RAC node, verify all expected paths remain healthy.
```
# SCSI/iSCSI/FC examples
multipath -ll

# NVMe-oF examples
nvme list
nvme list-subsys
```
Resolve any missing or failed path before continuing. Do not mount ASM with an incomplete or degraded storage presentation unless the disk group redundancy design and approved procedure explicitly support it.
Mount ASM Disk Groups

Run as the Grid Infrastructure owner.
```
srvctl start diskgroup -diskgroup DATA
srvctl start diskgroup -diskgroup FRA
srvctl start diskgroup -diskgroup REDO

asmcmd lsdg
```
Confirm every restored database disk group is mounted and that no unrelated disk group was affected.

Start, Recover, and Open the Database

Start one database instance in mount mode. Use the database unique name, not the DB_NAME, with srvctl.

srvctl start database -d <DB_UNIQUE_NAME> -o mount
sqlplus / as sysdba

Determine and execute the approved Oracle recovery path. Example commands below are illustrative; use only the command sequence appropriate to the snapshot type and recovery objective.

-- Run only if Oracle recovery is required by the selected recovery plan.
RECOVER DATABASE;

-- Open normally after complete recovery when Oracle permits it.
ALTER DATABASE OPEN;

If recovery requires a resetlogs open, perform it only after confirming that this is the required Oracle recovery path.
ALTER DATABASE OPEN RESETLOGS;

After the first instance opens successfully, start or confirm the remaining RAC instances.
srvctl start database -d <DB_UNIQUE_NAME>
srvctl status database -d <DB_UNIQUE_NAME>

Validate the Restored Database
```
SELECT name, open_mode, database_role FROM v$database;
SELECT inst_id, instance_name, host_name, status FROM gv$instance ORDER BY inst_id;
```
Validate all of the following:
- Every intended RAC instance is OPEN and stable.
- ASM disk groups are mounted and healthy.
- Database and ASM alert logs show expected recovery activity and no unresolved errors.
- Database services start on the expected preferred and available instances.
- Application read/write validation succeeds.
- Backup, monitoring, replication, and job-scheduling systems are checked before normal production traffic resumes.