Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ePVVI-0000yp-Bp for pgsql-admin@arkaria.postgresql.org; Thu, 14 Dec 2017 15:32:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ePVVH-0001d5-JT for pgsql-admin@arkaria.postgresql.org; Thu, 14 Dec 2017 15:32:55 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ePVRk-0003LF-Cf for pgsql-admin@lists.postgresql.org; Thu, 14 Dec 2017 15:29:16 +0000 Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ePVRd-0006l7-KZ for pgsql-admin@postgresql.org; Thu, 14 Dec 2017 15:29:15 +0000 Received: by mail-it0-x22f.google.com with SMTP id d137so11948178itc.2 for ; Thu, 14 Dec 2017 07:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=propaas-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=rOkX4pwNA/JmdWo62sOcdbjn1fXPi/KKKgGtBNvV1GI=; b=nkZX+92qfD1T7Cl9Elc8xJKe2UMHCfqzbkB/MwTi9eiBdCdmHt5VgCwvCjVI7cwLR7 RyKgQdOZVlM+E2Qd+tmrHbdGGmjKlnakWy3dlIvM17L7MnpPWSLujOCIzc4GOYv5uSRD H4aBW0x2iu+Yz67j77AMykIXNiSYQPTOvASL+iCUhP3xCEP+iHpYEWBPt61oIW362gq2 qYNKOPdqKqmJ8c/2fyA4j/tu+Vmzcp88wGHxOwcbCgBsQy1W/u6EKRxteOFltQgyeZos x/ifLDB0Mixt5pDUVNVqYY93N/7Zcvj9KKrW8XIlNQt1NUyiu+n6QEWvVqIq//kPoAs1 JKnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rOkX4pwNA/JmdWo62sOcdbjn1fXPi/KKKgGtBNvV1GI=; b=KuYCref6mepMOr2n5OODv6Y0ZA/gbaxs8xqY7/YUZlL7upuV8++OgXrKVSgPvIuZ/O wCM8nMdIRYsJdwRuC4wH2i9aahU0JdtcSawaAAckdxaJY82I3FxKofKyvqE8uuk1/8W2 TnCciB9ZrKL6yjFvFI6BaOYU6QPIxBL2X9B1KtslCoPYB5TFm/wKJOhnGs5ZIh1P78yc C++Qb/zNnqGCvHs4+rFbAbnu3nMVixfgzrrZRQKucBMxbDjPqif0hNcs9PPeLNbdqO7s Ll/9Sn9SVIJsJB4TUKT7GWzdnQXVbB2pO+1EBLgWkbrdydCbdGp9Z7aGypv0DfXwNdrg nvOw== X-Gm-Message-State: AKGB3mLe7QqY4KFpqaGsahokQlHrQSvZf8zOHo2OQ9kFd0aY4PQ54/zW ViORIA7N2oTQbYqcCnNnm5s8Ig== X-Google-Smtp-Source: ACJfBov0eEISm8L4lnqRAtUuotnA4UzTYU4oRX/2SvCNVAYtj5DQKFK9yqc02YR3ythOL2i6EAgHtw== X-Received: by 10.107.52.140 with SMTP id b134mr5045823ioa.291.1513265345480; Thu, 14 Dec 2017 07:29:05 -0800 (PST) Received: from [10.1.0.106] (50-243-150-81-static.hfc.comcastbusiness.net. [50.243.150.81]) by smtp.gmail.com with ESMTPSA id g1sm2696623itg.10.2017.12.14.07.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 07:29:04 -0800 (PST) Subject: Re: virtualized snapshots and PITR To: Laurenz Albe , pgsql-admin References: <38c84302-270e-a2b6-648f-26ba798d8787@propaas.com> <1513239540.2442.22.camel@cybertec.at> From: PropAAS DBA Message-ID: Date: Thu, 14 Dec 2017 08:29:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1513239540.2442.22.camel@cybertec.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/14/2017 01:19 AM, Laurenz Albe wrote: > PropAAS DBA wrote: >> we have a client using veeam to do vmware snapshots of the db servers, >> unfortunately as far as I can tell any restore of a veeam snapshot also >> restores the state, which means the db gets restored in an online state. >> As far as I know, once the db is online we cannot force it back into >> recovery mode to do a PITR recovery, correct? >> >> Anyone know of a way to do PITR recoveries with veeam? > It is fairly simple. > > Before the snapshot, run > > SELECT pg_start_backup('label of your choice', TRUE); > > After the snapshot, run > > SELECT pg_stop_backup(); > > Yours, > Laurenz Albe However restoring the snapshot with veeam will restore the db to a running/online state, which means we cannot force it to go back into recovery mode yes?