AIStor provides multiple replication strategies to ensure data availability, support disaster recovery, enable geographic distribution, and facilitate data migration between clusters. Each replication method serves different use cases and operates at different levels, from entire cluster to individual objects. Replication methods AIStor supports four distinct replication and synchronization approaches:

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.

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.

The AIStor Batch Framework allows you to create, manage, monitor, and execute jobs using a YAML-formatted job definition file (a “batch file”). The batch jobs run directly on the MinIO deployment to take advantage of the server-side processing power without constraints of the local machine where you run the MinIO Client. A batch file defines one job task. Once started, the AIStor server starts processing the batch job. Time to completion depends on the resources available to the deployment.

Each AIStor server process exposes unauthenticated endpoints for probing server uptime and deployment high availability for simple healthchecks. These endpoints return an HTTP status code indicating whether the underlying resource is healthy or satisfies read/write quorum. The server exposes no other data through these endpoints. AIStor liveness Use the following endpoint to test if the specified AIStor server is up and ready to serve requests:

AIStor provides tools for scaling your cluster capacity by adding or removing server pools. These tools allow you to expand storage capacity or retire aging hardware without disrupting ongoing operations. Planning for growth MinIO recommends initially sizing clusters for at least 2-3 years of anticipated data growth. This approach minimizes the frequency of expansion operations and simplifies long-term capacity management.

AIStor requires an active and unexpired MinIO Commercial License. Accessing your license The license is available in MinIO SUBNET. Log in to SUBNET. From the Deployments screen, select License Key. Select the copy button to the right of license key string.

This page summarizes how a DELETE operation affects objects depending on the configuration of the bucket that contains the object. Any combination of the following factors may impact how DELETE operations function: Bucket versioning Object locking rules Object Lifecycle Management rules Object tiering Site or bucket replication Scanner Permissions AIStor uses a policy based access control system for access management. The user or service account must provide the correct policy action and conditions to allow a DELETE for the bucket and object.

This page documents the steps necessary to remove a peer site from existing Site Replication configuration. Remove the peer site using AIStor Console In a browser, access the Console for one of the existing replicated sites.

The procedure on this page creates a new bucket replication rule for one-way synchronization of objects from one AIStor bucket to another AIStor bucket. The buckets can be on the same AIStor deployment or on separate AIStor deployments. Requirements Replication requires all participating clusters meet the bucket replication requirements. This procedure assumes you have reviewed and validated those requirements.