Author: Werner Kliewer <VKliewer AT MPI.MB DOT CA>
Date: Tue, 10 Sep 2002 10:29:48 -0500
I am working on our first TSM based DR plan for our data centre. We currently have a successfully tested several times plan using system specific tools, such as Sysback/6000 for AIX, BRM for AS/400,
Author: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>
Date: Tue, 10 Sep 2002 12:02:46 -0400
Werner, I feel your pain... ;) You have hit most of the major issues of disaster recovery with TSM squarely on the head. We have had similar experience in our testing... 4-6 hours to get the TSM serv
Author: David E Ehresman <deehre01 AT LOUISVILLE DOT EDU>
Date: Tue, 10 Sep 2002 14:43:38 -0400
should one we An alternative which does not involve client resources is to do a move nodedata command to consolidate a node's data onto a set of tapes. David Ehresman
Author: Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
Date: Wed, 11 Sep 2002 09:32:05 +1000
Werner Robin suggests periodic full backups by changing the mode. A less intensive approach is to run selectives over parts of of your node every day, so that over a week/fortnight/ month you will ha
Just 2 cents: Assuming that search for files spread over tape and tapes consumes much of your restore time, so that many small files count for significant amount of restore time while large files cou
Author: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>
Date: Wed, 11 Sep 2002 09:42:03 -0400
Juraj, Your scenario would be helpful to recover a lost filesystem or a lost client in the datacenter, but for Disaster Recovery, we must assume we'll be rebuilding the TSM server plus several critic
Author: "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>
Date: Wed, 11 Sep 2002 09:54:23 -0500
Werner -- My experience is that a point-in-time restore will use what already exists as a starting point. We have several large AIX filesystems with a great deal of daily activity (delete/create file