7장. Acronis True Image Home을 사용하여 데이터 백업 및 복원 오늘날 시장에는 다양한 백업 및 복구 제품이 있으며 우리는 이미 몇 가지 제품을 접했습니다.

프레스 센터

백업 및 복원

모든 데이터 센터의 기본적인 과제는 IT와 비즈니스 간에 서비스 수준 계약을 제공하는 것입니다. 비즈니스 요구 사항 충족의 핵심은 데이터 안전을 보장하는 것이므로 적절하게 구성된 데이터 센터의 데이터 스토리지 하위 시스템의 통합 인프라 블록은 데이터 백업 및 복구 시스템입니다.

SNIA(Storage Networking Industry Association)는 백업 작업을 다음과 같이 정의합니다.

• 백업 사본 - 일반적으로 원격으로 비휘발성 미디어에 저장된 데이터로, 데이터의 원본이 손실되거나 사용할 수 없는 경우 복구용입니다.
• 백업(영어 백업) - 생성 과정 백업.

모든 데이터 백업 시스템은 사용되는 복사 방법에 따라 파일별, 블록 또는 응용 프로그램 수준 데이터 백업의 세 가지 유형으로 나눌 수 있습니다.

블록 백업 시스템(영어 이미지 수준 또는 블록 수준 백업)은 파일 구조를 무시하고 운영 체제, 작업 데이터, 설정 등 모든 콘텐츠를 완전히 보존하면서 미디어와 직접 작동합니다. 이러한 유형의 백업을 수행하는 이점은 고속입니다. 그러나 복사 작업을 수행할 때 일반적으로 복사 일관성을 유지하기 위해 응용 프로그램을 일시 중지해야 합니다.

파일 수준에서 백업 작업을 수행할 때(영어 파일 수준 또는 파일 기반 백업) 파일 시스템이 사용됩니다. 이 경우 상대적으로 간단한 작업은 일부 특정 파일을 복원하는 것입니다. 일반적으로 백업 작업은 더 오래 걸리고 운영 체제에 추가 부하가 있으며 열린 파일에 액세스하는 문제도 있습니다.

애플리케이션 수준 백업에서도 백업을 만들 수 있습니다. 복사 및 복원 작업은 백업된 애플리케이션에서 특별히 제공되는 API(Application Programming Interface)를 사용하여 수행됩니다. 백업은 응용 프로그램 자체에서 정의한 파일 및 가능하면 다른 개체의 모음으로, 함께 특정 시점의 응용 프로그램 상태를 나타냅니다. ~에 이 방법해당 인터페이스를 구현하는 다른 버전의 응용 프로그램과 백업 시스템 간에 호환성 문제가 있을 수 있습니다.

백업 시스템은 데이터 센터의 서비스 하위 시스템이며 다음과 같은 기능이 있습니다.

• 백업 프로세스는 IS 작업을 해결하는 데 중요하지 않습니다. 백업 시스템의 장애는 중요한 정보 서비스의 가용성을 감소시키지 않습니다.
• 백업 프로세스가 생성하는 컴퓨팅 리소스에 대한 부하는 IS에 정보 서비스를 제공하는 측면에서 유용하지 않습니다.

백업 시스템을 구축할 때 다음을 수행해야 합니다.

축소된 백업 "창" 내에서 유지하십시오. 정보 서비스의 24시간(24x7) 운영 요구 사항으로 인해 백업 작업에 필요한 애플리케이션을 종료하는 데 사용할 수 있는 시간 간격("백업 창")이 줄어듭니다.
• 공유 회사 컴퓨터 네트워크에서 백업 데이터 트래픽을 줄입니다.

백업 방법.

LAN 백업
스토리지 네트워크가 등장하기 전(Storage 지역 네트워크- SAN) 메인 네트워크의 백업 트래픽을 줄이기 위해 전용 백업 네트워크를 사용하고 여러 카피 서버를 포함하는 다단계 구조를 사용했습니다. 복사 서버를 전용으로 지정하고 가장 많은 양의 정보를 처리하는 생산 서버에 "더 가까운" 네트워크에 배치하면 복사 서버와 생산 서버 간의 백업 트래픽을 현지화하고 공유 LAN의 로드를 줄일 수 있습니다.

LAN 무료 백업
SAN의 출현으로 백업 트래픽을 LAN을 통하지 않고 서버에서 직접 SAN에 연결된 저장 장치(일반적으로 테이프 라이브러리)로 전송할 수 있게 되었습니다. 이 방법을 "LAN 프리 백업"이라고 합니다. 이 방법을 사용할 때 서버 클라이언트는 다른 작업과 함께 SAN을 통해 액세스할 수 있는 저장 장치에 백업 데이터를 복사하는 서버 역할을 합니다. 동시에 LAN을 통해(TCP/IP 프로토콜을 통해) 제어 작업을 실행하고 복사 서버에 의한 작업 실행을 모니터링함으로써 백업 일정을 실행하는 작업이 백업 관리 서버에 할당됩니다. 따라서 LAN에서 백업 데이터 트래픽을 줄이는 문제가 해결됩니다.

그러나 "LAN 프리 백업" 방법은 "윈도우" 백업 문제를 해결하지 못합니다. 게다가, 이 방법클라이언트 서버에 추가 부하를 생성하여 백업 데이터 복사 서버의 추가 기능을 클라이언트 서버에 할당합니다. 일부 응용 프로그램에서는 작업을 중단하지 않고 백업할 수 있습니다(온라인 백업). 이는 많은 트랜잭션 응용 프로그램에서 구현되며 다음을 사용합니다. 특별 옵션열린 파일 복사 도구와 같은 백업 소프트웨어. 그러나 이러한 기술을 사용한다고 해서 대량의 데이터(테라바이트 이상)로 인해 기본 작업을 해결하는 데 필요한 시간을 허용 가능한 임계값 이상으로 늘릴 수 있는 생산 서버의 부하가 줄어들지는 않습니다.

서버리스 백업
이상적인 백업 체계는 클라이언트 서버의 컴퓨팅 리소스를 사용하거나 작업을 중단하지 않고 SAN을 통해 일부 타사 장치("Data Mover"라고 함)를 통해 클라이언트 서버 데이터를 스토리지 장치에 복사하는 것입니다. 이 백업 방법을 "서버리스 백업"이라고 합니다. "Data Mover" 역할은 생산 서버와 동일한 디스크 어레이에 연결된 이 전용 서버 또는 특수 장치인 라우터에 의해 수행될 수 있습니다.

CDP(지속적 데이터 보호기)
SNIA 정의에 따르면 CDP(Continuous Data Protection)는 데이터 변경 사항을 지속적으로 추적하고 원본 데이터와 독립적인 스토리지에 저장하여 과거 어느 시점으로든 복구할 수 있는 기술입니다. CDP 시스템은 블록, 파일 또는 애플리케이션 수준에서 구현될 수 있으며 최대 단일 쓰기 작업까지 모든 시점으로 객체의 세분화된 복구를 제공합니다. 이 정의에 따르면 모든 CDP 솔루션에는 다음과 같은 속성이 있습니다.

• 변경 사항을 지속적으로 모니터링하고 기록합니다.
• 모든 변경 사항은 별도의 논리적 장치에 저장됩니다.
• RPO(복원 지점)는 임의적이며 미리 정의하면 안 됩니다.

구현 예.

