--- title: "Restore to PIT" url: "https://docs.yugabyte.com/stable/manage/backup-restore/point-in-time-recovery/restore/" --- # Restore to PIT Restore from a YugabyteDB snapshot or backup to a specific point in time 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](/stable/manage/backup-restore/point-in-time-recovery/#the-pit-recovery-family "The PIT recovery family"). Restore to PIT restores from a backup or snapshot to a user-specified point in time. Unlike [Rewind to PIT](/stable/manage/backup-restore/point-in-time-recovery/rewind/ "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](/stable/manage/backup-restore/point-in-time-recovery/rewind/ "Rewind to PIT") or [Clone to PIT](/stable/manage/backup-restore/point-in-time-recovery/clone/ "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](/stable/yugabyte-platform/back-up-restore-universes/restore-universe-data/#restore-from-backup "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](/stable/manage/backup-restore/point-in-time-recovery/enable-pitr/#configuration-details "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](/stable/manage/backup-restore/snapshot-ysql/#restore-a-snapshot "Restore a snapshot"). ### Restore on the same cluster If the snapshot is already on the cluster, use [restore\_snapshot](/stable/admin/yb-admin/#restore-snapshot "restore_snapshot"). The optional restore target selects the point in time; omit it to restore to the snapshot's creation time. ```sh yb-admin \ --master_addresses \ restore_snapshot [] ``` - *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: ```sh ./bin/yb-admin \ --master_addresses \ restore_snapshot 72ad2eb1-65a2-4e88-a448-7ef4418bc469 1681964544554620 ``` ```sh ./bin/yb-admin \ --master_addresses \ 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](/stable/admin/yb-admin/#list-snapshots "list_snapshots") or [list\_snapshot\_restorations](/stable/admin/yb-admin/#list-snapshot-restorations "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](/stable/admin/ysql-dump "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](/stable/manage/backup-restore/snapshot-ysql/#move-a-snapshot-to-external-storage "Move a snapshot to external storage") (YSQL: includes `yb_catalog_version` checks and `ysql_dump`). 2. [Restore a snapshot from external storage](/stable/manage/backup-restore/snapshot-ysql/#restore-a-snapshot-from-external-storage "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](#restore-on-the-same-cluster "Restore on the same cluster"). The YCQL procedure is the same shape without the dump; see [Distributed snapshots for YCQL](/stable/manage/backup-restore/snapshot-ycql/#restore-a-snapshot-from-external-storage "Distributed snapshots for YCQL"). ### Surgical recovery When recent production writes must be preserved and you cannot [clone](/stable/manage/backup-restore/point-in-time-recovery/clone/ "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](/stable/manage/backup-restore/point-in-time-recovery/inspect/ "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](#restore-on-another-cluster "off-cluster restore procedure"). In YugabyteDB Anywhere, restore the PITR-enabled backup to another universe instead; see [Restore from backup](/stable/yugabyte-platform/back-up-restore-universes/restore-universe-data/#restore-from-backup "Restore from backup").