Re: Incremental backup including entire file?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yuraukar wrote:
| The file that is causing the problems is my personal Thunderbird
inbox. With my
| provider only offering POP3, I think there is no way to store it in a
different
| way.
| By the way, this also potenially applies to other files. We have some
large
| database files, where entries are added, so they change over time as well.
|
| I frankly don't see myself applying a manual workaround producing a manual
| binary diff first and then make the backup. Not knowing exactly which
other file
| may be affected, this is not a solution.

I can understand that,

|
| Dennis, would you consider this as a potential enhancement. I would
not go into
| detecting binary files. How about a command line option that specifies
a file
| size that, if the file is larger than that - would trigger a binary diff?

the idea is interesting, but there is several points to consider:
the lack of a single previous differential or full archive leads to the
impossibility to recover a file that has been recorded as a diff from
the archive of reference, if the diff cannot apply because the current
file is not exactly the same as the one on which the diff was applied.
(OK, that's a long sentense, maybe not very clear, but I'm sure you will
understand the idea).

And second point, I must check the existing binary diff tools, and how
to integrate them in dar.

|
| I do see your concern regarding the restore operation. But don't you
need the
| reference backup on an incremental restore anyway?

no.

| Yes, if you are restoring a
| single file only, you might need fewer archives, but for a full
restore, you
| need them all anyway.

not exactly, if restoring a set of file you need at worse (if you are
not lucky) one archive (full or differential) per file, and at best a
single archive if all last versions are located in a single archive. If
using binary diff in the backup instead, even for a single file you may
need all differential backups up to the original full backup ... just
for a single file !!! This is the case when that files changed (even a
little) each time a backup has been made.

But you are right, there is absolutely no difference when restoring a
whole system from scratch, the operation is even faster because you
don't have to read, uncompress, write the huge amount of date that will
be erased by the next differential backup, (if that huge data has
changed at every backup).

|
|
|
|

You win. :-) (With the restriction that it must be feasable seen the
current existing tools, or known algorithms, but I'm optimistic ;-) )

Cheers,
Denis - With a single 'n' :-)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDCinPpC5CI8gYGlIRAmysAJ97F/eM0SoDvk5V/99Un/uTraf/1gCguwfP
5HDbEA12bgARzurx+dbZX9E=
=XmUX
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf