Microsoft SQL Server 데이터베이스 백업. MS SQL 백업 자동 SQL 백업

배아 이식 후 임신 징후

이전 자료에서 이미 문제를 다루었음에도 불구하고 사본 예약마이크로소프트 기지 SQL 서버, 독자의 반응은 이론적 부분에 대한 더 깊은 연구와 함께 본격적인 자료를 만들 필요성을 보여주었습니다. 실제로 실용적인 지침에 중점을 둔 기사를 사용하면 백업을 빠르게 설정할 수 있지만 특정 설정을 선택하는 이유는 설명하지 않습니다. 이 격차를 해결해 봅시다.

복구 모델

백업을 설정하기 전에 복구 모델을 선택해야 합니다. 을위한 최적의 선택복구 요구 사항과 데이터 손실의 중요성을 특정 모델 구현의 간접비와 비교하여 평가해야 합니다.

아시다시피 MS SQL 데이터베이스는 데이터베이스 자체와 데이터베이스에 대한 트랜잭션 로그의 두 부분으로 구성됩니다. 데이터베이스에는 현재 시간의 사용자 및 서비스 데이터가 포함되고 트랜잭션 로그에는 특정 기간 동안의 모든 데이터베이스 변경 이력이 포함되며 트랜잭션 로그가 있으면 데이터베이스 상태를 임의의 시점으로 롤백할 수 있습니다.

프로덕션 환경에서 사용할 수 있도록 두 가지 복구 모델이 제공됩니다. 간단하고 완전한. 가 있는 모델도 있습니다. 불완전한 로깅, 그러나 기반을 복원할 필요가 없는 대규모 대량 작업 기간 동안 전체 모델에 추가로 권장됩니다. 어떤 순간시각.

단순한 모델각각 데이터베이스만 백업하도록 제공하며, 백업 시에만 데이터베이스 상태를 복원할 수 있습니다. 마지막 백업 생성과 실패 사이의 기간에 있는 모든 변경 사항은 손실됩니다. 같은 시간에 간단한 회로오버헤드가 적습니다. 데이터베이스 복사본만 저장하면 되고 트랜잭션 로그는 자동으로 잘리고 크기가 커지지 않습니다. 또한 복구 프로세스가 가장 간단하고 시간이 많이 걸리지 않습니다.

완전한 모델데이터베이스를 임의의 시점으로 복원할 수 있지만 데이터베이스 백업 외에도 복원이 필요할 수 있는 전체 기간 동안 트랜잭션 로그 복사본을 저장해야 합니다. 데이터베이스에 대한 활성 작업 중에 트랜잭션 로그의 크기와 결과적으로 아카이브의 크기가 커질 수 있습니다. 복구 프로세스도 훨씬 더 복잡하고 시간이 많이 걸립니다.

복구 모델을 선택할 때 복구 비용을 백업 저장 비용과 비교해야 하며 복구를 수행할 직원의 가용성과 자격도 고려해야 합니다. 전체 모델을 사용하여 복구하려면 직원의 특정 자격과 지식이 필요하지만 간단한 구성에서는 지침을 따르는 것으로 충분합니다.

소량의 정보가 추가된 데이터베이스의 경우 복사 빈도가 높은 단순 모델을 사용하는 것이 더 유리할 수 있습니다. 이렇게 하면 손실된 데이터를 수동으로 입력하여 신속하게 복구하고 작업을 계속할 수 있습니다. 전체 모델은 데이터 손실을 허용할 수 없고 복구 가능성이 상당한 비용과 관련된 경우 무엇보다도 먼저 사용해야 합니다.

백업 유형

데이터베이스의 전체 복사본- 이름에서 알 수 있듯이 백업이 형성된 시간 동안 데이터베이스의 내용과 활성 트랜잭션 로그의 일부를 나타냅니다(즉, 모든 현재 및 불완전한 트랜잭션에 대한 정보). 백업이 생성된 시점으로 데이터베이스를 완전히 복원할 수 있습니다.

델타 데이터베이스 복사본- 전체 사본에는 데이터베이스의 모든 정보가 포함되는 한 가지 중요한 단점이 있습니다. 만약에 백업꽤 자주 수행해야 하는 경우 대부분의 스토리지가 동일한 데이터로 점유되기 때문에 디스크 공간의 낭비적인 사용에 대한 문제가 즉시 발생합니다. 이 단점을 극복하기 위해 마지막 전체 백업 이후 변경된 정보만 포함하는 데이터베이스의 차등 복사본을 사용할 수 있습니다.

