Overview This reference provides complete documentation for inventory job configuration. Inventory jobs use YAML configuration files that define what objects to include, what metadata to report, how often to run, and where to store generated reports. The configuration file contains top-level fields that control job behavior, destination settings for output location and format, optional fields for including additional metadata, and filters for selecting specific objects. All configuration files must specify apiVersion, id, and destination as required fields.

The mc admin accesskey create command adds a new access key and secret key pair for an existing AIStor user. Syntax Example The following command creates a new access key associated to an existing AIStor user:

AIStor supports publishing bucket notification events to a MySQL service endpoint. AIStor supports MySQL 5.7.8 and later only. Prerequisites MySQL 5.7.8 and later AIStor relies on features introduced with MySQL 5.7.8. The AIStor mc command line tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions.

The AIStor Console is a rich graphical user interface that provides similar functionality to the mc command line tool. This page provides an overview of the AIStor Console and describes configuration options and instructions for logging in. Overview You can use the AIStor Console for administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration.

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 deploys AIStor onto Kubernetes distributions that follow the upstream API and functionality. The steps in this procedure may work on forked Kubernetes distributions. This procedure requires the installation of Kubernetes operators and associated resources including CustomResourceDefinitions, StatefulSets, and Secrets into new or existing Namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple Namespaces. Deploy AIStor using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts. MinIO recommends Helm version 3.17 or later.

Object tiering is the moving of the data of an object from one set of hardware to another set of hardware. This is often done as a cost-saving measure, keeping more expensive and performant hardware for the newest or most accessed objects while placing other objects to less expensive and less performant storage solutions. Retrieve a tiered object When AIStor moves an object to another tier, the object’s metadata remains on the primary tier while the object’s data moves to the secondary tier. When AIStor needs to serve a tiered object, it transparently retrieves the object from the secondary tier.

AIStor server-side bucket replication is an automatic bucket-level configuration that synchronizes objects between a source and destination bucket. AIStor server-side replication requires the source and destination bucket be two separate AIStor clusters running the same Object Store version. For each write operation to the bucket, AIStor checks all configured replication rules for the bucket and applies the matching rule with highest configured priority. AIStor synchronizes new objects and object mutations, such as new object versions or changes to object metadata. This includes metadata operations such as enabling or modifying object locking or retention settings.

This page documents the steps necessary to initialize site replication between two AIStor deployments. The procedures assume at least two existing AIStor installations. Only one of the two sites can have any data at the time of setup. All other sites must be empty of buckets and objects. All sites must otherwise having the following matching configurations: AIStor Server version Key Management Server for Server-Side Encryption Identity Manager Ensure each peer site has a Load Balancer, Reverse Proxy, or similar network control plane component to handle routing connections to its AIStor Server nodes. Using a single node hostname for a peer site creates a single point of failure for site replication where replication can fail if that single node goes down.

Configure batch expiration jobs to immediately expire objects by prefix, age, size, tags, or metadata. Faster than lifecycle rules for bulk cleanup.