On Thu, Mar 10, 2022 at 4:06 PM dulhaver via Barman, Backup and
Recovery Manager for PostgreSQL <pgba...@googlegroups.com
> hi Luca,
> On 10.03.22 14:34, Luca Ferrari wrote:
> On Thu, Mar 10, 2022 at 1:13 PM dulhaver via Barman, Backup and Recovery Manager for PostgreSQL <pgba...@googlegroups.com
> barman recover [postgre-server] [backup_ID] --target-time 20220310T103800 /some/path/
> Could it be that the target time is too far in the future?
> the complete recover command (maybe I should have posted that from the start) is
> barman recover postgres-local 20220310T080939 --target-time 20220310T103800 recover/
> so recovery time is 2.5 hours after the backup. Is that too far away?
No, with "too far" I meant that you could be asking the database to
resume to a time it has not seen. Is there activity on the database
after the backup or this is a test and you are not doing anything?
because it could be that you are asking to recover to some time that
did not exist in the database transaction flow. At least, this is what
seems to me since you are able to recover to the backup and not any
> hm, did we not just establish that I need to have archive_mode = off and/or archive_command - /bin/true as well as archiver = off (in barman) for streaming backups?
> In my understanding this qualifies for PostgreSQL not archiving WALs. Maybe I am not getting what you mean here by "PostgreSQL archiving WALs".
Yes, I wrote "archiving" because I did not remember you were doing
streaming. Is streaming active thus?