[Top][All Lists]

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

Re: [rdiff-backup-users] Re: 1) Using samba to backup windows shares 2)

From: Stelios K. Kyriacou
Subject: Re: [rdiff-backup-users] Re: 1) Using samba to backup windows shares 2) sparse files
Date: Sat, 21 Jun 2003 19:23:43 -0400 (EDT)

On Fri, 20 Jun 2003, Ben Escoto wrote:

> >>>>> "SK" == STELIOS KYRIACOU <address@hidden>
> >>>>> wrote the following on Tue, 17 Jun 2003 15:27:06 -0400
>   SK> I think i figured out the first part of my problem when backing
>   SK> up windows files (with samba): It seems that FAT and NTFS are
>   SK> not as accurate in reporting the modification date of a file so
>   SK> that file is flagged as changed even though it is not changed. A
>   SK> solution to this problem would be a flag to rdiff-backup similar
>   SK> to rsync --modify-window to allow a 2-second difference as being
>   SK> the same date.  By the way, i suggested in my first email that
>   SK> the modification time was changing by 1/100 of a second; that
>   SK> was a mistake: the change is 1 second.
> I'm not sure I understand the problem.  If, say, we are backing up a
> FAT filesystem that has coarser-grained modification times, shouldn't
> that, if anything, result in files which appear to the same and
> aren't, not vice-versa?
> Suppose we are backing up a windows file system to a linux one.  At
> time 1000000000 a file is created.  Later at time 1000000001 it gets
> changed, but the time stays at 1000000000.  This could cause
> rdiff-backup not to notice the file is changed.
> I could see there could be a problem if we backed up a unix filesystem
> onto a windows one, but that's not what you seem to be doing?


Thanks for your answer and for a great program that i use for many
important backups (daily backup of a 100GB dir). I also use it to document 
changes in our servers /etc directories. In a way it is also a very basic
tripwire program :-).  

Regarding your comment above: First, this is not really a very big issue
since it just changes the modif time of some files to +-2 seconds. It is
more of a nuisance since when i have verbocity on (5?) i dont know which
files actually changed since i get all these seperfluous files changed.
You are correct in your reasoning, but there seems to be something strange
behavior concerning this issue: either samba or windows2000 give a wrong
modif time by 2 seconds in my experience, either up or down. It seems
random to me. Now, why this happens exactly I dont know. Here is some of
my experience: I stat the modification time of the rdiff-backup increments
to a single file (i put .... where i removed some stuff for clarity or to
avoid publishing private data). See how the modif date oscillates by 2

address@hidden stat -c%y \

Fri Oct 18 13:38:52 2002
Fri Oct 18 13:38:50 2002
Fri Oct 18 13:38:52 2002
Fri Oct 18 13:38:50 2002
Fri Oct 18 13:38:52 2002

>   SK> Any comments on my second question regarding rdiff-backup and
>   SK> possibility of improving it to allow for sparse file checking
>   SK> and subsequent sparse file writing? This would be quite useful
>   SK> for saving a lot of space (20% in our lab) and more importantly
>   SK> for not running out of space due to the backup taking more space
>   SK> than the original (which has some sparse files).
> Hmm, I haven't really looked into this, but have heard that sparse
> files are a real pain.  For instance:
> ftp://ftp.berlios.de/pub/star/testscripts/zwicky/testdump.doc.html
> claims that there is no portable way to do this.  I wouldn't enjoy
> writing a lot of C, especially if it were specific to various OSes..
> But I guess if rsync does it maybe I can steal code or something.

Both gnu cp and rsync have this functionality. Unfortunately my
c-programming and python-programming is not so good to try to add this
feature myself. I was hoping that since rdiff-backup was based on rsync
libraries it would be easy. 

Thanks again


reply via email to

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