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?
==================
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. :-(
AB
-------------------------------------------------------------------------
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
