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^)

[RohanS]

@Sheldon Smith 

Hello Sheldon,

Hope you are doing well.

I have some additional query on this topic of ransomware protection via snapshots.

* We do not have replication, however we want to understand if taking snpashot can be a viable solution for ransomware at array end.  And if we should be looking toward more concreate solution [ ex. Backup's ]
* If answer is yes for above question, then as you mentioned to set policy to "no_stale_ss", will this use more space, if yes, how much ? Need some more clarification on the space consumption. [ in comparison with policy "stale_ss" ]
* And when we set retention policy for snapshots, how will it affect space reclamation at Volume and CPG level.
As from what I know, all snapshots need to be deleted of a volume and then freespace command need to be used to free up allocated space from volume and then  run compactcpg to reclaim space.
So how can we take care of space reclamation when we have snapshots with retention policy.

Regards,
Rohan.