Search the docs

Hammerspace WORM Capabilities

Hammerspace provides Enterprise WORM functionality within its own file system, though it can also integrate with third-party Compliance WORM systems. It provides many flexible options to enable organizations to protect valuable digital data against unauthorized changes or deletion.

WORM is implemented in Hammerspace using objectives, which are flexible policies that can define where files live, when they move, and many other aspects of their behavior. When applied to a file, directory, or entire share, WORM objectives prevent subject files from being changed or deleted. Because of the flexibility of objectives and Hammerspace in general, there are many different ways to configure WORM to meet different business requirements.

Hammerspace WORM has the following key characteristics:

  • Multi-protocol: WORM objectives apply across NFS, SMB, and S3 client protocols, and may even be set via S3 using standard S3 API calls.

  • Storage independent: Shares in Hammerspace are abstractions that by default are not tied to any specific underlying storage system. This is very different from traditional WORM that is implemented in a separate storage system or partition. In the traditional case, files must always live on the siloed WORM storage, which may be difficult to use or slow. With Hammerspace, files may be dynamically and transparently orchestrated between storage systems based on objectives, while remaining in the same logical location and retaining WORM protection.

  • Granular: WORM objectives may be applied at the file, directory, or share level, or a combination of these. When applied at the share or directory level, objectives are inherited. All files placed in a directory having the worm-operation objective will be affected, as will any subdirectories created there. By using the ALWAYS and TRUE objective applicability options judiciously, it is possible to create layered structures with different WORM characteristics. One example is creating a share with a default WORM retention period, and having some directories within the share configured with a longer retention period, for example for a legal hold use case.

  • Compatible with WORM storage: Selected files may be protected on third-party WORM storage. Examples include object storage or cloud storage that supports WORM (aka "Object Lock") and WORM tape behind a supported S3-to-tape gateway. Hammerspace brings previously siloed WORM repositories into the global namespace.

Some of the options that may be used with WORM objectives include:

  • Expiration date: A WORM share may have an expiration date, after which files again become writable and deletable. This date may be extended further into the future but not reduced.

  • Effective time: WORM objectives normally take effect when a file is created. If desired, there may be a delay before WORM takes effect. For example, only after a file has been closed for 15 minutes, 15 days, etc. Similarly, one may define a duration after which the WORM objective expires. For example, 1 year from the date the file was created.

  • Snapshots: Hammerspace snapshots are read only, but may be removed by an admin or a schedule. To provide protection against deletion, objectives may be used to copy snapshots to immutable storage, such as an AWS bucket with Object Lock enabled.

  • Clones: Hammerspace file and directory clones may be protected with WORM objectives.

  • Privileged delete: As with most other Enterprise WORM solutions, Hammerspace allows administrators to delete WORM-protected files. This is done via the privileged-delete command, which may be executed from the administrative CLI of the Hammerspace system. This command can only delete WORM-protected files, not regular files. It should be used with extreme care, keeping in mind the organization’s requirements and policies around the affected data.