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