> ## Documentation Index > Fetch the complete documentation index at: https://paper.brimble.io/llms.txt > Use this file to discover all available pages before exploring further. # Point-in-time recovery for Postgres > Restore a Postgres database to any second in the last 7 days. Changes stream to your own bucket, and restores land in a new database so the original keeps running. Point-in-time recovery (PITR) lets you restore a Postgres database to an exact moment, for example one second before a bad migration or an accidental `DELETE`. Brimble saves every change to a bucket you own as it happens, so you're not limited to the times a backup happened to run. A restore never touches the original database. It creates a new database with the data as it was at the moment you pick, and you point your app at it when you're ready. ## Availability | | | | - | - | | **Engines** | PostgreSQL 15, 17 and 18 | | **Plans** | Any paid plan | | **Restore window** | Up to 7 days back, from the moment you turned PITR on | | **Granularity** | Any second, up to about a minute ago | | **Storage** | A [Brimble bucket](https://paper.brimble.io/object-storage/buckets.md) or an external S3-compatible bucket (AWS S3, Cloudflare R2, Tigris and others) | Other database engines don't support PITR yet. You can still restore them from regular [backups](https://paper.brimble.io/projects/deploy-a-database.md#storage-and-durability). ## How it works Once PITR is on, two things are saved to your bucket: * **Every change, continuously.** Postgres writes each change to its write-ahead log (WAL). Each finished WAL segment is uploaded to your bucket within about a minute. * **A full backup once a day.** This is the starting point a restore replays the changes on top of. Brimble takes the first one right after you turn PITR on and keeps the 8 most recent. To restore, Brimble starts a new database from the most recent full backup before your target time, then replays the saved changes up to the exact second you chose. Everything lives under one folder in your bucket: ``` //pitr/ ``` Because the files are in a bucket you control, you can see them, keep them for as long as you like, and they stay put even if something happens to the database itself. ## Before you start * **Choose your own bucket for backups.** PITR needs your database's backup destination to be a Brimble bucket or an external bucket, not the default Brimble-managed storage. Open the database, go to **Backups & Restore**, click **Configure backups** and pick a bucket. See [backups](https://paper.brimble.io/projects/deploy-a-database.md#storage-and-durability) for the options. * **Automatic backups turn off while PITR is on.** The daily full backup that PITR takes replaces them. You can still take a backup by hand at any time. ## Turn on point-in-time recovery 1. Open the database and go to **Backups & Restore**. 2. Click **Configure PITR**. 3. Click **Turn on** and confirm. Brimble takes the first full backup straight away. The restore window starts once it finishes, usually within a few minutes. Until then the drawer shows **Taking the first backup…**. Most databases switch PITR on without a restart. High-availability clusters, and databases created before PITR was available, restart once to start saving changes. Once it's on, **Backups & Restore** shows a note with the earliest moment you can restore to. ## Restore to a point in time 1. Open the database and go to **Backups & Restore**. 2. Click **Restore to a point in time**. 3. Pick the moment. Drag along the timeline, type a date and time, or use a shortcut like **5 min ago** or **1 hour ago**. The timeline runs from your earliest restore point to now, and the time is shown in your local timezone and in UTC. 4. Optionally change the **New database name**. It defaults to `-restored`. 5. Click **Restore to this moment**. The new database is usually ready in a few minutes. The restore shows up in the database's history as **Point-in-time restore**, with an **Open** link to the new database once it's done. ### What the restored database gets The new database matches the original: * The same Postgres version, region, CPU, memory and disk size. * The same high-availability setup. A three-member cluster restores into a three-member cluster. * The same TLS, public access and IP allowlist settings. * The same username and password. It gets its own connection details. Nothing changes for apps connected to the original until you point them at the new one. ### Switch your app over 1. Check the restored data, for example with the database workbench or `psql`. 2. Update your app's connection string to the new database. If the app uses a [linked database](https://paper.brimble.io/projects/deploy-a-database.md), link the restored one instead. 3. Redeploy the app. 4. Once you're happy, delete the original database, or keep it for comparison. If you only need a few rows back, you don't have to switch at all. Connect to the restored database, copy the data you need into the original, then delete the restored one. ## Turn off point-in-time recovery Open **Backups & Restore**, click **Restore to a point in time**, then **Turn off**. Brimble stops saving changes and turns automatic backups back on. Files already in your bucket stay there. Delete the `/pitr/` folder yourself if you no longer need it. ## Manage point-in-time recovery from the CLI The [Brimble CLI](https://paper.brimble.io/cli/databases.md) has the same controls under `brimble db pitr`: ```bash theme={null} # Check whether it's on and the range you can restore to brimble db pitr status my-db # Turn it on, saving to a Brimble bucket brimble db pitr enable my-db --bucket db-archive # Restore to 15 minutes ago, or to an exact UTC time brimble db pitr restore my-db --to 15m brimble db pitr restore my-db --to "2026-10-25 06:30" --name my-db-before-migration # Follow the restore in the database's history brimble db backups my-db # Turn it off brimble db pitr disable my-db ``` See [Databases in the CLI](https://paper.brimble.io/cli/databases.md) for external buckets and every flag. ## Cost PITR has no separate charge. You pay for the storage it uses in your bucket: [Brimble object storage](https://paper.brimble.io/object-storage/overview.md) rates for a Brimble bucket, or your provider's rates for an external one. How much it uses depends on how much your data changes. A database with steady writes stores roughly its full size for each of the 8 daily backups, plus all the changes written in between. Everything is compressed. ## Limitations * **The window starts when you turn it on.** You can't restore to a moment before the first full backup finished. * **Restores create a new database.** In-place restores aren't supported, so the original is never overwritten. Switching your app over is a manual step. * **One restore at a time** per source database. * **About a minute behind live.** The most recent minute of changes may not be uploaded yet. * **Postgres only** for now. * **Settings can't change while the database is applying another change**, for example a resize. Wait for it to finish, then try again. ## Troubleshooting **"Point-in-time recovery needs your own bucket."** The database still uses the default backup storage. Choose a Brimble bucket or an external bucket under **Configure backups** first. **"Point-in-time recovery is not available for this database."** The database runs an engine or version that doesn't support PITR. See [Availability](#availability). **The restore window doesn't start.** The first full backup hasn't finished. Check that the bucket exists and its credentials are still valid. An external bucket's access key needs read and write access to the bucket. **"A restore is already running for this database."** Wait for it to finish. It shows as in progress in the database's history. **Changes stopped reaching the bucket.** If the bucket is deleted or its credentials are revoked, Postgres keeps the unsent changes on its own disk until it can upload them. A long outage uses up disk space. Fix the bucket access, or turn PITR off and on again with a working bucket. ## Next steps * [Deploy a database](https://paper.brimble.io/projects/deploy-a-database.md), engines, plans, and regular backups. * [Object storage buckets](https://paper.brimble.io/object-storage/buckets.md), create a bucket for your backups. * [Storage credentials](https://paper.brimble.io/object-storage/credentials.md), manage the keys an external bucket uses. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.