이 기사에서는 중소기업을 위한 데이터 백업 기술을 살펴보겠습니다.

고객이 묻는 일반적인 질문은 약 1GB 크기의 1C 시스템 데이터베이스와 약 300MB의 MS Access 고객 데이터베이스의 안전을 보장하는 것입니다. 모든 정보는 중요하며 하루 이상의 작업 손실은 바람직하지 않습니다. IT 부서에 할당된 예산은 100,000 루블을 초과하지 않습니다.

백업해야 하는 정보의 양, 백업을 저장하는 데 걸리는 시간, 백업의 원격 저장(오프라인)이 필요한지 여부 등 고객의 요구 사항을 이해해야 합니다.

고객이 향후 며칠 동안 데이터를 저장해야 하고 솔루션 비용이 최소화되어야 한다면 가장 간단하고 편리한 솔루션은 소규모 NAS(Network Attached Storage)일 것입니다. 이러한 장치가 생산됩니다. 다양한 제조사에서 2~12개의 디스크가 있고 기본 액세스 프로토콜인 CIFS, NFS, HTTP, iSCSI를 통해 액세스를 제공합니다. 솔루션의 블록 다이어그램은 그림 1에 나와 있습니다.

그림 1 NAS 스토리지.

이 솔루션의 비용은 저장량에 따라 15,000 ~ 70,000 루블입니다.

이 솔루션의 주요 단점은 스토리지 볼륨 증가에 따른 확장 불가능과 백업 성공 여부를 제어해야 한다는 것입니다.

백업 절차를 자동화하기 위해 특수 소프트웨어, 백업 생성 프로세스 및 복원 절차를 제어하고 테이프 장치를 포함한 다양한 저장 매체로 작업할 수 있습니다.

백업을 생성하기 위해 "무엇을, 어디서, 언제"를 규제하는 백업 정책이 생성됩니다. 어떤 데이터를 어디에, 얼마나 자주 저장해야 하는지. 중앙 집중식 백업 소프트웨어의 추가 기능을 사용하면 전체 데이터를 복원할 필요 없이 개별 문자와 데이터베이스 테이블을 복원할 수 있습니다. 백업을 테이프에 기록하면 재해 발생 시 백업을 원격으로 저장하고 중요한 데이터를 안전하게 보관할 수 있습니다. 아카이브 복사본을 저장하기 위해 테이프 미디어를 사용하면 데이터가 기록된 후 50년이 지난 데이터를 읽을 수 있습니다.

이러한 솔루션의 비용은 50,000 루블부터 시작되며 백업 및 백업 소프트웨어 저장용 서버가 포함됩니다.

강의 텍스트

주요 질문

강의 번호 15. 백업

소요 시간: 2시간(90분)

· 백업을 수행합니다.

· 백업 추적.

· 예약 백업.

Enterprise Manager, T-SQL 명령 또는 데이터베이스 백업 생성 마법사를 사용하여 백업할 수 있습니다. 대부분의 경우 데이터베이스 백업 생성 마법사를 사용하는 것이 가장 쉽지만 Enterprise Manager도 사용하기 쉽습니다. 반면에 T-SQL 명령은 여러 번 반복될 수 있는 SQL 스크립트에 배치될 수 있습니다. 요구 사항에 가장 적합한 방법을 사용해야 합니다.

백업 작업 자체는 물리적 장치나 논리 장치 . 물리적 장치는 테이프나 디스크 드라이브와 같은 하드웨어입니다. 운영 체제는 물리적 장치에 이름을 할당하며 해당 장치에 액세스하려면 해당 이름을 사용해야 합니다. 이러한 사전 할당된 이름은 기억하기 어려울 수 있으므로 물리적 장치에 대한 별칭(사용자 정의 대체 이름)을 생성할 수 있습니다. 이러한 별칭을 논리 장치라고 합니다. 이 논리적 장치는 SQL 서버, 논리적 백업 장치라고하는 SQL Server에서 백업에만 사용할 수 있습니다. 데이터를 논리 장치에 백업하려면 미리 장치를 생성해야 합니다. 백업을 수행하는 방법으로 이동하기 전에 논리적 백업 장치가 생성되는 방법을 살펴보겠습니다. 이 섹션의 예에서는 백업 논리 장치를 사용합니다. (물리적 장치를 시스템에 추가하는 방법에 대한 자세한 내용은 시스템 관리자에게 문의하십시오.)

T-SQL을 사용하여 백업 장치를 만들려면 sp_addumpdevice 저장 프로시저를 사용합니다. 다음과 같은 구문이 있습니다.

sp_addumpdevice device_type, logical_name, physical_name

device_type 매개변수의 값은 디스크 장치의 경우 디스크, 테이프 장치의 경우 테이프 또는 타사 소프트웨어를 백업 시스템에 연결하기 위한 파이프일 수 있습니다. logical_name 매개변수는 할당한 이름입니다. 이 기기; 이 이름은 BACKUP 및 RESTORE 문에서 장치를 참조하는 데 사용됩니다. physical_name 매개변수는 시스템이 장치 또는 파일에 할당한 이름입니다.

하나 이상의 백업 장치를 만든 후에는 백업을 수행할 수 있습니다.

Enterprise Manager를 사용하여 백업을 수행하려면 다음 단계를 완료하십시오.

1. 다음 방법 중 하나를 사용하여 SQL Server 백업 유틸리티를 호출합니다.

· Enterprise Manager의 왼쪽 창에서 서버 폴더를 확장한 다음 관리 폴더를 확장합니다. 백업을 마우스 오른쪽 버튼으로 클릭하고 상황에 맞는 메뉴에서 데이터베이스 백업을 선택합니다.

· Enterprise Manager의 왼쪽 창에서 서버 폴더를 확장하고 데이터베이스를 마우스 오른쪽 단추로 클릭하고 상황에 맞는 메뉴에서 모든 작업을 선택한 다음 데이터베이스 백업을 선택합니다.

· Enterprise Manager의 왼쪽 창에서 서버 폴더를 확장한 다음 데이터베이스 폴더를 클릭합니다. 오른쪽 창에서 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 상황에 맞는 메뉴에서 모든 작업을 선택한 다음 데이터베이스 백업을 선택합니다.

SQL Server 백업 대화 상자가 나타납니다(그림 16.1 참조).

그림 16.1 - SQL Server 백업 대화 상자의 일반 탭

2. 이 대화 상자의 상단 섹션에 있는 데이터베이스 드롭다운 목록에서 백업할 데이터베이스를 선택합니다. (1단계에서 세 번째 방법을 사용한 경우 적절한 데이터베이스 이름이 이미 선택되어 있습니다.) 이름 텍스트 상자에 백업 이름을 입력하여 이 자동 이름을 재정의할 수 있지만 백업 이름은 데이터베이스 이름에서 자동으로 생성됩니다. 설명 텍스트 상자에 백업에 대한 설명을 입력할 수도 있습니다. 이 설명은 데이터베이스를 복원할 때 중요할 수 있습니다. 예를 들어 테이블을 삭제하기 직전에 이 백업을 만든 경우 이 사실을 설명에 포함하는 것이 좋습니다. 새 데이터를 업로드하기 전에 백업을 수행한 경우 설명에 이 정보를 포함하십시오.

3. 이 대화 상자의 백업 섹션에서 백업 유형을 지정해야 합니다. 사용 가능한 선택 버튼은 선택한 데이터베이스에 따라 다릅니다. 예를 들어 Northwind 데이터베이스는 기본적으로 Truncate log on checkpoint로 설정됩니다. (생성 시 트랜잭션 로그 잘림 검문소). 이 경우 백업 프로그램에서 트랜잭션 로그와 파일 및 파일 그룹 선택 버튼을 사용할 수 없습니다. 백업 섹션에는 다음 선택 버튼이 있습니다.

데이터베이스 - 완료(데이터베이스 - 완료). 전체 데이터베이스 백업, 즉 해당 데이터베이스의 모든 데이터.

· 데이터베이스 - 차등. 차등 데이터베이스 백업, 즉 이전 백업 이후 변경된 모든 데이터.

· 트랜잭션 로그. 트랜잭션 로그 백업; 이렇게 하면 트랜잭션 로그도 잘립니다.

· 파일 및 파일 그룹(파일 및 파일 그룹). 하나의 파일 또는 파일 그룹 백업 이 파일 또는 파일 그룹을 지정해야 합니다.

이러한 백업 유형 중 하나만 선택할 수 있습니다. 전체 데이터베이스 백업과 트랜잭션 로그 백업을 수행하려면 이 백업 프로그램을 두 번 실행해야 합니다.

4. 대상(백업 복사본의 위치) 섹션에서 백업 복사본의 장치 유형을 테이프(테이프) 또는 디스크(디스크) 중에서 선택해야 합니다. 추가 버튼을 클릭하여 논리적 또는 물리적 백업 장치를 추가할 수 있습니다. 백업 대상 선택 대화 상자가 나타납니다(그림 16.2 참조).

그림 16.2 - 백업 대상 선택 대화 상자

이 대화 상자에서 파일 이름을 지정하거나 백업 장치 드롭다운 목록에서 백업 장치를 선택할 수 있습니다. 확인을 클릭하여 SQL Server 백업 대화 상자의 일반 탭으로 돌아갑니다. 그림 16.1의 예에서는 백업 대상 목록에 두 개의 장치가 있습니다. 장치를 제거하려면 장치를 강조 표시하고 제거 버튼을 클릭합니다. 장치의 내용을 보려면 내용 버튼을 클릭하십시오. 특정 백업 장치가 이전에 이미 사용된 경우 백업에 대한 다음 정보가 나타납니다.

· 이름(이름). 백업을 실행한 사람이 선택한 이름입니다.

· 서버(서버). 백업이 수행된 서버의 이름입니다.

· 데이터베이스. 백업된 데이터베이스의 이름입니다.

· 유형(유형). 백업 유형(전체, 차등, 트랜잭션 로그, 파일 그룹, 파일)

· 날짜(날짜). 백업 날짜 및 시간.

· 만료. 백업에 지정된 만료 날짜입니다.

· 크기(크기). 백업 세트의 총 크기입니다.

· 설명. 백업에 대해 제공된 설명입니다.

하나의 백업 장치에 여러 개의 백업을 생성할 수 있다는 점을 기억하십시오(실제로 자주 사용됨).

5. SQL Server 백업 대화 상자의 덮어쓰기 섹션에서 테이프 또는 디스크와 같은 미디어 덮어쓰기(덮어쓰기... 옵션 버튼)와 이전 데이터에 추가(추가... 옵션 버튼) 중에서 선택할 수 있습니다. . 그러나 테이프를 번갈아 사용하는 경우에는 이전 정보를 삭제해야 합니다. 이 대화 상자에서 기존 미디어 덮어쓰기 옵션 버튼을 클릭하여 이 정보를 덮어쓸 수 있지만 대신 정보를 백업하기 전에 지우는 것을 규칙으로 만들어야 합니다. 이렇게 하면 실수로 테이프나 디스크 장치를 덮어쓰지 않습니다.

6. 일정 섹션에서 다음 시간에 백업 실행 일정을 설정할 수 있습니다. 특정 시간. 예약된 백업은 전체 트랜잭션 로그를 방지하기 위해 정기적으로 수행할 수 있는 트랜잭션 로그 백업에 특히 유용합니다. 백업 일정을 설정하려면 일정 확인란을 선택한 다음 찾아보기 버튼(...)을 클릭하여 일정 편집 대화 상자를 표시합니다(그림 16.3 참조).

7. 이름 텍스트 상자에 일정 이름을 입력합니다. 일정 이름을 사용하면 각 백업에 대한 별도의 일정과 같은 여러 일정을 만들 수 있습니다.

그림 16.3 - 일정 편집 대화 상자

일정 유형 섹션에서 다음 일정 유형(옵션 단추 순서대로) 중 하나를 선택할 수 있습니다. SQL Server 에이전트가 시작될 때 자동으로 CPU가 사용 중이 아닐 때 백업을 한 번 실행하거나 반복합니다. 1회 백업 시작을 선택한 경우 팝업 달력 날짜(날짜)를 사용하여 백업 날짜를 선택하고 카운터 필드 시간(시간)을 사용하여 시간을 선택합니다.

반복 백업 일정을 설정하려면 반복 선택 버튼을 클릭하고 변경 버튼을 클릭합니다.

반복 작업 일정 편집 대화 상자가 나타납니다(그림 16.4 참조). 이 대화 상자는 일정을 만들기 위한 다양하고 유연한 옵션을 제공합니다. 매일(매일), 매주(매주) 또는 매월(매월) 옵션을 사용하여 해당 작업의 빈도와 기간을 지정할 수 있습니다.

8. 확인을 클릭하여 일정 편집 대화 상자로 돌아가고 확인을 다시 클릭하여 SQL Server 백업 대화 상자로 돌아간 다음 옵션 탭을 클릭합니다(그림 16.5 참조). 이 탭에서는 백업 완료 후 백업 미디어 확인 여부와 백업 미디어의 레이블(제목) 설정 여부 및 방법을 지정할 수 있습니다. 이 탭의 옵션은 아래에 설명되어 있습니다.

그림 16.4 - 반복 작업 일정 편집 대화 상자

그림 16.5 - SQL Server 백업 대화 상자의 옵션 탭

· 완료 시 백업을 확인합니다. 백업 미디어의 가독성 검사를 수행합니다. 복사본의 무결성만 검사합니다. 이 프로세스는 백업에 적절한 데이터가 포함되어 있는지 확인하지 않습니다.

· 백업 후 테이프 꺼내기(테이프 장치에만 해당). 백업이 완료되면 장치에서 테이프를 꺼냅니다. 이 플래그는 여러 응용 프로그램이나 사용자가 테이프 장치에 액세스하는 경우에 유용합니다. 이렇게 하면 다른 사용자가 테이프를 덮어쓰는 것을 방지할 수 있습니다.

· 트랜잭션 로그에서 비활성 항목을 제거합니다(트랜잭션 로그 백업에만 해당). 백업 후 트랜잭션 로그 잘림.

미디어 세트 이름 확인 및 백업만료 설정(백업 세트의 미디어 세트 이름 및 만료 날짜 확인).

· 백업 세트가 만료됨 - 테이프 장치만 해당. 이 미디어의 만료 날짜를 설정할 수 있습니다.

· 미디어를 초기화하고 레이블을 지정합니다(테이프 장치에만 해당). 이 미디어의 레이블을 설정할 수 있습니다.

9. 매개변수 설정이 완료되면 확인 버튼을 클릭하여 구성된 백업을 진행합니다.

T-SQL 문을 사용하여 데이터베이스를 백업하는 것은 처음에는 Enterprise Manager를 사용하는 것보다 조금 더 어려울 수 있습니다. 그러나 스크립트를 통해 작업을 자동화하는 것을 선호하는 유형의 관리자라면 이 방법이 더 편리할 것입니다. 게다가, T-SQL 문 BACKUP은 Enterprise Manager의 백업 프로그램보다 몇 가지 더 많은 옵션을 제공합니다. 이 섹션에서는 BACKUP 문의 구문과 매개변수를 살펴보겠습니다. 실제로 두 명의 백업 운영자가 있습니다. 사용할 연산자는 수행해야 하는 백업 유형에 따라 다릅니다. 다음 연산자는 다음과 같습니다.

백업 데이터베이스. 전체 데이터베이스 또는 파일 또는 파일 그룹을 백업하는 데 사용됩니다.

백업 로그. 트랜잭션 로그를 백업하는 데 사용됩니다.

이 두 연산자는 기본적으로 동일한 기능을 제공하므로 함께 고려할 것입니다.

전체 데이터베이스 백업을 위한 BACKUP 문에는 다음 구문이 있습니다.

이 문에서는 데이터베이스 이름과 백업 장치 이름만 필수 매개 변수입니다.

파일 또는 파일 그룹을 백업하기 위한 명령문의 구문은 다음과 같습니다.

백업 데이터베이스 database_name

파일 이름 또는 파일 그룹 이름 [,...n]

백업 장치로

[ 옵션 매개변수 포함 ]

이 명령문에 필요한 매개변수는 데이터베이스 이름, 파일 이름 또는 파일 그룹 이름, 백업 장치 이름뿐입니다. 여러 파일 이름 또는 파일 그룹 이름을 쉼표로 구분하여 지정할 수 있습니다.

트랜잭션 로그 백업 명령문의 구문은 다음과 같습니다.

백업 로그 database_name

([WITH\NO_LOG|TRUNCATE_ONLY)])

| ( 백업 장치로 )

[ 옵션 매개변수 포함 ]

이 문에 필요한 매개 변수는 데이터베이스 이름과 WITH NO_LOG 또는 WITH TRUNCATE_ONLY 옵션 또는 백업 장치의 이름뿐입니다. 그런 다음 원하는 옵션을 추가할 수 있습니다. NO_LOG 및 TRUNCATE ONLY 옵션은 동의어입니다. 둘 다 백업하지 않고 로그를 자르도록 지정합니다. BACKUP LOG 문에서 이러한 옵션 중 하나를 사용하면 시스템 오류가 발생하는 경우 로그 레코드가 저장되지 않으므로 데이터베이스를 오류 당시의 상태로 되돌릴 수 없습니다. 저장되었습니다. 이러한 설정은 권장되지 않습니다. 자신의 재량에 따라 사용하십시오.

위의 세 가지 백업 명령 모두에서 database_name은 백업될 데이터베이스를 나타냅니다. Backup_device는 논리적 백업 장치의 이름 또는 물리적 장치의 이름입니다. 물리적 장치가 지정된 경우 장치 이름 앞에 가 와야 합니다. 디스크 텍스트=, TAPE= 또는 PIPE=(장치 유형에 따라 다름). 단일 장치 또는 쉼표로 구분된 장치 집합을 지정할 수 있습니다.

표 16.1은 BACKUP 문에서 사용할 수 있는 추가 옵션을 나열합니다. 데이터베이스 또는 트랜잭션 로그만 백업하는 데 사용할 수 있는 옵션이 있는 경우 이 예외가 지정됩니다.

표 16.1 - BACKUP 문의 선택적 매개변수

위에서 설명한 대로 기존 미디어 데이터에 백업을 추가할지 아니면 미디어 데이터를 덮어쓸지 지정해야 합니다. 선택하는 옵션은 테이프에 들어갈 수 있는 데이터 양에 영향을 미칩니다. 테이프를 지우지 않고(또는 덮어쓰기를 비활성화하지 않고) 이미 사용 중인 테이프 장치에 데이터를 백업하는 경우 테이프 공간이 부족할 수 있습니다. 추가 모드에서 백업 프로그램은 테이프가 끝날 때까지 남은 공간만 사용합니다.

데이터베이스 복사

사용되는 데이터베이스는 3개의 시스템 데이터베이스(oktell, oktell_cc_temp 및 oktell_settings)와 Okapp 웹 클라이언트 모듈용 데이터베이스의 두 가지 범주로 나뉩니다. 복구 후 Oktell을 시작하려면 시스템 데이터베이스만 필요합니다. 나머지 데이터베이스는 웹 모듈 설정을 저장하려는 경우에만 필요합니다.

예를 들어 기본 WO_Module_journal은 모듈에서 사용됩니다. 잡지대화 기록의 태그를 저장합니다. WO_Module_dashboards 데이터베이스는 Okboard 대시보드 모듈이 작동하는 데 필요하며 사용된 지표에 대한 설정을 포함합니다.

1 단계.시스템 테이블은 DBAutoDailyBackup 설정이 비활성화되지 않는 한 기본적으로 매일 02:00 서버 시간에 자동으로 백업됩니다. 사본 생성은 특별한 방식으로 발생하며 사본을 남깁니다.

• 지난 2주 - 매일
• 3개월 후 - 일주일에 한 번
• 그 후 2년 - 매달
• 그럼 1년에 한번

DBBackupDir 매개변수에서 재정의하지 않는 한 모든 백업은 \oktell\server\Backup 폴더에 있습니다.

그러면 언제든지 백업을 만들 수 있습니다. 이렇게 하려면 다음으로 이동하십시오. 관리/일반 설정/데이터베이스 관리. 버튼을 클릭 데이터베이스 백업 만들기.

백업이 완료되면 생성된 백업은 폴더의 루트에서 사용할 수 있습니다. oktell\서버\백업.

2 단계다른 데이터베이스의 복사본을 만들려면 SQL Server Management Studio를 엽니다. 원하는 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 상황에 맞는 메뉴에서 작업을 선택한 다음 백업 만들기. 열리는 창에서 백업 생성 경로를 변경하고 복사를 시작하려면 확인을 클릭하십시오. 사본은 기본적으로 폴더에 생성됩니다. C:\프로그램 파일\마이크로소프트 SQL 서버\MSSQL11.OKTELL\MSSQL\백업\.

데이터베이스 복구

데이터베이스는 동일한 버전의 SQL Server 이상으로만 복원할 수 있습니다. 데이터베이스가 SQL Server 2008 R2에서 생성된 경우 SQL Server 2008로 복원할 수 없습니다.

1 단계. oktellserver 서비스를 중지합니다. 관리자 권한으로 명령 프롬프트를 시작하고 거기에 다음 줄을 입력하십시오.

인터넷 중지 oktellserver

2 단계 sa 계정으로 SQL Server Management Studio를 시작합니다.

• 로그인: sa
• 비밀번호: 123Oktell321

3단계이전에 Oktell 데이터베이스를 설치한 경우 제거해야 합니다. 이는 웹 모듈에서 사용하는 시스템 데이터베이스 및 데이터베이스에 적용됩니다.

4단계복구 프로세스를 시작하겠습니다. 시스템 데이터베이스( 시스템 기반데이터)를 누르고 데이터베이스 복원(백업 복원).

데이터베이스 사본이 있는 파일을 선택하십시오. 이렇게 하려면 열린 창에서 장치(장치) 항목을 선택하고 추가(추가)하고 예를 들어 백업 파일을 선택합니다. db_ok_130628.bak(이 경우 이것은 oktell 데이터베이스입니다).

창 상단에 복원 중인 데이터베이스의 이름을 입력합니다. 창 하단에서 데이터베이스 이름을 볼 수 있습니다. 체크하는 것을 잊지 마세요 복원하다(복원하다).

나머지 데이터베이스에 대해 동일한 작업을 반복합니다.

5단계데이터베이스를 복원한 후 전체 기능을 사용하려면 데이터베이스 사용자를 생성해야 합니다. 이렇게 하려면 다음 쿼리를 다운로드하고 실행합니다.

6단계데이터베이스를 타사 서버로 마이그레이션한 경우 서버 구성 파일의 설정을 확인하십시오. \oktell\server\oktell.ServerService.exe.config. DBConnectionString 키가 있는 라인에서 데이터베이스에 대한 링크, 로그인 및 비밀번호가 올바른지 확인하십시오. 기본적으로 연결 문자열은 다음과 같습니다.

Server=(local)\OKTELL;database=oktell;uid=AutelService;pwd=;pooling=true

값 대신 새 서버 이름을 지정해야 합니다. (로컬)\OKTELL. 예를 들어, SQL 서버는 IP 주소가 192.168.0.3인 WORK 서버로 이동됩니다. 따라서 매개변수에 다음을 지정해야 합니다. WORK\OKTELL. 이 설정으로 서버가 시작되지 않으면 인스턴스 없이 서버 이름만 지정해 보십시오. 일하다. 서버 이름 대신 IP 주소를 지정할 수 있습니다. 192.168.0.3/오케이텔또는 만 192.168.0.3 .

기본 AutelService 계정을 변경한 경우 필드에 새 사용자 이름과 암호를 지정해야 합니다. ID그리고 패스워드각기.

명령을 사용하여 항상 서버(인스턴스)의 이름을 찾을 수 있습니다.

Sqlcmd.exe -L

V 명령줄윈도우.

7단계서비스 시작 옥텔서버. 이렇게 하려면 명령줄에서 다음을 실행합니다.

알렉세이 베레즈니,시스템 관리자. 주요 활동: 가상화 및 이기종 네트워크. 기사 작성 외에 또 다른 취미는 자유 소프트웨어 대중화입니다.

지원
이론과 실습. 요약

백업 시스템을 가장 효과적으로 구성하려면 정보를 저장하고 복원하기 위한 실제 전략을 세워야 합니다.

백업 (또는 영어 단어 "백업"에서 백업이라고도 함)은 모든 IT 구조의 수명에서 중요한 프로세스입니다. 혹시 모를 재난에 대비한 구조용 낙하산입니다. 동시에 백업은 특정 수명 기간 동안 회사의 비즈니스 활동에 대한 일종의 기록 아카이브를 만드는 데 사용됩니다. 백업 없이 작업하는 것은 야외에서 생활하는 것과 같습니다. 날씨는 언제든지 악화될 수 있으며 숨을 곳이 없습니다. 그러나 중요한 데이터를 잃지 않고 환상적인 금액을 쓰지 않도록 올바르게 구성하는 방법은 무엇입니까?

일반적으로 백업 구성 주제에 관한 기사는 주로 기술 솔루션을 다루며 데이터 스토리지 구성 이론과 방법론에 가끔 주의를 기울입니다.

이 기사에서 우리는 정반대에 초점을 맞출 것입니다. 일반적인 개념, ㅏ 기술적 수단예시로만 다루겠습니다. 이를 통해 하드웨어와 소프트웨어를 추상화하고 "이 작업을 수행하는 이유는 무엇입니까?", "이 작업을 더 빠르고 저렴하며 안정적으로 수행할 수 있습니까?"라는 두 가지 주요 질문에 답할 수 있습니다.

백업의 목표 및 목표

백업을 구성하는 과정에서 장애가 발생한 경우 인프라 복원(재해 복구) 및 이후에 과거 기간 동안 정보에 대한 액세스를 제공하기 위해 데이터 아카이브를 유지 관리하는 두 가지 주요 작업이 설정됩니다.

재해 복구를 위한 백업의 전형적인 예는 Acronis True Image에서 생성한 서버 시스템 파티션 이미지입니다.

아카이브의 예로는 1C에서 데이터베이스를 매월 업로드하여 카세트에 기록하고 특별히 지정된 장소에 보관하는 것입니다.

빠른 복원 백업과 아카이브를 구별하는 몇 가지 요소가 있습니다.

• 데이터 보유 기간.보관 사본의 경우 상당히 깁니다. 경우에 따라 비즈니스 요구 사항뿐만 아니라 법률로도 규제됩니다. 재해 복구 사본의 경우 상대적으로 작습니다. 일반적으로 재해 복구를 위한 하나 또는 두 개의(신뢰성 요구 사항 증가) 백업이 하루나 이틀의 최대 간격으로 생성된 후 새 백업으로 덮어씁니다. 특히 중요한 경우 재해 복구를 위해 백업을 더 자주(예: 몇 시간에 한 번) 업데이트할 수도 있습니다.
• 데이터 액세스 속도.장기 아카이브에 대한 액세스 속도는 대부분의 경우 중요하지 않습니다. 일반적으로 문서를 조정할 때 "기간 동안 데이터를 수집"해야 할 필요성이 발생합니다. 이전 버전등, 즉, 긴급 모드. 또 하나는 재난 복구인데, 필요한 데이터와 서비스 성능을 최대한 빨리 돌려줘야 할 때다. 이 경우 백업에 대한 액세스 속도는 매우 중요한 지표입니다.
• 복사된 정보의 구성입니다.백업에는 일반적으로 지정된 기간 동안의 사용자 및 비즈니스 데이터만 포함됩니다. 이 데이터 외에도 재해 복구 복사본에는 시스템 이미지 또는 운영 체제 설정 및 응용 프로그램 소프트웨어의 복사본과 복구에 필요한 기타 정보가 포함되어 있습니다.

때로는 이러한 작업을 결합하는 것이 가능합니다. 예를 들어 월간 전체 "스냅샷"의 연간 세트 파일 서버, 주중에 변경된 사항. True Image는 이러한 백업을 생성하기 위한 도구로 적합합니다.

가장 중요한 것은 예약이 무엇인지 명확하게 이해하는 것입니다. 예를 들어 보겠습니다. 디스크 어레이 오류로 인해 중요한 SQL 서버가 실패했습니다. 우리는 올바른 재고가 있습니다 하드웨어, 그래서 문제에 대한 해결책은 소프트웨어와 데이터를 복원하는 것뿐이었습니다. 회사 경영진은 "언제 작동합니까? "라는 이해할 수있는 질문을합니다. -회복하는 데 최대 4시간이 걸린다는 사실에 불쾌하게도 놀랐습니다. 사실 서버의 전체 수명 동안 DBMS 자체의 소프트웨어를 포함한 모든 설정으로 서버 자체를 복원할 필요성을 고려하지 않고 데이터베이스만 정기적으로 백업되었습니다. 간단히 말해, 우리 영웅들은 데이터베이스만 저장하고 시스템은 잊어버린 것입니다.

