HPE Nimble Storage CLI: Snapshots and Replication

HPE Nimble (Array OS) organises data protection around the volume collection, not the individual volume. A volume collection is a group of volumes protected together by one schedule, with the same retention and the same replication target - which is exactly how applications are recovered in practice. Working from the CLI is faster than the UI for bulk operations and scriptable for DR runbooks, and this walkthrough follows the order that keeps snapshots and replication consistent.

1. Survey the array

vol --list
vol --info Production-DB
pool --list
partner --list

Confirm the pool that hosts the volume, its size and free space, and whether a replication partner is already configured - creating a protection schedule against a partner that is not in sync is the usual source of failed replications.

2. Group the volumes into a collection

volcoll --create Production-App
volcoll --add_vol Production-App Production-DB
volcoll --add_vol Production-App Production-Logs
volcoll --info Production-App

Adding the database and its logs to the same collection guarantees they are snapped at the same moment. Snapping them independently is one of the most common causes of a database that will not start cleanly after a restore.

3. Snapshots: manual, then scheduled

# immediate snapshot of a single volume or the whole collection
snap --create Production-DB --name pre-patch-20260929
snap --create_from_volcoll Production-App --name pre-patch-app-supply

# inspect and manage
snap --list Production-DB
snap --info Production-DB.pre-patch-20260929
snap --delete Production-DB.pre-patch-20260929

Snapshots are space-efficient pointers: their footprint is limited to the blocks that changed while the snapshot existed. Managing the snapshot count per collection is therefore a retention decision rather than a capacity emergency - but snapshots that are never superseded do accumulate.

4. Protection schedules: snapshot plus replication

prot --create_schedule Production-DB-15min   --volcoll Production-App   --period 15min   --snap_retain 8   --replicate_to DR-Array   --repl_retain 96

prot --list
prot --info Production-DB-15min

One command defines local retention and the remote copy in the same policy, so a snapshot that exists locally always has a matching replica. Stagger schedules across collections - a dozen collections all snapping at :00 will briefly contend for array resources.

5. Partner status and replication health

partner --list
partner --info DR-Array
vol --info Production-DB | grep -i repl
snap --list --replica Production-DB

Verify the partner is online and that the last replication completed. A Nimble array will keep taking local snapshots while replication is down, so the local view can look perfectly healthy while your DR copy is hours stale - the gap is invisible unless you check.

6. Promotion during DR or testing

# downstream partner takes ownership of the collection
volcoll --promote Production-App
volcoll --info Production-App

Promotion makes the downstream partner authoritative for the collection, which is the correct step in a real failover and also the safest way to test restores: clone from the replica rather than touching production volumes. Where a peer-persistence or snapmirror design is already in place, the failover semantics differ - see HPE 3PAR Primera Peer Persistence: Failover Explained and NetApp ONTAP NFS Export Policy Configuration (CLI) for comparison before documenting your runbook.

Operational checklist

• Every production volume belongs to exactly one collection; volumes outside a collection are unprotected.
• Retention counts are set deliberately: 96 quarterly replicas is a very different cost from 96 fifteen-minute ones.
• Run a restore drill from the replica each quarter - an unrehearsed restore plan is not a plan.
• Watch for volumes rendered into snapshots at the array level as well; a volume presented from a snapshot rather than a live clone is a favourite cause of "the data went backwards" after maintenance. The equivalent auditing discipline on other arrays (Pure Storage FlashArray: purevol and Host Management) transfers directly.

原文链接：https://support.hpe.com/hpesc/public/docDisplay?docId=sd00004395en_us&page=GUID-836242CC-7527-4F19-8444-CF6A3C814DE4.html