Bitwar Data Recovery는 전문적인 데이터 회복의 대가로 당신이 다운로드 할 수 있습니다.

http://kr.bitwar.net/

대표적인 컴퓨터 에러 원인인 CPU과열은 쿨러가 CPU의 열을 제대로 식혀주지 못해서 발생해요.
보통 먼지나 이물질로 인하여 쿨러팬의 속도저하나 방열판의 밀착불량 때문이랍니다.

이렇게 컴퓨터 에러 원인이 CPU쿨러에 있다면 쿨러를 깨끗이 청소해 해결할 수 있는데요.
간혹 방열판의 밀착불량이 있을 수 있는데 이 때 쿨러를 떼어 접촉면을 청소하고
써멀구리스를 도포한 후 방열판을 다시 장착하면 해결이 가능해요.

그런데, 컴퓨터 에러 원인이 CPU과열이라면 CPU점유율도 확인할 필요가 있지요.
특히 바이러스나 불법프로그램 등이 백그라운드에서 돌아가는지 확인해야 하죠.
자주 바이러스 검사를 해주고 각종 유틸리티를 이용해 시스템을 최적화해주는 것이 좋답니다.

누구나 알아야 할 컴퓨터 에러 시 문서복구방법 이야기!

컴퓨터가 오류가 생겨 문서가 열리지 않는 상황이 있는데요. 그 때는 ghost.exe 실행 후
'restore'를 선택하면 예전 날짜의 컴퓨터 환경으로 복구된다고 하는데요.
복구가 되었다면, 이 때 필요한 문서를 찾은 다음 새로 저장하시면 됩니다.

그리고 한글 문서를 작성하던 중 컴퓨터에 발생한 에러로 전원이 나갈 때가 있죠.
그럴 땐 한글 메뉴에서 '최근 작업 문서' 버튼을 눌러 작업했던 데이터를 가져올 수 있어요.

이 때, '네이버 셀'을 컴퓨터에 설치한다면 컴퓨터가 오류가 나더라도 쉽게 문서를 복원할 수 있는데요.
메뉴의 '임시 저장 문서 복구'를 클릭하면 오류 전 작성했던 문서를 열람할 수 있답니다.

또 컴퓨터가 고장 나 기존에 작성했던 문서를 복원하려면 'Final Data'라는 프로그램을 쓸 수 있죠.
새로운 컴퓨터에 프로그램을 깔고 오류가 발생한 피시의 하드디스크를 붙여 데이터를 복사하면 돼요.

간직하고 싶은 내 추억들이 들어있는 컴퓨터 데이터 복구를 하고 싶다면?
검증된 실력과 정직함을 겸비한 인젠데이타와 함께 하십시오!

인젠데이터는 컴퓨터를 비롯한 기타 정보저장매체 데이터 복구 전문기업으로서
20년 이상 경력을 갖춘 수 많은 경험을 보유한 연구진들이 탁월한 데이터 복원 서비스를 제공합니다.

최신 복구 전문설비와 자체 솔루션을 보유하고 있어 타사 대비 높은 복구율도 보장합니다.
1:1 인터넷 맞춤 서비스 무료 상담으로 내 컴퓨터의 문제점도 알아낼 수 있는 기회!

세계 최초 COB 복구기술 개발에 성공한 데이터 복구 업계 최고 전문인력의 탁월한 서비스,
다양한 고객 후기로 검증된 인젠데이터가 직접 보여 드리겠습니다.

여러분이 궁금해 하셨던 컴퓨터에러에 대해서
이제 확실히 알아내셨나요?
새로운 내용을 배우는 것은 제일 흥미로운 일인 것 같습니다.
그럼 다음 게시글을 기다려 주세요~!!

1. 개요

인터넷과 더불어 정보화사회를 가능하게 하는 양대 축 중 하나
당신이 접속한 문서들의 집합

여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합을 말하는 개념이다. 줄여서 DB라고도 하며, 특정 다수의 이용자들에게 필요한 정보를 제공한다든지 조직 내에서 필요로 하는 정보를 체계적으로 축적하여 그 조직 내의 이용자에게 필요한 정보를 제공하는 정보 서비스 기관의 심장부에 해당된다.

일반적으로 응용 프로그램과는 별개의 미들웨어를 통해서 관리된다. 데이터베이스 자체만으로는 거의 아무 것도 못하기 때문에 그걸 관리하는 시스템과 통합돼 제공되며 따라서 정확한 명칭은 데이터베이스 관리 시스템(DBMS)이 된다. 데이터베이스만 제공되는 건 CSV같이 아주 단순한 데이터에 국한되는데 이걸 직접 사용하는 경우는 많지 않고 이런 데이터를 RAW데이터로 간주해 다른 DBMS시스템에 적재하고 사용하는 게 일반적이다.

관계형 데이터 베이스(RDBMS)가 가장 널리 쓰이고 있다. 그리고 이 관계형 데이터베이스를 이용하기 위한 표준 언어가 만들어져 있는데 그것이 SQL이다. 구조화 질의 언어(Structured Query Language)의 약자. 예전에는 데이터베이스가 관계형 데이터베이스의 대명사처럼 여겨졌으나 요즘에는 다른 형태의 데이터베이스도 많이 나와있다. 가히 데이터베이스 춘추전국시대. 이런 비-관계형 데이터베이스는 NoSQL이라 불린다. SQL을 사용하지 않는 데이터베이스라는 다소 장난스런 표현. 물론 정식 명칭은 각자 가지고 있다. 객체형, 문서형, 컬럼형 등등.

관계형 데이터 베이스를 이용하기 위해 만들어진 SQL 문은 배워 두면 여러모로 쓸 데가 많다. 컴퓨터로 하는 일에서 대부분을 차지하는 작업은 바로 정렬과 탐색인데 이 두 작업을 가장 전문적으로 처리하는 건 데이터베이스이다. 컴퓨터로 계산을 하는 경우는 의외로 정렬과 탐색에 비하면 비중이 낮은 편이다.

간혹 무겁게 DB까지 돌리지 말고 파일로 하나하나 저장해놓으면 DB보다 훨씬 간편하지 않냐는 사람도 있다. 하지만 파일의 경우 간단한 작업을 할 때는 DB에 비해서 간단하고 오버헤드도 적은 편이나, 게시판을 만드는 등의 작업을 할 경우 DB에 비해서 훨씬 밀린다. 인덱싱, 멀티 스레드 작업으로 인해 파일에 비해 더 빠르고, 파일에서 몇 줄으로 처리해야 할 일들을 DB에선 단 한 줄만으로도 처리할 수가 있어서 본격적인 작업을 하려면 DB를 사용하는 것을 권한다. 

2. 데이터베이스의 특징

• 자기기술성 : 파일 시스템과 구별되는 특징. DBMS가 데이터의 삽입 및 삭제를 데이터/구조적 종속 없이 가능케 해준다.

• 프로그램과 데이터의 격리 : 단일한 응용 프로그램 내에서 데이터를 개별적으로 관리하는 방식은 데이터 저장 구조 등이 변경되면 응용 프로그램도 수정되어야 한다. 하지만 데이터베이스는 자기기술성을 가지므로 저장 구조 등을 수정하는 것이 응용 프로그램에 영향을 미치지 않는다.

• 추상화 : 복잡한 데이터베이스의 구조에 대한 정보를 감추고, 각 사용자에게 뷰를 제공한다.

• 특정 적용 업무나 응용 시스템이 아닌 동시에 복수의 적용 업무나 응용 시스템에 대한 데이터의 공급 기지로서 공유할 필요가 있는 데이터를 보관·관리한다. 즉, 다수의 사용자에게 동시 접근을 허용한다. 동시성제어 항목 참고항목이 없다(...).

• 데이터의 특성, 실체 상호 간의 의미 관계와 형식 관계를 기술한 개념적인 구조에 따라서 편성된 데이터의 집합이다.

• 동일한 내용의 데이터가 중복되어 있지 않아야 하고, 다양한 접근 방식이 마련되어 있어야 하며, 검색이나 갱신이 효율적으로 이루어질 수 있도록 해야 한다.