또 다른 예를 들겠습니다. 전체 작업 기간 동안 젊은 전문가는 ntbackup 프로그램을 사용하여 파일 서버의 단일 복사본을 만들었습니다. 윈도우 컨트롤데이터 및 시스템 상태를 포함하여 Server 2003을 다른 컴퓨터의 공유 폴더에 저장합니다. 디스크 공간 부족으로 인해 이 사본을 지속적으로 덮어썼습니다. 얼마 후 저장 시 손상된 여러 페이지로 된 보고서의 이전 버전을 복원하라는 요청을 받았습니다. 섀도 복사본이 꺼져 있는 아카이브 기록이 없기 때문에 그는 이 요청을 이행할 수 없었습니다.

결과: 재해 복구와 아카이브 스토리지 모두에 두 가지 유형의 백업을 모두 사용해야 합니다. 동시에 복사할 리소스 목록, 작업 실행 시간, 백업 복사본을 저장할 위치, 방법 및 기간을 결정해야 합니다.

소량의 데이터와 그다지 복잡하지 않은 IT 인프라를 사용하여 이러한 작업을 하나로 결합할 수 있습니다. 예를 들어 모든 디스크 파티션과 데이터베이스의 일일 전체 백업을 수행할 수 있습니다. 그러나 여전히 두 가지 목표를 구별하고 각각에 적합한 수단을 선택하는 것이 좋습니다. 따라서 Acronis True Image 패키지 또는 ntbackup 프로그램과 같은 범용 솔루션이 있지만 각 작업에 대해 다른 도구가 사용됩니다.

백업의 목표와 목표, 구현 솔루션을 결정할 때 비즈니스 요구 사항에서 진행해야 한다는 것은 분명합니다.

재해 복구 작업을 구현할 때 다양한 전략을 사용할 수 있습니다.

경우에 따라 시스템을 "베어 메탈"(베어 메탈)로 직접 복원해야 합니다. 예를 들어 Universal Restore 모듈과 함께 제공되는 Acronis True Image 프로그램을 사용하여 이 작업을 수행할 수 있습니다. 이 경우 매우 짧은 시간 내에 서버 구성을 서비스로 되돌릴 수 있습니다. 예를 들어 운영 체제가 20GB인 파티션은 8분 안에 백업 복사본에서 들어 올릴 수 있는 매우 현실적입니다(아카이브 복사본이 1GB/s 네트워크를 통해 사용 가능한 경우).

또 다른 옵션에서는 설정을 새로 설치된 시스템으로 "되돌리는" 것이 더 편리합니다. 시스템 상태). 물론이 접근 방식을 사용하면 운영 체제가 설치되기 전에 서버가 작동되고 필요한 설정이 복원되므로 훨씬 더 많은 시간이 소요됩니다. 장기간. 그러나 어떤 경우든 재해 복구를 결정하는 것은 비즈니스 요구 사항과 리소스 제약에서 비롯됩니다.

백업과 중복 중복 시스템의 근본적인 차이점

또 하나야 관심 부탁하다만져보고 싶은 것. 이중화 하드웨어 이중화 시스템은 구성 요소 중 하나에 갑작스러운 장애가 발생하는 경우에도 작동성을 유지하기 위해 하드웨어에 일부 이중화를 도입하는 것을 말합니다. 이 경우의 완벽한 예는 RAID 어레이(독립 디스크의 중복 어레이)입니다. 단일 디스크 장애가 발생하는 경우 정보 손실을 방지하고 안전한 교체를 수행하여 디스크 어레이 자체의 특정 구성으로 인해 데이터를 절약할 수 있습니다(RAID 입력에 대해 자세히 알아보기).

"매우 안정적인 장비가 있고 모든 곳에 RAID 어레이가 있으므로 백업이 필요하지 않습니다."라는 말을 들었습니다. 예, 물론입니다. 하나의 하드 드라이브에 장애가 발생해도 동일한 RAID 어레이가 데이터를 파괴로부터 보호합니다. 그러나 이것은 컴퓨터 바이러스에 의한 데이터 손상이나 부적합한 사용자 작업으로부터 당신을 구하지 못할 것입니다. 무단 재부팅으로 인해 파일 시스템이 충돌하더라도 RAID를 저장하지 않습니다.

한 가지 예를 들겠습니다. 다음 시나리오에 따라 이벤트가 발생하는 경우가 있습니다. 디스크에 오류가 발생하면 중복 메커니즘으로 인해 특히 저장된 데이터를 사용하여 데이터가 복원됩니다. 체크섬. 동시에 성능이 크게 저하되고 서버가 정지되고 제어가 거의 손실됩니다. 다른 방법이 없는 시스템 관리자는 콜드 재시작(즉, "RESET" 클릭)으로 서버를 재부팅합니다. 이러한 라이브 과부하의 결과로 파일 시스템 오류가 발생합니다. 이 경우 기대할 수 있는 최선은 파일 시스템의 무결성을 복원하기 위해 디스크 검사기의 긴 작업입니다. 최악의 경우 작별 인사를해야합니다. 파일 시스템데이터 및 서버 성능을 복원할 수 있는 위치, 방법 및 기간에 대한 질문에 당황하게 됩니다.

클러스터 아키텍처에서도 백업을 피할 수 없습니다. 실제로 장애 조치 클러스터는 서버 중 하나에 장애가 발생해도 작동하도록 위임된 서비스를 유지합니다. 악명 높은 "인적 요소"로 인한 바이러스 공격이나 데이터 손상과 같은 위의 문제의 경우 클러스터가 저장되지 않습니다.

재해 복구에 대한 열악한 백업 대체품으로 작용할 수 있는 유일한 것은 주 서버에서 백업 서버로 데이터를 지속적으로 복제하는 미러 백업 서버가 있다는 것입니다(주  대기 원칙에 따름). 이 경우 메인 서버에 장애가 발생하면 백업 서버가 해당 작업을 인계받으며 데이터를 전송할 필요조차 없습니다. 그러나 이러한 시스템은 구성하는 데 비용이 많이 들고 시간이 많이 걸립니다. 지속적인 복제의 필요성을 잊지 마십시오.

이러한 솔루션은 내결함성과 최소 복구 시간에 대한 요구 사항이 높은 중요한 서비스의 경우에만 비용 효율적이라는 것이 분명해졌습니다. 일반적으로 이러한 계획은 상품 회전율이 높은 대규모 조직에서 사용됩니다. 그리고 이 구성표는 컴퓨터 바이러스, 부적합한 사용자 작업 또는 응용 프로그램의 잘못된 작동으로 인해 데이터가 손상된 경우 두 서버의 데이터 및 소프트웨어가 영향을 받을 수 있기 때문에 모두 동일하므로 백업을 대체할 수 없습니다.

물론 중복 중복 시스템은 특정 기간 동안 데이터 아카이브를 유지 관리하는 문제를 해결할 수 없습니다.

"백업 윈도우"의 개념

백업을 수행하면 중복 서버에 과부하가 걸립니다. 이것은 특히 디스크 하위 시스템과 네트워크 연결에 해당됩니다. 경우에 따라 복사 프로세스의 우선 순위가 충분히 높으면 특정 서비스를 사용할 수 없게 될 수 있습니다. 또한 변경 시 데이터를 복사하는 데 상당한 어려움이 있습니다. 물론 이 경우 데이터 무결성을 유지하면서 문제를 방지할 수 있는 기술적인 수단이 있지만 가능하면 이러한 즉석 복사는 피하는 것이 가장 좋습니다.

