Add concept pages for Scanner and Healing (#1192)

Adds concept pages for healing and the scanner.
Updates other related files for better context.
    
Adds ref links and other related updates.
    
Closes #1168

source/administration/monitoring/bucket-notifications.rst

@@ -186,15 +186,15 @@ Specify the wildcard ``*`` character to select all events related to a prefix:
 Scanner Events
 ~~~~~~~~~~~~~~
 
-MinIO supports triggering notifications on the following S3 scanner transition events:
+MinIO supports triggering notifications on the following S3 :ref:`scanner <minio-concepts-scanner>` transition events:
 
 .. data:: s3:Scanner:ManyVersions
 
-   Scanner finds objects with more than 1,000 versions.
+   :ref:`Scanner <minio-concepts-scanner>` finds objects with more than 1,000 versions.
 
 .. data:: s3:Scanner:BigPrefix
 
-   Scanner finds prefixes with more than 50,000 sub-folders.
+   :ref:`Scanner <minio-concepts-scanner>` finds prefixes with more than 50,000 sub-folders.
 
 Global Events
 ~~~~~~~~~~~~~

source/administration/object-management/object-lifecycle-management.rst

@@ -127,22 +127,11 @@ MinIO has two specific default behaviors for versioned buckets:
 Lifecycle Management Object Scanner
 -----------------------------------
 
-MinIO uses a built-in scanner to actively check objects against all configured lifecycle management rules. 
+MinIO uses a built-in :ref:`scanner <minio-concepts-scanner>` to actively check objects against all configured lifecycle management rules. 
+
 The scanner is a low-priority process that yields to high :abbr:`I/O (Input / Output)` workloads to prevent performance spikes triggered by rule timing. 
 The scanner may therefore not detect an object as eligible for a configured transition or expiration lifecycle rule until *after* the lifecycle rule period has passed.
 
-Scanner performance typically depends on the available node resources, the size of the cluster, and the complexity of bucket hierarchy (objects and prefixes).
-For example, a cluster that starts with 100TB of data that then grows to 200TB of data may require more time to scan the entire namespace of buckets and objects given the same hardware and workload.
-As the cluster or workload increases, scanner performance decreases as it yields more frequently to ensure priority of normal S3 operations.
-
-.. include:: /includes/common/scanner.rst
-   :start-after: start-scanner-speed-config
-   :end-before: end-scanner-speed-config
-
-Consider regularly checking cluster metrics, capacity, and resource usage to ensure the cluster hardware is scaling alongside cluster and workload growth:
-
-- :ref:`minio-metrics-and-alerts`
-
 .. toctree::
    :hidden:
 

source/administration/object-management/transition-objects-to-gcs.rst

@@ -89,7 +89,7 @@ Considerations
 Lifecycle Management Object Scanner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MinIO uses a scanner process to check objects against all configured
+MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
 lifecycle management rules. Slow scanning due to high IO workloads or
 limited system resources may delay application of lifecycle management
 rules. See :ref:`minio-lifecycle-management-scanner` for more information.

source/administration/object-management/transition-objects-to-minio.rst

@@ -91,10 +91,9 @@ Considerations
 Lifecycle Management Object Scanner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MinIO uses a scanner process to check objects against all configured
+MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
 lifecycle management rules. Slow scanning due to high IO workloads or
-limited system resources may delay application of lifecycle management
-rules. See :ref:`minio-lifecycle-management-scanner` for more information.
+limited system resources may delay application of lifecycle management rules.
 
 Exclusive Access to Remote Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

source/administration/object-management/transition-objects-to-s3.rst

@@ -95,7 +95,7 @@ Considerations
 Lifecycle Management Object Scanner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MinIO uses a scanner process to check objects against all configured
+MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
 lifecycle management rules. Slow scanning due to high IO workloads or
 limited system resources may delay application of lifecycle management
 rules. See :ref:`minio-lifecycle-management-scanner` for more information.

source/glossary.rst

@@ -40,7 +40,7 @@ Glossary
      MinIO combats bit rot with :term:`hashing` and :term:`erasure coding`.
 
    bit rot healing
-     Objects corrupted due to bit rot automatically restore to a healed state at time of read.
+     Objects corrupted due to bit rot are automatically :term:`healed <healing>` during any ``GET`` or ``HEAD`` operation.
      MinIO captures and heals corrupted objects on the fly with its :term:`hashing` implementation.
 
    bucket
@@ -223,7 +223,10 @@ Glossary
      
      - lifecycle management rules requiring object transition
      - bucket or site replication status
-     - object :term:`bit rot` and healing
+     - object :term:`bit rot` and :term:`healing`
+     - usage data
+
+     For more, see :ref:`minio-concepts-scanner`.
 
    self signed certificates
      A self-signed certificate is one created by, issued by, and signed by the company or developer responsible for the content the certificate secures.

source/includes/common/scanner.rst

@@ -7,7 +7,7 @@ You can adjust how MinIO balances the scanner performance with read/write operat
 
 .. start-scanner-speed-values
 
-MinIO utilizes the scanner for :ref:`bucket replication <minio-bucket-replication>`, :ref:`site replication <minio-site-replication-overview>`, and :ref:`lifecycle management <minio-lifecycle-management>` tasks.
+MinIO utilizes the :ref:`scanner <minio-concepts-scanner>` for :ref:`bucket replication <minio-bucket-replication>`, :ref:`site replication <minio-site-replication-overview>`, :ref:`lifecycle management <minio-lifecycle-management>`, and :ref:`healing <minio-concepts-healing>` tasks.
 
 Valid values include:
 

source/operations/concepts.rst

@@ -166,7 +166,7 @@ MinIO Uses :ref:`Erasure Coding <minio-erasure-coding>` for Data Redundancy and
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 MinIO Erasure Coding is a data redundancy and availability feature that allows MinIO deployments with multiple drives to automatically reconstruct objects on-the-fly despite the loss of multiple drives or nodes in the cluster. 
-Erasure Coding provides object-level healing with significantly less overhead than adjacent technologies such as RAID or replication.
+Erasure Coding provides object-level :ref:`healing <minio-concepts-healing>` with significantly less overhead than adjacent technologies such as RAID or replication.
 
 
 MinIO Implements Bit Rot Healing to Protect Data At Rest
@@ -186,7 +186,14 @@ Some common reasons for bit rot include:
 - accidental overwrites
 
 MinIO uses a hashing algorithm to confirm the integrity of an object.
-If an object becomes corrupted by bit rot, MinIO can automatically heals the object depending on the system topology and availability.
+This algorithm automatically applies at the time of any ``GET`` and ``HEAD`` operations for an object.
+For objects in a versioned bucket, a ``PUT`` operation can also trigger healing if MinIO identifies version inconsistencies.
+If an object becomes corrupted by bit rot, MinIO can automatically :ref:`heal <minio-concepts-healing>` the object depending on the availability of parity shards for the object.
+
+MinIO can also perform bit rot checks and healing using the :ref:`MinIO Scanner <minio-concepts-scanner>`.
+However, scanner bit rot checking is **off** by default.
+Active bit rot healing during scanner has a high performance impact in comparison to the low probability of bit rot affecting multiple object shards distributed across multiple drives and nodes.
+The automatic checks during normal operations is generally sufficient for bit rot, and MinIO does not recommend using the scanner for this type of health check.
 
 MinIO Distributes Data Across :ref:`Erasure Sets <minio-ec-erasure-set>` for High Availability and Resiliency
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -203,7 +210,7 @@ MinIO calculates the size and number of Erasure Sets in a Server Pool based on t
 MinIO Automatically Heals Corrupt or Missing Data On-the-fly
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Healing is MinIO's ability to restore data after some event causes data loss.
+:ref:`Healing <minio-concepts-healing>` is MinIO's ability to restore data after some event causes data loss.
 Data loss can come from bit rot, drive loss, or node loss.
 
 :ref:`Erasure coding <minio-erasure-coding>` provides continued read and write access if an object has been partially lost.

source/operations/concepts/architecture.rst

@@ -52,7 +52,7 @@ MinIO automatically groups drives in the pool into :ref:`erasure sets <minio-ec-
    MinIO stripes erasure sets symmetrically across the nodes in the pool to maintain even distribution of erasure set drives.
    MinIO then partitions objects into data and parity shards based on the deployment :ref:`parity <minio-ec-parity>` and distributes them across an erasure set.
 
-   For a more complete discussion of MinIO redundancy and healing, see :ref:`minio-erasure-coding`.
+   For a more complete discussion of MinIO redundancy and healing, see :ref:`minio-erasure-coding` and :ref:`minio-concepts-healing`.
 
    .. figure:: /images/architecture/architecture-erasure-set-shard.svg
       :figwidth: 100%

source/operations/concepts/availability-and-resiliency.rst

@@ -176,7 +176,7 @@ MinIO implements :ref:`site replication <minio-site-replication-overview>` as th
       Each peer site is deployed to an independent datacenter to provide protection from large-scale failure or disaster.
       If one datacenter goes completely offline, clients can fail over to the other site.
 
-MinIO replication can automatically heal a site that has partial or total data loss due to transient or sustained downtime. 
+MinIO replication can automatically :ref:`heal <minio-concepts-healing>` a site that has partial or total data loss due to transient or sustained downtime. 
    .. figure:: /images/availability/availability-multi-site-healing.svg
       :figwidth: 100%
       :alt: Diagram of a multi-site deployment while healing

source/operations/concepts/erasure-coding.rst

@@ -113,7 +113,7 @@ If Parity ``EC:M`` is exactly 1/2 the erasure set size, **write quorum** is ``K+
 
    The ``K+1`` logic ensures that a client could not potentially write the same object twice - once to each "half" of the erasure set.
 
-For an object maintaining **read quorum**, MinIO can use any data or parity shard to heal damaged shards.
+For an object maintaining **read quorum**, MinIO can use any data or parity shard to :ref:`heal <minio-concepts-healing>` damaged shards.
    .. figure:: /images/erasure/erasure-coding-shard-healing.svg
       :figwidth: 100%
       :align: center
@@ -169,8 +169,10 @@ The following table lists the outcome of varying erasure code parity levels on a
      - 8
      - 9
 
-Bitrot Protection
------------------
+.. _minio-ec-bitrot:
+
+Bit Rot Protection
+------------------
 
 `Bit rot <https://en.wikipedia.org/wiki/Data_degradation>`__ is silent data corruption from random changes at the storage media level.
 For data drives, it is typically the result of decay of the electrical charge or magnetic orientation that represents the data.

source/operations/concepts/healing.rst

@@ -0,0 +1,116 @@
+.. _minio-concepts-healing:
+
+==============
+Object Healing
+==============
+
+.. default-domain:: minio
+
+.. contents:: Table of Contents
+   :local:
+   :depth: 1
+
+What is healing?
+----------------
+
+Healing is MinIO's ability to restore an object that has been damaged, corrupted, or partially lost.
+The loss can come from multiple types of corruptions or loss, such as but not limited to:
+
+- drive-level errors or failure
+- OS or filesystem errors or failure
+- :ref:`bit rot <minio-ec-bitrot>`
+
+Healing and Erasure Coding
+--------------------------
+
+The ability of MinIO to restore a damaged object relates directly to the following:
+
+- total number of drives in the :ref:`erasure set <minio-erasure-coding>` where the object exists
+- number of drives available with intact parts of the object
+- :ref:`parity setting <minio-ec-parity>` for the erasure set
+
+  :term:`Parity` refers to the number of dedicated recovery shards MinIO creates when writing the object.
+  For example, an erasure set may have eight total drives and use three drives during a write for parity.
+  In this scenario, MinIO splits an object into 5 data shards and create 3 parity shards.
+  MinIO distributes these eight shards across the drives in the erasure set.
+  No one drive contains only parity shards or only data shards.
+  Instead, MinIO writes shards for each object in a randomized way to distribute reads evenly across drives.
+
+  When MinIO needs to provide the object, it looks for the data shards for the object.
+  If any of the data shards are missing or damaged, MinIO uses one or more of the parity shards to restore the object.
+  WHen looking for the parity shards, if any of the parity shards are missing or damaged, MinIO restores those as well, provided there are sufficient other shards to serve the object.
+  For this scenario, up to three of data shard parts can be lost or damaged and MinIO can still successfully restore and serve the object. 
+
+  The number of drives available with intact data or parity shards of the object must meet or exceed the number of drives used for data shards in the erasure set.
+  In the scenario above, five drives with intact shards must be online and available for MinIO to successfully serve the object.
+
+When does MinIO heal an object?
+-------------------------------
+
+MinIO has a robust system for healing objects.
+
+Healing during ``GET`` requests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+MinIO automatically checks the consistency of an object's data shards each time you request an object with a ``GET`` or ``HEAD`` operation.
+For versioned buckets, MinIO also checks for consistency during ``PUT`` operation.
+
+If all of the data shards are found intact, MinIO serves the object from the data shards without inspecting the corresponding parity shards.
+
+If the object has missing or damaged data shards, MinIO uses the available parity shards to heal the object before serving it as part of the operation.
+There **must** be an intact parity shard available for each lost or damaged data shard, otherwise the object cannot be recovered.
+If any parity shards are lost or damaged, MinIO restores the parity shard, provided there are sufficient other parity shards to serve the object.
+
+Healing with the object scanner
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+MinIO uses an :ref:`object scanner <minio-concepts-scanner>` to perform a number of tasks related to objects.
+One of these tasks checks the integrity of objects and, if found damaged or corrupted, heals them.
+
+On each scanning pass, MinIO uses a hash of the object name to select one out of every 1,024 objects to check.
+
+If any object is found to have lost shards, MinIO heals the object from available shards.
+By default, MinIO does *not* check for :term:`bit rot` corruption using the scanner.
+This can be an expensive operation to perform and the risk of bit rot across multiple disks is low.
+
+Healing by manual request
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Administrators can use :mc:`mc admin heal` to initiate a full system healing.
+The procedure is very resource intensive and not typically needed.
+
+Consult with MinIO Engineers before manually starting a healing process on a deployment.
+
+Healing metrics
+---------------
+
+MinIO provides several `healing metrics <https://min.io/docs/minio/linux/operations/monitoring/metrics-and-alerts.html#healing-metrics>`__ to monitor the status of healing processes on a deployment.
+
+Refer to the :ref:`minio-metrics-and-alerts` for more information on available endpoints and configuration.
+
+.. _minio-concepts-healing-colors:
+
+Healing Output Color Key
+------------------------
+
+Earlier MinIO versions generated a table with green, yellow, red, and gray colors to indicate the healing status of individual objects.
+These colors have been deprecated in favor of more detailed :ref:`healing metrics available at the cluster level <minio-metrics-and-alerts-available-metrics>`.
+
+The following table describes the meaning of the now-deprecated status colors.
+
+.. list-table::
+   :widths: 25 75
+   :width: 100%
+
+   * - **Green**
+     - *Healthy*, the object has all data and parity shards available as required to serve the object
+ 
+   * - **Yellow** 
+     - *Healing*, the object is still in the process of healing, and there are sufficient data or parity shards available to complete the healing
+
+   * - **Red** 
+     - *Unhealthy*, the object has lost one or more shards and requires healing
+
+   * - **Grey** 
+     -  *Unrecoverable*, the object has lost too many data and/or parity shards and cannot be healed or recovered
+

source/operations/concepts/scanner.rst

@@ -0,0 +1,105 @@
+.. _minio-concepts-scanner:
+
+==============
+Object Scanner
+==============
+
+.. default-domain:: minio
+
+.. contents:: Table of Contents
+   :local:
+   :depth: 1
+
+Overview
+--------
+
+MinIO uses the built-in scanner to check objects for healing and to take any scheduled object actions.
+Such actions may include:
+
+- calculate data usage on drives
+- evaluate and apply configured :ref:`lifecycle management <minio-lifecycle-management>` or :ref:`object retention <minio-object-retention>` rules
+- perform :ref:`bucket <minio-bucket-replication>` or :ref:`site <minio-site-replication-overview>` replication
+- check objects for missing or corrupted data or parity shards and perform :ref:`healing <minio-concepts-healing>`
+
+The scanner performs these functions at two levels: cluster and bucket.
+At the cluster level, the scanner splits all buckets into groups and scans one group of buckets at a time.
+The scanner starts with any new buckets added since the last scan, then randomizes the scanning of other buckets.
+The scanner completes checks on all bucket groups before starting over with a new set of scans.
+
+At the bucket level, the scanner groups items in buckets and scans selected items from that bucket.
+The scanner selects objects for a scan based on a hash of the object name.
+Over a span of 16 scans, MinIO checks every object in the namespace.
+MinIO fully scans any prefixes known to be new since the last scan.
+
+Scan Length
+-----------
+
+Multiple factors impact the time it takes for a scan to complete.
+
+Some of these factors include:
+
+- Type of drives provided to MinIO
+- Throughput and :abbr:`iops (input/output operations per second)` available
+- Number and size of objects
+- Other activity on the MinIO Server
+
+For example, by default, MinIO pauses the scanner to make I/O operations available for read and write requests.
+This can lengthen the time it takes for a scan to complete.
+
+MinIO waits between each scan by a factor multiplication of the time it takes each scan operation to complete.
+By default, the value of this factor is ``10.0``, meaning MinIO waits 10x the length of an operation after one scan completes before starting the next scan.
+The value of this factor changes depending on the configured :ref:`scanner speed setting <minio-scanner-speed-options>`. 
+
+Scanner Performance
+-------------------
+
+Many factors impact the scanner performance.
+Some of these factors include:
+
+- available node resources
+- size of the cluster
+- number of erasure sets compared to the number of drives
+- complexity of bucket hierarchy (objects and prefixes).
+
+For example, a cluster that starts with 100TB of data and then grows to 200TB of data may require more time to scan the entire namespace of buckets and objects given the same hardware and workload.
+Likewise, a single erasure set of 16 drives takes longer to scan than the same number of drives split into two erasure sets of 8 drives each.
+
+MinIO treats the scanner as a background task and pauses it in favor of completing read and write requests on the cluster.
+As the cluster or workload increases, scanner performance decreases as it yields more frequently to ensure priority of normal S3 operations.
+
+.. include:: /includes/common/scanner.rst
+   :start-after: start-scanner-speed-config
+   :end-before: end-scanner-speed-config
+
+Scanner Metrics
+---------------
+
+MinIO provides a number of `metrics related to the scanner <https://min.io/docs/minio/linux/operations/monitoring/metrics-and-alerts.html#scanner-metrics>`__.
+
+Use ``mc admin scanner info`` to see the current status of the scanner and the time since the last full scan.
+This can help in understanding the metrics provided by the scanner operation.
+
+Scanner metrics, including usage metrics, reflect the last completed scan. 
+``PUT`` or ``DELETE`` operations since the last scan do not update in the usage until the next scan of the affected bucket(s).
+
+
+The output resembles the following:
+
+.. code-block::
+
+   Overall Statistics                                                                              
+   ------------------                                                                              
+   Last full scan time:   0d0h14m; Estimated 2885.28/month                                         
+   Current cycle:         70464; Started: 2024-04-19 20:02:34.568479139 +0000 UTC                  
+   Active drives:         2                                                                        
+                                                                                                   
+   Last Minute Statistics                                                                          
+   ----------------------                                                                          
+   Objects Scanned:       620 objects; Avg: 124.929µs; Rate: 892800/day                            
+   Versions Scanned:      620 versions; Avg: 2.801µs; Rate: 892800/day                             
+   Versions Heal Checked: 0 versions; Avg: 0ms                                                     
+   Read Metadata:         621 objects; Avg: 88.416µs, Size:
+   ILM checks:            656 versions; Avg: 663ns                        	
+   Check Replication:     656 versions; Avg: 1.061µs                      	
+   Verify Deleted:        0 folders; Avg: 0ms                             	
+   Yield:                 3.086s total; Avg: 4.705ms/obj   

source/operations/data-recovery.rst

@@ -31,7 +31,7 @@ and links to procedures for recovering from each:
      - MinIO supports hot-swapping failed drives with new healthy drives. 
 
    * - :ref:`Node Failure <minio-restore-hardware-failure-node>`
-     - MinIO detects when a node rejoins the deployment and begins proactively healing the node shortly after it is joined back to the cluster healing data previously stored on that node.
+     - MinIO detects when a node rejoins the deployment and begins proactively :ref:`healing <minio-concepts-healing>` the node shortly after it is joined back to the cluster healing data previously stored on that node.
 
    * - :ref:`Site Failure <minio-restore-hardware-failure-site>`
      - MinIO Site Replication supports complete resynchronization of buckets, objects, and replication-eligible configuration settings after total site loss.

source/operations/data-recovery/recover-after-drive-failure.rst

@@ -10,21 +10,18 @@ Drive Failure Recovery
    :local:
    :depth: 1
 
-MinIO supports hot-swapping failed drives with new healthy drives. MinIO detects
-and heals those drives without requiring any node or deployment-level restart.
-MinIO healing occurs only on the replaced drive(s) and does not typically impact
-deployment performance.
+MinIO supports hot-swapping failed drives with new healthy drives. 
+MinIO detects and heals those drives without requiring any node or deployment-level restart.
+:ref:`MinIO healing <minio-concepts-healing>` occurs only on the replaced drive(s) and in most cases has minimal or negligible impact on deployment performance.
 
-MinIO healing ensures consistency and correctness of all data restored onto the drive.
+MinIO healing ensures consistency and correctness of all data restored onto the drive. 
 
 .. include:: /includes/common-admonitions.rst
    :start-after: start-exclusive-drive-access
    :end-before: end-exclusive-drive-access
 
 The following steps provide a more detailed walkthrough of drive replacement.
-These steps assume a MinIO deployment where each node manages drives using
-``/etc/fstab`` with per-drive labels as per the
-:ref:`documented prerequisites <minio-installation>`.
+These steps assume a MinIO deployment where each node manages drives using ``/etc/fstab`` with per-drive labels as per the :ref:`documented prerequisites <minio-installation>`.
 
 1) Unmount the failed drive(s)
 ------------------------------
