--- title: "Managing Storage Nodes" slug: "managing-storage-nodes-6" tags: ["8.2", "Portal", "storage class"] status: "update" updated: 2026-11-01T05:53:01Z published: 2026-11-01T05:53:01Z canonical: "kb.ctera.com/managing-storage-nodes-6" --- > ## Documentation Index > Fetch the complete documentation index at: https://kb.ctera.com/llms.txt > Use this file to discover all available pages before exploring further. # Managing Storage Nodes CTERA Portal can write your data to storage nodes from many different vendors. The **Storage Nodes** page in the global administration view enables you to easily add new storage nodes, dedicate storage nodes to virtual portals, stop and start writing to different storage nodes, and migrate data seamlessly from one storage node to another storage node. **Note** CTERA recommends that whenever you create a new S3 bucket to use as the backend storage for a storage node, you enable *object lock* when creating the bucket and disable the default retention. For most S3 buckets, after the bucket is populated with content, you **cannot** set object lock. With AWS S3 buckets, you **can** set object lock after the bucket is populated with content. ## What Storage Node to Use Storage considerations include company policy, cost, and total size required. CTERA provides a storage node with the installation, [Local Filesystem](/v1/docs/local-filesystem-5), which can be used up to a maximum of 20TB. NFS storage, [EMC Isilon (NFS)](/v1/docs/emc-isilon-nfs-5), [Generic (NFS)](/v1/docs/generic-nfs-5), and [NetApp (NFS)](/v1/docs/netapp-nfs-5), storage nodes can be used for storage up to 100TB. All other storage nodes, such as [Amazon S3](/v1/docs/amazon-s3-7) and [IBM Cloud Object Storage (S3)](/v1/docs/ibm-cloud-object-storage-s3-5), support unlimited storage. ## Using Multiple Storage Nodes You can define multiple storage nodes. When there are multiple storage nodes, CTERA manages the writes so that the nodes are balanced in the following cases: - When multiple storage nodes are defined that are not dedicated to specific virtual portals. If a storage node is down, data is not written to that node, but to the other storage nodes that are up. - When multiple storage nodes are dedicated to the same virtual portal. If a storage node dedicated to the virtual portal is down, data is not written to that node, but to the other storage nodes dedicated to the same virtual portal, that are up. **Notes** Each block is written to a single storage node. If you want the same block to be written to another location, you have to use the storage provider functionality, such as Amazon Cross-Region Replication (CRR). When there are storage nodes of different types, for example, Amazon S3 and Microsoft Azure Blob Storage, a block from a single file can be written to one storage node while another block from the same file is written to another storage node of a different type. ## Grouping Storage Nodes: Cloud Storage Routing (Storage Classes) Cloud storage routing uses storage classes, which represent a group of one or more storage nodes that share a similar business requirement, such as location. For example, a storage class can consist of a number of storage nodes all in the same location. Each cloud folder group can be assigned to a storage class to enable the cloud folder group content to be written to a specific storage node. Storage classes can be used to provide the following main benefits: - Data sovereignty (GDPR) - Cost savings - Business efficiency ### Data Sovereignty Data sovereignty has become critical as strict rules dictate where data is stored and how it is moved, including differing laws and regulations across countries and regions. With CTERA Cloud Storage Routing, organizations can maintain data sovereignty, as well as compliance with GDPR and other regulations. ### Cost Savings By being able to select the cloud provider that exists nearest where the data creation is, huge cost savings can be achieved. Also, you can configure the routing to ensure that folder group content that is not accessed regularly, such as archived data, is always written to cheaper storage. ### Business Efficiency Your organization needs quick access to data in order to function efficiently. Until now, this has not always been possible, with data often stored in different places and especially when utilizing cloud data storage providers. CTERA Cloud Storage Routing provides low-latency access to data, ensuring that your teams always have access to the data they need. The team portal administrator can define [cloud folder groups](/v1/docs/adding-editing-or-deleting-a-folder-group-4) to write to a specific storage class, optimizing use of that cloud folder group with one or more of the benefits outlined above. Storage classes are defined using CLI. The storage nodes are assigned initially to a default storage class. The storage class can be changed from the default when the storage node is defined. After the storage node is defined the storage class cannot be changed. [Video](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/CloudStorageRouting.mp4?sv=2026-02-06&spr=https&st=2026-11-11T04%3A11%3A24Z&se=2026-11-11T05%3A11%3A24Z&sr=c&sp=r&sig=35uWqz5lXGT6zUOrAO2WJNZi6ntvkLoTYCRgJ32R4m4%3D) ### Defining a Storage Class Storage classes are defined using CLI. To run the CLI from the portal user interface, see [Execute CLI Commands from the Global Administrator User Interface](/v1/docs/execute-cli-commands-from-the-global-admin-user-interface). Use the following CLI to create a storage class: `add /storageClasses/ name <name>` where `<name>` is the name you call the storage class. ### Assigning a Storage Class to a Storage Node After defining the storage class, as described above in *Defining a Storage Class*, you can assign it to a specific storage node as part of the general storage node definition, described in [Adding and Editing Storage Nodes](/v1/docs/adding-and-editing-storage-nodes-5) ### Changing the Name of a Storage Class After defining a storage class, as described above in *Defining a Storage Class*, you can change the name using the following CLI: `set /storageClasses/<currentSCName>/ name <newSCName>` where `<currentSCName>` is the name of the storage class to change and `<newSCName>` is the name to change it to. ## Object Lock Support: WORM Propagation CTERA supports the seamless propagation of the portal cloud folder compliance settings to an S3 bucket, for all files in the cloud folder, extending protection from the application level through to the block-level on the storage. **Notes** CTERA recommends that whenever you create a new S3 bucket to use as the backend storage for a storage node, you enable object lock when creating the bucket and disable default retention. For most S3 buckets, after the bucket is populated with content, you cannot set object lock. With AWS S3 buckets, you can set object lock after the bucket is populated with content. **For CTERA Object Lock support, object lock must be enabled on the S3 bucket and the retention mode for the bucket must be disabled.** As long as the cloud folders that will write to the bucket have compliance set, as described in [Folder (WORM) Compliance: CTERA Vault](/v1/docs/folder-worm-compliance-ctera-vault-1), setting object lock on the S3 bucket ensures the following: - Files within dedicated WORM folders are immutable, preventing any modifications or deletions once written. - Retention settings are automatically propagated to the S3 bucket. - Customizable retention periods can be set for files within dedicated WORM folders. **Notes** Object locking is supported for S3 buckets with *governance* (*enterprise*) retention mode, both on-premise and in the cloud. S3 buckets with *compliance* retention mode only are **not** supported. The following storage nodes support object locking: Amazon (S3) and Hitachi Vantara HCP (S3). The following tables shows the different scenarios and their outcomes when setting **Use S3 Object Lock** on a storage node. ### **When *Use S3 Object Lock*** flag is checked for the storage node | Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes | | --- | --- | --- | --- | | Yes | No | Folder compliance is set on all objects written to the bucket | – | | Yes | Yes | Bucket cannot be accessed | Unset the bucket default retention policy | | No | – | Bucket cannot be accessed | Either uncheck **Use S3 Object Lock** for the storage node unless the storage node is **Amazon (S3)**, in which case, set the object lock on the bucket and disable default retention. | ### **When *Use S3 Object Lock*** flag is unchecked for the storage node | Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes | | --- | --- | --- | --- | | Yes | Yes | Bucket retention policy is applied to all the objects written to the bucket | – | | Yes | No | No bucket retention policy is applied to the objects written to the bucket | – | | No | – | No bucket retention policy is applied to the objects written to the bucket | – | ### **When *Use S3 Object Lock*** flag status changed for the storage node | Use S3 Object Lock setting | Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes | | --- | --- | --- | --- | --- | | **Checked** and then **unchecked** at a later date | Yes | No | All objects written before **Use S3 Object Lock** was unchecked keep their folder compliance settings. New writes are written to the bucket without a retention policy being applied. | – | | **Unchecked** and then **checked** at a later date | Yes | Yes | Bucket cannot be accessed | Either uncheck **Use S3 Object Lock** for the storage node or disable default retention. | | **Unchecked** and then **checked** at a later date | Yes | No | Retroactively apply the folder compliance settings on all the bucket objects. | – |