위에서 설명한 이러한 문제를 해결할 때의 탈출구는 백업 및 기타 작업 시스템의 상호 영향이 최소화되는 비활성 기간으로 복사본 생성 프로세스의 시작을 연기하는 것입니다. 이 기간을 "백업 창"이라고 합니다. 예를 들어, 8x5 공식(주당 5일 8시간 근무)으로 작업하는 조직의 경우 이러한 "창"은 일반적으로 주말과 야간입니다.

24x7 공식(24시간 연중무휴)에 따라 작동하는 시스템의 경우 최소 활동 시간이 서버에 높은 부하가 없는 기간으로 사용됩니다.

백업 유형

백업을 구성할 때 불필요한 재료 비용을 피하고 가능하면 백업 기간을 초과하지 않도록 특정 상황에 따라 사용되는 몇 가지 백업 기술이 개발되었습니다.

전체 백업(또는 전체 백업)

선택한 데이터 배열을 전체적으로 복사하는 백업 생성의 기본적이고 기본적인 방법입니다. 이것은 가장 비싸지만 가장 완전하고 신뢰할 수 있는 백업 유형입니다. 여러 개의 데이터 사본을 저장해야 하는 경우 총 저장 용량은 개수에 비례하여 증가합니다. 이러한 낭비를 방지하기 위해 압축 알고리즘과 이 방법을 증분 또는 차등 백업과 같은 다른 유형의 백업과 조합하여 사용합니다. 물론 처음부터 빠른 시스템 복원을 위해 백업을 준비해야 하는 경우 전체 백업은 필수 불가결합니다.

증분 복사

이 경우 전체 백업과 달리 모든 데이터(파일, 섹터 등)가 복사되지 않고 마지막 백업 이후 변경된 데이터만 복사됩니다. 다양한 방법을 사용하여 복사 시간을 결정할 수 있습니다. 예를 들어 Windows 제품군의 운영 체제를 실행하는 시스템에서 해당 파일 속성(아카이브 비트)이 사용됩니다. 백업 프로그램. 다른 시스템에서는 파일의 수정 날짜를 사용할 수 있습니다. 때때로 전체 백업을 수행하지 않으면 이러한 유형의 백업을 사용하는 체계가 열등할 것이라는 점은 분명합니다. 전체 시스템 복원을 사용하면 전체 백업으로 생성된 마지막 복사본에서 복원한 다음 생성된 순서대로 증분 복사본에서 데이터를 번갈아 "롤"해야 합니다.

이 유형의 사본은 무엇에 사용됩니까? 아카이브 사본을 생성하는 경우 저장 장치에서 사용되는 볼륨을 줄여야 합니다(예: 사용되는 테이프 미디어 수 줄이기). 또한 백업 작업을 완료하는 데 걸리는 시간을 최소화합니다. 이는 바쁜 24x7 일정으로 작업하거나 대량의 정보를 다운로드해야 할 때 매우 중요할 수 있습니다.

증분 복사에는 알아야 할 한 가지 뉘앙스가 있습니다. 점진적 복원으로 올바른 삭제된 파일회복 기간 동안. 예를 들어 보겠습니다. 예를 들어 전체 백업은 주말에 수행되고 증분 백업은 평일에 수행됩니다. 사용자는 월요일에 파일을 만들고 화요일에 변경하고 수요일에 이름을 바꾸고 목요일에 삭제했습니다. 따라서 매주 순차적인 단계별 데이터 복구를 사용하면 이름을 바꾸기 전 화요일에 이전 이름을 가진 파일과 수요일에 만든 새 이름을 가진 두 개의 파일을 얻게 됩니다. 서로 다른 증분 복사본이 저장되었기 때문에 이런 일이 발생했습니다. 다른 버전동일한 파일의 모든 변형이 복원됩니다. 따라서 "있는 그대로" 아카이브에서 데이터를 순차적으로 복원할 때 삭제된 파일도 들어갈 수 있도록 더 많은 디스크 공간을 예약하는 것이 좋습니다.

차등 백업

전체 백업의 마지막 순간부터 데이터가 복사된다는 점에서 증분 백업과 다릅니다. 이 경우 데이터는 발생 기준에 따라 아카이브에 저장됩니다. Windows 제품군의 시스템에서 이 효과는 차등 복사 중에 보관 비트가 재설정되지 않으므로 전체 복사가 보관 비트를 0으로 설정할 때까지 변경된 데이터가 보관 복사본에 저장된다는 사실에 의해 달성됩니다.

이렇게 생성된 각각의 새 사본에는 이전 사본의 데이터가 포함되어 있으므로 재해 발생 시 데이터를 완전히 복구하는 것이 더 편리합니다. 여기에는 두 개의 사본만 필요합니다. 전체 사본과 차등 사본의 마지막 사본이므로 모든 증분을 단계별로 롤링하는 것보다 훨씬 빠르게 데이터를 다시 생생하게 가져올 수 있습니다. 또한 이러한 유형의 복사는 위의 기능증분, 불사조 새와 같은 오래된 파일이 전체 복구 중에 잿더미에서 다시 태어날 때. 혼란이 적습니다.

하지만 차등 사본필요한 공간을 절약할 때 점진적으로 크게 손실됩니다. 각각의 새 사본은 이전 사본의 데이터를 저장하므로 백업된 데이터의 총량은 전체 사본과 비슷할 수 있습니다. 물론 일정을 계획할 때(그리고 백업 프로세스가 시간 창에 맞는지 여부를 계산할 때) 마지막으로 가장 두꺼운 차등 복사본을 만드는 시간을 고려해야 합니다.

백업 토폴로지

백업 구성표가 무엇인지 살펴보겠습니다.

분산 방식

이 체계의 핵심은 네트워크 공유입니다(그림 1 참조). 예를 들어 공유 폴더 또는 FTP 서버입니다. 서버 및 워크스테이션뿐만 아니라 다른 네트워크 개체(예: 라우터의 구성 파일)에서 이 리소스로 정보를 업로드하는 일련의 백업 프로그램도 필요합니다. 이러한 프로그램은 각 서버에 설치되며 서로 독립적으로 작동합니다. 의심 할 여지가없는 이점은이 체계의 구현이 쉽고 비용이 저렴하다는 것입니다. 운영 체제에 내장된 일반 도구나 DBMS와 같은 소프트웨어가 복사 프로그램으로 적합합니다. 예를 들어 Windows 계열의 ntbackup 프로그램, UNIX 계열 운영 체제의 tar 프로그램 또는 데이터베이스를 백업 파일로 덤프하기 위한 기본 제공 SQL 서버 명령이 포함된 스크립트 집합일 수 있습니다. 또 다른 장점은 백업을 저장하기 위해 모두 대상 리소스에 액세스할 수 있는 한 다양한 프로그램과 시스템을 사용할 수 있다는 것입니다.

단점은 이 체계의 속도가 느리다는 것입니다. 프로그램은 서로 독립적으로 설치되므로 각 프로그램을 개별적으로 구성해야 합니다. 대상 자원에 대한 경합을 피하기 위해 일정의 특성을 고려하고 시간 간격을 분배하는 것은 매우 어렵습니다. 모니터링도 어렵고 각 서버에서 복사하는 프로세스를 다른 서버와 별도로 모니터링해야 하므로 인건비가 많이 들 수 있습니다.

