Re: [GENERAL] Backup strategy using 'wal_keep_segments'

Greetings, * Rhhh Lin (ruanline...@hotmail.com) wrote: > I would actually be an advocate for using a proper archive_command in order > to facilitate a proper (Per the documentation) PITR and backup strategy. Glad to hear it. > However, a colleague had suggested such a creative approach (Possibl

Re: [GENERAL] Backup strategy using 'wal_keep_segments'

On Tue, Oct 31, 2017 at 9:53 AM, Rhhh Lin wrote: > I would actually be an advocate for using a proper archive_command in order > to facilitate a proper (Per the documentation) PITR and backup strategy. You should avoid using your own fancy archive command. There are things that WAL-E for this pur

Re: [GENERAL] Backup strategy using 'wal_keep_segments'

To: Rhhh Lin Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Backup strategy using 'wal_keep_segments' Greetings, * Rhhh Lin (ruanline...@hotmail.com) wrote: > A colleague recently suggested that instead of implementing an > 'archive_command' to push archivable WALs to

Re: [GENERAL] Backup strategy using 'wal_keep_segments'

Greetings, * Rhhh Lin (ruanline...@hotmail.com) wrote: > A colleague recently suggested that instead of implementing an > 'archive_command' to push archivable WALs to a secondary location (for > further backup to tape for example), we could instead persist the WAL files > in their current locat

Re: [GENERAL] Backup strategy using 'wal_keep_segments'

Thanks very much for your reply Michael. I note that it looks like pgbarman employs pg_receivexlog; I will check it out. Regards, Ruan From: Michael Paquier Sent: 22 October 2017 22:17:01 To: Rhhh Lin Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL

Re: [GENERAL] Backup strategy using 'wal_keep_segments'

On Mon, Oct 23, 2017 at 5:57 AM, Rhhh Lin wrote: > Is this approach feasible? Assuming obviously, we have sufficient disk space > to facilitate 1000 WAL files etc. You expose yourself to race conditions with such methods if a checkpoint has the bad idea to recycle past segments that your logic is

[GENERAL] Backup strategy using 'wal_keep_segments'

Hi, Version 9.4... Per the PG docs, to facilitate continuous WAL archiving and PITR recovery... "To enable WAL archiving, set the wal_level configuration parameter to archive (or hot_standby), archive_mode to on, and specify the shell command to use in the archive_command configuration paramet

Re: [GENERAL] Backup "Best Practices"

On Mon, Nov 28, 2016 at 11:20 PM, Thomas Kellerer wrote: > Israel Brewster schrieb am 28.11.2016 um 23:50: > >> >>> pg_archivecleanup -n /mnt/server/archiverdir >>> 00010010.0020.backup >>> >> >> Ok, but where does that "00010010.0020.backup" >> come from?

Re: [GENERAL] Backup "Best Practices"

On Nov 29, 2016, at 8:12 AM, Israel Brewster wrote: > > On Nov 28, 2016, at 10:04 PM, Jeff Janes > wrote: >> >> On Mon, Nov 28, 2016 at 2:50 PM, Israel Brewster > > wrote: >> >>> - What is the "best" (or just a good) method of keeping

Re: [GENERAL] Backup "Best Practices"

On Nov 28, 2016, at 10:20 PM, Thomas Kellerer wrote: > > Israel Brewster schrieb am 28.11.2016 um 23:50: >>> >>> pg_archivecleanup -n /mnt/server/archiverdir >>> 00010010.0020.backup >> >> Ok, but where does that "00010010.0020.backup" >> come from? I me

Re: [GENERAL] Backup "Best Practices"

On Nov 28, 2016, at 10:04 PM, Jeff Janes wrote: > > On Mon, Nov 28, 2016 at 2:50 PM, Israel Brewster > wrote: > >> - What is the "best" (or just a good) method of keeping the WAL archives >> under control? Obviously when I do a new basebackup I can "cleanup" any o

Re: [GENERAL] Backup "Best Practices"

Israel Brewster schrieb am 28.11.2016 um 23:50: pg_archivecleanup -n /mnt/server/archiverdir 00010010.0020.backup Ok, but where does that "00010010.0020.backup" come from? I mean, I can tell it's a WAL segment file name (plus a backup label), but I don'

Re: [GENERAL] Backup "Best Practices"

On Mon, Nov 28, 2016 at 2:50 PM, Israel Brewster wrote: > > - What is the "best" (or just a good) method of keeping the WAL archives >> under control? Obviously when I do a new basebackup I can "cleanup" any old >> files that said backup doesn't need, >> > > You have said you might be interested

Re: [GENERAL] Backup "Best Practices"

On Nov 28, 2016, at 2:13 PM, John R Pierce wrote: > > On 11/28/2016 2:50 PM, Israel Brewster wrote: >>> >>> Why wouldn't the streaming replica salvage that? Are they expected to fail >>> together? Is the NFS share onto which you want to store your basebackup >>> and WAL also expected to fail

Re: [GENERAL] Backup "Best Practices"

On 11/28/2016 2:50 PM, Israel Brewster wrote: Why wouldn't the streaming replica salvage that? Are they expected to fail together? Is the NFS share onto which you want to store your basebackup and WAL also expected to fail together with them? That's why I specified *total* failure. If only

Re: [GENERAL] Backup "Best Practices"

On Nov 25, 2016, at 1:00 PM, Jeff Janes wrote: > > On Wed, Nov 23, 2016 at 10:16 AM, Israel Brewster > wrote: > I was wondering if someone could inform me about, or point me to an online > article about best practices for backing up a postgresql database cluster? A

Re: [GENERAL] Backup "Best Practices"

On Wed, Nov 23, 2016 at 10:16 AM, Israel Brewster wrote: > I was wondering if someone could inform me about, or point me to an online > article about best practices for backing up a postgresql database cluster? > At the moment, I have two servers running with streaming replication for > failover

Re: [GENERAL] Backup "Best Practices"

On Wed, Nov 23, 2016 at 1:16 PM, Israel Brewster wrote: > I was wondering if someone could inform me about, or point me to an online > article about best practices for backing up a postgresql database cluster? > At the moment, I have two servers running with streaming replication for > failover p

Re: [GENERAL] Backup "Best Practices"

Am 23. November 2016 20:31:21 MEZ, schrieb John R Pierce : >On 11/23/2016 11:20 AM, Israel Brewster wrote: >> How do I determine which those are? Just based on the timestamp if >the >> WAL file, such that I could do something like take the timestamp of >> the last basebackup and delete all WAL

Re: [GENERAL] Backup "Best Practices"

On 11/23/2016 02:50 PM, Israel Brewster wrote: > On Nov 23, 2016, at 10:31 AM, John R Pierce > there's a tool, barman, I've never used but its supposed to greatly >> simplify this whole process... >> >> http://www.pgbarman.org/ > > Definitely looks like something to try. Thanks! I'd recommend you

Re: [GENERAL] Backup "Best Practices"

On Nov 23, 2016, at 10:31 AM, John R Pierce wrote: > > On 11/23/2016 11:20 AM, Israel Brewster wrote: >> How do I determine which those are? Just based on the timestamp if the WAL >> file, such that I could do something like take the timestamp of the last >> basebackup and delete all WAL files

Re: [GENERAL] Backup "Best Practices"

On 11/23/2016 11:20 AM, Israel Brewster wrote: How do I determine which those are? Just based on the timestamp if the WAL file, such that I could do something like take the timestamp of the last basebackup and delete all WAL files older than that? Or is there a better way? there's a tool, bar

Re: [GENERAL] Backup "Best Practices"

---Israel BrewsterSystems Analyst IIRavn Alaska5245 Airport Industrial RdFairbanks, AK 99709(907) 450-7293---BEGIN:VCARD VERSION:3.0 N:Brewster;Israel;;; FN:Israel Brewster ORG:Frontier Flying Service;MIS TITLE

Re: [GENERAL] Backup "Best Practices"

On 11/23/2016 10:16 AM, Israel Brewster wrote: To mitigate these issues, I am thinking of supplementing the individual dumps with a full base backup and WAL archiving to a NFS share. This should enable (relatively) quick/easy recovery from backup, plus the ability to do PIT Recovery. I do hav

[GENERAL] Backup "Best Practices"

I was wondering if someone could inform me about, or point me to an online article about best practices for backing up a postgresql database cluster? At the moment, I have two servers running with streaming replication for failover purposes, and then I do nightly database dumps for recovery/backup

[GENERAL] Backup and Restore BDR databases

Hello, I'm using BDR with master-master replication. It works like a charm. I have a question about backups and restoring them. I use this script to backup my database: https://wiki.postgresql.org/wiki/Automated_Backup_on_Linux However I'm getting problems with a pg_restore: pg_restore -h l

Re: [GENERAL] backup and archive postgresql data older than 6 months

On 08/26/2015 03:46 AM, Kaushal Shriyan wrote: Hi, Are there scripts which takes backup of postgresql database and archive data older than 6 months and push it to a remote server using scp or rsync method and purge/clean the local data on the hard disk at the same time meaning at any given time

Re: [GENERAL] backup and archive postgresql data older than 6 months

On Wed, 26 Aug 2015 10:46:53 + Kaushal Shriyan wrote: > Hi, > > Are there scripts which takes backup of postgresql database and archive > data older than 6 months and push it to a remote server using scp or rsync > method and purge/clean the local data on the hard disk at the same time > mea

Re: [GENERAL] backup and archive postgresql data older than 6 months

On 15/08/26 19:46, Kaushal Shriyan wrote: > Hi, > > Are there scripts which takes backup of postgresql database and archive data > older than 6 months and push it to a remote server using scp or rsync method > and purge/clean the local data on the hard disk at the same time meaning at > any given

[GENERAL] backup and archive postgresql data older than 6 months

Hi, Are there scripts which takes backup of postgresql database and archive data older than 6 months and push it to a remote server using scp or rsync method and purge/clean the local data on the hard disk at the same time meaning at any given time we have only six months of postgresql data on the

Re: [GENERAL] Backup fatal issue

Hi all, I am continuing to investigate and I found a probable malfunctioning in linux semaphores: I foud postgres semaphores are deleted during barman backup process. To executing test I have created a new empty postgres cluster in a Debian Citrix virtual machine; this is output of ipcs -s command:

Re: [GENERAL] Backup fatal issue

Hi Tom, I am using only pg_ctl to start and stop my database. At the moment I do not use any script. Bye. Meph On 17 July 2015 at 16:32, Tom Lane wrote: > mephysto writes: > > I have some problems in a postgres cluster when I try to execute a > backup. > > ... > > FATAL: semctl(983046, 3, SE

Re: [GENERAL] Backup fatal issue

​Hi Melvin, I tried to execute pg_dump and after I tried to launch pg_start_backup and pg_stop_backup. In both cases, I did not receive any error, so I decided to investigate in BarMan. Thanks for your help. Bye. Meph​ On 17 July 2015 at 16:16, Melvin Davidson wrote: > If this is occurring wi

Re: [GENERAL] Backup fatal issue

mephysto writes: > I have some problems in a postgres cluster when I try to execute a backup. > ... > FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument > ... > LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No > such file or directory > LOG: semctl(786432, 0, I

Re: [GENERAL] Backup fatal issue

If this is occurring with Barman, try doing a manual backup. IE: pg_dump your_database > /tmp/somefile.sql If that works, then the problem is with Barman or it's configuration. On Fri, Jul 17, 2015 at 10:07 AM, Mephysto wrote: > Hi Melvin, > I am using Pstgres 9.4.4 in a virtualized Debian Linu

Re: [GENERAL] Backup fatal issue

Hi Melvin, I am using Pstgres 9.4.4 in a virtualized Debian Linux 8.0. I do not know backup command because is launched by BARMAN 1.4.1. I have tried many times to execute the backup. I have restarted and reinstalled Postgres and I also rebooted OS many times. Thanks for your help. Meph On 17 Ju

Re: [GENERAL] Backup fatal issue

I think we need just a little bit more information. What is the O/S? What is the PostgreSQL version? What is the backup command? Does this always occur with the same command? Did you need to restarrt PostgreSQL after this started? On Fri, Jul 17, 2015 at 3:29 AM, mephysto wrote: > Hi there, >

[GENERAL] Backup fatal issue

Hi there, I have some problems in a postgres cluster when I try to execute a backup. This is the log of entire operation: LOG: connection received: host=91.121.182.110 port=54957 LOG: connection authorized: user=postgres database=postgres LOG: statement: BEGIN LOG: statement: SET application_n

Re: [GENERAL] Backup Method

On 7/3/15 8:08 AM, howardn...@selestial.com wrote: > Thanks everyone. > > I am trying to move away from pg_dump as it is proving too slow. The > size of the database clusters are approaching 1TB (with multiple > individual compressed pg_dumps of around 100GB each, but the pace of > change is relati

Re: [GENERAL] Backup Method

On 07/03/2015 08:08 AM, howardn...@selestial.com wrote: I am trying to move away from pg_dump as it is proving too slow. Have you looked into barman? http://www.pgbarman.org Also, another potential approach is to setup replication and to do the backups from the slave. -- Sent via pgsql-ge

Re: [GENERAL] Backup Method

På fredag 03. juli 2015 kl. 11:59:49, skrev howardn...@selestial.com < howardn...@selestial.com >: Hi everyone, I am reaching the point with my database backups where the backups are taking too long, and starting to interfere with running of the system during th

Re: [GENERAL] Backup Method

On 03/07/2015 12:23, Bill Moran wrote: On Fri, 03 Jul 2015 13:16:02 +0200 Jan Lentfer wrote: Am 2015-07-03 13:00, schrieb howardn...@selestial.com: On 03/07/2015 11:39, Guillaume Lelarge wrote: In that case is there any recommendation for how often to make base backups in relation to the

Re: [GENERAL] Backup Method

On Fri, 03 Jul 2015 13:16:02 +0200 Jan Lentfer wrote: > Am 2015-07-03 13:00, schrieb howardn...@selestial.com: > > On 03/07/2015 11:39, Guillaume Lelarge wrote: > >> > >> > In that case is there any recommendation for how often to make > >> base backups in relation to the size of the cluster and

Re: [GENERAL] Backup Method

Am 2015-07-03 13:00, schrieb howardn...@selestial.com: On 03/07/2015 11:39, Guillaume Lelarge wrote: > In that case is there any recommendation for how often to make base backups in relation to the size of the cluster and the size of the WAL? > Nope, not really. That depends on a lot of thi

Re: [GENERAL] Backup Method

On 03/07/2015 11:39, Guillaume Lelarge wrote: > In that case is there any recommendation for how often to make base backups in relation to the size of the cluster and the size of the WAL? > Nope, not really. That depends on a lot of things. Our customers usually do one per day. -- Guilla

Re: [GENERAL] Backup Method

Le 3 juil. 2015 12:31 PM, "howardn...@selestial.com" < howardn...@selestial.com> a écrit : > > > > On 03/07/2015 11:15, Guillaume Lelarge wrote: >> >> >> pg_dumpall is not more efficient than pg_dump. As far as I can tell, you're looking for PITR backups. >> > > Thanks Guillame. > > In that case is

Re: [GENERAL] Backup Method

On 03/07/2015 11:15, Guillaume Lelarge wrote: pg_dumpall is not more efficient than pg_dump. As far as I can tell, you're looking for PITR backups. Thanks Guillame. In that case is there any recommendation for how often to make base backups in relation to the size of the cluster and the

Re: [GENERAL] Backup Method

Le 3 juil. 2015 12:03 PM, "howardn...@selestial.com" < howardn...@selestial.com> a écrit : > > Hi everyone, > > I am reaching the point with my database backups where the backups are taking too long, and starting to interfere with running of the system during the day. So I am looking for a bit of s

[GENERAL] Backup Method

Hi everyone, I am reaching the point with my database backups where the backups are taking too long, and starting to interfere with running of the system during the day. So I am looking for a bit of sage advice as to how to proceed. For a typical server, I have a single database cluster with

Re: [GENERAL] Backup WAL Replication Server

On Thu, Mar 20, 2014 at 5:48 AM, basti wrote: > at the moment we use a Postgres Server as Master and one as Hot-Standby. > The Database is around 50GB and will massive grow next time. > > Backup and Restore with pg_dump take several hours, is there a faster > way to do this? Where does pg_backup

Re: [GENERAL] Backup WAL Replication Server

On Thu, Mar 20, 2014 at 9:48 PM, basti wrote: > at the moment we use a Postgres Server as Master and one as Hot-Standby. > The Database is around 50GB and will massive grow next time. > > Backup and Restore with pg_dump take several hours, is there a faster > way to do this? Everything is here: ht

[GENERAL] Backup WAL Replication Server

Hello, at the moment we use a Postgres Server as Master and one as Hot-Standby. The Database is around 50GB and will massive grow next time. Backup and Restore with pg_dump take several hours, is there a faster way to do this? Regards, Basti -- Sent via pgsql-general mailing list (pgsql-genera

Re: [GENERAL] Backup Question

On Tue, Oct 22, 2013 at 1:10 PM, Shaun Thomas wrote: > > So you can grab the extra files, but you can't make it apply them, > > as you are telling it that it doesn't need to. > > Do I have to, though? Replaying transaction logs is baked into the crash > recovery system. If I interrupt it in the mi

Re: [GENERAL] Backup Question

Shaun Thomas wrote: >> Wrong. The database cannot check all data for consistency >> upon backup. For one, that would take way too long. > > Well, what I meant, was that it would stop the database if it couldn't > apply one of the transaction logs for whatever reason. It wasn't > "inconsistent en

Re: [GENERAL] Backup Question

> So you can grab the extra files, but you can't make it apply them, > as you are telling it that it doesn't need to. Do I have to, though? Replaying transaction logs is baked into the crash recovery system. If I interrupt it in the middle of a checkpoint, it should be able to revert to the prev

Re: [GENERAL] Backup Question

On Tue, Oct 22, 2013 at 6:47 AM, Shaun Thomas wrote: > Hey everyone, > > This should be pretty straight-forward, but figured I'd pass it by anyway. > > I have a revised backup process that's coming out inconsistent, and I'm > not entirely sure why. I call pg_start_backup(), tar.gz the contents > e

Re: [GENERAL] Backup Question

> Wrong. The database cannot check all data for consistency > upon backup. For one, that would take way too long. Well, what I meant, was that it would stop the database if it couldn't apply one of the transaction logs for whatever reason. It wasn't "inconsistent enough" for that. :) > If you

Re: [GENERAL] Backup Question

Shaun Thomas wrote: > I have a revised backup process that's coming out inconsistent, and I'm not > entirely sure why. I call > pg_start_backup(), tar.gz the contents elsewhere, then pg_stop_backup(). > Nothing crazy. Upon restore, > two of my tables report duplicate IDs upon executing my redact

[GENERAL] Backup Question

Hey everyone, This should be pretty straight-forward, but figured I'd pass it by anyway. I have a revised backup process that's coming out inconsistent, and I'm not entirely sure why. I call pg_start_backup(), tar.gz the contents elsewhere, then pg_stop_backup(). Nothing crazy. Upon restore, tw

[GENERAL] backup and restore functions

I have a Postgressql-9.2 database with postgis-2.0 in production service. Due, I think, to a bad postgis upgrade, there are both old and new functions present. I am planning to install Postgresql-9.3 and Postgis-2.01 and then copy the data over with pg_upgrade. My question is: Will this also cop

Re: [GENERAL] Backup advice

On Mon, 15 Apr 2013 19:54:15 -0700 Jeff Janes wrote: > On Tue, Apr 9, 2013 at 3:05 AM, Eduardo Morras > > > wrote: > > > On Mon, 8 Apr 2013 10:40:16 -0500 > > Shaun Thomas > 'stho...@optionshouse.com');>> wrote: > > > > > > > > Anyone else? > > > > > > > If his db has low inserts/updates/delet

[GENERAL] Backup advice

On Tue, Apr 9, 2013 at 3:05 AM, Eduardo Morras > wrote: > On Mon, 8 Apr 2013 10:40:16 -0500 > Shaun Thomas 'stho...@optionshouse.com');>> wrote: > > > > > Anyone else? > > > > If his db has low inserts/updates/deletes he can use diff between pg_dumps > (with default -Fp) before compressing. > M

Re: [GENERAL] Backup advice

Hi Johann, On Wed, 10 Apr 2013 09:58:05 +0200, Johann Spies wrote: I can specify how many versions of the files should be kept on Tivoli. Another option you can evaluate is the usage of backup catalogues, retention policies and archiving of Barman (www.pgbarman.org). We use it in some cont

Re: [GENERAL] Backup advice

Thanks everybody for your valuable comments. I can specify how many versions of the files should be kept on Tivoli. The database will regularly get new data and there is a continuous process of data cleaning. It is a database mainly for research purposes and a few researchers are using it. I wil

Re: [GENERAL] Backup advice

On Mon, 8 Apr 2013 10:40:16 -0500 Shaun Thomas wrote: > > Anyone else? > If his db has low inserts/updates/deletes he can use diff between pg_dumps (with default -Fp) before compressing. --- --- Eduardo Morras -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To mak

Re: [GENERAL] Backup advice

On Mon, Apr 8, 2013 at 6:14 AM, Johann Spies wrote: > I would appreciate some advice from the experts on this list about the > best backup strategy for my database. > > The setup: > > Size: might be about 200Gb > The server uses a Tivoli backup client with daily backup > At the moment There are p

Re: [GENERAL] Backup advice

On 04/08/2013 08:14 AM, Johann Spies wrote: Size: might be about 200Gb The server uses a Tivoli backup client with daily backup At the moment There are pg_dumps for each database on the server on a daily, weekly and monthly basis. All this gets backed up to the Tivoli server. Ok. So far, so g

Re: [GENERAL] Backup advice

2013/4/8 Johann Spies : > I would appreciate some advice from the experts on this list about the best > backup strategy for my database. (...) > > I have read about using pg_basebackup in an article from Shaun Thomas' > booklet on Packt Publishers (I will probably buy the booklet). Get the bookle

Re: [GENERAL] Backup advice

On 08/04/2013 16:14, Johann Spies wrote: I would appreciate some advice from the experts on this list about the best backup strategy for my database. The setup: Size: might be about 200Gb The server uses a Tivoli backup client with daily backup At the moment There are pg_dumps for each database

[GENERAL] Backup advice

I would appreciate some advice from the experts on this list about the best backup strategy for my database. The setup: Size: might be about 200Gb The server uses a Tivoli backup client with daily backup At the moment There are pg_dumps for each database on the server on a daily, weekly and month

Re: [GENERAL] .backup file documentation

On Mar 18, 2013, at 7:36 PM, Christophe Pettus wrote: > Are is the contents of the .backup file (generated by pg_stop_backup()) > documented anywhere? (Some of it is self-explanatory, of course). If not, > is there a quick summary of what START WAL LOCATION, STOP WAL LOCATION, and > CHECKPOI

[GENERAL] .backup file documentation

Are is the contents of the .backup file (generated by pg_stop_backup()) documented anywhere? (Some of it is self-explanatory, of course). If not, is there a quick summary of what START WAL LOCATION, STOP WAL LOCATION, and CHECKPOINT LOCATION are? -- -- Christophe Pettus x...@thebuild.com

Re: [GENERAL] Backup/Restore bytea data

On 14/01/13 01:13, sub3 wrote: Hi, I am having an issue upgrading a really old 8.2 db up to 9.2.2. One of the tables contains a bytea field. When I backup& restore using pgadmin from my 9.2.2 install, it doesn't convert this field correctly. Could this be due to your bytea_output setting? h

[GENERAL] Backup/Restore bytea data

Hi, I am having an issue upgrading a really old 8.2 db up to 9.2.2. One of the tables contains a bytea field. When I backup & restore using pgadmin from my 9.2.2 install, it doesn't convert this field correctly. The original 8.2 database was created like: CREATE DATABASE test... ENCODING = 'SQL

Re: [GENERAL] backup script

al-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Stefan Tzeggai Sent: Friday, May 11, 2012 4:37 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] backup script Hi Am 11.05.2012 21:38, schrieb Vo, Catherine CTR DTIC Z: > We are using Sun Solaris 64bits ve

Re: [GENERAL] backup script

On 05/11/2012 12:38 PM, Vo, Catherine CTR DTIC Z wrote: We are using Sun Solaris 64bits version 10. postgresql-9.1.3-S10.sparc-6 I downloaded the script from some of the website and try to test out but didn't work at all. Don't know how to create a backup user (I know the syntax but where shoul

Re: [GENERAL] backup script

;Donnell [mailto:r...@iol.ie] > Sent: Friday, May 11, 2012 12:35 PM > To: Vo, Catherine CTR DTIC Z > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] backup script > > On 11/05/2012 16:23, Vo, Catherine CTR DTIC Z wrote: >> GM, >> >> First where can I post

Re: [GENERAL] backup script

to: bvo@dtic.mil -Original Message- From: Raymond O'Donnell [mailto:r...@iol.ie] Sent: Friday, May 11, 2012 12:35 PM To: Vo, Catherine CTR DTIC Z Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] backup script On 11/05/2012 16:23, Vo, Catherine CTR DTIC Z wrote: > GM, &g

Re: [GENERAL] backup script

On 11/05/2012 16:23, Vo, Catherine CTR DTIC Z wrote: > GM, > > First where can I post my question on the forum? Couldn't find the > forum for discussion. Hi there, Not sure what forum you mean you're writing to the pgsql-general mailing list, so you're already in the right place. > Second,

[GENERAL] backup script

GM, First where can I post my question on the forum? Couldn't find the forum for discussion. Second, I'm new with postgres. Try to evaluate this new db software before the company can switch all oracle and mysql to postgres. I don't understand the concept how to create backup user, tablespace,

Re: [GENERAL] Backup database remotely

On 2012-02-15, Andre Lopes wrote: > Hi all, > > To do this backup remotely we need to open the 5434 port in the Firewall? Yes, you need a connection to the database, opening the firewall is the simplest way to get that. (other ways include VPN and ssh tunneling) >> pg_dump -h (or pg_dumpall)

Re: [GENERAL] Backup database remotely

Andre Lopes wrote: > Hi all, > > To do this backup remotely we need to open the 5434 port in the Firewall? If the database running on this port and if there are a firewall, so yes. Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect.

Re: [GENERAL] Backup database remotely

Hi all, To do this backup remotely we need to open the 5434 port in the Firewall? Best Regards, On Mon, Feb 6, 2012 at 5:28 PM, Andreas Kretschmer wrote: > Fanbin Meng wrote: > >> I installed the PostgreSql9.0 in windows 7 with "one click installer". >> How can i backup another PostgreSql ser

Re: [GENERAL] Backup database remotely

Fanbin Meng wrote: > I installed the PostgreSql9.0 in windows 7 with "one click installer". > How can i backup another PostgreSql server database remotely via an internet > connection . > I trid "add a connection to a server", but it did not work. Don't know waht you mean with 'add a connection

[GENERAL] Backup database remotely

I installed the PostgreSql9.0 in windows 7 with "one click installer". How can i backup another PostgreSql server database remotely via an internet connection . I trid "add a connection to a server", but it did not work. Does anyone can help me or give suggestions? Thanks Fanbin

Re: [GENERAL] Backup Database Question

On Thursday, October 06, 2011 7:49:38 am Carlos Mennens wrote: > So I'm looking to start regularly backing up my production database at > work. I'm tired of doing it manually every day before I go home. I use > the built in 'pg_dump' or 'pg_dumpall' utilities however I don't know > which is more be

Re: [GENERAL] Backup Database Question

what about pg_rman ? - On Fri, Oct 7, 2011 at 1:20 AM, Raymond O'Donnell wrote: > On 06/10/2011 20:18, Carlos Mennens wrote: > > O

Re: [GENERAL] Backup Database Question

On 06/10/2011 20:18, Carlos Mennens wrote: > On Thu, Oct 6, 2011 at 3:12 PM, John R Pierce wrote: >> /path/to/pg_dumpall | gzip > /path/to/pgbackup-$(date -I).sql.gz > > Thanks John. I've never written a script so do I just use 'Vim' to > open a new file and just paste the following line? > >

Re: [GENERAL] Backup Database Question

On Thu, Oct 6, 2011 at 1:18 PM, Carlos Mennens wrote: > On Thu, Oct 6, 2011 at 3:12 PM, John R Pierce wrote: >>   /path/to/pg_dumpall | gzip > /path/to/pgbackup-$(date -I).sql.gz > > Thanks John. I've never written a script so do I just use 'Vim' to > open a new file and just paste the following

Re: [GENERAL] Backup Database Question

On Thu, Oct 6, 2011 at 3:12 PM, John R Pierce wrote: >   /path/to/pg_dumpall | gzip > /path/to/pgbackup-$(date -I).sql.gz Thanks John. I've never written a script so do I just use 'Vim' to open a new file and just paste the following line? #!/bin/bash /usr/bin/pg_dumpall | gzip > /var/db_backup/

Re: [GENERAL] Backup Database Question

On 10/06/11 8:26 AM, Carlos Mennens wrote: Yes I agree but I didn't know enough about PostgreSQL to make that determination. Seems very logical however. Does anyone know of a PostgreSQL backup script floating around the Internet for Linux systems? I found a great one for MySQL but sadly that does

Re: [GENERAL] Backup Database Question

I have a little bash script that is called by cron to make a backup of the db, as well as being able to pull a copy of our production db to my local machine for development. It requires that you have a .pgpass file setup to connect to your database without entering a password. On Thu, Oct 6, 2011

Re: [GENERAL] Backup Database Question

On Thu, Oct 6, 2011 at 11:19 AM, Tom Lane wrote: > Use pg_dumpall.  The extra time to dump the user and database > definitions is unlikely to be noticeable, and if push comes to shove > you'll be glad you had them. Yes I agree but I didn't know enough about PostgreSQL to make that determination.

Re: [GENERAL] Backup Database Question

Carlos Mennens writes: > So I'm looking to start regularly backing up my production database at > work. I'm tired of doing it manually every day before I go home. I use > the built in 'pg_dump' or 'pg_dumpall' utilities however I don't know > which is more beneficial for a nightly backup. Perhaps

[GENERAL] Backup Database Question

So I'm looking to start regularly backing up my production database at work. I'm tired of doing it manually every day before I go home. I use the built in 'pg_dump' or 'pg_dumpall' utilities however I don't know which is more beneficial for a nightly backup. Perhaps I should be using the 'pg_dumpal

Re: [GENERAL] backup-strategies for large databases

I also guessed the same at initial stage of debugging. So i tried to export the tbl_voucher data to a file and it works fine. Then i googled and found some link, its explaines the reason is higher size of the database. But didnt get any proper solution in the internet. -- View this message in con

Re: [GENERAL] backup-strategies for large databases

Hello 2011/8/26 Niyas : > Hi All, > > I have some other issue related to taking backup of the database having > bigger size. I have been getting the > following errors > > anil@ubuntu107:~/Desktop$ pg_dump -Uadmin -h192.168.2.5 dbname > > filename.sql > >  pg_dump: Dumping the contents of table "t

Re: [GENERAL] backup-strategies for large databases

On 26 Srpen 2011, 12:46, Niyas wrote: > Actually database is not crashed. I can run my application perfectly. That does not mean one of the backends did not crash. Check the log. Tomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: h

Re: [GENERAL] backup-strategies for large databases

Actually database is not crashed. I can run my application perfectly. -- View this message in context: http://postgresql.1045698.n5.nabble.com/backup-strategies-for-large-databases-tp4697145p4737697.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-ge

Re: [GENERAL] backup-strategies for large databases

On 26 Srpen 2011, 11:48, Niyas wrote: > Hi All, > > I have some other issue related to taking backup of the database having > bigger size. I have been getting the > following errors > > anil@ubuntu107:~/Desktop$ pg_dump -Uadmin -h192.168.2.5 dbname > > filename.sql > > pg_dump: Dumping the content

  1   2   3   4   >