• RAM,ROM같은 주기억장치가 아닌 컴퓨터에서 사용할 수 있는 보조기억장치에 저장된다.[1]

3. 설계

[2]데이터베이스 설계 단계는 요구 조건 분석, 개념적 설계, 논리적 설계, 물리적 설계, 구현, 운영 및 개선 단계로 이루어져 있다.

3.1. 요구 조건 분석

사용자가 무엇의 정보를 필요로 하는지, 문제가 무엇인지 등을 분석하여 어떤 데이터베이스를 만들어야 할지를 결정하는 단계이다.

3.2. 개념적 설계

데이터베이스의 구성요소(속성)들을 정하고, 다음 단계인 논리적 설계에서 수행할 작업을 설계한다.
구성요소를 정하고 다음 단계에서 할 일을 설계해 놓기 쉬운 피터 챈(Peter chen)박사가 제안한 개체-관계모델(ERD)을 
사용한다.

3.3. 논리적 설계

본격적인 스키마 설계로, 이전 개념적 설계에서 만들어 놓은 설계도를 사람들이 알아볼 수 있는 형태로 작업하는 것이라고
생각하면 된다. 이외 제약조건 등을 이 단계에서 제작한다.

3.4. 물리적 설계

저장장치에 저장되는 형태의 알고리즘을 효율적이게 개선하고 수정하는 단계이다.

3.5. 구현

여태까지 데이터베이스의 구조만 설계했다면, 이 단계는 실제로 자료들을 수집한 뒤 데이터베이스의 알맹이(관계 데이터 모델에서는 릴레이션 인스턴스라고도 한다.)들을 채워 넣는 것이라고 보면 된다.

3.6. 운영 및 개선

데이터베이스를 실제로 운영하고, 실제 사용하면서 생기는 문제점들을 개선하는 단계이다.

4. 종류

4.1. 관계형(Relational)

데이터베이스계의 주류. 아직도 주류의 자리에서 내려오지 않고 있다. 데이터를 컬럼(Column)과 로우(Row)라는 일종의 표 형태로 저장한다. 데이터의 종속성은 관계(Relation)으로 표현한다.

한 테이블에 있는 모든 로우는 같은 길이의 컬럼을 가지고 있으며 이 컬럼의 구조와 데이터의 관계가 테이블 스키마(Schema)로 사전 정의된다.

역사가 오래된 만큼 가장 신뢰성이 높고 데이터의 분류, 정렬, 탐색 속도가 빠르다. SQL은 고도로 정교한 검색 쿼리를 제공하며 상상하는 거의 모든 방식으로 데이터를 다룰 수 있게 해 준다. 또한 트랜젝션(Transaction) 지원이 매우 강력하여 신경만 제대로 써주면 데이터가 안 들어가는 경우는 있어도 잘못 들어가는 경우는 없다. 예를 들어 금융거래시 구매자 통장에서 돈이 빠져나가고 뒤이어 판매자 통장에 돈이 들어와야 거래가 정상적으로 끝나게 되는데 만약 판매자 통장을 관리하던 컴퓨터가 맛이 갔다고 한다면 RDBMS는 트랜젝션 롤백을 통해 구매자 통장의 잔금을 원상복구 시키면서 거래를 취소한다. 여기선 간단하게 설명했지만 현실에서는 네트워크 이상, 데이터 비트 오염, 하드디스크 이상, 동시성 문제 등 데이터 무결성을 보장하기 위해 넘어야 할 산이 많다. 근데 이 모든 상황을 다 고려해서 그 어떤 상황에서도 데이터 무결성을 '보장'하는 게 RDBMS의 특징이다. 다른 타입의 DBMS는 이정도의 데이터 무결성을 보장하지 못한다! 한마디로 없는 돈이 허공에서 솟아날 수도 있고 있던 돈이 증발할 수도 있다.

그러나 스키마를 수정하기가 어렵고, 데이터가 2차원 표형태로만 출력되기 때문에 트리 구조로 조직화되는 '객체'들과 궁합이 잘 안맞는 게 문제다. 이 문제는 ORM(Object-Relation Mapping)기법으로 땜빵하고는 있으나 밑에 설명하는 객체형, 문서형 DB가 더 객체 친화적이므로 신규 프로젝트를 시작하는 경우라면 ORM과 객체형 DB사이에서 잘 저울질해보자.

