Restoring Storage Snapshots of a 19c/26ai Oracle Multitenant Database on a Filesystem Using Everpure FlashArray

Purpose

This knowledge base (KB) describes the Oracle‑supportable procedure for restoring or cloning Oracle multitenant (CDB/PDB) databases deployed on filesystems (XFS/ext4) from Everpure FlashArray snapshots. The goal is to provide predictable recovery behavior, audit‑ready steps, and consistent DBA operations for CDB/PDB environments.

Scope and Assumptions

In Scope

• Oracle 19c/26ai CDBs with one or more PDBs (filesystem‑based)

• Linux hosts (RHEL, OEL, etc.)

• Everpure FlashArray block volumes mounted as filesystems

• Snapshots created via Everpure FlashArray protection groups (GUI/CLI/API)

Out of Scope

• Non-CDB databases (covered in single‑instance filesystem KB)

• ASM-based databases (covered in a separate KB)

• Oracle RAC databases, including RAC CDB’s

Storage Layout & Prerequisites

Prerequisites

• Oracle: SYSDBA access on target host; compatible Oracle binaries installed; pfile/spfile available and validated.

• OS: Kernel and filesystem versions compatible with source.

• Storage: Access to Everpure FlashArray; snapshots include all CDB datafiles, redo, and FRA/archivelogs; ability to create writable clones.

• Best practice: All CDB‑related volumes are on the same FlashArray and were snapshotted together in a single protection group.

Restore Types

Out-of-Place Restore / Clone (Recommended)

• Primary use cases: DR testing, Dev / QA CDB clones, tenant testing.

• Characteristics: Creates writable clones; runs on separate host or mount points; no impact to production.

In-Place Restore (Same Host)

• Primary use case: Production CDB recovery after corruption.

• Characteristics: Replaces production volumes, requires downtime and change control.

High-Level Workflow

Procedure: Out of Place CDB Restore / Clone (Recommended)

Step 1: Identify Snapshot

Record the following for audit and recovery tracking:

• Snapshot name and timestamp

• Source CDB name and DB_UNIQUE_NAME

• Environment (prod/test)

• Optional: SCN from snapshot pre‑script

Step 2: Create Volume Clones

Using the Everpure FlashArray GUI or CLI, create writable volume clones from the selected snapshot. This assumes snapshots were taken using an Everpure Protection Group, which is the recommended method as it preserves write‑order consistency.

# List snapshots for the CDB protection group
purepgroup list –snap <protection_group>
purepgroup list --snap pg-orcl26-prod1


# List volumes in a specific snapshot
purevol list --snap --pgrouplist <pgroup name>.<snap_name>
purevol list --snap --pgrouplist pg-orcl26-prod1.prod-orcl26-CRASHCONS-2026-04-03-140000-chg1234

This confirms that all database-related volumes (data, redo, archive, etc.) are present in the snapshot from the protection group (orcl26-prod1-pg) and the snapshot (2026-03-24-030000).

Create writable volume clones from the snapshot

# Create writable clones
purevol copy <pgroup name>.<snap_name>.<snap_volume_name> <new_volume_name>


purevol copy pg-orcl26-prod1.prod-orcl26-CRASHCONS-2026-04-03-140000-chg1234.PROD1-ORCL26-DATA CLONE_ORCL26_DATA
purevol copy pg-orcl26-prod1.prod-orcl26-CRASHCONS-2026-04-03-140000-chg1234.PROD1-ORCL26-LOGS CLONE_ORCL26_LOGS

purevol list CLONE_ORCL26_*

Naming Best Practices

• Include environment, database name, and purpose (ex. CLONE_ORCL_DATA)

• Avoid reusing production volume names

Step 3: Present Volumes to Target Host

# Check if the host exists 
purehost list

If you see the target host listed, it already exists as a host object. If the target host is not listed, the host object hasn’t been created yet and you’ll need to create it before purehost connect will work.

purehost connect HOSTNAME –-vol CLONE_ORCL26_DATA
purehost connect HOSTNAME –-vol CLONE_ORCL26_LOGS

