All Products
Search
Document Center

Time Series Database:Data migration solution for cloud InfluxDB

Last Updated:Jun 24, 2026

Cloud TSDB for InfluxDB is about to be discontinued, and existing data must be migrated out. This topic describes how to use the InfluxDB backup and restore tools to migrate historical data from your cloud instance to a self-hosted InfluxDB 1.x instance, shard by shard.

Important

TSDB for InfluxDB® will be officially discontinued on October 23, 2026. To ensure uninterrupted service, complete your data migration before the discontinuation date. For details about the discontinuation, see the TSDB for InfluxDB® discontinuation notice.

Prerequisites

  1. Upgrade your cloud TSDB for InfluxDB instance to version 1.8.14 or later.

  2. Submit a ticket through the Alibaba Cloud ticket system to contact technical support and enable backup port 8088.

  3. Purchase an ECS instance with the same specifications in the same region, zone, VPC, and vSwitch as your TSDB for InfluxDB instance. This ECS instance is used for the migration and to host the self-hosted InfluxDB. For more information, see Create an ECS instance.

  4. Download open-source InfluxDB 1.8.10, and complete the installation, startup, and basic configuration to serve as the self-hosted destination instance.

  5. Read the Backup and Restore section in the InfluxDB official documentation to understand the backup and restore process.

  6. Confirm that the available storage of the cloud TSDB for InfluxDB instance is at least 40%. The backup operation occupies temporary storage on the instance. If free storage is insufficient, the backup may fail and affect normal instance operations.

  7. Confirm that the memory usage of the cloud TSDB for InfluxDB instance does not exceed 60%. If memory usage exceeds 60%, upgrade the instance specifications before performing the backup and migration.

Considerations

  • Backup and restore migrates only historical data. Incremental data written after the backup is not guaranteed to be migrated. We recommend that you write data to both cloud TSDB for InfluxDB and the self-hosted InfluxDB simultaneously before you migrate historical data.

  • Backup files occupy storage space on the ECS instance hosting the self-hosted InfluxDB. Reserve at least twice the storage capacity of your data volume.

  • Data migration uses a serial import strategy by time shard. Complete the full data migration for the entire database within one time shard before starting the next time shard.

Workflow overview

Migration is performed shard by shard. The complete workflow is as follows:

  1. Confirm that all prerequisites are met.

  2. Run SHOW SHARDS to obtain information about all shards.

  3. Select a shard and run influxd backup on the ECS instance to back up the data locally.

  4. Run influxd restore to restore the backup to a temporary database on the self-hosted InfluxDB instance.

  5. Use SELECT INTO to write data from the temporary database to the destination database.

  6. Verify the integrity of the data in the destination database.

  7. Drop the temporary database.

  8. Repeat steps 3 through 7 for the remaining shards until all shards are migrated.

Procedure

View the shard list

Before performing a backup, run the following InfluxQL statement to view the information for all shards and determine the shards to migrate:

SHOW SHARDS

From the result, obtain the id, database, and retention_policy fields for each shard. These fields are used as parameters in subsequent backup commands. You must perform the backup and restore operations on each shard individually.

backup

Run the backup command on the ECS instance hosting the self-hosted InfluxDB to back up data shard by shard. You must specify the database name, retention policy name, and shard ID for each backup.

  • Syntax

    influxd backup -portable \
      -host <source instance VPC address:8088> \
      -db <database name> \
      -rp <retention policy name> \
      -shard <shard ID> \
      <backup directory>
  • Parameters

    Parameter

    Description

    -portable

    Uses the portable backup format.

    -host

    The VPC endpoint and backup port of the cloud TSDB for InfluxDB instance, in the format ts-xxx:8088.

    -db

    The name of the database to back up.

    -rp

    The name of the retention policy to back up.

    -shard

    The ID of the shard to back up. Run SHOW SHARDS to obtain shard IDs.

    <backup directory>

    The directory where backup files are saved, for example, /root/tmp/influx_backup.

  • Example

    influxd backup -portable \
      -host ts-xxx.influxdata.tsdb.aliyuncs.com:8088 \
      -db example_db \
      -rp example_rp \
      -shard 123 \
      /root/tmp/influx_backup
    Note

    In this example, replace ts-xxx.influxdata.tsdb.aliyuncs.com:8088, example_db, example_rp, 123, and /root/tmp/influx_backup with values appropriate for your actual migration scope.

