On 08/12/2013 02:22 PM, Magnus Hagander wrote:
> 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.
>
I'm not saying to do it exactly as barman does. I'm just describing how
they do it.
I'd be quite happy if we just provided, at least to begin with,
tablespace mapping for plain format pg_basebackup dumps.
cheers
andrew