purehost list --connect HOSTNAME

for h in /sys/class/scsi_host/host*; do echo "- - -" > $h/scan; done
multipath -r
multipath -ll | grep -E "^mpath|size="
lsblk /dev/dm*

Step 4: Mount Filesystems

# Add entries to fstab
cat >> /etc/fstab << 'EOF'
/dev/mapper/mpathc /u02 xfs defaults,noatime,nodiratime 0 0
/dev/mapper/mpathd /u03 xfs defaults,noatime,nodiratime 0 0
EOF


# Mount the clone volumes
mkdir -p /u02 /u03
mount /dev/mapper/CLONE_ORCL26_DATA /u02
mount /dev/mapper/CLONE_ORCL26_LOGS /u03
systemctl daemon-reload

Step 5: Prepare Oracle Environment

export ORACLE_SID=orcl26dev
export ORACLE_HOME=/u01/app/oracle/product/23.26.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

Initialization File Considerations

• Ensure SPFILE/PFILE points to cloned filesystem paths and that controlfile entries match cloned locations.

• Update diagnostic destinations if restoring to a non-production host

Optional: Database Rename Decision Point

If you want to rename the database (e.g., change PROD → DEV), you must decide now before starting the database. Two options are available:

Option A: Rename CDB using NID (DBNEWID)

• Changes the entire Container Database name and DBID

• Use when creating a complete clone with different identity

• Proceed to Step 5A below

Option B: Clone/Rename PDB Only

• Keeps CDB name unchanged, clones PDB with new name

• Simpler, faster, Oracle recommended approach for multitenant

• Proceed to Step 5B below

Option C: Keep Original Names

• No rename needed for dev/test environments

• Skip to Step 6

Step 5A: Rename CDB with NID (Optional)

Use this option if you want to change the entire CDB name (e.g., PRODCDB to DEVCDB)

Prerequisites:

• Database must be in MOUNT mode (not OPEN)

• Full backup/snapshot exists (you already have this)

• All PDBs will remain closed during process

# Startup in MOUNT EXCLUSIVE mode
sqlplus / as sysdba
STARTUP MOUNT EXCLUSIVE;


# Run NID to change database name and DBID
# Replace NEWCDBNAME with your desired name
nid TARGET=/ DBNAME=NEWCDBNAME LOGFILE=/tmp/nid.log


# Create and modify parameter file
export ORACLE_SID=newcdbsid 
sqlplus / as sysdba
STARTUP NOMOUNT;
CREATE PFILE='/tmp/initnewcdbsid.ora' FROM SPFILE;
SHUTDOWN IMMEDIATE;
EXIT;
sed -i "s/db_name='.*'/db_name='NEWCDBNAME'/" /tmp/initnewcdbsid.ora
cp /tmp/initnewcdbsid.ora $ORACLE_HOME/dbs/initnewcdbsid.ora


# Create SPFILE and prepare for recovery
sqlplus / as sysdba
CREATE SPFILE FROM PFILE='$ORACLE_HOME/dbs/initnewcdbsid.ora';
EXIT;


# Update /etc/oratab
sed -i "s/^oldcdbsid:/newcdbsid:/" /etc/oratab

Step 5B: Clone/Rename PDB Only (Optional)

Use this option if you want to clone a PDB with a new name (e.g., PRODPDB → DEVPDB)

This is the Oracle-recommended approach for multitenant databases.

Prerequisites:

• CDB must be OPEN

• Source PDB will be temporarily closed

• Faster and safer than renaming entire CDB

# Open CDB (skip recovery for CDB)
sqlplus / as sysdba
STARTUP;


# Identify source PDB name
ALTER SESSION SET CONTAINER=CDB$ROOT;
SELECT name, open_mode FROM v$pdbs;


# Clone PDB with new name
# Replace sourcepdb and targetpdb with your actual names
ALTER SESSION SET CONTAINER=CDB$ROOT;


-- Close source PDB
ALTER PLUGGABLE DATABASE sourcepdb CLOSE IMMEDIATE;