restore

Refer to the official documentation to restore data to an existing database.

  1. On the ECS instance hosting the self-hosted InfluxDB, run the restore command to restore data to a temporary database.

    • Syntax

      influxd restore -portable \
        -db <backed-up database name> \
        -rp <backed-up retention policy name> \
        -shard <shard ID> \
        -newdb <temporary database name> \
        <backup directory>
      
    • Parameters

      Parameter

      Description

      -portable

      Reads the portable backup format.

      -db

      The name of the backed-up database.

      -rp

      The name of the backed-up retention policy.

      -shard

      The ID of the backed-up shard.

      -newdb

      The name of the temporary database to restore data into.

      <backup directory>

      The directory where backup data is stored, for example, /root/tmp/influx_backup.

    • Example

      influxd restore -portable \
        -db example_db \
        -rp example_rp \
        -shard 123 \
        -newdb example_tmp_db \
        /root/tmp/influx_backup
      In this example, replace example_db, example_rp, 123, example_tmp_db, and /root/tmp/influx_backup with values appropriate for your actual backup content.
  2. Use InfluxQL to query data from the temporary database and write it to the destination database.

    For large data volumes, SELECT INTO may produce incomplete data due to query timeouts. Confirm the following before execution:

    • If a query timeout is enabled (that is, INFLUXDB_COORDINATOR_QUERY_TIMEOUT is set), increase it to a sufficiently large value. InfluxDB does not enforce a query timeout by default.

    • For scenarios with large data volumes, run SELECT INTO in batches by time range to avoid timeouts on a single query.

      SELECT *
      INTO "example_db"."example_rp".:MEASUREMENT
      FROM "example_tmp_db"."example_rp"/.*/
      GROUP BY *
    /.*/ is InfluxQL regular expression syntax that matches all measurements.
  3. Verify data integrity. Query the row counts in both the temporary database and the destination database. Confirm that the data is consistent before proceeding to the next step.

    SELECT COUNT(*) FROM "example_tmp_db"."example_rp"/.*/
    SELECT COUNT(*) FROM "example_db"."example_rp"/.*/
  4. Drop the temporary database.

    DROP DATABASE "example_tmp_db";

FAQ

  • Q: Does backup and restore migrate incremental data?

    A: No, incremental data is not migrated automatically. influxd backup captures only the data that exists at the time the backup is performed. Data written after the backup completes is not included. We recommend that you write data to both cloud TSDB for InfluxDB and the self-hosted InfluxDB simultaneously before you migrate historical data.

  • Q: How do I view the specifications of my cloud TSDB for InfluxDB instance?

    A: Log on to the TSDB console and go to the Instance Details page. In the Configuration Information section, view the instance specifications, including storage capacity, CPU, database memory, disk type, and engine version.

  • Q: How do I determine whether an instance still has read or write traffic?

    A: Log on to the TSDB console and go to the Instance Monitoring page. Select Engine Monitoring. Check the Data Points Written per Second metric to confirm whether write requests are still active, and check the Queries per Second metric to confirm whether query requests are still active.

  • Q: How do I migrate to a different database?

    A: We recommend that you migrate to a self-hosted InfluxDB instance first. The migration cost is relatively low, and you can preserve your existing data model, query language, and client usage patterns. When migrating to a different database, the data model, query language, time precision, data types, and import tools may differ from InfluxDB. Evaluate and verify the migration based on the capabilities of the target database. This topic does not provide migration steps for specific databases.

References