@@ -119,7 +116,7 @@ Use :mc:`mc admin console` command *or* ``journalctl -u minio`` for
 remounting drives. The output should include messages identifying each formatted
 and empty drive.
 
-Use :mc:`mc admin heal` to monitor the overall healing status on the
+Use :mc:`mc admin heal` to monitor the overall :ref:`healing <minio-concepts-healing>` status on the
 deployment. MinIO aggressively heals replaced drive(s) to ensure rapid recovery
 from the degraded state.
 

source/operations/data-recovery/recover-after-node-failure.rst

@@ -11,7 +11,7 @@ Node Failure Recovery
    :depth: 1
 
 If a MinIO node suffers complete hardware failure (e.g. loss of all drives,
-data, etc.), the node begins healing operations once it rejoins the deployment.
+data, etc.), the node begins :ref:`healing operations <minio-concepts-healing>` once it rejoins the deployment.
 MinIO healing occurs only on the replaced hardware and does not typically impact
 deployment performance.
 
@@ -77,7 +77,7 @@ using :mc:`mc admin console` or by monitoring the MinIO service logs
 using ``journalctl -u minio`` for ``systemd`` managed installations.
 
 The server output should indicate that it has detected the other nodes
-in the deployment and begun healing operations.
+in the deployment and begun :ref:`healing operations <minio-concepts-healing>`.
 
 Use :mc:`mc admin heal` to monitor overall healing status on the
 deployment. MinIO aggressively heals the node to ensure rapid recovery

source/operations/data-recovery/recover-after-site-failure.rst

@@ -132,7 +132,7 @@ Passive Bucket Replication Resynchronization
 
 As a passive process, bucket replication may not perform as quickly as desired for a site recovery scenario.
 
-Using bucket replication relies on the standard replication scanner queue, which does not take priority over other processes.
+Bucket replication relies on the standard replication :ref:`scanner <minio-concepts-scanner>` queue, which does not take priority over other processes.
 For recovery procedures with stricter SLA/SLO, use the active bucket replication process with :mc:`mc replicate resync` command as described above.
 
 Bucket replication rules copy the object, its version ID, versions, and other metadata to the target bucket.

source/operations/install-deploy-manage/multi-site-replication.rst

@@ -97,7 +97,7 @@ Any MinIO deployment in the site replication configuration can resynchronize dam
    Site replication operations retry up to three (3) times.
    
    MinIO dequeues replication operations that fail to replicate after three attempts.
-   The scanner can pick up those affected objects at a later time and requeue them for replication.
+   The :ref:`scanner <minio-concepts-scanner>` picks up those affected objects at a later time and requeues them for replication.
 
 .. versionchanged:: RELEASE.2022-08-11T04-37-28Z
 
@@ -107,7 +107,7 @@ Any MinIO deployment in the site replication configuration can resynchronize dam
 .. versionchanged:: RELEASE.2022-12-02T23-48-47Z
 
    If one site loses data for any reason, resynchronize the data from another healthy site with :mc-cmd:`mc admin replicate resync`.