따라서 이 체계는 사용 가능한 도구를 사용하여 중앙 집중식 백업 체계를 구성할 수 없는 상황뿐만 아니라 소규모 네트워크에서 사용됩니다. 이 계획과 실제 조직에 대한 자세한 설명은 다음에서 찾을 수 있습니다.

중앙 집중식 백업

이전 체계와 달리 이 사례는 "클라이언트-서버" 원칙에 따라 작동하는 명확한 계층 모델을 사용합니다. 클래식 버전에서는 각 컴퓨터에 특수 에이전트 프로그램이 설치되고 소프트웨어 패키지의 서버 모듈이 중앙 서버에 설치됩니다. 이러한 시스템에는 전용 관리 콘솔도 있습니다. 서버 부분. 제어 체계는 다음과 같습니다. 콘솔에서 복사, 복원, 시스템 정보 수집, 진단 등에 대한 작업을 생성하고 서버는 에이전트에 이러한 작업을 수행하는 데 필요한 지침을 제공합니다.

Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula 등과 같이 널리 사용되는 대부분의 백업 시스템은 이 원칙에 따라 작동합니다(그림 2 참조).

대부분의 운영 체제에 대한 다양한 에이전트 외에도 널리 사용되는 데이터베이스를 백업하기 위한 개발이 있으며 기업 시스템, 예를 들어 MS SQL Server, MS Exchange, Oracle 데이터베이스 등의 경우.

소규모 회사의 경우 경우에 따라 에이전트 프로그램을 사용하지 않고 단순화된 버전의 중앙 집중식 백업 체계를 시도할 수 있습니다(그림 3 참조). 또한 사용되는 백업 소프트웨어에 대해 특수 에이전트가 구현되지 않은 경우 이 구성표를 사용할 수 있습니다. 대신 서버 모듈은 기존 서비스 및 서비스를 사용합니다. 예를 들어 Windows 서버의 숨겨진 공유 폴더에서 데이터를 "청소"하거나 UNIX 시스템을 실행하는 서버에서 SSH를 통해 파일을 복사합니다. 이 구성표에는 쓰기용으로 연 파일을 저장하는 문제와 관련된 매우 중요한 제한 사항이 있습니다. 그러한 행동의 결과 파일 열기건너뛰고 백업에 포함되지 않거나 오류와 함께 복사됩니다. 이전에 열린 파일만 복사하도록 작업을 다시 실행하는 등 이 문제에 대한 다양한 해결 방법이 있지만 신뢰할 수 있는 것은 없습니다. 따라서 이러한 체계는 특정 상황에서만 사용하기에 적합합니다. 예를 들어 5x8 모드로 작업하는 소규모 조직에서 훈련된 직원이 집을 떠나기 전에 변경 사항을 저장하고 파일을 닫습니다. 독점적으로 운영되는 잘린 중앙 집중식 체계를 구성하려면 윈도우 환경, ntbackup이 잘 작동합니다. 이기종 환경에서 또는 UNIX 컴퓨터 사이에서만 유사한 구성표를 사용해야 하는 경우 Backup PC를 살펴보는 것이 좋습니다(참조).

그림 4. 혼합 백업 구성표

오프사이트란?

격변하고 변화하는 세상에서 IT 인프라와 비즈니스 전체에 불쾌한 결과를 초래할 수 있는 이벤트가 발생할 수 있습니다. 예를 들어, 건물에 화재가 발생했습니다. 또는 서버 룸의 중앙 난방 배터리가 끊어졌습니다. 또는 장비 및 구성 요소의 진부한 도난. 이러한 상황에서 정보 손실을 방지하는 방법 중 하나는 서버 장비의 주 위치에서 떨어진 곳에 백업 복사본을 저장하는 것입니다. 동시에 제공할 필요가 있다. 빠른 길복구에 필요한 데이터에 액세스할 수 있습니다. 설명된 방법을 오프 사이트(즉, 기업 외부에 복사본 저장)라고 합니다. 기본적으로 이 프로세스를 구성하는 두 가지 방법이 사용됩니다.

이동식 미디어에 데이터 쓰기 및 물리적 이동. 이 경우 장애가 발생할 경우 미디어를 신속하게 다시 전달할 수 있는 수단에 주의해야 합니다. 예를 들어 가까운 건물에 보관하십시오. 이 방법의 장점은 이 프로세스를 어려움 없이 구성할 수 있다는 것입니다. 단점은 미디어 반환이 복잡하고 보관을 위해 정보를 전송해야 할 필요성과 운송 중에 미디어가 손상될 위험이 있다는 것입니다.

네트워크 링크를 통해 데이터를 다른 위치로 복사합니다. 예를 들어 인터넷을 통해 VPN 터널을 사용합니다. 이 경우 장점은 정보가 있는 미디어를 어딘가에 휴대할 필요가 없다는 것입니다. 단점은 충분히 넓은 채널을 사용해야 하고(일반적으로 매우 비쌉니다) 전송된 데이터를 보호해야 한다는 것입니다(예: 동일한 VPN). 대용량 데이터 전송의 어려움은 압축 알고리즘이나 중복 제거 기술을 사용하여 크게 줄일 수 있습니다.

별도로 데이터 저장 조직의 보안 조치를 언급할 가치가 있습니다. 우선, 데이터 캐리어가 보안실에 있는지 확인하고 권한이 없는 사람이 데이터를 읽지 못하도록 하는 조치에 대해 주의해야 합니다. 예를 들어 암호화 시스템을 사용하고 비공개 계약을 체결하는 등의 작업을 수행합니다. 이동식 미디어가 포함된 경우 해당 미디어의 데이터도 암호화해야 합니다. 사용된 마킹 시스템은 데이터 분석에서 공격자를 도와서는 안 됩니다. 이름 캐리어에 레이블을 지정하려면 얼굴 없는 번호 매기기 체계를 사용해야 합니다. 전송된 파일. 네트워크를 통해 데이터를 전송할 때 VPN 터널과 같은 안전한 데이터 전송 방법을 사용해야 합니다(위에서 이미 언급한 대로).

백업을 구성할 때 주요 사항을 분석했습니다. 다음 부분에서는 방법론적 권장 사항을 고려하고 실용적인 예효율적인 백업 시스템을 만들 수 있습니다.

1. 백업에 대한 설명 윈도우 시스템, 시스템 상태 포함 - http://www.datamills.com/Tutorials/systemstate/tutorial.htm .
2. 섀도 복사본에 대한 설명 - http://ru.wikipedia.org/wiki/Shadow_Copy .
3. Acronis 공식 웹사이트 - http://www.acronis.ru/enterprise/products .
4. ntbackup에 대한 설명은 http://en.wikipedia.org/wiki/NTBackup입니다.
5. Berezhnoy A. MS SQL Server 작업 최적화. // 시스템 관리자, No. 1, 2008 - P. 14-22 ().
6. Berezhnoy A. 우리는 중소 규모 사무실을 위한 백업 시스템을 구성합니다. // 시스템 관리자, No. 6, 2009 - P. 14-23 ().
7. Windows를 보호하는 Markelov A. Linux. BackupPC 백업 시스템의 개요 및 설치. // 시스템 관리자, No. 9, 2004 - P. 2-6 ().
8. VPN 설명 - http://ru.wikipedia.org/wiki/VPN.
9. 데이터 중복 제거 - http://en.wikipedia.org/wiki/Data_deduplication .

접촉