Skip to main content

Scan a Flash Backup zip

POST 
/migrate/scan

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/migrate/scan"

Takes the Flash Backup zip and queues a migration_scan job (topology class, so no storage job runs beside it). The zip is kept in the daemon's state directory, readable by root only, as the session's source; it is never modified and never extracted: entries are read in memory. A scan replaces the previous session's report and zip once it finishes. Refused before anything is queued, with nothing kept: 400 file_required (no file), 400 invalid_zip (not a zip, an entry path with .. or starting with /, or a duplicate entry), 413 zip_too_large (a zip over 2 GiB, refused as soon as the request body, which is the zip and its multipart framing, passes that size plus 1 MiB), 400 invalid_flash_backup (no usable config/disk.cfg) and 400 unsupported_layout (an Unraid version other than 6.12.x or 7.x, or a flash layout Hoserva does not recognise, unless unverifiedLayout is true). 409 scan_in_progress while a scan runs, 409 migration_in_progress while an import is pending its point of no return (startMigrationImport), and 501 not_configured when this daemon has no migration service. unverifiedLayout overrides only the layout refusal; the override is recorded in the report and printed at its top. The scan reads the disks Hoserva already inventories and SMART without waking a disk in standby. It also reads every data disk the capture records, through a read-only mount at a private mountpoint under the daemon's state directory (XFS without replaying its log), after the disk's read-only filesystem check: a disk that fails a check, or is a ZFS, encrypted or multi-device btrfs disk, is refused by name in the report and the scan goes on with the rest. Each data disk's files are listed and a sample hashed, as the baseline the verify phase compares against (fullChecksums hashes every file). Nothing is written to a source disk, and no disk stays mounted when the job ends, whether it succeeded, failed or was cancelled. The job reports its progress and can be cancelled.

Request​

Responses​

The queued migration_scan job.