Point-In-Time Recovery issue - Timeline file lost

[300359] LOG: starting point-in-time recovery to WAL location (LSN) "7D2/15FFFEB8" 2024-01-05 12:19:30.468 -03 [300359] LOG: invalid primary checkpoint record 2024-01-05 12:19:30.468 -03 [300359] PANIC: could not locate a valid checkpoint record We found a web page that gave us an

Re: Point in time recovery

o a clean system to verify that everything is consistent. > On 8/18/20 5:10 AM, Daulat Ram wrote: > >I want to know the best way to ensure/verify that the Point in time > >recovery has done successfully after the crash and the restore. If you're coming from a crash, then that's an entire

Re: Point in time recovery

Search the log file for errors? Query the database(s) to verify that the latest data s there? On 8/18/20 5:10 AM, Daulat Ram wrote: Hello Team, I want to know the best way to ensure/verify that the Point in time recovery has done successfully after the crash and the restore. Thanks

Point in time recovery

Hello Team, I want to know the best way to ensure/verify that the Point in time recovery has done successfully after the crash and the restore. Thanks,

RE: Postgres Point in time Recovery (PITR),

sage- From: Andreas Kretschmer Sent: Friday, October 18, 2019 12:38 PM To: pgsql-general@lists.postgresql.org; Daulat Ram ; pgsql-general@lists.postgresql.org Subject: Re: Postgres Point in time Recovery (PITR), On 18 October 2019 07:59:21 CEST, Daulat Ram wrote: >Hello All, >Ca

Re: Postgres Point in time Recovery (PITR),

Hi > On 22/10/2019, at 4:14 AM, Adrian Klaver wrote: > > On 10/21/19 8:10 AM, Avinash Kumar wrote: >> Hi, >> On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson > > wrote: >>On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: >>> >>>We need to ensure that

Re: Postgres Point in time Recovery (PITR),

On Mon, Oct 21, 2019 at 8:47 PM Alan Hodgson wrote: > On Mon, 2019-10-21 at 20:40 +0530, Avinash Kumar wrote: > > can't he destroy the offline backups and your database ? > This is not a right justification to encouraging Offline Backups over > Online Backups. > If you are worried about storing

Re: Postgres Point in time Recovery (PITR),

On Mon, 2019-10-21 at 20:40 +0530, Avinash Kumar wrote: > can't he destroy the offline backups and your database ? > This is not a right justification to encouraging Offline Backups over > Online Backups. > If you are worried about storing your online backups through internet > on cloud (i do

Re: Postgres Point in time Recovery (PITR),

On 10/21/19 8:10 AM, Avinash Kumar wrote: Hi, On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson > wrote: On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: We need to ensure that we have safe backup locations, for example, push them to AWS S3 and

Re: Postgres Point in time Recovery (PITR),

Hi, On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson wrote: > On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: > > > We need to ensure that we have safe backup locations, for example, push > them to AWS S3 and forget about redundancy. > Why do you think only Offline Backups are reliable

Re: Postgres Point in time Recovery (PITR),

On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: > We need to ensure that we have safe backup locations, for example, > push them to AWS S3 and forget about redundancy. > Why do you think only Offline Backups are reliable today ? There have been examples of hackers gaining control of an

Re: Postgres Point in time Recovery (PITR),

On 21/10/2019 12:10, Avinash Kumar wrote: On Mon, Oct 21, 2019 at 4:19 PM Fabio Ugo Venchiarutti mailto:f.venchiaru...@ocado.com>> wrote: On 21/10/2019 09:52, Luca Ferrari wrote: > On Sat, Oct 19, 2019 at 7:46 PM Daulat Ram mailto:daulat@exponential.com>> wrote: >> One

Re: Postgres Point in time Recovery (PITR),

On Mon, Oct 21, 2019 at 4:19 PM Fabio Ugo Venchiarutti < f.venchiaru...@ocado.com> wrote: > On 21/10/2019 09:52, Luca Ferrari wrote: > > On Sat, Oct 19, 2019 at 7:46 PM Daulat Ram > wrote: > >> One more questions is, how backups are useful if we have streaming > replication . As I know, we can

