IBM Cloud Docs
Understanding data portability for VPC services

Understanding data portability for VPC services

Data portability involves a set of tools and procedures that enable you to export the digital artifacts that are needed to implement similar workload and data processing on different service providers or on-premises software. It includes procedures for copying and storing the service customer content, including the related configuration that is used by the service to store and process the data, in your location.

Responsibilities

IBM Cloud services provide interfaces and instructions to guide you through the process of copying and storing service customer content, including the related configuration, in your selected location.

You're responsible for the use of the exported data and configuration for data portability to other infrastructures, which includes:

  • The planning and execution for setting up alternative infrastructure on different cloud providers or on-premises software that provide similar capabilities to the IBM services.
  • The planning and execution for the porting of the required application code on the alternative infrastructure, including the adaptation of your application code, deployment automation, and so on.
  • The conversion of the exported data and configuration to the format that's required by the alternative infrastructure and adapted applications.

For more information about your responsibilities when using IBM Cloud® Virtual Private Cloud, see Understanding your responsibilities when you use Virtual Private Cloud.

Data export procedures

Exporting customer data for virtual servers

Virtual Servers for VPC provides the mechanisms to export your content that's uploaded, stored, and processed when you use the service.

Complete the following steps to export customer data for your virtual server to IBM Cloud Object Storage. From IBM Cloud Object Storage you can download the image for your use. This procedure applies to virtual servers that are provisioned on both public hosts and dedicated hosts.

  1. For the virtual server that contains data that you want to export, complete the steps in Creating an image from a volume.
  2. Make sure that you have an IBM Cloud Object Storage instance configured with authorization to export from IBM Cloud VPC. For more information, see Granting access to IBM Cloud Object Storage to import and export images.
  3. Complete the steps in Exporting a custom image to IBM Cloud Object Storage.
  4. Download the custom image from IBM Cloud Object Storage for your use. For more information, see Using Aspera high-speed transfer.
  5. If you have data volumes for your virtual server in addition to the boot volume, see Customer data in storage volumes and shares.

In addition to the boot volume image of the virtual server, you can find additional details about your virtual server configuration with the following resources.

How to view details of a virtual server
Service IBM Cloud console CLI API
Virtual servers View details for the virtual server ibmcloud is instance
ibmcloud is instance-profile
get-instance
get-instance-profile

Exporting customer data for bare metal servers

Bare metal servers are positioned as a fully customer-managed service. You are responsible to determine your own data export solution.

Exporting customer data for custom images

Images for VPC provides the mechanisms to export your content that's uploaded, stored, and processed when you use the service.

Complete the following steps to export customer data for your custom image to IBM Cloud Object Storage. From IBM Cloud Object Storage you can download the image for your use.

  1. Make sure that you have an IBM Cloud Object Storage instance configured with authorization to export from IBM Cloud VPC. For more information, see Granting access to IBM Cloud Object Storage to import and export images.
  2. Complete the steps in Exporting a custom image to IBM Cloud Object Storage.
  3. Download the custom image from IBM Cloud Object Storage for your use. For more information, see Using Aspera high-speed transfer.

Exporting customer data for networking services

There is no direct "export" feature for networking configurations, but you can gather details manually. Depending on your needs, you can use the IBM Cloud CLI to retrieve configurations for resources, or interact programmatically with the IBM Cloud API to pull configurations.

Exporting an IBM Cloud networking service configuration to another cloud platform involves a series of steps, each requiring careful attention to ensure that the configurations are replicated properly on the destination platform. Here's a general outline of the process and what you need to know:

  1. Assess the IBM Cloud networking service configurations. First, identify the services that you want to migrate. This could include services like Virtual Private Cloud (VPC), load balancers, VPNs, flow logs, subnets, and so on.
  2. Prepare the target cloud platform. Each cloud provider has its own set of networking features. Before starting the migration, you must understand the network setup of the destination platform by researching equivalent services in the target cloud. Then, check compatibility. Some feature might need to be reconfigured due to differences in cloud architectures.
  3. Replicate the configuration manually or by using tools. For example, use the UI, CLI, or API of the destination cloud provider to recreate the network configuration. Automation tools can be used to script out infrastructure and export configurations between cloud environments, assuming the network services are comparable.
  4. Migrate your network services by exporting your DNS records and setting them up in the DNS service of the new platform. You'll also need to manually recreate firewall configurations and security groups, ensuring the same security rules are applied. For load balancers, transfer the necessary configurations and ensure that behaviors like port forwarding and SSL settings are replicated in the target platform’s service. Additionally, establish any private network connections, such as VPNs or equivalents on the new platform.
  5. Test the configuration. To verify connectivity, ensure all network resources, including VPC, subnets, security groups, and routing tables, are properly set up and communicate as expected. Test DNS resolution, if applicable, to ensure that your domain names are pointing correctly. Also, check load balancer and VPN connections to make sure traffic flows as expected and that you have secure access to your services.

