---
title: Back up and recover services | Tiger Data Docs
description: Protect your data with automatic backups, cross-region protection, and point-in-time recovery
---

Tiger Cloud provides comprehensive backup and recovery solutions to protect your data, including automatic daily backups, cross-region protection, and point-in-time recovery.

## Automatic backups

Tiger Cloud automatically handles backup for your Tiger Cloud services using the `pgBackRest` tool. You don’t need to perform backups manually. What’s more, with [cross-region backup](#enable-cross-region-backup), you are protected when an entire AWS region goes down.

Tiger Cloud automatically creates one full backup every week, and incremental backups every day in the same region as your service. Additionally, all [Write-Ahead Log (WAL)](https://www.postgresql.org/docs/current/wal-intro.html) files are retained back to the oldest full backup. This means that you always have a full backup available for the current and previous week:

![Database backup and recovery architecture in Tiger Cloud](/docs/_astro/database-backup-recovery.DHoYmo-Y_Z1NJvh0.webp)

On [Scale and Enterprise](/docs/deploy/tiger-cloud/tiger-cloud-aws/pricing-and-account-management/index.md) pricing plans, you can check the list of backups for the previous 14 days in Tiger Console. To do so, select your service, then click `Operations` > `Backup and restore` > `Backup history`.

In the event of a storage failure, a service automatically recovers from a backup to the point of failure. If the whole availability zone goes down, your Tiger Cloud services are recovered in a different zone. In the event of a user error, you can [create a point-in-time recovery fork](#create-a-point-in-time-recovery-fork).

## Enable cross-region backup

Note

Cross-region backup is available on [Enterprise](/docs/deploy/tiger-cloud/tiger-cloud-aws/pricing-and-account-management/index.md) pricing plan.

For added reliability, you can enable cross-region backup. This protects your data when an entire AWS region goes down. In this case, you have two identical backups of your service at any time, but one of them is in a different AWS region. Cross-region backups are updated daily and weekly in the same way as a regular backup. You can have one cross-region backup for a service.

You enable cross-region backup when you create a service, or configure it for an existing service in Tiger Console:

1. **Select your service and open backup settings**

   In [Console](https://console.cloud.tigerdata.com/dashboard/services), select your service and click `Operations` > `Backup & restore`.

2. **Enable cross-region backup**

   In `Cross-region backup`, select the region in the dropdown and click `Enable backup`.

   ![Creating a cross-region backup in Tiger Console](/docs/_astro/create-cross-region-backup-in-tiger-console.BHzXdG8r_Z1UYiMM.webp)

   You can now see the backup, its region, and creation date in a list.

You can have one cross-region backup per service. To change the region of your backup:

1. **Open backup settings for your service**

   In [Console](https://console.cloud.tigerdata.com/dashboard/services), select your service and click `Operations` > `Backup & restore`.

2. **Disable the existing backup**

   Click the trash icon next to the existing backup to disable it.

   ![Cross-region backup list in Tiger Console](/docs/_astro/cross-region-backup-list-in-tiger-console.BmAYZaTL_olwP6.webp)

3. **Create a new backup in a different region**

## Create a point-in-time recovery fork

To recover your service from a destructive or unwanted action, create a point-in-time recovery fork. You can recover a service to any point within the period [defined by your pricing plan](/docs/deploy/tiger-cloud/tiger-cloud-aws/pricing-and-account-management/index.md). The original service stays untouched to avoid losing data created since the time of recovery.

Since the point-in-time recovery is done in a fork, to migrate your application to the point of recovery, change the connection strings in your application to use the fork. The provision time for the recovery fork is typically less than twenty minutes, but can take longer depending on the amount of WAL to be replayed.

To avoid paying for compute for the recovery fork and the original service, pause the original to only pay storage costs.

You initiate a point-in-time recovery from a same-region or cross-region backup in Tiger Console:

- [Same-region backup](#tab-panel-497)
- [Cross-region backup](#tab-panel-498)

1. **Ensure the service is running or paused**

   In [Tiger Console](https://console.cloud.tigerdata.com/dashboard/services), from the `Services` list, ensure the service you want to recover has a status of `Running` or `Paused`.

2. **Create a recovery fork**

   Navigate to `Operations` > `Service management` and click `Create recovery fork`.

3. **Select the recovery point**

   Select the recovery point, ensuring the correct time zone (UTC offset).

4. **Configure the fork**

   ![Creating a recovery fork in Tiger Console](/docs/_astro/create-recovery-fork-tiger-console.DLtDJBfR_ZWgTG1.webp)

   You can configure the compute resources, add an HA replica, tag your fork, and add a connection pooler. Best practice is to match the same configuration you had at the point you want to recover to.

5. **Confirm the recovery fork**

   Confirm by clicking `Create recovery fork`.

   A fork of the service is created. The recovered service shows in `Services` with a label specifying which service it has been forked from.

6. **Update the connection strings in your app**

   Since the point-in-time recovery is done in a fork, to migrate your application to the point of recovery, change the connection strings in your application to use the fork.

[Contact us](mailto:support@tigerdata.com), and we will assist in recovering your service.

## Create a service fork

To manage development forks:

1. **Install Tiger CLI**

   Use the terminal to install the CLI:

   - [Debian](#tab-panel-490)
   - [Ubuntu](#tab-panel-491)
   - [Red Hat](#tab-panel-492)
   - [Fedora](#tab-panel-493)
   - [MacOS](#tab-panel-494)
   - [Windows PowerShell](#tab-panel-495)
   - [x-platform](#tab-panel-496)

   Terminal window

   ```
   curl -s https://packagecloud.io/install/repositories/timescale/tiger-cli/script.deb.sh | sudo os=any dist=any bash
   sudo apt-get install tiger-cli
   ```

   Terminal window

   ```
   curl -s https://packagecloud.io/install/repositories/timescale/tiger-cli/script.deb.sh | sudo os=any dist=any bash
   sudo apt-get install tiger-cli
   ```

   Terminal window

   ```
   curl -s https://packagecloud.io/install/repositories/timescale/tiger-cli/script.rpm.sh | sudo os=rpm_any dist=rpm_any bash
   sudo yum install tiger-cli
   ```

   Terminal window

   ```
   curl -s https://packagecloud.io/install/repositories/timescale/tiger-cli/script.rpm.sh | sudo os=rpm_any dist=rpm_any bash
   sudo yum install tiger-cli
   ```

   Terminal window

   ```
   brew install --cask timescale/tap/tiger-cli
   ```

   Terminal window

   ```
   irm https://cli.tigerdata.com/install.ps1 | iex
   ```

   Terminal window

   ```
   curl -fsSL https://cli.tigerdata.com | sh
   ```

2. **Set up API credentials**

   1. Log Tiger CLI into your Tiger Cloud account:
      ```
      tiger auth login
      ```
      Tiger CLI opens Console in your browser. Log in, then click `Authorize`. You can have a maximum of 10 active client credentials. If you get an error, open [credentials](https://console.cloud.tigerdata.com/dashboard/settings) and delete an unused credential.
   2. Select a Tiger Cloud project:
      ```
      Auth URL is: https://console.cloud.tigerdata.com/oauth/authorize?client_id=lotsOfURLstuff
      Opening browser for authentication...
      Select a project:

      > 1. Tiger Project (tgrproject)
      2. YourCompany (Company wide project) (cpnproject)
      3. YourCompany Department (dptproject)

      Use ↑/↓ arrows or number keys to navigate, enter to select, q to quit
      ```
      If only one project is associated with your account, this step is not shown. Where possible, Tiger CLI stores your authentication information in the system keychain/credential manager. If that fails, the credentials are stored in `~/.config/tiger/credentials` with restricted file permissions (600). By default, Tiger CLI stores your configuration in `~/.config/tiger/config.yaml`.

3. **Test your authenticated connection to Tiger Cloud by listing services**

   Terminal window

   ```
   tiger service list
   ```

   This call returns something like:

   - No services:

     ```
     🏜️  No services found! Your project is looking a bit empty.
     🚀 Ready to get started? Create your first service with: tiger service create
     ```

   - One or more services:

     ```
     ┌────────────┬─────────────────────┬────────┬─────────────┬──────────────┬──────────────────┐
     │ SERVICE ID │        NAME         │ STATUS │    TYPE     │    REGION    │     CREATED      │
     ├────────────┼─────────────────────┼────────┼─────────────┼──────────────┼──────────────────┤
     │ tgrservice │ tiger-agent-service │ READY  │ TIMESCALEDB │ eu-central-1 │ 2025-09-25 16:09 │
     └────────────┴─────────────────────┴────────┴─────────────┴──────────────┴──────────────────┘
     ```

4. **Fork the service**

   Terminal window

   ```
    tiger service fork tgrservice --now --no-wait --name bob
   ```

   You must specify exactly one timing option: `--now` (fork at current state), `--last-snapshot` (fork at last snapshot, faster), or `--to-timestamp` (fork at specific point in time). By default a fork matches the resources of the parent Tiger Cloud service. For paid plans, specify `--cpu` and/or `--memory` for dedicated resources.

   You see something like:

   ```
   🍴 Forking service 'tgrservice' to create 'bob' at current state...
   ✅ Fork request accepted!
   📋 New Service ID: <service_id>
   🔐 Password saved to system keyring for automatic authentication
   🎯 Set service '<service_id>' as default service.
   ⏳ Service is being forked. Use 'tiger service list' to check status.
   ┌───────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┐
   │     PROPERTY      │                                              VALUE                                               │
   ├───────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤
   │ Service ID        │ <service_id>                                                                                       │
   │ Name              │ bob                                                                                              │
   │ Status            │                                                                                                  │
   │ Type              │ TIMESCALEDB                                                                                      │
   │ Region            │ eu-central-1                                                                                     │
   │ CPU               │ 0.5 cores (500m)                                                                                 │
   │ Memory            │ 2 GB                                                                                             │
   │ Direct Endpoint   │ <service-id>.<project-id>.tsdb.cloud.timescale.com:<port>                                             │
   │ Created           │ 2025-10-08 13:58:07 UTC                                                                          │
   │ Connection String │ postgresql://tsdbadmin@<service-id>.<project-id>.tsdb.cloud.timescale.com:<port>/tsdb?sslmode=require │
   └───────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┘
   ```

5. **When you are done, delete your forked service**

   1. Use the CLI to request service delete:
      ```
      tiger service delete <service_id>
      ```

   2. Validate the service delete:

      ```
      Are you sure you want to delete service ‘<service_id>’? This operation cannot be undone.
      Type the service ID ‘<service_id>’ to confirm:
      <service_id>
      ```

      You see something like:

      ```
      🗑️  Delete request accepted for service ‘<service_id>’.
      ✅ Service ‘<service_id>’ has been successfully deleted.
      ```