Azure SQL Database의 백업과 복구

Azure SQL databasePaaS(Platform as a service) 형태의 데이터베이스로 기본 인프라는 Azure가 책임을 지고 사용자는 Database를 생성해서 바로 테이블을 만들고 데이터를 넣어 사용할 수 있다. 요즘은 Database as a Service 라고도 부른다.

아무리 인프라의 운영을 Azure가 책임지는 PaaS 라고 해도 장애가 없다고 장담할 수 없으며 사람의 실수로 인해 데이터가 망가지는 경우는 언제나 발생할 수 있다. 데이터가 문제가 발생하면 비즈니스에 치명적인 영향을 준다. 이런 상황에서 우리가 믿을 건 백업 밖에 없다. Azure SQL database는 PaaS 답게 추가비용 없이 자동으로 백업을 해준다. 자동 백업이 어떻게 진행되는지 그리고 복구는 어떻게 하는지 살펴보자.

백업

Azure SQL database의 백업 4가지에 대해서 살펴보자.

자동백업

Azure SQL database는 매주 전체 백업을 하고 매시간 증분백업과 5분간격으로 트랜젝션 로그 백업을 자동으로 진행한다. 그리고 가격 정책 계층에 따라서 백업의 보존기간이 다른데 기본(Basic)은 7일, 표준(Stadard)와 프리미엄(Premium)은 35일 동안 보존한다. 보존기간 내에는 모든 복원지점에서 복구를 할 수 있다. 보존을 하는 위치는 ‘쌍을 이루는 데이터센터’에 저장되는데 한국 중부의 데이터베이스라면 한국남부에 일본서버의 데이터베이스라면 일본동부에 저장된다.

Portal에서 백업 진행상황을 보려면 개요 블레이드의 상단에 “복원” 버튼을 누르면 된다. 가장 오래된 복원지점을 확인 할 수있다.

장기 백업 보존

대부분의 경우 자동 백업에 7일 또는 35일 보존기간은 적절하지만 상황에 따라서 백업 기간을 더 연장해야하는 경우가 있을 것이다. 이 경우 장기 백업 보존 기능을 활용하면 최대 10년 동안 백업을 보관 할 수 있다. Azure SQL database를 만들때 ‘데이터베이스 서버’도 만들게 되어 있는데 (아이콘이 조금 다름) 장기 백업 보존은 데이터베이스 서버에 메뉴가 있다. 미리보기 조건에 동의를 먼저하고 Recovery service vault 자격 증명 모음을 만든 후 데이터 베이스를 선택하고 구성 버튼을 누르면 설정 블레이드가 나온다. 아래 그림은 일본 동부에 1년 동안 보관하는 설정이다.

활성 지역 복제

활성지역 복제(Active Geo-Replication)는 사실 백업이 아니라 Replication이다. 즉 다른 데이터센터에 똑같은 보조 데이터베이스를 만들고 지속적으로 싱크를 한다. 만약 원본 데이터베이스에 문제가 생기면 5초 이내에 복제된 데이터베이스로 마스터가 이전되어 빠르게 복구(Fail over) 된다.

Azure SQL database에서 “지역에서 복제”를 누르면 설정 할 수 있고 역시 ‘쌍으로 연결된 데이터센터’가 보라색으로 추천된다. 지역을 선택하고 해당 지역에 데이터베이스 서버를 만들어주면 자동으로 보조 데이터베이스를 만들어 싱크한다. 보조 데이터베이스를 읽기가능으로 설정해놓으면 데이터 읽기를 분산해줄 수도 있다.

수동으로 백업

데이터베이스 내보내기 기능을 이용하여 BACPAC 파일로 수동 백업이 가능하다. 백업된 파일은 스토리지에 저장된다. 이 방법은 데이터 마이그레이션 직전이나 대량으로 데이터가 생성되는 등 큰 변화의 전후 시점에 수행해 놓으면 좋다. 라이브 데이터베이스에서 내보내기를 하기가 부담스럽다면 복사를 하고 내보내기를 하면된다. 복사는 빠르게 이뤄진다. 내보내기는 크기에 따라서 오래걸릴 수 있다. 가끔 복사를 하지 않고 만든 BACPAC 파일이 복구 과정에서 오류를 발생하는 경우가 있으므로 복사 후 내보내기를 하는게 좋겠다. 이 기능은 포탈에서도 가능하고, SSMS(SQL Server Management Server), PowerShell로도 가능하다.

기존 구포탈에서 제공되었던 Azure SQL Database Automated Export 기능은 2017년 3월 1일로 서비스가 종료되므로 사용하지 않는 것이 좋다.

 

복구

3가지 시나리오로 백업된 데이터베이스를 복구해보자.

자세한 내용은 관련문서 SQL Database 백업 및 복원시작 문서를 참조 바란다.

1. 실수로 Azure SQL database를 삭제했을 때

멀쩡한 데이터베이스를 삭제하는 일이 있을 수 없는 상황이지만 이런일이 실제로 일어난다. 데이터베이스만 삭제 했다면 금방 복구 할 수 있다. ‘데이터베이스 서버’의 개요 블레이드에 보면 삭제된 데이터베이스라는 메뉴가 보이는데 이 메뉴를 열어보면 삭제된 데이터베이스를 볼 수 있다. 이 백업을 선택하고 이름을 다시 정해준 후 복원하면 된다. 데이터베이스 서버를 삭제하면 이 방법을 쓸 수 없다. 만약 데이터베이스를 삭제한 상황이라면 최대한 빨리 Azure의 기술지원 티켓을 끊어서 서비스를 요청해야 한다.

 

2. 데이터가 깨져서 이전 백업으로 돌아가야 할 때

어떤 이유에 의해서 또는 실수로 데이터 자체에 문제가 생길 수 있다. User 테이블을 지워버린 상황이 그런 예다. 데이터베이스를 선택하고 ‘개요’ 블레이드에서 복원 버튼을 누르면 복원 메뉴가 나온다. 가장 오래된 복원 지점을 확인하고 원하는 날짜와 시각을 정해준 다음 데이터베이스 이름을 지정한 후 확인을 누르면 새로운 데이터베이스가 생성되면서 복원된다. 장기 백업 보존을 설정했다면 Azure 자격 증명 모음 백업에서 원하는 백업을 선택한 후에 확인을 누른다.

3. 데이터센터의 데이터베이스 서비스에 장애가 발생하면

활성지역 복제를 설정해 놨다면 보조 지역을 선택하고 ‘페일오버’ 버튼을 누르면 5초 이내에 보조 데이터베이스가 주 데이터베이스로 변경되어 서비스된다. 그런 후에 애플리케이션에서 Connection String을 변경해서 Fail over된 데이터베이스에 연결되도록 설정해서 마무리한다.

활성지역 복제가 아니라면 복원의 시점을 잘 생각해야 한다. 장애가 금방 복구될 예정이거나 문제를 금방 해결 할 수 있다면 기다리는게 더 좋은 선택일 수 있다.

백업이 있다면 데이터베이스를 새로 만들면서 복원을 할 수 있다. 데이터베이스 만들기 블레이드에서 소스선택을 ‘백업’으로 지정하고 백업을 찾아서 만들 수 있다.

4. 재해복구 훈련

운영중인 서비스에 데이터가 문제가 생겨 장애가 발생하면 마음이 급해지고 힘든 상황이 닥치게 된다. 마음을 가다듬고 복구에 임하려면 평소에 복구훈련이 필요하다. 일분 일초가 급한상황에서 구글에서 문서를 찾는다면 그게 눈에 들어올리도 없고 정확한 판단이 어려울 수 있다. 프로덕션 환경의 데이터베이스를 복사해서 테스트 환경을 꾸밀 수 있다.

관련문서: Azure SQL 데이터베이스의 비즈니스 연속성 개요