Data Protection, Snapshots, and Replication
This domain separates snapshots from replicas, explains how protection policies bind schedules to objects, and tests the recovery sequence at a remote site.
Snapshots and clones
- A snapshot is a point-in-time, space-efficient copy inside the volume family; only changed blocks consume capacity.
- Snapshots support in-place restore of a volume or creation of a thin clone that is immediately writable and independent.
- A volume-group snapshot is consistent across all members, which is what multi-volume databases require.
- Snapshot rules define schedule and retention. A protection policy combines snapshot rules with an optional replication rule, and you assign the policy to volumes or volume groups rather than building schedules per volume.
Replication
- Native replication links two systems through a remote system object over FC or iSCSI. That interconnect is array-to-array, not routed through hosts.
- A replication rule defines the RPO; asynchronous replication ships changed blocks on that schedule.
- Metro or synchronous zero-RPO configurations exist in recent PowerStoreOS releases and demand low-latency links plus careful design.
- Recovery verbs: failover activates the destination copy, reprotect reverses direction after the source returns, and failback restores the original direction. Planned failover quiesces the source first for a clean RPO.
Worked example
An application needs a 15-minute RPO and 24 hours of retention. Reasoning: set the replication rule RPO to 15 minutes, and add a snapshot rule taking one snapshot every 15 minutes retaining 96 copies, which covers 24 hours. Then confirm link bandwidth can move the change rate inside one interval; a session that cannot complete within its RPO lags permanently and the RPO claim is fictional. At the DR site, fail over the volume group rather than individual volumes.
Traps
- Calling a snapshot a backup: it lives on the same array and does not survive array loss.
- Assigning a replication rule before the remote system connection is healthy.
- Assuming failover is automatic; it is an operator action.
- Deleting a snapshot rule or protection policy that is still assigned to objects.
- Ignoring replication session lag instead of alerting on it.