>>> This is a definitely a client-centric view! From my server-centric view >>> I think the primary benefit is the elimination of the server processing to >>> generate and download the whole activeset metadata.
To some extent this is true but the point I was trying to make was that building the local list of objects by scanning the entire local filesystem has proven to be a much bigger performance bottleneck than building the list of server objects. This is especially true with very large filesystems because the scan processing becomes progressively slower (maybe not quite exponential) with larger (number of objects) and more complex (deeply nested dir structure) filesystems. The basic difference between traditional incremental backup and journal based backup is that traditional incremental must build three lists of objects: a local list obtained by scanning the local filesystem, a server list of active objects obtained over the network, and a candidate list of objects to be updated, backed up, or expired which is derived by comparing the local and server lists. Journal Based Backup obtains objects to backup or expire (update currently isn't supported) by querying a local change journal database which is maintained by real-time monitoring of filesystem change activity. Journal Based Backup eliminates scanning the local filesystem, querying the server, comparing local and server objects, and is much less memory intensive (not only are the local and server lists eliminated, but the candidate list is as well because journal entries are processed individually, i.e the entire journal doesn't have to be stored in memory). The disadvantage of Jbb is that it is not as comprehensive as traditional incremental in that in can not enforce nor detect changes in many policy attributes such as copy frequency, binding to a different management class, etc. So you can draw your own conclusions as to what types of environments it is beneficial in ... Pete Tanenhaus Tivoli Storage Solutions Software Development email: [EMAIL PROTECTED] tieline: 320.8778, external: 607.754.4213 "Those who refuse to challenge authority are condemned to conform to it" ---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 01/11/2002 11:38 AM --------------------------- Bill Colwell <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/10/2002 03:47:55 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: ***The JOURNALED BACKUP saga continues...*** In <[EMAIL PROTECTED]>, on 01/10/02 at 03:47 PM, Pete Tanenhaus <[EMAIL PROTECTED]> said: >Answers/Comments to questions...... <snip> >The primary performance benefit over normal incremental backup is >eliminating >scanning the entire local file system. This is a definitely a client-centric view! From my server-centric view I think the primary benefit is the elimiation of the server processing to generate and download the whole activeset metadata. I am planning to roll out 4.2.1.15 clients on new xp machines, implementing both journalling and subfile backups at the same time, and to upgrade 500+ win2k machines to this level. These are all desktop machines, not the kind of machines so far described as the ideal candidates for journalling, but I am focusing on the server savings. (My server is tsm 4.2.1.7 on os/390 2.10). -- -------------------------- Bill Colwell C. S. Draper Lab Cambridge, Ma. [EMAIL PROTECTED] --------------------------