-- Clone to new name
-- Adjust file paths based on your environment
CREATE PLUGGABLE DATABASE targetpdb FROM sourcepdb
  FILE_NAME_CONVERT = (
    '/u02/oradata/CDBNAME/sourcepdb/',
    '/u02/oradata/CDBNAME/targetpdb/'
  );


-- Open new PDB
ALTER PLUGGABLE DATABASE targetpdb OPEN;


-- Reopen source PDB if needed
ALTER PLUGGABLE DATABASE sourcepdb OPEN;


-- Save state
ALTER PLUGGABLE DATABASE targetpdb SAVE STATE;


-- Verify
SHOW PDBS;
EXIT;

After completing Step 5B, you can skip Steps 6-8 for the cloned PDB.

If you still need to recover the original PDB, proceed to Step 6.

Step 6: Start CDB in MOUNT Mode

sqlplus / as sysdba
STARTUP MOUNT;

Step 7: Recover CDB

RECOVER DATABASE;

RECOVER DATABASE SNAPSHOT TIME
  "TO_DATE('2026-03-24 03:00:05','YYYY-MM-DD HH24:MI:SS')";

Oracle may request additional archive logs depending on snapshot timing. Recovery should only reference redo contained within the snapshot set.

Step 8: Open CDB and PDBs

Skip this step if you used Option 5B (PDB clone) - already complete

ALTER DATABASE OPEN RESETLOGS;  -- expected after snapshot restore
ALTER PLUGGABLE DATABASE ALL OPEN;
SELECT NAME, OPEN_MODE FROM V$PDBS;

If you renamed the CDB in Step 5A:

• RESETLOGS is required after NID

• PDB names remain unchanged (only CDB name changed)

• Update listener and tnsnames configuration for new CDB name

RESETLOGS after a snapshot restore is expected and fully supported by Oracle.

Procedure: In-Place Restore / Clone (Summary)

For an in-place restore:

1. Shut down the CDB.

2. Replace existing volumes with snapshot volumes.

3. Mount filesystems.

4. Follow Steps 5–8 above (MOUNT, RECOVER, OPEN, open PDBs).

In-place restores should only be performed with change approval and documented rollback plans.

Post-Restore Verification

SET LINESIZE 150 PAGESIZE 100
COLUMN name FORMAT A20
COLUMN pdb_name FORMAT A30
COLUMN open_mode FORMAT A15
COLUMN log_mode FORMAT A12
COLUMN instance_name FORMAT A20


# CDB Status 
SELECT d.name AS cdb_name, d.dbid, d.open_mode, d.log_mode, i.instance_name, i.status AS instance_status, i.database_status
FROM v$database d, v$instance i;


# PDB Status
SELECT con_id, name AS pdb_name, open_mode, restricted, recovery_status
FROM v$pdbs
ORDER BY con_id;

Automation Guidance

Automation is recommended for both snapshot creation and restore to reduce human error and enforce consistency, and simplify repeatable operations.

Core Principles

• Keep orchestration atomic, tightly timed, and failure-aware (fail fast, fail safe).

• For restores, never mix snapshot data with newer redo or archive logs, and ensure all CDB and PDB-related files are captured in the same snapshot set.

• Prefer out-of-place restores whenever possible for safety and repeatability at both CDB and PDB level.

• Always capture audit data: CDB name, PDB name(s), snapshot name, clone names, host mappings, timestamps, script version, and database open mode.

Reference Implementations

The following reference implementations are available in the EverpureStorage-OpenConnect GitHub repository:

• Shell scripts (bash): Filesystem-based Oracle snapshots on Everpure FlashArray

• Ansible playbooks: End-to-end orchestration of Oracle snapshot operations

• Python examples: Leverage Everpure FlashArray REST API and SDKs

Common Pitfalls

Summary

Everpure FlashArray snapshot-based restores deliver fast, predictable recovery for multitenant (CDB/PDB) Oracle databases on filesystem storage. By combining disciplined, CDB-aware snapshot routines with out-of-place restores, you gain safe, repeatable PDB- and CDB-level recovery, rapid cloning for dev/test, and confident day‑to‑day operations.