[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] rsync link behavior
Alright. Librsync it is.
I will try to make a separate program that will try to make it work with librsync. See how it goes.
I don’t suppose it should be that problematic to compare the two different data buffers.
If I have the old record in the volume, i can trigger a read_data session on the storage from within the fd and transfer the data to the fd.
In the save_file() callback I can both transfer the old data from the storage to the buffer, and read the file acquired from find_one().
The main problem may be actually implementing some kind of a merging policy prior to comparison since the old data must be up to the data with all relevant previous backups.
One thing that puzzles me is how I can transfer a large chunk of data to the file director machine for the comparison procedure without losing the actual reason for this feature. It will be vastly time consuming and expensive but I suppose in the rsync code I will find the answer to that question.
From: Kern Sibbald [mailto:kern@xxxxxxxxxxx]
Sent: Wednesday, October 01, 2008 6:25 PM
Cc: Eli Shemer; Bacula-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Bacula-devel] rsync link behavior
On Wednesday 01 October 2008 17:50:24 Eli Shemer wrote:
> Hey there,
> After doing several incremental backups of our remote servers, I've noticed
> the backup sizes and transfer time are just too long.
> Making bacula almost completely improper for backing up remote servers with
> big single files.
Yes, you need high speed connections.
> I wanted to know whether someone actually got to implement an incremental
> backup to act like rsync does upon file changes ?
It is a project we are currently discussing as possible in a release following
3.0.0 scheduled around the end of the year -- i.e. we hope to begin the
project sometime in 2009. If there is commercial funding of this project
(already one company interested) we could probably speed it up.
> I'm looking to write a patch to the save_file callback in the bacula-fd's
> backup procedure to utilize the gnu's diff and patches and to send those
> over the line to the bacula-sd. Of course a corresponding implementation in
> the storage device will also be required.
Unless I am missing I am not sure such a patch would be very appropriate. For
it to work, you would need both the original file and the new modified file,
and I am not sure how you will accomplish that. In addition, diff and patches
only work for source files, which is rather limiting.
If you do figure out some clever way to have both files, then it would be
*much* better to add some code that uses the librsync library calls to
effectively implement what rsync does.
> Comments anyone ?
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.