3Par Snapshot behaviour if primary volume is encrypted by Ransomware

[AWR]

Hi,

We have an HPE 3Par, and use Virtual copy snapshots as a part of the backup.

Our audit team raised the issue of what happens when the primary volume is encrypted with Ransomware, and how would this affect the snapshots and array capacity?

Any input would be appreciated.

Kind regards

Andrew Rycroft

[Sheldon Smith · Accepted solution]

Hi Andrew,

Short version: The snapshots will grow and consume some of your free pool.

Long version: Everything's virtual. Between the logical volume and the physical disks are pointers to pointers to pointers to ... You get the idea. When a snapshot is made, the virtual volume's pointer block is duplicated. At least for an instant, both the parent volume and the snapshot point to the same physical disk locations; one LUN block, two virtual volume pointers.
From that point on, if both virtual volumes' (parent and snapshot) point to the same physical data, then a free block is allocated, the parent pointers are updated to point to the free block and the data is written. The snapshot still points to the parent's pre-snap logical block.
Two logical blocks, two pointers. As they are now pointing to separate blocks of data, any subsequent changes to the parent logical block have no effect on the snapshot logical block.
As more and more of the parent volume is changed, the snapshot will grow holding all the pre-snapshot data.

You may want to search for the white paper, HPE 3PAR Virtual Copy -- 4AA6-4486ENW

[Sheldon Smith]

Lastly: Having thought about it, I went to the 3PAR bible ("HPE 3PAR Command Line Interface Reference"). The "setvv" command has a couple policy options:

• stale_ss—Specifies that invalid snapshot volumes are permitted. Failure to update snapshot data does not affect the write to the base volume, but the snapshot is considered invalid.
• no_stale_ss—Specifies that invalid snapshot volumes are not permitted. Failure to update a snapshot is considered a failure to write to the base volume.

The default is "stale_ss". And if I wanted snapshots to protect against a base volume getting corrupted by ransomware, I think you want them set to "no_stale_ss" -- Fail to write to the base volume rather than consider the snapshot invalid.

And you may want to set the Retention Date on the snapshots so someone can't get in to the 3PAR and delete the snapshots.. 2 or 3 days? a week? Long enough to see things have gone to hell and you still have valid snapshots.

You have hardened the password for 3paradm, haven't you? 8^)