Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XhJLS-0003Dz-Oc for pgsql-admin@arkaria.postgresql.org; Thu, 23 Oct 2014 14:26:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XhJLS-0001RY-9Q for pgsql-admin@arkaria.postgresql.org; Thu, 23 Oct 2014 14:26:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XhJLR-0001RS-Id for pgsql-admin@postgresql.org; Thu, 23 Oct 2014 14:26:29 +0000 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XhJLN-0003bB-KY for pgsql-admin@postgresql.org; Thu, 23 Oct 2014 14:26:28 +0000 Received: by mail-wi0-f173.google.com with SMTP id ex7so1941432wid.6 for ; Thu, 23 Oct 2014 07:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=kx8A7LKiqstAlS0u5n74Vy7r13ZIYnCauWRlcbtXp0A=; b=k8HUbCQEy2Kdo71vcp2JaMn9JM2ROv4EPCzNXKI9k/cp5AGhD3fWDagMAPus9ia7KO llvO53uVpPRo7ugSPAiriD3pYLDcFbZS0yLPYqwAuCj3/IkkjWLum01Smd6BWNFLQ36R nC92NziTb1+eNxzlvGUodUp7yE89o2+CppxsWkgbdl4A7VLBhahZEhdkLWox+A5HCzxn omeu5ypGS6vxKf4m4Pqz+sq3k0zvIWcx3qwt2Rf+5mgRlfGCtHgLUBlb/6MK2C76o9wY XxcgFvfd1xb0AQcbQR1cqxrsHFd1WGHsB18bY6tx/rZvvpx23Xpc4g2FwoX1mHztnQH+ fPcA== X-Received: by 10.194.175.67 with SMTP id by3mr5855698wjc.32.1414074383641; Thu, 23 Oct 2014 07:26:23 -0700 (PDT) Received: from enterprisedb01 (84.125.177.156.dyn.user.ono.com. [84.125.177.156]) by mx.google.com with ESMTPSA id gg18sm2758790wic.21.2014.10.23.07.26.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2014 07:26:22 -0700 (PDT) Message-ID: <1414074381.25413.1.camel@gmail.com> Subject: Re: Single Database Recovery? From: jaime soler Reply-To: jaime.soler@gmail.com To: john@jpm-cola.com Cc: pgsql-admin@postgresql.org Date: Thu, 23 Oct 2014 16:26:21 +0200 In-Reply-To: <20141023064401.569d35d6ab57613ee80d5d1694a397ee.da2ef0c184.wbe@email06.secureserver.net> References: <20141023064401.569d35d6ab57613ee80d5d1694a397ee.da2ef0c184.wbe@email06.secureserver.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org El jue, 23-10-2014 a las 06:44 -0700, john@jpm-cola.com escribió: > > > Hi all, > > > I'm trying to recover a single database that's part of an instance > with other databases which I do not want to recover. We do a physical > backup and have the WAL archive files available. The purpose of this > is to place a copy of one of the Prod databases onto the QA server > which has other existing databases that we want to keep. > > > What I was thinking was that I could recover all of the files to a > separate area, then basically just copy the files from that database's > directory into the QA instance database directory (same oid.) There > was an existing copy on the QA server and I want to replace it with > the new copy. > > > Is this possible? No, if you have a physical backup with all archive files, you will able to restore the whole instance. It's not posible to restore only a database with a physical backup. > I know that I could simply do a pg_dump into this QA database but this > seems to take way too long - days instead of the hours that it takes > to unzip the physical backup file into a directory on the QA server. > > > I also know that I could easily create a new instance but I have a > constraint that the IP addresses and ports cannot be changed. > > > If this instance only had a single database it would be a simple > physical restore, but the presence of the additional databases has me > stumped. > > > The PostgreSQL version is 9.1.9. The server is Red Hat Enterprise > Linux Server release 6.2 (Santiago) on a VM machine - 8 GB RAM with 2 > CPUs: > > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 2 > On-line CPU(s) list: 0,1 > Thread(s) per core: 1 > Core(s) per socket: 2 > CPU socket(s): 1 > NUMA node(s): 1 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 44 > Stepping: 2 > CPU MHz: 2660.000 > BogoMIPS: 5320.00 > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 12288K > NUMA node0 CPU(s): 0,1 > > > Thanks for any ideas or myth debunking that you can apply to this > conundrum. > > > Regards, > > > John McDougald -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin