Upgrade

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.

Use the mc admin cluster bucket export commands to take a snapshot of the bucket metadata and IAM configurations prior to performing an upgrade. You can use these snapshots to restore settings to recover from user or process errors as necessary.

The Release Notes section provides a reference for identifying the changes applied in each release. Review the associated release notes between your current AIStor version and the newer release so you have a complete view of any changes.

Pay particular attention to any releases that are not backwards compatible. You cannot trivially downgrade from any such release.

AIStor uses a testing and validation suite as part of all releases. However, no testing suite can account for unique combinations and permutations of hardware, software, and workloads of your production environment.

You should always validate any AIStor upgrades in a lower environment (Dev/QA/Staging) before applying those upgrades to Production deployments, or any other environment containing critical data. Performing updates to production environments without first validating in lower environments is done at your own risk.

For AIStor deployments that are significantly behind latest stable (6+ months), consider using AIStor SUBNET for additional support and guidance during the upgrade procedure.

For deployments on Windows or macOS, you can upgrade the Server at any time by performing a binary replacement on the server and restarting the process.

For deployments in a container such as Podman or Docker, use the relevant pull command to retrieve the latest image and restart your container process. If you have pinned to a specific container image, replace that image with the latest release RELEASE.2025-06-27T22:30:56Z

System maintenance operations such hardware, firmware, or OS upgrades may require minutes or hours to complete during which all software running on that host is unavailable. For upgrade procedures that require longer periods of downtime, use a rolling upgrade pattern at the host level to take one or more systems offline at a time. AIStor erasure coding supports availability if one or more nodes require downtime during system maintenance.

The number of hosts you can safely take offline depends on the erasure code stripe and parity used for deploying the cluster. For example, consider a cluster with 8 servers and 8 drives each with a stripe size of 8 and parity of 3. As per the erasure code calculator, the cluster can tolerate up to 3 server failures while maintaining read and write quorum. Taking 2 nodes down at a time ensures a buffer of 1 additional node which could fail incidentally while maintaining cluster operations.

Certain architectures, such as rack-aware deployments, may support taking a larger number of hosts down for maintenance at once. Consult with MinIO support using SUBNET before conducting maintenance operations for additional oversight and guidance.

AIStor supports downgrading to previous versions, except where explicitly stated otherwise. Any features, improvements, or APIs not supported in the previous versions become unavailable upon downgrade. Take precautions to coordinate with any client applications before commiting to a downgrade operation.