On 12/29/17 1:53 PM, Stephen Frost wrote:
> Greetings,
>
> * David Steele (david@pgmasters.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@pgmasters.net