차등 복사는 마지막 순간의 데이터입니다. 완벽한복사, 즉 각각의 후속 차등 복사본에는 이전 데이터의 데이터가 포함되며(변경될 수 있음) 복사본의 크기는 지속적으로 증가합니다. 복원에는 하나의 전체 백업과 하나의 차등 백업이 필요하며 일반적으로 마지막 백업이 필요합니다. 차등 복사본의 수는 크기 증가에 따라 선택해야 합니다. 차등 복사본의 크기가 전체 복사본의 절반 크기와 비교되는 즉시 새 전체 복사본을 만드는 것이 좋습니다.

트랜잭션 로그 백업- 전체 복구 모델에만 적용되며 이전 복사본이 생성된 순간부터 트랜잭션 로그 복사본을 포함합니다.

다음 사항을 기억하는 것이 중요합니다. 트랜잭션 로그의 복사본은 어떤 식으로든 데이터베이스 복사본과 관련이 없고 이전 복사본의 정보를 포함하지 않으므로 데이터베이스를 복원하려면 연속적인 복사본 체인이 있어야 합니다. 데이터베이스 상태를 롤백할 수 있는 기간입니다. 이 경우 마지막 복사가 성공한 순간은 이 기간 내에 있어야 합니다.

위의 그림을 보면 로그 파일의 첫 번째 복사본이 유실된 경우 전체 복사 시에만 데이터베이스의 상태를 복원할 수 있으며 이는 단순 복구 모델과 유사하게 복원할 수 있습니다. 데이터베이스의 상태를 다음 차등(또는 전체) 복사 이후의 특정 시점으로 변경합니다. 단, 복사 이전의 데이터베이스에서 시작하여 계속되는 로그 복사본 체인(그림에서 - 세 번째 이상부터).

트랜잭션 로그

복구 프로세스와 다양한 백업 유형의 목적을 이해하려면 트랜잭션 로그의 구조와 작동을 보다 자세히 고려해야 합니다. 트랜잭션은 의미가 있고 전체로만 완료될 수 있는 가능한 가장 작은 논리 연산입니다. 이 접근 방식은 작업의 중간 상태가 허용되지 않기 때문에 어떤 상황에서도 데이터의 무결성과 일관성을 보장합니다. 트랜잭션 로그는 데이터베이스의 모든 변경 사항을 제어하도록 설계되었습니다.

어떤 작업이 수행되면 트랜잭션 시작에 대한 항목이 트랜잭션 로그에 추가되고 각 항목이 할당됩니다. 고유 번호(LSN) 중단되지 않은 시퀀스에서 데이터가 변경되면 해당 항목이 로그에 만들어지고 작업이 완료된 후 로그에 트랜잭션 닫기(커밋)에 대한 표시가 나타납니다.

시작할 때마다 시스템은 트랜잭션 로그를 분석하고 커밋되지 않은 모든 트랜잭션을 롤백하는 동시에 로그에 커밋되었지만 디스크에 기록되지 않은 변경 사항은 롤포워드됩니다. 이를 통해 백업 전원 시스템이 없는 경우에도 데이터 무결성에 대한 두려움 없이 캐싱 및 다시 쓰기를 사용할 수 있습니다.

활성 트랜잭션을 포함하고 데이터 복구에 사용되는 로그 부분을 로그의 활성 부분이라고 합니다. 최소 복구 번호(MinLSN)라는 숫자로 시작합니다.

가장 간단한 경우 MinLSN은 첫 번째 보류 트랜잭션의 레코드 번호입니다. 위의 그림을 보면 파란색 트랜잭션을 열면 MinLSN이 321과 같게 됩니다. 레코드 324에서 고정된 후 MinLSN 번호는 323으로 변경되며, 이는 녹색 트랜잭션 번호에 해당합니다. 아직 커밋되었습니다.

