컴퓨터 백업이란 무엇입니까?

백업이란 데이터베이스를 덤프 디바이스에 복제하는 프로세스입니다. 여기서 덤프 디바이스는 데이터베이스 복제본을 배치하는 데 사용되는 테이프 또는 디스크입니다. 덤프 디바이스에 저장된 데이터베이스 복제본을 원본 데이터베이스의 백업 또는 덤프라고도 합니다. 다음 그림과 같이 나타납니다.

ORACLE 데이터베이스 백업은 물리적 백업과 논리적 백업으로 나눌 수 있습니다. 물리적 백업은 실제로 데이터베이스를 구성하는 운영 체제 파일을 한 곳에서 다른 곳으로 복제하는 백업 프로세스이며, 일반적으로 디스크에서 테이프로 복제하는 프로세스입니다. Oracle 의 RMAN (복구 관리자) 또는 운영 체제 명령을 사용하여 데이터베이스를 물리적으로 백업할 수 있습니다. 논리적 백업은 SQL 언어를 사용하여 데이터베이스에서 데이터를 추출하고 이진 파일에 저장하는 프로세스입니다. Oracle 에서 제공하는 논리적 백업 툴은 EXP 입니다.

데이터베이스의 논리적 백업은 물리적 백업을 보완합니다.

물리적 백업 시 데이터베이스 상태에 따라 백업은 일관된 백업과 일관되지 않은 백업으로 나눌 수 있습니다.

일관된 백업: 일관된 백업은 데이터베이스에서 읽을 수 있는 모든 데이터베이스 파일과 제어 파일의 SCN (시스템 변경 번호) 이 동일하고 데이터 파일에 현재 SCN 을 제외한 변경 사항이 포함되지 않음을 의미합니다. 데이터베이스 체크포인트가 진행되는 동안 Oracle 은 모든 제어 파일과 데이터 파일을 일관되게 유지합니다. Oracle 은 읽기 전용 및 오프라인 테이블스페이스에 대해서도 일관성이 있다고 간주합니다. 데이터베이스를 일관된 상태로 유지하는 유일한 방법은 데이터베이스를 정상적으로 종료하는 것입니다 (shutdown normal 또는 shutdown immediate 명령을 사용하여 종료). 따라서 다음과 같은 경우에만 백업이 일관성을 유지합니다.

데이터베이스가 정상적으로 종료됩니다 (정상 종료 또는 즉시 종료 명령을 사용하여 종료).

일관되지 않은 백업: 일관되지 않은 백업은 읽을 수 있는 데이터베이스 파일의 SCN (시스템 변경 번호) 이 데이터베이스의 제어 파일과 일치하지 않을 때의 백업입니다. 7*24 작업 데이터베이스의 경우 종료할 수 없고 데이터베이스 데이터가 끊임없이 변하기 때문에 일관되지 않은 백업만 할 수 있습니다. SCN 번호가 일치하지 않는 경우 리두 로그를 적용하여 SCN 을 일관되게 해야 데이터베이스를 시작할 수 있습니다. 따라서 일관되지 않은 백업을 수행할 경우 데이터베이스를 아카이브 상태로 설정해야 합니다. 이는 리두 로그를 아카이브하는 데 매우 중요합니다. 다음과 같은 경우 백업이 일관되지 않은 백업입니다.

데이터베이스가 이미 열려 있습니다.

데이터베이스가 종료되었지만 종료 방법이 정상이 아닙니다. 예를 들어, 시스템 종료 중단이나 시스템 전원 장애로 인해 데이터베이스가 종료됩니다.

복구란 무엇입니까?

복구란 데이터베이스를 장애 상태에서 장애 없는 상태로 변경하는 프로세스입니다. 실패 원인에 따라 복구에는 두 가지 유형이 있습니다.

인스턴스 복구. 이 복구는 Oracle 인스턴스에 장애가 발생한 후 Oracle 의 자동 복구입니다.

미디어 복구. 이 복구는 데이터베이스를 저장하는 미디어에 장애가 발생할 때 수행됩니다. 이 책의 뒷부분에 언급된 복구는 미디어 복구를 가리킨다.

물리적 백업 복구 및 물리적 백업 복원은 미디어 복구의 수단입니다. 로드는 백업을 디스크로 되돌려 보내는 프로세스이며, 복구는 리두 로그를 사용하여 디스크로 가져온 데이터 파일 (물리적 백업의 또 다른 부분) 을 수정하여 데이터베이스를 복구하는 프로세스입니다. 다음 그림과 같이 나타납니다.

데이터베이스 복구 정도에 따라 복구 방법은 두 가지로 나뉩니다.

전체 복구: 데이터베이스를 데이터베이스 실패 시점의 상태로 복원합니다. 이러한 복구는 데이터베이스 백업을 로드하고 모든 리두 로그를 적용하여 수행됩니다.

불완전한 복구: 데이터베이스가 실패하기 전 특정 시점의 상태로 데이터베이스를 복구합니다. 이러한 복구는 데이터베이스 백업을 로드하고 일부 리두 로그를 적용하여 수행됩니다. 불완전한 복구 후 데이터베이스를 시작할 때 resetlogs 옵션을 사용하여 온라인 리두 로그를 재설정해야 합니다.

예를 들어, 아침 10: 00 에서는 데이터베이스가 디스크 손상으로 인해 사용되지 않습니다. 이제 데이터베이스를 복구하는 방법에는 두 가지가 있습니다. 첫 번째 방법은 데이터베이스를 정상적으로 작동시키고 복구된 데이터베이스의 데이터를 손상된 데이터베이스의 데이터와 동일하게 (10: 00) 만들기 때문에 첫 번째 복구 방법은 전체 복구 유형입니다. 두 번째 방법은 데이터베이스가 제대로 작동하지만 복구된 데이터베이스의 데이터만 손상 전 데이터와 동일할 수 있으며 (예: 9: 00), 데이터베이스를 장애 시 상태 (10:00) 로 복구할 수 없으므로 두 번째 복구 방법은 불완전한 복구 유형입니다.

실제로 데이터베이스 백업이 일관된 경우 로드된 데이터베이스를 사용하여 리두 로그 없이 데이터베이스 백업 시점으로 복구할 수 있습니다. 이것도 불완전한 회복이다.

백업과 복구의 관계

ORACLE 데이터베이스를 백업하는 것은 의료 보험 구매와 유사합니다. 병에 걸릴 때까지 그 중요성을 인식하지 못하며, 받는 보험금의 양은 보험 증권의 유형에 따라 달라집니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 건강명언) 마찬가지로 백업 유형과 빈도에 따라 장애 발생 후 데이터베이스 복구의 타당성, 난이도 및 소요 시간도 다릅니다.

데이터베이스 실패는 데이터베이스 실행 중 데이터베이스의 정상적인 사용에 영향을 미치는 특수 이벤트입니다. 데이터베이스 장애에는 여러 가지 유형이 있으며, 그 중 가장 심각한 것은 디스크 손상과 같은 미디어 장애이며, 복구할 수 없는 경우 데이터베이스의 데이터가 손실됩니다. 데이터베이스 오류 유형은 다음과 같습니다.

문장이 실패했습니다.

사용자 프로세스가 실패했습니다.

인스턴스가 실패했습니다.

사용자 또는 응용 프로그램 오류 작업. 이 오류는 테이블의 데이터를 실수로 삭제하는 등 잘못된 작업일 수 있습니다.

미디어 실패. 하드 드라이브에 장애가 발생하면 하드 드라이브의 데이터가 손실됩니다.

자연재해. 지진 홍수 등.

장애 유형에 따라 데이터베이스를 복구하는 방법도 다릅니다. 백업을 로드하여 데이터베이스를 복구하는 것은 일반적인 복구 방법일 뿐만 아니라 미디어 장애로부터 복구하는 주요 방법이기도 합니다.

백업 및 복구 시 고려해야 할 사항

백업 및 복구에서는 다음 세 가지 문제를 고려해야 합니다.

백업 및 복구 전략에서 고려해야 할 비즈니스, 운영 및 기술적 문제.

재해 복구 계획의 구성

백업 및 복구 전략의 중요성 테스트

수행할 수 있는 복구 유형은 사용 중인 백업에 따라 다릅니다. DBA 는 다음 세 가지 영역에서 데이터베이스의 복구 가능성을 유지 관리해야 할 책임이 있습니다.

데이터베이스 장애 횟수를 최소화하여 데이터베이스의 가용성을 극대화합니다.

데이터베이스가 불가피하게 실패할 경우 복구 시간을 최소화하여 복구 효율성을 극대화해야 합니다.

데이터베이스 장애 발생 시 데이터 손실을 최소화하거나 전혀 잃지 않도록 하여 데이터 복구 능력을 극대화해야 합니다.

백업 및 복구 전략에서 고려해야 할 비즈니스, 운영 및 기술적 문제.

DBA 는 먼저 기업이 데이터베이스 시스템을 어떻게 사용하는지, 그리고 데이터베이스 가용성, 복구 성능, 데이터 복구 가능성, 복구 시간에 대한 기업의 요구 사항을 이해해야 합니다. 그런 다음 DBA 는 이러한 데이터베이스의 가용성을 유지하는 데 드는 비용을 기업 관리자에게 알려야 합니다. 이를 수행하는 가장 좋은 방법은 기업의 복구 비용과 데이터 손실을 평가하는 것입니다.

비용을 평가한 후 백업 및 복구에 대해 논의할 수 있습니다. 이 시점에서 데이터베이스의 전체 가용성 요구 사항을 정의하고 각 작업이 데이터베이스 가용성에 미치는 영향에 따라 작업 우선 순위를 정의해야 합니다. 예를 들어, 데이터베이스를 사용하려면 7*24 를 사용할 수 있어야 합니다. 그러면 다른 작업보다 중요도가 높고 종료해야 할 다른 작업은 완료할 수 없습니다.

