Hi David. I have a customer where we have implemented a similar approach. The environment is significantly smaller than yours. Our daily maintenance script, which was originally based on the Admincenter is shown below. I still prefer to have a scheduled daily maintenance script that performs all daily housekeeping functions as opposed to a myriad of schedules performing one function at a time and manually managing timings for the completion of the individual administrative command schedules.
Name Line Command Number ---------- ------ ------------------------------------------------------------ MAINTENAN- 5 backup db devclass=VV type=full wait=yes CE_PLAN_- CUSTOM 10 prepare source=dbbackup devcl=VV wait=YES 15 protect stg backupcontainer w=y 20 replicate node * maxsess=10 wait=yes 25 EXPIRE INVENTORY SKIPDIRS=NO WAIT=YES RESOURCE=40 30 reclaim stgpool ARCHIVETAPE threshold=50 35 reclaim stgpool VVTAPE threshold=50 40 mig stg archivepool lo=0 45 mig stg vvpool lo=0 50 del volhist type=all todate=-30 We still use virtual volumes for the DBB even though you can make a good argument that the DBB is less important in a fully synchronized container storage pool environment and can be put on a local file system (as in the 8.1 Blueprint). The nice thing about virtual volumes is that DRM manages the DBB and RPF expiration. This server pair is at 7.1.6 and we have not had any problems with directory container pools, nor moving containers to different file systems (analogous to moving file device class volumes). Best regards, Joerg Pohlmann -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of David Beardsley Sent: Tuesday, May 09, 2017 05:45 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Protect Storage Pool and Replicate Node Process Issuance Hello All, We are currently in the process of implementing node replication in our environment. We have an onsite server onsite, and one about 200 miles away as our replication target. Our implementation plan has been to start a "protect stg" for our container pools in the morning when the majority of our backups are done, allow that to complete, then later in the day run a "replicate node" command. This seems like it should work to me, and I started by creating scripts to run the protect storage pool and been running the replicate node command for a few days by hand for a few reasons. But since we have our processes hammered out, the protect storage pool continued to run without issue, but when the script issued the "replicate node * " command it crashed the server. I am curious to see what implementation specs others have or are looking at in regards to implementing replication. Now for some details on the instance that experienced the issue, note our replication server is running the same OS and TSM server version: Operating systems: Redhat 6.1 TSM server version: 7.1.7.100 Number of nodes: just over 1600 Nodes currently enabled for replication: about 5 Thanks David Beardsley Cornell University