KR20110040591A - 백업 서버 및 그 방법 - Google Patents

백업 서버 및 그 방법 Download PDF

Info

Publication number
KR20110040591A
KR20110040591A KR1020090097925A KR20090097925A KR20110040591A KR 20110040591 A KR20110040591 A KR 20110040591A KR 1020090097925 A KR1020090097925 A KR 1020090097925A KR 20090097925 A KR20090097925 A KR 20090097925A KR 20110040591 A KR20110040591 A KR 20110040591A
Authority
KR
South Korea
Prior art keywords
server
schema
servers
backup
hss
Prior art date
Application number
KR1020090097925A
Other languages
English (en)
Inventor
양태호
Original Assignee
서울통신기술 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 서울통신기술 주식회사 filed Critical 서울통신기술 주식회사
Priority to KR1020090097925A priority Critical patent/KR20110040591A/ko
Publication of KR20110040591A publication Critical patent/KR20110040591A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 발명은 주기적으로 복수의 서버들의 데이터를 백업하는 백업 서버 및 그 방법에 있어서, 특히 상기 복수의 서버들로부터 주기적으로 각각의 데이터베이스(DB) 및 스키마를 다운 받아 백업하고 백업된 상기 각각의 DB를 즉시 이용할 수 있도록 상기 각각의 DB의 맞는 스키마를 이용하여 상기 각각의 DB를 로딩을 하는 것을 특징으로 하는 백업 서버 및 그 방법에 대한 것이다.
HSS(Home subscriber server), HSS Back-up Server, DB, 스키마

Description

