On May 11, 2009, at 7:06 PM, silky wrote:
How about this.
When you modify a file, the backup system attempts to see if it can
summarise your modifications into a file that is, say, less then 50%
of the file size.
So if you modify a 10kb text file and change only the first word, it
will encrypt that component (the word you changed) on it's own, and
upload that seperate to the file. On the other end, it will have a
system to merging these changes when a file is "decrypted". It will
actually be prepared and decrypted (so all operations of this nature
must be done *within* the system).
Then, when it reaches a critical point in file changes, it can just
upload the entire file new again, and replace it's "base" copy and all
the "parts".
Slightly more difficult with binary files where the changes are spread
out over the file, but if these changes can still be "summarised"
relatively trivially, it should work.
To do this, the backup system needs access to both the old and new
version of the file. rsync does, because it is inherently sync'ing
two copies, usually on two different systems, and we're doing this
exactly because we *want* that second copy.
If you want the delta computation to be done locally, you need two
local copies of the file - doubling your disk requirements. In
principle, you could do this only at file close time, so that you'd
only need such a copy for files that are currently being written or
backed up. What happens if the system crashes after it's updated but
before you can back it up? Do you need full data logging?
Victor Duchovni suggested using snapshots, which also give you the
effect of a local copy - but sliced differently, as it were, into
blocks written to the file system over some defined period of time.
Very useful, but both it and any other mechanism must sometimes deal
with worst cases - an erase of the whole disk, for example; or a
single file that fills all or most of the disk.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
