rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] backup misses files with older date


From: Jakob Unterwurzacher
Subject: Re: [rdiff-backup-users] backup misses files with older date
Date: Thu, 08 Jan 2009 13:17:58 +0100
User-agent: Thunderbird 2.0.0.18 (X11/20081125)

bt101 schrieb:
> I installed rdiff-backup and used it for a few days.  I was eager to see how 
> it would handle a small change to a large (2G) truecrypt file.  I added a 
> small file into the truecrypt file and then performed a backup.  To my 
> surprise, the truecrypt file was completely missed from the backup.  I then 
> looked at the modify date of the truecrypt file and it was old.  It seems 
> truecrypt will preserve the modify date (there's a setting to change it if 
> you wish). 
> Be that as it may, am I to understand that backup programs will completely 
> miss files that NEED to be backed-up, simply because their dates are old?  Do 
> they not do a checksum or something?

Yes. The default mode of operation for most backup programs is to check
wether size, date or inode number of a file have changed since the last
backup. If none has changed, the file contents are assumed to be
unchanged since the last backup and the file won't be copied again.

This will miss changes when files lie about their modification dates!
Disable the "preserve modify date" option in TrueCrypt and everything
will work as expected.

> 
> It occurs to me that I have (many times) downloaded software that is gzipped. 
>  When I unzip the files, they all have old dates.  It would seem that the 
> backup program would be missing loads of files that really need to be 
> backed-up.

No. rdiff-backup will skip the file (i.e. not copy the contents *again*)
if and only if the modification date and size and inode number is the
same as it was *when the last backup was run*.
New files will always be copied.

> 
> Incidentally, I am also performing a dar backup of the filesystem as well, 
> and it also missed the backup of this modified file.
> 
> Seems like a pretty big hole to me!

There is only one alternative to checking the date, size, inode number
and then assuming that the file content hasn't changed: Reading the
whole file off the disk and then comparing it (by checksum, f.x.). And
this will be slow... (checksumming filesystems may change the situation
in the future)

A --checksum option like in rsync is not available AFAICT from reading
the man page, unfortunately.

Conclusion:
Don't make files lie about their modification date and everything will
be allright.

Jakob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]