Exporting network services data using the UI

Each networking service has a Download icon on its main console page, which lets you export your data into a CSV file. This provides a convenient way to transfer data from the user interface.

Exporting network services data using the UI
Download network services data from the UI

Exporting network services data with the CLI and API

The following table provides mechanisms to export the settings and configurations that are used to process the customer's content through the means of the IBM Cloud VPC CLI and API. The procedures given in the linked documentation should be followed and the output stored to ensure all necessary configuration data is available.

Exporting network services data with the CLI and API
Service CLI API
Floating IPs ibmcloud is floating-ips list-floating-ips
Flow logs ibmcloud is flow-logs list-flow-log-collectors
Load balancers ibmcloud is load-balancers
ibmcloud is load-balancer-listener-policies
ibmcloud is load-balancer-listener-policy-rules
ibmcloud is load-balancer-listeners
ibmcloud is load-balancer-pool-members
ibmcloud is load-balancer-pools
list-load-balancers
list-load-balancer-listener-policies
list-load-balancer-listener-policy-rules
list-load-balancer-listeners
list-load-balancer-pool-members
list-load-balancer-pools
list-load-balancer-profiles
Network ACLs ibmcloud is network-acls
network-acl-rules
list-network-acls
list-network-acl-rules
Private Path services ibmcloud is private-path-service-gateways list-private-path-service-gateways
Public gateways ibmcloud is public-gateways list-public-gateways
Routing tables / routes ibmcloud is vpc-routing-tables
ibmcloud is routing-table-routes
list-vpc-routing-tables
list-vpc-routing-table-routes
Security groups ibmcloud is security-groups
ibmcloud is security-group-rules
ibmcloud is security-group-targets
list-security-groups
list-security-group-rules
list-security-group-targets
Subnets ibmcloud is subnet
ibmcloud is subnet-reserved-ips
list-subnets
list-subnet-reserved-ips
Virtual network interfaces ibmcloud is virtual-network-interfaces
ibmcloud is virtual-network-interface-floating-ips
ibmcloud is virtual-network-interface-reserved-ips
list-virtual-network-interfaces
list-network-interface-floating-ips
list-virtual-network-interface-ips
Virtual Private Endpoint gateways ibmcloud is endpoint-gateways
ibmcloud is endpoint-gateway-targets
list-endpoint-gateways
list-endpoint-gateway-ips
VPCs ibmcloud is vpcs
ibmcloud is vpc-address-prefixes
list-vpcs
list-address-prefixes
VPNs ibmcloud is vpn-servers
ibmcloud is vpn-server-clients
ibmcloud is vpn-server-routes
ibmcloud is ike-policies
ibmcloud is ike-policy-connections
ibmcloud is ipsec-policies
ibmcloud is ipsec-policy-connections
list-vpn-gateways
list-vpn-servers
list-vpn-server-routes
list-ike-policies
list-ipsec-policies

Exporting customer data in storage volumes and shares

When you create a strategy for migrating Block Storage for VPC or File Storage for VPC data to another target storage platform, whether that is on premises or another cloud provider, many factors must be considered to facilitate a successful outcome.

