3 ms·
It depends. If the resulting file is truly random vs. the last time you mounted it, then you (of course) need to retransmit everything. However, imagine that
by rsync 13y ago
It depends.
If the resulting file is truly random vs. the last time you mounted it, then you (of course) need to retransmit everything.
However, imagine that every time you closed your TC volume or unmounted filevault it had to rewrite an entirely new multi-GB file ? Of course that would take forever and would be difficult to use.
So most encryption image software organizes the image internally such that new data written only affects portions of the file. And then, in theory, rsync with options like --partial --inplace --whatever will then transfer it efficiently.
BUT, our experience is this seldom works properly. The amount of internally changed data changes dramatically form usage to usage, and often has very little to do with the amount of actual data you changed. We just never got it to work well, consistently.
- nsomaru 13y agoDoes this mean you guys found that a large portion of the encrypted file had to be retransmitted as compared with the number of bits actually changed? How does one consistently store encrypted data using rsync.net as a backend, whilst maintaining the benefits of the rsync protocol? This seems to rule out the benefits of using rsync w/ encrypted files. Is there something I'm missing?