실제로는 상황이 조금 더 복잡합니다. 예를 들어 닫힌 파란색 트랜잭션의 데이터가 아직 디스크로 플러시되지 않을 수 있으며 MinLSN을 323으로 이동하면 이 작업을 복구할 수 없습니다. 이러한 상황을 피하기 위해 개념 검문소. 다음 조건이 발생하면 체크포인트가 자동으로 생성됩니다.

  • CHECKPOINT를 명시적으로 실행할 때. 체크포인트는 현재 연결 데이터베이스에서 실행됩니다.
  • 대량 로그 복구 모델이 적용되는 데이터베이스에서 대량 복사 작업을 수행하는 경우와 같이 데이터베이스에서 최소 로그 작업을 수행하는 경우.
  • ALTER DATABASE 문을 사용하여 데이터베이스 파일을 추가하거나 제거하는 경우.
  • SHUTDOWN 문을 사용하여 SQL Server 인스턴스를 중지하거나 SQL Server(MSSQLSERVER) 서비스를 중지하는 경우. 두 경우 모두 SQL Server 인스턴스의 각 데이터베이스에 대해 검사점이 만들어집니다.
  • SQL Server 인스턴스가 주기적으로 각 데이터베이스에 자동 검사점을 만들어 데이터베이스 복구 시간을 줄이는 경우.
  • 데이터베이스 백업을 생성할 때.
  • 데이터베이스를 종료해야 하는 작업을 수행할 때. 예에는 AUTO_CLOSE를 ON으로 설정하고 데이터베이스에 대한 사용자의 마지막 연결 닫기 또는 데이터베이스를 다시 시작해야 하는 데이터베이스 설정 변경이 포함됩니다.

어떤 이벤트가 먼저 발생했는지에 따라 MinLSN은 체크포인트 레코드 번호 또는 가장 오래된 보류 트랜잭션의 시작으로 설정됩니다.

트랜잭션 로그 잘림

모든 로그와 마찬가지로 트랜잭션 로그는 사용되지 않는 레코드를 주기적으로 정리해야 합니다. 그렇지 않으면 사용 가능한 모든 공간이 커져서 차지하게 됩니다. 데이터베이스에 대한 활성 작업 중에 트랜잭션 로그의 크기가 데이터베이스의 크기를 크게 초과할 수 있다는 점을 고려하면 이 문제는 많은 관리자에게 관련이 있습니다.

물리적으로 트랜잭션 로그 파일은 로그가 커짐에 따라 순차적으로 채워지는 가상 로그의 컨테이너입니다. MinLSN 항목이 포함된 논리 로그는 활성 로그의 시작 부분이며 그 앞에 있는 논리 로그는 비활성 상태이며 자동 데이터베이스 복구에 필요하지 않습니다.

단순 복구 모델을 선택한 경우 논리 로그가 실제 파일의 70%와 같은 크기에 도달하면 로그의 비활성 부분이 자동으로 지워집니다. 잘림. 그러나 이것은 물리적 로그 파일을 줄이는 것이 아니라 이 작업 후에 재사용할 수 있는 논리적 로그만 잘립니다.

트랜잭션 수가 많고 실제 파일 크기가 70%에 도달할 때까지 비활성 논리 로그가 없으면 실제 파일 크기가 증가합니다.

따라서 단순 복구 모델의 트랜잭션 로그 파일은 로그의 전체 활성 부분을 안정적으로 포함할 때까지 데이터베이스 작업 활동에 따라 증가합니다. 그 후에는 성장이 멈출 것입니다.

전체 모델의 경우 로그의 비활성 부분은 완전히 백업될 때까지 자를 수 없습니다. 트랜잭션 로그를 백업한 후 체크포인트를 생성한 상태에서 로그 잘라내기를 수행합니다.

전체 모델에서 트랜잭션 로그 백업을 제대로 설정하지 않으면 로그 파일이 제어할 수 없을 정도로 커질 수 있으며 이는 경험이 부족한 관리자에게 종종 문제가 됩니다. 트랜잭션 로그를 수동으로 자르는 팁도 종종 있습니다. 전체 복구 모델을 사용하면 이 작업을 범주적으로 수행하면 안 됩니다. 이렇게 하면 로그 복사본 체인의 무결성을 위반하고 복사본이 생성된 시점에만 데이터베이스를 복원할 수 있기 때문입니다. 단순한 모델.

이 경우 우리가 기사의 시작 부분에서 이야기 한 것을 기억할 때입니다. 전체 모델의 비용이 복원 비용을 초과한다면 간단한 모델이 선호되어야합니다.

단순 복구 모델

이제 필요한 최소한의 지식을 얻은 후에 복구 모델에 대한 더 자세한 고려 사항으로 넘어갈 수 있습니다. 간단한 것부터 시작하겠습니다. 장애가 발생했을 때 하나의 전체 복사본과 두 개의 차등 복사본이 있다고 가정해 보겠습니다.

백업은 1일 1회 수행하였으며, 마지막 복사본은 21일~22일 밤에 생성하였다. 다음 복사본이 생성되기 전인 22일 저녁에 실패가 발생합니다. 이 경우 전체 및 최신 차등 백업을 순차적으로 복원해야 하며 마지막 영업일의 데이터는 손실됩니다. 어떤 이유로 21 일의 사본도 손상된 것으로 판명되면 이전 사본을 복원하여 다른 작업 일을 잃을 수 있지만 동시에 20 일 사본의 손상으로 인해 적절한 사본으로 21일 저녁에 데이터를 성공적으로 복원했습니다.

완전한 복구 모델

유사한 상황을 고려하지만 전체 복구 모델을 사용합니다. 우리는 또한 전체 + 차등 원칙에 따라 매일 백업을 수행하고 트랜잭션 로그는 하루에 여러 번 복사됩니다.

이 경우 복구 프로세스가 더 복잡해집니다. 우선, 최종 로그 조각(빨간색으로 표시)의 수동 백업을 생성해야 합니다. 복사본이 마지막으로 생성된 시간부터 충돌 이전까지의 로그 일부입니다.

이 작업이 수행되지 않으면 트랜잭션 로그의 마지막 복사본이 생성된 시점의 상태로만 데이터베이스를 복원할 수 있습니다.

동시에 전날의 로그 복사본 파일이 손상되더라도 데이터베이스의 현재 상태를 복원할 수 없지만 마지막 복사본이 생성된 순간으로 제한됩니다. 현재 일.

그런 다음 마지막 백업 이후에 생성된 로그의 전체 및 차등 복사본과 체인 복사본을 순차적으로 복원합니다. 사고의 시간 또는 그 이전의 임의의 시간.

마지막 차등 복사본이 손상된 경우 단순 모델의 경우 다른 작업일이 손실되며 전체 모델을 사용하면 끝에서 두 번째 복사본을 복원할 수 있으며 그 후에 전체 체인을 복원해야 합니다. 두 번째 복사본이 발생한 순간부터 오류가 발생한 시점까지의 트랜잭션 로그 복사본입니다. 복구 깊이는 연속 로그 체인의 깊이에만 의존합니다.

반면에 트랜잭션 로그 복사본 중 하나가 손상되면(예: 끝에서 두 번째 복사본) 손상되지 않은 로그 복사본 체인에서 마지막 백업 복사본 시간 + 기간으로만 데이터를 복원할 수 있습니다. 예를 들어, 로그가 12:00, 14:00 및 16:00에 생성되었고 14:00에 생성된 로그가 손상된 경우 매일 복사본이 있으면 연속 체인이 끝날 때까지 데이터베이스를 복원할 수 있습니다. 12시까지.

MS SQL Server 데이터베이스에서 테이블을 복사하는 방법에는 여러 가지가 있습니다. 테이블 사본을 생성하기 위한 몇 가지 옵션을 제공합니다. 선택할 것은 테이블의 구조, 인덱스, 트리거 등의 존재 여부, 손으로 무언가를 하려는 욕구에 따라 다릅니다.

1. 테이블 구조를 수동으로 복사하는 방법

Microsoft SQL Management Studio에서 데이터베이스를 선택하고 테이블을 선택하고 마우스 오른쪽 버튼을 클릭하고 "Script Table as" -> "CREATE TO" -> "New Query Editor Window"를 선택합니다. 쿼리 창에서 테이블을 생성하는 코드가 열립니다. 여기에는 테이블의 복사본을 만들려는 데이터베이스의 이름을 지정해야 하며 데이터베이스가 변경되지 않으면 새 이름을 지정해야 합니다. 기존 테이블의 구조를 생성하는 코드를 생성하는 방법은 아래 그림과 같습니다.

이 방법은 테이블 인덱스를 생성하지만 복사 트리거는 생성하지 않습니다. 같은 방식으로 복사해야 합니다.

이미 생성된 테이블에 데이터를 복사하려면 다음 SQL 쿼리를 사용해야 합니다.

..tmp_tbl_Deps에 INSERT SELECT * FROM ..tbl_Deps

2. 쿼리가 있는 SQL 테이블을 한 줄로 복사

동일한 데이터베이스 내에서 테이블 구조와 데이터의 복사본을 만듭니다.

SELECT * tmp_tbl_Dep FROM tbl_Deps로

한 데이터베이스에서 다른 데이터베이스로 테이블 구조와 해당 데이터를 복사합니다.

SELECT * ..tmp_tbl_Deps FROM ..tbl_Deps

이 솔루션의 단점은 인덱스가 복사되지 않는다는 것입니다.

