v2026.1 STS Stable release with standard-term support v2025.2 LTS Stable release with long-term support v2025.1 STS Stable release with standard-term support v2024.2 LTS Stable release with long-term support v2.20 LTS Stable release with long-term support Unsupported versions

Restore to PIT

Restore from a YugabyteDB snapshot to a specific point in time
Which PITR method should I use?
To decide which point-in-time feature is right for your use case, refer to The PIT recovery family.

Restore to PIT restores from a backup or snapshot to a user-specified point in time. Unlike Rewind to PIT, which rewinds the live database in place using a snapshot schedule, Restore to PIT starts from a snapshot or backup and applies flashback to the chosen time. You can restore on the original cluster or on an alternate cluster.

Advanced workflow

Moving a distributed snapshot between clusters is a multi-step procedure (for YSQL, it includes a ysql_dump of the schema).

In addition, restore_snapshot does not prevent you from choosing an unsafe restore time. Restoring across a DDL boundary, or to a time outside the snapshot's retained history, can produce unexpected results. There is no check that the target time is recoverable.

Prefer Rewind to PIT or Clone to PIT for in-cluster recovery.

Use YugabyteDB Anywhere
YugabyteDB Anywhere provides managed Restore to PIT using PITR-enabled backups. You can restore to the original universe or to an alternate universe, and optionally rename databases or keyspaces, with guardrails for DDL changes and history retention. See Restore universe data.

Restore to PIT on a manually managed cluster

You should use this only if you are building a custom backup and restore workflow and cannot use YugabyteDB Anywhere.

DDL boundary and history retention

You cannot restore to a point in time earlier than the most recent DDL change that precedes the snapshot. If a DDL change (for example, DROP TABLE) occurs at time t1 and a snapshot is taken at t2, you cannot restore to a time before t1.

A single snapshot also cannot recover data outside its history retention window. The snapshot retains change history only for a limited period before t2 (see history retention), so it may not include all data written after t1. Restore only to a time that is both after that DDL and within the snapshot's retained history.

Mitigation: Before making DDL changes, take a manual ad hoc snapshot or backup.

For restoring to the snapshot creation time only (no point-in-time target), see Restore a snapshot.

Restore on the same cluster

If the snapshot is already on the cluster, use restore_snapshot. The optional restore target selects the point in time; omit it to restore to the snapshot's creation time.

yb-admin \
    --master_addresses <master-addresses> \
    restore_snapshot <snapshot-id> [<restore-target>]
  • snapshot-id: The identifier for the snapshot.
  • restore-target: Optional. A timestamp at or before the snapshot's creation time. Absolute Unix timestamp in microseconds, or a relative time such as minus 5m.

For example:

./bin/yb-admin \
    --master_addresses <ip1:7100,ip2:7100,ip3:7100> \
    restore_snapshot 72ad2eb1-65a2-4e88-a448-7ef4418bc469 1681964544554620

./bin/yb-admin \
    --master_addresses <ip1:7100,ip2:7100,ip3:7100> \
    restore_snapshot 72ad2eb1-65a2-4e88-a448-7ef4418bc469 minus 5m

When the restore starts, the snapshot_id and a generated restoration_id are displayed. Check progress using list_snapshots or list_snapshot_restorations.

Restore on another cluster

Importing a distributed snapshot into a different cluster is not a single command. You must export metadata, copy tablet snapshot files from every node, recreate schema, import the snapshot, and remap tablet IDs before you can call restore_snapshot.

For YSQL, that workflow includes a schema-only ysql_dump taken at the same catalog version as the snapshot. Without that dump, you cannot recreate the database on the target cluster.

Follow the full procedures, then pass a restore target on the final restore_snapshot if you need a time other than the snapshot's creation time:

  1. Move a snapshot to external storage (YSQL: includes yb_catalog_version checks and ysql_dump).
  2. Restore a snapshot from external storage (YSQL: apply the dump with ysqlsh, then import_snapshot, then copy tablet files using the old-to-new ID mapping).
  3. Run restore_snapshot as shown in Restore on the same cluster.

The YCQL procedure is the same shape without the dump; see Distributed snapshots for YCQL.

Surgical recovery

When recent production writes must be preserved and you cannot clone on the production cluster, a typical recovery is:

  1. Restore the snapshot or backup to an alternate cluster as of a time just before the error.
  2. Optionally use Inspect at PIT on that restored database to search across candidate times.
  3. Extract the needed rows or objects.
  4. Import and merge them back into the production database.

On a manually managed cluster, step 1 is the off-cluster restore procedure. In YugabyteDB Anywhere, restore the PITR-enabled backup to another universe instead; see Restore from backup.