-   This launches an active process that resynchronizes the data without waiting for the passive MinIO scanner to recognize the missing data.
+   This launches an active process that resynchronizes the data without waiting for the passive :ref:`MinIO scanner <minio-concepts-scanner>` to recognize the missing data.
 
 .. include:: /includes/common/scanner.rst
    :start-after: start-scanner-speed-config

source/reference/deprecated/mc-ilm-add.rst

@@ -122,7 +122,7 @@ Parameters
    For versioned buckets, the expiry rule applies only to the *current* object version. 
    Use the :mc-cmd:`~mc ilm add --noncurrent-expire-days` option to apply expiration behavior to noncurrent object versions.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -143,7 +143,7 @@ Parameters
    - :mc-cmd:`~mc ilm add --tags`
    - :mc-cmd:`~mc ilm add --expire-days`
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -162,7 +162,7 @@ Parameters
 
    Requires specifying :mc-cmd:`~mc ilm add --transition-tier`.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -184,7 +184,7 @@ Parameters
 
    This option has the same behavior as the S3 ``NoncurrentVersionExpiration`` action.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -199,7 +199,7 @@ Parameters
 
    This option has the same behavior as the S3 ``NoncurrentVersionTransition`` action.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -243,7 +243,7 @@ Parameters
    Updating the number for this flag only impacts the unmarked versions of objects.
    Any versions already marked for expiration do not change if you increase the number to retain.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -313,10 +313,9 @@ Behavior
 Lifecycle Management Object Scanner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MinIO uses a scanner process to check objects against all configured
