Please, answer some short questions which should help us to understand your problem / question better?
Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.6.3
Where do you run it - cloud or metal? Kubernetes or OpenShift? Bare Metal K8s
Are you running Postgres Operator in production? yes
Type of issue? Bug report
I truncated the wrong schema in a production database (as smart people do) and I am trying to do a point-intime recovery.
I was able to recreate a backup cluster on a different namespace, and I am to see that data. Want I want to do is make sure that no data is missed between the time I recovered to the time I truncated. I can't figure out the exact time I did the truncate using pg_waldump so I decided to step one second by modifying clone.timestamp 1 second at a time unless I can't find the data. But it seems like changing the timestamp and re-applying the crd doesn't d the trick. And deleting and recreating the crd, takes too long because it needs to re-download and extract the base backup...
Is there a smarter way to creep forward until I reach the correct timestamp ? Could the operator be fixed to do that as one would expect ?
Please, answer some short questions which should help us to understand your problem / question better?
I truncated the wrong schema in a production database (as smart people do) and I am trying to do a point-intime recovery. I was able to recreate a backup cluster on a different namespace, and I am to see that data. Want I want to do is make sure that no data is missed between the time I recovered to the time I truncated. I can't figure out the exact time I did the truncate using
pg_waldumpso I decided to step one second by modifyingclone.timestamp1 second at a time unless I can't find the data. But it seems like changing the timestamp and re-applying the crd doesn't d the trick. And deleting and recreating the crd, takes too long because it needs to re-download and extract the base backup...Is there a smarter way to creep forward until I reach the correct timestamp ? Could the operator be fixed to do that as one would expect ?