Skip to main content

Upgrade a data or parity disk to a larger one

POST 
/disks/array/upgrade

Required role: admin. Only an account or token with the admin role can call this operation.

Example request
curl --request POST \
  --header "Authorization: Bearer $HOSERVA_TOKEN" \
  --header "Content-Type: application/json" \
  --data @body.json \
  "https://$HOSERVA_HOST:8008/api/v1/disks/array/upgrade"

Starts a resumable Topology job (a data-disk or a parity-disk upgrade, resolved from the slot's role). The confirmation must be the exact string the matching planDiskUpgrade call returned; a wrong or missing one is refused with confirmation_required and formats nothing. A data disk in removal is refused (disk_leaving_array, 409) as planDiskUpgrade refuses it. A data-disk upgrade follows a fixed state machine: it is admitted only once stopArray has completed (otherwise array_not_stopped) and while no other data-disk upgrade is pending (otherwise disk_upgrade_pending, naming it). It requires a clean snapraid diff before formatting, copies and verifies the old disk, mounts the new one at the same mountpoint, requires snapraid diff to show no removed or updated files, and only then names the new disk in SQLite; the array stays stopped until the user starts it. A parity-disk upgrade runs with the array started (refused with maintenance_mode while it is stopped): it copies the parity file, verifies it byte for byte, switches the configuration and passes snapraid check before releasing the old parity disk. The old disk is never written to or released until its verification gate passes.

Request​

Responses​

The queued, resumable Topology job.