Child pages
  • Appendix A: Content Metadata
Skip to end of metadata
Go to start of metadata


This appendix describes the system metadata that you can use to recover from a disaster and the content file server metadata to create your content distribution or replication rules. In planning your data replication strategy between geographical locations and/or disaster recovery scenarios within Netmail Store, ensure that you are using the system metadata automatically stored with every object to your advantage, as well as adding custom metadata that allows you to create dynamic rules for distributing your content. Metadata can be stored with an object from system metadata or content file server metadata.

System Metadata

The following persisted headers can assist you with restoring from a disaster recovery cluster based on either the cluster of origin or the date the object was created or last modified:

  • Castor-System-Cluster. Can be used to trace an object back to its cluster of origin in the event of a disaster. This is particularly important in scenarios where multiple satellite clusters are replicated into a centralized disaster recovery cluster.
  • Castor-System-Created. Specifies the date when an object was created or last modified. This header can be used for date-based rules.
  • Castor-System-Path. Specifies an object's qualified name (domain/bucket/object). Using this header, you can easily locate objects in any domain in a multi-tenant cluster, in addition to locating objects in any bucket in that domain. This type of metadata enumeration is most useful in a filter clause to filter objects by domain or bucket.
  • Castor-System-Domain. Specifies the name of the domain.

Content File Server Metadata

If you are using a Content File Server (CFS) client, the following metadata is stored automatically with CFS objects and can be used in content distribution or replication rules. For example, an admin can replicate only those files written to a configured 'Legal' share and a rule based on the CAStor-CFS-CFSID header could be used to isolate those files.

  • Castor-CFS-Filepath. The full path to the file when it was originally stored.
  • Content-Disposition.The name of the file.
  • Castor-CFS-Version. The version of the CFS software that originally stored the file.
  • Content-Type. The file MIME type.
  • CAStor-CFS-CFSID. The name of the mountpoint ID through which the file was originally stored.
  • Castor-CFS-FileId. The file's system ID for the file in the CFS namespace.
  • Castor-CFS-Uid. The file's user ID at the time it was stored.
  • Castor-CFS-Gid. The file's group ID at the time it was stored.
  • Castor-CFS-Mode. The file's permission mode in decimal at the time it was stored.

Custom Metadata

If you are using a custom-developed client to write to Netmail Store, additional HTTP headers (such as Content-Language, Content-Type, and so on) and optional custom metadata can also be stored with a object to aid in content distribution and processing with the new Content Router. Additionally, CFS allows definition of custom metadata at the mountpoint level.

  • No labels