데이터베이스 백업 시 흔히 하는 12가지 실수
by Alexey Kovyazin, 2015년 11월 11일
PDF 다운로드 (영어) 이 글은 원래 Firebird DBMS 개발자와 관리자를 위해 작성되었지만, 다른 데이터베이스 관리자들과의 접촉을 통해 대부분의 실수가 그들에게도 공통적이며 사실상 거의 모든 사람이 똑같은 돌에 걸려 넘어진다는 것이 분명해졌습니다. 이 목록에 무언가를 추가할 수 있다면(특정 DBMS에 국한된 내용이라도), 저희 이메일 [email protected]로 연락해 주십시오.
1. 새 백업 복사본이 생성되기 전에 이전 백업 복사본을 삭제하는 경우
이 실수는 데이터베이스 백업 복사본의 주된 목적이 단순히 데이터베이스 사본을 만드는 것이 아니라, 정보 시스템(그 중요한 부분이 데이터베이스임)의 다운타임을 가능한 한 짧게 만드는 것임을 깨닫지 못하는 초보자들에게 가장 흔합니다.
그 결과, 최신 백업 복사본이 삭제된 순간부터 새 복사본이 생성되는 순간까지 시스템은 보호되지 않은 상태로 남게 되는데, 이 기간 동안 데이터베이스에는 단 하나의 백업 복사본도 없기 때문입니다. 백업 복사본 생성에는 상당한 시간이 걸릴 수 있으므로, 머피의 법칙이 발동하기에 완벽한 시기입니다. 이 접근 방식은 문제 7(아래 참조)과 결합될 때 특히 효과적입니다.
권장 사항: 새 복사본이 생성되기 전에 이전 백업 복사본을 삭제하지 마십시오! (그리고 기존 파일에 새 백업 복사본을 만들지 마십시오).
Firebird를 위한 권장 사항: HQbird(Firebird의 고급 배포 패키지)에 포함된 FBDataGuard 도구는 새 복사본이 생성된 후에만 이력상 가장 오래된 백업 복사본을 삭제합니다.
2. 백업 복사본에서 복원할 때 기존 데이터베이스를 덮어쓰는 경우
이 실수는 덜 흔하지만 결과는 훨씬 더 심각할 수 있습니다. 백업 복사본이 검증되지 않았고 손상된 것으로 판명되면(문제 6 참조), 이전 데이터베이스 사본도 유효한 백업 복사본도 갖지 못하게 됩니다.
이런 엉망진창은 보통 금요일 저녁, 일이 정신없이 돌아가고 경영진의 지시가 다소 모순될 때 발생합니다. 약간의 불운이 겹치면 서버실에서의 나른한 주말이 여러분을 기다립니다.
Firebird에는 이 실수에 대한 일종의 보호 장치가 있습니다. 기본 -create 스위치가 켜져 있고 지정된 파일 이름이 기존 데이터베이스를 가리키는 경우 gbak 유틸리티로는 백업 복사본에서 데이터베이스를 복원할 수 없습니다. 안타깝게도 이 보호 장치를 우회하는 방법이 있습니다. -rep 스위치는 여전히 기존 파일을 덮어쓸 수 있게 해줍니다.
권장 사항: 경영진의 서면 지시 없이는 운영 중인 데이터베이스의 파일을 절대 덮어쓰지 마십시오.
Firebird를 위한 권장 사항: FBDataGuard는 데이터베이스 파일을 절대 덮어쓰지 않으므로 이를 사용하십시오.
3. 중간 백업 파일 없이 단일 단계 백업/복원을 사용하는 경우
표준 입출력 스트림을 사용하면 많은 DBMS( Firebird 포함)에서 재미있는 트릭을 할 수 있습니다. 스트리밍 백업을 구현하고 그로부터 데이터베이스를 즉시 복원하는 것입니다. 결과적으로 중간 백업 파일이 생성되지 않습니다. 일상적인 유지 관리와 테스트 복원 작업 실행에는 편리하지만(다른 백업 복사본이 있는 경우), 자동 백업에는 절대 사용해서는 안 됩니다!
예를 들어, 이 백업/복원 과정에서 심각한 디스크 장애가 발생하면 초기 데이터베이스가 손상될 수 있으며 아직 새 데이터베이스가 생성되지 않은 상태일 수 있습니다. 물론 문제 1을 고려하여 이전 시도의 데이터베이스 사본이 있다면, 그 사본이 생성된 이후 데이터베이스에서 생성되거나 업데이트된 데이터만 손실됩니다.
권장 사항: 자동 모드에서는 단일 단계 백업/복원을 사용하지 말고, 수동 모드에서는 항상 충분히 최신 상태인 사본이 있는지 확인하십시오.
4. 백업 복사본과 데이터베이스를 동일한 물리적 장치에 저장하는 경우
많은 분들은 저희가 드리는 조언이 어린아이 수준 같다고 웃으실지도 모릅니다. 백업의 기초 상식이니까요. 맞습니다. 하지만 가상 환경의 인기로 인해 데이터베이스와 디스크가 결국 하나의 데이터 저장 시스템에 저장될 수 있습니다. 그리고 그것은 틀림없이 가장 부적절한 순간에 고장 날 것입니다. 게다가 RAID 배열(버전 1 이상 :))을 사용하면 데이터에 아무 일도 일어나지 않는다고 믿는 사람들이 여전히 있습니다. 또한 일부 “브랜드” 서버는 고장이 나지 않는다고 믿는 사람들도 있습니다. 하지만 그것은 특별한 경우입니다.
권장 사항: 아무리 신뢰할 수 있어 보이더라도 백업 복사본과 데이터베이스를 하나의 장치에 저장하지 마십시오.
5. 백업 프로세스의 성공적 완료에 대한 통제가 없는 경우
관리자와 IT 부서장 모두에게 다소 흔한 실수입니다. 백업 프로세스의 결과를 확인하지 않는다면, 차라리 백업을 수행하지 않는 편이 낫습니다. 성공적으로 완료된 백업 프로세스에 대한 알림을 이메일로, 더 나아가 문자 메시지로도 받아야 합니다. 그리고 그러한 알림이 없다는 것은 문제가 있다는 신호입니다!
우리 기사의 이 지점까지 읽은 주의 깊은 독자(아직 상을 주기에는 이르지만)는 이렇게 물을 수 있습니다. ‘하지만 그것이 경영진과 무슨 관련이 있습니까?’ 바로 이것입니다. 관리자는 보통 백업 프로세스를 구성하지만, 특히 알림이 별도의 폴더에 저장되는 경우 알림을 확인하는 것이 너무 지루하게 느껴지므로 프로세스 상태에 대한 추가 보고서를 요청하는 것이 결코 과하지 않습니다. 백업 복사본이 있는 것처럼 보였지만 실제로 필요한 순간에 없다면 누구의 책임인가에 대한 질문입니다 :)
! 문제 2와 결합되면, 우리는 데이터베이스도 그 백업 복사본도 갖지 못하게 됩니다.
권장 사항: 성공 및 실패한 백업 프로세스를 모니터링하고, 문제를 사용자에게 알리며, 요약 통제 도구를 제공하는 백업 자동화 도구를 사용하십시오(특히 여러 서버에서 수십, 수백 개의 백업 프로세스를 통제해야 할 때 관련이 있습니다).
Firebird를 위한 권장 사항: FBDataGuard는 백업 프로세스가 완료되었는지 확인하고 해당 알림을 보냅니다. 데이터베이스가 많은 시스템의 경우 Control Center 도구를 통한 2차 요약 모니터링이 있으며, 이를 통해 한 페이지에서 모든 모니터링 대상 서버와 데이터베이스의 상태를 볼 수 있습니다.
6. 백업 검증이 없는 경우
백업 복사본이 어딘가에 저장되어 있다는 사실이 그곳에서 읽을 수 있다는 것을 의미하지는 않습니다.
그렇기 때문에 생성한 백업 복사본이 손상되지 않았는지 또는 /dev/null로 복사되지 않았는지 확인하기 위해 정기적으로 검증해야 합니다.
Firebird를 위한 권장 사항: FBDataGuard를 사용하여 백업 검증을 자동화할 수 있습니다.
7. 검증되지 않은 백업 복사본을 사용하면서 데이터베이스 상태 검사를 하지 않는 경우
일반적으로 데이터베이스는 덤프, 정기 백업 복사본 등 여러 유형의 백업을 사용합니다. 세부 사항으로 들어가지 않고, 검증된 것과 검증되지 않은 두 가지 범주로 나눌 수 있습니다. Firebird의 경우 gbak과 nbackup입니다.
Gbak은 백업 파일을 생성하기 위해 레코드 수준에서 전체 데이터베이스를 읽고, 새 데이터베이스에 레코드를 삽입하여 데이터베이스를 생성함으로써 백업 복사본(복원된 복사본에 오류가 몰래 들어갈 수 있는 방법이 있지만, 그것은 잘못 구성된 마이그레이션과 관련하여 데이터베이스 관리자가 일을 망칠 수 있는 또 다른 방법입니다)과 데이터베이스 자체(처음부터 끝까지 읽을 수 있다면 손상되지 않았을 가능성이 높습니다)를 검증합니다.
Nbackup(일명 증분 백업)은 업데이트를 위해 기본 데이터베이스 파일을 일시적으로 잠그고(일관된 상태에서) 데이터베이스 파일을 빠르게 복사(전체 또는 부분/증분)할 수 있게 해줍니다.
대규모 Firebird 데이터베이스(500GB 이상)의 경우 사용자 작업 속도를 늦추지 않기 위해 nbackup을 사용하는 것이 바람직하지만, 동시에 데이터베이스를 검증해야 합니다. 왜냐하면 그것이 생성하는 검증되지 않은 백업 복사본은 데이터베이스 페이지 사본이며, (RAM 장애로 인해) 레코드 수준이나 논리 수준에 오류가 있는 경우 검증되지 않은 백업 복사본에도 원본 데이터베이스와 마찬가지로 그 오류가 포함되기 때문입니다.
이를 피하려면 원본 데이터베이스에 대해 온라인 검증을 사용해야 합니다(gfix를 이용한 온라인 검증은 Firebird 버전 2.5.4부터 사용할 수 있으며, 당사의 FBDataGuard 도구는 버전 1.5-2.5에 대해 온라인 데이터베이스 검증을 지원합니다).
또한, 검증되지 않은 백업 외에도 때때로(예를 들어 일주일에 한 번) 검증된 백업을 수행하는 것이 좋습니다.
Firebird를 위한 권장 사항: 온라인 상태 점검 외에도 FBDataGuard를 사용하면 자동 모드로 백업 복원 프로세스를 테스트할 수 있습니다.
8. 백업 사본을 위한 여유 공간에 대한 통제 부재
사실 이것은 전형적인 실수입니다. 공간이 충분하지 않으면 백업 사본이 모든 여유 공간을 차지하고 프로세스는 오류로 종료됩니다. 백업 사본을 데이터베이스와 같은 디스크에 저장하면 데이터베이스 운영이 중단될 수 있고, 시스템 디스크에 저장하면 시스템 장애가 발생할 수 있습니다.
문제 4와 결합하면, 데이터베이스에도 여유 공간이 필요하지만 백업 사본이 이를 차지하고 있어 시스템이 작동을 멈추는 상황이 최선의 결과가 될 것입니다. 문제 5 및 2와의 결합에 관해서는, 다시 데이터베이스도 백업 사본도 남지 않게 됩니다.
권장 사항: 백업 크기를 예측하고 여유 공간 부족 가능성에 대해 경고하는 백업 도구를 사용하십시오.
Firebird를 위한 권장 사항: FBDataGuard는 백업 목적의 여유 공간 크기와 데이터베이스가 있는 디스크 및 시스템 디스크의 여유 공간 크기를 모두 제어합니다.
9. 백업 사본 생성에 걸리는 시간에 대한 통제 부재
불과 반년 전만 해도 백업 프로세스가 40분 걸렸는데 갑자기 3시간이 걸린다면, 그 이유는 무엇일까요? 데이터베이스 크기가 증가했거나 RAID 배열에서 디스크가 빠져 쓰기 성능이 상당히 느려졌을 수 있으며, 모든 백업 사본이 곧 사라질 위기에 처해 있을 수 있습니다. 또는 동료가 동시에 또 다른 백업 시스템을 실행했을 수도 있습니다(참고로 Firebird는 여러 백업 프로세스를 동시에 실행할 수 있지만, 왜 그것이 필요할 수 있는지는 그다지 명확하지 않습니다). 백업 사본 생성에 걸리는 시간을 통제하지 않으면, 새로 발생한 문제를 간과하고 문제가 커지기 전에 해결할 기회를 놓칠 수 있습니다.
또한, 백업 시스템이 백업 작업의 상태를 모니터링하지 않고 일정에 따라서만 실행한다면, 이전 백업 프로세스가 아직 끝나지 않았는데 시스템이 새 백업 프로세스를 시작하는 상황, 즉 “성급한 출발"을 쉽게 겪을 수 있습니다.
권장 사항: 백업 프로세스에 걸리는 시간을 통제하는 도구를 사용하십시오!
Firebird를 위한 권장 사항: FBDataGuard는 백업 프로세스에 걸리는 시간을 통제합니다.
10. 운영 체제 업데이트가 적용되는 동안 데이터베이스 백업
특히 문제 9와 결합하고 Windows 자동 업데이트가 활성화된 경우(기본적으로 업데이트는 오전 3시에 적용됨) 매우 흔한 문제입니다. 최선의 경우 속도 저하로 이어지지만, 업데이트를 적용하기 위해 운영 체제가 재시작되면 백업 사본이 손상됩니다. 적어도 다행인 점은 운영 체제가 매일 업데이트되지는 않는다는 것입니다.
권장 사항: 운영 체제 업데이트가 백업 프로세스를 방해하지 않는 시간에 예약하십시오.
11. 데이터베이스 서버가 실행 중인 상태에서 파일 백업 도구 또는 가상 머신 백업 도구를 사용하여 데이터베이스 백업
많은 관리자가 잊고 있는 사실은 모든 DBMS에는 읽고 쓰는 데이터를 담고 있는 활성화된 복잡한 캐시가 있으며, 데이터베이스 파일 자체는 임의 접근 모드로 열린다는 것입니다. 그렇기 때문에 단순한 파일 백업(데이터베이스 파일을 단순히 복사하는 것 포함)이나 가상 머신 백업 대신 특수한 백업 유형을 사용해야 합니다. 파일 백업 도구는 데이터베이스를 순차적으로 읽으며, 특히 대용량 데이터베이스의 경우 상당한 시간이 걸릴 수 있으므로 생성된 백업 사본의 무결성을 보장할 수 없습니다.
가상 머신은 스냅샷 및 Changed Block Tracking 메커니즘을 사용할 수 있지만, 일관된 데이터베이스 백업 사본을 얻으려면 생성된 백업 사본을 동기화해야 합니다. 변경된 블록 모음을 정리하는 순간에 데이터베이스에 대한 활성 쓰기 작업이 있으면 백업 사본이 일관되지 않게 되기 때문입니다.
파일 또는 가상 머신 백업 도구를 사용하여 데이터베이스를 백업하려는 분들을 위해 두 가지 방법을 제안할 수 있습니다:
- DBMS 서비스와 프로세스를 완전히 종료하여 캐시에 아무것도 남지 않도록 합니다,
- 데이터베이스 파일을 순차적으로 복사하는 것이 안전하도록 데이터베이스를 특수 모드로 전환하는 에이전트 및/또는 스크립트를 사용합니다. 예를 들어 MSSQL 데이터베이스에는 VSS writer라는 메커니즘이 있습니다. 요청 시 스냅샷이 만들어지는 순간 데이터베이스를 스냅샷 친화적 모드로 전환합니다. Changed Block Tracking 기반 메커니즘을 사용하는 경우, 동기화 시점에 데이터베이스가 일관성을 유지하도록 직접 확인해야 합니다.
데이터베이스를 백업 친화적 모드로 전환하지 않으면, 결과 데이터베이스 사본은 호스트 컴퓨터에서 하드 리셋(예: 정전)이 발생한 것처럼 보일 것입니다. 이러한 수준의 신뢰성은 대부분의 비즈니스에 절대적으로 불충분합니다. 이에 대한 자세한 내용은 “가상 머신에서 데이터베이스 작업 시의 특이점” 문서에서 확인할 수 있습니다.
Firebird의 경우, 백업 프로세스가 시작되기 전에 nbackup을 사용하여 데이터베이스의 주 파일을 잠그고 프로세스가 끝난 후 잠금을 해제해야 합니다. 다른 DBMS의 경우 해당 모드를 켜고 끄는 유사한 도구가 있습니다.
일부 데이터베이스 관리자는 DBMS에 트랜잭션 로그가 있으면 표준 파일 백업 도구로 데이터베이스를 안전하게 백업할 수 있다고 확신합니다. 최악의 경우 이 로그만 손상될 뿐이라고 생각합니다. 이것은 DBMS 개발자들이 지지하지 않는 위험한 오해입니다.
이 오해의 근원은 분명합니다. 가상 머신 및 백업 도구 개발자들의 공격적인 광고는 일반적으로 데이터베이스와 다른 집중적으로 업데이트되는 파일에는 고급 구성이 필요하다는 점을 언급하지 않습니다. 과대 광고를 믿지 마십시오. 모든 요구르트가 동일한 효능을 가진 것은 아닙니다.
권장 사항: 데이터베이스를 위한 해당 자동화 도구 없이 파일 및 VM 백업 도구를 사용하지 마십시오.
Firebird를 위한 권장 사항: FBDataGuard(HQbird 배포 패키지에 포함)를 사용하십시오. VSS 인식 백업 도구와의 통합을 제공합니다.
12. 백업을 복제로 대체
데이터 백업과 데이터 복제는 신뢰성을 높이고 데이터 손실을 방지하는 데 사용되지만, 여전히 상당히 다릅니다.
모든 사람이 최소 지연으로 다른 서버의 데이터를 동기화할 수 있는 복제 기능을 좋아하지만, 백업에도 확실한 장점이 있습니다. 예를 들어, 실수로(또는 의도적으로) 데이터를 삭제한 경우 복제는 변경 사항을 빠르고 태연하게 복제본으로 보내지만, 백업(특히 읽기 전용 미디어에 사본이 있는 경우)은 그러한 작업에 면역입니다. 복제와 백업을 모두 올바르게 구성하려면 상당한 노력이 필요하며, 그럼에도 불구하고 오류 가능성은 여전히 존재합니다.
권장 사항: 복제가 구성되어 있더라도 백업 사본을 소홀히 하지 말고 둘 다 사용하십시오.
Firebird를 위한 권장 사항: HQbird Enterprise 배포 패키지를 사용하십시오. 백업 및 복제 도구가 모두 포함되어 있습니다.
요약
좋아하는 DBMS를 위한 백업을 구성하는 것은 그리 쉬운 일이 아니므로, 일반적으로 데이터를 소중히 여기는 조직의 데이터베이스 관리자는 위에서 언급한 문제를 고려하고 문제를 예방할 수 있는 전문 백업 도구를 사용합니다.
Firebird를 위해서는(광고에 대해 양해를 구합니다) FBDataGuard가 포함된 HQbird라는 패키지가 있습니다.
또한, 당사는 Firebird 및 기타 데이터베이스에 대한 완전한 백업 및 유지 관리 지원을 제공하며, 이는 백업의 모든 기술적 세부 사항을 잘 모르는 분들에게 좋은 선택입니다.
그리고 물론, 관리자로서의 당신의 편집증을 계속 소중히 간직하세요. 예를 들어, 지금 당장 일어나서 백업 복사본을 확인해 보세요 :)
연락처
궁금한 점이 있으시면 언제든지 문의해 주세요: [email protected]
Firebird에 관한 뉴스와 기사를 받고 싶으신가요? Telegram https://t.me/firebirdsql에서 만나요