Backups in Yandex MPP Analytics for PostgreSQL
Yandex MPP Analytics for PostgreSQL supports automatic and manual database backups.
For clusters running an unsupported DBMS version, restoring from backups is not available.
To restore a cluster from a backup, follow this guide. You can also restore your cluster to move its hosts to a different availability zone.
Creating a backup
The first and every seventh automatic backups as well as all manually created backups are full backups of all databases. To save space and reduce cluster load when creating a backup, other backups are incremental and only store the data that has changed since the previous backup.
A backup is automatically created once a day. You cannot disable automatic backups. However, for such backups, you can specify a time interval during which the backup will start when you create or update a cluster. The default value is 22:00 - 23:00 UTC (Coordinated Universal Time).
Once created, a backup is compressed for storage. Append-optimized tables use data deduplication technology: newly added data or old data last archived more than 30 days ago is copied. The backup size does not include the deduplicated part size, so the displayed value can be significantly smaller than the data size in the cluster.
Backups are only created on running clusters. If you are not using your Yandex MPP Analytics for PostgreSQL cluster 24/7, check the settings of backup start time.
Learn about creating manual backups in Managing backups.
Storing a backup
Storing backups in Yandex MPP Analytics for PostgreSQL:
-
Backups are stored in object storage as binary files and are encrypted using GPG. Each cluster has its own encryption keys.
-
The total backup size is a whole of data copy and WAL sizes. The backup size does not include the amount of deduplicated append-optimized table data. The size of WAL data depends on the amount of made changes and is comparable to the backup size. You can get both values with a list of backups.
-
Automatic backups are stored for seven days. Manual backups are stored until the user deletes them manually.
-
After you delete a cluster, all its backups are kept for seven days.
-
Quotas and limits for cluster storage do not apply to backup storage.
Recovery from a backup
Restoring a cluster from a backup creates a new cluster with that backup’s data. You need to specify all the cluster's settings, just as when creating a new cluster. If your folder lacks resources to create such a cluster, you will not be able to recover it from a backup.
You can also use backup recovery to move Yandex MPP Analytics for PostgreSQL cluster hosts between availability zones. Do it by specifying a new availability zone when recovering. If your cluster operates as a Yandex Data Transfer endpoint, create the endpoint and transfer again after restoring the cluster from a backup.
If you set the current time as the restore time, the new cluster will match the state of the latest available restore point.
Tip
Conduct scheduled tests of cluster recovery from backups.
Limits
When restoring a cluster from a backup, there will be restrictions on the new cluster's configuration:
- The total number of segments must be the same as in the source cluster.
- The disk size per segment in the new cluster must be at least as large as in the source cluster.
Let's assume the source cluster has four segment hosts, each containing four segments. The total number of segments is 16. When restoring the cluster, you can choose two segment hosts with eight segments per host, so that the total number of segments remains 16.
To ensure that the disk size per segment does not decrease, the disk size in each segment host must at least double.
PITR in Yandex MPP Analytics for PostgreSQL
Yandex MPP Analytics for PostgreSQL enables you to restore your cluster to a specific recovery point where the data is consistent. This feature is known as Point-in-Time-Recovery (PITR). Recovery points are created every hour. When you specify a time to recover data for, the service will use the backup closest to that point in time. When recovering the selected cluster backup, records from write-ahead logs (WALs) will be added to the backup data up to the closest recovery point.
For example, if the backup was created on November 10, 2022, 12:00:00 UTC, the current date is November 15, 2022, 19:00:00 UTC, and the latest recovery point was saved on November 15, 2022, 18:00:00 UTC, the cluster can be restored to any recovery point between November 10, 2022, 12:00:01 UTC and November 15, 2022, 18:00:00 UTC, inclusive. If you specify November 15, 2022, 17:30:00 UTC as the recovery time, the cluster will be restored to the recovery point saved on November 15, 2022, 17:00:00 UTC.
PITR mode is enabled by default. It only supports automatic backups.