minio/docs
1
0
Fork 0
mirror of https://github.com/minio/docs.git synced 2025-07-30 07:03:26 +03:00
Code Activity

DOCS-998: Tiering requires source and remote (#1008)

Browse Source 
Closes #998
This commit is contained in:
Ravind Kumar
2023-09-21 11:44:38 -04:00
committed by GitHub
parent 77f3074081
commit 535c1ed36b
2 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
source/administration/object-management/object-lifecycle-management.rst
View File

@ -58,6 +58,15 @@ The output includes the storage tier of each object:
- ``STANDARD`` marks objects stored on the MinIO deployment.
- ``WARM`` marks objects stored on the remote tier with matching name.
.. important::
MinIO Object Transition supports cost-saving strategies around moving older or aged data to cost-optimized remote storage tiers, such as cloud storage or high-density HDD storage.
MinIO Object Transition does **not** provide backup and recovery functionality.
You cannot use the remote tier as a recovery source in the event of data loss in MinIO.
Use either :ref:`site replication <minio-site-replication-overview>` or :ref:`bucket replication <minio-bucket-replication>` to support backup/recovery or :abbr:`BC/DR (Business Continuity / Disaster Recovery)` requirements.
Exclusive Access to Remote Data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

25
source/includes/common-minio-tiering.rst
View File

@ -87,24 +87,25 @@ complete documentation on MinIO users and policies respectively.
.. start-transition-bucket-access-desc
MinIO *requires* exclusive access to the transitioned data on the remote storage
tier. MinIO ignores any objects in the remote bucket or bucket prefix not
explicitly managed by the MinIO deployment. Automatic transition and transparent
object retrieval depend on the following assumptions:
MinIO *requires* exclusive access to the transitioned data on the remote storage tier.
Object metadata on the "hot" MinIO source is strongly linked to the object data on the "warm/cold" remote tier.
MinIO cannot retrieve object data without access to the remote, nor can the remote be used to restore lost metadata on the source.
All access to the transitioned objects *must* occur through MinIO via S3 API operations only.
Manually modifying a transitioned object - whether the metadata on the "hot" MinIO tier *or* the object data on the remote "warm/cold" tier - may result in loss of that object data.
MinIO ignores any objects in the remote bucket or bucket prefix not explicitly managed by the MinIO deployment.
Automatic transition and transparent object retrieval depend on the following assumptions:
- No external mutation, migration, or deletion of objects on the remote storage.
- No lifecycle management rules (e.g. transition or expiration) on the remote
storage bucket.
MinIO stores all transitioned objects in the remote storage bucket or resource
under a unique per-deployment prefix value. This value is not intended to
support identifying the source deployment from the backend. MinIO supports an
additional optional human-readable prefix when configuring the remote target,
which may facilitate operations related to diagnostics, maintenance, or disaster
recovery.
MinIO stores all transitioned objects in the remote storage bucket or resource under a unique per-deployment prefix value.
This value is not intended to support identifying the source deployment from the backend.
MinIO supports an additional optional human-readable prefix when configuring the remote target, which may facilitate operations related to diagnostics, maintenance, or disaster recovery.
MinIO recommends specifying this optional prefix for remote storage tiers which
contain other data, including transitioned objects from other MinIO deployments.
MinIO recommends specifying this optional prefix for remote storage tiers which contain other data, including transitioned objects from other MinIO deployments.
This tutorial includes the necessary syntax for setting this prefix.
.. end-transition-bucket-access-desc