A few years ago I was introduced to the NetApp storage technology and it’s backup, clone, DR capabilities and etc. To be honest at the beginning I didn’t feel very confident on how would that work with Oracle internals and particularities like SCN, archived logs and others.
After several testing and trying different scenarios I had my first database in production using NetApp and just to add a bit of complexity it was a RAC database.
Well, It actually works very well. The FlexClone capability is awesome to replicate production data for testing and other purposes. SnapShot for local backup are amazing fast and SnapMirror and SnapValt for DR are just what I need.
NetApp has now SnapValidator which is what was missing for block corruption check.
Below is some information about SnapShots from NetApp man pages.
The snap family of commands provides a means to create and manage snapshots in each volume.
A snapshot is a read-only copy of the entire file system, as of the time the snapshot was created. The filer uses a copy-on-write technique to create snapshots very quickly without consuming any disk space. Only as blocks in the active file system are modified and written to new locations on disk does the snapshot begin to consume extra space.
Snapshots are exported to all CIFS or NFS clients. They can be accessed from each directory in the file system. From any directory, a user can access the set of snapshots from a hidden sub-directory that appears to a CIFS client as ~snapshot and to an NFS client as .snapshot. These hidden sub-directories are special in that they can be accessed from every directory, but they only show up in directory listings at an NFS mount point or at the root of CIFS share.
Each volume on the filer can have up to 31 snapshots at one time. Because of the copy-on-write technique used to update disk blocks, deleting a snapshot will generally not free as much space as its size would seem to indicate. Blocks in the snapshot may be shared with other snapshots, or with the active file system, and thus may be unavailable for reuse even after the snapshot is deleted.
The snap commands are persistent across reboots. Do not include snap commands in the /etc/rc. If you include a snap command in the /etc/rc file, the same snap command you enter through the command line interface does not persist across a reboot and is overridden by the one in the /etc/rc file.
Automatic snapshots can be scheduled to occur weekly, daily, or hourly. Weekly snapshots are named weekly.N, where N is “0” for the most recent snapshot, “1” for the next most recent, and so on. Daily snapshots are named daily.N and hourly snapshots hourly.N. Whenever a new snapshot of a particular type is created and the number of existing snapshots of that type exceeds the limit specified by the sched option described below, then the oldest snapshot is deleted and the existing ones are renamed. If, for example, you specified that a maximum of 8 hourly snapshots were to be saved using the sched command, then on the hour, hourly.7 would be deleted, hourly.0 would be renamed to hourly.1, and so on.
snap list [ vol_name ]
snap create vol_name name
snap delete vol_name name
snap rename vol_name from to
snap reserve [ vol_name [ percent ] ]
snap restore [ -f ] [ -t vol | file ] [ -s snapshot_name ] [ -r restore_as_path ] vol_name | restore_from_path
snap sched [ vol_name [ weeks [ days [ hours[@list] ] ] ] ]
Source from this post: NetApp man pages