> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/storage-vsan/scaling-down-a-vsan.md).

# Scaling Down a vSAN (Removing Drives)

How to request a vSAN scale-down (drive removal) through VergeOS Support, including what to prepare before opening a ticket.

## Overview

{% hint style="info" %}
**Key Points**

* Removing drives from a vSAN tier is **not a self-service operation**
* Drive removal must be coordinated with VergeOS Support
* The process requires data redistribution across the remaining drives before any drives can be safely removed
  {% endhint %}

Scaling down a vSAN (removing physical drives to reduce storage capacity) is fundamentally different from [scaling up](/knowledge-base/storage-vsan/scaling-up-a-vsan.md). Adding drives is an additive, low-risk operation. Removing them requires the system to first safely redistribute all data off the target drives, which involves careful coordination to avoid disruption or data loss.

For this reason, vSAN scale-down is handled exclusively by VergeOS Support.

## Why Drive Removal Requires Support

When a drive is removed from a vSAN tier, VergeOS must:

1. Confirm the remaining drives have sufficient free capacity to absorb the data from the drives being removed
2. Migrate all data off the target drives to maintain redundancy
3. Monitor repair and redistribution to completion before drives are physically pulled

If any of these steps are rushed or sequenced incorrectly, the vSAN tier can enter a degraded or unrecoverable state. Support engineers coordinate this process and monitor it through to a healthy green status before physical removal occurs.

## Before You Contact Support

Gathering the following information in advance will help Support scope the request and schedule the work:

* **Why you need to scale down** — repurposing drives, tier restructuring, etc.
* **Which tier** the drives belong to (Tier 0, Tier 1, Tier 2, etc.)
* **Number and size of drives** to be removed per node
* **Current tier capacity and usage** — available in the VergeOS UI under **Infrastructure > vSAN Tiers**
* **Current vSAN tier status** — confirm the tier is green/healthy before the call
* **Preferred maintenance window** — drive removal and data redistribution may take hours to complete depending on data volume

## Initiating the Request

[Open a support ticket](/support-and-services.md) and include the information above. For time-sensitive requests, note your preferred maintenance window in the ticket so Support can prioritize scheduling.

## What to Expect

Once the request is scheduled, Support will:

1. Review your current vSAN health and capacity headroom
2. Walk through the planned removal with you before beginning
3. Initiate the data redistribution process and monitor repair status
4. Confirm the tier returns to a healthy green state before any drives are physically removed
5. Guide you through the physical removal and any post-removal verification steps

## Related Documentation

* [vSAN Scale Up Guide](/knowledge-base/storage-vsan/scaling-up-a-vsan.md) — the inverse operation, which is self-service
* [vSAN Scale Up SOP](/run-the-platform/operations/vsan-scale-up-sop.md) — preparation and verification best practices for storage operations
* [vSAN Architecture Overview](/run-the-platform/storage/vsan-architecture.md)

***

{% hint style="info" %}
**Document Information**

* Last Updated: 2026-04-20
* VergeOS Version: 4.13
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.verge.io/knowledge-base/storage-vsan/scaling-down-a-vsan.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.