또한 데이터베이스의 변화도 백업 및 복구 전략에서 고려해야 할 요소입니다. 예를 들어, 데이터가 계속 변경되거나, 새로운 데이터나 데이터 파일이 추가되거나, 테이블 구조가 크게 변경된 경우 자주 백업해야 합니다. 반면 데이터가 정적이거나 읽기 전용인 경우 한 번 백업할 수 있습니다. 어쨌든 데이터베이스의 복구 가능성을 의심한다면 백업해야 한다는 원칙을 따라야 합니다.

재해 복구 계획의 구성

재해 복구의 경우 다음 질문에 답해야 합니다.

시스템에서 발생할 수 있는 재해 복구 상황은 무엇입니까?

데이터 손실 시 재해 복구 상황은 어떻습니까?

시스템의 데이터가 얼마나 불안정합니까?

문제가 발생할 경우 시스템을 얼마나 빨리 복구해야 합니까?

각 경우에 복구 정책 비용은 얼마이고, 그에 따라 데이터를 재입력하는 데 필요한 시간 비용은 얼마입니까?

이러한 질문에 대한 답은 재해 복구 계획을 구성합니다.

컴퓨터가 썩기 쉽다. 마더보드의 칩, 마더보드 회로, 메모리, 전원 공급 장치가 제대로 작동하지 않으면 컴퓨터 시스템이 제대로 작동하지 않을 수 있습니다. 물론 이러한 손상은 어플리케이션 및 데이터에 손상을 주지 않고 복구할 수 있습니다. 그러나 컴퓨터 하드 드라이브가 손상되면 데이터 손실이 발생할 수 있습니다. 이때 백업을 통해 데이터를 복구해야 합니다.

재해 복구의 가장 중요한 단계는 충분히 빈번한 하드 디스크 백업 프로세스를 설계하는 것입니다. 백업 프로세스는 시스템의 복구 가능성 요구 사항을 충족해야 합니다. 예를 들어, 데이터베이스를 장시간 종료할 수 있다면 일주일에 한 번 콜드 백업을 하고 리두 로그를 아카이브할 수 있습니다. 그러나 데이터베이스 종료 시간이 거의 없다면 하드 디스크 미러링 또는 듀얼 시스템 사용과 같은 하드웨어 측면에서만 백업 및 복구 문제를 고려할 수 있습니다. 백업 전략을 선택하는 것은 데이터 손실을 방지하는 비용에 대한 데이터 손실 비용의 비율입니다.

매일 백업할 수 있다면 이상적이지만 현실성을 고려해야 한다. 기업들은 유지 보수 비용을 절감하기 위해 노력하고 있으며 현실적인 솔루션을 채택할 수 있다. 신중하게 계획하고 데이터베이스 가용성의 한계에 도달하려고 노력하면 백업 및 복구에 적은 돈을 쓸 수 있습니다.

DBA 는 또한 서비스 계약의 형태로 복구 가능성과 가용성에 대한 표준 문서를 개발해야 합니다. 이 문서는 DBA 서비스 및 이러한 서비스가 예상한 기준에 부합하는지 여부를 논의하기 위한 기초이어야 합니다. 이렇게 하면 모든 관계자들이 같은 기대에 대해 잠재적 위기감을 느낄 수 있다.

백업 및 복구 전략의 중요성 테스트

백업 및 복구 전략을 사용하기 전에 테스트해야 합니다. 백업을 수행했지만 백업이 필요한 복구 목표를 지원하는지 여부를 모르는 경우 백업이 전혀 없는 것과 다르지 않습니다.

복구 전략은 환경에 대한 의존도 고려해야 한다. 예를 들어, 기계 하드 드라이브 고장, 공급업체는 얼마나 자주 새 하드 드라이브를 제공할 수 있습니까? 시스템을 다시 시작해야 할 때 운영 체제 관리자를 찾을 수 있습니까?

고려해야 할 또 다른 문제는 데이터베이스가 자연 파괴를 견딜 수 있는지 여부입니다. 백업 미디어는 자연 재해 시 호스트 및 백업 손상을 방지하기 위해 컴퓨터와 다른 곳에 보관해야 합니다.

고려해야 할 마지막 질문은 DBA 에 문제가 있으면 어떻게 합니까? 백업 DBA 가 백업 전략을 실행할 수 있습니까? 그 또는 그녀가 증빙 서류를 찾을 수 있습니까? 이 파일들이 있습니까?

많은 정력을 들여 좋은 계획을 지정하지만, 그 유효성을 테스트하지 않고, 그것을 동류하는 것보다 더 좋은 것은 없다. (아리스토텔레스, 니코마코스 윤리학, 노력명언) 좋은 계획은 또한 인간의 실수, 특히 개발을 위한 시스템을 고려해야 한다. 이상적인 테스트 계획에는 다음이 포함되어야합니다.

일련의 테스트 사례 및 상태 설명;

테스트 결과 성공 기준;

이러한 상태를 해결하는 단계.

DBA 는 위의 상황 테스트가 성공한 경우에만 백업 배치를 고려해야 합니다.