Skip to content

K8SPSMDB-1361 Removed oplog only requirement for PITR #240

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

K8SPSMDB-1361 Removed oplog only requirement for PITR #240

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a82b904
K8SPSMDB-1361 Removed a requirement to have oplogOnly option enabled …
nastena1606 Apr 30, 2025
d3a53f9
Reworked PITR and multiple storages wording making it clear
nastena1606 Apr 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 15 additions & 28 deletions docs/backups-pitr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,48 +1,35 @@
# Storing operations logs for point-in-time recovery

Point-in-time recovery functionality allows users to roll back the cluster to a
specific date and time. Technically, this feature involves saving operations log
updates [to the cloud storage](backups-storage.md).
Point-in-time recovery enables you to roll back your cluster to a
specific date and time. The Operator first restores a backup and then applies an operation log (oplog) - the changes that occurred to the operations up to the defined moment. To do so, the Operator saves oplog [to the cloud storage](backups-storage.md).

Starting from the Operator version 1.15.0, point-in-time recovery functionality
can be used with both logical and physical backups. Previous versions
supported point-in-time recovery only with logical backups.
Starting from the Operator version 1.15.0, you can do a point-in-time recovery from both logical and physical backups.

To be used, it requires setting the [backup.pitr.enabled](operator.md#backuppitrenabled)
To start saving oplog, set the [backup.pitr.enabled](operator.md#backuppitrenabled)
key in the `deploy/cr.yaml` configuration file:

```yaml
backup:
...
pitr:
enabled: true
oplogOnly: true
```

Setting `backup.pitr.oplogOnly` option to `true` is needed only for physical
backups. For logical backups this option can be omitted (or set to `false`,
which is the default value).
You must have a full backup to use point-in-time recovery. Without a full backup, Percona Backup for MongoDB will not upload operations logs. You must have a full backup for a new cluster and for a cluster that you restored from a backup.

It is necessary to have at least one full backup to use point-in-time recovery.
By default Percona Backup for MongoDB will not upload operations logs if there
is no full backup (`backup.pitr.oplogOnly` option controls this behavior).
The rule of having at least one full backup is true for new clusters and also
true for clusters which have been just recovered from backup.
After you enabled point-in-time recovery, it takes 10 minutes for a first oplog chunk to be uploaded. The default time period between uploads is 10 minutes. You can adjust this time by setting the new duration for the 'backup.pitr.oplogSpanMin` option.

!!! note
## Point-in-time recovery with multiple storages

There is also the 'backup.pitr.oplogSpanMin` option which sets the time
period between the uploads of oplogs, with default value of 10 minutes.
=== "Version 1.20.0 and above"

Percona Backup for MongoDB uploads operations logs to the same bucket/container,
where full backup is stored. This makes point-in-time recovery functionality
available only if there is a single bucket/container in [spec.backup.storages](operator.md#backupstoragesstorage-nametype).
Otherwise point-in-time recovery will not be enabled and there will be an error
message in the operator logs.
The Operator natively supports [multiple storages for backups](multi-storage.md) inheriting this functionality from Percona Backup for MongoDB. This allows you to enable point-in-time recovery and make backups on a storage of your choice. PBM saves oplog only to the main storage to ensure data consistency for all backups on all storages. As a result, you can [make a point-in-time restore](backups-restore.md#with-point-in-time-recovery) from any backup on any storage.

=== "Version 1.19.1 and earlier"

You must have a single storage defined in the [spec.backup.storages](operator.md#backupstoragesstorage-nametype) option to enable point-in-time recovery. This is because PBM writes oplog to the same bucket where the backup snapshot is saved.

If you defined several storages and try to enable point-in-time recovery, PBM won't know where to save oplog and can't therefore guarantee data consistency for the restore. Therefore, point-in-time recovery is not allowed for multiple storages. You will see the error message in the Operator logs.

!!! note

Adding a new bucket or container when point-in-time recovery is enabled will
not break it, but put error message about the additional bucket in the
Operator logs as well.