²Hello James, James Harper a écrit : > I put together some code to build a list of 'files changed since' using > the Windows USN Change Journal, and did a few comparisons... > > My example machine normally takes 8 minutes to back up 32MB on an > incremental, which calculates out at 66.6KB/second (according the bacula > report). To get a rough idea of the ideal speed, a full backup is 80GB > and normally averages around 2-4MB/second (again, according to bacula). > I don't think that you should compare backup throughput, the number of files/s should be a better choice.
> My un-optimised 'change journal' code which simply calculates a list of > files changed runs in a few seconds. In theory, even if I got 10% of the > backup speed of my 'Full' backup, my backup should run in under a minute > and put a heap less load on the server being backed up. I think this is > worth pursuing. > This is designed for that :) > (If you didn't read some previous emails from me on this subject - > Windows supports a Change Journal which contains a journal of all the > stuff that has happened to the filesystem. Accessing this is a bit more > work than I initially thought (building full paths is not > straightforward) but compared to recursing the filesystem and asking > "has this file changed", the Change Journal is much much faster) > > So now I'm looking at how I could integrate my code into bacula for some > proper performance comparisons. The 'find_one' routine appears to be the > right place for it, and my current idea is: > . top level call to find_one will build the change list from the > journal, then iterate through it, but only if the "File=" is the root of > the drive (eg C:/ or D:/) (initially at least, this isn't necessarily a > restriction, it's just easier :) > Do test in the simplest way. In a second time, if we are happy with this functionality we will have to think on how to make our code portable, how handle filters (File=c:/ksks), how associate USN with timestamp, etc... (lot of work and design to do, isn't it ?) > . the first level of recursion just backs up the file as normal, making > sure not to recurse itself any further. > After that you should be able to use the bacula testfind tool that should make your tests more easy. (maybe you need also a tool like "time" under unix that compute io, cpu, etc..) > . if, when building the change list, we find that the change list isn't > working for whatever reason (records fell of the end of the journal etc) > then we just fall back to the regular 'check each file against the since > date' code and everything works the same, but slower. > I would replace slower by something like "smarter" :) > Any comments? > > Thanks > Thanks you James Bye ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
