Hello, On Tuesday 21 November 2006 22:32, Steen Meyer wrote: > 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?
The voting determines the priority, but for a feature to be implemented, it requires a developer to implement it. Item 1 was encryption, and Landon implemented that. Item 2 was migration, I implemented that. No one signed up for Item 3, which is the project you want, accurate restoration of files. > > I believe it is not true that other backup systems don't handle this. I would like to know what you base that belief on. My understanding is that virtually all backup systems decide to backup or not on the OS time stamps as Bacula does, and hence suffer the same problem. Whatever the answer to that question is, knowing it will not change anything concerning getting the feature implemented in Bacula. There are a lot of ways to help get code in Bacula implemented ... it just requires a bit of imagination, and some action. There are a large number of *big* users out there, but over the last year there have been very few (zero I think) offers of help from them -- no code submissions, no contributions. Most everything that has been done in Bacula over the last year has been done by individual contributors (some with the concent of their employers). Landon's effort was sponsored by a lot of people. The migration effort was sponsored by Riege Software International. To the best of my knowledge no other project was sponsored though many other projects got done, all by individual contributors. As always, I will continue to oversee everything that goes into Bacula, and for my own personal contribution to the next version, I will focus on performance issues, and a better GUI, so if you want that particular feature, please organize something so that it gets implemented. Regards, Kern > > > 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
