I personally think that using ssh compression is the better method. I say
this because running rsync through ssh encrypts the data and compresses
it(optionally). Unless you plan to run rsync in the clear then the built in
compression isnt needed.
On Sat, Aug 29, 2009 at 11:36 PM, Jeffrey J. Kosowsky <backu...@kosowsky.org
> wrote:
> Les Mikesell wrote at about 07:37:07 -0500 on Tuesday, August 25, 2009:
> > Nigel Kendrick wrote:
> > > Hi,
> > >
> > > This may also be applicable to MySQL etc..
> > >
> > > I have an MS-SQL database that dumps out a backup that's around 700MB
> in
> > > size. BackupPC brought this over to its server via ADSL/VPN/Rsyncd
> > > (422mins!) and when I did another data dump about 4 hours later,
> around
> > > 16Mb of changes to the file were transferred very quickly. However,
> > > every single backup since then has gone back to 422 minutes. I could
> > > imagine that the database and dump will change over time, but it seems
> > > strange that the entire file needs copying every time - as if its
> > > structure is always 100% different from the previous.
> > >
> > > I wondered if I was missing anything obvious (being a BackupPC noob)
> > > like file time stamping causing a complete file transfer every day, or
> > > are database dumps likely to be completely different every time?
> > >
> > > I will keep some copies of the dumps and do some comparisons but in
> the
> > > meantime any tips, thoughts etc.?
> >
> > I don't know anything about the contents of the file, but are these full
> or
> > incremental runs for backuppc? Assuming this is rsync or rsyncd, note
> that
> > incrementals always compare against the last full unless you have
> configured
> > multiple incremental levels, so they tend to transfer more each time.
> Or there
> > may just be enough difference that it can't find the matching parts.
> >
> > If you are running rsync with ssh (probably not if this is windows), you
> might
> > save some time by adding the -C option for ssh compression. If transfer
> time is
> > important, it might be worth setting up a scheduled rsync command to
> copy to
> > something on the network local to the backuppc server so you could use
> the -z
> > option (which backuppc doesn't support), then have backuppc pick up that
> copy to
> > keep the history. Or, if rsync isn't finding matching parts anyway
> perhaps you
> > could compress the file before the transfer.
>
> Just out of curiosity, are there any plans to have rsync within
> Backuppc recognize the -z (compression) flag?
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