Re: Postgres Point in time Recovery (PITR),

On 21/10/2019 09:52, Luca Ferrari wrote: On Sat, Oct 19, 2019 at 7:46 PM Daulat Ram wrote: One more questions is, how backups are useful if we have streaming replication . As I know, we can promote the standby as primary in case of disaster at primary side. Do we need to schedule backups if

Re: Postgres Point in time Recovery (PITR),

On Sat, Oct 19, 2019 at 7:46 PM Daulat Ram wrote: > One more questions is, how backups are useful if we have streaming > replication . As I know, we can promote the standby as primary in case of > disaster at primary side. Do we need to schedule backups if we have streaming > replication?

Re: Postgres Point in time Recovery (PITR),

visena.com>; Daulat Ram ; > pgsql-general@lists.postgresql.org > *Subject:* Re: Postgres Point in time Recovery (PITR), > > > > Hi Daulat, > > > > PITR entirely depends on what type of backups you choose. > Sometimes, to reduce the amount of downtime involved while

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 1:59 AM Daulat Ram wrote: > Hello All, > > Can you please share some ideas and scenarios how we can do the PITR in > case of disaster. > It depends on what you mean by "disaster". Usually I think that would mean your server (or entire data center) was destroyed. In

RE: Postgres Point in time Recovery (PITR),

Kumar Sent: Friday, October 18, 2019 5:28 PM To: David Steele Cc: Luca Ferrari ; Andreas Joseph Krogh ; Daulat Ram ; pgsql-general@lists.postgresql.org Subject: Re: Postgres Point in time Recovery (PITR), Hi Daulat, PITR entirely depends on what type of backups you choose. Sometimes, to reduce

Re: Postgres Point in time Recovery (PITR),

it to the safest point to achieve PITR. But this requires you to have an additional standby. https://www.percona.com/blog/2018/06/28/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/ If you have several TBs of database, pgBackRest is of course a way to go for backups (there are few more

Re: Postgres Point in time Recovery (PITR),

