Moving client filspace data

[ptate]

Hi Everyone,

I'm really hoping for some clarifcation on something I'm trying to acheive. We have a Windows file cluster with 4 volumes, each of which stores a large number of files. I'm finding the backup process is taking a very long time with the scanning on the files being a large proportion of that time.

To try and improve performance (without going down the journaling route) I'm thinking of adding three more BA-Client instances to the server so that the file scanning is multi-threaded (I have enough tape mounts to run these instances together).

However, I have a node which has all 4 filespaces worth of data and I need to create 3 more nodes and reassign the relevant filespace from the original node to the new node.

I've found an old article on the IBM website which details the following process:

Note: NodeA is the original node, NodeB is one of the new nodes

1. Rename NodeA to NodeB
2. Export the filespace from NodeB
3. Rename NodeB back to NodeA
4. Create a new node NodeB
5. Import the filespace into NodeB

Is this the way to do this? Is there a better way of doing this?

Many thanks

Phill

[moon-buddy]

You are better off using a Journaled backup.

[JeanSeb]

What moon-buddy said.
I was very reluctant to implement Journal based backup on a file server here, but after almost 2 months of trouble free backups for a server that was a daily nightmare to backup (30 millions + files), I can now say it's the best way to go. Fast to implement too !

[crooked]

Hi, sounds like we also need to go down the journaling route, can someone point me in the right direction of documentation for setting up journaling - we're struggling with backing up email vault servers (yes evault!).

[Jeff_Jeske]

The use of named pipes http://publib.boulder.ibm.com/infoce...ans6000050.htm is required to force the journal to attach itself to a specific node. Implementing named pipes required modifications to the dsm.opt and tsmjbbd.ini files.

The dsm.opt file received the following named pipe command:
JournalPipe \.

The tsmjbbd.ini file received the following named pipe command:
JournalPipe=\.

To associate the ini file with the journal service I ran the following dsmcutil command:
dsmcutil update journal /name:"TSM Journal Service" /JBBCONFIGFILE:c:files.ini

Running "dsmcutil query journal" will show the relationship.

According to IBM this is all that is needed to force a journal to node relationship.

A service restart was required to load the newly entered changes. Therefore tonight's backup will perform a full scan of the 'H' drive and my run longer than expected.

[ptate]

Thanks for all the replies...Journal based backups seem sensible. I've just done some analysis and a 12 hour backup of the file server has been primaraily made of up file processing (over 7 hours).

How do I go from a normal client to a journal-based backup? Do I just install the jounralling service, link it with the filespace and let the backup run tonight as normal?

Are there any pitfalls with journal based backups? Where is the jounral stored? Are there any disk or memory-related requirements over and above a non-journal backup?

Many thanks

Phill