This was on the feature request vote last year, but did not get a top priority. It is a pity that not so many users are interested in the ability to make a correct restore under all (rather normal) circumstances. Also that deleted files are always restored come under this category.
I thought however that it would be implemented when the top priorities were finished - am I wrong here? I believe it is not true that other backup systems don't handle this. Steen Torsdag 16 november 2006 19:07 skrev Martin Simmons: > >>>>> On Thu, 16 Nov 2006 13:45:55 +0000 (GMT), Alan Brown said: > > > > On Wed, 15 Nov 2006, Martin Simmons wrote: > > > Incremental backups use the ctime as well as the mtime by default, so > > > it depends on whether mv changes the ctime (some file systems do, some > > > don't). > > > > rsync processes mirror both the ctime and mtime by default. > > > > This raises a problem if files older than the last backup are mirrored > > with the rsync process. > > > > > If Bacula does detect the moved file then there is also a problem with > > > restoring from incrementals, because it will create two copies of the > > > file, with the old and the new names. > > > > > > There is currently no way around this, so regular full backups are > > > advisable. > > > > Synthetic backups would solve both problems. This has been discussed as a > > way of handling backup/restore of large filesets. > > Right, but if synthetic backups can be made reliable then so can > incrementals. I can't imagine why anyone would actually need unreliable > incrementals :-) > > > Basically the only _reliable_ method of doing backups is to compare a > > snapshot of the current disk's index structure with a snapshot from the > > previous backup and then backup all files which have altered or appeared, > > no matter how old they may look. > > > > Having made the snapshots for accurate backups, keeping them means that > > "point-in-time" restores are trivial and there's no issue of previously > > deleted files "coming back to life"... > > > > It's a win-win situation. > > It's just a SMOP to generate the indexes then :-) > > > It also has major advantages if a backup is performed on an unmounted > > filesystem stub,(**) because the next backup will catch files which have > > changed, even if older than the last one. > > > > To my knowledge, almost every backup method out there relies on > > mtime/ctime stamps and is susceptable to the same problems with files > > with old stamps not being backed up. > > Alternatively, backups should made from filesystems instead of files and > directories. > > On most unix systems it is impossible to set the ctime via the normal file > APIs, so there is no way to create old files except by old file systems > reappearing like that. > > __Martin > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
