Guides

Timestream backups: restore without a ticket

Customers can manage their own Influx backups in Amazon Timestream. Restoring to a new resource is safe; replace mode deletes the current data.

By Alec Chizhik August 26, 2026 4 min read

Timestream backups: restore without a ticket

Restoring an Influx instance in Amazon Timestream used to require a support ticket. Now restore is available in the console, right beside the button that overwrites the running instance.

Key takeaways

Your own copies without the ticket queue. InfluxDB 2 and 3 support on-demand backups and up to four schedules. The first backup is a full copy; AWS then stores only changes.
A new resource leaves the old one intact. REPLACE_EXISTING deletes the current data. IAM (Identity and Access Management) can block this specific mode.
Your own schedule does not replace ticket-based backups. Recent writes may be missing, region changes are unavailable, and AWS Backup does not cover InfluxDB.

Related:AWS Identity Center: multi-region is now part of setup / Supply chains break at the data path between MES and ERP

Restores depended on support

Amazon Timestream stores time series. Users running InfluxDB as a managed service there already had internal copies. Access required a ticket. On 7 August 2026, AWS put users in control: their own backups and restores, through the console, command line or API. This applies to InfluxDB 2 and InfluxDB 3.

The existing service-managed copies remain. AWS still controls them and provides access only through support. The service retains internal copies for around a day and snapshots for around 30 days after a resource is deleted. Neither replaces a backup plan you control. Both approaches can run in parallel.

Previously, anyone preparing a version upgrade or instance reconfiguration faced the support queue. Now a backup can run immediately before the risky step. The benefit is direct access. The database remains the same.

Four schedules, one initial full backup

AWS allows at most four automated configurations per instance or cluster. Hourly, daily, weekly, monthly or a custom cron schedule, each with its own retention period. The first backup copies everything. Subsequent backups are incremental, storing only changes.

For everyday use, frequent backups with short retention often suffice, alongside less frequent backups for scenarios nobody checks every morning. Scheduled backups may start up to an hour late. Under load, the initial full backup takes longer, while the instance remains accessible.

The price list shows no additional feature charge; customers pay for backup storage, through EBS for InfluxDB 2 and S3 for InfluxDB 3. Deleting a resource removes automated backups; on-demand copies remain. Keeping automated backups requires an explicit setting during deletion.

A new instance leaves the old one intact

The recommended restore creates a new resource. The running instance remains untouched. Without additional settings, the new copy inherits the backup’s configuration. A single instance can be restored to a read-replica cluster. The reverse is unavailable: a cluster backup cannot be restored to a single instance.

This is the approach for changes you may need to reverse. The old instance remains available to verify the restore against. Only once the new copy responds do you decide what happens to the old one.

The same button overwrites production

REPLACE_EXISTING restores the backup to the existing resource. The instance is inaccessible during restoration. Existing data is deleted and replaced with the backup’s contents. If restoration fails, the service attempts a rollback. AWS recommends taking a fresh on-demand backup beforehand. Without that copy, the previous data is gone afterwards.

IAM can block this specific mode. The condition checks the restore mode and denies REPLACE_EXISTING. Teams sharing console access should apply the restriction before the first emergency.

Recent writes are left out

A backup does not capture the very latest data. InfluxDB 3 may omit writes from approximately the last 15 minutes. Point-in-time recovery requires a continuously active configuration and a timestamp at least a quarter of an hour in the past.

InfluxDB 2 has an additional gap when restoring a single instance to a read-replica cluster. Only data already in TSM files is included. Anything still in the write-ahead log is excluded. The threshold is roughly ten minutes without writes or 25 megabytes of cache. An almost empty or sparsely written instance may arrive as an empty database. Restoring to another single instance includes the WAL contents.

Cross-region and cross-account restores are unavailable. Backups and restores stay within the same account and region. AWS Backup, the central service for other tables in Timestream LiveAnalytics, does not cover InfluxDB. A copy in a second region requires a separate approach outside this feature.

The command line and API can trigger the same operation as the console. The console suffices for the first schedule. CLI command names belong in the runbook. The decision comes first.

Frequently asked questions

What’s new in Timestream backups for InfluxDB?

Since 7 August 2026, users can create and restore backups themselves without a support ticket. This applies to InfluxDB 2 and InfluxDB 3.

How many backup schedules can an instance have?

At most four automated configurations, plus unlimited on-demand backups. Each configuration has its own retention period.

Which restore mode leaves the running instance untouched?

Restoring to a new resource. REPLACE_EXISTING overwrites the existing instance and makes it inaccessible during restoration.

Are the most recent minutes always included?

No. InfluxDB 3 may omit around 15 minutes. When restoring a single instance to a replica cluster, InfluxDB 2 excludes data still in the write-ahead log.

Do my own backups replace service-managed copies?

No. AWS continues to maintain service-managed copies. Access still requires a ticket. Both approaches can run in parallel.

Editor’s Picks

AWS Identity Center: Multi-Region Now Integrated into Setup
Data Sovereignty, AI Model Dependency
Cloudflare Turns HTTP 402 into a Paywall for AI Agents