IBM Connections 백업 과 복구

IBM Connections 백업 & 복구

IBM Connections 란 솔루션에서의 백업과 복구에 대한 설명 글입니다.

모든 솔루션에서 그리고 기업용 솔루션에서 중요한 부분이 백업과 복구입니다.

어느시점에 백업이 됐던 백업된 시점으로 자연스럽고 빠르게 복구가 되어야 하고

백업 역시 손쉽게 될수록 좀더 안정적인 서비스를 할수 있는 구조라고 생각합니다.

그런 의미에서 IBM Connections는 백업과 복구를 제공하지만 수동작업이 있는 측면이 불편한 요소입니다.

또한 백업시 DB와 파일 스토리지를 별도로 백업해야되는것 역시 불편한 사항입니다.

물론, 이런 백업과 복구를 쉽게 해주는 솔루션이 별도로 있는것 같지만, 그렇다고 해도 불편한건 불편한거죠 

아래 솔루션에서의 백업과 복구 단계 순서가 정리된 내용입니다.

참고하세요

1. Backup & Restore Data

1.1 backup

백업 솔루션에서 가이드하는 방법에 따라 백업을 수행합니다.

Application에서 사용하는 database와 content store를 모두 백업 해야 합니다. content store는 file과 entry가 저장되는 공간을 의미합니다.

백업 대상은 아래와 같습니다.

- Database

- Content Store

- Configuration files

백업은 Database를 제일 먼저 해야 하고 나머지는 순서 없이 하면 됩니다.

1) Database backup

아래 Database를 백업합니다.

OPNACT,BLOGS,SNCOMM,DOGEAR,FILES,FORUM,HOMEPAGE,METRICS,COGNOS,MOBILE,PEOPLEDB,WIKIS

DB2 사용시 백업 방법은 여기를 참조하십시오.

혹시, Symentec backup exec를 사용하여 백업한다면 여기를 참조하십시오.

Metrics Database에 대한 백업은 IC_Administration(Metrics).odt의 4장을 참조하십시오.

 

2) Content store backup

Content store는 Local content store와 Shared content store가 있습니다.

Local content store는 Local Disk에 생성되고, shared content store는 공유 Disk에 생성됩니다.  아래 Table을 참고하여 백업 합니다.

 

Shared content store

shared_content_store/news/search/indexReplication shared_content_store/search/dictionary shared_content_store/search/stellent/dcs/oiexport/exporter shared_content_store/audit shared_content_store/activities/content shared_content_store/activities/statistics shared_content_store/blogs/upload shared_content_store/communities/statistics shared_content_store/customization shared_content_store/dogear/favorite shared_content_store/files/upload shared_content_store/forums/content shared_content_store/profiles/statistics shared_content_store/wikis/upload     앱별 추가 백업 대상 1) Files : <files.storage.rootDirectory>/files/ 하위 디렉토리 전체 2) Activities   Activities에 content store를 추가한 경우(oa-config.xml의 store항목에 정의)에는 그 content store들도 백업합니다. 3) Search:   - IC_Administration(Search).odt의 3장 > 14.Backup 및 Restore를 참고하십시오.   - 주) Search앱의 백업Task가 local_content_store/search/index 디렉토리를 local_content_store/search/backup디렉토리로 백업하는것 같음. 만약 그렇다면 Search index 백업Task를 이용하거나  local_content_store/search/index 디렉토리만 백업해야 함

 

Local content store

local_content_store/news/search/index local_content_store/profiles/cache local_content_store/search/backup local_content_store/search/index 주) local content store는 더 있는것 같은데 도움말에 없음. 프로젝트 시 추가로 list-up 필요

 

3) Configuration files

- LotusConnections-config.xml

- 각 앱별 환경설정 파일을 백업:forum-config.xml, profiles-config.xml, files-config.xml, search-config.xml, metrics-config.xml,  mobile-config.xml,  wikis-config.xml, dogear-config-cell.xml, news-config.xml,  communities-config.xml, oa-config.xml, notification-config.xml, contentreview-config.xml, widget-config.xml, calendar-config.xml

 

주)

