Yandex Cloud
Search
Discuss with expertTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Managed Service for Sharded PostgreSQL
  • Getting started
    • Resource relationships
    • Sharding
    • Sharding keys
    • Selecting a sharding strategy
    • Host classes
    • Storage in Sharded PostgreSQL
    • Backups
    • Quotas and limits
    • Sharded PostgreSQL settings
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Public materials
  • Release notes
  • FAQ

In this article:

  • Creating a backup
  • Storing a backup
  • Recovery from a backup
  1. Concepts
  2. Backups

Backups in Managed Service for Sharded PostgreSQL

Written by
Yandex Cloud
Updated at May 29, 2026
  • Creating a backup
  • Storing a backup
  • Recovery from a backup

Managed Service for Sharded PostgreSQL supports automatic and manual database backups.

To restore a cluster from a backup, follow this guide.

Creating a backupCreating a backup

You can create backups either automatically or manually. In both cases, you get a full backup of shard configuration (metadata storage) for INFRA or COORDINATOR hosts.

Shard backups are based on the settings of their respective Managed Service for PostgreSQL clusters. For more information, see Backups in Managed Service for PostgreSQL.

A cluster backup is automatically created once a day. You cannot disable automatic backups. However, when creating or editing a cluster, you can set the following parameters for automatic backups:

  • Retention time.
  • Time interval during which the backup starts. The default value is 22:00 - 23:00 UTC (Coordinated Universal Time).

Once created, a backup is compressed for storage. To find out its exact size, request a list of backups.

Backups are created only on running Managed Service for Sharded PostgreSQL clusters. If not using your cluster 24/7, check the settings to make sure that backups take place during the cluster's active hours.

Learn about creating manual backups in Managing backups.

Storing a backupStoring a backup

Backups are stored in Object Storage as binaries and do not take up space in the cluster storage. Quotas and limits for cluster storage do not apply to backup storage.

Before they are moved to object storage, all backups are encrypted using GPG. Each cluster has its own encryption keys.

The retention time for backups of an existing cluster depends on the way they were created:

  • Automatic backups are stored for 7 days by default. When creating or reconfiguring a cluster, you can specify a different retention period between 7 and 60 days.

  • Manual backups are stored with no time limit.

After you delete a cluster, all its backups are kept for seven days.

Recovery from a backupRecovery from a backup

By restoring a cluster from a backup, you create a new cluster. You need to specify all the cluster's settings, just as when creating a new cluster. Regardless of the original cluster’s sharding type, you can restore a cluster with either standard or advanced sharding. If your folder lacks resources to create such a cluster, you will not be able to restore from the backup.

Managed Service for Sharded PostgreSQL allows you to restore the cluster state to any point in time since the oldest full backup was created. For this purpose, this backup is updated with archived entries from the coordinator's metadata storage. In a running cluster, metadata storage is continuously archived every five minutes. Then archived entries are uploaded to object storage.

For example, if a backup operation completed on August 10, 2025 at 12:00:00 UTC, and the latest metadata storage backup was saved on August 15, 2025, at 18:50:00 UTC, the cluster can be restored to any of its states within the time interval from August 10, 2025, 12:00:01 UTC to August 15, 2025, 18:50:00 UTC, inclusive.

The new cluster will reflect the state of:

  • Existing cluster at the time of the latest backup of the coordinator's metadata storage.
  • Deleted cluster at the time of the latest metadata archiving.

After restoring your cluster, you can add shards to it:

  • Based on existing PostgreSQL clusters.
  • Based on PostgreSQL clusters restored from backups to a selected point in time. For more information, see Restoring a PostgreSQL cluster.

The restored cluster's shards must match the original cluster's shards at the time of creating the backup.

Tip

Periodically test the recovery of production system clusters. Verify metadata integrity in the restored cluster.

Was the article helpful?

Previous
Storage in Sharded PostgreSQL
Next
Quotas and limits
© 2026 Direct Cursus Technology L.L.C.