Re: PgBackRest question?

Thank you very much David and Stephen for your quick reply.

On Fri, Dec 29, 2017 at 1:55 PM, David Steele <david(at)pgmasters(dot)net> wrote:

> On 12/29/17 1:53 PM, Stephen Frost wrote:
> > Greetings,
> >
> > * David Steele (david(at)pgmasters(dot)net) wrote:
> >> On 12/28/17 6:15 PM, chiru r wrote:
> >>> I am unable to copy the complete backup.manifest file due to security
> >>> reasons . please find the below contents.
> >>>
> >>> [backup:target]
> >>> pg_data={"path":"/u02/pgdata01/9.5/data","type":"path"}
> >>> pg_tblspc/721349={"path":"/u02/pgdata02/report1","
> tablespace-id":"721349","tablespace-name":"report1","type":"link"}
> >>>
> >>> [db]
> >>> db1={"db-id":770161,"db-last-system-id":13289}
> >>> db2={"db-id":770162,"db-last-system-id":13289}
> >>> db3={"db-id":770169,"db-last-system-id":13289}
> >>> postgres={"db-id":13294,"db-last-system-id":13289}
> >>> template0={"db-id":13289,"db-last-system-id":13289}
> >>> template1={"db-id":1,"db-last-system-id":13289}
> >>
> >> OK -- it looks like this is a bug. pgBackRest is validating the
> >> database mappings against the files in the manifest but does not
> >> recognize databases that are assigned to a tablespace. It's OK if
> >> tables are assigned to a tablespace, but not the entire database.
> >>
> >> We'll fix this in the next release. I've opened an issue on github to
> >> track it: https://github.com/pgbackrest/pgbackrest/issues
> >
> > Of course, a full restore should work just fine, this issue occurs
> > only if you're doing a single-database restore from a cluster.
> >
> > Presuming you're doing more than just testing, doing a full restore
> > (and then dropping the databases that you don't want) would be a
> > workaround until 1.28 is out.
>
> Stephen is correct -- if you have the space to do full restores then
> that will work until this is fixed.
>
> --
> -David
> david(at)pgmasters(dot)net
>
>