이 문서는 MS SQL 복구를 위한 솔루션에 전념합니다. 우리는 MS SQL 데이터베이스 복구를 위한 솔루션을 계획하고 선택할 때 고려해야 할 주요 사항과 중요한 세부 사항을 고려하려고 노력할 것입니다.

MS SQL 재해 복구 계획 내에서 RTO(복구 시간 목표)와 RPO(복구 시점 목표)라는 두 가지 매개변수가 특히 중요합니다.

즉, RPO는 마지막 백업 순간부터 사고가 발생한 순간까지 중요하지 않은 양의 데이터(정보)가 손실되는 시간입니다. RTO는 사고가 발생한 순간부터 서비스/시스템을 서비스로 복구하는 데 필요한 허용 시간입니다. 두 매개변수 모두 변수 값을 가지며 특정 시스템의 요구 사항에 따라 다릅니다. 따라서 설정된 RPO 및 RTO를 수행하기 위해서는 적절한 백업 계획이 필요합니다. 예를 사용하여 가능한 긴급 사고를 분석하고 SQL 서버의 실패 지점과 해결 방법을 강조해 보겠습니다.

지정된 각 사건에 대해 사건의 결과를 피하기 위한 모든 범위의 조치가 있습니다.

고가용성 MS SQL

RPO 및 RTO(초/분)에 대한 요구 사항이 높기 때문에 MS SQL 내결함성을 보장하는 유일한 솔루션은 고가용성 서버 기술의 구성입니다.

  • 내장 MS SQL 및 OS 윈도우 서버 AlwaysOn 기술을 사용하는 것을 포함하여 장애 조치 클러스터 WSFC(Windows Server 장애 조치 클러스터)를 구현하여 고가용성(고가용성)을 달성할 수 있습니다. 장애 조치 클러스터는 두 개 이상의 노드/서버로 구성됩니다. 활성 서버에 장애가 발생하면 사용 가능한 다른 서버로 장애 조치되어 활성 상태가 됩니다. 이 경우 서버에서 호스팅된 모든 서비스는 사용 가능한 다른 노드로 자동 또는 수동으로 전송됩니다.
  • MS SQL 가상 머신의 경우 VMware HA 클러스터 또는 Hyper-V 고가용성 가상화 도구를 사용하여 고가용성을 제공할 수 있습니다. 이 경우 물리적 서버에 장애가 발생하면 자동으로 시작할 수 있습니다. 가상 기기다른 클러스터 서버에서.

두 방법 모두 필요한 경우 별도로 또는 함께 구현할 수 있습니다. 클러스터링은 하드웨어 오류를 빠르게 수정하도록 설계되었습니다.

고가용성 MS SQL의 이점:

  • 노드에서 노드로의 즉각적인 전환, 가동 중지 시간 없음
  • 물리적 서버에 의존하지 않고
  • 데이터베이스 작업을 중단하지 않고 서버를 유지 관리할 수 있습니다.

고가용성 MS SQL의 단점:

  • 구현에는 추가 인프라와 리소스가 필요합니다.
  • 라이센스 및 장비 솔루션의 높은 비용
  • 보다 복잡하고 수준 높은 서비스

백업 MS SQL

RTO 및 RPO에 대한 요구 사항이 높지 않고 고가용성(클러스터링)이 필요하지 않은 경우 물리적 또는 가상 서버에서 MS SQL 데이터베이스의 내결함성을 보장합니다. 필요조건백업입니다. 이렇게하려면 내장 된 SQL 함수다양한 MS SQL 백업 방법을 지원하는 별도의 특수 시스템을 사용하거나 서버를 사용합니다. 예:

이러한 시스템은 데이터베이스 서버 작동에서 하드웨어 및 소프트웨어 오류를 모두 방지하는 데 도움이 됩니다.

RTO 및 RPO 값을 계산한 후 SQL 서버 구성 계획을 진행할 수 있습니다. 이러한 가치를 달성하기 위해 위에 나열된 고가용성 기술과 데이터베이스 백업을 모두 사용할 수 있습니다.

