MySQL PITR limitation in Everest

Percona Everest
1

Hi,
I’m testing Everest’s Point in time restore feature for MySQL. According to the interface, PITR can only be done for a point in time between the last full backup and the latest transaction:

image
image797×425 28.3 KB

Is there a way to do a PITR to a point earlier than the last full backup?
I can see this scenario happening: a user empty a table at 12:55. The full backup runs at 13:00. I get the request to restore at 13:05. How can I restore to database state at 12:54?

Thank you

2 Likes
2

In this case, you should have taken a full backup earlier to empty a table at 12:55 (you can check the previous day’s full backup taken at 13:00) and then perform a PITR from the last day’s full backup until 12:54.

2 Likes
3

Hi,
Yes, of course. Let’s assume there is a daily backup taken at 13:00, so we have a full backup prior to the disaster.

My problem is: how to do the point in time restore, considering that Everest only allow pitr from the latest backup? I need to go back to the second last backup in this scenario.

Thank you

1 Like
4

PITR before the latest backup is not available right now.

We have created a request
https://perconadev.atlassian.net/browse/EVEREST-2196
Thanks for reporting that.

1 Like
5

Hi,

Considering the current limitation in Everest regarding PITR restores, could I bypass Everest and interact directly with the operator to perform a point in time restore to an existing database cluster created by Everest without interfering with Everest operations?

Thank you!

1 Like
6

Create database cluster restore Perhaps worth investigating for your situation, if you use this POST call from the API in the SPEC object you can specify the full backup you want to use as your base with the ‘dbClusterBackupName’ variable. I was able to recover from an older backup using this method.