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