백업 MS SQL 정책

  • 백업은 원본 데이터베이스 파일과 다른 물리적 미디어에 있어야 합니다.
  • 테스트 서버(샌드박스)를 사용하여 백업 복원 절차 테스트
  • 당신의 일상을
  • 가능한 한 자주하십시오. 저장 공간을 훨씬 적게 차지하고 데이터 손실 위험을 더욱 줄입니다.
  • 가능한 한 자주 트랜잭션 로그를 백업하십시오. 트랜잭션 로그에는 모든 것이 포함됩니다. 최근 활동데이터베이스에서 발생했습니다. 로그는 데이터베이스를 특정 시점으로 복원하는 데 사용할 수 있으며 이것이 가장 큰 이점입니다. 트랜잭션 로그 백업은 시스템이 실행되는 동안 수행할 수 있습니다. 데이터베이스에서 새 데이터가 생성되는 빈도가 매우 높으면 10분마다 트랜잭션 로그를 백업할 수 있지만 덜 활성화된 다른 데이터베이스의 경우 이러한 백업을 30분 또는 60분마다 수행할 수 있습니다.
  • 백업 만들기 시스템 베이스 MS SQL 데이터: 서버, 마스터, 모델 및 msdb . 이러한 데이터베이스는 시스템 구성과 전체 시스템 복원 시 복원해야 하는 SQL Server 작업 정보를 포함하므로 절대적으로 필요합니다.

BACKUP EXEC를 사용하여 MS SQL 백업 설정

Backup Exec은 전체, 차등 및 전체 복사 전용의 세 가지 MS SQL 백업 방법을 제공합니다. 전체 방법은 전체 데이터베이스의 전체 백업을 수행하는 반면 차등은 마지막 전체 백업 이후 데이터베이스에서 변경된 블록만 백업합니다. 전체 복사 전용 방법은 후속 차등 백업 작업에 영향을 미치지 않는다는 점을 제외하고 전체 백업과 동일합니다.

각 경우에 대해 더 자세히 살펴보겠습니다. 이를 위해 시스템에서 기본 및 시스템 데이터베이스를 백업하는 새 작업을 생성합니다.

그런 다음 매개변수 설정(옵션)에서 작업 유형을 선택합니다(먼저 전체 설정 후 차등 백업 설정).



Backup Exec은 매우 중요하고 유용한 기능"백업 전/후 데이터베이스 무결성 검사"(백업 전/후 일관성 검사)에서 선택할 수 있는 4가지 옵션이 있습니다.

  • 확인하지 마십시오
  • 인덱스를 제외한 전체 검사
  • 인덱스 기반 전체 검사
  • 신체검사만


차등 백업을 구성하려면 작업 전체 백업과 유사하게 먼저 새 작업 차등 작업을 추가한 다음 Microsoft SQL 탭에서 백업 방법 중 하나를 선택해야 합니다.


입력 이 목록주로 관심 "차등 - 마지막 전체 이후 데이터베이스 변경 사항 백업"(전체 백업을 기반으로 차등 백업 만들기). 이후에 가상 머신으로 변환하여 차등 백업(블록 수준에서)을 생성할 수도 있습니다. "차등(블록 수준) - 마지막 전체 이후 데이터베이스 변경 사항 백업 - 가상 머신으로 변환 작업과 함께 사용".

또 다른 중요한 매개변수는 "로그 - 트랜잭션 로그 백업 및 자르기" MS SQL 트랜잭션 로그 백업용.

MS SQL 백업의 요점을 다뤘습니다. 백업은 전체 DRP(재해 복구 계획)의 일부이므로 백업을 계획하기 전에 RPO 및 RTO를 보장하기 위해 시스템 및 인프라에 대한 완전한 분석을 수행해야 합니다. 그리고 시스템 개발 중에 DRP 계획을 수행할 수 있다면 많은 문제를 제거하고 시스템 운영 비용을 줄이는 데 도움이 될 것입니다.

기사에 사용된 정보는 공식 출처에서 가져왔습니다.

우리는 백업에 대해 계속 이야기하고 오늘 배울 것입니다 Microsoft SQL Server 2008 데이터베이스의 백업 생성. 그래픽 인터페이스와 SQL 쿼리를 모두 사용하는 예제를 사용하여 모든 것을 평소와 같이 고려하고 자동 배치 파일을 사용하여 백업 생성.

예를 들어 다음 자료에서 이미 이 주제를 두 번 이상 제기했기 때문에 데이터베이스 백업의 중요성에 대한 질문으로 돌아가지 않을 것입니다.

그리고 지난 기사에서 MS SQL Server 2008 DBMS에 아카이브를 만드는 가능성을 고려할 것이라고 말했으므로 이제 그렇게 할 것입니다.

그리고 이미 많은 이론이 있었기 때문에 즉시 연습, 즉 백업 기반 생성으로 넘어 갑시다.

메모! 기사 제목에서 알 수 있듯이 Management Studio를 사용하여 Microsoft SQL 2008 DBMS에 아카이브를 만듭니다. 서버는 로컬에 있습니다. OS 윈도우 7.

