SYSTEM Cited by 1 source
NetApp SnapCenter¶
Definition¶
NetApp SnapCenter is NetApp's application-aware data-protection control plane for ONTAP storage. It coordinates storage-layer snapshots with application state (databases, VMs, filesystems) so backups are application-consistent, and it drives point-in-time recovery, FlexClone cloning, and SnapMirror replication updates from a single scheduler. On AWS it manages FSx for NetApp ONTAP file systems; the SnapCenter Plugin for Oracle makes it Oracle-aware.
Stub page — surfaced on the wiki as the Oracle-aware backup / PITR / clone control plane in AWS's Oracle-on-EVS deployment. Expand as further ONTAP data-management sources are ingested.
Why storage-layer, application-aware backup¶
Because SnapCenter backups are ONTAP snapshots (not Oracle RMAN streams or file copies), backup and restore are near-instant and independent of database size — the architecture companion claims "recovery in seconds regardless of DB size." The application-aware part is that SnapCenter quiesces / coordinates Oracle so the snapshot is consistent (data + control + archive logs captured as a recoverable set), and it can trigger a SnapMirror update as part of a backup so the DR copy advances in lockstep.
In the Oracle-on-EVS deployment, FSx ONTAP's own automatic daily backups are disabled specifically so SnapCenter owns Oracle-aware scheduling instead. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)
Setup (Oracle-on-EVS, 2026-10-02)¶
- Deploy SnapCenter Server (or use SnapCenter SaaS).
- Add the FSx ONTAP storage system by its cluster management IP.
- Install the SnapCenter Plugin for Oracle on each Oracle VM.
- Create backup policies, resource groups, and schedules:
| Policy | Scope | Frequency | SnapMirror update |
|---|---|---|---|
| Full DB Backup | Data + Control + Archive | every 4–6 hours | Yes |
| Archive Log | Archive logs only | every 10–15 minutes | Yes |
The two-tier cadence (coarse full + frequent archive-log) is what makes tight-RPO PITR possible — the archive-log snapshots every 10–15 min bound how far back a recovery must replay.
Day-2 capabilities¶
- Snapshot backup — full DB snapshots as storage-layer operations.
- Point-in-time recovery — select an SCN or timestamp, mount the log
snapshot, restore the data snapshot, apply archive logs, and open with
RESETLOGS. A classical (storage-array) instance of PITR — snapshot-restore + log-replay, not a compute-storage-separated COW fork. - Database cloning (FlexClone) — space-efficient copies that share unchanged blocks with the source and consume storage only for deltas; a copy-on-write fork at the ONTAP layer. Used for dev/test, patch validation, and reporting.
(Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)
Seen in¶
- sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap
— the Oracle-aware backup/PITR/clone control plane for Oracle on
EVS: SnapCenter Server + Oracle plugin per VM, Full
DB (4–6h) + Archive Log (10–15 min) policies both triggering SnapMirror
updates; PITR via SCN/timestamp + archive-log apply +
RESETLOGS; FlexClone space-efficient cloning for dev/test.
Related¶
- systems/amazon-fsx-for-netapp-ontap — the ONTAP storage SnapCenter protects; SnapMirror + FlexClone are ONTAP primitives SnapCenter orchestrates.
- systems/oracle-database — the protected workload (SnapCenter Plugin for Oracle).
- systems/amazon-evs — the EVS/VCF substrate the Oracle VMs run on.
- concepts/point-in-time-recovery — the storage-snapshot + archive-log-replay PITR SnapCenter performs.
- concepts/copy-on-write-storage-fork — the mechanism behind FlexClone cloning.
- concepts/rpo-rto — SnapCenter cadence + SnapMirror updates set the achievable RPO.