-lifecycle management rules. Slow scanning due to high IO workloads or
-limited system resources may delay application of lifecycle management
-rules. See :ref:`minio-lifecycle-management-scanner` for more information.
+MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against the configured lifecycle management rules. 
+Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
+See :ref:`minio-lifecycle-management-scanner` for more information.
 
 Expiry vs Transition
 ~~~~~~~~~~~~~~~~~~~~

source/reference/deprecated/mc-ilm-edit.rst

@@ -137,7 +137,7 @@ Parameters
    :mc-cmd:`~mc ilm edit --noncurrentversion-expiration-days` option
    to apply expiration behavior to noncurrent object versions.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -158,7 +158,7 @@ Parameters
    - :mc-cmd:`~mc ilm edit --tags`
    - :mc-cmd:`~mc ilm edit --expiry-days`
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -174,7 +174,7 @@ Parameters
    This option has the same behavior as the 
    S3 ``NoncurrentVersionExpiration`` action.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -195,7 +195,7 @@ Parameters
    This option has the same behavior as the 
    S3 ``NoncurrentVersionTransition`` action.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -253,7 +253,7 @@ Parameters
 
    Requires specifying :mc-cmd:`~mc ilm edit --tier`.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.

source/reference/minio-mc-admin/mc-admin-heal.rst

