The following section documents environment variables and configuration settings for customizing AIStor’s global audit event queue. These settings control all configured audit targets. Settings Audit Event Queue Dir Environment Variable MINIO_AUDIT_QUEUE_DIR Configuration Setting audit_event_queue dir Specify the directory path to enable AIStor’s persistent event store for undelivered messages, such as /opt/minio/audit/events.

The mc retention info command configures the Write-Once Read-Many (WORM) locking settings for an object or object(s) in a bucket. You can also set the default object lock settings for a bucket, where all objects without explicit object lock settings inherit the bucket default. To lock an object under legal hold, use mc legalhold set. mc retention info requires that the specified bucket has object locking enabled. You can enable object locking at bucket creation. See mc mb --with-lock for documentation on creating buckets with object locking enabled.

The mc support inspect command collects the data and metadata associated to objects at the specified path. If this information is required to diagnose a SUBNET issue, AIStor Engineering will provide the appropriate command. AIStor assembles this data from each backend drive storing an erasure shard for each specified object. For registered clusters, the file uploads to AIStor for use by the engineering team in support efforts. The command produces an encrypted zip file that includes all matching files with their respective host+drive+path. When writing the zip archive, AIStor also encrypts the zip index of file names included in the archive. The resulting report is intended for use by AIStor Engineering via SUBNET and may contain internal or private data points associated to the object. Exercise caution before sending a report to a third party or posting the report in a public forum.

Version changed Beginning with AIStor Client RELEASE.2025-08-21T03-14-05Z, this command returns S3 call information gathered during the last minute. Previously, the command returned information about in-progress S3 API calls gathered from mc admin trace. The mc support top api command outputs the last minute of S3 API events on an AIStor server in real-time. The output is a high level summary of these calls. For more in-depth tracing, use mc admin trace.

The mc support callhome command allows the enabling or disabling of sending diagnostic reports from a deployment to SUBNET. With Call Home, AIStor automatically sends a deployment’s diagnostic information to SUBNET. This makes it easier and quicker for the AIStor team to respond to questions and issues. AIStor enables this functionality by default for registered clusters. If you prefer not to automatically send these reports to SUBNET, you may disable callhome.

AIStor automatically creates remote targets based on a given file path or resource location (such as an IP or DNS address). Users defining a remote target no longer need to determine an ARN for the remote bucket. The mc replicate add command creates a new server-side replication rule for a bucket on an AIStor deployment. The remote bucket must be on an AIStor deployment running the same version of AIStor as the local 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.

The mc replicate export command exports the JSON-formatted replication rules for an AIStor bucket to STDOUT. Syntax Example The following command exports the replication configuration for the mydata bucket on the myaistor AIStor deployment:

This section documents best practices and tutorials for updating the AIStor server on Linux and Kubernetes infrastructure to a newer release. All AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds. Applications using MinIO or S3 SDKs can rely on the built-in transparent retry to ensure continuous operations during the update procedure.

AIStor supports scaling deployments by expanding or decomissioning server pools. Ideally, deployments should plan for 3 years of data growth at installation.