pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedPG_DUMP backup
9+ messages / 6 participants
[nested] [flat]
* PG_DUMP backup
@ 2010-02-12 09:58 Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 15:29 ` Re: PG_DUMP backup Josh Kupershmidt <schmiddy@gmail.com>
2010-02-12 19:31 ` Re: PG_DUMP backup Tomeh, Husam <HTomeh@facorelogic.com>
0 siblings, 2 replies; 9+ messages in thread
From: Renato Oliveira @ 2010-02-12 09:58 UTC (permalink / raw)
To: pgsql-admin
Dear all,
I have a server running 8.2.4 and has a database 170GB in size.
Currently I am backing it up using pg_dump and it takes around 28 hours, sadly.
I was asked to check and compare the newly created DUMP file to the live database and compare records.
I personally cannot see an easy or quick way of doing this, and even the point in doing so.
I am already restoring the full database to a separate server and no errors were reported.
How far can I trust pg_dump, can I trust a restore of the full DUMP to a separate server will be good enough?
The time it takes for me to:
1 - Backup it up
2 - Transfer the dump (12.7GB compressed) to the office across the internet
3 - Decompress the full dump locally which will be 105GB raw file
4 - Restore the full dump to a test server
It is easily a week to do all of that, when I have finished doing all of that if a problem has developed with my live server, what good that test will be? How relevant that will be? How helpful?
My question is:
1 - Is there a more efficient way of backing up such large database, using pg_dump or any other tool?
2 - Is there an easy way to compare the live database with the DUMP file just created?
3 - If I restore the database to a separate server, is there a point to do such a check, especially if it is going to take suck a long time to even start doing such a check?
Idea:
Pg_dump to split the file into smaller usable chuncks, which could be restored one at time, is that possible?
PS I know about PITR but I can't implement it yet as I am still figuring out certain things with the restore process.
I would really appreciate helps, please?
Thank you very much in advance
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PG_DUMP backup
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
@ 2010-02-12 15:29 ` Josh Kupershmidt <schmiddy@gmail.com>
2010-02-12 15:52 ` Re: PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-16 17:34 ` Re: PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
1 sibling, 2 replies; 9+ messages in thread
From: Josh Kupershmidt @ 2010-02-12 15:29 UTC (permalink / raw)
To: Renato Oliveira <renato.oliveira@grant.co.uk>; +Cc: pgsql-admin
On Feb 12, 2010, at 4:58 AM, Renato Oliveira wrote:
> Dear all,
>
> I have a server running 8.2.4 and has a database 170GB in size.
> Currently I am backing it up using pg_dump and it takes around 28 hours, sadly.
That's suspiciously slow for a pg_dump alone. I have a ~168 GB database which gets pg_dumped nightly, taking about 2.5 hours, all on 2+ year-old commodity hardware.
> I was asked to check and compare the newly created DUMP file to the live database and compare records.
>
If you really must run this comparison, maybe you can check out "pg_comparator" (I think you would restore first, then use pg_comparator to run the diffs). However, it sounds like your assignment really is more about making sure that your backup server is functional and ready to take over if the master dies. There are easier, and better, ways to establish this than doing a row-by-row comparison of your backup and live server
> I personally cannot see an easy or quick way of doing this, and even the point in doing so.
> I am already restoring the full database to a separate server and no errors were reported.
>
There's probably a much easier way of ensuring the validity of your backup server without running this diff, but that'll of course depend on your environment and your boss' wishes.
> My question is:
> 1 - Is there a more efficient way of backing up such large database, using pg_dump or any other tool?
Only other ways, other than PITR which you rule out, are documented here, but I doubt you'll like them:
http://developer.postgresql.org/pgdocs/postgres/backup-file.html
> 2 - Is there an easy way to compare the live database with the DUMP file just created?
Take another dump, and compare the two dumps? This borders on absurdity, of course.
> Idea:
> Pg_dump to split the file into smaller usable chuncks, which could be restored one at time, is that possible?
You can dump a table at a time, or a few at a time, using pg_dump --table=... I doubt this will speed the restore up, though. If you can upgrade to 8.4, or upgrade the backup server to 8.4, your pg_restore should be faster with parallel restores.
Also, I would look into tuning your backup server to make pg_restore as fast as possible. See e.g.
http://wiki.postgresql.org/wiki/Bulk_Loading_and_Restores
Josh
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PG_DUMP backup
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 15:29 ` Re: PG_DUMP backup Josh Kupershmidt <schmiddy@gmail.com>
@ 2010-02-12 15:52 ` Renato Oliveira <renato.oliveira@grant.co.uk>
1 sibling, 0 replies; 9+ messages in thread
From: Renato Oliveira @ 2010-02-12 15:52 UTC (permalink / raw)
To: Josh Kupershmidt <schmiddy@gmail.com>; +Cc: pgsql-admin
Josh,
That is great thank you very much
I really appreciate your reply
Thank you
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Josh Kupershmidt [mailto:schmiddy@gmail.com]
Sent: 12 February 2010 15:30
To: Renato Oliveira
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PG_DUMP backup
Importance: High
On Feb 12, 2010, at 4:58 AM, Renato Oliveira wrote:
> Dear all,
>
> I have a server running 8.2.4 and has a database 170GB in size.
> Currently I am backing it up using pg_dump and it takes around 28 hours, sadly.
That's suspiciously slow for a pg_dump alone. I have a ~168 GB database which gets pg_dumped nightly, taking about 2.5 hours, all on 2+ year-old commodity hardware.
> I was asked to check and compare the newly created DUMP file to the live database and compare records.
>
If you really must run this comparison, maybe you can check out "pg_comparator" (I think you would restore first, then use pg_comparator to run the diffs). However, it sounds like your assignment really is more about making sure that your backup server is functional and ready to take over if the master dies. There are easier, and better, ways to establish this than doing a row-by-row comparison of your backup and live server
> I personally cannot see an easy or quick way of doing this, and even the point in doing so.
> I am already restoring the full database to a separate server and no errors were reported.
>
There's probably a much easier way of ensuring the validity of your backup server without running this diff, but that'll of course depend on your environment and your boss' wishes.
> My question is:
> 1 - Is there a more efficient way of backing up such large database, using pg_dump or any other tool?
Only other ways, other than PITR which you rule out, are documented here, but I doubt you'll like them:
http://developer.postgresql.org/pgdocs/postgres/backup-file.html
> 2 - Is there an easy way to compare the live database with the DUMP file just created?
Take another dump, and compare the two dumps? This borders on absurdity, of course.
> Idea:
> Pg_dump to split the file into smaller usable chuncks, which could be restored one at time, is that possible?
You can dump a table at a time, or a few at a time, using pg_dump --table=... I doubt this will speed the restore up, though. If you can upgrade to 8.4, or upgrade the backup server to 8.4, your pg_restore should be faster with parallel restores.
Also, I would look into tuning your backup server to make pg_restore as fast as possible. See e.g.
http://wiki.postgresql.org/wiki/Bulk_Loading_and_Restores
Josh
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PG_DUMP backup
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 15:29 ` Re: PG_DUMP backup Josh Kupershmidt <schmiddy@gmail.com>
@ 2010-02-16 17:34 ` Renato Oliveira <renato.oliveira@grant.co.uk>
1 sibling, 0 replies; 9+ messages in thread
From: Renato Oliveira @ 2010-02-16 17:34 UTC (permalink / raw)
To: Josh Kupershmidt <schmiddy@gmail.com>; +Cc: pgsql-admin
Josh,
Thank you again for the links you sent to me, really appreciated.
I actually was thinking of that to backup the server, here is the idea, maybe one of you guys can tell me if it would work.
Backup idea, pick holes please?
Create a script which does at the beggning:
SELECT pg_start_backup('label');
Then tar -cf backup.tar /usr/local/pgsql/data
Restore the tar file to a secondary DB server
Rsync -avf /usr/local/pgsql/data to remote machine
SELECT pg_stop_backup();
I think rsync will sinc the files and as it can copy deltas it will keep the files in sync, will this work?
I must bring the database window to below 24 hours so I can backup daily.
The server hardware is old and we will not change it right now.
Do you guys think I have any hope to achieve this? ;-)
Thank you very much
I would welcome ideas and any help.
Really appreciated.
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Josh Kupershmidt [mailto:schmiddy@gmail.com]
Sent: 12 February 2010 15:30
To: Renato Oliveira
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PG_DUMP backup
Importance: High
On Feb 12, 2010, at 4:58 AM, Renato Oliveira wrote:
> Dear all,
>
> I have a server running 8.2.4 and has a database 170GB in size.
> Currently I am backing it up using pg_dump and it takes around 28 hours, sadly.
That's suspiciously slow for a pg_dump alone. I have a ~168 GB database which gets pg_dumped nightly, taking about 2.5 hours, all on 2+ year-old commodity hardware.
> I was asked to check and compare the newly created DUMP file to the live database and compare records.
>
If you really must run this comparison, maybe you can check out "pg_comparator" (I think you would restore first, then use pg_comparator to run the diffs). However, it sounds like your assignment really is more about making sure that your backup server is functional and ready to take over if the master dies. There are easier, and better, ways to establish this than doing a row-by-row comparison of your backup and live server
> I personally cannot see an easy or quick way of doing this, and even the point in doing so.
> I am already restoring the full database to a separate server and no errors were reported.
>
There's probably a much easier way of ensuring the validity of your backup server without running this diff, but that'll of course depend on your environment and your boss' wishes.
> My question is:
> 1 - Is there a more efficient way of backing up such large database, using pg_dump or any other tool?
Only other ways, other than PITR which you rule out, are documented here, but I doubt you'll like them:
http://developer.postgresql.org/pgdocs/postgres/backup-file.html
> 2 - Is there an easy way to compare the live database with the DUMP file just created?
Take another dump, and compare the two dumps? This borders on absurdity, of course.
> Idea:
> Pg_dump to split the file into smaller usable chuncks, which could be restored one at time, is that possible?
You can dump a table at a time, or a few at a time, using pg_dump --table=... I doubt this will speed the restore up, though. If you can upgrade to 8.4, or upgrade the backup server to 8.4, your pg_restore should be faster with parallel restores.
Also, I would look into tuning your backup server to make pg_restore as fast as possible. See e.g.
http://wiki.postgresql.org/wiki/Bulk_Loading_and_Restores
Josh
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PG_DUMP backup
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
@ 2010-02-12 19:31 ` Tomeh, Husam <HTomeh@facorelogic.com>
2010-02-16 08:54 ` Re: PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
1 sibling, 1 reply; 9+ messages in thread
From: Tomeh, Husam @ 2010-02-12 19:31 UTC (permalink / raw)
To: Renato Oliveira <renato.oliveira@grant.co.uk>; pgsql-admin
Backing up a 170GB in 28 hours definitely doesn't sound right and I
almost certain has nothing to do with pg_dump, but rather your hardware,
ie, server, disk, etc. with a 170GB, backup should be done in a couple
of hours in my opinion. Seems to be more like a system resource issue.
Regards,
Husam
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Renato Oliveira
Sent: Friday, February 12, 2010 1:59 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] PG_DUMP backup
Importance: High
Dear all,
I have a server running 8.2.4 and has a database 170GB in size.
Currently I am backing it up using pg_dump and it takes around 28 hours,
sadly.
I was asked to check and compare the newly created DUMP file to the live
database and compare records.
I personally cannot see an easy or quick way of doing this, and even the
point in doing so.
I am already restoring the full database to a separate server and no
errors were reported.
How far can I trust pg_dump, can I trust a restore of the full DUMP to a
separate server will be good enough?
The time it takes for me to:
1 - Backup it up
2 - Transfer the dump (12.7GB compressed) to the office across the
internet
3 - Decompress the full dump locally which will be 105GB raw file
4 - Restore the full dump to a test server
It is easily a week to do all of that, when I have finished doing all of
that if a problem has developed with my live server, what good that test
will be? How relevant that will be? How helpful?
My question is:
1 - Is there a more efficient way of backing up such large database,
using pg_dump or any other tool?
2 - Is there an easy way to compare the live database with the DUMP file
just created?
3 - If I restore the database to a separate server, is there a point to
do such a check, especially if it is going to take suck a long time to
even start doing such a check?
Idea:
Pg_dump to split the file into smaller usable chuncks, which could be
restored one at time, is that possible?
PS I know about PITR but I can't implement it yet as I am still figuring
out certain things with the restore process.
I would really appreciate helps, please?
Thank you very much in advance
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our
http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
******************************************************************************************
This message may contain confidential or proprietary information intended only for the use of the
addressee(s) named above or may contain information that is legally privileged. If you are
not the intended addressee, or the person responsible for delivering it to the intended addressee,
you are hereby notified that reading, disseminating, distributing or copying this message is strictly
prohibited. If you have received this message by mistake, please immediately notify us by
replying to the message and delete the original message and any copies immediately thereafter.
Thank you.
******************************************************************************************
FACLD
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PG_DUMP backup
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 19:31 ` Re: PG_DUMP backup Tomeh, Husam <HTomeh@facorelogic.com>
@ 2010-02-16 08:54 ` Renato Oliveira <renato.oliveira@grant.co.uk>
0 siblings, 0 replies; 9+ messages in thread
From: Renato Oliveira @ 2010-02-16 08:54 UTC (permalink / raw)
To: Tomeh, Husam <HTomeh@facorelogic.com>; pgsql-admin
Hi Husam,
I know the problem is not pg_dump. It is a combination of things.
The hardware is old and the configuration is terrible:
CPU AMD Opteron(tm) Processor 246
RAM 8GB
DISKS single volume 300GB with 70GB FREE
1GB SWAP
It might be there are some problems also with the database design and application, how it works.
What I am trying to do is to gather some ideas on how I can improve the backup time so we can at least backup daily.
Once we have improved certain things internally then I am sure we will upgrade this Server.
How you guys are backing up your servers?
Using pg_dump using pitr? Combination?
I have an idea of what hardware I should have to run a 176GB database, but what sort of configuration are you guys running?
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Tomeh, Husam [mailto:HTomeh@facorelogic.com]
Sent: 12 February 2010 19:31
To: Renato Oliveira; pgsql-admin@postgresql.org
Subject: RE: [ADMIN] PG_DUMP backup
Backing up a 170GB in 28 hours definitely doesn't sound right and I
almost certain has nothing to do with pg_dump, but rather your hardware,
ie, server, disk, etc. with a 170GB, backup should be done in a couple
of hours in my opinion. Seems to be more like a system resource issue.
Regards,
Husam
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Renato Oliveira
Sent: Friday, February 12, 2010 1:59 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] PG_DUMP backup
Importance: High
Dear all,
I have a server running 8.2.4 and has a database 170GB in size.
Currently I am backing it up using pg_dump and it takes around 28 hours,
sadly.
I was asked to check and compare the newly created DUMP file to the live
database and compare records.
I personally cannot see an easy or quick way of doing this, and even the
point in doing so.
I am already restoring the full database to a separate server and no
errors were reported.
How far can I trust pg_dump, can I trust a restore of the full DUMP to a
separate server will be good enough?
The time it takes for me to:
1 - Backup it up
2 - Transfer the dump (12.7GB compressed) to the office across the
internet
3 - Decompress the full dump locally which will be 105GB raw file
4 - Restore the full dump to a test server
It is easily a week to do all of that, when I have finished doing all of
that if a problem has developed with my live server, what good that test
will be? How relevant that will be? How helpful?
My question is:
1 - Is there a more efficient way of backing up such large database,
using pg_dump or any other tool?
2 - Is there an easy way to compare the live database with the DUMP file
just created?
3 - If I restore the database to a separate server, is there a point to
do such a check, especially if it is going to take suck a long time to
even start doing such a check?
Idea:
Pg_dump to split the file into smaller usable chuncks, which could be
restored one at time, is that possible?
PS I know about PITR but I can't implement it yet as I am still figuring
out certain things with the restore process.
I would really appreciate helps, please?
Thank you very much in advance
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our
http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
******************************************************************************************
This message may contain confidential or proprietary information intended only for the use of the
addressee(s) named above or may contain information that is legally privileged. If you are
not the intended addressee, or the person responsible for delivering it to the intended addressee,
you are hereby notified that reading, disseminating, distributing or copying this message is strictly
prohibited. If you have received this message by mistake, please immediately notify us by
replying to the message and delete the original message and any copies immediately thereafter.
Thank you.
******************************************************************************************
FACLD
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html
^ permalink raw reply [nested|flat] 9+ messages in thread
* Pg_dump backup
@ 2022-02-23 14:14 Daulat <daulat.dba@gmail.com>
2022-02-23 14:45 ` Re: Pg_dump backup Ron <ronljohnsonjr@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Daulat @ 2022-02-23 14:14 UTC (permalink / raw)
To: pgsql-admin <pgsql-admin@lists.postgresql.org>
H Team,
I need your advice.
How can we ensure the pg_dump backup is successful?
Thanks !
Daulat
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Pg_dump backup
2022-02-23 14:14 Pg_dump backup Daulat <daulat.dba@gmail.com>
@ 2022-02-23 14:45 ` Ron <ronljohnsonjr@gmail.com>
2022-02-23 15:00 ` Re: Pg_dump backup Holger Jakobs <holger@jakobs.com>
0 siblings, 1 reply; 9+ messages in thread
From: Ron @ 2022-02-23 14:45 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
On 2/23/22 8:14 AM, Daulat wrote:
> H Team,
>
> I need your advice.
> How can we ensure the pg_dump backup is successful?
Check the return code immediately after pg_dump completes:
pg_dump ....
echo $?
If it's 0, then pg_dump exited successfully.
Of course, it's always good to test the dump files by restoring them on
non-prod systems.
--
Angular momentum makes the world go 'round.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Pg_dump backup
2022-02-23 14:14 Pg_dump backup Daulat <daulat.dba@gmail.com>
2022-02-23 14:45 ` Re: Pg_dump backup Ron <ronljohnsonjr@gmail.com>
@ 2022-02-23 15:00 ` Holger Jakobs <holger@jakobs.com>
0 siblings, 0 replies; 9+ messages in thread
From: Holger Jakobs @ 2022-02-23 15:00 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
Am 23.02.22 um 15:45 schrieb Ron:
> On 2/23/22 8:14 AM, Daulat wrote:
>> H Team,
>>
>> I need your advice.
>> How can we ensure the pg_dump backup is successful?
>
> Check the return code immediately after pg_dump completes:
> pg_dump ....
> echo $?
>
> If it's 0, then pg_dump exited successfully.
>
> Of course, it's always good to test the dump files by restoring them
> on non-prod systems.
>
Correct. On top of this you can also look for these lines at the bottom
of the dump
--
-- PostgreSQL database dump complete
--
--
Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012
Attachments:
OpenPGP_signature (application/pgp-signature, 202B) download
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2022-02-23 15:00 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-02-12 09:58 PG_DUMP backup Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 15:29 ` Josh Kupershmidt <schmiddy@gmail.com>
2010-02-12 15:52 ` Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-16 17:34 ` Renato Oliveira <renato.oliveira@grant.co.uk>
2010-02-12 19:31 ` Tomeh, Husam <HTomeh@facorelogic.com>
2010-02-16 08:54 ` Renato Oliveira <renato.oliveira@grant.co.uk>
2022-02-23 14:14 Pg_dump backup Daulat <daulat.dba@gmail.com>
2022-02-23 14:45 ` Re: Pg_dump backup Ron <ronljohnsonjr@gmail.com>
2022-02-23 15:00 ` Re: Pg_dump backup Holger Jakobs <holger@jakobs.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