백업 서버 및 그 방법{Back-up server and method thereof}
본 발명은 네트워크 시스템에 있어서 복수의 서버들의 백업 기능을 수행 하는 백업 서버 및 그 방법에 관한 것으로, 보다 상세하게는 복수의 서버들의 DB를 주기적을 백업하고 장애가 발생한 서버의 환경을 즉시에 구축하여 장애가 발생한 서버의 기능을 즉시 대체하는 백업 서버 및 그 방법에 관한 것이다.
종래의 백업 서버는 동작 서버로부터 자료를 다운 받아 저장하고, 동작 서버에 장애가 발생한 경우에, 저장된 자료를 가지고 동작 서버의 기능을 대체하였다. 그러나 백업 서버가 장애가 발생한 서버의 기능을 대체 하기 위해서는 장애가 발생한 이후에 장애가 발생한 서버의 시스템 환경을 구축하기 위한 많은 시간이 소요된다. 따라서 장애가 발생한 서버가 담당하는 가입자들의 서비스 제공이 장시간 중단되는 문제가 있다.
본 발명은 종래의 문제점을 해결하기 위하여 백업 서버는 장애가 발생한 서버로부터 자료 및 자료를 즉시 이용할 수 있는 스키마를 동시에 수신하여 스키마에 다라 자료를 백업하고 장애가 발생한 경우에 백업 서버가 즉시 장애가 발생한 서버의 기능을 대체하도록 하는 백업 서버 및 그 방법을 제공하는데 목적이 있다.
본 발명의 다른 목적들은 이하의 실시예에 대한 설명을 통해 쉽게 이해될 수 있을 것이다.
본 발명의 일 측면에 따르면, 주기적으로 복수의 서버들의 데이터를 백업하는 백업 서버에 있어서, 상기 복수의 서버들로부터 주기적으로 각각의 데이터베이스(DB) 및 스키마를 다운 받아 백업하고, 상기 각각의 DB의 맞는 스키마를 이용하여 상기 각각의 DB를 로딩을 하는 것을 특징으로 하는 백업 서버가 제공된다.
여기서, 상기 복수의 서버들은 HSS(Home subscriber server)로서 가입자들의 정보를 가지고 있는 서버인 것을 특징으로 할 수 있다.
여기서, 상기 복수의 서버들의 각각의 상기 DB 및 상기 스키마를 백업하고 로딩하는 저장장치를 더 포함하고 있는 것을 특징으로 할 수 있다.
여기서, 상기 저장장치에는 상기 복수의 서버들의 각각의 상기 DB 및 상기 스키마가 구분되어 저장되는 것을 특징으로 할 수 있다.
여기서, 상기 백업 서버는 상기 복수의 각각의 DB 및 상기 스키마의 백업 결과 및 상기 DB 로딩 결과를 운용 터미널로 전송하고, 상기 운용 터미널로부터 상기 복수의 서버 중 장애가 발생한 서버를 대체하는 명령을 수신하는 경우에 상기 로딩된 DB를 이용하여 상기 장애가 발생한 서버를 대체 하는 것을 특징으로 할 수 있다.
또한, 백업 서버의 복수의 서버들의 데이터를 백업하는 방법에 있어서, 복수의 서버들로부터 각각의 데이터베이스(DB) 및 스키마를 다운 받는 단계와 상기 다운 받은 DB 및 상기 스키마를 백업하는 단계와 상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계 및 상기 운용 터미널로부터 장애가 발생한 서버를 대체하는 명령을 수신하는 경우에 상기 장애가 발생한 서버의 상기 로딩된 DB를 이용하여 해당 서버를 대체하는 단계를 포함하는 것을 특징으로 하는 백업 서버 방법이 제공된다.
여기서, 상기 복수의 서버들로부터 각각의 DB 및 상기 스키마를 다운 받는 단계는 상기 백업 서버와 상기 복수의 서버들간에 주기적으로 행해지는 것을 특징으로 할 수 있다.
여기서, 상기 백업 서버가 주기적으로 상기 복수의 서버들의 DB와 스키마를 전송 요청하고 상기 복수의 서버들은 상기 전송 요청에 응답하여 자신의 DB 및 상기 스키마를 상기 백업 서버로 전송하는 것을 특징으로 할 수 있다.
여기서, 상기 백업 서버가 상기 복수의 서버들의 DB와 상기 스키마를 주기적으로 상기 백업 서버로 전송하도록 요청을 하면, 상기 복수의 서버들은 상기 백업 서버가 설정한 주기에 맞게 자신의 DB 및 스키마를 상기 백업 서버로 전송하는 것을 특징으로 할 수 있다.
여기서, 상기 백업된 결과를 운용 터미널에 보고하는 단계 및 상기 DB의 로딩 결과를 상기 운용 터미널에 보고하는 단계를 더 포함하는 것을 특징으로 할 수 있다.
여기서, 상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계는 상기 백업 서버에 상기 복수의 서버들에 상응하는 디렉토리가 존재하여 상기 디렉토리에 상기 복수의 서버들의 해당 DB를 해당 스키마에 맞도록 로딩하는 것을 특징으로 할 수 있다.
여기서, 상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계는 상기 로딩에 성공하는 경우는 새로운 DB를 이용하여 로딩하고 상기 로딩에 실패하는 경우는 이전 DB를 유지하는 것을 특징으로 할 수 있다.
여기서, 상기 장애가 발생한 서버의 환경을 즉시 구축하여 해당 서버를 대체하는 단계는 상기 백업 서버에 상기 장애가 발생한 서버의 IP 및 상기 장애가 발생한 서버의 프로세서가 로딩되어 상기 백업 서버가 상기 장애가 발생한 서버를 대체하는 것을 특징으로 할 수 있다.
여기서, 상기 복수의 서버들은 HSS(Home subscriber server)로서 가입자들의 정보를 가지고 있는 서버인 것을 특징으로 할 수 있다.
본 발명에 따르면, 백업 서버에서 복수의 서버에 대한 DB 및 각 시스템 환경을 구분하여 저장하고 DB를 로딩된 상태를 유지함으로써 장애가 발생한 경우에 DB 로딩에 필요한 시간 소요 없이 즉시 장애가 발생한 서버를 대체 할 수 있는 효과가 있다.
또한 주기적으로 동작 서버들로부터 DB 및 스키마를 수신하여 이를 백업하므로 장애가 발생한 경우에 최신 DB를 가지고 대체 기능을 수행 할 수 있는 효과가 있다.
본 발명은 다양한 변환을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변환, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
본 발명에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 제1 및 제2 등의 표현은 발명을 보다 상세히 표현하기 위한 수단일 뿐 발명을 상기 표현으로 발명이 한정되지 않는다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
이하, 본 발명의 실시예를 첨부한 도면들을 참조하여 상세히 설명하기로 한다.
도1은 본 발명의 일 실시예로서 본 발명의 백업 서버를 이용한 시스템 구성을 나타낸 도면이다.
본 발명의 백업 서버를 이용한 시스템 구성은 가정 가입자 서버들(100,200)과 HSS(Home Subscriber Server) Back-up Server(300) 및 운용 터미널(400)구성될 수 있다.
홈 가입자 서버(Home Subscriber Server; HSS - 이하 HSS 로 표기)들(100,200)은 주기적으로 DB(Data Base)와 스키마(Schema)를 HSS Back-up Server(300)로 전송한다.
여기서 HSS 서버는 가입자 정보를 가지고 있는 서버로 서비스 가입자들의 정보를 가지고 있어 서비스 공급자(Provider)가 서비스를 제공할 때 필요한 가입자들의 정보를 가지고 있는 서버를 의미한다.
여기서 스키마(Schema)란 DB에서는 DB를 논리적으로 정의한 것을 나타내는 것으로 DB에 어떤 구조로 데이터가 저장되어 있는가를 나타낸 DB 구조를 의미한다. 스키마는 DB를 관리하거나 운용하는데 있어서 매우 중요하므로 데이터사전에 저장되어 있다. 또한 스키마에는 외부 스키마, 내부 스키마, 개념 스키마가 존재하고 각 스키마 사이에는 사상(Mapping)이 성립되어 외부 스키마와 개념 스키마 사이에는 외부/개념 사상이 이루어지고 개념 스키마와 내부 스키마 사이에는 개념/내부 사상이 이루어지며 데이터의 논리적 독립성 및 물리적 독립성을 구현하는데 아주 중요한 역할을 수행한다. 즉 스키마란 DB를 저장하고 운용하는 데 필요한 패키지 및 시스템 환경(configuration)을 의미한다.
외부 스키마는 DB 전체 중에서 개개 사용자나 응용 프로그램에서 필요로 하는 개체와 관계에 대하여 정의한 것을 의미한다. 때로는 전체 DB의 논리적 일부분이 된다는 의미에서 서브 스키마 또는 DB를 들여다 보는 창이라는 의미에서 View 라고도 한다. 따라서 사용자의 수나 응용 프로그램의 수만큼 많은 외부 스키마가 존재 할수 있다. 외부 스키마를 통해 DB에 접근할 수 있으므로 DB에 대한 외부로부터의 접근 통로구실을 한다.
개념 스키마는 조직체 전체를 관장하는 입장에서 DB를 정의한 것이다. 따라서 조직체의 모든 용용 시스템에서 필요로 하는 모든 개체와 그 관계, 및 제약조건들을 포함해야 한다. 즉, DB를 효율적으로 관리하는데 필요한 접근권한, 보안정책, 무결성 규칙 등에 관한 사항들도 추가적으로 포함하고 있다. 따라서 일반적으로는 스키마는 개념 스키마를 의미한다. 개념 스키마는 DB전체에 대해 기술한 것이기 때문에 하나만 존재한다.
내부 스키마는 물리적 저장 장치의 입장에서 DB가 저장되는 방법을 기술한 것이다. 구체적으로는 개념 스키마는 디스크 기억장치에 물리적으로 구현하기 위한 방법을 기술한 것으로서 실제 저장될 내부 레코드의 형식, 내부 레코드의 물리적 순서, 인덱스의 유/무 등에 관한 것이다. 하지만 실제의 DB는 내부 스키마에 의해 곧바로 구현되는 것이 아니라 내부 스키마에서 기술한 내용에 따라 운영체제의 파 일 시스템에 의해 물리적 저장장치에 기록이 된다.
본 발명에서 의미하는 스키마는 상술한 모든 스키마들을 포함하는 것을 말한다. 따라서 HSS들(100,200)은 주기적으로 가입자 정보 DB 및 DB에 대한 스키마를 HSS Back-up Server(300)로 전송한다.
HSS Back-up Server(300)는 수신한 HSS(100,200)의 DB를 저장하고 각각의 스키마에 따라 로딩한다.
HSS Back-up Server(300)는 운용 터미널(400)으로 각각 HSS(100,200)의 DB의 저장(백업) 결과 및 스키마를 이용하여 로딩한 결과를 전송한다.
운용 터미널(400)은 원격지에서 HSS(100,200)의 운용을 담당하고 있으며, HSS Back-up Server(300)로부터 각각의 HSS(100,200)의 백업 결과를 수신하고 있어 HSS(100,200) 중 어느 하나 이상의 HSS에 이상이 생긴 경우에 HSS Back-up Server(300)에 저장되고 로딩되어 있는 이상인 생긴 HSS의 DB를 이용하여 즉시 해당 HSS의 기능을 대체하도록 할 수 있다.
도2는 HSS Back-up Server의 각 HSS 시스템 DB의 백업 구조를 나타낸 도면이다.
HSS Back-up Server(300)는 저장장치를 포함하고 있어 저장장치에 각각의 HSS의 DB를 디렉토리로 구분하여 백업하고 로딩한다.
HSS의 DB는 저장장치의 서로 다른 디렉토리(301,302,...,30n)에 백업되고 로딩된다.
HSS Back-up Server(300)는 또한 복수의 저장장치를 포함할 수 있어 각각의 저장장치에 서로 다른 HSS의 DB를 백업하고 로딩한다. 이 경우 도면에서 도시된 HSS1 디렉토리(301), HSS2 디렉토리(302), ...,HSSn 디렉토리(30n)은 하나의 저장장치 일수 있다.
도2에 도시한 바와 같이 HSS Back-up Server(300)는 서로 다른 저장장치 또는 저장역역(디렉토리)에 서로 다른 HSS의 DB를 저장하고 서로 다른 HSS의 스키마-패키지 및 시스템 환경(configuration-이하 config로 표시함)-를 이용하여 DB를 로딩을 한다.
따라서 HSS에 장애가 발생한 경우 HSS Back-up Server(300)의 해당 HSS의 DB가 백업되고 해당 HSS의 스키마로 로딩되어 있는 HSS 디렉토리에 접근하여 활성화 시킴으로 즉시 장애가 발생한 해당 HSS를 대체 할 수 있다.
도3은 HSS Back-up Server의 각 HSS 시스템 백업 과정을 나타낸 도면이다.
S100 단계는 각각의 HSS(100,200)는 주기적으로 DB 및 스키마를 HSS Back-up Server(300)로 전송하는 단계이다. 각각의 HSS(100,200)의 가입자 정보 및 그 외 데이터를 포함하고 있는 DB는 시간이 지남에 따라 업그레이드되므로 각각의 HSS(100,200)는 주기적으로 업그레이드된 DB를 HSS Back-up Server(300)로 전송한다. 여기서 주기는 특정한 주기일 수 있으며 HSS의 DB가 업그레이드되는 시점일 수 있다. 또한 HSS Back-up Server(300)가 주기적으로 HSS 서버들의 DB와 스키마를 전송하도록 요청하거나 특정 주기를 설정하고 설정 주기에 맞게 HSS 서버들의 DB와 스키마를 전송하도록 요청할 수 있다. HSS는 전송 요청에 응답하여 자신의 DB 및 스키마를 HSS Back-up Server(300)로 전송할 수 있다.
S110 단계는 HSS Back-up Server(300)가 복수의 서버들로부터 각각의 데이터베이스(DB) 및 스키마를 다운 받아 DB를 각각의 저장영역에 백업하고 DB의 백업 결과를 운용 터미널(400)로 보고하는 단계이다.
S120 단계는 HSS Back-up Server(300)가 수신한 각각의 HSS의 DB를 해당 HSS의 스키마에 따라 로딩하고 이를 판단하는 단계이다. 즉 HSS Back-up Server(300)의 특정 영역 또는 특정 저장장치에 해당 HSS의 DB를 해당 HSS의 스키마에 따라 구축하는 기능을 수행하고 수행 결과가 제대로 되었는지를 판단하는 단계이다.
만일 판단 결과 해당 DB가 제대로 로딩(구축)에 성공하면, 지금 새롭게 로딩한 DB를 유지하는 S140 단계로 진행하고, 해당 DB의 로딩(구축)에 성공하지 못하는 경우에는 이전에 로딩되어 있는 DB를 유지하는 S130 단계로 진행한다.
HSS Back-up Server(300)는 HSS로부터 주기적으로 수신하고 백업한 DB를 해당 HSS의 스키마에 따라 로딩하나 HSS로부터의 DB 수신과정에서 이상이 있거나, 수신한 DB를 해당 HSS의 스키마에 따라 로딩시 에러로 인해서 DB의 로딩이 제대로 이루어지지 않는 경우가 발생할 수 있다. 이때는 에러가 난 DB는 무시하고 이전 로딩되어 있는 DB를 유지하는 것이 바람직하다.
S150 단계는 HSS Back-up Server(300)가 DB의 로딩 결과를 운용 터미널(400)로 보고하는 단계이다. 운용 터미널(400)은 장애가 발생한 경우에 S150 단계에서 수신한 DB 로딩 결과를 가지고 해당 HSS를 대체하는 명령을 HSS Back-up Server(300)로 전송한다.
HSS Back-up Server(300)는 S150 단계 이전까지는 복수의 서버들의 해당 동작 환경과 동일한 환경으로 DB를 로딩하여 어느 하나 이상의 서버에서 장애가 발생한 경우에 해당 서버의 DB를 로딩하기 위한 시간 소요를 줄일 수 있다.
도4는 장애가 발생한 HSS 시스템을 기동하는 과정을 나타낸 도면이다.
S200단계는 특정 HSS에 장애가 발생한 경우에 운용 터미널(400)이 장애가 발생한 HSS를 대체하도록 하는 명령을 HSS Back-up Server(300)로 전송하는 단계이다.
S210단계는 HSS Back-up Server(300)가 장애가 발생한 HSS의 환경을 즉시 구축하여 장애가 발생한 HSS를 대체하는 단계이다. Back-up Server(300)는 운용 터미널(400)로부터 장애가 발생한 HSS를 대체하도록 하는 명령을 수신하면, 해당 HSS 의 데이터가 로드되어 있는 백업된 DB를 로딩하고, 장애가 발생한 HSS의 IP를 로딩하고, 장애가 발생한 HSS의 프로세서를 로딩한다.
S210단계를 거치면 HSS Back-up Server(300)는 장애가 발생한 HSS의 기능을 즉시 수행 가능하여 대체 기능을 수행 할 수 있다.
S220단계는 HSS Back-up Server(300)가 S210단계에서 수행한 대체 HSS 로딩 결과를 운용 터미널(400)로 보고하는 단계이다.
상기에서는 본 발명의 실시예를 참조하여 설명하였지만, 해당 기술 분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.
도1은 본 발명의 일 실시예로서 본 발명의 백업 서버를 이용한 시스템 구성을 나타낸 도면이다.
도2는 HSS Back-up Server의 각 HSS 시스템 DB의 백업 구조를 나타낸 도면이다.
도3은 HSS Back-up Server의 각 HSS 시스템 백업 과정을 나타낸 도면이다.
도4는 장애가 발생한 HSS 시스템을 기동하는 과정을 나타낸 도면이다.
<도면의 주요부분에 대한 부호의 설명>
100, 200 : HSS(Home Subscriber Server)
300 : HSS(Home Subscriber Server) Back-up Server
400 : 운용 터미널