Each migration scenario is different. Capture the requirements and any special considerations for your use case. Each migration scenario includes factors such as the type of data that is being migrated, the data availability, data compatibility, target storage environment requirements, and so on.

  1. Identify the type of data that you intend to migrate. You must ensure compatibility of the storage services that are available between the source and target storage environments to help ensure seamless workload transition upon completion of the migration process.

    • If the targeted storage is block volume service data, make sure that the target cloud provider has equivalent block storage services available to map your existing data correctly.
    • If target storage is file service data, confirm that the target cloud provider has equivalent NFS file services available to map your existing data correctly.
  2. Identify the performance and capacity requirements for the data. Make sure that the target platform has compatible performance, and capacity profiles available to reduce any impact to workload behavior after the transition. It is recommended to conduct performance testing upfront within the new target environment to evaluate any workload performance impacts before you migrate your data.

  3. Consider the data availability and downtime requirements of your services.

    • Identify any specific requirements around data availability and outage windows.
    • Consider the strategies that you can incorporate to help ensure data consistency and accessibility across your workloads during the migration process.
    • Think about how long the migration can take. If you have a large data estate, you must develop a detailed migration plan that defines the timeline for migration execution. You must evaluate the size of the data sets to be transferred and consider expected data transfer speeds between the source and target environments.
  4. Select the right tool. When you consider specific tools for data migration, it’s important to pick the right solution for the job.

    • Block storage – Select a block volume migration tool that maintains the native block format. Make sure that the data is transferred as raw blocks or chunks, maintaining the original file system structure and volume layout upon ingest into the target storage system. The specific tools that you choose depend on your unique migration requirements. Some important considerations to keep in mind during the evaluation process include the capacities that the provider has for data integrity, data monitoring, and data security during the migration process. In addition, it is important to evaluate any requirements that are dictated by the target storage vendor you are migrating data to. It is recommended that you review the target storage environment documentation to understand if they recommend processes or tools to simplify the migration.
    • File storage – Select an NFS migration tool that maintains file system hierarchy, directory structure, metadata, and permissions when the data is transferred to the new storage environment. When you evaluate NFS migration tools, make sure that the tool you use maintains data consistency and integrity during the migration. Make sure that the tool supports secure data transfer capabilities and has adequate monitoring facilities. Different tools each have their own strengths, so it's important to evaluate your specific requirements and choose the one that best fits your needs.
  5. Develop a comprehensive test plan to validate the migration tools' capabilities against your requirements before you start your data migration plan. Make sure that the testing evaluates the following:

    • The data consistency and data integrity of the data during the migration process
    • The ability to monitor, detect, and react to issues during the migration process
    • The network bandwidth and network reliability between the source and target environments
    • The ability to verify that all data is intact on the target system after the migration is complete

Other Considerations:

  • It is recommended that snapshots are taken within IBM Cloud before execution of any data migration activities. It is important to have a backup of all data to help ensure data retention during the process.
  • Update any applications or systems that rely on the migrated data to point to the new storage location.

Exported data formats

Exported data formats for virtual servers and custom images

Virtual Servers for VPC supports the following data format and schema of the exported data, configuration, and application:

When you export a custom image, whether it is created through image from a volume for a virtual server, or your own custom image, the image is exported in the format that you specify:

  • VHD
  • QCOW2 (required when exporting an encrypted image)

When you export configuration information for your virtual server, export the virtual server details in JSON format.

Example command using the CLI, ibmcloud is instance:

ibmcloud is instance INSTANCE [--output JSON] 

Example request using the API, get-instance:

curl -X GET \
"$vpc_api_endpoint/v1/instances/$instance_id?version=2024-11-13&generation=2" \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $iam_token"

Exported data formats for networking services

Networking services for VPC support the following data format and schema of the exported data, configuration, and application:

  • Export in JSON format only

When you export configuration information for a networking service, export its details in JSON format.

Example command using the CLI, ibmcloud is load-balancers:

ibmcloud is load-balancers [--resource-group-id RESOURCE_GROUP_ID | --resource-group-name RESOURCE_GROUP_NAME | --all-resource-groups] [--output JSON] [-q, --quiet]

Example request using the API, list-load-balancers:

curl -X GET "$vpc_api_endpoint/v1/load_balancers?version=2024-11-12&generation=2" \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $iam_token"

Data ownership

All exported data is classified as Customer content. Therefore, full customer ownership and licensing rights apply to them, as stated in the IBM Cloud Service Agreement.