Re: pg_basebackup vs. Windows and tablespaces - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_basebackup vs. Windows and tablespaces
Date
Msg-id CABUevEyeHSvhGMupcNNRN0qxaBJUE58na0E4gcNdqaXpza+scQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup vs. Windows and tablespaces  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_basebackup vs. Windows and tablespaces  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 08/12/2013 01:40 PM, Magnus Hagander wrote:
>>>>
>>>> I also like the concept of #2, but I think we need to think about it a
>>>> bit more. One of the things I like about barman backups is that on
>>>> recovery you can map where tablespaces go, on a per tablespace basis
>>>> (it's not very well documented, or wasn't when I last looked, but it
>>>> does work). I think something like that would be awesome to have for
>>>> pg_basebackup. So allowing multiple options of the form
>>>>
>>>>      --map-tablespace c:/foo/bar=d:/baz/blurfl
>>>>
>>>> or some such would be great.
>>>
>>> Good point.  I see now that the syntax I floated covered just one slice
>>> of a
>>> whole range of things folks might want in that area.
>>
>> I think I have an old patch around for doing just the map-tablespace
>> thing that I never quite finished. That one was mostly useful for
>> setting up replicas really, since that's when you know at backup time
>> where you want to the new tablespaces to go. For a regular backup, you
>> want it to happen at restore time. And in this case, you're quite
>> likely working off the tarfiles, and we don't really have a program
>> dealing with the restore of those at all - you're just supposed to do
>> it manually.
>>
>> A trivial tool that worked off the directory of tarfiles and allowed
>> remapping of the tablespace locations (by updating the
>> symlinks/junctions restored out of the base.tar flie) might be an
>> easier and less invasive way to do it than to put it in the actual
>> recovery code?
>>
>>
>
>
> What barman does is to dissolve the symlink when making its backup (i.e
> pg_tblspc/12345 becomes a directory in the backup instead of a symlink), and
> store the info relating to the source symlink in its metadata file. On
> restore it recreates the symlink. It's at that stage that you can modify its
> default behaviour by specifying where the link should go.

Something like that makes sense for a plain format dump - but maybe
not for a tar one. And in either case, that also requires there to be
a pg_baserestore (or whatever you'd want to call it, please come up
with a better name :D) to do the restore process, to make sure it's
properly mapped.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #8335: trim() un-document behaviour
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces