미스터 역마살

SQL Server 백업 및 복구 본문

Database/SQL SERVER

SQL Server 백업 및 복구

Mr. YeokMaSsal 2022. 7. 31. 18:59
728x90
반응형

백업

SQL Server의 백업 종류 및 백업 전략은 아래와 같다.

SQL Server 백업 종류

  • 전체 백업
  • 차등 백업
  • 트랜잭션 로그 백업

백업 전략

  • 전체 백업
  • 전체 백업 + 차등 백업
  • 전체 백업 + 트랜잭션 로그 백업
  • 전체 백업 + 차등 백업 + 트랜잭션 로그 백업

트랜잭션 로그

SQL Server에서는 쿼리르 실행하고 Commit이 일어날때 까지의 동작 작위를 트랜잭션이라고 한다. 각 트랜잭션에 의해 적용된 모든 트랜잭션 및 데이터베이스 수정 내용을 기록하는 것이 트랜잭션 로그의 역할이다. 이것은 데이터베이스에서 아주 중요한 구성요소이며, 복제와 미러링 등에서도 주 데이터베이스와 복제 또는 미러 데이터베이스의 동기화를 위해 사용되며 시스템 오류가 발생 할 경우 데이터베이스를 다시 일관된 상태로 만들기 위해 사용 된다.

트랜잭션 로그는 DB에서 별도의 파일 또는 파일 집합으로 구현된다. SQL Server 에서는 ldf형식의 파일에 저장된다. 로그 캐시는 데이터 페이지의 버퍼 캐시와는 별도로 관리 되므로 DB엔진에 단순하고 빠르고 강력한 코드를 구현할 수 있다.

트랜잭션 로그는 데이터 파일과 같이 여러 파일에 구현할 수 있으며 트랜잭션 로그에 FILEGROUTH 값을 설정 하여 자동으로 확장되도록 파일을 정의 할 수 있다. 이를 통해 트랜잭션 로그에서 공간이 부족해질 확률이 줄어들며 관리 오버헤드를 줄일 수 있다.

 

백업의 종류

전체 백업

가장 기본적인 백업이다. DB를 구성하는 모든 데이터 파일과 백업이 진행되는 동안 발생한 트랜잭션에 대한 로그를 백업한다. 모든 DB 복원의 베이스가 때문에, 복원을 위해서는 최소한 1개 이상의 전체 백업이 있어야 한다.

  • 데이터베이스 전체를 백업, 데이터의 변경 유무에 관여하지 않고 전체 데이터의 복사본을 만드는 백업
  • 데이터베이스의 개체 , 시스템 테이블 , 데이터를 모두 백업
  • 데이터베이스의 내용과 더불어서 백업이 진행되는 동안 발생되는 트랜잭션 로그 중 필요한 부분도 백업
  • 복구 과정이 다른 백업 보다 간편, 다른 백업 방식보다 복구 시간이 적게 소요

전체 백업이 필요한 경우는 아래와 같다.

  • 처음 데이터베이스를 생성 하였을 때
  • 트랜잭션 로그를 강제로 비웠을 때
  • 데이터베이스 변경이 생겼을 때 (Alter Database 구문 실행 후)
  • 보통 주기적으로 해줌 (필자의 주관적 생각)
  • 차등 백업과 로그 백업을 하기 이전에 꼭 한번 수행 해야함


차등 백업

가장 마지막 전체 백업 이후에 변경된 데이터를 백업한다. 즉, SQL Server는 내부적으로 전체 백업 이후에 변경된 데이터가 무엇인지 관리하고 있다. DB 크기가 커서 전체 백업을 자주 받을 수 없는 경우 중간 중간 차등 백업을 받음으로써 주기적인 백업을 수행한다. 차등 백업은 혼자서 존재할 수 없으며 반드시 전체 백업을 받은 이후에 수행해야 한다.

차등 백업은 전체백업을 만든 시간과 차등백업을 만든 시간 사이에 변경된 Extent의 상태를 캡쳐한다. 차등 백업의 장점은 아래와 같다.

  • 전체복구 모델 에서 차등백업을 사용하면 복원해야 하는 로그백업의 수를 줄일 수 있다.
  • 차등백업은 전체 백업에 비해 매우 빠른 속도를 낸다. 하지만 차등백업에서 복원을 할 경우 전체 백업을 복원 하는것에 비해 더 많은 시간과 노력이 필요하다.
  • 차등백업은 데이터베이스 하위 집합이 나머지 데이터베이스보다 자주 수정되는 경우 유용하다. 이런 경우 차등 백업을 사용하면 전체 백업의 오버헤드를 발생시키지 않고 자주 백업을 할 수 있다.

 


트랜잭션 로그 백업

트랜잭션 로그 파일을 백업 받으면서 트랜잭션 로그 파일에 쌓여진 로그를 지운다(옵션으로 보존 가능). DB의 복구모델이 Simple인 경우 트랜잭션 로그가 자동으로 지워지므로 사용이 불가하다. 복구모델이 Full이나 Bulk-Logged인 경우 트랜잭션 로그가 계속 쌓여 디스크가 꽉 차는 현상이 발생할 수 있으므로 꼭 주기적인 트랜잭션 로그 백업이 필요하다. 로그가 꽉 차게 되면 더이상 데이터 변경이 불가능 해질 뿐 아니라 DBMS에도 문제가 발생할 수 있따.

로그백업의 내용이 유실된다면 유실된 이후의 모든 로그백업된 자료는 복원 할 수가 없다. 로그 백업의 특징은 아래와 같다.

  • 로그 백업은 변경된 내용만을 백업하기 때문에 대개는 백업속도가 무척 빠르다. 일반적으로 실무에서 사용되는 대용량의 데이터에서 실제 변경되는 내용은 많지 않기 때문이다.
  • 복원되는 속도는 느리다. 데이터를 백업받은 경우는 데이터를 바로 DB에 복사하는 형식이지만, 로그를 백업받은 경우에는 DML문을 다시 수행해야 하기 때문이다.
  • 대량의 데이터 변경이 일어난 경우에는 로그 백업이 바람직하지 않다. 복원할 양이 많기 때문에 속도가 느려지기 때문이다.따라서, 대량의 데이터 변경이 일어난 후에는 전체 백업을 해주고, 다시 처음부터 로그 백업을 해 주는 것이 바람직 하다.

 

 

백업 전략

  • 전체 백업
  • 전체 백업 + 차등 백업
    복원 시 전체 백업 후 차등 백업을 여러번 수행했더라도 마지막 차등 백업만 있으면 된다(차등 백업 자체가 전체 백업을 기준으로 변경된 데이터를 백업하는 것이기 때문에)
  • 전체 백업 + 트랙잭션 로그 백업
    복원 시 전체 백업 후 실행된 모든 트랜잭션 로그 백업이 필요하다.
  • 전체 백업 + 차등 백업 + 트랜잭션 로그 백업
    복원 시 전체 백업 후 마지막 차등 백업과 그 뒤에 일어난 트랜잭션 로그 백업이 필요하다.

 

복구

복구에는 다음과 같은 3가지가 있다.

  • 단순 복구 모델 (Simple)
  • 전체 복구 모델 (Full)
  • 대량 로그 복구 모델 (Bulk Logged)

단순 복구 모델 (Simple)

단순복구 모델은 데이터가 변경되는 내용을 트랜잭션로그파일에 기록하지 않는 모델이다. 따라서 트랜잭션 로그 백업이 있을수 없으며 마지막 백업된 시점까지만 복원이 가능하다. 단순 복구 모델은 아래와 같은 상황일때 사용 가능하다.

  • 오류 지점 복구가 필요하지 않습니다. 데이터베이스가 손실되거나 손상될 경우 오류 지점과 이전 백업 사이의 모든 업데이트가 손실되어도 상관 없습니다.
  • 로그에 있는 일부 데이터가 손실되어도 상관 없습니다.
  • 트랜잭션 로그를 백업 및 복원하지 않고 전적으로 전체 및 차등 백업을 사용하려고 합니다.

 

전체 복구 모델(Full)

전체 복구 모델은 데이터가 변경되는 모든 작업과 내용을 로그파일에 기록하는 모델이다. 따라서 장애가 난 최근 시점까지 복구가 가능하다. 아래 경우 중 하나에 해당되는 경우 전체 복구 모델과 선택적으로 대량 로그 복구 모델을 함께 사용한다.

  • 모든 데이터를 복구할 수 있어야 합니다.
  • 데이터베이스에 여러 파일 그룹이 있으며 읽기/쓰기 보조 파일 그룹과 선택적으로 읽기 전용 파일 그룹의 증분 복원을 수행하려고 합니다.
  • 실패 지점까지 복구 할 수 있어야 합니다.
  • 개별 페이지를 복원하려고 합니다.
  • 트랜잭션 로그 백업의 관리 비용이 발생해도 괜찮습니다.

전체 복구 모델을 사용할 경우 트랜잭션 로그 파일의 크기가 커져서 DB백업 파일의 크기가 늘어나게 된다.

 

대량 로그 복구 모델(Bulk Logged)

대량 로그 복구 모델은 전체 복구 모델과 비슷한 방식으로 작동하는 특수 용도 모델이다. 유일한 차이점은 대량 데이터 수정 작업을 처리하는 방식에 있다. 대량 로그 모델은 최소 로깅 기술을 사용 한다. . 이렇게하면 처리 시간이 크게 절약되지만 특정 시점 복원 옵션을 사용할 수 없다.대량 로그 복구 모델은 단기간 동안 만 사용하는 것이 좋다. 가장 좋;은 방법은 대량 작업을 수행하기 전에 데이터베이스를 대량 로그 복구 모델로 전환하고 이러한 작업이 완료되면 전체 복구 모델로 복원하는 것이다.

 

 

 

 

 

728x90

'Database > SQL SERVER' 카테고리의 다른 글

SQL Server 고가용성  (0) 2022.07.27
SQL Server 아키텍처  (0) 2022.07.27
Comments