Here is how I think an algorithm could work, which requires no
changes on the remote side, so it should work with the plain rsync
protocol, but likely will require some changes to rsyncp.
Let:
B be the BackupPC_dump process
P be the peer (PC to be backed up)
R b
Craig Barratt wrote at about 18:45:05 -0700 on Sunday, August 29, 2010:
> Although I probably won't support it initially in 4.0, my plan would be
> to use the --checksum option to pre-match potential files in the pool
> if there isn't an existing file with the same path (ie: for new or
> rename
Jeffrey writes:
> True - I haven't seen any mention in the documentation of any 'flag'
> that would send checksums.
There is an rsync option --checksum that will compute and send a
full-file MD5 digest from the client for every file as part of the
initial file list. It is there as an alternative
also sprach Les Mikesell [2010.08.29.1814 +0200]:
> I haven't followed the code, but I think the idea is that if the file - or
> maybe
> the difference from the existing guessed match - fits in memory it doesn't
> need
> to write a tmp file before writing to the pool. I'm not sure if the rsyn
On 8/29/10 10:16 AM, martin f krafft wrote:
>
> What I think BackupPC is doing right now is:
>
> 1. It starts receiving a file
>
> 2. After a certain time, it has enough information to take a guess
> at the corresponding pool file, and opens it.
>
> 3. What seems to happen now is weird: the Fil
[Replying to multiple messages]
also sprach Jeffrey J. Kosowsky [2010.08.29.0358 +0200]:
> You are ignoring pool collisions which are very real and not
> altogether infrequent. For example a constant length log or database
> file could easily have the same 1st and 8th 128k block but still be
> di
Les Mikesell wrote at about 18:02:12 -0500 on Saturday, August 28, 2010:
> On 8/28/10 3:22 PM, martin f krafft wrote:
> > also sprach Les Mikesell [2010.08.28.2151 +0200]:
> > Don't you think BackupPC could be optimised *iff* rsyncp could ask
> > the peer mid-transfer to calculate the whole fi
martin f krafft wrote at about 19:44:53 +0200 on Saturday, August 28, 2010:
>
> I think that one of two things should happen instead:
>
> 1. If the dump process has access to the following information: (a)
>checksum of the 1st and last/8th 128k block of the file, (b) the
>size of th
On 8/28/10 3:22 PM, martin f krafft wrote:
> also sprach Les Mikesell [2010.08.28.2151 +0200]:
>> If it is one or a few files or constrained to a directory that you know you
>> already have backed up locally, why not just exclude it on the remote
>> machines?
>
> It happens regularly.
But if it
also sprach Les Mikesell [2010.08.28.2151 +0200]:
> If it is one or a few files or constrained to a directory that you know you
> already have backed up locally, why not just exclude it on the remote
> machines?
It happens regularly.
Don't you think BackupPC could be optimised *iff* rsyncp cou
On 8/28/10 1:41 PM, martin f krafft wrote:
> also sprach Les Mikesell [2010.08.28.2021 +0200]:
>> Keep in mind that what you are wanting to happen only matters in the unusual
>> case that an exact copy exists in the pool but not in the previous backup of
>> this machine.
>
> True; but that is biti
also sprach Les Mikesell [2010.08.28.2021 +0200]:
> Keep in mind that what you are wanting to happen only matters in the unusual
> case that an exact copy exists in the pool but not in the previous backup of
> this machine.
True; but that is biting a bit: I create a large file, it gets
backed u
On 8/28/10 10:18 AM, martin f krafft wrote:
> Hello,
>
> Using rsync+ssh as my transfer method, I find that backuppc, when
> backing up a new host, transfers all files, even if specific files
> are already in the pool.
>
> The docs[0] say:
>
>As BackupPC_tarExtract extracts the files from smbcl
also sprach martin f krafft [2010.08.28.1854 +0200]:
> Using lsof, I found that the BackupPC_dump process actually has the
> corresponding pool file up for reading, so it has identified it.
>
> This makes me wonder even more why the client still transfers the
> whole file. Shouldn't BackupPC_dump
also sprach martin f krafft [2010.08.28.1718 +0200]:
> This is in contrast to what I am experiencing. Is backuppc fetching
> the file into memory to compare it with the pool from there?
>
> Thinking about it, this is what needs to happen because it needs to
> have the file to determine its hash.
Hello,
Using rsync+ssh as my transfer method, I find that backuppc, when
backing up a new host, transfers all files, even if specific files
are already in the pool.
The docs[0] say:
As BackupPC_tarExtract extracts the files from smbclient or tar,
or as rsync or ftp runs, it checks each file
16 matches
Mail list logo
