Skip to main content
Important: We are not able to provide support or guidance for unmanaged Postgres. We now offer Fly.io Managed Postgres , our fully-managed database service that handles all aspects of running production PostgreSQL databases.
An important part of running any production db-backed application is making sure your data is backed up and safe, and if the unspeakable happens, it’s straightforward to restore data and get back up and running. Postgres databases on Fly.io are treated as Fly Apps, which you can read more about in the docs. What that means is backing up data is an exercise in taking snapshots of the Postgres app’s volumes, then restoring the snapshots to a new database server, verifying the restoration, and connecting the application to the restored database.

​
Finding the database app instance

If you set up your application using fly launch, the name of your database app might be <app-name>-db, or you might have given it a name during the initial configuration. To find the name of your Postgres app, run:
Look for your database app under the NAME column. In this example, my-app-db is the value to use for <postgres-app-name> in the following commands.

​
Listing snapshots

Fly.io performs daily storage-based snapshots of each of your provisioned volumes. These snapshots can be used to restore your dataset into a new Postgres application. Snapshots are volume specific, so you need to identify the volume whose snapshot you want to restore from. You can list your volumes by running the volumes list command with your Postgres app name.
The number of volumes varies depending on how many database replicas were elected when provisioning the database. One primary database and one replica yields 2 volumes. Once you have identified which volume to target, you can list its snapshots:
The values under the ID columns are what will be used to restore a snapshot.

​
Identifying your Postgres image version

Depending on when you created your Postgres cluster, it may be running an older image than the default for newly created clusters. Different Postgres major versions may not be fully compatible, so it’s important to use the same version for your restored cluster. To see your Postgres image and version, run fly image show.
The values under the REPOSITORY and TAG columns reference the image you’ll use to restore the snapshot. Legacy postgres images use the flyio/postgres repository, while new Postgres Flex images use the flyio/postgres-flex repository. Join the two values with a colon to form the image reference: in the above example, the machine is running a legacy flyio/postgres:14.6 image.

​
Restoring from a snapshot

To restore a Postgres application from a snapshot, simply specify the --snapshot-id argument and the --image-ref argument when running the create command as shown below:
This provisions and launches a new Fly Postgres database server with the specified snapshot and the same image as your existing database.
Important: The size of the volume provisioned for the new Fly Postgres application must be equal to or greater than the volume from where the snapshot was taken.

​
Connect the Restored Database

Detach the web application from the current Postgres cluster:
Then attach it to the new cluster:
Now your application is pointing at the restored database.