Creating Storage Snapshots of an Oracle Single-Instance Databases on Filesystems Using Everpure FlashArray

Purpose

This knowledge base (KB) describes the recommended, supportable procedure for creating crash‑consistent and application‑consistent volume snapshots of Oracle single‑instance, non‑CDB databases on Linux that use traditional filesystems (XFS/ext4) backed by Everpure FlashArray volumes.

​It documents the preferred snapshot workflow for Oracle 11g, 12c, and 19c single‑instance databases that are not configured as multitenant container databases (CDBs). For Oracle multitenant (CDB/PDB) deployments, see the separate KB Oracle 19c/26ai Multitenant Snapshots on Everpure FlashArray, which supersedes this document for CDB/PDB environments.

For single‑instance multitenant database snapshots on filesystems, see Creating Storage Snapshots of Oracle 19c/26ai Multitenant Databases on Everpure FlashArray.

A full restore procedure is provided in the companion KB: Restoring Storage Snapshots of Oracle Multitenant Databases on Filesystem on Everpure FlashArray.

Scope and Assumptions

Target Audience

• DBAs

• Storage administrators

• Platform / infrastructure engineers

In Scope

• Oracle single-instance databases (filesystem-based)

• Linux hosts (RHEL, OEL, etc.)

• Everpure FlashArray block volumes mounted as filesystems

• Snapshot creation using Everpure FlashArray (GUI or CLI)

Out of Scope

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

• Oracle RAC

• Application-managed snapshots (RMAN, Oracle Snapshot Manager)

Storage Layout & Prerequisites

To ensure valid snapshots, create three dedicated Everpure FlashArray volumes (or LUNs) for the database: one each for datafiles, online redo logs, and archived logs, then map them to the database host and mount them as separate filesystems. All database‑related volumes must reside on the same FlashArray and will later be grouped in a single Protection Group (PG) for atomic snapshots.

Example target layout

Prerequisite checklist

Database

• ARCHIVELOG mode is not a requirement for crash‑consistent volume snapshots

• ARCHIVELOG mode is required for application-consistent volume snapshots so backups include archived redo and can be used for full and point‑in‑time recovery.

• ​Control files and parameter files are located on storage that will be protected by backup and/or included in the same snapshot strategy as needed.

• Access: SYSDBA access for SQL commands and OS permission to flush buffers.

​Host and OS

• Linux host has multipath configured and stable device names for all Everpure volumes.

• ​Filesystems are mounted and owned by the Oracle OS user with sufficient free space for growth.

FlashArray

• All database volumes (data, redo, arch) are on the same Everpure FlashArray.

• ​Volumes are members of a single Protection Group that will be used for snapshots.

Snapshot Consistency Models

Crash-Consistent Snapshot (Fastest)

Method: Snapshot without pausing the database.

• Impact: Zero database downtime.

• Recovery uses instance recovery from online redo only; ARCHIVELOG is optional.

• Use cases: Backups, Reporting clones, DR testing

Application-Consistent Snapshot (Recommended)

Method: Place the database in BEGIN BACKUP mode, take snapshots, then END BACKUP.

• Impact: Brief increase in redo generation; no database outage.

• Recovery: Clean, predictable recovery after restore.

• Use cases: Production restores, Gold images, Compliance backups

Snapshot Strategy Summary

Guidance: Use application‑consistent snapshots for production recovery SLAs. Reserve crash‑consistent snapshots only for non‑production or when Oracle coordination is not possible.

High-Level Workflow

1. Identify filesystem volumes to snapshot

2. Place database in BEGIN BACKUP mode (application-consistent only)

3. Force archive log switch

4. Flush OS buffers

5. Take Everpure FlashArray volume snapshots

6. END BACKUP mode

7. Post-snapshot validation

Notes

Create a Protection Group (as required)

Before snapshotting the database volumes, create a Protection Group (PG) to ensure all related volumes are snapped together with write‑order consistency.

purevol list *ORCL*

purepgroup create --vollist oracle-prod-fs oradata_vol,redo_vol,arch_vol pg-oracle-prod-fs

purepgroup add --vollist pg-oracle-prod-fs oradata_vol,redo_vol,arch_vol

purepgroup list pg-orcl-prod-fs

Procedure: Application-Consistent Snapshot

Step 1: Place Database in Backup Mode

sqlplus / as sysdba
ALTER DATABASE BEGIN BACKUP;

ALTER SYSTEM ARCHIVE LOG CURRENT;

# On the database host
sync

Snapshot all volumes as part of the Protection Group (PG). While individual volumes can be snapped, using a PG is the best practice to maintain write‑order consistency across all volumes.

purepgroup snap --suffix ${ENV}-${DB_NAME}-${APPCONS}-$(date +%F_%H%M%S)-${CHANGE_ID} pg-prod-orcl-fs

<ENV>-<DB_NAME>-<APPCONS>-<YYYY-MM-DD-HHMMSS>-<CHANGE_ID>
Example:
pg-prod-orcl-fs.prod-orcl-appcons-2026-03-17-142530-chg1234

ALTER DATABASE END BACKUP;
ALTER SYSTEM ARCHIVE LOG CURRENT;

Procedure: Crash-Consistent Snapshot

-- Force a checkpoint to flush dirty buffers to disk
ALTER SYSTEM CHECKPOINT;

-- Switch and archive the current redo log (captures all committed work)
ALTER SYSTEM ARCHIVE LOG CURRENT;

-- Optionally record the SCN for documentation
SELECT CURRENT_SCN, TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS') SNAP_TIME
FROM V$DATABASE;

purepgroup snap --suffix ${ENV}-${DB_NAME}-CRASHCONS-$(date +%F_%H%M%S)-${CHANGE_ID} pg-prod-orcl-fs

<ENV>-<DB_NAME>-CRASHCONS-<YYYY-MM-DD-HHMMSS>-<CHANGE_ID>

prod-orcl26-CRASHCONS-2026-03-17-142530-chg1234

Verification

Confirm snapshot creation:

• Everpure GUI: Storage → Volumes → Snapshots

• Everpure CLI:

purepgroup listobj --type snap pg-prod-orcl-fs

SELECT open_mode, log_mode FROM v$database;

Automation Guidance

Automation Principles

• BEGIN BACKUP → SNAPSHOT → END BACKUP must be atomic, tightly timed, and failure-safe

• Ensure END BACKUP executes even if snapshot creation fails

• Snapshot timing measured in seconds, not minutes

• Logging and error handling must be clear and auditable

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

Repository: https://github.com/PureStorage-OpenConnect/oracle-scripts

Automation Best Practices

• Pre-stage Pure authentication (API tokens, CLI login) to avoid interactive prompts during scheduled runs

• Keep BACKUP windows to seconds by performing only minimum required operations between BEGIN and END BACKUP

• Centralize snapshot execution where possible (Ansible control node, scheduling system, automation server)

• Prefer Protection Group snapshots over per-volume commands to preserve write-order consistency

• Log snapshot name, timestamp, database mode, and current log sequence for auditing and recovery

Common Pitfalls and Solutions

Summary

Everpure FlashArray filesystem snapshots deliver near‑instant capture, minimal performance impact, and fast recovery when coordinated with Oracle coordination. For production recovery SLAs, use application‑consistent snapshots and protection groups to ensure predictable restores.