Hi,
Arnold Krille wrote on 2013-02-23 17:22:50 +0100 [Re: [BackupPC-users] speed
Mb/sec]:
> On Sat, 23 Feb 2013 07:52:58 -0800 zdravko
> <backuppc-forum AT backupcentral DOT com> wrote:
> > I'm still checking things with BackupPC. Yesterday I switched to tar
> > instead of rsync and the result was awesome: 9min for incr. backup.
yes, tar incrementals may miss files. That speeds things up. If that is your
primary concern, use tar, or switch off backups altogether (that's even
faster).
> Before you get your hopes to high: there is a difference in how rsync
> and tar work.
> - rsync checks the whole file-tree and only transfers files that have
> changed in attributes and (on incremental) content. So it puts a bit
> more strain on server and client but transfers less files.
> - tar transfers everything where the attributes have changed,
> regardless whether the contents have changed or not. Less load on
> server and client but more data to transfer.
That is not quite exact. rsync compares the file trees on server and
client. tar only has a time stamp to go by (for incrementals, that is). tar
will miss renamed files or files created with time stamps in the past, where
rsync will catch the fact, that the new file is not on the server yet. rsync
will transfer *checksums* for all files on *full* backups.
Also, rsync will catch file *deletions* even on incremental backups. tar, with
only a time stamp to go on, cannot. Imagine you really want to restore a
directory (tree) in the state as it was, say, last tuesday. It happens that
you spent hours on monday deleting a lot of files you no longer needed. Do you
want to do that again after restoring? It's kind of pointless having backups
that don't accurately reflect the state your file system was in at the time of
backup, unless you have a *very good reason* for such a tradeoff (i.e. the
backup would otherwise not be feasible at all).
Of course, you need to decide what your priorities are. But I'd seriously
recommend switching to tar *as a last resort*, when you've actually determined
that you even *have* a problem (and not just some numbers that sound like you
might), exactly *where* the problem lies, and that switching to tar will fix
it.
So far, I've seen no evidence you have a problem, apart from the one you
created by switching to tar.
> The transfer-rate shown in backuppc tells you how many data was
> transfered in the backup-time. So the higher value for tar doesn't
> necessarily mean that your backup transfered faster. It means your new
> method of choice had more data to transfer and did so in the same
> amount of time.
Meaning it put more strain on your network. Determine where your bottleneck is
before trying to fix it.
Regards,
Holger
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