On 10/18/19 11:29 AM, Luca Ferrari wrote: On Fri, Oct 18, 2019 at 10:30 AM Andreas Joseph Krogh wrote: We use barman (https://www.pgbarman.org/) for continuous streaming backup and I had to restore from it once, and it went like this: Just for the records, here's an example of restore with

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 10:30 AM Andreas Joseph Krogh wrote: > We use barman (https://www.pgbarman.org/) for continuous streaming backup and > I had to restore from it once, and it went like this: Just for the records, here's an example of restore with pgbackrest: % sudo -u postgres pgbackrest

Re: Postgres Point in time Recovery (PITR),

On 18 October 2019 07:59:21 CEST, Daulat Ram wrote: >Hello All, >Can you please share some ideas and scenarios how we can do the PITR in >case of disaster. > > >Thanks, Consider Barman. -- 2ndQuadrant - The PostgreSQL Support Company

Sv: Postgres Point in time Recovery (PITR),

På fredag 18. oktober 2019 kl. 07:59:21, skrev Daulat Ram < daulat@exponential.com >: Hello All, Can you please share some ideas and scenarios how we can do the PITR in case of disaster. We use barman (https://www.pgbarman.org/

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 7:59 AM Daulat Ram wrote: > Can you please share some ideas and scenarios how we can do the PITR in case > of disaster. In order to be able to do PITR you need: - a base backup of your database - WALs from the backup going on See

Postgres Point in time Recovery (PITR),

Hello All, Can you please share some ideas and scenarios how we can do the PITR in case of disaster. Thanks,

Re: using pg_basebackup for point in time recovery

On Mon, Jun 25, 2018 at 12:51:10PM -0400, Bruce Momjian wrote: > FYI, in recent discussions on the docs list: > > > https://www.postgresql.org/message-id/CABUevEyumGh3r05U3_mhRrEU=dfacdrr2hew140mvn7fsbm...@mail.gmail.com I did not recall this one. Thanks for the reminder, Bruce. > There

Re: using pg_basebackup for point in time recovery

On Thu, Jun 21, 2018 at 04:50:38PM -0700, David G. Johnston wrote: > On Thu, Jun 21, 2018 at 4:26 PM, Vik Fearing > wrote: > > On 21/06/18 07:27, Michael Paquier wrote: > > Attached is a patch which includes your suggestion.  What do you think? > > As that's an improvement, only HEAD

Re: using pg_basebackup for point in time recovery

- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1430,12 +1430,15 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' Standalone Hot Backups - It is possible to use PostgreSQL's backup facilities to - produce standalone hot backups. These are backups that

Re: using pg_basebackup for point in time recovery

On Thu, Jun 21, 2018 at 04:42:00PM -0400, Ravi Krishna wrote: > Same here even though I use Mac mail. But it is not yahoo alone. > Most of the web email clients have resorted to top posting. I miss > the old days of Outlook Express which was so '>' friendly. I think > Gmail allows '>' when you

Re: using pg_basebackup for point in time recovery

t;These backups are typically much faster to create and restore, but generate larger file sizes, compared to pg_dump." For the last sentence I'd suggest: "Note that because WAL cannot be applied on top of a restored pg_dump backup it is considered a cold backup and cannot be used for point-in-ti

Re: using pg_basebackup for point in time recovery

On 21/06/18 07:27, Michael Paquier wrote: > Attached is a patch which includes your suggestion. What do you think? > As that's an improvement, only HEAD would get that clarification. Say what? If the clarification applies to previous versions, as it does, it should be backpatched. This isn't a

Re: using pg_basebackup for point in time recovery

> > > >You should avoid top-posting on the Postgres lists, this is not the > >usual style used by people around :) > > Will do, but Yahoo Mail! does not seem to like that, so I am typing the > > myself > Same here even though I use Mac mail. But it is not yahoo alone. Most of the web email

Re: using pg_basebackup for point in time recovery

Hi Michael On Thursday, June 21, 2018, 7:28:13 AM GMT+2, Michael Paquier wrote: >You should avoid top-posting on the Postgres lists, this is not the >usual style used by people around :) Will do, but Yahoo Mail! does not seem to like that, so I am typing the > myself >Attached is a

Re: using pg_basebackup for point in time recovery

On 06/21/2018 12:27 AM, Michael Paquier wrote: [snip] Attached is a patch which includes your suggestion. What do you think? As that's an improvement, only HEAD would get that clarification. You've *got* to be kidding. Fixing an ambiguously or poorly worded bit of *documentation* should

Re: using pg_basebackup for point in time recovery

aybe take the opportunity to re-instate that pg_dump cannot be > used for PITR, so in the line of > "These are backups that could be used for point-in-time recovery if > combined with a WAL archive able to recover up to the wanted recovery > point.  These backups are typically much faster to

Re: using pg_basebackup for point in time recovery

Hi Michael Thanks for the confirmation. Your rewording removes the confusion. I would maybe take the opportunity to re-instate that pg_dump cannot be used for PITR, so in the line of "These are backups that could be used for point-in-time recovery if combined with a WAL archive able to re

Re: using pg_basebackup for point in time recovery

Hi Pierre, On Tue, Jun 19, 2018 at 12:03:58PM +, Pierre Timmermans wrote: > Here is the doc, the sentence that I find misleading is "There are > backups that cannot be used for point-in-time recovery", also > mentioning that they are faster than pg_dumps add to confusio

using pg_basebackup for point in time recovery

Hi,I find the documentation about pg_basebackup misleading : the documentation states that standalone hot backups cannot be used for point in time recovery, however I don't get the point : if one has a combination of the nightly pg_basebackup and the archived wals, then it is totally OK to do

Re: Point-in-time recovery after failover

Dylan Luong wrote: > We are on Postgres 9.6 and we have primary/standby wal replication setup for > HA. > > I am trying to perform a point-in-time recovery after a failover has occurred. > > I extracted the base backups (tar files) to the data directory and extracted >

Point-in-time recovery after failover

: [3-1] db=,user= app=,host= LOG: starting point-in-time recovery to 2018-03-13 13:54:00+10:3 0 2018-03-13 20:46:53 ACDT [154912]: [4-1] db=,user= app=,host= LOG: restored log file "0006.history" from archive cp: cannot stat '/pg_backup/backup/archive/000601110087': No suc