다만 DBMS가 부하분산이 잘 안된다. 읽기 작업은 분산이 되지만 쓰기 작업을 분산하려면 고도의 기술력에 더해 전략까지 필요하다.

4.2. 키-값형(KV store)

모든 데이터를 키(Key)와 값(Value)의 쌍으로 매핑한다. Key를 어떻게 인덱싱했느냐에 따라 다르지만 보통 특정 값 하나를 찾아내는 데에는 가장 뛰어난 성능을 보인다. 하지만 데이터를 그룹화하고 정렬하는 기능은 없다시피하다. 대신 RDBMS에 비해 가볍고, 빠르고, 다루기 쉽다.

언뜻 보면 1차원 데이터만 다룰 수 있을 것 같이 생겼지만 Value에 넣을 수 있는 값이 자기 자신의 Key를 포함하여 Any object이기 때문에(크기 제한은 있을 수 있다) 대부분의 데이터를 다룰 수 있다. 물론 다른 DBMS는 이런 데이터 조직화를 도와주는 각종 도구를 제공하므로 2차원 이상 데이터는 KV store 말고 다른 걸 찾아보는 게 좋다.

웹 캐시나 세션 데이터, 쇼핑몰의 장바구니 데이터 등을 담는 데에 최적인 DB여서 이쪽으로 활용을 많이 한다. 그 외에 KV store는 데이터베이스의 크기가 상대적으로 작아 메모리에 통째로 올려놓고 구동하는 것도 쉽기 때문에 인-메모리 데이터베이스로 많이 사용된다. 인-메모리 데이터베이스는 그 특성상 매우 고속으로 동작하는 대신 데이터의 안정성을 전혀 보장하지 않는데 장바구니 같은 건 날아가도 상관없는 데이터이면서 반응이 즉시 와야 하는 성격이라 주로 선택된다. KV store로 세션을 처리하는 웹 서버도 하드디스크에 부담을 상당히 덜어주면서 반응이 아주 빠르다. 그러니까 일종의 '임시 데이터' 저장소로서의 입지를 굳게 다지고 있다.

4.3. 객체형(Object)

프로그래밍 언어에서 객체지향의 개념이 포함되었듯이, 관계형 데이터베이스 이후, 데이터베이스에서도 객체지향을 구현한 것이 바로 객체형 데이터베이스이다. 이러한 DBMS를 ODBMS라고 한다.

다만, 데이터베이스 분야에서는 ODBMS가 주류가 되지는 못했는데, 이유는 쿼리 사용이 복잡해지기 때문이다. 다른 형태의 DBMS가 도태된 이유와 같은 것. 때문에 아직까지도 RDBMS 방식이 널리 사용되고 있다.

4.4. 문서형(Document)

MongoDB의 방식. 위의 객체형과 비슷하다. 문서의 구조를 나타내는 스키마가 필수가 아닌 것이 특징이다.
스키마가 없기 때문에 인덱스 필드를 제외하고(인덱스를 해제하는 건 가능하다) 필드를 마음대로 넣거나 뺄 수 있다. 기존 데이터에 해당 필드가 있든 없든 상관없고 그런 데이터를 상대로도 조회, 그룹핑 등의 작업이 가능하다.

객체 지향 프로그래밍이 주류인 현재, 데이터를 따로 매핑할 필요 없이 그냥 집어넣으면 알아서 잘 저장되는 객체형, 문서형 데이터베이스가 주목받고 있다.

그러나 저장한 상태 그대로의 문서를 뽑아내는 게 아니라 뭔가 데이터를 가공하려고 하면 잘 되지 않는다. 예를 들어 Group by나 Join 쿼리 등. 또한 데이터를 지속적으로 '쌓아 올리는' 응용(예를 들어 금융거래 기록 저장)에서는 성능이 상당히 떨어진다. 이런 건 RDBMS가 가장 잘 하는 분야.

데이터의 스키마가 자주 바뀌고 데이터가 다계층의 객체 형태이면서 대부분의 업무가 갱신, 삽입(문서단위), 조회에 집중돼있고 통계 연산에 쓰일 일이 많지 않은 곳에서 사용하기 좋다. 통계 연산이 가끔 필요한 곳에서는 필요한 데이터를 추출해 RDBMS에 옮기고 SQL로 처리한다. 아니면 DBMS에서 자체 제공하는 map/reduce 연산을 쓰던지.

한마디로 바인더 서류철과 비슷한 성격을 가졌다. 바인더철에 추가로 종이를 꽂거나(삽입), 꽂힌 종이를 다른 걸로 갈아넣거나(갱신), 종이를 찾거나(조회) 하는 일에는 뛰어나지만 한 종이 안에 적힌 데이터가 계속 늘어나거나(추가), 여러 종이에 걸쳐 있는 어떤 값을 다 더하거나(통계) 하는 일에는 취약하다. RDBMS는 여기서 '종이'에 해당하는 놈이 무한한 두루마리와 같아서 데이터의 추가 작업이나 특정 필드를 대상으로 한 통계 및 그룹화 작업이 쉽다. 대신 RDBMS는 2차원을 넘어가는 데이터(트리 구조 데이터 등)를 저장할 때 두루마리를 여러 개 준비해야 하는 게 단점이다. 중간에 형식이 다른 데이터를 끼워넣는 건 불가능하고. 문서형 DB는 종이 하나에 모든 관련 데이터를 다 담아두므로 다른 종이에 무슨 데이터가 어떻게 저장되든 상관하지 않는다. 조회를 위한 인덱스만 하나 이상 있으면 OK.

4.5. 컬럼형(Column)

Map/reduce에 특화된 DB. Hadoop이 컬럼형 DB이다.
디스크에조차 다 담지 못할 정도의 거대한 데이터를 다루는 게 특기이다. 다만 데이터 검색용으로 사용하기보다는 데이터의 통계 처리용으로 주로 사용된다.

NoSQL의 범람을 알리는 신호탄 같은 역할을 했기에 초반에 반짝 유행을 탔으나 이놈은 사용하기가 더럽게 어렵다. 일단 설계 사상 자체가 초대형 빅 데이터를 다루는 데 치중해있어서 최소 12대 이상의 컴퓨터로 클러스터 머신을 구성해야 하고[3](한 대로 돌릴 수 있긴 한데 그럴거면 RDBMS가 훨씬 고성능이다) 그걸 관리하기 위해서는 데이터베이스 뿐만 아니라 네트워크와 하드웨어에 대한 심도깊은 이해가 필요해서 지금은 인기가 많이 식었다. 디스크 하나에 다 못담을만큼 대용량 데이터면 적어도 테라바이트급 데이터라는건데 그만한 데이터를 처리할 만큼 거대한 조직은 은행이나 대형 쇼핑몰(아마존등), 검색엔진 회사(구글등) 정도를 제외하면 거의 없다. 저 Hadoop이라는 놈도 태생은 구글의 빅테이블이다.

어지간한 대기업 레벨이 아니고서야 컬럼형 데이터베이스를 고려해야 할 정도로 대량의 데이터가 매일같이 쏟아지진 않을 것이다. 게다가 저게 시스템 구축하기가 너무 힘들기 때문에 정 쓰고 싶다면 학습 목적이 아닌 한에야 클라우드 컴퓨팅 서비스로 제공하고 있는 걸 가져다 쓰는 게 좋다.

5. DB 에러

각종 정보를 저장하는 데이터베이스(DataBase)의 약자가 DB 이기 때문에, 많은 곳에서 두부라는 애칭으로 불린다.
게임의 경우 게임의 실행파일을 제외한 그 나머지들, 책방이라면 책의 목록을 정리해 둔 PC, 웹사이트라면 회원정보나 게시물의 내용을 모두 저장해둔 서버 등, 뭔가를 운영하고 실행하기 위해 필수불가결한 존재이다. 그러나...


누르고 싶다

