Managed Service for MongoDB provides automatic and manual database backups. Backups take up space in the storage allocated to the cluster. If the total amount of data and backups exceeds the amount of storage, the excess is billed.
You can recover the cluster data from a given point in time (Point-in-Time-Recovery, PITR). The cluster must meet the following criteria:
- MongoDB version in the cluster: 4.2 or higher.
- Sharding is enabled. PITR works only for a cluster with a single replica set.
Managed Service for MongoDB allows you to restore the cluster state from any point in time from the creation of the oldest backup to the present. For this purpose, the backup selected as the starting point of recovery is updated by
oplog entries for the later backups and the cluster itself.
Learn more about PITR and its limitations in the MongoDB documentation.
To restore a cluster from a backup, follow the instructions.
Backups can be automatic or manual:
- The first backup and every seventh backup are full backups of all databases.
- Other backups are incremental and only store data that has changed since the previous backup to save storage space.
- Storage time.
- Backup start time. The backup will start within half an hour of the specified time. By default, the backup process starts at 22:00 UTC (Coordinated Universal Time).
To learn how to manually create a backup, see Managing backups.
Storing backups in Managed Service for MongoDB:
- Backups are stored in Yandex internal storage as logical dumps and are encrypted using GPG. Each cluster has its own encryption keys.
- Backups are compressed to ensure compact storage. To find out the total backup size stored, request a list of backups.
- Automatic backups are stored for 7 days by default. When creating or editing a cluster, you can set a different storage period in the range from 7 to 35 days. Automatic backups are deleted when the storage period expires. This feature is at the Preview stage.
- Manual backups are stored indefinitely. This feature is at the Preview stage stage.
Checking backup integrity
Backup integrity is checked on synthetic data using integration tests available in the service. For user clusters, backups currently aren't checked.
Checking backup recovery
To test the backup feature, restore a cluster from a backup and check the integrity of your data.