You cannot move an IP address between BinaryLane servers. Instead, you can keep the server that has the IP address you want and clone another server onto it. This replaces its operating system and disk contents with a backup of the other server, while keeping its IP address.

In this guide, the destination is the server whose IP address you want to keep. The source is the other server, which has the operating system and contents you want to use on that address.

TABLE OF CONTENTS

Before you begin

You need:

  • a BinaryLane API token
  • bl 0.21.0 for the backup and verification commands
  • two existing BinaryLane servers: the destination (has the IP address you want to keep) and the source (has the operating system and contents you want to clone onto it)
  • the destination server must have finished its initial build and be available for use

Applies to

  • BinaryLane API 0.40.0
  • binarylane-cli 0.21.0

This guide uses bl, with a curl example for the clone request.

For token setup, see Getting Started with BinaryLane API. For bl, follow the CLI configuration instructions. The curl examples use Bash syntax and the BINARYLANE_API_TOKEN environment variable described in the API guide. The examples use ${BINARYLANE_API_TOKEN} for your token, ${destination_server_id} for the server whose IP address you are keeping, and ${source_server_id} for the server whose operating system and contents you are cloning onto it.

Warning: cloning wipes the destination server's existing disks without asking for further confirmation. Back up any destination data you may need, and confirm you have selected the correct destination before continuing. Keep the source server until you have verified the destination and decided what data and backups you need to retain.

Existing backups of the destination server remain unchanged by cloning. Unlocked backups are replaced on the normal backup schedule; locked backups are not replaced by scheduled backups.

Step 1: Get a backup of the source server

The clone action needs an existing backup image of the source server. Any backup type works (a scheduled daily, weekly, or monthly backup, or a one-off backup) as long as it belongs to the source server. The destination receives the data from the time that backup was taken, not changes made on the source afterwards.

Check whether the source server already has a usable backup:

bl server get ${source_server_id} --output json

Look at the backup_ids field in the response. If it already lists a recent backup you want to use, note that backup's ID and skip ahead to Step 2.

If there is no suitable backup yet, take a one-off backup:

bl server action take-backup ${source_server_id} --replacement-strategy none --backup-type temporary

The CLI waits for the backup action by default. Continue only after it reports completed; if it reports an error, resolve it before cloning. Then find the backup's ID:

bl server get ${source_server_id} --output json

Note the new entry in backup_ids.

Step 2: Clone the backup onto the destination server

With bl:

bl server action clone-using-backup ${source_server_id} --image-id ${backup_id} --target-server-id ${destination_server_id}

With the API:

curl --request POST \
  "https://api.binarylane.com.au/v2/servers/${source_server_id}/actions" \
  --header "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{"type": "clone_using_backup", "image_id": '"${backup_id}"', "target_server_id": '"${destination_server_id}"'}'

Note that the source server's ID is the one in the URL path, and the destination server's ID goes in the request body as target_server_id. This is easy to get backwards.

By default the destination server keeps its own existing hostname. To give it a new hostname as part of the clone, add --name (CLI) or a "name" field in the request body (API).

The CLI waits for the clone action by default. With the API, note the returned action.id and check its status:

bl action get ${action_id} --output json

For API-only status checks, use GET /v2/actions/{action_id} with the same Bearer token. Wait while action.status is in-progress. Continue when it is completed; if it is errored, inspect the error before retrying.

Step 3: Check the destination

Confirm the destination still has the IP address you intended to retain:

bl server get ${destination_server_id} --output json

Check the destination through the console and confirm the operating system's network settings match its assigned addresses before relying on remote access. Test the required services on that address. Keep the source server until those checks pass and your recovery needs are covered.

Troubleshooting

The clone action fails immediately

Check that the destination has finished building and inspect the error response before retrying.

The one-off backup fails because no slot is free

--replacement-strategy none does not overwrite an existing backup. Use a suitable existing source backup, or review the source server's backups before deciding whether one can be replaced.

I'm not sure which backup ID to use

Run bl server backup list ${source_server_id} to list every backup of the source server, or check the backup_ids field from bl server get ${source_server_id} --output json. The image must be a backup of the source server specifically; a backup of a different server will not work.

Related article

For a short explanation of IP address retention, see Can I migrate my IP address between servers?.