이와 같이 웹 사이트를 이용하는 도중 갑자기 접속이 안되면서, 이 메세지와 함께(예시 화면은 제로보드 DB 접속 에러화면) 마왕으로 각성하는 경우가 있다.

웹 사이트와 마찬가지로 게임이나 유틸리티와 같이 컴퓨터에 설치되는 프로그램들도 자신의 DB에 이상이 생기면 에러메세지와 함께 작동불능이 되지만, 이 경우 이용자 개인의 불편사항에 머무르는 편이기 때문에 웹 사이트 서버의 DB 에러와 같이 여러 사람이 동시에 겪을 정도의 파괴력이 나오지 않아 마왕이라고 일컬어지는 일은 별로 없다.

디시에서도 실세갤의 판단 여부를 가늠할 때 두부에러가 얼마나 자주 일어나느냐에 따라 결정하던 시절이 있었다. 스갤은 실제로 명경기나 그에 준하는 사건이 터질 때 수시로 두부 에러를 일으켰다. 최근에는 서버 증설&이지디씨 무력화&갤 인구감소 등의 이유로 웬만해선 두부 에러를 보기 어렵다.

6. 함께 보기

• 데이터베이스권

• 학술 데이터베이스 (학술DB)

• 인 메모리 데이터베이스

• 후쿠베 사토시

• DBMS (데이터베이스 관리 시스템)

  • SQLite

• 나무위키:데이터베이스 덤프

도입 목적

전동차 관련 회사로써 설계팀에 운용중인 파일 서버의 설계 도면을 실시간으로 백업해야 한다는 이슈로 도입하게 되었음. 설계에 사용되는  프로그램이 만들어내는 데이터의 용량이 기본 1~2G 용량이었고, 어떤 데이터는 10G 용량이 넘는 경우도 있었음. 따라서, 실시간 백업을 거의 하지 못하고 일과 시간 이후에 1회 백업하는 형태로 운영중이었음. 고객은 이러한 문제를 해결 할 수 있는 실시간 백업 솔루션이 필요했고, 조건으로 실시간 백업 도중에 운용중인 서버에 부하를 거의 주지 말아야 한다는 조건이었음.

이런 까다로운 조건을 만족할 수 있는 제품으로 선정되어 도입되게 되었음.

도입 효과

담당자가 가장 훌륭하게 평가했던 부분은 실시간 백업이 되는 도중에도 CPU 점유율이 거의 없다는 점을 가장 높이 칭찬했음. 타 회사 제품들로 BMT 했을 때는 평균 50% 이상의 CPU 점유율을 보여서 도입을 할 수 없었는데, Tri-backup시스템은 CPU 점유율이 거의 없으면서도 고속으로 실시간 이중화가 이루어지는 것을 보고 아주 흡족해 했음.

Redundant array of independent disks

Wikimedia Commons, 자유로운 미디어 저장소

In computing, a redundant array of inexpensive disks (more commonly known as a RAID) is a system of using multiple hard drives for sharing or replicating data among the drives. Depending on the version chosen the benefit of RAID is a one or more of increased data integrity, fault-tolerance, throughput or capacity compared to single drives.

Standard RAID levels

Main Wikipedia article: Standard RAID levels

• 

  RAID 0

•  

• 

  RAID 1

•  

• 

  RAID 2

•  

• 

  RAID 3

•  

• 

  RAID 4

•  

• 

  RAID 5

•  

• 

  RAID 6

Nested RAID levels

Main Wikipedia article: Nested RAID levels

• 

  RAID 01 (nested)

•  

• 

  RAID 01 (hybrid)

•  

• 

  RAID 03

•  

• 

  RAID 10

•  

• 

  RAID 100

Non-RAID drive architectures

Main Wikipedia article: Non-RAID drive architectures

• 

  JBOD

도입 목적

일부팀에서 운용중인 서버에 저장된 자료가 빈번히 삭제되는 사례가 발생하여 실시간 이중화(백업)와 삭제방지 기능을 목적으로 도입.

도입 효과

기존에 일과 시간 후 스케줄 백업하던 방식에서 데이터 발생 시점에서 곧바로 백업이 되는 형태로 바뀌어 관리자가 아주 만족했고, 도입 이후에 원본 데이터가 삭제되더라도 이중화쪽의 데이터는 항상 보존되어 있기 때문에 데이터 손실에 대한 우려가 해소..

도입 목적

화학과 연구실에서 대학원 과정에 있는 학생들의 논문 자료가 저장된 파일 서버가 중국 해커에 공격당해 졸업 논문이 삭제되는 사고가 발생했음. 자체적으로 NAS로 백업을 구축해 놓고는 있었으나 공격을 당하면서 NAS에 저장되어 있던 데이터까지 삭제되어 버린 상태였음. 급히 데이터복구 업체에 맡겼으나 해당 졸업 논문을 복구하지 못해 결국 학생들이 졸업을 1학기 연기하는 사태에 놓여 있었음. 따라서, 자동 백업 및 데이터 삭제 방지라는 목적으로 도입이 이루어졌음.

도입 효과

도입 후 동일한 공격을 받았으나 이번에는 원본 데이터만 삭제되고 이중화 데이터는 삭제되지 않고 그대로 남아 있는 것을 확인한 학생들이 아주 만족스럽다는 반응들을 보였음.

특히, 학생들 데이터뿐만 아니라 담당 교수님의 연구 데이터의 경우 국비로 진행되는 프로젝트 연구 데이터들도 상당히 많았는데, 그러한 데이터들까지 삭제방지로 보호되는 것을 보고서는 담당 교수님도 만족스러워했음.

도입 목적

관공서에서 운용중인 서버에는 관공서 홈페이지 자료와 회의록 자료관 시스템이 동시에 운용중인 상태였는데 백업이 자동화 되어 있지를 못했음. 그리고, 운용중인 MS-SQL의 경우에도 담당자가 1주일에 한번정도 늦은 시간에 DB를 정지시켜 놓고 수동으로 백업하고 있는 실정이었음. 따라서, 이러한 주먹구구식 백업 현황을 개선하기 위해서 본 시스템을 도입하게 되었음.

도입 효과

우선, 담당자는 너무 고가라서 도입을 할 수 없었던 DB 실시간 백업 솔루션을 반값 이하의 가격으로 도입하게 되어 아주 만족했고, 그 가격대에서 DB 뿐만 아니라 서버에 운용중인 모든 데이터들이 체계적으로 무인 자동화 백업화 되는 것을 보고 놀랍다는 반응을 보였음.

도입 목적

운영중이던 서버용 PC 고장으로 데이터복구 의뢰했으나 시간과 비싼 비용을 치르고서도 자료의 30% 이상이 손실되는 사태가 발생하여 도입.

도입 효과

관리 시스템 상에서 DB가 운용중인 DB 데이터는 사실상 백업이 하루 1회에 그쳐 손실에 대한 우려가 있었으나 본 백업 시스템 도입 이후에 DB 데이터까지 곧바로 실시간 백업되는 것을 보고 고객은 물론, 해당 관리 업체쪽에서도 아주 만족했음.

도입 목적

통신을 연구하는 연구소에서 연구용 논문 및 연구 자료용 파일 서버를 운용 중이었음.

연구소 입장에서는 상당히 중요한 자료 인만큼 외장 HDD를 연결하여 백업을 진행하고 있었음. 하지만, 연구원들의 USB 메모리를 통해서 유입된 악성코드로 인해 백업 데이터의 일부분이 삭제되는 사태가 벌어졌고 그로 인해 도입이 추진되었음.

도입 효과

담당자는 백업을 해 놓기만 하면 된다고 여겼으나 실제로 악성코드가 심어진 데이터가 백업될 경우에는 백업 데이터 역시나 삭제가 된다는 사실을 그때서야 깨달았고 그런 문제에 대해서 아무런 대책이 없었다가 우리 제품으로 구축 후 삭제방지 기능이 수행되는 것을 보고 안심이 된다며 만족을 표시했음. 동시에 백업 된 데이터를 기존 외장 HDD에 스케줄 방식으로 2차 백업을 수행하게 했고, 이 2차 백업 데이터 역시나 삭제 방지 기능을 걸어놓음으로써 거의 완벽에 가까운 백업 시스템이 구축될 수 있었음.

