Disaster Recovery Plan Documentation The name and location of this file that you are reading is on the Reload server at the following path: /opt/beginfinite/reload/web/custom/drplan/drplan.pdf Reload s Push-Button Disaster recovery takes several actions automatically. However; there are generally some additional steps that must be taken at the time of a disaster. The idea behind the button is to create a Disaster Recovery Plan specific to your organization. The Disaster Recovery Plan would have information such as what actions need to be taken on the Reload server, and what is done in the live system in the case of a disaster. For example, in the event of a disaster recovery event, there may need to be some changes to the DNS to reflect the new TCP/IP Address of a GroupWise POA or MTA. This document could also contain phone numbers for individuals to contact, etc. Since the Disaster Recovery Plan should generally not be shared with the public, you may want to change the file location and corresponding URL where the Disaster Recovery Plan is located. The URL can be configured from the Configure tab in the Web Administration Preferences panel. If the Disaster Recovery Plan file is going to be served up by the Reload server, it should be put in a directory off of the /opt/beginfinite/reload/web/custom directory with a unique name of some sort. Here is an example of where ACME put their Disaster Recovery Plan /opt/beginfinite/reload/web/custom/acme_465/acme_dr_plan_secret.pdf When the file is in place, make sure to modify the Disaster Recovery Document URL. This setting is on the Configure tab in the Web Administration Preferences panel. Matching our example document above, the URL would look similar to this: http://reload.acme.com/custom/acme_465/acme_dr_plan_secret.pdf Below is an example Disaster Recovery Plan.
Acme Inc. GroupWise and Reload System Implementation Documentation & Disaster Recovery Plan Document Author: Tay Kratzer, tk@gwava.com 1 P age
Table of Contents Introduction... 4 GroupWise System Overview... 4 GWAVA Reload System Overview... 4 Chicago Office... 5 Production GroupWise System in Chicago... 5 Failover/Redundant GroupWise System in Chicago on Reload Servers... 6 New York Office... 7 Production GroupWise System in New York... 7 Failover/Redundant GroupWise System in New York on a Reload Server... 8 Washington D.C. Office... 9 Production GroupWise System in Washington D.C.... 9 Failover/Redundant GroupWise System in Washington D.C. on a Reload Server 9 Post Office Disaster Recovery Action List... 10 Post Office Disaster Recovery Notes... 10 Domain Disaster Recovery Action List... 12 Domain Disaster Recovery Notes... 12 Domain Administration During Failover... 14 Internet Mail Failover Notes... 14 Procedures After Post Office Disaster Recovery... 15 Post Office Pre-Migration... 15 Monitoring Pre-Migration... 16 Determining Pre-Migration Completion and Success... 18 Post Office Final (Full) Migration... 19 Post Office Final Migration Steps... 21 2 P age
Monitoring Full (Final) Migration... 23 Determining Full Migration Completion and Success... 24 Failback Putting Everything Back to Normal... 25 Procedures After Domain Disaster Recovery... 25 3 P age
Introduction This document is an overview of the existing Novell GroupWise system at Acme Inc. as of March of 2009, and how the GWAVA Reload servers are integrated at Acme Inc. to provide backup and disaster recovery services for GroupWise post offices and domains. The Reload servers have also been leveraged to provide total GroupWise system redundancy by also hosting Internet mail. This document also contains a disaster recovery plan. GroupWise System Overview The GroupWise system is spread amongst three geographical locations Chicago, New York and Washington D.C. In total there are 6 production post offices and 10 production domains. Many of the domains are special purpose domains some of which are located on the GWAVA Reload servers to be used in the case of a failover to the GWAVA Reload servers. GWAVA Reload System Overview There are Reload servers in all three geographical locations. There are three Reload servers in Chicago, one Reload server in New York and one Reload server in Washington D.C. The Reload servers are providing backup, disaster recovery and GroupWise system redundancy for the production GroupWise system. The Reload servers are backing up the GroupWise post offices every two hours between 6 A.M. and 10 P.M. The GroupWise Domains are backed up once a day by Reload. NOTE: All the Reload servers have been configured by Tay Kratzer to allow for graphical sessions to the server via VNC. If ever you cannot VNC to the Reload server then get a Putty session to the Reload server and type in the command: vnc 4 P age
This command will stop and start the VNC server component that allows a VNC client session to the server. The VNC server is listening on port 5955/5855. From a VNC client then the syntax for getting a VNC session is <ip address>:55 Chicago Office The following two tables detail the production GroupWise system in Chicago, and the failover/redundant GroupWise system on the Reload servers in Chicago. Production GroupWise System in Chicago GroupWise Entity [Production Server Name] Description DNS Address IP Address 1. (DOMAIN) AMCHIGWDOM65 [AMCHIGW65] Primary domain servicing two post offices mtaamchigwdom65 10.1.1.27 2. (DOMAIN) AMCHI_GWDOM [AMCHIGW3] 3. (DOMAIN) CHIGWIADOM [AMCHIGWIA] (GWIA Internet Mail) CHIGWIA [AMCHIGWIA] 4. (POST OFFICE) AMCHIGWALUMPO [AMCHIGWALUM] 5. (POST OFFICE) AMCHIGWPO65B [AMCHIGW65B] 6. (POST OFFICE) AMCHI_GWPO [AMCHIGW3] Domain servicing one post office Production GWIA only domain Default GWIA for outbound Internet mail from CHIGWIADOM s MTA GroupWise post office under AMCHIGWDOM65 domain GroupWise post office under AMCHIGWDOM65 GroupWise post office under AMCHI_GWDOM domain mtaamchigwdom 10.1.1.17 mtachigwiadom 10.1.1.13 DNS address not needed for connectivity 10.1.1.13 poaamchigwalumpo 10.1.1.30 poaamchigwpo65b 10.1.1.28 poaamchigwpo 10.1.1.17 5 P age
Failover/Redundant GroupWise System in Chicago on Reload Servers GroupWise Entity [Reload Server Name] Description DNS Address IP Address 1. (DOMAIN) AMCHIGWDOM65 [AMCHIRELOAD1] Primary domain servicing two post offices in Chicago mtaamchigwdom65 (In a failover situation assign this 10.1.2.2 2. (DOMAIN) AMCHI_GWDOM [AMCHIRELOAD3] 3. (DOMAIN) CHIGWIADOM [AMCHIRELOAD1] (DOMAIN) CHIRLDOM1 [AMCHIRELOAD1] (GWIA Internet Mail) CHIRLGWIA [AMCHIRELOAD1] 4.(POST OFFICE) AMCHIGWALUMPO [AMCHIRELOAD3] 5.(POST OFFICE) AMCHIGWPO65B [AMCHIRELOAD2] 6.(POST OFFICE) AMCHI_GWPO [AMCHIRELOAD3] Domain servicing one post office in Chicago Production GWIA only domain Production domain, on the Reload server CHIRLGWIA Alternate GWIA for outbound Internet mail from CHIGWIADOM s MTA GroupWise post office under AMCHIGWDOM65 domain GroupWise post office under AMCHIGWDOM65 domain GroupWise post office under AMCHI_GWDOM domain address) mtaamchigwdom (In a failover situation assign this address) mtachigwiadom (In a failover situation assign this address) DNS address not needed for connectivity DNS address not needed for connectivity poaamchigwalumpo (In a failover situation assign this address) poaamchigwpo65b (In a failover situation assign this address) poaamchigwpo (In a failover situation assign this address) 10.1.2.6 10.1.2.40 10.1.2.40 10.1.2.2 10.1.2.11 10.1.2.3 10.1.2.6 6 P age
New York Office The following two tables detail the production GroupWise system in New York, and the failover/redundant GroupWise system on the Reload server in New York. Production GroupWise System in New York GroupWise Entity [Production Server Name] Description DNS Address IP Address 1.(DOMAIN) AMNYGWDOM65 [AMNY_GW65] Domain servicing one post office in New York and a mtaamnygwdom65 10.6.1.4 (GWIA Internet Mail) NYVMGWIA [AMNYVMGWIA] 2.(POST OFFICE) AMNYGWPO65 [AMNY_GW65] GWIA Default GWIA for outbound Internet mail from AMNYGWDOM65 s MTA GroupWise post office under AMNYGWDOM65 domain DNS address not needed for connectivity 10.6.1.50 poaamnygwpo65 10.6.1.4 7 P age
Failover/Redundant GroupWise System in New York on a Reload Server GroupWise Entity [Reload Server Name] Description DNS Address IP Address 1. (DOMAIN) AMNYGWDOM65 [AMNYRELOAD2] Domain servicing one post office in New York and a GWIA mtaamnygwdom65 (In a failover situation assign this 10.6.1.25 (DOMAIN) NYRLDOM1 [AMNYRELOAD2] (GWIA Internet Mail) NYRLGWIA [AMNYRELOAD2] 2. (POST OFFICE) AMNYGWPO65 [AMNYRELOAD2] Production domain, on the Reload server to allow for the alternate GWIA NYIRLGWIA Alternate GWIA for outbound Internet mail from AMNYGWDOM65 s MTA GroupWise post office under AMNYGWDOM65 domain address) DNS address not needed for connectivity DNS address not needed for connectivity poaamnygwpo65 (In a failover situation assign this address) 10.6.1.25 10.6.1.25 10.6.1.25 8 P age
Washington D.C. Office The following two tables detail the production GroupWise system in Washington D.C., and the failover/redundant GroupWise system on the Reload server in Washington D.C. Production GroupWise System in Washington D.C. GroupWise Entity [Production Server Name] Description DNS Address IP Address 1.(DOMAIN) AMDCGWDOM [AMDCGW] Domain servicing one post office in Washington D.C. and mtaamdcgwdom 10.4.10.14 2.(POST OFFICE) AMDCGWPO [AMDCGW] a GWIA GroupWise post office under AMDCGWDOM domain poaamdcgwpo 10.4.10.14 Failover/Redundant GroupWise System in Washington D.C. on a Reload Server GroupWise Entity [Reload Server Name] Description DNS Address IP Address 1.(DOMAIN) AMDCGWDOM [DCRELOAD] (DOMAIN) DCRLDOM1 [DCRELOAD] (GWIA Internet Mail) DCRLGWIA [DCRELOAD] 2. (POST OFFICE) AMDCGWPO Domain servicing one post office in Washington D.C. and a GWIA Production domain, on the Reload server to allow for the alternate GWIA DCRLWIA Alternate GWIA for outbound Internet mail from AMDCGWDOM s MTA GroupWise post office under mtaamdcgwdom (In a failover situation assign this address) DNS address not needed for connectivity DNS address not needed for connectivity poaamdcgwpo (In a failover 10.4.11.237 10.4.11.237 10.4.11.237 10.4.11.237 9 P age
[DCRELOAD] AMNYGWDOM65 domain situation assign this address) The following procedure explains how to failover to a Reload post office profile in the case of a disaster on a production GroupWise post office. Post Office Disaster Recovery Action List # Action 1. In Reload Web Administration locate the Reload profile that represents the post office that has failed. 2. Click the ambulance button next to the profile. 3. Access the DNS tables and modify the A record associated with the POA for the post office that has failed. Reference the DNS Address and IP Address in column specific to the post office in the Failover/Redundant GroupWise System table. 4. Test client connectivity. Log in as a user on the post office that is now on the Reload server. 5. Test mail flow. Send a message from another post office to the post office that is now hosted on the Reload server and then reply. 6. Notify users as needed. Post Office Disaster Recovery Notes The Reload server performs backups of the production post offices between the hours of 6 A.M. and 10 P.M. on weekdays. In the case of a disaster during the 10 P age
daytime of a weekday, the latest backup will be at most four hours old. The GroupWise clients associated with the post office that is now running on the Reload server will automatically discover the Reload server through the DNS change in step #3 in the Post Office Disaster Recovery Action List. Also, as an alternative POA discovery method, an additional POA has been defined for each post office called RELOAD_POA. If the users have an edirectory authenticated client their GroupWise client can auto-discover the Reload server via the RELOAD_POA object. The GroupWise MTA discovers the existence of the GroupWise POA on the Reload server through DNS. The GroupWise MTA is not as robust as the GroupWise client in discovering the new POA s IP address via the RELOAD_POA object. So if DNS discovery of the GroupWise POA, which is now on the Reload server, is not working for some reason, then a manual change to the IP address of the POA object in ConsoleOne will be necessary. The IP address should then reflect the address for the post office as specified in the column specific to the post office that is in failover as per the Failover/Redundant GroupWise System table. 11 P age
The following procedure explains how to failover to a Reload domain profile in the case of a disaster on a production GroupWise domain. Domain Disaster Recovery Action List # Action 1. In Reload Web Administration locate the Reload profile that represents the domain that has failed. 2. Click the ambulance button next to the profile. 3. Access the DNS tables and modify the A record associated with the MTA for the domain that has failed. Reference the DNS Address and IP Address in column specific to the domain in the Failover/Redundant GroupWise System table. 4. Test message flow between domains. In ConsoleOne, be connected to a domain other than the domain that has failed. Edit the MTA object of the domain, and go to the Agent Settings page. Edit the Attach Retry value and modify it from 600 to 601. Connect to a different domain than the one that you just were connected to and look at the Attach Retry value. When it increments from 600 to 601 then you have confirmed that there is message flow between domains. Domain Disaster Recovery Notes The Reload server performs backups of the production domains once a day. In the case of a disaster, the latest backup of domain database could be slightly out of sync with the rest of the system. Generally this is not an issue, however if there are concerns with the databases accuracy then rebuild the domain. 12 P age
Following are example steps of how you might accomplish this task in a simple fashion: 1. Create the new WPDOMAIN.DB File a. *Rebuilding a Secondary Domain: In ConsoleOne, connect to the primary domain b. *Rebuilding the Primary Domain: In ConsoleOne, connect to a secondary domain c. Highlight the domain to be rebuilt d. Select Tools GroupWise Utilities System Maintenance e. *Rebuilding a Secondary Domain: Select Rebuild Database f. *Rebuilding the Primary Domain: Select Replace Primary with Secondary g. Specify a temporary path to create the WPDOMAIN.DB on the local hard drive of the computer where you are running ConsoleOne h. Select Run to create the wpdomain.db file 2. Temporarily Disable Disaster Recovery Mode for the domain a. From Reload Web Administration, edit the domain profile b. Go to the Disaster Recovery tab and select Failback 3. Transfer the newly created wpdomain.db file to the Reload server housing the domain a. Using WINSCP for example, get connected to the Reload server b. Place the wpdomain.db file in the Reload profile s <profile path>/connect/live directory. NOTE: The profile path can be determined by viewing the Profile Information panel on the Overview tab of the profile in Reload Web Administration. 4. Re-enabled Disaster Recovery Failover for the domain profile a. Click the ambulance button next to the domain profile 13 P age
Domain Administration During Failover When a GroupWise domain is running on the Reload server it is a fully functioning and participating domain in the GroupWise system. Administering changes to a GroupWise domain located on the Reload server is as simple as connecting to some other domain in the system and administering changes to the domain that is running on the Reload server. If there is a need to actually connect to the wpdomain.db on the Reload server for administrative purposes this can be accomplished easily. Each of the Reload servers has ConsoleOne with the GroupWise Snapins installed. And so the domain can be directly administered through ConsoleOne running on the Reload server. Here are example steps for doing so. 1. Load ConsoleOne on the Reload server a. Get a VNC/XWindows session to the Reload server b. Click on the ConsoleOne icon c. Authenticate to edirectory as prompted 2. Connect to the wpdomain.db for the domain that you intend to administer a. In ConsoleOne highlight the GroupWise System object b. Select Tools GroupWise System Operations Select Domain c. For the path to the domain, browse to the Reload profile s <profile path>/connect/live directory. Now the domain which is currently running on the Reload server can be directly administered. Internet Mail Failover Notes Internet mail will automatically flow without any changes to the GroupWise system. The reason for this is because the GroupWise system at Acme Inc. has already been configured to use Alternate GWIAs. Alternate GWIAs are more fully explained in the Chapter 32 of the Novell Press book titled: Novell GroupWise 7 Administrator s Solutions Guide. 14 P age
Procedures After Post Office Disaster Recovery Once a production server is able to host the GroupWise post office that is currently functioning on the Reload server, you will want to migrate the post office to the production server. Following are some example procedures and considerations. Reload has a simple to use Migration Wizard. Reload can migrate GroupWise post offices to any platform. For example, even if a post office was originally established on a NetWare server when Reload backed it up, and you have determined that you would like to migrate the post office to the Linux platform, you may use Reload to do this. In the paragraphs below are high-level procedures and considerations for using Reload for migration when the post office/reload profile is currently in Disaster Recovery mode. Post Office Pre-Migration The Pre-Migration process migrates the contents of the offiles directory from the post office on the Reload server to the post office path on the production server. If an offiles directory already exists, Reload simply migrates right into the existing offiles directory. The only thing that Reload will alter about an offiles directory is that it will rename the sub-directories and files off of the offiles directory to lowercase names. The reason the contents of the offiles directory can be pre-migrated is because the files in the offiles directory (often referred to as BLOBS) don t ever change. What is also important to note is that approximately 90% of the post office size on disk is contained in the offiles directory. So the pre-migration is effectively migrating 90% of the size of the post office. This enables the final/full migration process which is explained later, to go a lot faster. When the Pre-Migration begins and finishes an e-mail notification is sent to whoever is configured to be the Daily Status Report recipient in Reload Administration. Please have someone configured as the Daily Status Report recipient in Reload Administration. From Reload Web Administration configure 15 P age
the recipient under the Configure tab on the front page of Reload Web Administration. Following are example procedures for Post Office Pre-Migration: 1. Establish a production server that will eventually host the GroupWise post office which is currently running on the Reload server. 2. Run Reload Console Administration for the Reload server that is hosting the GroupWise post office. 3. Select Disaster Recovery and select the appropriate post office profile. 4. Select [ MIGRATE ]. NOTE: If the post office is going to be on the Linux platform, you will need to establish an NFS Export on the Linux server you are migrating to. See the Reload documentation for more details on how to do this. 5. Perform the Pre-Migration under Step #1. 6. Monitor the Pre-Migration if you desire, and then determine if the Pre- Migration completed successfully as explained later in this document. Monitoring Pre-Migration The Reload System Event Log and System Agent Log are very helpful in understanding what Reload is doing. To further monitor what is actually happening you might go to the post office location on the production server and observe the contents of the offiles directory. You should see a continual increase of directories and files in the offiles directory over time. If you are even more curious and adventurous you can attempt to telnet to the DBCOPY instance on the Reload server that is performing the migration. This may or may not work for 16 P age
you, but give it a try if you would like. In a terminal session or SSH session to the Reload server type in the following command: telnet localhost 5005 If that command worked, then type in the following directive to DBCOPY: rff This command will cause DBCOPY to report the latest file it has migrated or is currently migrating. Telnet to DBCOPY NOTE: The port that Reload tells DBCOPY to use is based on the port specified in Reload Console Administration under the profile. Edit the profile, select Standard BLOBS Port-Range. It is the beginning port range that DBCOPY will be listening on. 17 P age
Determining Pre-Migration Completion and Success When the Pre-Migration process has completed the Daily Status Report recipients will get an e-mail to this effect. Date and Time: Tue Sep 15 07:15:02 EDT 2009 Message from GWAVA Reload Server: RELOAD2 Report TO Recipient: ec@acme.com Report CC Recipient: tk@gwava.com The Reload Migration job is finished for Profile: CHIPO The Backup That Was Migrated is: [ TUESEP15 ] See the Attached Reload System Event Log for more information about the migration job. Reload Server URL: http://reload2.acme.com:5555 The Reload System Event Log which is sent along with the completion message will also indicate the status of the job. Here is an excerpt from a Reload System Event Log that shows the entire Pre-Migration of a post office: PROFILE: CHIPO - [MIGRATE] Starting Reload Migration Agent PROFILE: CHIPO - [MIGRATE] - Profile: [ CHIPO ] PROFILE: CHIPO - [MIGRATE] Job Type: PRE-MIGRATION of Post Office BLOB Files PROFILE: CHIPO - [MIGRATE] Migrating Backup: [ TUESEP15 ] PROFILE: CHIPO - [MIGRATE] Source Location:.../weeknow/tuesep15 PROFILE: CHIPO - [MIGRATE] Destination Server Type: NetWare Server PROFILE: CHIPO - [MIGRATE] Destination Location: \\nwchi1\data\grpwise\chipo PROFILE: CHIPO - [MIGRATE] Migrating OFFILES Directory Data PROFILE: CHIPO - [MIGRATE] Finished Migrating OFFILES Directory Data PROFILE: CHIPO - [MIGRATE] OFFILES Migration Run Time: 1 Minutes 42 Seconds 18 P age
PROFILE: CHIPO - [MIGRATE] Completed Migration PROFILE: CHIPO - FINISHED MIGRATION JOB FOR PROFILE: [ CHIPO ] PROFILE: CHIPO - TOTAL TIME TO FINISH: 1 Minutes 51 Seconds At the post office path on the production server there should be an offiles directory with approximately 248 subdirectories. If this is not the case for some reason, then troubleshoot the problem and call your technical support contact for Reload if needed. Post Office Final (Full) Migration NOTE: Please read through this entire procedure before performing the Post Office Final (Full) Migration. The Final (Full) Migration process entirely migrates the contents of the post office from the Reload server to the production server. Here is the sequence of events. An instance of DBCOPY is started which migrates only the contents of the OFFILES directory. This instance of DBCOPY will generally not be migrating much data if the pre-migration has already been performed. An instance of DBCOPY is started with migrates the contents of the OFUSER directory. Once the instance of DBCOPY that has migrated the contents of the OFUSER directory is complete, another instance of DBCOPY is started which migrates the contents of the OFMSG directory. Once the instance of DBCOPY that has migrated the contents of the OFMSG directory is complete, if GroupWise Document Management libraries exist at the post office then an instance of DBCOPY will migrate the contents of the GWDMS directory off of the post office. When the migration of the OFMSG directory contents is complete, Reload will send a message to the Daily Status Report recipients. Here is an example of that message: Date and Time: Tue Sep 15 08:11:53 EDT 2009 19 P age
Message from GWAVA Reload Server: RELOAD2 Report TO Recipient: ec@acme.com Report CC Recipient: tk@gwava.com This is a message regarding the Reload Migration job for Profile: CHIPO The Backup Being Migrated is: [ TUESEP15 ] Reload has migrated all of the GroupWise databases for this post office. The migration is not complete, but it is possible that production post office can be started now. Please read the attached Reload System Event Log for more details. Reload Server URL: http://reload2.acme.com:5555 Here is the excerpt from the accompanying System Event Log relative to the migration. PROFILE: CHIPO - [MIGRATE] Starting Reload Migration Agent PROFILE: CHIPO - [MIGRATE] - Profile: [ CHIPO] PROFILE: CHIPO - [MIGRATE] Job Type: FULL MIGRATION of all Post Office Data PROFILE: CHIPO - [MIGRATE] Migrating Backup: [ TUESEP15 ] PROFILE: CHIPO - [MIGRATE] Source Location:.../weeknow/tuesep15 PROFILE: CHIPO - [MIGRATE] Destination Server Type: Local Path PROFILE: CHIPO - [MIGRATE] Destination Location: /data/mig1 PROFILE: CHIPO - [MIGRATE] Migrating OFFILES Directory Data PROFILE: CHIPO - [MIGRATE] Migrating OFUSER Directory Data PROFILE: CHIPO - [MIGRATE] Finished Migrating OFUSER Directory Data PROFILE: CHIPO - [MIGRATE] OFUSER Migration Run Time: 2 Minutes 33 Seconds PROFILE: CHIPO - [MIGRATE] Migrating GWDMS Directory Data PROFILE: CHIPO - [MIGRATE] Finished Migrating GWDMS Directory Data PROFILE: CHIPO - [MIGRATE] DMS Migration Run Time: 1 Minutes 4 Seconds PROFILE: CHIPO - [MIGRATE] Migrating OFMSG Directory Data PROFILE: CHIPO - [MIGRATE] Finished Migrating OFMSG Directory Data 20 P age
PROFILE: CHIPO - [MIGRATE] OFMSG Migration Run Time: 6 Minutes 55 Seconds PROFILE: CHIPO - [MIGRATE] Database Migration Run Time: 10 Minutes 33 Seconds PROFILE: CHIPO - [MIGRATE] The Migration of User Mailboxes Is Mostly Complete PROFILE: CHIPO - [MIGRATE] The BLOBS are Still Being Migrated PROFILE: CHIPO - [MIGRATE] NOTE: If the BLOB files were premigrated, PROFILE: CHIPO - [MIGRATE] Then you may want to just bring up the... PROFILE: CHIPO - [MIGRATE]... production post office Here is the idea that the Reload Migration Agent is trying to convey. If this is actually the Final (Full) Migration job that you are performing, and not a test run, the GroupWise post office is down and not functioning. In some organizations there is a strong need to have the GroupWise post office up and functioning as soon as possible. So the Reload Migration Agent is saying, if you performed the pre-migration, then since the contents of the OFUSER and OFMSG directory have been migrated over, the post office is largely intact on the production server. The only things that are missing are the remaining BLOB files that were added to the OFFILES directory after the Pre-Migration. For some customers getting the post office up and running as soon as possible outweighs having all of the latest BLOBs files intact. If this is the case in your environment, then go ahead and start the post office on the production server, and change the POA s DNS or IP Address as needed in ConsoleOne. The Full Migration process will still continue to run and migrate the final contents of the OFFILES directory. The only potential impact on the users will be that some of their latest e-mails might have attachments or subelements of an e-mail which can t be viewed. The problem will correct itself when the migration is complete, so there is no harm done. Post Office Final Migration Steps NOTE: You might identify some additional steps that are not outlined in this document. Please take care to test your procedural methods before transitioning from the Reload server back over to the production server for good. With the Migration Wizard you can skip steps #2 and #3 that prompt you to disable and unload the Disaster Recovery POA and proceed to step #4. You would do this in order to test and understand how migration works. When you are comfortable 21 P age
with the migration procedure, and are actually ready to perform the Final (Full) Migration then you will want to perform steps #2 and #3 before performing step #4. 1. On the production server, make sure that the GroupWise agent software is installed and configured. This way when Reload has completed the migration of the OFUSER and OFMSG directory contents and if the BLOB files were premigrated to the production server you can load the POA immediately. NOTE: Do not load the POA on the production server now! 2. In Reload Console Administration select Disaster Recovery. 3. Choose the post office to be migrated. 4. Choose the [MIGRATE] menu option. 5. NOTE: Do not perform Step #2 as stated in this step if you are just testing the migration procedure. Choose Step #2, and perform this step. This will tell Reload that even though the Reload profile is still in Disaster Recovery mode, you really do want the Disaster Recovery POA to actually be unloaded, which you are going to do in the next step. 6. NOTE: Do not perform Step #3 as stated in this step if you are just testing the migration procedure. Choose Step #3, and perform this step. This will cause the Disaster Recovery POA to be unloaded. Users will no longer be able connect to the post office once this step has been performed. The idea here is to make sure that no changes are made to the GroupWise post office message store. This way you are guaranteed that no messages are lost. 7. Choose Step #4, and perform this step. This will perform the Full Migration of the post office data to the production server. 22 P age
Monitoring Full (Final) Migration The Reload System Event Log and System Agent Log are helpful in understanding what Reload is doing. The Full Migration should generally not take nearly as long as the Pre-Migration. During a Full Migration there are two separate threads. One thread is migrating databases, indexes and libraries, and the other thread is migrating the BLOBs in the OFFILES directory. To better monitor what is actually happening you might go to the post office location on the production server and observe the contents of the OFUSER and OFMSG directories. You should see a continual increase of files in these directories. If you are even more curious and adventurous you can attempt to telnet to the DBCOPY instance on the Reload server that is performing the migration. This may or may not work for you, but give it a try if you would like. In a terminal session or SSH session to the Reload server type in the commands below: (To Monitor Database File Migration) telnet localhost 5001 (To Monitor BLOBs File Migration) telnet localhost 5005 If either command worked, then type in the following directive to DBCOPY: rff This command will cause DBCOPY to report the latest file it has or is currently migrating. 23 P age
Telnet to DBCOPY NOTE: The instance of DBCOPY that gathers databases uses the port that Reload tells it to use in Reload Console Administration under the profile. Edit the profile, select Standard Database Port-Range. It is the beginning port range that the Database instance of DBCOPY will be listening on. For the instance of DBCOPY that gathers BLOBS files the port that Reload tells DBCOPY to use is based on the port specified in Reload Console Administration under the profile. Edit the profile, select Standard BLOBS Port-Range. It is the beginning port range that the BLOBs instance of DBCOPY will be listening on. Determining Full Migration Completion and Success When the Final Migration process has completed the Daily Status Report recipient will get an e-mail to this effect: Date and Time: Tue Sep 15 07:55:54 EDT 2009 24 P age
Message from GWAVA Reload Server: RELOAD2 Report TO Recipient: ec@acme.com Report CC Recipient: tk@gwava.com The Reload Migration job is finished for Profile: BEG2PO The Backup That Was Migrated is: [ TUESEP15 ] See the Attached Reload System Event Log for more information about the migration job. Reload Server URL: http://reload2.acme.com:5555 Once the migration is complete, you can load the GroupWise POA on the production server. You then will want to change the POA's DNS address or IP Address in ConsoleOne to allow for both GroupWise client and GroupWise MTA connectivity to the POA that is now running on the production server. Failback Putting Everything Back to Normal Once you are assured that the post office is up and running just fine on the production server, make sure to do a FAILBACK of the Reload post office profile. This can be done in the Reload Console or Web Administration. The FAILBACK option is under the Disaster Recovery section of Reload Administration. Once the Failback has been performed, the post office profile will resume its normal backup routines etc. Procedures After Domain Disaster Recovery Once a production server is able to host the GroupWise domain that is currently functioning on the Reload server you will want to migrate the domain to the production server. Following are some example procedures and considerations. 1. Reload has a Migration Wizard which will migrate the GroupWise domain directory and it s contents to a production server. Simply follow the procedures for the migration. To get to the Migration Wizard go to the Disaster Recovery menu in Reload Console Administration, and select the 25 P age
domain to be migrated. Then choose the [MIGRATE] menu choice. The migration process is extremely straight forward and it only takes a couple of minutes from start to finish. 2. Install and configure the GroupWise agent software on the production server that will host the GroupWise domain. Once the migration is complete, you can load the GroupWise MTA on the production server. You then will want to change the MTA's DNS address or change the IP Address in ConsoleOne to allow both GroupWise POA and MTA connectivity to the MTA that is now running on the production server. Make sure to FAILBACK the Reload domain profile. This can be done in the Reload Console or Web Administration. Once the Failback has been performed, the domain profile will resume its normal backup routines etc. 26 P age