Thread: pgbackrest restore to new location?
Hi, In order to do this, do I create a new stanza in config file which has pg1-path point to the new/empty directory structure while still pointing to the existing backup directory, and restore that stanza? Thanks -- Angular momentum makes the world go 'round.
On Tue, Sep 17, 2019 at 3:09 AM Ron <ronljohnsonjr@gmail.com> wrote: > > Hi, > > In order to do this, do I create a new stanza in config file which has > pg1-path point to the new/empty directory structure while still pointing to > the existing backup directory, and restore that stanza? No, I would do this: 1) execute stop for that stanza on the backup machine 2) change the pg1-path for that stanza on the target machine 3) execute the restore command on the target machine 4) adjust backup machine stanza path and 'start' it again. If you create a new stanza, pgbackrest will not find it in the backup repository. Luca
On 9/17/19 4:29 AM, Luca Ferrari wrote: > On Tue, Sep 17, 2019 at 3:09 AM Ron <ronljohnsonjr@gmail.com> wrote: >> Hi, >> >> In order to do this, do I create a new stanza in config file which has >> pg1-path point to the new/empty directory structure while still pointing to >> the existing backup directory, and restore that stanza? > No, I would do this: > 1) execute stop for that stanza on the backup machine > 2) change the pg1-path for that stanza on the target machine > 3) execute the restore command on the target machine > 4) adjust backup machine stanza path and 'start' it again. > > If you create a new stanza, pgbackrest will not find it in the backup > repository. Thanks, Luca. I realized that mistake when trying the restore. The real problem is that after doing that, "pg_ctl start -D /path/to/new/data" fails with "PANIC: could not locate a valid checkpoint record". -- Angular momentum makes the world go 'round.
On Tue, Sep 17, 2019 at 12:00 PM Ron <ronljohnsonjr@gmail.com> wrote: > The real problem is that after doing that, "pg_ctl start -D > /path/to/new/data" fails with "PANIC: could not locate a valid checkpoint > record". Hard to say what's going wrong without logs/configs. Do you have any other backup to try to restore from? As a sidenote, in this kind of restore you should not be using --delta, but I guess pgbackrest will prevent you to do so. Luca
On 9/17/19 7:23 AM, Luca Ferrari wrote: > On Tue, Sep 17, 2019 at 12:00 PM Ron <ronljohnsonjr@gmail.com> wrote: >> The real problem is that after doing that, "pg_ctl start -D >> /path/to/new/data" fails with "PANIC: could not locate a valid checkpoint >> record". Sounds like backup_label is missing or has been deleted. The easiest way to restore to a new location is just to copy pgbackrest.conf from the primary (or create a new one) with the same stanza and then alter pg1-path in pgbackrest.conf or at the command line. Regards, -- -David david@pgmasters.net
On 9/17/19 6:48 AM, David Steele wrote: > On 9/17/19 7:23 AM, Luca Ferrari wrote: >> On Tue, Sep 17, 2019 at 12:00 PM Ron <ronljohnsonjr@gmail.com> wrote: >>> The real problem is that after doing that, "pg_ctl start -D >>> /path/to/new/data" fails with "PANIC: could not locate a valid checkpoint >>> record". > Sounds like backup_label is missing or has been deleted. > > The easiest way to restore to a new location is just to copy > pgbackrest.conf from the primary (or create a new one) with the same > stanza and then alter pg1-path in pgbackrest.conf or at the command line. That's what I did. (Also, I opened Issue #839 in GitHub All of the log files are attached there.) -- Angular momentum makes the world go 'round.
Greetings, * Ron (ronljohnsonjr@gmail.com) wrote: > On 9/17/19 6:48 AM, David Steele wrote: > >On 9/17/19 7:23 AM, Luca Ferrari wrote: > >>On Tue, Sep 17, 2019 at 12:00 PM Ron <ronljohnsonjr@gmail.com> wrote: > >>>The real problem is that after doing that, "pg_ctl start -D > >>>/path/to/new/data" fails with "PANIC: could not locate a valid checkpoint > >>>record". > >Sounds like backup_label is missing or has been deleted. > > > >The easiest way to restore to a new location is just to copy > >pgbackrest.conf from the primary (or create a new one) with the same > >stanza and then alter pg1-path in pgbackrest.conf or at the command line. > > That's what I did. (Also, I opened Issue #839 in GitHub All of the log > files are attached there.) Per the discussion in that issue, it looks like there's some issue with the restore command failing to be able to pull the needed WAL from the repo. That said- it brings up a pretty serious issue that should be discussed, and that's nuking this: HINT: If you are not restoring from a backup, try removing the file ".../backup_label". That hint is absolutely wrong these days when many tools have been updated to use the non-exclusive backup method and it just ends up getting people into trouble and, worse, can result in them having corrupted clusters. I'll get a patch into the next commitfest to remove it. The exclusive method has been deprecated for quite a few releases and we should stop giving bad advice on the assumption that people are using it. Thanks, Stephen
Attachment
On 9/17/19 10:03 PM, Stephen Frost wrote: > > That said- it brings up a pretty serious issue that should be discussed, > and that's nuking this: > > HINT: If you are not restoring from a backup, try removing the file ".../backup_label". > > That hint is absolutely wrong these days when many tools have been > updated to use the non-exclusive backup method and it just ends up > getting people into trouble and, worse, can result in them having > corrupted clusters. > > I'll get a patch into the next commitfest to remove it. The exclusive > method has been deprecated for quite a few releases and we should stop > giving bad advice on the assumption that people are using it. We updated the error message and hints in c900c152, but it was not back-patched. -- -David david@pgmasters.net
Attachment
Greetings, * David Steele (david@pgmasters.net) wrote: > On 9/17/19 10:03 PM, Stephen Frost wrote: > > I'll get a patch into the next commitfest to remove it. The exclusive > > method has been deprecated for quite a few releases and we should stop > > giving bad advice on the assumption that people are using it. > > We updated the error message and hints in c900c152, but it was not > back-patched. Ohh, right, good. :) Thanks! Stephen