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 1sZoME-0045d8-TE for pgsql-general@arkaria.postgresql.org; Fri, 02 Aug 2024 09:13:55 +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 1sZoMD-00GNvx-0t for pgsql-general@arkaria.postgresql.org; Fri, 02 Aug 2024 09:13:53 +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 1sZoMC-00GNvp-Im for pgsql-general@lists.postgresql.org; Fri, 02 Aug 2024 09:13:52 +0000 Received: from mail-vk1-xa31.google.com ([2607:f8b0:4864:20::a31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZoM5-002kWH-9J for pgsql-general@postgresql.org; Fri, 02 Aug 2024 09:13:51 +0000 Received: by mail-vk1-xa31.google.com with SMTP id 71dfb90a1353d-4f6ac477ff4so4286787e0c.3 for ; Fri, 02 Aug 2024 02:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722590023; x=1723194823; 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=dY3EKva9Ozzf4A1qpYyZ5hYJLUQRLSU6R9Lhshg9HxY=; b=asODNHcD/NHM0Oemtov7snIkQQpXXNX/AtF0n51bfAv1qS2pwXVKvr+h5pmIP/244N UEuO+VDG0ZxLg2KGJCg/mIFAjKTkfTq0a4gTDhxR057Y/us3is1wdpmce5xm5MXTE6H9 NudQCi6qBuUYVDEAh+oWij3obkunVrRMcgNg3J1w/bgnqGw57hHIarhSO5GdZ0a4jf1p LyezGtGTIWz8bfkou7ioeID4smIfzAop6ynm7rswV3rfumOhd1+1CTur8BPUONEKU309 1cx/AlLE6jQanpNnbcAHKwdELA57KfPKfIyHoTxWSZR7Mufmi32NM3HHrJxogAr251KE L1lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722590023; x=1723194823; 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=dY3EKva9Ozzf4A1qpYyZ5hYJLUQRLSU6R9Lhshg9HxY=; b=mDgoW7ExkhoM/RXIZONgnx4gwilEwn+g+CzUupHm/0qEX1wekJeJvZsThOT8fAKz2B oLgUwWcJyxRRChd4kOGjCoWa2bYooXVVaSKYpdELwaG1hYcxpSOijbO8R7y5awflJ8KT qx9zziGFxprGbP55tYmoTj9dlp4Xg57z/AoM+aDbr4kCUXI96nnr4jL5xDZe0uKfzopQ ueSmVUbK1vt68byHKoMWBkjSdtwu6DxqMt8zyaRYvmh33K0PK3w1knSHOpduEas9Euv7 0MaTLOk+sAalQaybc4TN8iWNHiktw0oKaOTcnSBiwJeGiqQ9/hsvPVUkERFy/ygOCJ6K YumA== X-Forwarded-Encrypted: i=1; AJvYcCVhCSi3KB5ls7IPF5WJIgUzztvzftLViht2lIMbUO+b4wfNXxaDraxALiTpIZrOIGMCdUU4x0j/g71lAiYw0DxhJecTGqcDk2LrXa3m X-Gm-Message-State: AOJu0YxPK6kKxhvlORkVXqJ5/px3GkYa2d5lpNPSCwd+L7tMGeXF8RCz uL8a2LY5Bs73RA6mAlFV9mFrKTaXTVaULJTPhiGiTAMHi7RVw0TB3H0uL41/RS4jpsx+6H+zGP4 0p1NfgGScFYFYEg/t3Q4Vd2DHDve3mLAd X-Google-Smtp-Source: AGHT+IEIveApzxufpuPhVEPgnFOoFu6QmmxD5AqzLiLZbpSiFBJaMSOetPt/7HD+ev+hP6uxBcd8v3vs2qo3Xzw7ZSg= X-Received: by 2002:a05:6122:903:b0:4ec:f996:5d84 with SMTP id 71dfb90a1353d-4f89ff41d42mr3853844e0c.2.1722590023198; Fri, 02 Aug 2024 02:13:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kashif Zeeshan Date: Fri, 2 Aug 2024 14:13:32 +0500 Message-ID: Subject: Re: PgBackRest PTR recovery: After table drop to get dropped state To: KK CHN Cc: Mateusz Henicz , pgsql-general Content-Type: multipart/alternative; boundary="0000000000006d303c061eafbe88" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006d303c061eafbe88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Fri, Aug 2, 2024 at 1:28=E2=80=AFPM KK CHN wrote: > 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 >> your last committed transaction. In your case you provided timestamp aft= er >> your 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 > When you take a back and checkpoint is called which will update the data files and till that time you now dont need the WAL Files as they are already written on Data Files and are part of the backp. How PITR works is 1. You take a backup (full/incremental) 2. Make changes in the data 3. Note down all the timestamps per the transactions as you need them 4. Now if you want to restore,what you will do is to give the required timestamp with the required backup This will restore the backup and then replay the WAL files as per your given timestamp I hope this clarifies Regards Kashif Zeeshan > 4. If I do a PITR, with --target =3D timestamp noted in step1 and --= set > =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 afte= r >> 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 n= o >> 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 othe= r >> 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 wro= te: >>>> >>>>> List, >>>>> >>>>> *Not working (start EPAS server always fails):* >>>>> >>>>> 1. Testing PTR using PgBackRest(2.52.1) on RHEL9 EPAS-16, and RHEL= 9 >>>>> ( 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 in= cr >>>>> backup and target=3D step 2 time stamp .. It finished the pgaback re= store >>>>> 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=3Dcurren= t >>>>> --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 th= e >>>>> 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 t= he >>>>> 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 table= 4 >>>>> in step1 to verify that my EPAS restores from the backup in step 3 an= d 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=3Dcurre= nt >>>>> --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_Repo --delta --set=3D20240729-160137F_20240801-142433= I >>>>> --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= =3Dpostgres >>>>> --set=3D20240729-160137F_20240801-142433I --stanza=3DDemo_Repo >>>>> --target=3D"01-AUG-24 14:23:22.085076+05:30" --target-action=3Dpromot= e >>>>> --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 tot= al >>>>> =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 IS= T >>>>> LOG: redirecting log output to logging collector process >>>>> Aug 01 14:30:56 rservice01 edb-postgres[82757]: 2024-08-01 14:30:56 >>>>> IST 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 >>>> >>> --0000000000006d303c061eafbe88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Fri, Aug 2, 2024 at 1:28=E2=80=AFPM = KK CHN <kkchn.in@gmail.com>= wrote:
Thank you for shedding=C2=A0light on this.=C2=A0=C2=A0
<= br>
On Thu,= Aug 1, 2024 at 4:04=E2=80=AFPM Mateusz Henicz <mateuszhenicz@gmail.com> wrote:=
When you are performing PITR you need to configure a timestamp before you= r last committed=C2=A0transaction. In your case you provided timestamp afte= r your last commit.

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

STEPS:
1. Noting=C2=A0down the time stamp=C2=A0 just before my table drop,= =C2=A0 then=C2=A0
2.=C2=A0 Drop=C2=A0a=C2=A0 table, then
3. Taking the incremental backup after this table drop on Repo server, Th= en=C2=A0
When you take a back and checkp= oint is called which will update the data files and till that time you now = dont need the WAL Files as they are already written on Data Files and are p= art of the backp.

How PITR works is
1. Y= ou take a backup (full/incremental)
2. Make changes in the data
3. Note down all the timestamps per the transactions as you need t= hem
4. Now if you want to restore,what you will do is to give the= required timestamp with the required backup
This will restore th= e backup and then replay the WAL files as per your given timestamp

I hope this clarifies

Regards
Kashif Zeeshan
=C2=A0
4. If I= do a=C2=A0 PITR,=C2=A0 with --target =3D=C2=A0=C2=A0timestamp=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 pgback= rest in step4=C2=A0 will it succeed or fail theoretically ?

<= /div>
Thanks,
Krishane


=
When postgtes is restoring until a specified point, it restores a tran= saction 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. Un= til next transaction is after configured timestamp.
If there is n= o transaction after your current timestamp in current WAL, postgres will tr= y to restore next WAL from archive. And since there is no next WAL, and you= r timestamp is past latest committed=C2=A0transaction, it is unable to cont= inue, because it does not know if there should be any other transaction rep= layed or not.

Just=C2=A0perform some other actions= after you note down the timestamp after drop table. Create=C2=A0another on= e, insert some data, do whatever to have another transaction in WALs.
=

Cheers,
Mateusz

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

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

On Thu, Aug 1, 2024 at 2:54=E2=80=AFPM KK CHN <kkchn.in@gmail.com> wrote:
=
Lis= t,

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

1. Testing PTR using=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 When I do a PTR

1.=C2=A0 After doing a table drop and then
2. N= oting 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, tha= t won't=C2=A0 contain the=C2=A0 dropped table.=C2=A0
4.=C2=A0= Correct me=C2=A0 if I=C2=A0am=C2=A0 conceptually wrong here.=C2=A0=C2=A0
5.=C2=A0 I am never successful in restoring 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. Th= en stop the EPAS server and do a=C2=A0 PTR, by the=C2=A0 --set=3Dstep 3 inc= r 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 recovered 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 cr= eation of this table it is=C2=A0 ( t1 :=C2=A0 "01-AUG-24 14:08:32.4477= 96+05:30" )

Then I performed an Incremental b= ackup=C2=A0 =C2=A0(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 tab= le4 from the EPAS and noted down the time=C2=A0

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

$ sudo -u enterprisedb pgbackrest --st= anza=3DDemo_Repo --delta --set=3D20240729-160137F_20240801-141148I =C2=A0--= target-timeline=3Dcurrent --type=3Dtime =C2=A0--target=3D"01-AUG-24 14= :08:32.447796+05:30" --target-action=3Dpromote restore
<= br>
IT WORKS AS EXPECTED .. after restarting the EPAS I am able t= o get the important_table4 back.=C2=A0

root@servic= e01 ~]# sudo -u enterprisedb psql edb
psql (16.3.0)
Type "help&q= uot; 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=A0public | important_table = =C2=A0| table | enterprisedb
=C2=A0public | important_table2 | table | e= nterprisedb
=C2=A0public | important_table3 | table | enterprisedb
= =C2=A0public | important_table4 | table | enterprisedb
(4 rows)

<= /div>
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
BEGIN
DROP TABLE
= COMMIT
2 .=C2=A0 [root@service01 ~]# sudo -u enterprisedb psql -A= tc "select current_timestamp" edb=C2=A0 01-AUG-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 a= n incremental backup after step 2=C2=A0 on REPO SErver ( Hoping that this l= atest INCR Backup is without dropped important_table4, so that a recovery o= f the cluster=C2=A0 shouldn't show the table4 again. )=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 times= tamp 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= =C2=A0 after dropping the table4 in step1 to verify that my EPAS restores f= rom the backup in step 3 and time stamp (01-AUG-24 14:23:22.085076 +05:30,= =C2=A0 =C2=A0so that=C2=A0 the restored EPAS cluster doesn't contain th= e important_table4.

5.=C2=A0 $ sudo -u enterprised= b pgbackrest --stanza=3DDemo_Repo --delta=C2=A0 =C2=A0--set=3D20240729-1601= 37F_20240801-142433I =C2=A0--target-timeline=3Dcurrent --type=3Dtime =C2=A0= --target=3D"01-AUG-24 14:23:22.085076+05:30" --target-action=3Dpr= omote restore
=C2=A0------------
-------------
INFO: restore command end: completed successfully (1035ms)
=
ISSUE:=C2=A0 =C2=A0 I am unable to get the EPAS Server in running state after step 5=C2=A0

=C2=A0Wha= t am I doing=C2=A0wrong ?=C2=A0 OR am I conceptually wrong ?
=



OUTPUT on execu= ting step 5.=C2=A0

[root@service01 ~]# sudo -u ent= erprisedb pgbackrest --stanza=3DDemo_Repo --delta --set=3D20240729-160137F_= 20240801-142433I =C2=A0--target-timeline=3Dcurrent --type=3Dtime =C2=A0--ta= rget=3D"01-AUG-24 14:23:22.085076+05:30" --target-action=3Dpromot= e restore

2024-08-01 14:30:03.535 P00 =C2=A0 INFO: restore co= mmand 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-v= ersion-force=3D16 --repo1-host=3D10.10.20.7 --repo1-host-user=3Dpostgres --= set=3D20240729-160137F_20240801-142433I --stanza=3DDemo_Repo --target=3D&qu= ot;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 =C2=A0 INF= O: repo1: restore backup set 20240729-160137F_20240801-142433I, recovery wi= ll 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 updated /var/lib/edb/as16/da= ta/postgresql.auto.conf
2024-08-01 14:30:04.569 P00 =C2=A0 INFO: restore= global/pg_control (performed last to ensure aborted restores cannot be sta= rted)
2024-08-01 14:30:04.569 P00 =C2=A0 INFO: restore size =3D 75.9MB, = file total =3D 2171
2024-08-01 14:30:04.569 P00 =C2=A0 INFO: restore com= mand end: completed successfully (1035ms)
[root@service01 ~]# systemc= tl =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 - EDB Postgres Advanced Serve= r 16
=C2=A0 =C2=A0 =C2=A0Loaded: loaded (/etc/systemd/system/edb-as-16.s= ervice; disabled; preset: disabled)
=C2=A0 =C2=A0 =C2=A0Active: faile= d (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/u= sr/edb/as16/bin/edb-as-16-check-db-dir ${PGDATA} (code=3Dexited, status=3D0= /SUCCESS)
=C2=A0 =C2=A0 Process: 82757 ExecStart=3D/usr/edb/as16/bin/edb= -postgres -D ${PGDATA} (code=3Dexited, status=3D1/FAILURE)
=C2=A0 =C2=A0= Main PID: 82757 (code=3Dexited, status=3D1/FAILURE)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 CPU: 325ms

Aug 01 14:30:56 service01 systemd[1]: Starting ED= B Postgres Advanced Server 16...
Aug 01 14:30:56 service01 edb-postgres[= 82757]: 2024-08-01 14:30:56 IST LOG: =C2=A0redirecting log output to loggin= g 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 systemd[1]: Started EDB Postg= res 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 1= 4:30:58 service01 systemd[1]: edb-as-16.service: Killing process 82758 (edb= -postgres) with signal SIGKILL.
Aug 01 14:30:58 service01 systemd[1]:= edb-as-16.service: Failed with result 'exit-code'.
[root@se= rvice01 ~]#

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

Can you please share the= DB Server log as it contains the exact error which is causing the server n= ot to start.

Thanks=C2=A0
--0000000000006d303c061eafbe88--