Claims (14)

  1. 주기적으로 복수의 서버들의 데이터를 백업하는 백업 서버에 있어서,
    상기 복수의 서버들로부터 주기적으로 각각의 데이터베이스(DB) 및 스키마를 다운 받아 백업하고, 상기 각각의 DB의 맞는 스키마를 이용하여 상기 각각의 DB를 로딩을 하는 것을 특징으로 하는 백업 서버.
  2. 제1항에 있어서,
    상기 복수의 서버들은 HSS(Home subscriber server)로서 가입자들의 정보를 가지고 있는 서버인 것을 특징으로 하는 백업 서버.
  3. 제1항에 있어서,
    상기 복수의 서버들의 각각의 상기 DB 및 상기 스키마를 백업하고 로딩하는 저장장치를 더 포함하고 있는 것을 특징으로 하는 백업 서버.
  4. 제3항에 있어서,
    상기 저장장치에는 상기 복수의 서버들의 각각의 상기 DB 및 상기 스키마가 구분되어 저장되는 것을 특징으로 하는 백업 서버.
  5. 제1항에 있어서,
    상기 백업 서버는 상기 복수의 각각의 DB 및 상기 스키마의 백업 결과 및 상기 DB 로딩 결과를 운용 터미널로 전송하고, 상기 운용 터미널로부터 상기 복수의 서버 중 장애가 발생한 서버를 대체하는 명령을 수신하는 경우에 상기 로딩된 DB를 이용하여 상기 장애가 발생한 서버를 대체 하는 것을 특징으로 하는 백업 서버.
  6. 백업 서버의 복수의 서버들의 데이터를 백업하는 방법에 있어서,
    복수의 서버들로부터 각각의 데이터베이스(DB) 및 스키마를 다운 받는 단계;
    상기 다운 받은 DB 및 상기 스키마를 백업하는 단계;
    상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계; 및
    상기 운용 터미널로부터 장애가 발생한 서버를 대체하는 명령을 수신하는 경우에 상기 장애가 발생한 서버의 상기 로딩된 DB를 이용하여 해당 서버를 대체하는 단계를 포함하는 것을 특징으로 하는 백업 서버 방법.
  7. 제6항에 있어서,
    상기 복수의 서버들로부터 각각의 DB 및 상기 스키마를 다운 받는 단계는 상기 백업 서버와 상기 복수의 서버들간에 주기적으로 행해지는 것을 특징으로 하는 백업 서버 방법.
  8. 제7항에 있어서,
    상기 백업 서버가 주기적으로 상기 복수의 서버들의 DB와 스키마를 전송 요청하고 상기 복수의 서버들은 상기 전송 요청에 응답하여 자신의 DB 및 상기 스키마를 상기 백업 서버로 전송하는 것을 특징으로 하는 백업 서버 방법.
  9. 제7항에 있어서,
    상기 백업 서버가 상기 복수의 서버들의 DB와 상기 스키마를 주기적으로 상기 백업 서버로 전송하도록 요청을 하면, 상기 복수의 서버들은 상기 백업 서버가 설정한 주기에 맞게 자신의 DB 및 스키마를 상기 백업 서버로 전송하는 것을 특징으로 하는 백업 서버 방법.
  10. 제6항에 있어서,
    상기 백업된 결과를 운용 터미널에 보고하는 단계; 및
    상기 DB의 로딩 결과를 상기 운용 터미널에 보고하는 단계를 더 포함하는 것을 특징으로 하는 백업 서버 방법.
  11. 제6항에 있어서,
    상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계는 상기 백업 서버에 상기 복수의 서버들에 상응하는 디렉토리가 존재하여 상기 디렉토리에 상기 복수의 서버들의 해당 DB를 해당 스키마에 맞도록 로딩하는 것을 특징으로 하는 백업 서버 방법.
  12. 제6항에 있어서,
    상기 백업된 DB를 해당 스키마에 맞게 로딩하는 단계는 상기 로딩에 성공하는 경우는 새로운 DB를 이용하여 로딩하고 상기 로딩에 실패하는 경우는 이전 DB를 유지하는 것을 특징으로 하는 백업 서버 방법.
  13. 제6항에 있어서,
    상기 장애가 발생한 서버의 환경을 즉시 구축하여 해당 서버를 대체하는 단계는 상기 백업 서버에 상기 장애가 발생한 서버의 IP 및 상기 장애가 발생한 서버 의 프로세서가 로딩되어 상기 백업 서버가 상기 장애가 발생한 서버를 대체하는 것을 특징으로 하는 백업 서버 방법.
  14. 제6항에 있어서,
    상기 복수의 서버들은 HSS(Home subscriber server)로서 가입자들의 정보를 가지고 있는 서버인 것을 특징으로 하는 백업 서버 방법.
