Andrus wrote:
You seem dead set on making your life harder than it needs to be. If you
really don't want to have the ssh port open then set the backup to run
from a cron-job on the main server and have it scp the result over to the
backup server. That way only the backup server needs ssh open.
nesday, November 29, 2006 2:43:56 PM
Subject: Re: [GENERAL] How to implement backup protocol
>> Not sure but using a binary cursor might improve things.
>
> Why not use COPY protocol?
I did full text search in Postgres 8.1 help file for "COPY protocol" but
havent found
>> Not sure but using a binary cursor might improve things.
>
> Why not use COPY protocol?
I did full text search in Postgres 8.1 help file for "COPY protocol" but
havent found any matches.
Which is COPY protocol and how to use it ?
Andrus.
---(end of broadcast)-
> You seem dead set on making your life harder than it needs to be. If you
> really don't want to have the ssh port open then set the backup to run
> from a cron-job on the main server and have it scp the result over to the
> backup server. That way only the backup server needs ssh open.
By bac
On þri, 2006-11-28 at 19:23 +0200, Andrus wrote:
> Richard,
>
> I really do'nt want to open separate port for backup only.
> Pelase, can you recomment a solution which uses port 5432 owned by Postgres
I do not want to advice you to do things that might be
counter your company's security policies
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> Not sure but using a binary cursor might improve things.
Why not use COPY protocol?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
Andrus wrote:
Richard,
Use scp. Open port 22 and allow only connections from the backup machine
with a specified user (e.g. "pgbackup").
Alternatively, you might try dumping in a text-format and using rsync to
transfer changes.
I really do'nt want to open separate port for backup only.
Pel
On Tue, Nov 28, 2006 at 07:34:56PM +0200, Andrus wrote:
> This id good idea but it forces to use Postgres protocol for downloading.
Why, of course.
> This protocol has some timeouts which are too small for large file download.
For "sane" values of "large" I doubt this is true. A field
in PG can s
On Tue, Nov 28, 2006 at 07:23:44PM +0200, Andrus wrote:
> Pelase, can you recomment a solution which uses port 5432 owned by Postgres
If you think you know your usage pattern:
Have cron stop PostgreSQL at, say, 2am.
Have cron start ssh on port 5432 at 2:05am if PG is down.
Have cron shutdown s
On Tue, 2006-11-28 at 19:34 +0200, Andrus wrote:
> > You could use an *un*trusted procedural language to create a
> > function to binary-read the backup from disk and return it
> > as a bytea field. Not sure how efficient that is, though.
> >
> > You could then simply do
> >
> > select get_backup()
I don't see where doing the backup directly to another computer increases
your safety margin, it may even lower it due to the increased potential for
network issues messing up the backup cycle. Do it locally then SCP the
completed (and compressed) file to another computer, which is what I do.
(In
Richard,
> Use scp. Open port 22 and allow only connections from the backup machine
> with a specified user (e.g. "pgbackup").
>
> Alternatively, you might try dumping in a text-format and using rsync to
> transfer changes.
I really do'nt want to open separate port for backup only.
Pelase, can
> You could use an *un*trusted procedural language to create a
> function to binary-read the backup from disk and return it
> as a bytea field. Not sure how efficient that is, though.
>
> You could then simply do
>
> select get_backup();
>
> If you allow for parameters you could make it return cert
Andrus wrote:
So I think that 4.5 hours which requires to create backup is because pg_dump
download the whole database (1 GB) in uncompressed format over slow
internet connection.
Compression level does not affect to this almost at all.
Might well be latency issues too.
I think I can create
On Tue, Nov 28, 2006 at 06:01:43PM +0200, Andrus wrote:
> 5. Server has *only* 5432 port open.
>
> pg_read_file() can read only text files and is restricted only to
> superusers.
>
> How to add a function pg_read_backup() to Postgres which creates and
> returns backup file with download speed
> The weekly backup of the larger of the two databases produces a file that
> is about 20GB and takes about an hour and 15 minutes. I then compress it
> down to about 4 GB, which takes another hour. However, because that's a
> separate task, it doesn't impact the database server as much. (I su
16 matches
Mail list logo
