Les Mikesell wrote at about 16:36:37 -0500 on Monday, August 31, 2009: > Jeffrey J. Kosowsky wrote: > > > > I have seen problems where the attrib files are not synchronized with > > the backups or when the pc tree is broken. In fact, that is the reason > > I wrote several of my routines to identify and fix such problems. Now > > true, the cause is typically due to crashes or disk/filesystem issues > > outside of the direct scope of BackupPC but there are real-world > > synchronization and integrity issues that can arise. > > But nothing you've proposed will make any difference in this respect. > Well, maybe different, but nothing to enforce additional synchronization > with the file content.
Except that it is easier to back up a database than to back up thousands if not millions of scattered attrib files. Also, there are well-known tools for checking database consistency while you need to write custom ones for attrib files. But the main point is that I was never claiming this as a particular advantage of databases, I was merely answering your question about whether I had ever had problems with attrib files. > > Also, the slowness of reconstructing incrementals whether in the > > web-based view or in the fuser view is in a large part due to both the > > slow nature of attrib files and the fact that you have to crawl > > backwards through the backup tree to find which is the latest visible > > version of each file. Just think how many attrib files you need to > > find, open, read, decompress, parse, etc. just in order to see what > > files are visible and think how this scales when you have large > > directories and many levels of incrementals. > > OK, but I almost never do that, and probably wouldn't even if it were > faster. And I don't use incremental levels because even without the > attrib files you'd still have to do extra work to merge the directories. OK. Then we have different use cases. For example. I like to use the fuser implementation to look for old files or old versions of files. > > > Indeed, there is no > > question in my mind that a single well-constructed relational database > > would be orders of magnitude faster here. > > Until you go to get the data, which is kind of the point. I can only tell you how slow and non-optimized the current implementation is. Do you really believe that a relational database wouldn't be significantly faster than the current approach finding/opening/reading/decompressing/parsing multiple layers of attrib files? ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
