Обсуждение: Slow backups over VPN

I have a tiny database that I need to take frequent backups of.  The database is on a test server in our office.  When I’m at the office, backups take only a few seconds.  But when I am working from home, connecting to the office through a SonicWall VPN, backups take a few minutes.  Other data transfer operations, like file copies, are reasonably fast.  I’ve seen this behavior for databases using PostgreSQL8.4, 9.0 and 9.3.  Can you suggest any way that I might get backups to be reasonably fast?

Depends on the values of "tiny", "reasonably fast", the type of dump you are doing, etc. It's not surprising that your (gigabit?) office network performs better than a VPN connection from home.

I'd try dumping to a file (your few-second dump) and look at the file-size compared to your reasonably-fast transferring files to see if it's simply a data-size issue which I suspect though it is, I suppose, possible that there is a latency or other issue.

If you are doing a plain pg_dump the output is uncompressed text. You could use one of the compressed formats or do a dump->compress->transfer.

N.B.: If you use a compressed format the compression happens in the pg_dump client, *not* in the server. So using a compressed format will not help if your dump client is at home and the server is at the other end of the VPN. You must compress the data at the office side of the connection.

Cheers,
Steve

 Can you suggest any way that I might get backups to be reasonably fast?

Probably not enough detail here.   You might describe the backup design so we can pick our lure.

Rob Richardson <RDRichardson@rad-con.com> writes:
> I have a tiny database that I need to take frequent backups of.  The database is on a test server in our office.
WhenI'm at the office, backups take only a few seconds.  But when I am working from home, connecting to the office
througha SonicWall VPN, backups take a few minutes.  Other data transfer operations, like file copies, are reasonably
fast. I've seen this behavior for databases using PostgreSQL8.4, 9.0 and 9.3.  Can you suggest any way that I might get
backupsto be reasonably fast? 

Does your "tiny" database contain lots of small objects (functions,
perhaps)?

I'm just guessing here, but I wonder if you aren't getting killed by
round-trip latency.  pg_dump issues quite a lot of per-object queries,
so if there are lots of objects, high latency would pose a problem even
if the one-way throughput is reasonably fast.  It would be interesting
to find out the round trip time through your VPN as measured by, say,
ping.

If this theory is correct, there's probably no easy fix :-(.

            regards, tom lane

On 04/29/2014 03:14 PM, Tom Lane wrote:
> Rob Richardson <RDRichardson@rad-con.com> writes:
>> I have a tiny database that I need to take frequent backups of.  The database is on a test server in our office.
WhenI'm at the office, backups take only a few seconds.  But when I am working from home, connecting to the office
througha SonicWall VPN, backups take a few minutes.  Other data transfer operations, like file copies, are reasonably
fast. I've seen this behavior for databases using PostgreSQL8.4, 9.0 and 9.3.  Can you suggest any way that I might get
backupsto be reasonably fast? 
> Does your "tiny" database contain lots of small objects (functions,
> perhaps)?
>
> I'm just guessing here, but I wonder if you aren't getting killed by
> round-trip latency.  pg_dump issues quite a lot of per-object queries,
> so if there are lots of objects, high latency would pose a problem even
> if the one-way throughput is reasonably fast.  It would be interesting
> to find out the round trip time through your VPN as measured by, say,
> ping.
>
> If this theory is correct, there's probably no easy fix :-(.
>
>             regards, tom lane
>
>

It seems like pushing the latency and compression issues into the office
LAN should work well. For instance:

ssh user@machine_in_office "pg_dump -Fc [...standard options...] |
buffer" > my_local_file

The use of "buffer" may not even be necessary or beneficial but we don't
have enough detail to know. This is just one way - plenty of options
exist for achieving the same goal.

Cheers,
Steve