SQL 서버 데이터베이스의 아카이브를 만드는 방법

"test"라는 테스트 데이터베이스의 아카이브를 만들기로 결정합시다. 처음부터 GUI, 그리고 이 과정에서 우리는 스크립트를 작성하여 미래에 단순히 실행할 수 있고 더 이상 모든 종류의 매개변수를 입력하여 주의가 산만하지 않도록 할 것입니다.

Management Studio를 열고 확장 « 데이터 베이스» , 원하는 베이스를 선택하고 마우스 오른쪽 버튼으로 클릭하고 작업->백업

"라는 창이 나타납니다. 데이터베이스 백업", 여기에서 보관 매개변수를 설정할 수 있습니다. 이름만 지었어요 백업 세트", 기본적으로 Program Files 폴더에 생성되기 때문에 아카이브 이름과 경로도 변경했습니다. 예를 들어 기본 경로가 있었습니다.

C:\프로그램 파일\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\백업\

예를 들어 C:\temp\로 변경하고 아카이브 이름을 test_arh.bak

또한 탭으로 이동하면 « 매개변수», 그런 다음 모든 데이터 세트를 덮어쓰도록 설정을 지정할 수 있습니다. 이제 그것이 무엇인지 설명하겠습니다. 모든 것을 그대로 두면, 즉. 기존 데이터 세트에 추가하면 하나의 백업 파일이 생성되지만 여러 데이터 세트 인스턴스가 있습니다. 복원할 때 필요한 세트를 선택하기만 하면 됩니다. 그리고 "를 넣으면 모든 기존 백업 세트 덮어쓰기"라고 가정하면 세트가 항상 동일할 것이며, 이 경우 다른 이름으로 아카이브(일일 아카이브라고 가정)를 생성해야 합니다. 덮어쓰도록 설정했습니다. 앞으로 필요한 경우 필요한 백업을 빠르게 복사하기 위해 이러한 아카이브 이름에 날짜를 사용하여 매일 아카이브를 만들 계획이기 때문입니다. 특정 날짜어떤 장소로.

그리고 그건 그렇고, 이 시점에서 모든 매개변수를 입력한 후 스크립트를 생성하여 기록하고 나중에 사용할 수 있습니다. 이렇게 하려면 상단을 클릭하기만 하면 됩니다. 대본».

그리고 이 작업의 결과로 이 스크립트에 대한 코드가 있는 쿼리 창이 열립니다. 잠시 후에 다시 돌아가겠지만 지금은 "확인"을 클릭하고 작업이 완료된 후 백업 결과가 표시되는 창이 표시됩니다. 모든 것이 정상이면 다음 메시지가 표시됩니다. 나타나다

쿼리를 통해 SQL Server 데이터베이스 아카이브 생성

위와 같이 모두 했다면 저것들. "스크립트"를 클릭했습니다.) 그런 다음 실제로 아카이브 생성 요청이 포함 된 쿼리 창을 열었지만 매일 실행할 계획이라고 말했기 때문에 약간 다시 할 것이므로 이름이 적절하려면 우리는 이 SQL 문을 작성할 것입니다.

DECLARE @path AS VARCHAR(200) SET @path = N"C:\temp\test_arh_" + CONVERT(varchar(10), getdate(), 104) + ".bak" 디스크 백업 데이터베이스 = @path NOFORMAT, INIT, 이름 = N"데이터베이스 테스트", 건너뛰기, NOREWIND, NOUNLOAD, 통계 = 10 GO

이제 실행하면 test_arh_라는 이름으로 데이터베이스 백업을 생성합니다. 현재 날짜.bak

SQL 서버에 백업 자동 생성

이러한 목적을 위해 MS SQL 2008에는 " 서비스 계획"에서 데이터베이스 백업을 생성하기 위한 일정을 설정할 수 있지만 이러한 목적을 위해 bat 파일을 사용하여 스케줄러에서 설정하고 매일 시작하여 데이터베이스를 백업하도록 제안합니다.

이렇게 하려면 위에서 검토한 SQL 문을 복사하여 메모장( 메모장++ 추천합니다), 확장자로 저장 .sql저것들. 이 스크립트는 MS Sql 2008에서 실행됩니다. 그런 다음 SQL 서버에 연결하고 스크립트를 실행하도록 배치 파일을 작성해야 합니다. 또한 메모장에 작성하십시오.

