A stand-alone MinIO server would go down if the server hosting the drives goes offline. In contrast, a distributed MinIO setup with _m_ servers and _n_ drives will have your data safe as long as _m/2_ servers or _m*n_/2 or more drives are online.

For example, an 16-server distributed setup with 200 drives per node would continue serving files, up to 4 servers can be offline in default configuration i.e around 800 drives down MinIO would continue to read and write objects.

- We limited the number of drives to 16 for erasure set because, erasure code shards more than 16 can become chatty and do not have any performance advantages. Additionally since 16 drive erasure set gives you tolerance of 8 drives per object by default which is plenty in any practical scenario.

  - Pool number the object operation was performed on.
  - Set number the object operation was performed on.
  - The list of drives participating in this operation belong to the set.

```json
{
  "version": "1",
  "deploymentid": "51bcc7b9-a447-4251-a940-d9d0aab9af69",
  "time": "2021-10-08T00:46:36.801714978Z",
  "trigger": "incoming",

| Minimum number of drives per server when server count is 1      | 02            |
| Minimum number of drives per server when server count is 2 or 3 | 01            |
| Minimum number of drives per server when server count is 4      | 01            |
| Maximum number of drives per server                             | no-limit      |
| Read quorum                                                     | N/2           |

require distributed deploying MinIO with Erasure Coding. For extended development and production, deploy MinIO with Erasure Coding enabled - specifically,
with a *minimum* of 4 drives per MinIO server. See [MinIO Erasure Code Overview](https://min.io/docs/minio/linux/operations/concepts/erasure-coding.html)
for more complete documentation.

### Stable

### Remotely Inspecting backend data