I know of at least one large customer who is successfully using Journal Based Backup in a SAN cluster environment.
The ReadDirectoryChangesW api works with any local (non network) disk and will work with network drives but the Journal Daemon blocks specifying network drives because the API limits the notification buffer size for these types of drives to 64K or less which essentially makes it unusable. As mentioned if the previous append SAN drives are considered local resources. I have written several utilities for interrogating the file system and profiling file system change activity which are helpful in determining if a Journal Based Backup is viable in a particular environment. If you are interested in obtaining these utilities on an AS IS basis please send me a note directly. There are some limitations in running multiple Journal Based Backup processes (via multiple schedules or whatever) which have been somewhat addressed in the latest release (5.20) and fixtest (5.16.2) which may come into play in a cluster environment, so please consider applying the latest fixtest (and reading the relevant portions of the readme file) if the target environment has multiple Journal Based Backups scheduled which may run concurrently. I'm not sure I understand the following statement: >>> I'm going to defer to Andy Raibeck on the official answer on this >>> one.Does it work? The answer I got was >>> that this was not supported, because the TSM Journal Service cannot be >>> restarted on the second >>> half of the cluster if a failover occurs. But if you are willing to live >>> with this limitation, it does work. You >>> can have the journal service monitor the shared resources, and it will >>> journal them. It just won't work in >>> the event of a failover. The journal will not be valid, and you will have >>> to resort to a "normal" incremental backup. If the journal service is installed on both nodes in the cluster and the journal service is configured to journal the shared resources the same I don't see any reason why failover wouldn't work (clustering isn't my area of expertise so I could be wrong...). The journal service should be installed on both nodes in the cluster with identical configuration for shared journaled resources. The shared resource(s) being journaled should be offline and deferred on one node in the cluster, and online (being journaled) on the other node. When a failover occurs the shared resource(s) should go offline on the node which is failing over, and should come online on the node which is being failed over to. Since the PreserveDbOnExit setting is used the journal db should remain valid and journal based backups should resume uninterrupted. Again, I'm not sure why this would work, but perhaps there is something I am missing. Sample configuration settings for a shared resource with Journal daemon running on both nodes in cluster: [JournaledFileSystemSettings.D:\] ; Journal DB must always be accessible from each node is cluster JournalDir=d:\tsmjournal ; Journal will remain valid if journal fs goes offline and comes backup online ; such as is the case if journal daemon stops/restarts PreserveDBOnExit=1 ; Fs will go in defer mode if it is not available on the node which the journal daemon is ; running on, will come online as soon as it becomes available DeferFsMonStart=1 ; ;Interval in seconds to check availability of deferred FS DeferRetryInterval=30 ; ; Prevents error messages from being logged when FS is offline but deferred via prior setting logFsErrors=0 Pete Tanenhaus, TSM Client Development Pete Tanenhaus Tivoli Storage Solutions Software Development email: [EMAIL PROTECTED] tieline: 320.8778, external: "Those who refuse to challenge authority are condemned to conform to it" ---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 07/13/2003 10:40 AM --------------------------- Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: MSCS Win2K, TSM Journal Backups and SAN attached disks!!! See answers below: At 04:07 PM 7/11/2003 +0100, you wrote: >*SMers, > >I understand from searching back on the list that this one might be a >bit of a hot potato, but here goes anyway: > >We'd ideally like to set up TSM Journaling on a Win2K MSCS Cluster using >TSM 4.2 Client with SAN attached disk. > >So, my questions are: > > o) Does the TSM Journal Engine support SAN-attached disks - I >recall something about the Win32 api ReadDirectoryChangesW only >monitoring 'local' file system changes - does this preclude SAN attached >disk? A SAN-attached disk is considered a local file system. Yes, this would be "journalable". (Is that even a word?) > o) Would this work in an MSCS cluster? I'm going to defer to Andy Raibeck on the official answer on this one.Does it work? The answer I got was that this was not supported, because the TSM Journal Service cannot be restarted on the second half of the cluster if a failover occurs. But if you are willing to live with this limitation, it does work. You can have the journal service monitor the shared resources, and it will journal them. It just won't work in the event of a failover. The journal will not be valid, and you will have to resort to a "normal" incremental backup. >Has anyone done this, or tried to? Any advice? > >Any help greatly received, as always! > >Rgds, > >David McClelland >Global Management Systems >Reuters Ltd > > >--------------------------------------------------------------- - > Visit our Internet site at http://www.reuters.com > >Get closer to the financial markets with Reuters Messaging - for more >information and to register, visit http://www.reuters.com/messaging > >Any views expressed in this message are those of the individual >sender, except where the sender specifically states them to be >the views of Reuters Ltd. Dave Canan TSM Performance IBM Advanced Technical Support [EMAIL PROTECTED]
