pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedBackup?
57+ messages / 27 participants
[nested] [flat]
* Backup?
@ 2003-09-04 19:31 Bjørn T Johansen <btj@havleik.no>
0 siblings, 2 replies; 57+ messages in thread
From: Bjørn T Johansen @ 2003-09-04 19:31 UTC (permalink / raw)
To: pgsql-general
Should one use pg_dumpall to backup the database or is it more practical
to just copy the data directory?
Regards,
BTJ
--
-----------------------------------------------------------------------------------------------
Bjørn T Johansen (BSc,MNIF)
Executive Manager
btj@havleik.no Havleik Consulting
Phone : +47 67 54 15 17 Conradisvei 4
Fax : +47 67 54 13 91 N-1338 Sandvika
Cellular : +47 926 93 298 http://www.havleik.no
-----------------------------------------------------------------------------------------------
"The stickers on the side of the box said "Supported Platforms: Windows
98, Windows NT 4.0,
Windows 2000 or better", so clearly Linux was a supported platform."
-----------------------------------------------------------------------------------------------
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup?
@ 2003-09-04 20:40 Doug McNaught <doug@mcnaught.org>
parent: Bjørn T Johansen <btj@havleik.no>
1 sibling, 1 reply; 57+ messages in thread
From: Doug McNaught @ 2003-09-04 20:40 UTC (permalink / raw)
To: Bjørn T Johansen <btj@havleik.no>; +Cc: pgsql-general
Bjørn T Johansen <btj@havleik.no> writes:
> Should one use pg_dumpall to backup the database or is it more practical
> to just copy the data directory?
The data directory will not be consistent unless the server is
stopped. pg_dumpall works well, produces a consistent backup and is
easily portable to a different machine architecture if need be.
-Doug
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup?
@ 2003-09-04 20:47 Vivek Khera <khera@kcilink.com>
parent: Bjørn T Johansen <btj@havleik.no>
1 sibling, 0 replies; 57+ messages in thread
From: Vivek Khera @ 2003-09-04 20:47 UTC (permalink / raw)
To: pgsql-general
>>>>> "BTJ" == Bjørn T Johansen <Bj> writes:
BTJ> Should one use pg_dumpall to backup the database or is it more
yes, or pg_dump specific databases.
BTJ> practical to just copy the data directory?
this would do you no good, since the files are not necessarily in a
consistent state when you copy many of them. ie, the copy is
non-atomic, and there is no guarantee that all data is flushed to
disk.
i don't even do a file system dump of my PG data partition because of
this.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup?
@ 2003-09-04 22:23 Ron Johnson <ron.l.johnson@cox.net>
parent: Doug McNaught <doug@mcnaught.org>
0 siblings, 1 reply; 57+ messages in thread
From: Ron Johnson @ 2003-09-04 22:23 UTC (permalink / raw)
To: pgsql-general
On Thu, 2003-09-04 at 15:40, Doug McNaught wrote:
> Bjørn T Johansen <btj@havleik.no> writes:
>
> > Should one use pg_dumpall to backup the database or is it more practical
> > to just copy the data directory?
>
> The data directory will not be consistent unless the server is
> stopped. pg_dumpall works well, produces a consistent backup and is
> easily portable to a different machine architecture if need be.
And it's smaller than the data/ directory, especially when "-F c"
option is used.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA
"The UN couldn't break up a cookie fight in a Brownie meeting."
Larry Miller
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup?
@ 2003-09-05 15:17 Vivek Khera <khera@kcilink.com>
parent: Ron Johnson <ron.l.johnson@cox.net>
0 siblings, 0 replies; 57+ messages in thread
From: Vivek Khera @ 2003-09-05 15:17 UTC (permalink / raw)
To: pgsql-general
>>>>> "RJ" == Ron Johnson <ron.l.johnson@cox.net> writes:
RJ> On Thu, 2003-09-04 at 15:40, Doug McNaught wrote:
>> Bjørn T Johansen <btj@havleik.no> writes:
>>
>> > Should one use pg_dumpall to backup the database or is it more practical
>> > to just copy the data directory?
>>
>> The data directory will not be consistent unless the server is
>> stopped. pg_dumpall works well, produces a consistent backup and is
>> easily portable to a different machine architecture if need be.
RJ> And it's smaller than the data/ directory, especially when "-F c"
RJ> option is used.
That and indexes are represented as a single "CREATE INDEX" statement,
rather than possibly gigabytes of data ;-)
I had one index which I just realized was redundant to another and
deleting it saved me ~1Gb on disk.
For the curious, the indexes were like this:
PRIMARY KEY (a,b);
INDEX a ON mytable (a);
The query planner shows slightly longer plans with just the PK, but
the cost savings on mass inserts which happen often offset this
immensely, not to mention 1Gb of disk which never needs to be read
into the buffers ;-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
^ permalink raw reply [nested|flat] 57+ messages in thread
* BackUp
@ 2006-06-19 12:17 Daniel <DFelix19@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Daniel @ 2006-06-19 12:17 UTC (permalink / raw)
To: pgsql-general
Hi All..
Is there a way to do auto database bacl up in "PostgreSQL".
Please Reply..
Thanks,
Daniel
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: BackUp
@ 2006-06-22 06:10 Chris <dmagick@gmail.com>
parent: Daniel <DFelix19@gmail.com>
0 siblings, 0 replies; 57+ messages in thread
From: Chris @ 2006-06-22 06:10 UTC (permalink / raw)
To: Daniel <DFelix19@gmail.com>; +Cc: pgsql-general
Daniel wrote:
> Hi All..
> Is there a way to do auto database bacl up in "PostgreSQL".
> Please Reply..
There are different ways, the most common is to do a pg_dump /
pg_dumpall once a night via cron.
http://www.postgresql.org/docs/8.1/static/backup.html
--
Postgresql & php tutorials
http://www.designmagick.com/
^ permalink raw reply [nested|flat] 57+ messages in thread
* Backup ?
@ 2007-02-02 12:19 Wilton Wonrath <wrwonrath@yahoo.com.br>
0 siblings, 1 reply; 57+ messages in thread
From: Wilton Wonrath @ 2007-02-02 12:19 UTC (permalink / raw)
To: pgsql-general
Hi.
Is it possible to do a backup only with index ?
Is it possible to do a backup only with users, login roles or group roles ?
regards,
Wilton Ruffato Wonrath
wrwonrath@yahoo.com.br
__________________________________________________
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup ?
@ 2007-02-02 13:21 Richard Huxton <dev@archonet.com>
parent: Wilton Wonrath <wrwonrath@yahoo.com.br>
0 siblings, 0 replies; 57+ messages in thread
From: Richard Huxton @ 2007-02-02 13:21 UTC (permalink / raw)
To: Wilton Wonrath <wrwonrath@yahoo.com.br>; +Cc: pgsql-general
Wilton Wonrath wrote:
>
> Is it possible to do a backup only with index ?
You could backup the whole schema and then restore only the schema. See
the --use-list option on pg_restore.
> Is it possible to do a backup only with users, login roles or group roles ?
You can backup the roles with "pg_dumpall -g"
--
Richard Huxton
Archonet Ltd
^ permalink raw reply [nested|flat] 57+ messages in thread
* Backup
@ 2008-01-24 19:08 Dominic Carlucci <carlucci@cae.com>
0 siblings, 3 replies; 57+ messages in thread
From: Dominic Carlucci @ 2008-01-24 19:08 UTC (permalink / raw)
To: pgsql-general; pgsql-admin@postgresql.org; +Cc: carlucci@cae.ca
Hi,
We have a center in Europe who has just started to use PostgreSQL
and was asking me if there are any Symantec product or other products
that backup this type of database. We presently run VERITAS ver9.1 on
windows2003 server. What is being used by users out there now. We are
thinking of upgrading to the latest Symantec backup exec software but am
not sure if this version does backup PostgreSQL. When called for support
they told me to go to the Symantec site and search the compatibility
list. I didn't find anything dealing with PostgreSQL database.
Any answer would help me simplify my backup situation.
Thanks,
Dominic Carlucci
Production Control Analyst
CAE Inc.
8585 Cote de Liesse
St. Laurent, Quebec H4T 1G6
(514)341-2000 #2936
Carlucci@cae.ca
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2008-01-25 00:34 Phillip Smith <phillip.smith@weatherbeeta.com.au>
parent: Dominic Carlucci <carlucci@cae.com>
2 siblings, 1 reply; 57+ messages in thread
From: Phillip Smith @ 2008-01-25 00:34 UTC (permalink / raw)
To: 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; +Cc: carlucci@cae.ca
> We have a center in Europe who has just started to use PostgreSQL and was
> asking me if there are any Symantec product or other products that backup
> this type of database.
It doesn't appear to. I've just been through the whole rigmarole of
BackupExec for some Windows Servers, and I couldn't find anything to deal
with PostgreSQL.
Just dump Postgres to the File System and backup that dump. Depends on what
your Recovery Point requirements are.
THINK BEFORE YOU PRINT - Save paper if you don't really need to print this
*******************Confidentiality and Privilege Notice*******************
The material contained in this message is privileged and confidential to
the addressee. If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.
Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments
e-mail.
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2008-01-25 00:47 Scott Marlowe <scott.marlowe@gmail.com>
parent: Dominic Carlucci <carlucci@cae.com>
2 siblings, 0 replies; 57+ messages in thread
From: Scott Marlowe @ 2008-01-25 00:47 UTC (permalink / raw)
To: Dominic Carlucci <carlucci@cae.com>; +Cc: pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Jan 24, 2008 1:08 PM, Dominic Carlucci <carlucci@cae.com> wrote:
>
>
> Hi,
> We have a center in Europe who has just started to use PostgreSQL and
> was asking me if there are any Symantec product or other products that
> backup this type of database. We presently run VERITAS ver9.1 on
> windows2003 server. What is being used by users out there now. We are
> thinking of upgrading to the latest Symantec backup exec software but am not
> sure if this version does backup PostgreSQL. When called for support they
> told me to go to the Symantec site and search the compatibility list. I
> didn't find anything dealing with PostgreSQL database.
> Any answer would help me simplify my backup situation.
Not sure if there's some kind of special plug in for Symantec, but
basically, you want to run pg_dump or pg_dumpall and then point
symantec to back up the file thus created.
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2008-01-25 09:21 Simon Riggs <simon@2ndquadrant.com>
parent: Phillip Smith <phillip.smith@weatherbeeta.com.au>
0 siblings, 1 reply; 57+ messages in thread
From: Simon Riggs @ 2008-01-25 09:21 UTC (permalink / raw)
To: Phillip Smith <phillip.smith@weatherbeeta.com.au>; +Cc: 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Fri, 2008-01-25 at 11:34 +1100, Phillip Smith wrote:
> > We have a center in Europe who has just started to use PostgreSQL and was
> > asking me if there are any Symantec product or other products that backup
> > this type of database.
>
> It doesn't appear to.
The design of the PITR system allows a product-agnostic backup. Anything
that can backup a file can backup PostgreSQL. There is no need for
special certifications of hologram logos.
You may need to write a few lines of script to do it, but that's not a
problem surely?
So you can use pg_dump or PITR, as you choose.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2008-01-30 04:15 Vishal Arora <aroravishal22@hotmail.com>
parent: Dominic Carlucci <carlucci@cae.com>
2 siblings, 1 reply; 57+ messages in thread
From: Vishal Arora @ 2008-01-30 04:15 UTC (permalink / raw)
To: Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; +Cc: carlucci@cae.ca
PostgreSQL has its own inbuilt mechanism for backing up the database. you can refer to the postgres manual online for more information.
http://www.postgresql.org/docs/8.2/interactive/backup.html
- Vishal
Subject: [ADMIN] BackupDate: Thu, 24 Jan 2008 14:08:26 -0500From: carlucci@cae.comTo: pgsql-general@postgresql.org; pgsql-admin@postgresql.orgCC: carlucci@cae.ca
Hi,
We have a center in Europe who has just started to use PostgreSQL and was asking me if there are any Symantec product or other products that backup this type of database. We presently run VERITAS ver9.1 on windows2003 server. What is being used by users out there now. We are thinking of upgrading to the latest Symantec backup exec software but am not sure if this version does backup PostgreSQL. When called for support they told me to go to the Symantec site and search the compatibility list. I didn't find anything dealing with PostgreSQL database.
Any answer would help me simplify my backup situation.
Thanks,
Dominic CarlucciProduction Control Analyst
CAE Inc.8585 Cote de LiesseSt. Laurent, Quebec H4T 1G6
(514)341-2000 #2936Carlucci@cae.ca
_________________________________________________________________
Tried the new MSN Messenger? It’s cool! Download now.
http://messenger.msn.com/Download/Default.aspx?mkt=en-in=
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2008-01-30 04:27 Guido Barosio <gbarosio@gmail.com>
parent: Vishal Arora <aroravishal22@hotmail.com>
0 siblings, 0 replies; 57+ messages in thread
From: Guido Barosio @ 2008-01-30 04:27 UTC (permalink / raw)
To: Vishal Arora <aroravishal22@hotmail.com>; +Cc: Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
AFAIK Dominic needs a plug-in certified by Symantec, and that is not the case.
As you may have read prior to this mail, the common way is to pg_dump
against a file, picking up that file later with BackupExec as a
regular file.
We are currently (www.globant.com) using it that way, no problems at all.
gb.-
On Jan 30, 2008 2:15 AM, Vishal Arora <aroravishal22@hotmail.com> wrote:
>
> PostgreSQL has its own inbuilt mechanism for backing up the database. you
> can refer to the postgres manual online for more information.
>
> http://www.postgresql.org/docs/8.2/interactive/backup.html
>
> - Vishal
>
>
>
>
>
> ________________________________
> Subject: [ADMIN] Backup
> Date: Thu, 24 Jan 2008 14:08:26 -0500
> From: carlucci@cae.com
> To: pgsql-general@postgresql.org; pgsql-admin@postgresql.org
> CC: carlucci@cae.ca
>
>
>
>
> Hi,
> We have a center in Europe who has just started to use PostgreSQL and
> was asking me if there are any Symantec product or other products that
> backup this type of database. We presently run VERITAS ver9.1 on
> windows2003 server. What is being used by users out there now. We are
> thinking of upgrading to the latest Symantec backup exec software but am not
> sure if this version does backup PostgreSQL. When called for support they
> told me to go to the Symantec site and search the compatibility list. I
> didn't find anything dealing with PostgreSQL database.
> Any answer would help me simplify my backup situation.
> Thanks,
>
>
> Dominic Carlucci
> Production Control Analyst
>
> CAE Inc.
> 8585 Cote de Liesse
> St. Laurent, Quebec H4T 1G6
>
> (514)341-2000 #2936
> Carlucci@cae.ca
>
>
>
>
> ________________________________
> Live the life in style with MSN Lifestyle. Check out! Try it now!
>
--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 12:21 Chander Ganesan <chander@otg-nc.com>
parent: Simon Riggs <simon@2ndquadrant.com>
0 siblings, 1 reply; 57+ messages in thread
From: Chander Ganesan @ 2008-01-31 12:21 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Phillip Smith <phillip.smith@weatherbeeta.com.au>; Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
Simon Riggs wrote:
> On Fri, 2008-01-25 at 11:34 +1100, Phillip Smith wrote:
>
>>> We have a center in Europe who has just started to use PostgreSQL and was
>>> asking me if there are any Symantec product or other products that backup
>>> this type of database.
>>>
>> It doesn't appear to.
>>
>
> The design of the PITR system allows a product-agnostic backup. Anything
> that can backup a file can backup PostgreSQL. There is no need for
> special certifications of hologram logos.
>
> You may need to write a few lines of script to do it, but that's not a
> problem surely?
>
> So you can use pg_dump or PITR, as you choose.
>
If you don't mind if you lose some transactions you can also use file
system snapshotting....which would work just as well as pg_dump, and
probably have less impact on the running database (assuming you had
decent enough hardware).
So long as the product you are using can snapshot the file system prior
to performing a backup, you can use just about any product (without
having to really do much/any work). When you restore a snapshotted file
system that contains your postgresql database, postgresql (on restart)
will enter auto-recovery mode and recover (as it does in the case of the
crash) to the last transaction that was completed successfully prior to
the snapshot being created. Note that this would only work if all your
tablespaces were on the same file system, and would be unable to "roll
forward" using WAL files generated after the backup.
However, you should keep in mind that - like a pg_dump - you won't be
able to perform PITR recovery from such a backup. Also, the recovery
time may be non-trivial depending on your WAL settings.
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
Phone: 877-258-8987/919-463-0999
http://www.otg-nc.com
As me about Expert PostgreSQL & PostGIS Training delivered worldwide.
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 13:28 Simon Riggs <simon@2ndquadrant.com>
parent: Chander Ganesan <chander@otg-nc.com>
0 siblings, 2 replies; 57+ messages in thread
From: Simon Riggs @ 2008-01-31 13:28 UTC (permalink / raw)
To: Chander Ganesan <chander@otg-nc.com>; +Cc: Phillip Smith <phillip.smith@weatherbeeta.com.au>; 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Thu, 2008-01-31 at 07:21 -0500, Chander Ganesan wrote:
> If you don't mind if you lose some transactions
That sentence has no place in any discussion about "backup" because the
risk is not just a few transactions, it is a corrupt and inconsistent
database from which both old and new data would be inaccessible.
As far as I am concerned, if any Postgres user loses data then we're all
responsible.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 14:34 Martijn van Oosterhout <kleptog@svana.org>
parent: Simon Riggs <simon@2ndquadrant.com>
1 sibling, 1 reply; 57+ messages in thread
From: Martijn van Oosterhout @ 2008-01-31 14:34 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Chander Ganesan <chander@otg-nc.com>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
> That sentence has no place in any discussion about "backup" because the
> risk is not just a few transactions, it is a corrupt and inconsistent
> database from which both old and new data would be inaccessible.
Hmm? I thought the whole point of a filesystem snapshot was that it's
the same as if the system crashed. And I was fairly sure we could
recover from that...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy
Attachments:
signature.asc (application/pgp-signature, 188B) download
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 14:43 Magnus Hagander <magnus@hagander.net>
parent: Martijn van Oosterhout <kleptog@svana.org>
0 siblings, 1 reply; 57+ messages in thread
From: Magnus Hagander @ 2008-01-31 14:43 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; Chander Ganesan <chander@otg-nc.com>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
> > That sentence has no place in any discussion about "backup" because the
> > risk is not just a few transactions, it is a corrupt and inconsistent
> > database from which both old and new data would be inaccessible.
>
> Hmm? I thought the whole point of a filesystem snapshot was that it's
> the same as if the system crashed. And I was fairly sure we could
> recover from that...
That was my assumption as well. *Assuming* that the filesystem snapshot is
consistent. There are a bunch of solutions that don't do consistent
snapshots between different partitions, so if your WAL or one tablespace is
on a different partition, you'll get corruption anyway... (seen this in
Big Commercial Database, so that's not a pg problem)
//Magnus
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 15:00 Chander Ganesan <chander@otg-nc.com>
parent: Simon Riggs <simon@2ndquadrant.com>
1 sibling, 1 reply; 57+ messages in thread
From: Chander Ganesan @ 2008-01-31 15:00 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Phillip Smith <phillip.smith@weatherbeeta.com.au>; Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
Simon Riggs wrote:
> On Thu, 2008-01-31 at 07:21 -0500, Chander Ganesan wrote:
>
>> If you don't mind if you lose some transactions
>>
>
> That sentence has no place in any discussion about "backup" because the
> risk is not just a few transactions, it is a corrupt and inconsistent
> database from which both old and new data would be inaccessible.
>
> As far as I am concerned, if any Postgres user loses data then we're all
> responsible.
>
I understand your point, but indicating that you can't trust a
point-in-time snapshot of the database is, IMHO, the same as saying you
can't trust PostgreSQL's automatic crash recovery, since the two are
essentially the same thing...
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 15:02 Chander Ganesan <chander@otg-nc.com>
parent: Magnus Hagander <magnus@hagander.net>
0 siblings, 2 replies; 57+ messages in thread
From: Chander Ganesan @ 2008-01-31 15:02 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; Dominic Carlucci <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
Magnus Hagander wrote:
> On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
>
>> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
>>
>>> That sentence has no place in any discussion about "backup" because the
>>> risk is not just a few transactions, it is a corrupt and inconsistent
>>> database from which both old and new data would be inaccessible.
>>>
>> Hmm? I thought the whole point of a filesystem snapshot was that it's
>> the same as if the system crashed. And I was fairly sure we could
>> recover from that...
>>
>
> That was my assumption as well. *Assuming* that the filesystem snapshot is
> consistent. There are a bunch of solutions that don't do consistent
> snapshots between different partitions, so if your WAL or one tablespace is
> on a different partition, you'll get corruption anyway... (seen this in
> Big Commercial Database, so that's not a pg problem)
>
Agreed. That's why I made it a point to mention that all of your
tablespaces should be on the same file system... In hindsight, I should
have also stated that your WAL logs should be on the same file system as
well...
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 15:09 Alvaro Herrera <alvherre@commandprompt.com>
parent: Chander Ganesan <chander@otg-nc.com>
0 siblings, 1 reply; 57+ messages in thread
From: Alvaro Herrera @ 2008-01-31 15:09 UTC (permalink / raw)
To: Chander Ganesan <chander@otg-nc.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
> Simon Riggs wrote:
>> As far as I am concerned, if any Postgres user loses data then we're all
>> responsible.
Remember, our license says this software is given without any warranty
whatsoever, implicit or explicit, written or implied, given or sold,
alive or deceased.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 15:48 Simon Riggs <simon@2ndquadrant.com>
parent: Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 0 replies; 57+ messages in thread
From: Simon Riggs @ 2008-01-31 15:48 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Chander Ganesan <chander@otg-nc.com>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Thu, 2008-01-31 at 12:09 -0300, Alvaro Herrera wrote:
> > Simon Riggs wrote:
>
> >> As far as I am concerned, if any Postgres user loses data then we're all
> >> responsible.
>
> Remember, our license says this software is given without any warranty
> whatsoever, implicit or explicit, written or implied, given or sold,
> alive or deceased.
Yes! ...I meant via the free press, not via the courts.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-01-31 15:58 Simon Riggs <simon@2ndquadrant.com>
parent: Chander Ganesan <chander@otg-nc.com>
1 sibling, 0 replies; 57+ messages in thread
From: Simon Riggs @ 2008-01-31 15:58 UTC (permalink / raw)
To: Chander Ganesan <chander@otg-nc.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Phillip Smith <phillip.smith@weatherbeeta.com.au>; 'Dominic Carlucci' <carlucci@cae.com>; pgsql-general; pgsql-admin@postgresql.org; carlucci@cae.ca
On Thu, 2008-01-31 at 10:02 -0500, Chander Ganesan wrote:
> Magnus Hagander wrote:
> > On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
> >
> >> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
> >>
> >>> That sentence has no place in any discussion about "backup" because the
> >>> risk is not just a few transactions, it is a corrupt and inconsistent
> >>> database from which both old and new data would be inaccessible.
> >>>
> >> Hmm? I thought the whole point of a filesystem snapshot was that it's
> >> the same as if the system crashed. And I was fairly sure we could
> >> recover from that...
> >>
> >
> > That was my assumption as well. *Assuming* that the filesystem snapshot is
> > consistent. There are a bunch of solutions that don't do consistent
> > snapshots between different partitions, so if your WAL or one tablespace is
> > on a different partition, you'll get corruption anyway... (seen this in
> > Big Commercial Database, so that's not a pg problem)
> >
> Agreed. That's why I made it a point to mention that all of your
> tablespaces should be on the same file system... In hindsight, I should
> have also stated that your WAL logs should be on the same file system as
> well...
I think we all understand and agree, I just start twitching when anyone
talks about it being OK to lose transactions when backing up. You meant
the ones currently in progress, not the ones already committed and on
disk.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-02-06 13:29 Hannes Dorbath <light@theendofthetunnel.de>
parent: Chander Ganesan <chander@otg-nc.com>
1 sibling, 1 reply; 57+ messages in thread
From: Hannes Dorbath @ 2008-02-06 13:29 UTC (permalink / raw)
To: Chander Ganesan <chander@otg-nc.com>
Chander Ganesan wrote:
> Magnus Hagander wrote:
>> On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
>>
>>> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
>>>
>>>> That sentence has no place in any discussion about "backup" because the
>>>> risk is not just a few transactions, it is a corrupt and inconsistent
>>>> database from which both old and new data would be inaccessible.
>>>>
>>> Hmm? I thought the whole point of a filesystem snapshot was that it's
>>> the same as if the system crashed. And I was fairly sure we could
>>> recover from that...
>>>
>>
>> That was my assumption as well. *Assuming* that the filesystem
>> snapshot is
>> consistent. There are a bunch of solutions that don't do consistent
>> snapshots between different partitions, so if your WAL or one
>> tablespace is
>> on a different partition, you'll get corruption anyway... (seen this in
>> Big Commercial Database, so that's not a pg problem)
>>
> Agreed. That's why I made it a point to mention that all of your
> tablespaces should be on the same file system... In hindsight, I should
> have also stated that your WAL logs should be on the same file system as
One more reason to consider using Solaris ZFS -- it does consistent
snapshots across all file systems.
--
Best regards,
Hannes Dorbath
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: [GENERAL] Backup
@ 2008-02-06 13:49 Hannes Dorbath <light@theendofthetunnel.de>
parent: Hannes Dorbath <light@theendofthetunnel.de>
0 siblings, 0 replies; 57+ messages in thread
From: Hannes Dorbath @ 2008-02-06 13:49 UTC (permalink / raw)
To: pgsql-admin@postgresql.org; +Cc: Chander Ganesan <chander@otg-nc.com>
Hannes Dorbath wrote:
> Chander Ganesan wrote:
>> Magnus Hagander wrote:
>>> On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
>>>
>>>> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
>>>>
>>>>> That sentence has no place in any discussion about "backup" because
>>>>> the
>>>>> risk is not just a few transactions, it is a corrupt and inconsistent
>>>>> database from which both old and new data would be inaccessible.
>>>>>
>>>> Hmm? I thought the whole point of a filesystem snapshot was that it's
>>>> the same as if the system crashed. And I was fairly sure we could
>>>> recover from that...
>>>>
>>>
>>> That was my assumption as well. *Assuming* that the filesystem
>>> snapshot is
>>> consistent. There are a bunch of solutions that don't do consistent
>>> snapshots between different partitions, so if your WAL or one
>>> tablespace is
>>> on a different partition, you'll get corruption anyway... (seen this in
>>> Big Commercial Database, so that's not a pg problem)
>>>
>> Agreed. That's why I made it a point to mention that all of your
>> tablespaces should be on the same file system... In hindsight, I
>> should have also stated that your WAL logs should be on the same file
>> system as
>
> One more reason to consider using Solaris ZFS -- it does consistent
> snapshots across all file systems.
In general file system snapshots are quite a pain with Linux LVM.
Even when using separate spindles for the snapshot COW area the impact
on write performance on the origin LV is still huge. You'll have a hard
time to write with more than 15MB/sec to the origin LV.
Additionally when you lost your COW device there is this nice bug in
vgreduce --removemissing that will silently delete your origin LV as
well: http://readlist.com/lists/redhat.com/linux-lvm/0/2025.html
Not to mention that LVM does not support write barriers and does mess
with any kind of stripe alignment of your file system.
--
Best regards,
Hannes Dorbath
^ permalink raw reply [nested|flat] 57+ messages in thread
* backup
@ 2024-10-07 15:48 Andy Hartman <hartman60home@gmail.com>
0 siblings, 3 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-07 15:48 UTC (permalink / raw)
To: pgsql-general
anyone use Powershell in an automated fashion to do DB backup? Would you
share your example?
Thanks.
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: backup
@ 2024-10-07 16:14 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
2 siblings, 0 replies; 57+ messages in thread
From: Adrian Klaver @ 2024-10-07 16:14 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; pgsql-general
On 10/7/24 08:48, Andy Hartman wrote:
> anyone use Powershell in an automated fashion to do DB backup? Would
> you share your example?
Search engine of your choice: "powershell postgresql backup script"
Using DuckDuckGo I see 6 relevant entries right of the top.
>
> Thanks.
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: backup
@ 2024-10-07 16:17 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Andy Hartman <hartman60home@gmail.com>
2 siblings, 0 replies; 57+ messages in thread
From: Ron Johnson @ 2024-10-07 16:17 UTC (permalink / raw)
To: pgsql-general
On Mon, Oct 7, 2024 at 11:48 AM Andy Hartman <hartman60home@gmail.com>
wrote:
> anyone use Powershell in an automated fashion to do DB backup? Would you
> share your example?
>
PS can execute utilities, so using it as a wrapper for pg_dump and
pg_restore (just like a bash script) is perfectly viable.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: backup
@ 2024-10-08 03:24 Muhammad Usman Khan <usman.k@bitnine.net>
parent: Andy Hartman <hartman60home@gmail.com>
2 siblings, 1 reply; 57+ messages in thread
From: Muhammad Usman Khan @ 2024-10-08 03:24 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general
Hi,
You can refer the following:
Automating PostgreSQL Backups with Python Using pg_basebackup | by Usman
Khan | Sep, 2024 | Medium
<https://medium.com/@usman.khan9805/automating-postgresql-backups-with-python-using-pg-basebackup-fe8...;
Automating PostgreSQL Backups with PG Back Web: The Complete Walkthrough |
by Usman Khan | Sep, 2024 | Medium
<https://medium.com/@usman.khan9805/automating-postgresql-backups-with-pg-back-web-the-complete-walkt...;
On Mon, 7 Oct 2024 at 20:48, Andy Hartman <hartman60home@gmail.com> wrote:
> anyone use Powershell in an automated fashion to do DB backup? Would you
> share your example?
>
> Thanks.
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: backup
@ 2024-10-08 11:31 Andy Hartman <hartman60home@gmail.com>
parent: Muhammad Usman Khan <usman.k@bitnine.net>
0 siblings, 0 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-08 11:31 UTC (permalink / raw)
To: Muhammad Usman Khan <usman.k@bitnine.net>; +Cc: pgsql-general
Thanks, I'll check it out.
On Mon, Oct 7, 2024 at 11:25 PM Muhammad Usman Khan <usman.k@bitnine.net>
wrote:
>
> Hi,
> You can refer the following:
> Automating PostgreSQL Backups with Python Using pg_basebackup | by Usman
> Khan | Sep, 2024 | Medium
> <https://medium.com/@usman.khan9805/automating-postgresql-backups-with-python-using-pg-basebackup-fe8...;
> Automating PostgreSQL Backups with PG Back Web: The Complete Walkthrough |
> by Usman Khan | Sep, 2024 | Medium
> <https://medium.com/@usman.khan9805/automating-postgresql-backups-with-pg-back-web-the-complete-walkt...;
>
> On Mon, 7 Oct 2024 at 20:48, Andy Hartman <hartman60home@gmail.com> wrote:
>
>> anyone use Powershell in an automated fashion to do DB backup? Would you
>> share your example?
>>
>> Thanks.
>>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Backup
@ 2024-10-16 19:37 Andy Hartman <hartman60home@gmail.com>
0 siblings, 4 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-16 19:37 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
I am very new to Postgres and have always worked in the mssql world. I'm
looking for suggestions on DB backups. I currently have a DB used to store
Historical information that has images it's currently around 100gig.
I'm looking to take a monthly backup as I archive a month of data at a
time. I am looking for it to be compressed and have a machine that has
multiple cpu's and ample memory.
Suggestions on things I can try ?
I did a pg_dump using these parms
--format=t --blobs lobarch
it ran my device out of storage:
pg_dump: error: could not write to output file: No space left on device
I have 150gig free on my backup drive... can obviously add more
looking for the quickest and smallest backup file output...
Thanks again for help\suggestions
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 19:52 Tomas Vondra <tomas@vondra.me>
parent: Andy Hartman <hartman60home@gmail.com>
3 siblings, 2 replies; 57+ messages in thread
From: Tomas Vondra @ 2024-10-16 19:52 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; pgsql-general@lists.postgresql.org
On 10/16/24 21:37, Andy Hartman wrote:
> I am very new to Postgres and have always worked in the mssql world. I'm
> looking for suggestions on DB backups. I currently have a DB used to
> store Historical information that has images it's currently around 100gig.
>
> I'm looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t --blobs lobarch
>
> it ran my device out of storage:
>
> pg_dump: error: could not write to output file: No space left on device
>
> I have 150gig free on my backup drive... can obviously add more
>
> looking for the quickest and smallest backup file output...
>
> Thanks again for help\suggestions
>
You didn't specify the Postgres version - that matters, because older
pg_dump versions (before PG 16) do not support compression. Since PG 16
you can use either -Fc or -Fd (instead of the tar format), and it'll
compress the output using gzip.
Alternatively, you can use --compress=method:level (the supported
methods depend on how the packages were built, no idea what platform
you're on etc.). See
https://www.postgresql.org/docs/current/app-pgdump.html
If you're on older version, you should be able to write the dump to
standard output, and compress that way. Something like
pg_dump -Fc | gzip -c > compressed.dump.gz
However, be aware that pg_dump is more an export tool than a backup
suitable for large databases / quick recovery. It won't allow doing PITR
and similar stuff.
regards
--
Tomas Vondra
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 19:55 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Andy Hartman <hartman60home@gmail.com>
3 siblings, 1 reply; 57+ messages in thread
From: Ron Johnson @ 2024-10-16 19:55 UTC (permalink / raw)
To: pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman <hartman60home@gmail.com>
wrote:
> I am very new to Postgres and have always worked in the mssql world. I'm
> looking for suggestions on DB backups. I currently have a DB used to store
> Historical information that has images it's currently around 100gig.
>
> I'm looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t --blobs lobarch
>
> it ran my device out of storage:
>
> pg_dump: error: could not write to output file: No space left on device
>
> I have 150gig free on my backup drive... can obviously add more
>
> looking for the quickest and smallest backup file output...
>
> Thanks again for help\suggestions
>
Step 1: redesign your DB to *NOT* use large objects. It's an old, slow and
unmaintained data type. The data type is what you should use.
Step 2: show us the "before" df output, the whole pg_dump command, and the
"after" df output when it fails. "du -c --max-depth=0 $PGDATA/base" also
very useful.
And tell us what version you're using.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 19:59 Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Achilleas Mantzios @ 2024-10-16 19:59 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
> On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman <hartman60home@gmail.com>
> wrote:
>
> I am very new to Postgres and have always worked in the mssql
> world. I'm looking for suggestions on DB backups. I currently have
> a DB used to store Historical information that has images it's
> currently around 100gig.
>
> I'm looking to take a monthly backup as I archive a month of data
> at a time. I am looking for it to be compressed and have a machine
> that has multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t --blobs lobarch
>
> it ran my device out of storage:
>
> pg_dump: error: could not write to output file: No space left on
> device
>
> I have 150gig free on my backup drive... can obviously add more
>
> looking for the quickest and smallest backup file output...
>
> Thanks again for help\suggestions
>
>
> Step 1: redesign your DB to *NOT* use large objects. It's an old,
> slow and unmaintained data type. The data type is what you should use.
You mean bytea I guess. As a side note, (not a fan of LOs), I had the
impression that certain drivers such as the JDBC support streaming for
LOs but not for bytea? It's been a while I haven't hit the docs tho.
>
> Step 2: show us the "before" df output, the whole pg_dump command, and
> the "after" df output when it fails. "du -c --max-depth=0
> $PGDATA/base" also very useful.
>
> And tell us what version you're using.
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 20:00 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Tomas Vondra <tomas@vondra.me>
1 sibling, 0 replies; 57+ messages in thread
From: Ron Johnson @ 2024-10-16 20:00 UTC (permalink / raw)
To: pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
On Wed, Oct 16, 2024 at 3:52 PM Tomas Vondra <tomas@vondra.me> wrote:
[snip]
> You didn't specify the Postgres version - that matters, because older
> pg_dump versions (before PG 16) do not support compression. Since PG 16
> you can use either -Fc or -Fd (instead of the tar format), and it'll
> compress the output using gzip.
>
Not true. pg_dump has had built-in gzipping of directory format backups
since at least 9.6. Probably earlier.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 20:02 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
0 siblings, 2 replies; 57+ messages in thread
From: Ron Johnson @ 2024-10-16 20:02 UTC (permalink / raw)
To: pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios <
a.mantzios@cloud.gatewaynet.com> wrote:
> Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
>
> On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman <hartman60home@gmail.com>
> wrote:
>
>> I am very new to Postgres and have always worked in the mssql world. I'm
>> looking for suggestions on DB backups. I currently have a DB used to store
>> Historical information that has images it's currently around 100gig.
>>
>> I'm looking to take a monthly backup as I archive a month of data at a
>> time. I am looking for it to be compressed and have a machine that has
>> multiple cpu's and ample memory.
>>
>> Suggestions on things I can try ?
>> I did a pg_dump using these parms
>> --format=t --blobs lobarch
>>
>> it ran my device out of storage:
>>
>> pg_dump: error: could not write to output file: No space left on device
>>
>> I have 150gig free on my backup drive... can obviously add more
>>
>> looking for the quickest and smallest backup file output...
>>
>> Thanks again for help\suggestions
>>
>
> Step 1: redesign your DB to *NOT* use large objects. It's an old, slow
> and unmaintained data type. The data type is what you should use.
>
> You mean bytea I guess. As a side note, (not a fan of LOs), I had the
> impression that certain drivers such as the JDBC support streaming for LOs
> but not for bytea? It's been a while I haven't hit the docs tho.
>
Our database is stuffed with images in bytea fields. The Java application
uses JDBC and handles them just fine.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 20:16 Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
1 sibling, 0 replies; 57+ messages in thread
From: Achilleas Mantzios @ 2024-10-16 20:16 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Στις 16/10/24 23:02, ο/η Ron Johnson έγραψε:
> On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios
> <a.mantzios@cloud.gatewaynet.com> wrote:
>
> Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
>
>> On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman
>> <hartman60home@gmail.com> wrote:
>>
>> I am very new to Postgres and have always worked in the mssql
>> world. I'm looking for suggestions on DB backups. I currently
>> have a DB used to store Historical information that has
>> images it's currently around 100gig.
>>
>> I'm looking to take a monthly backup as I archive a month of
>> data at a time. I am looking for it to be compressed and have
>> a machine that has multiple cpu's and ample memory.
>>
>> Suggestions on things I can try ?
>> I did a pg_dump using these parms
>> --format=t --blobs lobarch
>>
>> it ran my device out of storage:
>>
>> pg_dump: error: could not write to output file: No space left
>> on device
>>
>> I have 150gig free on my backup drive... can obviously add more
>>
>> looking for the quickest and smallest backup file output...
>>
>> Thanks again for help\suggestions
>>
>>
>> Step 1: redesign your DB to *NOT* use large objects. It's an
>> old, slow and unmaintained data type. The data type is what you
>> should use.
> You mean bytea I guess. As a side note, (not a fan of LOs), I had
> the impression that certain drivers such as the JDBC support
> streaming for LOs but not for bytea? It's been a while I haven't
> hit the docs tho.
>
>
> Our database is stuffed with images in bytea fields. The Java
> application uses JDBC and handles them just fine.
Likewise, but the "streaming" part is still not clear to me, unless one
reads the newest JDBC source. Lots of problems due to image explosion,
java app heap space exhaustion and the like.
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> crustacean!
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 20:32 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Tomas Vondra <tomas@vondra.me>
1 sibling, 0 replies; 57+ messages in thread
From: Adrian Klaver @ 2024-10-16 20:32 UTC (permalink / raw)
To: Tomas Vondra <tomas@vondra.me>; Andy Hartman <hartman60home@gmail.com>; pgsql-general@lists.postgresql.org
On 10/16/24 12:52, Tomas Vondra wrote:
> On 10/16/24 21:37, Andy Hartman wrote:
>> I am very new to Postgres and have always worked in the mssql world. I'm
> You didn't specify the Postgres version - that matters, because older
> pg_dump versions (before PG 16) do not support compression. Since PG 16
> you can use either -Fc or -Fd (instead of the tar format), and it'll
> compress the output using gzip.
Oh, it goes back further then that:
https://www.postgresql.org/docs/7.1/app-pgdump.html
"-F format, --format=format
Format can be one of the following:
p
output a plain text SQL script file (default)
t
output a tar archive suitable for input into pg_restore. Using
this archive format allows reordering and/or exclusion of schema
elements at the time the database is restored. It is also possible to
limit which data is reloaded at restore time.
c
output a custom archive suitable for input into pg_restore.
This is the most flexible format in that it allows reordering of data
load as well as schema elements. This format is also compressed by default.
"
>
> Alternatively, you can use --compress=method:level (the supported
> methods depend on how the packages were built, no idea what platform
> you're on etc.). See
>
> https://www.postgresql.org/docs/current/app-pgdump.html
>
> If you're on older version, you should be able to write the dump to
> standard output, and compress that way. Something like
>
> pg_dump -Fc | gzip -c > compressed.dump.gz
>
> However, be aware that pg_dump is more an export tool than a backup
> suitable for large databases / quick recovery. It won't allow doing PITR
> and similar stuff.
>
>
> regards
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 21:48 Peter J. Holzer <hjp-pgsql@hjp.at>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
1 sibling, 1 reply; 57+ messages in thread
From: Peter J. Holzer @ 2024-10-16 21:48 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 2024-10-16 16:02:24 -0400, Ron Johnson wrote:
> On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios <
> a.mantzios@cloud.gatewaynet.com> wrote:
> Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
> On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman <hartman60home@gmail.com>
> wrote:
[...]
>
> Step 1: redesign your DB to NOT use large objects. It's an old, slow
> and unmaintained data type. The data type is what you should use.
>
> You mean bytea I guess. As a side note, (not a fan of LOs), I had the
> impression that certain drivers such as the JDBC support streaming for LOs
> but not for bytea? It's been a while I haven't hit the docs tho.
>
>
> Our database is stuffed with images in bytea fields. The Java application uses
> JDBC and handles them just fine.
Images are usually small enough (a few MB) that they don't need to be
streamed.
I don't think bytea can be streamed in general. It's just like text, you
write and read the whole thing at once.
If you have data which is too large for that and want to store it in
bytea fields, you'll probably have to chunk it yourself (which you
probably have to anyway because for me "so large it has to be streamed"
implies "at least possibly larger than 1 GB").
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-16 22:59 Andy Hartman <hartman60home@gmail.com>
parent: Peter J. Holzer <hjp-pgsql@hjp.at>
0 siblings, 0 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-16 22:59 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
I'm on Ver16 and yes Our database has image in a bytea field.
Running on Win22 box...
On Wed, Oct 16, 2024 at 5:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
> On 2024-10-16 16:02:24 -0400, Ron Johnson wrote:
> > On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios <
> > a.mantzios@cloud.gatewaynet.com> wrote:
> > Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
> > On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman <
> hartman60home@gmail.com>
> > wrote:
> [...]
> >
> > Step 1: redesign your DB to NOT use large objects. It's an old,
> slow
> > and unmaintained data type. The data type is what you should
> use.
> >
> > You mean bytea I guess. As a side note, (not a fan of LOs), I had the
> > impression that certain drivers such as the JDBC support streaming
> for LOs
> > but not for bytea? It's been a while I haven't hit the docs tho.
> >
> >
> > Our database is stuffed with images in bytea fields. The Java
> application uses
> > JDBC and handles them just fine.
>
> Images are usually small enough (a few MB) that they don't need to be
> streamed.
>
> I don't think bytea can be streamed in general. It's just like text, you
> write and read the whole thing at once.
>
> If you have data which is too large for that and want to store it in
> bytea fields, you'll probably have to chunk it yourself (which you
> probably have to anyway because for me "so large it has to be streamed"
> implies "at least possibly larger than 1 GB").
>
> hp
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | hjp@hjp.at | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-17 03:52 Muhammad Usman Khan <usman.k@bitnine.net>
parent: Andy Hartman <hartman60home@gmail.com>
3 siblings, 0 replies; 57+ messages in thread
From: Muhammad Usman Khan @ 2024-10-17 03:52 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
Hi,
you can refer the following link where many backup methods are mentioned
according to your need.
Backups in PostgreSQL. In PostgreSQL, different types of… | by Usman Khan |
Aug, 2024 | Medium
<https://medium.com/@usman.khan9805/backups-in-postgresql-2fca57c2872b;
On Thu, 17 Oct 2024 at 00:37, Andy Hartman <hartman60home@gmail.com> wrote:
> I am very new to Postgres and have always worked in the mssql world. I'm
> looking for suggestions on DB backups. I currently have a DB used to store
> Historical information that has images it's currently around 100gig.
>
> I'm looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t --blobs lobarch
>
> it ran my device out of storage:
>
> pg_dump: error: could not write to output file: No space left on device
>
> I have 150gig free on my backup drive... can obviously add more
>
> looking for the quickest and smallest backup file output...
>
> Thanks again for help\suggestions
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-17 04:46 Asad Ali <asadalinagri@gmail.com>
parent: Andy Hartman <hartman60home@gmail.com>
3 siblings, 1 reply; 57+ messages in thread
From: Asad Ali @ 2024-10-17 04:46 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
Hi Andy,
I hope you're doing well. Based on your inquiry about PostgreSQL backups
for your 100GB historical database with images, here are some suggestions
that should help you achieve compressed, efficient backups without running
into storage issues.
*1. Use Custom Format with Compression*
A more efficient option would be to use the custom format (-Fc) with
compression. You can also adjust the compression level and make use of your
machine's multiple CPUs by using parallel jobs:
pg_dump -Fc -Z 9 -j 4 --blobs -f /path/to/backup/file.dump
your_database_name
- -Fc: Custom format (supports compression and flexible restore options).
- -Z 9: Maximum compression level (0-9 scale).
- -j 4: Number of parallel jobs (adjust based on CPU cores).
- --blobs: Includes large objects (important for your images).
This approach should give you a smaller backup file with faster performance.
*2. Splitting Backups into Parts*
If you're concerned about running out of storage space, consider splitting
the backup by table or schema, allowing more control over the backup size:
pg_dump -Fc --table=my_large_table -f /path/to/backup/my_large_table.dump
your_database_name
pg_dump -Fc --table=other_table -f /path/to/backup/other_table.dump
your_database_name
This can be helpful when you archive different tables or sections of data.
*3. External Compression Tools*
If you need additional compression, you can pipe the pg_dump output through
an external compression tool like gzip:
pg_dump -Fc --blobs your_database_name | gzip > /path/to/backup/file.dump.gz
This should further reduce the size of your backups.
*4. Consider Alternative Backup Methods*
- Explore other backup methods like `*pgBackRest` or `WAL-E`*. These tools
are specifically designed for PostgreSQL backups and offer features like
incremental backups and point-in-time recovery
pgbackrest --stanza=your-database --type=full --compress-type=zst
--compress-level=6 --process-max=4 backup
- You can use *pg_basebackup* for PostgreSQL backups, but it has
limitations compared to tools like pgBackRest. While pg_basebackup is easy
to use and built-in with PostgreSQL, it is primarily designed for physical
backups (base backups) and doesn't offer as many advanced features such as
incremental backups, sophisticated compression, or parallelism.
However, it does support basic compression and can be used for full backups.
pg_basebackup -D /path/to/backup/directory -F t -z -Z 9 -P -X stream
- -D: The destination directory for the backup.
- -F t: Specifies the tar format for the backup, which is required for
compression.
- -z: Compresses the output.
- -Z 9: Compression level (0–9, where 9 is the highest).
- -P: Shows the progress of the backup.
- -X stream: Includes the WAL files needed to make the backup consistent
(important for recovery).
pg_basebackup -D /backups/db_backup -F t -z -Z 9 -P -X stream
This command will take a full physical backup of the database, compress the
output using gzip, and store the backup in a tarball.
*5. Automating Backups*
Since you need monthly backups, I recommend automating this process with a
cron job. For example, you can set this up to run on the 1st of every month
at 2 AM:
0 2 1 * * /usr/bin/pg_dump -Fc -Z 9 -j 4 --blobs -f
/path/to/backup/file.dump your_database_name
*6. Monitoring Disk Usage & * *Backup Performance*
Finally, it's important to monitor your available storage. You can either
ensure you have enough free space or consider moving older backups to
external or cloud storage to free up space.
Use monitoring tools to track the performance of your backups. This will
help you identify any potential bottlenecks and optimize the backup process.
I hope this helps you create smaller and quicker backups for your
PostgreSQL database. Let me know if you have any questions or need further
assistance!
Best regards,
Asad Ali
On Thu, Oct 17, 2024 at 12:38 AM Andy Hartman <hartman60home@gmail.com>
wrote:
> I am very new to Postgres and have always worked in the mssql world. I'm
> looking for suggestions on DB backups. I currently have a DB used to store
> Historical information that has images it's currently around 100gig.
>
> I'm looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t --blobs lobarch
>
> it ran my device out of storage:
>
> pg_dump: error: could not write to output file: No space left on device
>
> I have 150gig free on my backup drive... can obviously add more
>
> looking for the quickest and smallest backup file output...
>
> Thanks again for help\suggestions
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-17 10:28 Andy Hartman <hartman60home@gmail.com>
parent: Asad Ali <asadalinagri@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Andy Hartman @ 2024-10-17 10:28 UTC (permalink / raw)
To: Asad Ali <asadalinagri@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
This is great, thank you so much!
On Thu, Oct 17, 2024 at 12:47 AM Asad Ali <asadalinagri@gmail.com> wrote:
>
> Hi Andy,
>
> I hope you're doing well. Based on your inquiry about PostgreSQL backups
> for your 100GB historical database with images, here are some suggestions
> that should help you achieve compressed, efficient backups without running
> into storage issues.
>
> *1. Use Custom Format with Compression*
> A more efficient option would be to use the custom format (-Fc) with
> compression. You can also adjust the compression level and make use of your
> machine's multiple CPUs by using parallel jobs:
>
> pg_dump -Fc -Z 9 -j 4 --blobs -f /path/to/backup/file.dump
> your_database_name
>
> - -Fc: Custom format (supports compression and flexible restore
> options).
> - -Z 9: Maximum compression level (0-9 scale).
> - -j 4: Number of parallel jobs (adjust based on CPU cores).
> - --blobs: Includes large objects (important for your images).
>
> This approach should give you a smaller backup file with faster
> performance.
>
> *2. Splitting Backups into Parts*
> If you're concerned about running out of storage space, consider splitting
> the backup by table or schema, allowing more control over the backup size:
>
> pg_dump -Fc --table=my_large_table -f /path/to/backup/my_large_table.dump
> your_database_name
> pg_dump -Fc --table=other_table -f /path/to/backup/other_table.dump
> your_database_name
>
> This can be helpful when you archive different tables or sections of data.
>
> *3. External Compression Tools*
> If you need additional compression, you can pipe the pg_dump output
> through an external compression tool like gzip:
>
> pg_dump -Fc --blobs your_database_name | gzip >
> /path/to/backup/file.dump.gz
>
> This should further reduce the size of your backups.
>
> *4. Consider Alternative Backup Methods*
> - Explore other backup methods like `*pgBackRest` or `WAL-E`*. These
> tools are specifically designed for PostgreSQL backups and offer features
> like incremental backups and point-in-time recovery
> pgbackrest --stanza=your-database --type=full --compress-type=zst
> --compress-level=6 --process-max=4 backup
>
> - You can use *pg_basebackup* for PostgreSQL backups, but it has
> limitations compared to tools like pgBackRest. While pg_basebackup is easy
> to use and built-in with PostgreSQL, it is primarily designed for physical
> backups (base backups) and doesn't offer as many advanced features such as
> incremental backups, sophisticated compression, or parallelism.
>
> However, it does support basic compression and can be used for full
> backups.
>
> pg_basebackup -D /path/to/backup/directory -F t -z -Z 9 -P -X stream
>
> - -D: The destination directory for the backup.
> - -F t: Specifies the tar format for the backup, which is required for
> compression.
> - -z: Compresses the output.
> - -Z 9: Compression level (0–9, where 9 is the highest).
> - -P: Shows the progress of the backup.
> - -X stream: Includes the WAL files needed to make the backup
> consistent (important for recovery).
>
> pg_basebackup -D /backups/db_backup -F t -z -Z 9 -P -X stream
> This command will take a full physical backup of the database, compress
> the output using gzip, and store the backup in a tarball.
>
> *5. Automating Backups*
> Since you need monthly backups, I recommend automating this process with a
> cron job. For example, you can set this up to run on the 1st of every month
> at 2 AM:
>
> 0 2 1 * * /usr/bin/pg_dump -Fc -Z 9 -j 4 --blobs -f
> /path/to/backup/file.dump your_database_name
>
> *6. Monitoring Disk Usage & * *Backup Performance*
> Finally, it's important to monitor your available storage. You can either
> ensure you have enough free space or consider moving older backups to
> external or cloud storage to free up space.
> Use monitoring tools to track the performance of your backups. This will
> help you identify any potential bottlenecks and optimize the backup process.
>
> I hope this helps you create smaller and quicker backups for your
> PostgreSQL database. Let me know if you have any questions or need further
> assistance!
>
> Best regards,
>
> Asad Ali
>
>
> On Thu, Oct 17, 2024 at 12:38 AM Andy Hartman <hartman60home@gmail.com>
> wrote:
>
>> I am very new to Postgres and have always worked in the mssql world. I'm
>> looking for suggestions on DB backups. I currently have a DB used to store
>> Historical information that has images it's currently around 100gig.
>>
>> I'm looking to take a monthly backup as I archive a month of data at a
>> time. I am looking for it to be compressed and have a machine that has
>> multiple cpu's and ample memory.
>>
>> Suggestions on things I can try ?
>> I did a pg_dump using these parms
>> --format=t --blobs lobarch
>>
>> it ran my device out of storage:
>>
>> pg_dump: error: could not write to output file: No space left on device
>>
>> I have 150gig free on my backup drive... can obviously add more
>>
>> looking for the quickest and smallest backup file output...
>>
>> Thanks again for help\suggestions
>>
>>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 12:39 Andy Hartman <hartman60home@gmail.com>
parent: Andy Hartman <hartman60home@gmail.com>
0 siblings, 2 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-18 12:39 UTC (permalink / raw)
To: Asad Ali <asadalinagri@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
I would like to use the closest thing to a mssql backup...
How do I install pgbackrest after downloading and UnZip?
On Thu, Oct 17, 2024 at 6:28 AM Andy Hartman <hartman60home@gmail.com>
wrote:
> This is great, thank you so much!
>
> On Thu, Oct 17, 2024 at 12:47 AM Asad Ali <asadalinagri@gmail.com> wrote:
>
>>
>> Hi Andy,
>>
>> I hope you're doing well. Based on your inquiry about PostgreSQL backups
>> for your 100GB historical database with images, here are some suggestions
>> that should help you achieve compressed, efficient backups without running
>> into storage issues.
>>
>> *1. Use Custom Format with Compression*
>> A more efficient option would be to use the custom format (-Fc) with
>> compression. You can also adjust the compression level and make use of your
>> machine's multiple CPUs by using parallel jobs:
>>
>> pg_dump -Fc -Z 9 -j 4 --blobs -f /path/to/backup/file.dump
>> your_database_name
>>
>> - -Fc: Custom format (supports compression and flexible restore
>> options).
>> - -Z 9: Maximum compression level (0-9 scale).
>> - -j 4: Number of parallel jobs (adjust based on CPU cores).
>> - --blobs: Includes large objects (important for your images).
>>
>> This approach should give you a smaller backup file with faster
>> performance.
>>
>> *2. Splitting Backups into Parts*
>> If you're concerned about running out of storage space, consider
>> splitting the backup by table or schema, allowing more control over the
>> backup size:
>>
>> pg_dump -Fc --table=my_large_table -f /path/to/backup/my_large_table.dump
>> your_database_name
>> pg_dump -Fc --table=other_table -f /path/to/backup/other_table.dump
>> your_database_name
>>
>> This can be helpful when you archive different tables or sections of data.
>>
>> *3. External Compression Tools*
>> If you need additional compression, you can pipe the pg_dump output
>> through an external compression tool like gzip:
>>
>> pg_dump -Fc --blobs your_database_name | gzip >
>> /path/to/backup/file.dump.gz
>>
>> This should further reduce the size of your backups.
>>
>> *4. Consider Alternative Backup Methods*
>> - Explore other backup methods like `*pgBackRest` or `WAL-E`*. These
>> tools are specifically designed for PostgreSQL backups and offer features
>> like incremental backups and point-in-time recovery
>> pgbackrest --stanza=your-database --type=full --compress-type=zst
>> --compress-level=6 --process-max=4 backup
>>
>> - You can use *pg_basebackup* for PostgreSQL backups, but it has
>> limitations compared to tools like pgBackRest. While pg_basebackup is easy
>> to use and built-in with PostgreSQL, it is primarily designed for physical
>> backups (base backups) and doesn't offer as many advanced features such as
>> incremental backups, sophisticated compression, or parallelism.
>>
>> However, it does support basic compression and can be used for full
>> backups.
>>
>> pg_basebackup -D /path/to/backup/directory -F t -z -Z 9 -P -X stream
>>
>> - -D: The destination directory for the backup.
>> - -F t: Specifies the tar format for the backup, which is required
>> for compression.
>> - -z: Compresses the output.
>> - -Z 9: Compression level (0–9, where 9 is the highest).
>> - -P: Shows the progress of the backup.
>> - -X stream: Includes the WAL files needed to make the backup
>> consistent (important for recovery).
>>
>> pg_basebackup -D /backups/db_backup -F t -z -Z 9 -P -X stream
>> This command will take a full physical backup of the database, compress
>> the output using gzip, and store the backup in a tarball.
>>
>> *5. Automating Backups*
>> Since you need monthly backups, I recommend automating this process with
>> a cron job. For example, you can set this up to run on the 1st of every
>> month at 2 AM:
>>
>> 0 2 1 * * /usr/bin/pg_dump -Fc -Z 9 -j 4 --blobs -f
>> /path/to/backup/file.dump your_database_name
>>
>> *6. Monitoring Disk Usage & * *Backup Performance*
>> Finally, it's important to monitor your available storage. You can either
>> ensure you have enough free space or consider moving older backups to
>> external or cloud storage to free up space.
>> Use monitoring tools to track the performance of your backups. This will
>> help you identify any potential bottlenecks and optimize the backup process.
>>
>> I hope this helps you create smaller and quicker backups for your
>> PostgreSQL database. Let me know if you have any questions or need further
>> assistance!
>>
>> Best regards,
>>
>> Asad Ali
>>
>>
>> On Thu, Oct 17, 2024 at 12:38 AM Andy Hartman <hartman60home@gmail.com>
>> wrote:
>>
>>> I am very new to Postgres and have always worked in the mssql world. I'm
>>> looking for suggestions on DB backups. I currently have a DB used to store
>>> Historical information that has images it's currently around 100gig.
>>>
>>> I'm looking to take a monthly backup as I archive a month of data at a
>>> time. I am looking for it to be compressed and have a machine that has
>>> multiple cpu's and ample memory.
>>>
>>> Suggestions on things I can try ?
>>> I did a pg_dump using these parms
>>> --format=t --blobs lobarch
>>>
>>> it ran my device out of storage:
>>>
>>> pg_dump: error: could not write to output file: No space left on device
>>>
>>> I have 150gig free on my backup drive... can obviously add more
>>>
>>> looking for the quickest and smallest backup file output...
>>>
>>> Thanks again for help\suggestions
>>>
>>>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 14:45 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
1 sibling, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-18 14:45 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; Asad Ali <asadalinagri@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
On 10/18/24 05:39, Andy Hartman wrote:
> I would like to use the closest thing to a mssql backup...
>
> How do I install pgbackrest after downloading and UnZip?
Read the docs?:
https://pgbackrest.org/user-guide.html#installation
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 15:34 Andy Hartman <hartman60home@gmail.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 57+ messages in thread
From: Andy Hartman @ 2024-10-18 15:34 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@aklaver.com>; +Cc: Asad Ali <asadalinagri@gmail.com>; pgsql-general@lists.postgresql.org
Thanks.. I'm on a Windows platform using PG.
On Fri, Oct 18, 2024 at 10:45 AM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
> On 10/18/24 05:39, Andy Hartman wrote:
> > I would like to use the closest thing to a mssql backup...
> >
> > How do I install pgbackrest after downloading and UnZip?
>
> Read the docs?:
>
> https://pgbackrest.org/user-guide.html#installation
>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 15:55 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
0 siblings, 0 replies; 57+ messages in thread
From: Adrian Klaver @ 2024-10-18 15:55 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: Asad Ali <asadalinagri@gmail.com>; pgsql-general@lists.postgresql.org
On 10/18/24 08:34, Andy Hartman wrote:
> Thanks.. I'm on a Windows platform using PG.
AFAIK pgBackRest does not run on Windows:
https://github.com/pgbackrest/pgbackrest/issues/2431
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 16:04 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
1 sibling, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-18 16:04 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; Asad Ali <asadalinagri@gmail.com>; +Cc: pgsql-general@lists.postgresql.org
On 10/18/24 05:39, Andy Hartman wrote:
> I would like to use the closest thing to a mssql backup...
>
As in?
Searching on 'mssql backup' returns a lot of choices. You will need to
be more specific on what you want to achieve. Also be specific about
what versions of OS and Postgres you are using.
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 17:00 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-18 17:00 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general
On 10/18/24 09:52, Andy Hartman wrote:
Reply to list also
Ccing list.
> Windows 22 and Postgres 16.4
>
Is that Windows Server 2022 or Windows 10/11 with the 22H2 update?
You also need to provide a more detailed description of what you want
the backup to do?
>
>
> On Fri, Oct 18, 2024 at 12:04 PM Adrian Klaver
> <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
>
> On 10/18/24 05:39, Andy Hartman wrote:
> > I would like to use the closest thing to a mssql backup...
> >
>
> As in?
>
> Searching on 'mssql backup' returns a lot of choices. You will need to
> be more specific on what you want to achieve. Also be specific about
> what versions of OS and Postgres you are using.
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 18:25 Andy Hartman <hartman60home@gmail.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 57+ messages in thread
From: Andy Hartman @ 2024-10-18 18:25 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@aklaver.com>; +Cc: pgsql-general
Windows Server 2022
I would like a backup process similar to what I'm used to using in the
mssql world if that's possible with Postgres... I will be loading monthly
archive data to Postgresql so that's why I probably only need once a backup
.. once loaded data is just viewed thru an app... no updates..
in mssql you create the .bak and easily restorable .... that's what I'm
looking for with Postgres
thanks for replies..
On Fri, Oct 18, 2024 at 1:00 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
> On 10/18/24 09:52, Andy Hartman wrote:
>
> Reply to list also
> Ccing list.
>
> > Windows 22 and Postgres 16.4
> >
> Is that Windows Server 2022 or Windows 10/11 with the 22H2 update?
>
> You also need to provide a more detailed description of what you want
> the backup to do?
>
> >
> >
> > On Fri, Oct 18, 2024 at 12:04 PM Adrian Klaver
> > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
> >
> > On 10/18/24 05:39, Andy Hartman wrote:
> > > I would like to use the closest thing to a mssql backup...
> > >
> >
> > As in?
> >
> > Searching on 'mssql backup' returns a lot of choices. You will need
> to
> > be more specific on what you want to achieve. Also be specific about
> > what versions of OS and Postgres you are using.
> >
> > --
> > Adrian Klaver
> > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-18 18:30 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-18 18:30 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general
On 10/18/24 11:25 AM, Andy Hartman wrote:
> Windows Server 2022
>
> I would like a backup process similar to what I'm used to using in the
> mssql world if that's possible with Postgres... I will be
> loading monthly archive data to Postgresql so that's why I probably only
> need once a backup .. once loaded data is just viewed thru an app... no
> updates..
>
> in mssql you create the .bak and easily restorable .... that's what I'm
> looking for with Postgres
>
Then pg_dump for database backup:
https://www.postgresql.org/docs/current/app-pgdump.html
and pg_dumpall for entire cluster backup:
https://www.postgresql.org/docs/current/app-pg-dumpall.html
> thanks for replies..
>
>
>
> On Fri, Oct 18, 2024 at 1:00 PM Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
> On 10/18/24 09:52, Andy Hartman wrote:
>
> Reply to list also
> Ccing list.
>
> > Windows 22 and Postgres 16.4
> >
> Is that Windows Server 2022 or Windows 10/11 with the 22H2 update?
>
> You also need to provide a more detailed description of what you want
> the backup to do?
>
> >
> >
> > On Fri, Oct 18, 2024 at 12:04 PM Adrian Klaver
> > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> <mailto:adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>>> wrote:
> >
> > On 10/18/24 05:39, Andy Hartman wrote:
> > > I would like to use the closest thing to a mssql backup...
> > >
> >
> > As in?
> >
> > Searching on 'mssql backup' returns a lot of choices. You
> will need to
> > be more specific on what you want to achieve. Also be
> specific about
> > what versions of OS and Postgres you are using.
> >
> > --
> > Adrian Klaver
> > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> <mailto:adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>>
> >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-23 14:07 Andy Hartman <hartman60home@gmail.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 57+ messages in thread
From: Andy Hartman @ 2024-10-23 14:07 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@aklaver.com>; +Cc: pgsql-general
I have been testing different backup methods suggested and wonder if I have
all my files used to load the DB .. could that be considered a backup...
obviously need to have schema backup in case of problem, but that seems to
be easily re-created
Thoughts?
On Fri, Oct 18, 2024 at 2:30 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
>
>
> On 10/18/24 11:25 AM, Andy Hartman wrote:
> > Windows Server 2022
> >
> > I would like a backup process similar to what I'm used to using in the
> > mssql world if that's possible with Postgres... I will be
> > loading monthly archive data to Postgresql so that's why I probably only
> > need once a backup .. once loaded data is just viewed thru an app... no
> > updates..
> >
> > in mssql you create the .bak and easily restorable .... that's what I'm
> > looking for with Postgres
> >
>
> Then pg_dump for database backup:
>
> https://www.postgresql.org/docs/current/app-pgdump.html
>
> and pg_dumpall for entire cluster backup:
>
> https://www.postgresql.org/docs/current/app-pg-dumpall.html
>
> > thanks for replies..
> >
> >
> >
> > On Fri, Oct 18, 2024 at 1:00 PM Adrian Klaver <adrian.klaver@aklaver.com
> > <mailto:adrian.klaver@aklaver.com>> wrote:
> >
> > On 10/18/24 09:52, Andy Hartman wrote:
> >
> > Reply to list also
> > Ccing list.
> >
> > > Windows 22 and Postgres 16.4
> > >
> > Is that Windows Server 2022 or Windows 10/11 with the 22H2 update?
> >
> > You also need to provide a more detailed description of what you want
> > the backup to do?
> >
> > >
> > >
> > > On Fri, Oct 18, 2024 at 12:04 PM Adrian Klaver
> > > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> > <mailto:adrian.klaver@aklaver.com
> > <mailto:adrian.klaver@aklaver.com>>> wrote:
> > >
> > > On 10/18/24 05:39, Andy Hartman wrote:
> > > > I would like to use the closest thing to a mssql backup...
> > > >
> > >
> > > As in?
> > >
> > > Searching on 'mssql backup' returns a lot of choices. You
> > will need to
> > > be more specific on what you want to achieve. Also be
> > specific about
> > > what versions of OS and Postgres you are using.
> > >
> > > --
> > > Adrian Klaver
> > > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> > <mailto:adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com
> >>
> > >
> >
> > --
> > Adrian Klaver
> > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-23 15:50 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-23 15:50 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general
On 10/23/24 07:07, Andy Hartman wrote:
> I have been testing different backup methods suggested and wonder if I
> have all my files used to load the DB .. could that be considered a
> backup... obviously need to have schema backup in case of problem, but
> that seems to be easily re-created
>
> Thoughts?
Did you actually read the information at the links provided?
By default pg_dump and pg_dumpall will dump both the schema definitions
as well as the data.
Yes it is a backup of the database(s) at the point in time you initiate
the dump. If you want something different then you are probably looking
for one of the replication methods. You still have not answered:
" You also need to provide a more detailed description of what you want
the backup to do?"
so it is hard to say what method is best for your situation.
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-23 17:43 Andy Hartman <hartman60home@gmail.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 57+ messages in thread
From: Andy Hartman @ 2024-10-23 17:43 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@aklaver.com>; +Cc: pgsql-general
I'm using the DB as a History repository... I'm pulling info from a Mssql
db using a P/S script to a csv file then Import that to Postgres I only
keep 6 months live on the mssql db and roll everything else to Postgres
Arch DB.
After I load this latest month to Postgres I just need to backup, or
should I just retain my .csv files as a Backup... I have 2 tables that I
load to Hist and one table holds the images...
THanks .
On Wed, Oct 23, 2024 at 11:50 AM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
> On 10/23/24 07:07, Andy Hartman wrote:
> > I have been testing different backup methods suggested and wonder if I
> > have all my files used to load the DB .. could that be considered a
> > backup... obviously need to have schema backup in case of problem, but
> > that seems to be easily re-created
> >
> > Thoughts?
>
> Did you actually read the information at the links provided?
>
> By default pg_dump and pg_dumpall will dump both the schema definitions
> as well as the data.
>
> Yes it is a backup of the database(s) at the point in time you initiate
> the dump. If you want something different then you are probably looking
> for one of the replication methods. You still have not answered:
>
> " You also need to provide a more detailed description of what you want
> the backup to do?"
>
> so it is hard to say what method is best for your situation.
>
> >
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-23 19:47 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Andy Hartman <hartman60home@gmail.com>
0 siblings, 1 reply; 57+ messages in thread
From: Adrian Klaver @ 2024-10-23 19:47 UTC (permalink / raw)
To: Andy Hartman <hartman60home@gmail.com>; +Cc: pgsql-general
On 10/23/24 10:43, Andy Hartman wrote:
> I'm using the DB as a History repository... I'm pulling info from a
> Mssql db using a P/S script to a csv file then Import that to Postgres I
> only keep 6 months live on the mssql db and roll everything else to
> Postgres Arch DB.
>
> After I load this latest month to Postgres I just need to backup, or
> should I just retain my .csv files as a Backup... I have 2 tables that I
> load to Hist and one table holds the images...
Your choice, though the factors I would consider would be:
1) The process you use to load the CSV files into Postgres and whether
that is faster then loading the data from the dump file?
2) Loading from the CSV files directly would be month by month steps
versus loading from the dump file which would be cumulative to the last
backup.
Also, what format are the image files in and are they part of the CSV
files or separate?
>
> THanks .
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 57+ messages in thread
* Re: Backup
@ 2024-10-23 23:59 Andy Hartman <hartman60home@gmail.com>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 0 replies; 57+ messages in thread
From: Andy Hartman @ 2024-10-23 23:59 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@aklaver.com>; +Cc: pgsql-general
The images are part of the csv file...
On Wed, Oct 23, 2024 at 3:47 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
> On 10/23/24 10:43, Andy Hartman wrote:
> > I'm using the DB as a History repository... I'm pulling info from a
> > Mssql db using a P/S script to a csv file then Import that to Postgres I
> > only keep 6 months live on the mssql db and roll everything else to
> > Postgres Arch DB.
> >
> > After I load this latest month to Postgres I just need to backup, or
> > should I just retain my .csv files as a Backup... I have 2 tables that I
> > load to Hist and one table holds the images...
> Your choice, though the factors I would consider would be:
>
> 1) The process you use to load the CSV files into Postgres and whether
> that is faster then loading the data from the dump file?
>
> 2) Loading from the CSV files directly would be month by month steps
> versus loading from the dump file which would be cumulative to the last
> backup.
>
> Also, what format are the image files in and are they part of the CSV
> files or separate?
>
>
> >
> > THanks .
> >
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
>
^ permalink raw reply [nested|flat] 57+ messages in thread
end of thread, other threads:[~2024-10-23 23:59 UTC | newest]
Thread overview: 57+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-09-04 19:31 Backup? Bjørn T Johansen <btj@havleik.no>
2003-09-04 20:40 ` Doug McNaught <doug@mcnaught.org>
2003-09-04 22:23 ` Ron Johnson <ron.l.johnson@cox.net>
2003-09-05 15:17 ` Vivek Khera <khera@kcilink.com>
2003-09-04 20:47 ` Vivek Khera <khera@kcilink.com>
2006-06-19 12:17 BackUp Daniel <DFelix19@gmail.com>
2006-06-22 06:10 ` Re: BackUp Chris <dmagick@gmail.com>
2007-02-02 12:19 Backup ? Wilton Wonrath <wrwonrath@yahoo.com.br>
2007-02-02 13:21 ` Re: Backup ? Richard Huxton <dev@archonet.com>
2008-01-24 19:08 Backup Dominic Carlucci <carlucci@cae.com>
2008-01-25 00:34 ` Re: Backup Phillip Smith <phillip.smith@weatherbeeta.com.au>
2008-01-25 09:21 ` Re: Backup Simon Riggs <simon@2ndquadrant.com>
2008-01-31 12:21 ` Re: [GENERAL] Backup Chander Ganesan <chander@otg-nc.com>
2008-01-31 13:28 ` Re: [GENERAL] Backup Simon Riggs <simon@2ndquadrant.com>
2008-01-31 14:34 ` Re: [GENERAL] Backup Martijn van Oosterhout <kleptog@svana.org>
2008-01-31 14:43 ` Re: [GENERAL] Backup Magnus Hagander <magnus@hagander.net>
2008-01-31 15:02 ` Re: [GENERAL] Backup Chander Ganesan <chander@otg-nc.com>
2008-01-31 15:58 ` Re: [GENERAL] Backup Simon Riggs <simon@2ndquadrant.com>
2008-02-06 13:29 ` Re: [GENERAL] Backup Hannes Dorbath <light@theendofthetunnel.de>
2008-02-06 13:49 ` Re: [GENERAL] Backup Hannes Dorbath <light@theendofthetunnel.de>
2008-01-31 15:00 ` Re: [GENERAL] Backup Chander Ganesan <chander@otg-nc.com>
2008-01-31 15:09 ` Re: [GENERAL] Backup Alvaro Herrera <alvherre@commandprompt.com>
2008-01-31 15:48 ` Re: [GENERAL] Backup Simon Riggs <simon@2ndquadrant.com>
2008-01-25 00:47 ` Re: Backup Scott Marlowe <scott.marlowe@gmail.com>
2008-01-30 04:15 ` Re: Backup Vishal Arora <aroravishal22@hotmail.com>
2008-01-30 04:27 ` Re: Backup Guido Barosio <gbarosio@gmail.com>
2024-10-07 15:48 backup Andy Hartman <hartman60home@gmail.com>
2024-10-07 16:14 ` Re: backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-07 16:17 ` Re: backup Ron Johnson <ronljohnsonjr@gmail.com>
2024-10-08 03:24 ` Re: backup Muhammad Usman Khan <usman.k@bitnine.net>
2024-10-08 11:31 ` Re: backup Andy Hartman <hartman60home@gmail.com>
2024-10-16 19:37 Backup Andy Hartman <hartman60home@gmail.com>
2024-10-16 19:52 ` Re: Backup Tomas Vondra <tomas@vondra.me>
2024-10-16 20:00 ` Re: Backup Ron Johnson <ronljohnsonjr@gmail.com>
2024-10-16 20:32 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-16 19:55 ` Re: Backup Ron Johnson <ronljohnsonjr@gmail.com>
2024-10-16 19:59 ` Re: Backup Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
2024-10-16 20:02 ` Re: Backup Ron Johnson <ronljohnsonjr@gmail.com>
2024-10-16 20:16 ` Re: Backup Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
2024-10-16 21:48 ` Re: Backup Peter J. Holzer <hjp-pgsql@hjp.at>
2024-10-16 22:59 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-17 03:52 ` Re: Backup Muhammad Usman Khan <usman.k@bitnine.net>
2024-10-17 04:46 ` Re: Backup Asad Ali <asadalinagri@gmail.com>
2024-10-17 10:28 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-18 12:39 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-18 14:45 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-18 15:34 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-18 15:55 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-18 16:04 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-18 17:00 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-18 18:25 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-18 18:30 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-23 14:07 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-23 15:50 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-23 17:43 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
2024-10-23 19:47 ` Re: Backup Adrian Klaver <adrian.klaver@aklaver.com>
2024-10-23 23:59 ` Re: Backup Andy Hartman <hartman60home@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox