Without using checksum, how backuppc does the pool match?
AFAIK it will use the checksum as filename but if checksum is not sent
during the transfer......
Anyway, I've seen that checksum is used only on fulls. Currently I've set a
full every 60 days, because incrementals done after a successful full are
rocket fast
Would be better, for me, to totally remove the checksum option even from
full, staying with the default rsync behavior but I don't know if this
makes a bad use of backuppc pool
Il 23 set 2017 4:33 AM, "Adam Goryachev" <
mailingli...@websitemanagers.com.au> ha scritto:
> 2017-09-22 17:24 GMT+02:00 Gandalf Corvotempesta
>> <gandalf.corvotempe...@gmail.com>:
>>
>>> 2017-09-22 17:20 GMT+02:00 Les Mikesell <lesmikes...@gmail.com>:
>>>
>>>> How does your overall CPU and RAM use look while this is happening?
>>>> Remember, your situation is unusual in that you are competing with the
>>>> ZFS compression activity.
>>>>
>>> CPU almost idle, RAM used at 70%, due to ZFS ARC cache (50% of ram)
>>> No swap.
>>>
>>
> On 23/9/17 02:50, Gandalf Corvotempesta wrote:
>
>> Just removed "--checksum" from the BackupPC arguments.
>> Now is........... FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAST
>>
>> What i've backupped in about 40hours, now took 60 minutes.
>>
>> YES: 40 hours => 60 minutes.
>>
>> Is --checksum really needed ? (checksum is also missing from rsnapshot
>> arguments, that's why rsnapshot is rocket fast)
>>
> I can't be sure for BPC4, but maybe you need more than one full backup to
> get the checkum information available to BPC. I think on v3 you needed two
> full backups before this would happen.
> The other point to consider, is that this shows you *DID* have a
> performance issue, but you didn't seem to find it. checksum will increase
> the read load and CPU load on at least the client (and possibly BPC server
> depending on where it gets the checksum info from). So you should have seen
> that you were being limited by disk IO or CPU on either BPC server, or the
> client. I'm not sure of the memory requirement for the checksum option, but
> this too might have been an issue, especially if BPC tried to uncompress
> the file into memory. Also, all of this would trash your disk read cache on
> both systems, further increasing demands on the disks.
>
> Whether you need to use --checksum or not, will depend on if you are happy
> to potentially skip backing up some files without knowing about it until
> you need to do a restore. Of course, this is a little contrived, as it
> still requires:
> a) size doesn't change
> b) timestamp doesn't change
> c) content *does* change
> That is not a normal process, but it is the corner case that always ends
> up being the most important file ;)
>
>
>
> Regards,
> Adam
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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/
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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/
