On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan <and...@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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
