Re: hdup 2.0.1 argggg

Miek Gieben <[email protected]> Wed, 8 Dec 2004 10:32:52 +0100
Newsgroups gmane.comp.sysutils.backup.hdup.general
Message-ID <[email protected]>
[On 02 Dec, @ 19:19, Boris wrote in "Re: [hdup-user] hdup 2.0.1 arg ..."]
> On Wed, 2004-12-01 at 15:46 +0100, Miek Gieben wrote:
> > If you move /opt to /foo the ctime changes - at least under Linux.
> > (if you put something in a dir the mtime changes). So when you
> > recursively walk a tree and encounter such a directory - you must
> > backup the entire subtree, no matter what. This is a bit like the
> > opposite of the .nobackup keyword.
> 
> That would work, but it may be overkill - there are other reasons the
> directory ctime could change (e.g., deleting a file in it).  Backing up

In that case the mtime would change, I think. But I don't know how
portable that is, prob. very non portable.

> the entire subtree rooted at that directory would be unnecessary in that
> case, and could result in much-bigger-than-necessary backups.
> 
> I think the only way to know what really needs to be done is to have a
> list of what files were backed up the last time -- hence the concept of
> the listed-incremental used by tar.  Anything not on the list is backed
> up unconditionally; anything that is on the list has its modification
> time checked and is only backed up if recently changed.  If a file is on

I'm toying with the idea of splitting hdup in 2 parts - one part will
get a filelist through stdin and will spit out a list of files/dirs
that needs to be backupped. Hdup itself will then just read this list
of files/dirs and will back this up. This will happen in a standard
pipeline. As advantages of this approach I see; KISS :-) and the
possibility to tweak the file list with 'egrep' or whatever before
it is send to hdup...

> the list but no longer exist, that fact is noted so that it can be
> removed during a restore of the containing directory.

how on earth tar does this is a mystery to me...Maybe I will look into
this, but I have enough of gnu tar already :-)

Keeping the listed-incremental list around for a possible backup sucks
big time, OTOH backups and restores are ofcourse related to each
other,

grtz Miek