@@ -23,7 +23,9 @@ corrupted and heals those objects.
 :mc-cmd:`mc admin heal` is resource intensive and typically not required even
 after drive failures or corruption events. Instead, MinIO automatically heals
 objects damaged by silent bit rot corruption, drive failure, or other issues on
-POST/GET. MinIO also performs periodic background object healing.
+``POST`` or ``GET``. MinIO also performs periodic background object healing using the :ref:`scanner <minio-concepts-scanner>`.
+
+Refer to :ref:`minio-concepts-healing` for more details on how MinIO heals objects.
 
 .. admonition:: Use ``mc admin`` on MinIO Deployments Only
    :class: note
@@ -95,26 +97,8 @@ Syntax
      
      Removes dangling objects and data directories in the healing process not referenced by the metadata on a per-drive basis.
 
-Healing Output Color Key
-------------------------
+Healing Colors
+--------------
 
-Originally, the healing mechanism output a table that used a Green-Yellow-Red-Gray color key to attempt to differentiate the status of objects in healing.
-These colors have been deprecated in favor of more detailed :ref:`healing metrics available at the cluster level <minio-metrics-and-alerts-available-metrics>`.
-
-The following table describes the intent of each of the deprecated color keys.
-
-.. list-table::
-   :widths: 25 75
-   :width: 100%
-
-   * - **Green**
-     - *Healthy*, the object has all data and parity shards available as required to serve the object
- 
-   * - **Yellow** 
-     - *Healing*, the object is still in the process of healing, and there are sufficient data or parity shards available to complete the healing
-
-   * - **Red** 
-     - *Unhealthy*, the object has lost one or more shards and requires healing
-
-   * - **Grey** 
-     -  *Unrecoverable*, the object has lost too many data and/or parity shards and cannot be healed or recovered
+Some versions of MinIO used a color key as a way to differentiate objects with different healing statuses.
+For details of this key, see the :ref:`Healing <minio-concepts-healing-colors>` concept page.

