Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZnep-003xOj-EK for pgsql-general@arkaria.postgresql.org; Fri, 02 Aug 2024 08:29:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sZnen-00GADS-3v for pgsql-general@arkaria.postgresql.org; Fri, 02 Aug 2024 08:29:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZnem-00GADK-MV for pgsql-general@lists.postgresql.org; Fri, 02 Aug 2024 08:29:00 +0000 Received: from mail-yw1-x1136.google.com ([2607:f8b0:4864:20::1136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZnef-002k6Y-CQ for pgsql-general@postgresql.org; Fri, 02 Aug 2024 08:29:00 +0000 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-66526e430e0so66308447b3.2 for ; Fri, 02 Aug 2024 01:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722587328; x=1723192128; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xG8cnSNdvkWd5jpKDi6bLiXdNHml4TO+mqkqJKgtrXk=; b=JxxGo0EbultuzVfrR6VhEbj+bE1krCJg9mrP1edF8kd+WPZRWk9r0KHHyGQYXioJLH +OZ4drosmpm1eCazYoRvUwc710vdpX8V01WlT7ObEZBATGy9olJqNCDz7aOR0/KdETua rMaWmioUMGgsUEKk3BHlAfisdZNFFyeNUkzXzYWlpI3IYXHmIb2Ue/L7xEWjH+71y2OM 9vFfgJcpZx4MKH05L6NcQgBzA1lLPjzAhGGZIIauYZ0j4JO8dPrhWyRbd8sckzhzy4aN dv08vyUXMxk6Biq68jdA1rSypvnV+T6g6WlLUnN4qcUOlMB2odfa6fg1gcUcEnqO3AcT C6TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722587328; x=1723192128; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xG8cnSNdvkWd5jpKDi6bLiXdNHml4TO+mqkqJKgtrXk=; b=BU+uE190KU1KEPV8cDvwsRCvD4zkTckxstnVv70Go4CJ4WlOE+eyk2UHvhTX7zmS3x ofhAeOMXaoKVY6MA9tx3GltqQanDxxIU0aL3JU0bXI/XQXwVrInL3WBqMSXmFfjekKaB egnkfaUPRM1Y93wyYQP0DiFtls2EuxYbOwnqGSAhgfg+1/qxq6H3n2/cPjgyrA9CHMIP bhDRIpoCJsPVV2Qol1/EglO+5wHem9pB6oe5L4PZLkQJA/xnj4I8hGw/H9ctYk+Upu9m KbK4WkwAuYpEPQJzKqGz7TNCXzRDb2ipbDmq7PhTZjH+WBpLIzMzcG6M1bZGobA5ZAvR STSg== X-Forwarded-Encrypted: i=1; AJvYcCWzBuKm18Y21FTb4JiVYgo347oEDFuLFKxmEDhB5TzxKYC7pbNZPdDqBvS6Ifvea62X6zkNwoXSZhrvMYA5C0L3CULsIMaEBrVc1w3v X-Gm-Message-State: AOJu0YzNoTs5YYmVEKylYQOMHx+nFPSiChOUQ1CxzdlB+QrriXxleyRl AlHY1IdPj4ynk2euR6IBe34X3EMzkcZ9ZqKuztcxXJY9YlEkMn2VRLnRr49A+RwhQ34oLuOP60b G8t0XY0zZUOWSlnkjZNToiXl8RQ/TI+Hk X-Google-Smtp-Source: AGHT+IEplNSwCtOh73vIwdWFJQZ4Iy/JNwTAiRNh+Uru2l1a8lSe0tKLob+HQEkPEHUnodAgRekBN8BkYmYZoO/wzKI= X-Received: by 2002:a0d:c946:0:b0:66a:7cbe:6d4b with SMTP id 00721157ae682-6896067f6d6mr33251207b3.12.1722587328048; Fri, 02 Aug 2024 01:28:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: KK CHN Date: Fri, 2 Aug 2024 14:07:38 +0530 Message-ID: Subject: Re: PgBackRest PTR recovery: After table drop to get dropped state To: Mateusz Henicz Cc: Kashif Zeeshan , pgsql-general Content-Type: multipart/alternative; boundary="000000000000c87679061eaf1d67" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c87679061eaf1d67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for shedding light on this. On Thu, Aug 1, 2024 at 4:04=E2=80=AFPM Mateusz Henicz wrote: > When you are performing PITR you need to configure a timestamp before you= r > last committed transaction. In your case you provided timestamp after you= r > last commit. > > I am trying to understand this concept and correct me if I am wrong If I do STEPS: 1. Noting down the time stamp just before my table drop, then 2. Drop a table, then 3. Taking the incremental backup after this table drop on Repo server, Then 4. If I do a PITR, with --target =3D timestamp noted in step1 and --se= t =3D the incr backup taken in step3 Then if perform a PITR restore by pgbackrest in step4 will it succeed or fail theoretically ? Thanks, Krishane When postgtes is restoring until a specified point, it restores a > transaction from WAL, and checking if next transaction is before or after > said timestamp. If it is before it will replay it and check next > transaction. Until next transaction is after configured timestamp. > If there is no transaction after your current timestamp in current WAL, > postgres will try to restore next WAL from archive. And since there is no > next WAL, and your timestamp is past latest committed transaction, it is > unable to continue, because it does not know if there should be any other > transaction replayed or not. > > Just perform some other actions after you note down the timestamp after > drop table. Create another one, insert some data, do whatever to have > another transaction in WALs. > > Cheers, > Mateusz > > czw., 1 sie 2024 o 12:23 KK CHN napisa=C5=82(a): > >> The logs are here. >> >> https://pastecode.io/s/s5dp8ur1 >> >> >> >> On Thu, Aug 1, 2024 at 3:30=E2=80=AFPM Kashif Zeeshan >> wrote: >> >>> Hi >>> >>> On Thu, Aug 1, 2024 at 2:54=E2=80=AFPM KK CHN wrot= e: >>> >>>> List, >>>> >>>> *Not working (start EPAS server always fails):* >>>> >>>> 1. Testing PTR using PgBackRest(2.52.1) on RHEL9 EPAS-16, and RHEL9 >>>> ( Repo Server) >>>> >>>> When I do a PTR >>>> >>>> 1. After doing a table drop and then >>>> 2. Noting down the time stamp and then >>>> 3. Taking an incremental backup in hope that If I do a restore from >>>> this incr Backup, that won't contain the dropped table. >>>> 4. Correct me if I am conceptually wrong here. >>>> 5. I am *never *successful in restoring the EPAS server in this >>>> scenario. >>>> >>>> >>>> *I know the following will work for me, w*hy not the above one if I >>>> really want that state of cluster also ? >>>> >>>> *This is Working. * >>>> 1. Create table >>>> 2. Noting down the timestamp >>>> 3. Taking incremental backup on RepoServer. >>>> 4. drop the created table . >>>> 5. Then stop the EPAS server and do a PTR, by the --set=3Dstep 3 inc= r >>>> backup and target=3D step 2 time stamp .. It finished the pgaback res= tore >>>> and promote command >>>> 6. I am able to start back the EPAS server and see the dropped table >>>> recovered there. >>>> >>>> But If I want a PTR as in the first section it fails.. Why ? >>>> >>>> Thank you, >>>> Krishane >>>> >>>> >>>> >>>> >>>> >>>> *What I have done and results obtained: * >>>> >>>> Created a table important_table4 in my EPAS and note down the time >>>> after creation of this table it is ( t1 : "01-AUG-24 >>>> 14:08:32.447796+05:30" ) >>>> >>>> Then I performed an Incremental backup (incr backup: >>>> 20240729-160137F_20240801-141148I ) >>>> timestamp start/stop: 2024-08-01 14:11:48+05:30 / 2024-08-01 >>>> 14:11:52+05:30 >>>> >>>> >>>> Now I dropped the table table4 from the EPAS and noted down the time >>>> >>>> >>>> I want to restore the table4,, so I stopped EPAS and executed >>>> >>>> $ sudo -u enterprisedb pgbackrest --stanza=3DDemo_Repo --delta >>>> --set=3D20240729-160137F_20240801-141148I --target-timeline=3Dcurrent >>>> --type=3Dtime --target=3D"01-AUG-24 14:08:32.447796+05:30" >>>> --target-action=3Dpromote restore >>>> >>>> IT WORKS AS EXPECTED .. after restarting the EPAS I am able to get the >>>> important_table4 back. >>>> >>>> root@service01 ~]# sudo -u enterprisedb psql edb >>>> psql (16.3.0) >>>> Type "help" for help. >>>> >>>> edb=3D# \dt >>>> List of relations >>>> Schema | Name | Type | Owner >>>> --------+------------------+-------+-------------- >>>> public | important_table | table | enterprisedb >>>> public | important_table2 | table | enterprisedb >>>> public | important_table3 | table | enterprisedb >>>> public | important_table4 | table | enterprisedb >>>> (4 rows) >>>> >>>> SO all works fine !!!! . >>>> >>>> >>>> *But Now the PROBLEM Statement. * >>>> >>>> *1. I am dropping the table table 4 again * >>>> edb=3D# \q >>>> [root@service01 ~]# sudo -u enterprisedb psql -c "begin; drop table >>>> important_table4; commit;" edb >>>> BEGIN >>>> DROP TABLE >>>> COMMIT >>>> *2 . [root@service01 ~]#* sudo -u enterprisedb psql -Atc "select >>>> current_timestamp" edb 01-AUG-24 14:23:22.085076 +05:30 >>>> Noting the time as : (01-AUG-24 14:23:22.085076 +05:30 ) >>>> >>>> 3. Now I am performing an incremental backup after step 2 on REPO >>>> SErver ( Hoping that this latest INCR Backup is without dropped >>>> important_table4, so that a recovery of the cluster shouldn't show th= e >>>> table4 again. ) >>>> >>>> incr backup details. : 20240729-160137F_20240801-142433I >>>> timestamp start/stop*: 2024-08-01 14:24:33+05:30 / >>>> 2024-08-01 14:24:36+05:30* >>>> >>>> 4. Now I want to test the database recovery after dropping the table4 >>>> in step1 to verify that my EPAS restores from the backup in step 3 and= time >>>> stamp (01-AUG-24 14:23:22.085076 +05:30, so that the restored EPAS >>>> cluster doesn't contain the important_table4. >>>> >>>> 5. $ sudo -u enterprisedb pgbackrest --stanza=3DDemo_Repo --delta >>>> --set=3D20240729-160137F_20240801-142433I --target-timeline=3Dcurren= t >>>> --type=3Dtime --target=3D"01-AUG-24 14:23:22.085076+05:30" >>>> --target-action=3Dpromote restore >>>> ------------ >>>> ------------- >>>> INFO: restore command end: completed successfully (1035ms) >>>> >>>> *ISSUE: I am unable to get the EPAS Server* in running state after >>>> step 5 >>>> >>>> *What am I doing wrong ? OR am I conceptually wrong ?* >>>> >>>> >>>> >>>> >>>> OUTPUT on executing step 5. >>>> >>>> [root@service01 ~]# sudo -u enterprisedb pgbackrest --stanza=3DDemo_Re= po >>>> --delta --set=3D20240729-160137F_20240801-142433I --target-timeline= =3Dcurrent >>>> --type=3Dtime --target=3D"01-AUG-24 14:23:22.085076+05:30" >>>> --target-action=3Dpromote restore >>>> >>>> 2024-08-01 14:30:03.535 P00 INFO: restore command begin 2.52.1: >>>> --delta --exec-id=3D82738-b5fe7415 --log-level-console=3Dinfo >>>> --log-level-file=3Ddebug --pg1-path=3D/var/lib/edb/as16/data >>>> --pg-version-force=3D16 --repo1-host=3D10.10.20.7 --repo1-host-user=3D= postgres >>>> --set=3D20240729-160137F_20240801-142433I --stanza=3DDemo_Repo >>>> --target=3D"01-AUG-24 14:23:22.085076+05:30" --target-action=3Dpromote >>>> --target-timeline=3Dcurrent --type=3Dtime >>>> 2024-08-01 14:30:03.880 P00 INFO: repo1: restore backup set >>>> 20240729-160137F_20240801-142433I, recovery will start at 2024-08-01 >>>> 14:24:33 >>>> 2024-08-01 14:30:03.881 P00 INFO: remove invalid files/links/paths >>>> from '/var/lib/edb/as16/data' >>>> 2024-08-01 14:30:04.567 P00 INFO: write updated >>>> /var/lib/edb/as16/data/postgresql.auto.conf >>>> 2024-08-01 14:30:04.569 P00 INFO: restore global/pg_control >>>> (performed last to ensure aborted restores cannot be started) >>>> 2024-08-01 14:30:04.569 P00 INFO: restore size =3D 75.9MB, file tota= l =3D >>>> 2171 >>>> 2024-08-01 14:30:04.569 P00 INFO: restore command end: completed >>>> successfully (1035ms) >>>> *[root@service01 ~]# systemctl start edb-as-16.service* >>>> >>>> *Now If I check the server status : Its dead * >>>> >>>> [root@service01 ~]# systemctl status edb-as-16.service >>>> =C3=97 edb-as-16.service - EDB Postgres Advanced Server 16 >>>> Loaded: loaded (/etc/systemd/system/edb-as-16.service; disabled; >>>> preset: disabled) >>>> *Active: failed* (Result: exit-code) since Thu 2024-08-01 >>>> 14:30:58 IST; 4s ago >>>> Duration: 228ms >>>> Process: 82752 >>>> ExecStartPre=3D/usr/edb/as16/bin/edb-as-16-check-db-dir ${PGDATA} >>>> (code=3Dexited, status=3D0/SUCCESS) >>>> Process: 82757 ExecStart=3D/usr/edb/as16/bin/edb-postgres -D >>>> ${PGDATA} (code=3Dexited, status=3D1/FAILURE) >>>> Main PID: 82757 (code=3Dexited, status=3D1/FAILURE) >>>> CPU: 325ms >>>> >>>> Aug 01 14:30:56 service01 systemd[1]: Starting EDB Postgres Advanced >>>> Server 16... >>>> Aug 01 14:30:56 service01 edb-postgres[82757]: 2024-08-01 14:30:56 IST >>>> LOG: redirecting log output to logging collector process >>>> Aug 01 14:30:56 rservice01 edb-postgres[82757]: 2024-08-01 14:30:56 IS= T >>>> HINT: Future log output will appear in directory "log". >>>> Aug 01 14:30:58 service01 systemd[1]: Started EDB Postgres Advanced >>>> Server 16. >>>> Aug 01 14:30:58 service01 systemd[1]: edb-as-16.service: Main process >>>> exited, code=3Dexited, status=3D1/FAILURE >>>> Aug 01 14:30:58 service01 systemd[1]: edb-as-16.service: Killing >>>> process 82758 (edb-postgres) with signal SIGKILL. >>>> A*ug 01 14:30:58 service01 systemd[1]: edb-as-16.service: Failed with >>>> result 'exit-code'.* >>>> [root@service01 ~]# >>>> >>>> Any hints/guidance most welcome. >>>> >>>> Can you please share the DB Server log as it contains the exact error >>> which is causing the server not to start. >>> >>> Thanks >>> >> --000000000000c87679061eaf1d67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for shedding=C2=A0light on this.=C2=A0=C2= =A0

On Thu, Aug 1, 2024 at 4:04=E2=80=AFPM Mateusz Henicz <mateuszhenicz@gmail.com> wrote:
When y= ou are performing PITR you need to configure a timestamp before your last c= ommitted=C2=A0transaction. In your case you provided timestamp after your l= ast commit.

=C2=A0

I am trying to understand this concept and correct me if I am wrong= =C2=A0
If I do

STEPS:
= 1. Noting=C2=A0down the time stamp=C2=A0 just before my table drop,=C2=A0 t= hen=C2=A0
2.=C2=A0 Drop=C2=A0a=C2=A0 table, then
3. Tak= ing the incremental backup after this table drop on Repo server, Then=C2=A0=
4. If I do a=C2=A0 PITR,=C2=A0 with --target =3D=C2=A0=C2=A0time= stamp=C2=A0 noted in step1 and=C2=A0 --set =3D the incr backup=C2=A0 =C2=A0= taken in step3

Then if=C2=A0 perform a=C2=A0 PITR= restore by pgbackrest in step4=C2=A0 will it succeed or fail theoretically= ?

Thanks,
Krishane

=

When postgtes is restoring until a specified point= , it restores a transaction from WAL, and checking if next transaction is b= efore or after said timestamp. If it is before it will replay it and check = next transaction. Until next transaction is after configured timestamp.
If there is no transaction after your current timestamp in current W= AL, postgres will try to restore next WAL from archive. And since there is = no next WAL, and your timestamp is past latest committed=C2=A0transaction, = it is unable to continue, because it does not know if there should be any o= ther transaction replayed or not.

Just=C2=A0perfor= m some other actions after you note down the timestamp after drop table. Cr= eate=C2=A0another one, insert some data, do whatever to have another transa= ction in WALs.

Cheers,
Mateusz

czw.= , 1 sie 2024 o 12:23=C2=A0KK CHN <kkchn.in@gmail.com> napisa=C5=82(a):
The logs are= here.=C2=A0=C2=A0

<= a href=3D"https://pastecode.io/s/s5dp8ur1" target=3D"_blank">https://pastec= ode.io/s/s5dp8ur1


<= br>
On Thu,= Aug 1, 2024 at 3:30=E2=80=AFPM Kashif Zeeshan <kashi.zeeshan@gmail.com> wrote:=
Hi

On Thu, Aug 1, 2024 at 2:54=E2=80=AFPM KK CHN <kkchn.in@gmail.com&= gt; wrote:
List,

Not working (start EPAS = server always fails):=C2=A0

1. Testing PTR usi= ng=C2=A0 PgBackRest(2.52.1)=C2=A0 on RHEL9=C2=A0 EPAS-16, and RHEL9 ( Repo= =C2=A0 =C2=A0 =C2=A0 =C2=A0Server)=C2=A0

=C2=A0 Wh= en I do a PTR

1.=C2=A0 After doing a table drop an= d then
2. Noting down the time stamp and then=C2=A0
3. = Taking an incremental=C2=A0backup in hope that If I do a restore=C2=A0from = this incr Backup, that won't=C2=A0 contain the=C2=A0 dropped table.=C2= =A0
4.=C2=A0Correct me=C2=A0 if I=C2=A0am=C2=A0 conceptually wron= g here.=C2=A0=C2=A0
5.=C2=A0 I am never successful in rest= oring the EPAS server in this scenario.


I know the following=C2=A0will work for me, why not the = above one if I really want=C2=A0that state of cluster also=C2=A0 ?=C2=A0

This is Working.=C2=A0
=C2=A01.= Create table=C2=A0
2. Noting down the timestamp
3.=C2= =A0 Taking incremental backup on RepoServer.
4. drop the created = table .
5. Then stop the EPAS server and do a=C2=A0 PTR, by the= =C2=A0 --set=3Dstep 3 incr backup=C2=A0 and target=3D step 2 time stamp .. = It finished the pgaback=C2=A0restore and promote=C2=A0command
6. = I am able to start back the=C2=A0 EPAS server and see the dropped table rec= overed there.

But If I want a PTR as in the first = section it fails.. Why ?=C2=A0

Thank you,
Krishane





What I have done and results obtained:=C2=A0

Created a table important_table4 in my EPAS and note= down the time after creation of this table it is=C2=A0 ( t1 :=C2=A0 "= 01-AUG-24 14:08:32.447796+05:30" )

Then I per= formed an Incremental backup=C2=A0 =C2=A0(incr backup: 20240729-160137F_202= 40801-141148I )
timestamp start/stop: 2024-08-01 14:11:48+05:30 /= 2024-08-01 14:11:52+05:30


Now = I dropped the table table4 from the EPAS and noted down the time=C2=A0


I want to=C2=A0 restore the table4,, so= I stopped EPAS and executed=C2=A0

$ sudo -u enter= prisedb pgbackrest --stanza=3DDemo_Repo --delta --set=3D20240729-160137F_20= 240801-141148I =C2=A0--target-timeline=3Dcurrent --type=3Dtime =C2=A0--targ= et=3D"01-AUG-24 14:08:32.447796+05:30" --target-action=3Dpromote = restore

IT WORKS AS EXPECTED .. after restarti= ng the EPAS I am able to get the important_table4 back.=C2=A0
root@service01 ~]# sudo -u enterprisedb psql edb
psql (16.3.= 0)
Type "help" for help.

edb=3D# \dt
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List of relations
=C2=A0Schema= | =C2=A0 =C2=A0 =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 | Type =C2=A0| =C2=A0 =C2= =A0Owner
--------+------------------+-------+--------------
=C2=A0pub= lic | important_table =C2=A0| table | enterprisedb
=C2=A0public | import= ant_table2 | table | enterprisedb
=C2=A0public | important_table3 | tabl= e | enterprisedb
=C2=A0public | important_table4 | table | enterprisedb<= br>(4 rows)

SO all works fine !!!! .=C2=A0

=

But Now the PROBLEM Statement.=C2=A0

1. I am dropping the table table 4=C2=A0again= =C2=A0
edb=3D# \q
[root@service01 ~]# sudo -u enterprisedb= psql -c "begin; drop table important_table4; commit;" edb
BEG= IN
DROP TABLE
COMMIT
2 .=C2=A0 [root@service01 ~]# sudo -u = enterprisedb psql -Atc "select current_timestamp" edb=C2=A0 01-AU= G-24 14:23:22.085076 +05:30
Noting the time as :=C2=A0 =C2=A0= (01-AUG-24 14:23:22.085076 +05:30 )

3. Now=C2= =A0 I am performing an incremental backup after step 2=C2=A0 on REPO SErver= ( Hoping that this latest INCR Backup is without dropped important_table4,= so that a recovery of the cluster=C2=A0 shouldn't show the table4 agai= n. )=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 incr backup= details. : 20240729-160137F_20240801-142433I
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 timestamp start/stop: 2024-08-01 14:24:33+05:30 / 2024= -08-01 14:24:36+05:30

4. Now I want to tes= t the database recovery=C2=A0 after dropping the table4 in step1 to verify = that my EPAS restores from the backup in step 3 and time stamp (01-AUG-24 1= 4:23:22.085076 +05:30,=C2=A0 =C2=A0so that=C2=A0 the restored EPAS cluster = doesn't contain the important_table4.

5.=C2=A0= $ sudo -u enterprisedb pgbackrest --stanza=3DDemo_Repo --delta=C2=A0 =C2= =A0--set=3D20240729-160137F_20240801-142433I =C2=A0--target-timeline=3Dcurr= ent --type=3Dtime =C2=A0--target=3D"01-AUG-24 14:23:22.085076+05:30&qu= ot; --target-action=3Dpromote restore
=C2=A0------------
-------------
INFO: restore command end: completed successfully= (1035ms)

ISSUE:=C2=A0 =C2=A0 I am unable t= o get the EPAS Server in running state after step 5=C2=A0
=C2=A0What am I doing=C2=A0wrong ?=C2=A0 OR am I conceptuall= y wrong ?




OUTPUT on executing step 5.=C2=A0

[root@s= ervice01 ~]# sudo -u enterprisedb pgbackrest --stanza=3DDemo_Repo --delta -= -set=3D20240729-160137F_20240801-142433I =C2=A0--target-timeline=3Dcurrent = --type=3Dtime =C2=A0--target=3D"01-AUG-24 14:23:22.085076+05:30" = --target-action=3Dpromote restore

2024-08-01 14:30:03.535 P00= =C2=A0 INFO: restore command begin 2.52.1: --delta --exec-id=3D82738-b5fe7= 415 --log-level-console=3Dinfo --log-level-file=3Ddebug --pg1-path=3D/var/l= ib/edb/as16/data --pg-version-force=3D16 --repo1-host=3D10.10.20.7 --repo1-= host-user=3Dpostgres --set=3D20240729-160137F_20240801-142433I --stanza=3DD= emo_Repo --target=3D"01-AUG-24 14:23:22.085076+05:30" --target-ac= tion=3Dpromote --target-timeline=3Dcurrent --type=3Dtime
2024-08-01 14:3= 0:03.880 P00 =C2=A0 INFO: repo1: restore backup set 20240729-160137F_202408= 01-142433I, recovery will start at 2024-08-01 14:24:33
2024-08-01 14:30:= 03.881 P00 =C2=A0 INFO: remove invalid files/links/paths from '/var/lib= /edb/as16/data'
2024-08-01 14:30:04.567 P00 =C2=A0 INFO: write updat= ed /var/lib/edb/as16/data/postgresql.auto.conf
2024-08-01 14:30:04.569 P= 00 =C2=A0 INFO: restore global/pg_control (performed last to ensure aborted= restores cannot be started)
2024-08-01 14:30:04.569 P00 =C2=A0 INFO: re= store size =3D 75.9MB, file total =3D 2171
2024-08-01 14:30:04.569 P00 = =C2=A0 INFO: restore command end: completed successfully (1035ms)
[ro= ot@service01 ~]# systemctl =C2=A0start edb-as-16.service
=
Now=C2=A0 If I check the server=C2=A0 status=C2=A0 :=C2= =A0 =C2=A0Its dead=C2=A0

[root@service01 ~= ]# systemctl =C2=A0status edb-as-16.service
=C3=97 edb-as-16.service - E= DB Postgres Advanced Server 16
=C2=A0 =C2=A0 =C2=A0Loaded: loaded (/etc/= systemd/system/edb-as-16.service; disabled; preset: disabled)
=C2=A0 =C2= =A0 =C2=A0Active: failed (Result: exit-code) since Thu 2024-08-01 14= :30:58 IST; 4s ago
=C2=A0 =C2=A0Duration: 228ms
=C2=A0 =C2=A0 Process= : 82752 ExecStartPre=3D/usr/edb/as16/bin/edb-as-16-check-db-dir ${PGDATA} (= code=3Dexited, status=3D0/SUCCESS)
=C2=A0 =C2=A0 Process: 82757 ExecStar= t=3D/usr/edb/as16/bin/edb-postgres -D ${PGDATA} (code=3Dexited, status=3D1/= FAILURE)
=C2=A0 =C2=A0Main PID: 82757 (code=3Dexited, status=3D1/FAILURE= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CPU: 325ms

Aug 01 14:30:56 service0= 1 systemd[1]: Starting EDB Postgres Advanced Server 16...
Aug 01 14:30:5= 6 service01 edb-postgres[82757]: 2024-08-01 14:30:56 IST LOG: =C2=A0redirec= ting log output to logging collector process
Aug 01 14:30:56 rservice01 = edb-postgres[82757]: 2024-08-01 14:30:56 IST HINT: =C2=A0Future log output = will appear in directory "log".
Aug 01 14:30:58 service01 syst= emd[1]: Started EDB Postgres Advanced Server 16.
Aug 01 14:30:58 service= 01 systemd[1]: edb-as-16.service: Main process exited, code=3Dexited, statu= s=3D1/FAILURE
Aug 01 14:30:58 service01 systemd[1]: edb-as-16.service: K= illing process 82758 (edb-postgres) with signal SIGKILL.
Aug 01 14:30= :58 service01 systemd[1]: edb-as-16.service: Failed with result 'exit-c= ode'.
[root@service01 ~]#

Any hints= /guidance most welcome.=C2=A0

C= an you please share the DB Server log as it contains the exact error which = is causing the server not to start.

Thanks=C2=A0
--000000000000c87679061eaf1d67--