Last month I discussed the switch of the management interfaces to start implementing new features using a Policy Based Management philosophy. That post discussed the simple Provisioning Policies that can be created, here we are going to talk about FlashCopy 2.0 – or at least a new way to manage a subset of the FlashCopy capabilities with the new Volume Group Snapshot capabilities introduced earlier this year in 8.5.1 and enhanced in 8.5.2 to provide Snapshots with Immutability as a new way to implement Safeguarded Copy for Cyber Resilience.

FlashCopy Considerations

First off, Snapshots make use of FlashCopy. That is, the underlying technology used by Snapshots is the same FlashCopy we’ve had for many years. Snapshots, and to give it a more accurate name, Volume Group Snapshots simply take the time consuming and sometimes painful pre-configuration tasks out of the picture, hiding the complexity and simplifying day to day snapshoting tasks.

Investments in FlashCopy, scripting, process etc and the technology itself is not wasted, we will continue to support and use the technology, but new installs or updated process may want to switch to the Snapshot management constructs to benefit from the simplification and ease of integration with external automation software.

FlashCopy has been around since version 1 of Spectrum Virtualize, some 19+ years ago. It is feature rich and can be used to create a plethora of different point in time copies, incremental, cascaded, multi-target, reverse, backups to name just a few. However as a result, it can become quickly complex, and particularly troublesome if you have cascaded multi-target topologies and happen to stop or delete “the wrong one”… the dependency chains have cause many users to have ‘unexpected’ results.

Volume Group Snaphot (VGS)

All of this leads us to the introduction of Volume Group Snapshots (VGS). As we introduced last time, a Volume Group is at the heart of the new Snapshot management. Create a Volume Group, add multiple Volumes (vdisks) to you Volume Group and then make a point in time copy of the Volume Group – et voila, now you have a Volume Group Snapshot.

Its that simple, you don’t need to mess around with target vdisks and flash copy mappings. If a Volume exists in the Volume Group at the time the Snapshot is created, an equivalent Volume Snapshot will be created in the VGS that corresponds to that Volume.

The VGS has some attributes, such as the date and time it was created, and if it is immutable or not.

Of Immutability & Consistency

The data that represents the point in time that makes up the Volume Group Snapshot is always immutable and all Volumes within the Snapshot are mutually consistent.

Put another way, the data within a VGS is always immutable, but the VGS itself can be deleted.

If you want to create a Safeguarded VGS that has both immutability of the data, and the VGS object itself (to use as a Safeguarded Copy) then you can select that the VGS is immutable or “Safeguarded” when created.

Clones and Thin-Clones

As the contents of a VGS are immutable, you need to use the VGS as the source for a Clone or Thin-Clone if you wish to access the point in time copy of the data stored within the VGS. This again is a simple a asking for a Clone or Thin-Clone of the VGS, you can think of this a essentially having a third Volume Group – but this time one you can read and write to.

A Clone as the name suggests creates a full copy of the VGS point in time data and will eventually be independent of the VGS itself – think setting the background copy rate to anything other than 0 (NOCOPY).

A Thin-Clone stays thin provisioned, so the copy that you access only contains data that you may update or over-write in the Thin-Clone Volume Group itself. It therefore doesn’t really grow or consume more space. All the changes are stored in the VGS itself. This is equivalent to setting the background copy to 0 (NOCOPY).

You can create multiple Clones or Thin-Clones of a VGS. Just as you can create multiple VGS of a Volume Group.

Policy Based Management

With the updates in 8.5.1 and 8.5.2 we can finally implement a schedule of Snapshots. That is we have a built in scheduler for Volume Group Snapshots (unfortunately this doesn’t extend backwards to vanilla FlashCopy). This allows you to specify a Snapshot Policy.

The Policy can be given a name, you define the frequency that new VGS will be created, and how long they are to be retained for. The retention allows you to ensure that your regular snapshot creation doesn’t run away with all your capacity!

You can also define an exact start date and time. Thus you can schedule for example a daily VGS to be created at 10pm every night for use as the source of a backup or archive job etc.

Using this scheduler provides only crash consistent VGS. That is we do not allow you to run pre/post scripts to wrap around the triggering of a new VGS.

Safeguarded Copy using Snapshots

You will see in the screenshot above that the “Safeguarded” box is ticked, this as described before make the VGS itself immutable. Only the system can clean up or delete these VGS based on the retention period of the policy.

Like most other policies you simply apply this Policy to the Volume Group and it will automatically begin creating VGS based on the schedule defined in the Policy. You do not need to create a Child Pool repository as you did before. The Snapshot Volumes are created in the same Pool as they source Volume. Therefore a Volume Group can contain Volumes from different pools and the Volume Snapshots are handled automatically. Since the Volume Snapshot data is immutable by nature, then there is no need for a separate Child Pool any longer.

Other Notable Information

Up to 512 Volumes can be contained in a single Volume Group, and up to 1024 Volume Groups per System. However I’d caution against adding many hundreds of Volumes to a single Volume Group. The underlying FlashCopy pause and prepare – where it has to flush the data from cache to maintain disk level consistency can lead to serialised delays if many hundreds of Volumes need to be maintained consistently. Consider reducing the number of Volumes in this case.

At present there is no “reverse in place” to reverse back from a Snapshot to the source to recover. This can be achieved by re-mapping to a Clone Volume Group.

If you add a Volume to a Volume Group, the next time you Snapshot the Volume Group it will include the new Volume Snapshot. Older Snapshots remain valid and usable, they have a flag to denote they are no longer consistent with the contents of the source Volume Group but they are still maintained.

One other use case that has been discussed is the ability to re-use an existing Clone/Thin-Clone Volume Group – today when you create a Clone/Thin-Clone it will always create a new Volume Group with new Volumes. It would be a nice addition if you could re-use existing Volumes (that are already mapped to hosts for example) if this is a staging area for a backup or archive type workload and the development team are looking at what could be done here.

Its worth noting that Snapshots are not intended to replace the entire functionality provided by FlashCopy today – more over they are intended as a simplification for commonly repeated tasks and a way to provide a simple way to integrate point in time copies into your business automation processes.