SET cur_date=%date:~6.4%%date:~3.2%%date:~0.2% osql -S localhost -i C:\temp\test.sql -o C:\temp\%cur_date %_log_sql.log -E

여기서 현재 날짜를 저장하기 위해 cur_date 변수를 만든 다음 연결합니다. 로컬 서버, 유틸리티를 통해 sql, ODBC를 사용하고 스크립트( 나는 그것을 test.sql이라고 불렀다.), 그리고 로그를 기록해 둡니다. 여기서 우리는 변수가 필요한 위치에 모든 것을 확장자로 저장합니다. .박쥐, 스케줄러에서 작업을 생성하고 데이터베이스 아카이브 프로세스를 잊어 버렸다고 말할 수 있습니다. 음, 아카이브가 생성되었는지 여부를 주기적으로 확인합니다.

기본적으로는 이것으로 충분합니다. 이제 2008 SQL Server에서 데이터베이스를 백업하는 방법을 알게 되었습니다. 다음 기사에서는 MS SQL Server 2008에서 데이터베이스를 복원하는 방법을 살펴보겠습니다. 그동안은 여기까지입니다. ! 행운을 빕니다!

sqlcmd -S DECLSERVER\SQLGTD -E -Q "@s varchar(255) set @s='E:\backup\GTD_' + convert(varchar(1), datepart(dw, getdate())) + '를 선언합니다. bak' 백업 데이터베이스 GTD를 디스크로 = @s with init, noformat, skip, nounload"

SQLcmd Transact-SQL 문, 시스템 프로시저 및 스크립트 파일을 입력할 수 있습니다. 명령줄 SQLCMD 모드에서 쿼리 편집기로,

  • -에스 - 서버 이름을 설정합니다. 서버[\instance_name];
  • DECLSERVER\SQLGTD - 데이터베이스가 실행 중인 서버 이름/인스턴스 이름
  • -이자형 - 사용자 이름과 암호 대신 신뢰할 수 있는 연결을 사용하여 SQL 서버에 연결합니다.
  • -Q "cmdlinequery" - 프로그램을 시작할 때 SQLcmd요청을 실행하지만 완료될 때 프로그램이 종료되지 않습니다. 세미콜론으로 구분하여 여러 쿼리를 실행할 수 있습니다. 위와 같이 쿼리를 따옴표로 묶습니다.
  • 선언하다 - 변수 s를 선언하고 변수 이름은 항상 @로 시작하므로 @에스. 우리의 경우 @에스- 이것은 백업을 저장하기 위한 폴더(디스크)입니다.
  • varchar(n) - 변수의 유형을 설정합니다. @에스긴 문자열 n이 있는 문자열로, 예에서 255자;
  • 세트 - 변수의 값을 설정 @에스, 예에서 이것은 드라이브 E의 백업 폴더입니다( E:\백업\), 이름이 주어진다 백업 파일, 여기서 함수 집합 변환(varchar(1), 날짜 부분(dw, getdate()))현재 요일(월요일 - 1 , 화요일 - 2 등) 확장자가 추가됩니다. 박. 출력은 다음과 같은 파일이 될 것입니다. GTD_WeekDayNumber.bak;
  • 지원 - 백업을 생성합니다.
  • 데이터 베이스 - 전체 데이터베이스의 백업 생성을 나타냅니다.
  • GTD - 이 예에서는 SQL 서버의 데이터베이스 이름입니다.
  • 디스크에 - 백업 저장 장치, 파일의 유형을 나타냅니다. 하드 드라이브, 변수가 지정되었습니다. @에스, 생성되는 파일의 경로와 이름이 할당됩니다.
  • init, noformat, skip, nounload 포함 - 헤더 재정의로 원의 데이터를 덮어쓸 필요가 있음을 나타냅니다. 이렇게 하면 각 요일에 대해 7개의 백업 파일을 원으로 덮어쓸 수 있습니다.

필요한 경우 압축과 같은 다른 기능을 사용할 수도 있습니다. Transact-SQL 쿼리 및 함수 참조를 참조하세요.

2단계. 텍스트 파일 확장자를 .cmd로 변경

결과적으로 우리는 파일을 얻습니다. 백업GTD.cmd. 생성된 배치 파일은 MS SQL 데이터베이스가 설치된 머신에서 실행해야 합니다.

3단계. 이 프로세스 자동화

MS Windows Server 2008의 예에서 다음 단계를 고려하십시오. 서버 관리자 -> 구성 -> 작업 스케줄러 -> 작업 스케줄러 라이브러리.

관련 출판물