Abstract: Generation of new snapshots of a storage object are prompted based on changes to the storage object. An absolute storage change condition is satisfied when the aggregate amount of changed data since the most recent snapshot satisfies a threshold that represents a predefined amount of storage capacity, e.g., N GB. A percentage of used storage change condition is satisfied when the aggregate size of the changes expressed as a percentage of the provisioned storage capacity of snapped storage object satisfies a predetermined threshold, e.g., X % of Y TB. A percentage of provisioned storage change condition is satisfied when the aggregate amount of the changes in terms of percentage of utilized storage capacity of storage object satisfies a predetermined threshold expressed as a percentage of the utilized capacity of the storage object, e.g., P % of Z TB.

Abstract: Snapsets containing snapshots from a group of storage volumes are assigned snapset IDs. The same snapset ID is applied to each snapshot of the snapset, and is a globally unique value within the storage system. The snapset ID is assigned to a snapshot upon creation, and remains the same regardless of creation or deletion of other snapshots on the storage volume. By assigning a snapset ID to each snapshot of the snapset, and maintaining the snapset ID as a constant value as long as the snapshot is maintained on the storage system, it is possible to easily determine which snapshots form a given snapset. Control operations on particular storage groups or across storage groups are implemented by specifying particular actions to be taken on snapsets or snapshots, which are identified using the snapset IDs.

Abstract: Targetless snapshot schedules are defined by policy objects that include a snap creation interval, maximum snap count, and schedule ID. Multiple schedule IDs can be associated with a single storage object to implement different concurrent targetless snapshot schedules with a single storage object. Multiple storage objects may use the same targetless snapshot schedule independently. Because the targetless snapshot schedules are implemented independently, discard of old snapshots to maintain a snap count for a first storage object does not cause discard of snapshots for a second storage object. Further, discard of old snapshots to maintain a snap count for a first schedule does not cause discard of snapshots for a second schedule applied to the same storage object.

Abstract: Targetless snapshots that are in use are excluded from discard and exempted from inclusion against a snapshot retention count limit. Snapshots that are linked to a target volume are considered to be in use. Snapshots having a persist attribute set are considered to be in use. Snapshots having an expiration attribute set are considered to be in use until at least the expiration time. Snapshots having an age limit attribute set are considered to be in use until reaching at least the specified age. The snapshot retention count limit can be updated with a command. Other commands discard snapshots created before a specified time or older than a specified age, provided the snapshots are not in use. A terminate all command prompts discard of all snapshots that are not in use.

Abstract: Snapsets containing snapshots from a group of storage volumes are assigned snapset IDs. The same snapset ID is applied to each snapshot of the snapset, and is a globally unique value within the storage system. The snapset ID is assigned to a snapshot upon creation, and remains the same regardless of creation or deletion of other snapshots on the storage volume. By assigning a snapset ID to each snapshot of the snapset, and maintaining the snapset ID as a constant value as long as the snapshot is maintained on the storage system, it is possible to easily determine which snapshots form a given snapset. Control operations on particular storage groups or across storage groups are implemented by specifying particular actions to be taken on snapsets or snapshots, which are identified using the snapset IDs.

Abstract: Targetless snapshot schedules are defined by policy objects that include a snap creation interval, maximum snap count, and schedule ID. Multiple schedule IDs can be associated with a single storage object to implement different concurrent targetless snapshot schedules with a single storage object. Multiple storage objects may use the same targetless snapshot schedule independently. Because the targetless snapshot schedules are implemented independently, discard of old snapshots to maintain a snap count for a first storage object does not cause discard of snapshots for a second storage object. Further, discard of old snapshots to maintain a snap count for a first schedule does not cause discard of snapshots for a second schedule applied to the same storage object.

Abstract: Targetless snapshots that are in use are excluded from discard and exempted from inclusion against a snapshot retention count limit. Snapshots that are linked to a target volume are considered to be in use. Snapshots having a persist attribute set are considered to be in use. Snapshots having an expiration attribute set are considered to be in use until at least the expiration time. Snapshots having an age limit attribute set are considered to be in use until reaching at least the specified age. The snapshot retention count limit can be updated with a command. Other commands discard snapshots created before a specified time or older than a specified age, provided the snapshots are not in use. A terminate all command prompts discard of all snapshots that are not in use.

Abstract: Described are techniques used in defining and maintaining group data used by multiple host systems. Group data is stored in a distributed fashion on one or more data storage systems. If a device of a data storage system belongs to a group, group data for that group is stored on that data storage system. Group data changes made by one host are communicated to the other hosts by accessing a common data area on each data storage system using a daemon executing on each host. Remotely mirrored groups may be defined on a remote data storage system. A remote mirror of a group includes group data modified in accordance with a point of view of the remote data storage system and a remote host.

Abstract: Described are techniques for simulation of a data storage system configuration. The simulation state reflects the data storage system configuration in accordance with an application programming interface (API) model. API calls result in reading existing data storage system configuration data and/or modifying the configuration data by execution of one or more low level calls. A daemon may operate in a simulation mode in which the low level calls are simulated rather than resulting in communications with a data storage system when operating in a non-simulation mode. A low level cache is used to store simulated values returned from the data storage system microcode. A high level cache is used to store API call return data. A seed file is used to initialize the simulation state.