도입 목적

네비게이션 지도를 제작하는 업체인 만큼 실 데이터의 양이 무려 4TB에 이르렀고, 많은 사람들이 동시에 접속해서 제작하다보니 운용중인 파일 서버내의 데이터가 체계적으로 백업되지 못하고 있는 실정이었음. 특히나 수시로 폴더명과 파일명 그리고 위치가 변동되는 특성상 기존 백업 솔루션으로는 도무지 백업을 할 수 없다는 결론에 이르러 디스크 전체의 볼륨을 실시간으로 똑같이 이중화하는 백업 시스템이 필요하다는 요청으로 도입되게 되었음.

도입 효과

기존 백업 솔루션들은 백업 설정 이후에 폴더명을 바꾸거나 위치를 옮기게 되면 그 이후로는 백업이 안되거나 중복 백업되는 사태가 벌어져 관리자가 백업에 아주 골머리를 앓고 있었는데, 본 시스템 도입 이후에는 폴더명이 바뀌거나 심지어 위치가 옮겨지는 것까지 실시간 이중화되는 것을 보고서는 그야말로 환호성을 질렀음. 더욱이 운용중인 SQL DB까지 똑같이 이중화되는 것을 보고서는 일주일에 한번씩 퇴근도 못하고 DB 백업해야 했던 자신의 업무 부담이 획기적으로 줄여지게 되었다고 아주 큰 만족감을 표시했음

도입목적

웹호스팅을 운용하는 업체의 서비스 서버의 DB 데이터를 저렴한 가격으로 백업하기 위해서 도입되었음.

도입 효과

담당자의 요구는 실시간 백업 뿐만 아니라 필요시 운용중인 DB에는 전혀 영향을 주지 않는 조건에서 운용 DB 데이터를 횟수에 제한없이 복사 및 스케줄 백업을 할 수 있기를 희망했는데, 사실상 이러한 요구를 만족시킬 수 있는 저렴한 제품이 없는 실정이었음. 그런데, Tri-backup을 설치하고 실제로 그렇게 백업되는 것을 보고서는 상당히 독특하고 좋다고 만족감을 표시했음.

도입 목적

사람의 복부를 촬영하는 감마선 촬영기라는 의료 기기에 내장된 디스크가 물리적으로 손실되어 그날 하루치의 모든 촬영 데이터가 망실되는 사태가 벌어졌음. 그로인해 모든 환자들을 다시 불러 재촬영하는 업무 지연사태가 발생했음. 따라서, 데이터 발생과 동시에 곧바로 실시간으로 저장할 수 있는 실시간 백업 시스템의 요구로 도입하게 되었음.

도입 효과

매일 일과 시간 이후에 스케줄 백업하던 방식에서 실시간 백업하는 방식으로 바뀌어 되어 데이터 손실 우려가 완전히 해소되었고, 조작이 미숙한 사용자들에 의해 손실되던 데이터까지 이중화쪽에 저장되어 있음으로써 완벽한 데이터 손실 대응이 구비되었다고 담당자는 만족감을 표시했음.

도입 목적

외국계 회사에서 생산 라인에서 발생하는 생산량을 저장하는 DB가 삭제되는 사고가 발생하여 본사로부터 조사를 받는 경우가 발생했었음. 그런데, 문제는 여기서 운용되는 DB가 공장 자동화에만 쓰이는 특수한 DB인 탓에 기존의 백업 솔루션으로는 백업 자체가 불가능하다는 것이었음. 따라서, 이러한 현실적인 문제 때문에 어떠한 DB든지 상관없이 실시간 이중화(백업) 되는 백업 솔루션을 찾는 고객의 요청으로 도입하게 되었음.

도입 효과

모든 경쟁 제품들이 불가능하다던 백업이 실제로 구현되는 것을 본 담당자는 상당한 만족을 표시했고, 담당자가 필요시에 언제든지 이중화쪽의 데이터를 복사해 와서 관리할 수 있다는 점이 아주 독특한 기능이라고 말했음.