For us it's a problem because we are dumping out some very large databases, some of which change daily but many which do not. We'd like to dump the files out every night and just have bacula back up the changed files. The unchanged files were recreated but are still identical to previous versions. We wouldn't care if they were restored with the wrong mtime. In fact, I've never run into a situation where I was concerned about the mtime of the restored files.
M. On Nov 28, 2006, at 8:12 PM, Dan Langille wrote: > On 28 Nov 2006 at 17:26, Michael Koppelman wrote: > >> Sorry if this is redundant but I just wanted to add my voice to the >> mix that it is too bad that bacula backs up files that have not >> changed just because their mtime changed. > > I have never seen it as a problem. > >> In the end, it is probably less expensive to checksum than move and >> handle redundant data. It would at least be nice if one could choose >> the scheme in the configuration so people who need to conserve >> computation time and people who need to converse bandwidth could >> choose accordingly. > > Any restore would give you the wrong mtime. Unless you started > getting fancy within the Bacula Catalogs. > > -- > Dan Langille : Software Developer looking for work > my resume: http://www.freebsddiary.org/dan_langille.php > PGCon - The PostgreSQL Conference - http://www.pgcon.org/ > > ------------------------------------------------------------------------- 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
