On Wednesday 22 November 2006 17:54, Alan Brown wrote: > On Tue, 21 Nov 2006, Kern Sibbald wrote: > > > 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. > > The only package I'm aware of which doesn't rely on OS timestamps uses a > database to keep snapshots of the filesystem state (and is quite > expensive) > > > Bacula has an extensive database, why not USE it?
This is no problem. It has been planned. This database is already used to detect changed files for Verify. It works very well. > > > ================== > > > The fundamental problem with almost all backup software is an assumption > that file timestamps will only ever increase, never decrease. While this > is right most of the time, it's not right all the time. > > > > The current problem is that Bacula (in common with almost all other backup > software) only looks for mtime or ctime higher than the last backup start > time. > > If for whatever reason a file appears with Mtime and ctime PRIOR to the > last backup start time (eg rsynced in, or last backup was of an unattached > filesystem stub...), it won't get looked at. > > These can be taken care of by comparing the current filesystem > state with the last known filesystem state in the database and > backing up files which have appeared regardless of timertamp. > > Once you start doing this, it is possible to note if a file has gone > missing and flag it as deleted in the database - that takes care of > restores bringing back zombie files, effectively giving "snapshot" > restoration without having to replicate the entire database. > > > Another worse-case scenario: > > An attacker replaces a system-critical file with another of the same size > and tweaks ctime+mtime. This won't be backed up, even if the file is on a > different inode (some versions of file replacement may not change the > inode being used, some filesystems (reiser) do not store inode > information. This means there is no way of telling when the file was > changed and renders all backups suspect. > > > The only way to deal with this is checksumming the file vs > stored file checksums and that is computationally expensive. > > > > Whatever the answer to that question is, knowing it will not change anything > > concerning getting the feature implemented in Bacula. > > We are willing to put some money into sponsoring development. > > > 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. > > *Big* users are the ones who stand to benefit most from these changes, > however we're academic and cash-strapped. :-( Yes, even though there are some quite large academic sites, I didn't consider them as *Big* users in my prior email. If there are a few more users like yourself that want this feature and are willing to contribute directly to a developer, please get in touch with me oof list because a developer contacted me today and I am sure he could be encouraged to implement this feature. If possible please specify what you could afford. I would really like to see this implemented. All the mechanisms already exist, it is just a matter of implementing them. Best regards, Kern ------------------------------------------------------------------------- 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
