pgbackrest restore to new location?

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

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

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