백업 데이터베이스 시 흔히 저지르는 12가지 실수
Alexey Kovyazin 작성, 2015년 11월 11일
PDF 다운로드 (영어) 이 기사는 원래 Firebird DBMS 개발자와 관리자를 대상으로 작성되었지만, 다른 데이터베이스 관리자들과의 접촉을 통해 대부분의 실수가 그들 사이에서도 공통적이며 말 그대로 모든 사람이 거의 같은 돌부리에 걸려 넘어진다는 것이 분명해졌습니다. 이 목록에 추가할 내용이 있다면(특정 DBMS에 특화된 내용이라도), 이메일 [email protected]을 통해 연락해 주십시오.
1. 새 백업 복사본이 생성되기 전에 이전 백업 복사본을 삭제하는 경우
이 실수는 데이터베이스 백업 복사본의 주요 목적이 단순히 데이터베이스 복사본을 만드는 것이 아니라 정보 시스템(그 중요한 부분이 데이터베이스임)의 다운타임을 가능한 한 짧게 만드는 것임을 깨닫지 못하는 초보자들에게 가장 흔합니다.
그 결과, 최신 백업 복사본이 삭제된 순간부터 새 복사본이 생성되는 순간까지 데이터베이스에 단 하나의 백업 복사본도 없기 때문에 시스템은 보호되지 않은 상태로 남게 됩니다. 백업 복사본을 만드는 데는 꽤 시간이 걸릴 수 있으므로, 머피의 법칙이 적용되기에 완벽한 시기입니다. 이 방식은 아래의 문제 7(참조)과 결합될 때 특히 효과적입니다.
권장 사항: 새 백업 복사본이 생성되기 전에 이전 백업 복사본을 삭제하지 마십시오! (그리고 기존 파일에 새 백업 복사본을 만들지도 마십시오).
Firebird에 대한 권장 사항: HQbird(Firebird의 고급 배포 패키지)에 포함된 FBDataGuard 도구는 새 백업 복사본이 생성된 후에만 기록상 가장 오래된 백업 복사본을 삭제합니다.
2. 백업 복사본에서 복원하는 동안 기존 데이터베이스를 덮어쓰는 경우
이 실수는 덜 흔하지만 결과는 훨씬 더 나쁠 수 있습니다. 백업 복사본이 검증되지 않았고 손상된 것으로 판명되면(문제 6 참조), 이전 데이터베이스 복사본도 유효한 백업 복사본도 모두 갖지 못하게 됩니다.
이런 엉망진창은 보통 금요일 저녁에 상황이 혼란스럽고 경영진의 지시가 모순적일 때 발생합니다. 약간의 불운과 함께 서버실에서의 나른한 주말이 당신을 기다리고 있습니다.
Firebird에는 이 실수에 대한 일종의 보호 기능이 있습니다. gbak 유틸리티의 기본 -create 스위치가 켜져 있고 지정된 파일 이름이 기존 데이터베이스를 가리키는 경우 백업 복사본에서 데이터베이스를 복원할 수 없습니다. 불행히도 이 보호 기능을 우회하는 방법이 있습니다. -rep 스위치는 여전히 기존 파일을 덮어쓸 수 있게 해줍니다.
권장 사항: 경영진의 서면 지시 없이는 운영 중인 데이터베이스의 파일을 절대 덮어쓰지 마십시오.
Firebird에 대한 권장 사항: FBDataGuard는 데이터베이스 파일을 절대 덮어쓰지 않으므로 이를 사용하십시오.
3. 중간 백업 파일 없이 원스텝 백업/복원을 사용하는 경우
표준 입력/출력 스트림을 사용하면 많은 DBMS( Firebird 포함)에서 재미있는 트릭을 구현할 수 있습니다. 즉, 스트리밍 백업을 수행하면서 동시에 그 백업에서 데이터베이스를 복원하는 것입니다. 그 결과 중간 백업 파일이 생성되지 않습니다. 이는 일상적인 유지보수와 테스트 복원 작업(다른 백업 복사본이 있는 경우)에 편리하지만, 자동 백업에는 사용해서는 안 됩니다!
예를 들어, 이 백업/복원 프로세스 중에 심각한 디스크 장애가 발생하면 새 데이터베이스가 아직 생성되지 않은 상태에서 원래 데이터베이스가 손상될 수 있습니다. 물론 문제 1을 고려하여 이전 시도의 데이터베이스 복사본이 있다면, 그 복사본이 생성된 후 데이터베이스에서 생성되거나 업데이트된 데이터만 손실됩니다.
권장 사항: 자동 모드에서는 원스텝 백업/복원을 사용하지 말고, 수동 모드에서는 항상 충분히 최신의 복사본이 있는지 확인하십시오.
4. 백업 복사본과 데이터베이스를 동일한 물리적 장치에 저장하는 경우
많은 분들이 우리가 주는 조언이 다소 유치하다고 생각할 수 있습니다 - 백업의 ABC라고요. 맞습니다, 사실입니다. 하지만 가상 환경의 대중화로 인해 데이터베이스와 디스크가 하나의 데이터 저장 시스템에 저장될 수 있습니다. 그리고 그것은 가장 부적절한 순간에 확실히 실패할 것입니다. 게다가 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. 백업 복사본 생성에 걸리는 시간에 대한 통제 부재
백업 프로세스는 정확히 6개월 전에는 40분이 걸렸는데 갑자기 이미 3시간이 걸린다면 - 왜 그럴까요? 데이터베이스 크기가 증가했거나 RAID 어레이에서 디스크가 빠져 쓰기 성능이 상당히 저하되어 모든 백업 복사본이 사라질 위기에 처했을 수 있습니다. 또는 좋은 동료가 동시에 백업 시스템을 하나 더 실행했을 수도 있습니다(그런데 Firebird는 한 번에 여러 백업 프로세스를 실행할 수 있지만 왜 그것이 필요한지는 명확하지 않습니다). 백업 복사본을 만드는 데 걸리는 시간을 통제하지 않으면 새로 발생한 문제를 간과하고 문제가 커지기 전에 해결할 기회를 놓칠 수 있습니다.
또한, 백업 시스템이 백업 작업의 상태를 모니터링하지 않고 일정에 따라 실행만 한다면, 이전 프로세스가 아직 끝나지 않았는데 시스템이 새 백업 프로세스를 시작하는 상황, 즉 “성급하게 시작"하기 쉽습니다.
권장 사항: 백업 프로세스에 걸리는 시간을 통제하는 도구를 사용하십시오!
Firebird에 대한 권장 사항: FBDataGuard는 백업 프로세스에 걸리는 시간을 통제합니다.
10. 운영 체제 업데이트가 적용되는 동안 데이터베이스 백업
이것은 특히 문제 9 및 활성화된 자동 Windows 업데이트(기본적으로 업데이트는 오전 3시에 적용됨)와 결합하여 매우 흔한 문제입니다. 기껏해야 속도 저하로 이어지지만, 업데이트를 적용하기 위해 운영 체제가 다시 시작되면 백업 복사본이 손상됩니다. 적어도 좋은 소식은 운영 체제가 매일 업데이트되지 않는다는 것입니다.
권장 사항: 운영 체제 업데이트가 백업 프로세스와 간섭하지 않는 시간에 예약하십시오.
11. 데이터베이스 서버가 실행되는 동안 파일 백업 도구 또는 가상 머신 백업 도구를 사용한 데이터베이스 백업
많은 관리자는 모든 DBMS에 읽고 쓰는 데이터가 포함된 활성 및 복잡한 캐시가 있고 데이터베이스 파일 자체가 임의 액세스 모드로 열려 있다는 것을 잊습니다. 그렇기 때문에 단순한 파일 백업(데이터베이스 파일 복사 포함)이나 가상 머신 백업 대신 특수 백업 유형을 사용해야 합니다. 파일 백업 도구는 데이터베이스를 순차적으로 읽으며, 특히 대규모 데이터베이스의 경우 상당히 오래 걸릴 수 있으므로 생성된 백업 복사본의 무결성을 보장할 수 없습니다.
가상 머신은 스냅샷 및 변경 블록 추적 메커니즘을 사용할 수 있지만, 일관된 데이터베이스 백업 복사본을 얻으려면 생성된 백업 복사본을 동기화해야 합니다. 변경된 블록 모음을 정리하는 시점에 데이터베이스에 대한 활성 쓰기 작업이 있으면 백업 복사본이 일관되지 않기 때문입니다.
파일 또는 가상 머신 백업 도구로 데이터베이스를 백업하려는 분들을 위해 두 가지 방법을 제안합니다:
- 캐시에 아무것도 없도록 DBMS 서비스와 프로세스를 완전히 종료합니다,
- 데이터베이스를 파일을 순차적으로 안전하게 복사할 수 있는 특수 모드로 전환하는 에이전트 및/또는 스크립트를 사용합니다. 예를 들어, MSSQL 데이터베이스에는 VSS writer라는 메커니즘이 있습니다. 요청 시 스냅샷이 만들어지는 순간 데이터베이스를 스냅샷 친화적 모드로 전환합니다. 변경 블록 추적 기반 메커니즘을 사용하는 경우 동기화 시점에 데이터베이스가 일관된 상태인지 직접 확인해야 합니다.
데이터베이스를 백업 친화적 모드로 전환하지 않으면 결과 데이터베이스 복사본은 호스트 컴퓨터에서 하드 리셋(예: 정전)이 발생한 것처럼 보입니다. 이 수준의 안정성은 대부분의 비즈니스에 절대적으로 충분하지 않습니다. 이에 대한 자세한 내용은 “가상 머신에서 데이터베이스 작업의 특성” 기사에서 확인할 수 있습니다.
Firebird의 경우 백업 프로세스가 시작되기 전에 nbackup을 사용하여 데이터베이스의 기본 파일을 잠그고 프로세스가 끝난 후 잠금을 해제해야 합니다. 다른 DBMS에도 해당 모드를 켜고 끄는 유사한 도구가 있습니다.
일부 데이터베이스 관리자는 DBMS에 트랜잭션 로그가 있으면 표준 파일 백업 도구로 데이터베이스를 안전하게 백업할 수 있다고 확신합니다. 왜냐하면 기껏해야 이 로그만 손상될 것이기 때문입니다. 이것은 DBMS 개발자가 지원하지 않는 위험한 오해입니다.
이 오해의 뿌리는 분명합니다: 가상 머신 및 백업 도구 개발자의 공격적인 광고는 데이터베이스 및 기타 집중적으로 업데이트되는 파일에 고급 구성이 필요하다는 사실을 언급하지 않는 경향이 있습니다. 과대광고를 믿지 마십시오 - 모든 요구르트가 동일한 효능을 가진 것은 아닙니다.
권장 사항: 데이터베이스에 대한 해당 자동화 도구 없이 파일 및 VM 백업 도구를 사용하지 마십시오.
Firebird에 대한 권장 사항: FBDataGuard(HQbird 배포 패키지에서)를 사용하십시오. VSS 인식 백업 도구와의 통합을 제공합니다.
12. 백업을 복제로 대체
데이터 백업과 데이터 복제는 신뢰성을 높이고 데이터 손실을 방지하는 데 사용되지만, 여전히 상당히 다릅니다.
모든 사람은 최소 지연으로 다른 서버의 데이터를 동기화할 수 있는 복제를 좋아하지만, 백업에도 확실한 장점이 있습니다. 예를 들어, 우발적(또는 의도적) 데이터 삭제의 경우 복제는 변경 사항을 신속하고 태연하게 복제본으로 보내지만 백업(특히 읽기 전용 미디어의 복사본)은 그러한 작업에 면역입니다. 복제와 백업을 모두 올바르게 구성하는 데는 일정한 노력이 필요하며 어쨌든 오류 가능성은 존재합니다.
권장 사항: 복제가 구성되어 있어도 백업 복사본을 소홀히 하지 말고 둘 다 사용하십시오.
Firebird에 대한 권장 사항: HQbird Enterprise 배포 패키지를 사용하십시오. 백업 및 복제 도구가 모두 포함되어 있습니다.
요약
즐겨 사용하는 DBMS에 대한 백업을 구성하는 것은 그렇게 쉽지 않으므로, 데이터를 소중히 여기는 조직의 데이터베이스 관리자는 일반적으로 위에서 언급한 문제를 고려하고 문제를 예방할 수 있는 전문 백업 도구를 사용합니다.
Firebird의 경우(광고로 사과드립니다) FBDataGuard가 포함된 HQbird라는 패키지가 있습니다.
또한, 당사는 Firebird 및 기타 데이터베이스에 대한 완전한 백업 및 유지 관리 지원을 제공합니다. 이는 백업의 모든 기술적 세부 사항을 알지 못하는 분들에게 좋은 선택입니다.
물론, 관리자로서의 의심병을 계속 간직하세요. 예를 들어, 지금 바로 일어나서 백업 복사본을 확인해 보세요 :)
연락처
궁금한 점이 있으시면 언제든지 문의해 주세요: [email protected]
Firebird에 관한 뉴스와 기사를 받아보고 싶으신가요? 텔레그램에서 함께하세요 https://t.me/firebirdsql