To run another server's content on an IP address you need to retain, clone that server onto the existing server that holds the address. The source supplies the content; the destination keeps its IP address and has its disks replaced with a backup of the source.

BinaryLane cannot move an IP address between servers. Cloning lets you keep the destination server and its address while replacing what runs on it.

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 source (has the content you want to keep) and the destination (has the IP address you want to keep)
  • 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, ${source_server_id} for the server whose content you are keeping, and ${destination_server_id} for the server whose IP address you are keeping.

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

A separate article describes a customer-managed network proxy: Can I migrate my IP address between servers?.