source/reference/minio-mc-admin/mc-admin-rebalance.rst

@@ -178,5 +178,5 @@ Starting with :minio-release:`RELEASE.2023-06-23T20-26-00Z`, rebalancing ignores
 Rebalancing also ignores objects where the only remaining version is a :ref:`delete marker <minio-bucket-versioning-delete>`.
 This avoids inter-pool :abbr:`I/O (Input/Output)` for objects already considered fully deleted.
 
-MinIO relies on the :ref:`scanner <minio-lifecycle-management-scanner>` to capture and remove those expired objects or trailing ``DeleteMarker`` objects.
+MinIO relies on the :ref:`scanner <minio-concepts-scanner>` to capture and remove those expired objects or trailing ``DeleteMarker`` objects.
 

source/reference/minio-mc/mc-ilm-rule-add.rst

@@ -124,7 +124,7 @@ Parameters
    Expire all current **and** noncurrent versions of an object.
    Use with the :mc-cmd:`~mc ilm rule add --expire-days` option to specify the number of days after which all versions of an object should be deleted by the scanner process.
 
-   After the :ref:`scanner <minio-lifecycle-management-scanner>` processes this command, no versions of the object remain on the deployment.
+   After the :ref:`scanner <minio-concepts-scanner>` processes this command, no versions of the object remain on the deployment.
 
 .. mc-cmd:: --expire-days
    :optional:   
