Server transfers
Move a server from one FeatherWings node to another, how allocations are picked, what happens to backups, and the config.yml keys for transfers and shared storage.
On this page
A transfer moves a server’s files to another node and points the server at it. The panel itself marks the feature as experimental: make and check a backup somewhere else before you move a server you care about.
Moving one server
In the admin area open Servers, then Transfer server on the server’s row. Choose:
- Destination node. It must be a different node, and the dialog shows how many allocations the server needs and how many are free on the destination.
- Assign allocation automatically (default on). The panel takes the next free allocations on the destination for the primary port and any extra ports. Turn it off to pick the primary allocation yourself.
- Auto-open missing ports on destination. When the destination has too few free allocations, create them from the IPs Wings reports, with the same ports the server uses now.
- Include backups and Delete backups on source, shown when the source daemon can move backups.
The panel refuses a transfer while the server is installing, restoring or already transferring. When it accepts, it:
- Assigns the new allocations, sets the server status to
transferringand moves it to the destination node in the database. - Signs a transfer token with the destination node’s key.
- Asks the source Wings to start the transfer, passing the destination URL, the token and the list of backups.
What the nodes do
- The source stops the server, builds a compressed archive of its files and streams it to
POST /api/transferson the destination, with progress messages in the console every five seconds. Selected backups are sent in the same request. - The destination creates the server, extracts the archive into its data folder and backups into
system.backup_directory, builds the container environment and reports success to the panel. - If a step fails, the failure is reported to the panel and the transfer stops.
While it runs, GET /api/admin/servers/{id}/transfer returns the status, and DELETE on the same path cancels it.
Cancelling asks both nodes to stop and releases the new allocations on the destination. Files that were already
copied may stay behind.
Moving many servers
On the Nodes list or the node page, Mass move servers moves several servers, or all of them, from one node to another. The panel previews which servers can move and how many allocations it needs, then starts one transfer per server, up to 100 per request.
Node settings
system:
transfers:
download_limit: 0 # MiB/s on the destination, 0 for no limit
perform_checksum_checks: false # check the SHA-256 checksum of incoming archives
storage_pool:
enabled: false
pool_name: ""
The destination must be reachable from the source on its Wings API port.
storage_pool is for nodes that share one data volume, for example over NFS or Ceph. The source sends its pool name in
the X-Storage-Pool header. If the destination has the pool enabled with the same name (case does not matter), it
skips copying, creates the server environment on the existing files and reports success.
Frequently asked questions
Yes. The source node stops the server before it builds the archive, and the server is started on the new node only after the transfer finishes.
No. Transfers are started from the admin area and need the admin.servers.edit permission.