- oa-config.xml : Activities

- dogear-config-cell.xml : Bookmarks

- notification-config.xml: Blog email통보 설정

- contentreview-config.xml : Blogs pre-moderation 설정

- widget-config.xml: 커뮤니티의 위젯(예:북마크, 파일 등) 설정

- calendar-config.xml: 커뮤니티 이벤트 설정

 

※ 주) 이 이외에도 백업 대상이 더 있을것임(예: WAS, HTTP 환경설정 파일들). 프로젝트를 수행하면서 list-up하여 보완해야 할것임

 

1.2 Restore

1.2.1 Search앱 restore : IC_Administration(Search).odt의 3장 > 14. Backup 및 Restore참조

 

1.2.2 Activities앱 Restore : IC_Administration(Activities).odt의 4장 > 3. Activities 데이터 백업 & Restore 참조

 

1.2.3 Metrics 앱 Restore : IC_Administration(Metrics).odt의 4장 참조

 

 

1.2.4 Communities앱 Restore

bookmark, member, feed widget은 community 데이터베이스가 관리하나, 그외의 widget들은 각각 독립적인 database를 갖고 있습니다. 이로 인해 restore이후에 community 데이터베이스와 각 독립 database간에 sync를 맞춰주는 작업이 필요합니다.

1) 사용자 접근 차단

- maintenance page: upgrading.htm을 수정

- httpd.conf파일에서 운영자와 서버외의 모든 접근 차단

<Location / > Order Deny,Allow Deny from all Allow from <your.ip.address> Allow from <ip.of.each.machine.in.deployment> </Location>

- Restart http server

2)  schedule task 일시 중지

CommunitiesScheduler.pauseSchedulingTask("LifecycleRetryQueuedEvents") 수행

3) queue에 있는 task clear

- wsadmin client 실행

- execfile("communitiesAdmin.py")

만약, 커뮤니티 어플리케이션은 정상이고 나머지 어플만 장애가 난 경우라면

 CommunitiesQEventService.clearQueuedEventsByRemoteAppDefId("remoteAppDefId")

remote application id는 여기 열고 Table1 참조

만약, 모두 장애가 났다면 CommunitiesQEventService.clearQueuedEventsByResourceType("community")

4) 커뮤니티와 연관된 Activities, Blogs, Files, Forums, News, Wikis와의 동기화를 위한 report를 만들어 냅니다.

- execfile("<application_name>Admin.py") 와 xxxService.exportSyncedResourceInfo(String filePath, String eventType) 명령어를 실행합니다. 자세한 방법은 여기의 Table2를 참조 합니다.

- CommunitiesRemoteAppService.generateSyncReports("syncedResourceInfoFilepath", "outputDirPath")을 실행합니다. 첫번째 파라미터는 바로 전 명령의 결과 파일이고 두번째는 결과 report가 생성될 디렉토리입니다. 결과 디렉토리에는 communityDifferences와 orphanedRemoteApplications  두개의 파일이 생성됩니다.

5) 중지되었던 스케쥴 작업을 다시 실행

CommunitiesSchedulerService.resumeSchedulingTask("LifecycleRetryQueuedEvents")

6) 사용자 접근 차단 해제: httpd.conf에 추가하였던 Location구문 삭제 or remark

7) 커뮤니티와 연관 어플리케이션간의 sync 강제 수행:

- CommunitiesRemoteAppService.resyncRemoteAppsForCommunity

- 특정 entry를 커뮤니티에 assign할 수도 있음: CommunitiesRemoteAppService.assignRemoteApp("remoteAppDefId", "objectIdentifyingId", "oldCommunityUuid", "newCommunityUuid", "uiLocation") 세부사항은 여기의 Table1 참조

 

8) Files sync 수행 : FilesDataIntegrityService.syncAllCommunityShares()

9) member 권한 sync : AccessControlService.syncAllCommunityShares()

10) orphanedRemoteApplications 파일에 대한 조치

- 데이터 유지 하려면 :CommunitiesRemoteAppService.assignRemoteApp

- 데이터 삭제 하려면: 여기를 참고하여 각 데이타별로 삭제