Rich Rauenzahn wrote:
dan wrote:
no, incrementals are more efficient on bandwidth. they do a less
strenuous test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress the rsync
traffic either with rsync -z
Have you tried rsync -z? Last I
On Thu, Feb 21, 2008 at 11:43 AM, Nick Webb [EMAIL PROTECTED] wrote:
Rich Rauenzahn wrote:
dan wrote:
no, incrementals are more efficient on bandwidth. they do a less
strenuous test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress
Nick Webb wrote:
Rich Rauenzahn wrote:
dan wrote:
no, incrementals are more efficient on bandwidth. they do a less
strenuous test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress the rsync
traffic either with rsync -z
Have you tried rsync
David Rees wrote:
On Thu, Feb 21, 2008 at 11:43 AM, Nick Webb [EMAIL PROTECTED] wrote:
Rich Rauenzahn wrote:
As Rich said, BackupPC's rsync modules don't support compression. SSH
compression should work fine, though.
-Dave
Yeah, but ssh compression isn't working for me either. Here is
Carl Wilhelm Soderstrom wrote:
On 11/28 09:39 , Tim Hall wrote:
Are there any known backuppc tweaks/settings that
are proven to increase transfer performance over
wan links? Specifically with using rsyncd or rsync
as the transfer method.
. . . .
If you're running =v3 the following
If you're running =v3 the following option will make all the incrementals
sync against the previous incremental, instead of the last full. This keeps
them from growing quite as quickly. (It's the behavior you expect from
rsync).
$Conf{IncrLevels} = [1, 2, 3, 4, 5, 6];
I was under
On 02/19 05:53 , Raman Gupta wrote:
Carl Wilhelm Soderstrom wrote:
If you're running =v3 the following option will make all the incrementals
sync against the previous incremental, instead of the last full. This
keeps
them from growing quite as quickly. (It's the behavior you expect from
i looked at my archive history hear and i have a number of hosts than do
incrementals take like 6 minutes and fulls like 46 minutes
On Feb 19, 2008 4:07 PM, Carl Wilhelm Soderstrom [EMAIL PROTECTED]
wrote:
On 02/19 05:53 , Raman Gupta wrote:
Carl Wilhelm Soderstrom wrote:
If you're
no, incrementals are more efficient on bandwidth. they do a less strenuous
test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress the rsync
traffic either with rsync -z or if you are using ssh then with ssh's
compression. if you REALLY wanted to go
dan wrote:
no, incrementals are more efficient on bandwidth. they do a less
strenuous test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress the rsync
traffic either with rsync -z
Have you tried rsync -z? Last I heard, BackupPC's rsync
Rich Rauenzahn wrote:
dan wrote:
no, incrementals are more efficient on bandwidth. they do a less
strenuous test to determine if a file has changed.
at the expense of CPU power on both sides, you can compress the rsync
traffic either with rsync -z
Have you tried rsync -z? Last I
On 11/28 09:39 , Tim Hall wrote:
Are there any known backuppc tweaks/settings that
are proven to increase transfer performance over
wan links? Specifically with using rsyncd or rsync
as the transfer method.
the -C option to compress your SSH data is highly recommended. Also, going
with '-c
Hi,
new to backuppc, I want to use to send my backups
across the Internet (DSL) to an offsite server.
Are there any known backuppc tweaks/settings that
are proven to increase transfer performance over
wan links? Specifically with using rsyncd or rsync
as the transfer method.
For example a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Hall wrote:
Hi,
new to backuppc, I want to use to send my backups
across the Internet (DSL) to an offsite server.
Are there any known backuppc tweaks/settings that
are proven to increase transfer performance over
wan links? Specifically
14 matches
Mail list logo