@@ -136,7 +136,7 @@ Parameters
    For versioned buckets, the expiry rule applies only to the *current* object version. 
    Use the :mc-cmd:`~mc ilm rule add --noncurrent-expire-days` option to apply expiration behavior to noncurrent object versions.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -157,7 +157,7 @@ Parameters
    - :mc-cmd:`~mc ilm rule add --tags`
    - :mc-cmd:`~mc ilm rule add --expire-days`
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -176,7 +176,7 @@ Parameters
 
    Requires specifying :mc-cmd:`~mc ilm rule add --transition-tier`.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -198,7 +198,7 @@ Parameters
 
    This option has the same behavior as the S3 ``NoncurrentVersionExpiration`` action.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -213,7 +213,7 @@ Parameters
 
    This option has the same behavior as the S3 ``NoncurrentVersionTransition`` action.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
 
@@ -257,7 +257,7 @@ Parameters
    Updating the number for this flag only impacts the unmarked versions of objects.
    Any versions already marked for expiration do not change if you increase the number to retain.
 
-   MinIO uses a scanner process to check objects against all configured lifecycle management rules. 
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured lifecycle management rules. 
    Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules. 
    See :ref:`minio-lifecycle-management-scanner` for more information.
    
@@ -438,7 +438,7 @@ Behavior
 Lifecycle Management Object Scanner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MinIO uses a scanner process to check objects against all configured
+MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
 lifecycle management rules. Slow scanning due to high IO workloads or
 limited system resources may delay application of lifecycle management
 rules. See :ref:`minio-lifecycle-management-scanner` for more information.

source/reference/minio-mc/mc-ilm-rule-edit.rst

@@ -138,7 +138,7 @@ Parameters
    :mc-cmd:`~mc ilm rule edit --noncurrent-expire-days` option
    to apply expiration behavior to noncurrent object versions.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -159,7 +159,7 @@ Parameters
    - :mc-cmd:`~mc ilm rule edit --tags`
    - :mc-cmd:`~mc ilm rule edit --expire-days`
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -175,7 +175,7 @@ Parameters
    This option has the same behavior as the 
    S3 ``NoncurrentVersionExpiration`` action.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -204,7 +204,7 @@ Parameters
    This option has the same behavior as the 
    S3 ``NoncurrentVersionTransition`` action.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.
@@ -246,7 +246,7 @@ Parameters
 
    Requires specifying :mc-cmd:`~mc ilm rule edit --transition-tier`.
 
-   MinIO uses a scanner process to check objects against all configured
+   MinIO uses a :ref:`scanner process <minio-concepts-scanner>` to check objects against all configured
    lifecycle management rules. Slow scanning due to high IO workloads or
    limited system resources may delay application of lifecycle management
    rules. See :ref:`minio-lifecycle-management-scanner` for more information.

source/reference/minio-server/settings/core.rst

@@ -160,7 +160,7 @@ Scanner Speed
       .. mc-conf:: scanner speed
          :delimiter: " "
 
-Manage the maximum wait period for the scanner when balancing MinIO read/write performance to scanner processes.
+Manage the maximum wait period for the :ref:`scanner <minio-concepts-scanner>` when balancing MinIO read/write performance to scanner processes.
    
 .. include:: /includes/common/scanner.rst
    :start-after: start-scanner-speed-values

source/reference/minio-server/settings/kes.rst

@@ -10,6 +10,8 @@ Key Encryption Service Settings
    :local:
    :depth: 2
 
+.. |SSE|           replace:: :abbr:`SSE (Server-Side Encryption)`
+
 The following environment variables control how the MinIO Server interacts with the Key Encryption Service (KES) when managing encryption and keys.
 
 .. note::