KR1020090097925A 2009-10-14 2009-10-14 백업 서버 및 그 방법 KR20110040591A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020090097925A KR20110040591A (ko) 2009-10-14 2009-10-14 백업 서버 및 그 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020090097925A KR20110040591A (ko) 2009-10-14 2009-10-14 백업 서버 및 그 방법

Publications (1)

Publication Number Publication Date
KR20110040591A true KR20110040591A (ko) 2011-04-20

Family

ID=44046937

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020090097925A KR20110040591A (ko) 2009-10-14 2009-10-14 백업 서버 및 그 방법

Country Status (1)

Country Link
KR (1) KR20110040591A (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015111856A1 (ko) * 2014-01-21 2015-07-30 신철우 전자 투표 시스템 및 방법

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015111856A1 (ko) * 2014-01-21 2015-07-30 신철우 전자 투표 시스템 및 방법

Similar Documents

Publication Publication Date Title
US10387451B2 (en) Synchronization system for multiple client devices
US9239767B2 (en) Selective database replication
RU2595482C2 (ru) Обеспечение прозрачной отработки отказа в файловой системе
US7680910B2 (en) System and method for efficient transfer of applications and data during device swap
US10116764B1 (en) Method for state based snapshot difference with restart capability
US20070208782A1 (en) Updating of Data Processing and Communication Devices
CN107483241B (zh) 一种在网元升级过程中下载升级镜像版本的方法和装置
US20080244552A1 (en) Upgrading services associated with high availability systems
CN104715001A (zh) 用于对数据处理系统的集群中的共享资源执行写入操作的方法和系统
CN105515872A (zh) 配置信息的更新方法、装置及系统
US6961764B2 (en) Description distributed computer system and method of applying maintenance thereto
US7181739B1 (en) Installation relationship database
WO2020233351A1 (zh) 面向区块链的数据管理方法、装置、设备及存储介质
US10318330B2 (en) Data-persisting temporary virtual machine environments
US7222338B2 (en) Method for upgrading data
JP2020184325A (ja) レプリカ処理方法、ノード、ストレージシステム、サーバ及び読み取り可能な記憶媒体
CN108509296B (zh) 一种处理设备故障的方法和系统
KR20110040591A (ko) 백업 서버 및 그 방법
EP2711836B1 (en) Data distribution system
KR20140031260A (ko) 캐시 메모리 구조 및 방법
CN111756562B (zh) 一种集群接管方法、系统及相关组件
CN115994188A (zh) 数据库的主备切换方法、装置、系统、设备及存储介质
CN112632130A (zh) 一种数据管理的方法、装置、设备及介质
US10853188B2 (en) System and method for data retention in a decentralized system
US7343376B2 (en) Management information notification to a manager in a management system

Legal Events

Date Code Title Description
N231 Notification of change of applicant
WITN Withdrawal due to no request for examination