Re: BUG #13642: no backup_label file in PG_DATA after pg_stop_backup(); - Mailing list pgsql-bugs

From Amir Rohan
Subject Re: BUG #13642: no backup_label file in PG_DATA after pg_stop_backup();
Date
Msg-id 5607561B.3030702@mail.com
Whole thread Raw
In response to Re: BUG #13642: no backup_label file in PG_DATA after pg_stop_backup();  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-bugs
On 09/27/2015 03:58 AM, Jeff Janes wrote:
> On Fri, Sep 25, 2015 at 11:27 PM, Amir Rohan <amir.rohan@mail.com
> <mailto:amir.rohan@mail.com>> wrote:
>

>     No. Well, there's a backup file in the archive directory that looks like
>     it might be /it/ but it's not named `backup_label` (it wouldn't, since
>     multiple backups need to coexist).
>

> The very next item says:
>
> 3.  Perform the backup, using any convenient file-system-backup tool
> such as tar or cpio (not pg_dump or pg_dumpall).
>

I understand, but "backup" is so overloaded that "perform the backup"
isn't really descriptive. What is meant is "Make a copy of your server's
entire tree, including configuration files, subdirectories, as well as
the backup_labeland tablespace_map files created when you
initiate pg_start_backup()".

It may seem ovious to veteransm but trust me, to someone new the
various steps can be very confusing, and the documentation for it
isn't great.

>
> You have to "perform the backup", as quoted above.  You don't have to do
> it with tar, and you don't need to name the resulting file ".tgz".  But
> using some method or another, you do need to actually take a backup, if
> your desire is to have a backup.
>
> Did you create a backup?  If you did not, then no, your backup is not
> usable.  If you did, does it include the backup_label file?
>
> Cheers,
>
> Jeff

Thanks Jeff. I've spent enough time on this so that I feel I have
a reasonable grasp of the steps involved. My WALs are archived,
The file system backup is stowed away, with backup_label safely
tucked in it.

I posted a documentation to -docs, which hopefully would qualify
as an improvement. Obviously, it would help if someone more
experienced reviewed it and gave it up a thumbs up. If you have
the spare cycles...


Kind Regards,
Amir

pgsql-bugs by date:

Previous
From: Jeff Janes
Date:
Subject: Re: BUG #13642: no backup_label file in PG_DATA after pg_stop_backup();
Next
From: Tim Bunce
Date:
Subject: Re: BUG #13638: Exception texts from plperl has bad encoding