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.96) (envelope-from ) id 1vkQlV-00F31I-2o for pgsql-general@arkaria.postgresql.org; Mon, 26 Jan 2026 17:52:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vkQlU-009rGK-37 for pgsql-general@arkaria.postgresql.org; Mon, 26 Jan 2026 17:52:41 +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.96) (envelope-from ) id 1vkQlU-009rGC-20 for pgsql-general@lists.postgresql.org; Mon, 26 Jan 2026 17:52:40 +0000 Received: from sonic322-56.consmr.mail.ne1.yahoo.com ([66.163.189.31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vkQlR-00000000Zw6-3yCh for pgsql-general@lists.postgresql.org; Mon, 26 Jan 2026 17:52:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1769449954; bh=FNOck9MIr4XisChre9DiGhHGKKTZxGJ+oY4D33xupwU=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=XOw4Mkz5BkO1I5cYl/ETlRw4Ly9/yQY2PcHy9ha7KL7HCsRURF2IQ37BQ5yfUboox0e8o/scys2dvCe54/P8Kxd85MRmbk/ZmLKdOVF9DGNfBQufZpVQlpwk8sfe7twTz4GnINUGg8ETgbeJJyuuUqvOeLUWwk3+CHRLuUOloMAlfhrJIWYLfUcadOxt0HbEX+X1mk4h3F84fb4UedzNEFM3RZ7SOlkB6ioDCFGOYOrFqWKfNFGEkpJjELZDBsVpGFommvGed1qthsGrwFf0zKaVYlTZiaxWdaO9ioscU+DNUE4+sBSPyGv2SrBgLPChIs7TiwFlh1SPJb4Fo68qLw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1769449954; bh=2sePklV5mpbsmm8a2HV1uCXG55CDGpy4kfi/p6+jn5D=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ARUcCXnjRBfURFW1/bBmK4eYjeJu5klqyVhbBUeorU5XuIQ0GAoynA2nlF1XyCK4trU6CLTP/795OzAbjv7tTq4P4d4BoXoNULXnaEnRJo2MNn8VSPON+KjB9n01/BN+rdbFII2pH2XB5MY3ChI4MMLz5oCVObUSDoW2KiYJD1MA8yQSSSD4ZplPdJ8VKGFxqwRfu/rrOG5EqfRBr9v13R18L5FenStzyge/70gRMNfWipFWe+jM6/0EoG0IullV9jL7deaF42Dyr/sADw68e3RtwCX7SQ1eN9guTG0hS6Y4RoFGs0Myf+1lLXjVEkdg0it7SBveIbghLg1ZNwBYHg== X-YMail-OSG: czM4sR0VM1nmWbtA4aDA2xg01W3l1hDaHawUqB3ZAju63W8g7AH0jGKPESu.TnV F1TpY385lzt5Tv8nSUmiFsP7mC6dtxwa6qnp_uyPv5DzQDvtNBLBt6_yhBOgedqLiR3hTMSjvaE9 yCfZQdxsKdoCiiawrRepYWolPqqeKzS.aK9O68L.LIF5lDxPv7qJhOc1r_igFW67pI5Mvb4Fw0bF nmkLjT3T3y9MV3cRobxeDG07pNAjWG5f7kcHZQ_8Ah.9.I5AP1ztWmjE4YnnHTdFJuVz3fIsdc2H ziNglDHK.BXnUyahNsjggKuSm4SNZdUU.lNM1M3m1_dj15.z9v4qwmrstqpUEe_O.f1APF5nL3sD F99Wj8GDa4.q9imtKiNK2LmGfaW15ow_WMVshcg52CF2W_DJT_f89njzl1ypCoPoR.nRpFh1uzOu _2Kwl7pYIzTQIcK3azgiBjL7z1K1TyzTAizWEhs6fXM0LD7oYRR8nNYxcIXsHzGWVXL1XN.vv0BY .GKJi.DQlyHGBmnIoP6jytDE9k0nrskuIZsBnttY3awwrgjO857rkaI2ZicfbdgqFWlT0IJQAHrb UKEzDl6JPDSvhKXTNeGPE95IPn6eqRFU7hYsxsTo9QH_op5NCefT_s96UHx7KyVUU09uITnsNJNA _I4b335X.I4d9V3haurCnDtKtBv4S3izVoxgNgXgXyGp6hUQ4l28nbW44BA_XaQq6TMqLRKhwbTN e6lwEbiIqc5pCNg2x92ax7MWW.fzniIkZ7fQ8lRiNRAq0eqlrfMlchq3gpNzXKUiBB17sJRjF5.o vMaTO9_JCMBvEXpnuTmX27EHNE767ldNQTT0ofwGmN8uKPq4Xm4NqqAMNrXHTflzvJU7kzYGgepl n5QELDwFwX_puPlz0P7g53JqeN.DwvsZXzQf8Jjw6EnwPdvhWSf2F2miVNJNrx5cjCwzJVsj6hk5 uFgIc4lUR2oPb2mkgMlYghIRLmy.l7dt0WYy_dBULg3VmtUfAqOazm9OWtjLgvL6t8rnrv1M3LEt Rq.E4k0BEImIBRU7CDa9srS.efuoauiXzlEz5vsLBLFhlflcBcMt4ouDr1se7IKheIfI3zszmBtL u.TN1LujE7qzAD.ykG9E7_z6LvabrEu9.LWCGXzBWFbV3i3hWSc7KQkVhLL_QHLSsq5Eikqk1gQA Sr.pTeT.pb0mvTRkxtPFYaBvUaRcNMF1PGEJ6.NbfI3V.TDzxNr0x73U.FyvMK7b6Ij0hjf2uVF_ 3895IDOLK0fx3V2gFCnRuAITJWo6kX6x6JAQTYhV_OE4N5WiXOk_8.xdjQtTYJ0Q1L7pvxgpLOP_ BEu.N89mSoHkacwKWgd8VnPS3kvZ42B.fXcPkyLfXFQ7MDxX8_kIdWFQyClnm6Q34ivdFbCoF0D_ F_RGTK6kCh5GTHnvj6rJQxIp_paIxUKTKKtc.D4lsyHTA53s0kTIiOE1o_6SkIgVj1m0FoeUdqo3 95TBYE3twbqsKTslXrB16xQ3cltE29KH3gu36rhCtA3c1RP_tBinHkJjvQoqxuhJE64aktljqco2 UPejhMVDDo2Imgryum9HjynWHp87bGvwY_wQv5k9Sudu26gfb1YrmLETY2KBXpR..uPsLL.dJDof fu9bNjCcxv8YWV2tZid.4G53ktqLQmu24Krewf1T_2xbisLDOo3PhZ5mN05FpbuffM_OKdLqgMvL nFjLtcPaBRo9DofOKrHZlJqdu_GcF6v0ML43s1t4e8e3I4XBmXFVkPGuqcoj1Ox8UQtxyRQBsq0u 5Yk2pXuMxc40Ex0cCJ1azYe62NgdTtgKRKDjw0jPFxWPGgznNz0NOSfYLLHSFQbl.sBuL1kghH9J aXxCT4AypTlCllnxFagzzBkghX.5h.CPSDsCVZHKJMwfAjG18mbnrolLg20aWwwOi9M.rIVKf0kt rx07JHGb131pnb6gP4JtH32WMRFzg2mUyZ6O3mGCYj52M7FkoF4gXBhUwSMa_SD7L0ouaPw1k03s z9axJ.lJLSj_9lGYvB5JC0ZgxxXri1Tb3TUSgmcrIAXbEdWG8b6UNkcVQVNKwrKE_JjULKN08b_O QjMsRaIXQbv1FWAGx17qKD4CRkN5zgDbZauIh0tifa0U6W14JdDZmFIFviKzphErxTvZTOBCjl8b E7pb_eHA8..JMJO9FK.SmQ7paZIiftX0pNQNFrLc3YGstQSLT6Df3EZ1N8fV4AWIBTwUo32IktWV a5H_KFHKsDBnV5.N_tss- X-Sonic-MF: X-Sonic-ID: 6ff0fbb4-58ca-4c2e-9b24-9b9e76b7000d Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.ne1.yahoo.com with HTTP; Mon, 26 Jan 2026 17:52:34 +0000 Date: Mon, 26 Jan 2026 17:52:31 +0000 (UTC) From: felix.quintgz@yahoo.com To: pgsql-general@lists.postgresql.org Message-ID: <868938296.4311067.1769449951678@mail.yahoo.com> In-Reply-To: References: <1730736265.4259921.1769443263077.ref@mail.yahoo.com> <1730736265.4259921.1769443263077@mail.yahoo.com> Subject: Re: About backups MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.24987 YMailNodin Content-Length: 1957 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I'm having a problem with this. I'm repurposing an old application written = in Visual Basic 6 that did allow backups through signed stored procedures.= =20 This is a requirement for financial applications; the user can perform a ba= ckup whenever they want, but they can't access the database. The new application is web-based, deployed in containers, and the database = server container is not the same as the application's, so I can't use pg_du= mp in the application, or at least I don't know how to do it. On Monday, January 26, 2026 at 12:31:48 PM GMT-5, Ron Johnson wrote: On Mon, Jan 26, 2026 at 11:11 AM Adrian Klaver = wrote: On 1/26/26 08:01, felix.quintgz@yahoo.com wrote: > Is there a way to implement the SQL Server command 'BACKUP DATABASE'? Not from within the Postgres instance. You will need to use: https://www.postgresql.org/docs/current/app-pgdump.html Felix,=C2=A0pg_dump is a logical export tuned for speed and multithreading.= =C2=A0 Almost certainly not what you want. pgbackrest is the equivalent of BACKUP DATABASE and BACKUP LOG.=C2=A0 It's = an external program (stuffing everything in the database engine is not The = Unix Way) which typically you run from cron.=C2=A0Redrirect=C2=A0stdout and= stderr to a log file with a timestamp in the name.=C2=A0 (That, at least, = is what I've been doing for 8 years.=C2=A0 It works perfectly.) pgbackrest also has an "info" option which gives you details of all the bac= kups currently in the repository.=C2=A0> > Is there a way to see the restores performed on a database? > Is there an equivalent table to msdb.dbo.restorehistory in SQL Server? > Is there a way to implement an equivalent if one doesn't exist? =C2=A0From what I understand there are various ways of doing this in SQL Server, which way are you interested in? -- Death to , and butter sauce.Don't boil me, I'm still alive. lobster!