ALIBABA CLOUD NAS AND DISKS → STACKIT · GUIDE
Alibaba NAS and cloud disks to STACKIT File Storage and Block Storage
A NAS file system becomes a STACKIT File Storage share and a cloud disk becomes a STACKIT volume. The shape of the target is clear; the data is the work. StackToIT reads both from your Alibaba Cloud Terraform, assigns the targets and the migration class, names every setting you carry across and lists both as stateful units whose copy method you choose. This guide follows that run and adds the copy steps.
A NAS file system with its mount target, assessed
A small Alibaba Cloud estate written for this page: a VPC, a worker instance, a cloud disk, a NAS file system and a mount target, assessed by StackToIT on 4 November 2026. Left: the input. Right: the result for the file system, an excerpt of assessment.json with the values exactly as the run wrote them. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.
resource "alicloud_nas_file_system" "media" {
protocol_type = "NFS"
storage_type = "Capacity"
file_system_type = "standard"
description = "shared media library"
zone_id = "eu-central-1a"
}
resource "alicloud_nas_mount_target" "media" {
file_system_id = alicloud_nas_file_system.media.id
vswitch_id = alicloud_vswitch.app.id
network_type = "Vpc"
access_group_name = "DEFAULT_VPC_GROUP_NAME"
}{
"id": "alicloud_nas_file_system.media",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT File Storage (SFS)",
"resources": [
"stackit_sfs_resource_pool",
"stackit_sfs_share",
"stackit_sfs_export_policy"
]
},
"reason": "A NAS file system becomes a STACKIT File Storage share. Data moves with a file copy, and mount targets and access groups are rewritten."
}
}REPLATFORM
A file system moves to a managed service of a different shape. The run names three target resources: stackit_sfs_resource_pool, stackit_sfs_share and stackit_sfs_export_policy.
Five settings named
description, file_system_type, protocol_type, storage_type and zone_id are listed for your team. None is carried silently.
Mount targets are rewritten
The run's reason says it plainly: data moves with a file copy, and mount targets and access groups are rewritten. Which clients reach the share is set on the target side by the export policy the run names, and STACKIT documents up to 10 rules per share export policy.
The cloud disk and what the run says about it
From the same run. Left: the input. Right: the result for the disk. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.
resource "alicloud_disk" "scratch" {
zone_id = "eu-central-1a"
disk_name = "media-scratch"
category = "cloud_essd"
performance_level = "PL1"
size = 500
encrypted = true
}
resource "alicloud_disk_attachment" "scratch" {
disk_id = alicloud_disk.scratch.id
instance_id = alicloud_instance.worker.id
}{
"id": "alicloud_disk.scratch",
"result": {
"class": "RECONFIGURE",
"confidence": "LOW",
"target": {
"service": "STACKIT Block Storage",
"resources": [
"stackit_volume",
"stackit_server_volume_attach"
]
},
"reason": "A cloud disk becomes a STACKIT volume. The performance category does not carry over; choose a STACKIT performance class, and move the data at the host level or with the server image."
}
}Performance does not carry over
category = cloud_essd and performance_level = PL1 have no equal on STACKIT. You choose a STACKIT performance class for the volume.
The data moves at the host
The run states that the data moves at the host level or with the server image. Attaching an empty volume does not move a byte.
Why the disk is LOW
The disk is rated LOW because the disk attachment linked to it is a resource type the run does not know, so its effect is not assessed; the instance is LOW for the same reason. Six settings are named for review: category, disk_name, encrypted, performance_level, size and zone_id.
How the estate maps
| Alibaba Cloud resource | STACKIT target | Migration class |
|---|---|---|
| NAS file system | STACKIT File Storage (SFS): resource pool, share and export policy | Replatform |
| Cloud disk | STACKIT Block Storage: volume attached to a server | Reconfigure |
| ECS instance | STACKIT Compute Engine: server, volumes, network interfaces | Reconfigure |
| VPC and vSwitch | STACKIT networks, with a Network Area where routing is needed | Reconfigure |
| Security group | STACKIT security groups | Reconfigure |
| NAS mount target | Not in the catalogue: an architect decides | Architect decision |
| Disk attachment | Not in the catalogue: an architect decides | Architect decision |
Classes as the run decided them for 8 resources in 8 units: 5 RECONFIGURE, 1 REPLATFORM, 2 MANUAL_REVIEW. The two MANUAL_REVIEW units are resource types the run does not know, so nothing of them is assessed.
The order the run gives
Excerpt of migration/technical-sequencing.md, taken as written. Units move after every unit they depend on.
## Wave 1 — 3 unit(s)
| Unit | Class | Target |
|---|---|---|
| `alicloud_disk.scratch` | RECONFIGURE / LOW | STACKIT Block Storage |
| `alicloud_nas_file_system.media` | REPLATFORM / MEDIUM | STACKIT File Storage (SFS) |
| `alicloud_vpc.main` | RECONFIGURE / MEDIUM | STACKIT network |
## Wave 2 — 2 unit(s)
| Unit | Class | Target |
|---|---|---|
| `alicloud_security_group.app` | RECONFIGURE / MEDIUM | STACKIT security groups |
| `alicloud_vswitch.app` | RECONFIGURE / MEDIUM | STACKIT network |
## Wave 3 — 2 unit(s)
| Unit | Class | Target |
|---|---|---|
| `alicloud_instance.worker` | RECONFIGURE / LOW | STACKIT Compute Engine |
| `alicloud_nas_mount_target.media` | MANUAL_REVIEW / LOW | — |
## Wave 4 — 1 unit(s)
| Unit | Class | Target |
|---|---|---|
| `alicloud_disk_attachment.scratch` | MANUAL_REVIEW / LOW | — |Wave 1
The disk, the file system and the VPC depend on nothing in the estate, so they can start together.
Wave 3 and 4
The instance and the mount target follow the network. The attachment comes last, after both the disk and the instance exist.
The two copies are listed, not chosen
StackToIT never moves data. Excerpt of migration/data-movement.md, taken as written.
StackToIT never moves data. 2 stateful source units are listed here: a person must choose a data-movement mechanism for each, and none is chosen (the mechanism is UNKNOWN).
State: DECISION REQUIRED.
## Stateful source units
| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| alicloud_disk.scratch | alicloud_disk | STACKIT Block Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| alicloud_nas_file_system.media | alicloud_nas_file_system | STACKIT File Storage (SFS) | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |Mechanism UNKNOWN
The size of the data and the downtime you tolerate are not in the Terraform. The provisioned capacity of the disk is not the size of what is on it.
The migration, in order
The steps of the guide. The run supplies the inventory, the targets and the order; the STACKIT and Alibaba Cloud facts come from the documentation under the sources, and the copy itself is general practice.
1. Inventory what is mounted where
The run lists the file system, its mount target and the disk. Add what Terraform cannot show: which hosts mount the share, under which path, with which protocol, and which processes write to it.
2. Prepare the landing zone
STACKIT File Storage is always connected to a STACKIT Network Area with routing tables enabled, and it reserves subnets: a /28 and four /29 for the interconnection. Plan this with the network work package before you create the first resource pool.
3. Create the targets
A resource pool holds the shares. STACKIT documents 500 GB as the minimum pool capacity and 20 TB as the maximum, with up to 200 shares per pool and 10 rules per export policy. Data volumes for the disks run from 1 GB to 16 TB; they can be enlarged while detached but never shrunk, so size them for the data, not for the source disk.
4. Copy the share
Alibaba documents an rsync procedure for NFS: mount both file systems on a temporary instance, run a full pass while the application runs, stop the writers, run an incremental pass with --delete and verify with a dry run. Its warning applies as well: --delete removes files at the destination that no longer exist at the source, so use it with care. The same pattern works toward a STACKIT share, provided the copy host can mount both sides, for example over a VPN into the Network Area.
5. Move the disk contents
For a data disk, copy at the host: attach a new volume to the target server and copy with the tools your operating system offers. For a system disk, export the image on the Alibaba Cloud side and import it on STACKIT.
6. Cut over and keep the old copy
Unmount the old share, mount the new one at the same path, restart the application and update the mount configuration. Alibaba advises keeping the old data for at least a week after the cutover; do the same here.
Limits that decide the plan
From the STACKIT and Alibaba Cloud documentation listed under the sources. Check them again against your region.
STACKIT File Storage speaks NFS
The File Storage pages under the sources describe NFS shares only and list NFSv3, NFSv4.1 and NFSv4.2 as the supported unencrypted versions; SMB is not mentioned. A NAS file system that serves SMB needs an architect's decision before it has a target.
Pool size is a floor and a ceiling
A resource pool is at least 500 GB and at most 20 TB. A very small share still lives in a pool of that minimum; a very large file system may not fit one pool.
Image import: 70 GB
A custom image uploaded through the STACKIT IaaS API may be raw, qcow2 or iso and at most 70 GB. A system disk image larger than that needs another route, for example a server built from a STACKIT image and the data copied at the host.
Image export has exceptions
On Alibaba Cloud, encrypted images, images created from Marketplace images and Windows Server images cannot be exported, and the target bucket must use Standard or Infrequent Access storage.
Block volumes attach to one server
A data volume attaches to one server at a time. A disk that several instances use at once at the source needs a different design, for example a share.
Decisions your architects own
Performance class
The run asks you to choose a STACKIT performance class for the volume, because cloud_essd with PL1 does not carry over. Choose it from the measured load of the source, not from the name of the source category.
Export policy
Translate each access group of the source into export policy rules with the client networks you intend, within the 10 rules per policy.
Zone placement
The vSwitch and the disk are bound to a zone at the source, and the run asks you to review the zone placement of the workloads on the vSwitch. Decide where the target server and its volume live.
Owner of the open units
The run puts the mount target and the attachment into work package WP-04, with the owner NOT_STATED. Name one.
Questions about NAS and disk migration
Does StackToIT copy the NAS data or the disk contents?
No. It lists both as stateful units in the data-movement file, with the mechanism left to you, and it never runs a copy.
Why are the mount target and the disk attachment MANUAL_REVIEW?
The run does not know these two resource types, so it assesses nothing about them and asks an architect to decide. The run's other targets show where they land: the disk's target already includes stackit_server_volume_attach, and the file system's target includes an export policy, which controls which clients reach the share.
Can I keep the same mount paths?
Yes. The application sees a path, not a vendor. Mount the STACKIT share at the old path during the cutover and update the mount configuration; exports, IP ranges and the NFS version are what change.
Which tool copies the data?
The run chooses none. Alibaba documents rsync for NFS-to-NFS moves through a temporary transfer instance; rsync works the same way toward a STACKIT share once one host can mount both sides.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.