> 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 :)
>
>
> Brian Vraamark

Surely the use of rsync assumes that the source file is not changing during
the sync process? It sounds very dangerous to me to be thinking of applying
this methodology to large files.. no?
Alan