m2data wrote:

>>How is NBackup going to work?
>
> Only the developer can say, but I would like to have rsync build in
> :).
>
> The algorithme could be simplyfied, because data is allocate in pages.
> The page at offset 819200 with a pagesize of 8192 bytes would stay
> there as long as the record is not updated/deleted. If it gets
> updated, you would have to backup it up anyway. Only a full
> backup/restore would break you algorithme.
>
> If you at both ends build a MD5 checksum list you could compare the
> lists and only copy when the cheksum dosen't match. Each MD5 checksum
> (fingerprint) is 16 bytes long, so the blocksize should not be to
> small. If your database is 1GB and 8192 bytes in blocksize/pagesize
> then the list would be 2MB in size. That means that you would transfer
> 2MB even if file A and B is the same.
>
> An even better idea would be to only compare some sort of
> versionnumber/string in the database page header and only transfer
> (with compression) when the page has changed. Maybe that is what
> NBackup already is/will be doing :)

Forget MD5.

From memory, NBackup will be logging all changes to the database since
the last backup. This will be based on pages changed, and will allow the
rolling of an old backup forward to match the current database state.
The NBackup file will contain more information than a 'simple' rsync
diff, but that is because it carries more than a simple copy of the
database at a particular point in time, but it will still only contain
changes. For database with large volumes of daily changes it may be a
problem, but where there are gigabytes of fixed data it will be the only
way forward in the future.

We will have to wait for FB2 to see it in practice ;)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services