---
title: "fly mpg restore now supports naming and point-in-time restore"
description: "fly mpg restore can now restore to a point in time and name the restored cluster."
date: "2026-08-10"
author: "Vincent Charlebois"
url: "https://fly.io/changelog/managed-postgres-point-in-time-restore/"
discussion: "https://community.fly.io/t/fly-mpg-restore-now-supports-naming-and-point-in-time-restore/28464"
---

# fly mpg restore now supports naming and point-in-time restore

Here are a couple of things you could already do from the dashboard that are now available in `fly mpg restore` as of flyctl v0.4.80:

* restoring to a specific point in time instead of a backup ID
* naming your restored cluster

**Restoring to a point in time**

Pass `--pitr-time` with a timestamp instead of `--backup-id`:

`fly mpg restore <CLUSTER_ID> --pitr-time 2026-08-09T14:30:00Z`

Useful for getting back to right before a bad migration or accidental delete. A few things to know:

* The timestamp has to fall inside your cluster's PITR recovery window.
* You can pass `--backup-id` or `--pitr-time`, not both.
* PITR restore is available for v2 clusters only. The CLI returns a clear error if you try it on v1.
* Timestamps are RFC3339 with an explicit offset: `2026-08-09T14:30:00Z` for UTC, or `2026-08-09T10:30:00-04:00`.

**Naming the restored cluster**

Use `--name` with either restore mode:

`fly mpg restore <CLUSTER_ID> --backup-id <BACKUP_ID> --name my-cluster-recovered`

Leave `--name` off and you get the same auto-generated name as before.

Either way, your source cluster stays untouched. A restore always creates a new cluster, billed separately.

If the PITR window isn't what you expected, tell us. We'd like to hear what your ideal recovery workflow looks like.