| 1 |
Am 08.01.2013 08:55, schrieb Alan McKinnon: |
| 2 |
> On Tue, 08 Jan 2013 08:27:51 +0100 |
| 3 |
> Florian Philipp <lists@×××××××××××.net> wrote: |
| 4 |
> |
| 5 |
[...] |
| 6 |
>> |
| 7 |
>> As I said above, the point is that I need to detect the error as long |
| 8 |
>> as I still have a valid backup. Professional archive solutions do |
| 9 |
>> this on their own but I'm looking for something suitable for desktop |
| 10 |
>> usage. |
| 11 |
> |
| 12 |
> rsync might be able to give you something close to what you want |
| 13 |
> easily |
| 14 |
> |
| 15 |
> Use the -n switch for an rsync between your originals and the last |
| 16 |
> backup copy, and mail the output to yourself. Parse it looking for ">" |
| 17 |
> and "<" symbols and investigate why the file changed. |
| 18 |
> |
| 19 |
> This strikes me as being a very easy solution that you could use |
| 20 |
> reliably with a suitable combination of options. |
| 21 |
> |
| 22 |
> |
| 23 |
|
| 24 |
Hmm, good idea, albeit similar to the `md5sum -c`. Either tool leaves |
| 25 |
you with the problem of distinguishing between legitimate changes (i.e. |
| 26 |
a user wrote to the file) and decay. |
| 27 |
|
| 28 |
When you have completely static content, md5sum, rsync and friends are |
| 29 |
sufficient. But if you have content that changes from time to time, the |
| 30 |
number of false-positives would be too high. In this case, I think you |
| 31 |
could easily distinguish by comparing both file content and time stamps. |
| 32 |
|
| 33 |
Now, that of course introduces the problem that decay could occur in the |
| 34 |
same time frame as a legitimate change, thus masking the decay. To |
| 35 |
reduce this risk, you have to reduce the checking interval. |
| 36 |
|
| 37 |
Regards, |
| 38 |
Florian Philipp |
Archives