The mc support top disk command displays current drive statistics. Syntax Example The following command displays the current disk usage and performance on the alias myaistor.

The mc qos rule remove command removes one or more Quality of Service (QoS) rules from an AIStor deployment. The command can also be invoked with the short name rm. For more information, see Bucket-level Quality of Service. Syntax Example The following command removes the QoS rule with ID rule1 from the mybucket bucket on the myaistor deployment:

The mc replicate backlog shows a list of unreplicated new or deleted objects. You can list the replication status of objects for a particular remote target. To do so, you must have the ARN of the remote target. You can mc replicate ls and mc replicate status to retrieve the remote targets configured for a bucket and find the ARN. Syntax Example The following command shows new or deleted objects in the notes bucket of the teamorange/projects prefix on the myaistor alias that have not yet replicated to a specific remote target bucket. The remote target’s ARN is arn:minio:replication::3bb8c736-4014-42c5-b3cb-d64e3ebaa75e:notes.

This page describes how to enable FIPS 140-3 ready cryptography for AIStor deployments on Kubernetes. When enabled, FIPS mode restricts cryptographic operations to algorithms that align with the Federal Information Processing Standards (FIPS) 140-3 program. Organizations subject to U.S. federal government compliance requirements, or those with similar regulatory needs, may require FIPS-aligned cryptography. AIStor FIPS mode uses Go’s native cryptographic module, which restricts operations to FIPS 140-3 approved algorithms. MinIO makes no statements or representations regarding FIPS 140-3 certification status. Evaluate whether this implementation meets your specific compliance requirements. Overview AIStor uses Go 1.24’s native FIPS 140-3 cryptographic module. Enable FIPS mode at runtime with the GODEBUG environment variable. There is no separate binary required.

Configure load balancers and Ingress controllers for AIStor on Kubernetes. Includes examples for NGINX, HAProxy, and Traefik.

The procedure on this page creates a new object lifecycle management rule that transitions objects from a bucket on a primary AIStor deployment to a bucket on a remote AIStor deployment. This procedure supports cost-management strategies such as tiering objects from a “hot” AIStor deployment using NVMe storage to a “warm” AIStor deployment using SSD. Requirements Install and configure mc This procedure uses mc for performing operations on the AIStor cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests. You must set up TLS before you can enable data encryption, also called server-side encryption. AIStor supports the following types of certificate signatures: self-signed internal or private certificate authorities (CAs) third-party CAs Multiple certificates are implemented with SNI to determine which certificate to return to a client based on the hostname in the request.

This procedure downloads and installs the AIStor Server onto bare-metal hosts running Red Hat Enterprise Linux Review the Hardware and System Requirements to ensure your target infrastructure meets our guidance. You can also open a SUBNET issue to request an architecture review or assistance during deployment. MinIO strongly recommends using only RHEL releases in the Full Support lifecycle with Long-Term Support (LTS) Kernels in the 6.12 or later release series, such as RHEL 10. See Linux Kernel Requirements for recommended distributions and performance details.

This procedure provides guidance for enabling Server-Side Encryption (SSE) using MinIO KMS as the Key Management Service (KMS). Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key selected during the setup process.

This tutorial shows how to setup a KES server that uses a Thales CipherTrust Manager instance (formerly known as Gemalto KeySecure) as a persistent and secure key store. K E S C l i e n t K E S S e r v e r C i p h e r T r u s t M a n a g e r This guide assumes that you have a running CipherTrust Manager instance. It has been tested with CipherTrust Manager k170v version 2.0.0 and Gemalto KeySecure k170v version 1.9.1 and 1.10.0.