On Saturday 11 August 2007 02:28, Kenny Dail wrote:
Thank you for those suggestions, it's appreciated. Although I get the
same results with setting those values both on the server and on the
client. SCP starts full speed, but at 20% of the 200 MB file it starts
to stall. All ICMP traffic
On Thursday 09 August 2007 17:39, Alex Zbyslaw wrote:
Nikos Vassiliadis wrote:
Keep in mind that dump(8) uses UFS2 snapshots. I don't know
the current status, but in the past, snapshots were not working
that good.
This statement is far too general and IMHO does a disservice to those
who
Op vrijdag 10 augustus 2007, schreef u:
Hi,
This really looks like a broken PMTU discovery.
Is this still the case? After the firewall changes you did?
Things may be different now. But, if a router in the path
is filtering all ICMP traffic then the problem will remain.
Try this on both
Op vrijdag 10 augustus 2007, schreef Nikos Vassiliadis:
Hi,
Some more info:
But, if a router in the path
is filtering all ICMP traffic then the problem will remain.
No most probably not. I live a few 100m from the office, having the same type
of internet connection and the same provider.
On Thursday 09 August 2007 19:51, Bram Schoenmakers wrote:
Op donderdag 09 augustus 2007, schreef Alex Zbyslaw:
Hello,
Bram Schoenmakers wrote:
# /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh
[EMAIL PROTECTED] \
dd of=/backup/webserver/root.0.bz2
bzip2 is
Bram Schoenmakers wrote:
If you can write (and compress if short of disk space) the dump
locally and
try an scp to your remote host as Nikos is suggesting, that will narrow
down the problem a bit. Any other large file will do: doesn't have to be a
dump.
As I wrote in my initial mail:
Thank you for those suggestions, it's appreciated. Although I get the same
results with setting those values both on the server and on the client. SCP
starts full speed, but at 20% of the 200 MB file it starts to stall. All ICMP
traffic was open on both firewalls at that time.
I had
On Thursday 09 August 2007 11:25, Bram Schoenmakers wrote:
Dear list,
There is a problem with performing a dump from our webserver at the data
centre to a backup machine at the office. Everytime we try to perform a
dump, the SSH tunnel dies:
# /sbin/dump -0uan -L -h 0 -f - / |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bram Schoenmakers wrote:
Dear list,
There is a problem with performing a dump from our webserver at the data
centre to a backup machine at the office. Everytime we try to perform a dump,
the SSH tunnel dies:
[snip]
* The client (where the
On Thu, Aug 09, 2007 at 10:25:41AM +0200, Bram Schoenmakers wrote:
Dear list,
There is a problem with performing a dump from our webserver at the data
centre to a backup machine at the office. Everytime we try to perform a dump,
the SSH tunnel dies:
# /sbin/dump -0uan -L -h 0 -f - / |
Op donderdag 09 augustus 2007, schreef u:
Try using a much lower MTU, something like 1400 or perhaps lower,
just for testing. You should configure this, on both client and server.
I'm not familiar with ipf to give the exact rule, but I would allow
ALL ICMP traffic, at least for testing
On Thursday 09 August 2007 16:43, Bram Schoenmakers wrote:
Op donderdag 09 augustus 2007, schreef u:
Try using a much lower MTU, something like 1400 or perhaps lower,
just for testing. You should configure this, on both client and
server.
I'm not familiar with ipf to give the exact
Nikos Vassiliadis wrote:
Keep in mind that dump(8) uses UFS2 snapshots. I don't know
the current status, but in the past, snapshots were not working
that good.
This statement is far too general and IMHO does a disservice to those
who worked on snapshots.
There were (and maybe even are, but
Op donderdag 09 augustus 2007, schreef Alex Zbyslaw:
Hello,
Bram Schoenmakers wrote:
# /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh
[EMAIL PROTECTED] \
dd of=/backup/webserver/root.0.bz2
bzip2 is darned slow and not always much better than gzip -9. It might
be
14 matches
Mail list logo
