Pure Storage FlashArray: purevol and Host Management

Purity's CLI is deliberately flat and predictable: each object type has its own command (purevol, purehost, purehgroup, purearray), and almost every operation has a list subcommand that makes it self-documenting. The trap for newcomers is the lifecycle wording — destroyed is not deleted, and eradicated is not recoverable — plus the fact that a volume cannot simply be enlarged or shrunk without consequences. This guide is a working runbook for provisioning, snapshotting and mapping volumes.

Get Oriented

ssh pureuser@flasharray-vip
purehelp
pureman purevol

purearray list
purearray list --space
purearray list --space --historical 30d
pureversion

Connect to the array's virtual IP so Purity can steer your session to the current primary controller; the same commands run against a physical controller IP but will fail over mid-session during a controller event.

Create and Map Volumes

purevol create --size 2T vol_vmdata01
purevol create --size 500G vol_backup_proxy
purevol list --sort size-
purevol list --space

purehost create --iqn iqn.1998-01.com.vmware:esxi01 esxi01
purehost create --wwnn 20:00:00:25:b5:01:00:0a --wwpn 20:00:00:25:b5:01:00:0b esxi02
purehgroup create esxi_cluster --hostlist esxi01,esxi02

purevol connect vol_vmdata01 --hgroup esxi_cluster
purehost list --connect
purevol list --connect

Prefer host groups over individual host mappings: a LUN ID that changes for one host but not another is the most common cause of "the datastore disappeared after a rescan".

Snapshots and the Destroy/Restore Semantics

purevol snap vol_vmdata01                    # creates vol_vmdata01.snap1
purevol snap vol_vmdata01 --suffix PRD       # named suffix
purevol list --snap
purevol setattr --size 3T vol_vmdata01       # grow
purevol truncate --size 20G vol_vmdata01     # shrink - dangerous

purevol disconnect vol_vmdata01 --host esxi01
purevol destroy vol_vmdata01                 # unavailable, recoverable for 24h
purevol list --pending
purevol recover vol_vmdata01
purevol eradicate vol_vmdata01               # permanent

• A destroyed volume and its snapshots remain on the array for 24 hours; after that they are eradicated automatically. purevol eradicate skips the wait.
• Shrinking a volume below the used capacity corrupts the filesystem — the snapshot taken at truncate time is your rollback, so verify it exists before shrinking.
• Take a snapshot immediately before any size change or host re-mapping; it is the fastest rollback path and costs nothing in performance.

Protection Groups and Immutability

purepgroup create pg_prod --hostlist esxi01,esxi02
purepgroup addvol pg_prod --vol vol_vmdata01
purepgroup setattr pg_prod --snap-frequency 86400 --snap-retention 2592000

# SafeMode must be activated by support first
pureprotection safemode --enable --eradication-delay 1440 pg_prod
pureprotection list pg_prod
pureprotection snap --suffix manual-test pg_prod

Snapshot frequency and retention are in seconds: 86400 is daily, 2592000 is 30 days. SafeMode snapshots cannot be eradicated even by an administrator with a compromised credential, which is what makes them a genuine ransomware control rather than a backup convenience.

Health and Capacity Checks Worth Automating

purearray list --space
purearray phonehome
purehw list --exclude-ok
purealert list
purealert tag --help
puredrive list
puremessage list

Alert the on-call rotation on purehw list --exclude-ok (hardware faults), purealert list for unacknowledged array alerts, and capacity trending from purearray list --space --historical at 70 percent and 80 percent thresholds. Everything above is scriptable, so the array can report its own state into your monitoring stack instead of relying on someone opening the GUI.

Related reading: SAN HBA queue depth and multipath tuning and ONTAP fpolicy configuration.

原文链接：https://storagearea.network/pure-storage-cli-commands-cheatsheet/