Werner --- > > The second option is to do full system ARCHIVES, but this > would cause activity on both the NSM and the client, neither > of which have available windows for this activity. > > Because either of these possibilities would, of necessity, be > occasional (at best once a week), there is the additional > issue of how easy it is to bring the system up to the most > current backup after the restore. Would a multi-filespace > simple restore be intelligent enough to pass only the last 7 > days of tape or would it pass all tapes with those filespaces on them?
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 files). On our first D/R test the PIT restore took six hours. As a result, I now run a weekly archive of the directory. At the D/R site we retrieve the most recent archive (about 30 minutes) and then do the PIT restore (about 15 minutes). > > A third possibility I have thought of recently is to isolate > these very large servers in their own COPY POOLs, effectively > co-locating only these servers, but I am not convinced this > would reduce the number of tapes passed by the DR restores, > and it would certainly increase the total number of tapes in > the DR set and increase off-site reclamation activity, which > already takes the better part of the day shift most days. We do this as well -- at the very least, split archive pools from backup pools. Then don't bother with reclaims on the archive pools. Just let them expire. This will require more tape, but tape is cheap in the great scheme of things. In our case, most archive data has a 23-day retention so we need 23 X <number of daily tapes> plus a few for contingencies. In actual fact, we have 4 off-site archive copy pools: one for MS-Exchange; one for the SAP datbase; one for the SAP redo logs; and one for all other Oracle database archives (and the second copy of the SAP redo logs). These all exist to speed up recovery during D/R. At one point, when using DLT-7000 drives, we had 445 tapes in the off-site storage that we had to take to the hot-site for our D/R testing. Thanks to the move to LTO and a bit of creative combinations (we used to have a seperate copy pool for the second set of SAP redo logs, for example) we now have about 115 LTO tapes off-site on any given day. We can recover adsm, restore a 650-plus GB SAP (Oracle) database, restore three additional Oracle databases (25 GB total), recover two MS-Exchange servers, and start recovering other TSM storage pools, all in just under 24 hours. Our TSM server is also the SAP DB server, so it's an S7A -- but we use 5 3581 LTO autochangers, configued as stand-alone drives. Our SLA doesn't require our big NT server to be up until day 3, so I recover the NT backup tapes from the consolidated off-site backup copypool first. HTH -- Tom Kauffman NIBCO, Inc
