트랜잭션 로그를 백업하는 것이 왜 그렇게 중요합니까?

현재 클라이언트를위한 백업 솔루션을 구현하고 있으며 ERP 솔루션은 SQL Server를 사용합니다.

ERP 솔루션은 다른 회사에서 설정했습니다. 그리고 그들은 트랜잭션 로그를 백업하고 자르는 것이 매우 중요하다고 나에게 말하고 있습니다.

이 트랜잭션 로그에서 약간을 읽었으며 어쨌든 전체 머신을 이미 백업 할 때 이것이 왜 중요한지 알지 못합니다 (우리는 SQL Server를 알고 사용하는 ArcServe UDP를 사용하고 있습니다. VSS). SQL Server VM의 정리 작업이 이미 로그 잘라내기를 처리하고 있지만 UDP에서도 SQL Server 로그 잘림을 허용한다는 것을 이해하고 있습니다.

트랜잭션 로그는 손상된 데이터베이스를 복원하는 데 사용될 수 있다는 것을 이해합니다. 왜냐하면 모든 트랜잭션의 로그이기 때문입니다. 그러나 이미 전체 데이터베이스를 한 시간 단위로 백업하고 있는데 왜 걱정해야합니까?

DB 복구 모드가 "full"로 설정된 경우에만이 작업을 수행해야합니다. "단순"으로 설정되어 있으면 트랜잭션 로그를 백업 할 필요가 없습니다. 그러나이 두 옵션의 차이점에주의하십시오!

우선 : DB를 특정 시점 으로 복원 하려면 "전체"모드를 사용해야합니다. (복원 지점의 밀리 초를 지정할 수 있도록 타이밍을 정확하게 조정할 수 있다고 생각합니다.) "단순"모드에서는 마지막 전체 백업으로 만 돌아갈 수 있습니다 .

트랜잭션 로그를 백업 / 잘라 내지 않으면 전체 시간 (전체 모드)으로 증가합니다. .trn 파일이 데이터베이스 자체보다 두 배 이상 큰 데이터베이스를 보았습니다. 이것은 DB가 얼마나 자주 변경되었는지에 달려 있습니다.

또 다른 요점은 일반적으로 로그 백업이 전체 백업보다 빠르다는 것입니다.

따라서 매 시간마다 전체 백업을 수행하는 백업 계획이 최적이 아니라고 생각합니다. 그러나 상황에 따라 다릅니다.

당신이 말하는 경우 : 좋아, 내가 마지막 전체 시간까지 DB를 복원 할 수 있다면 모든 것이 괜찮습니다. -> 매시간마다 전체 백업을 유지하려면 복구 모드를 "단순"으로 설정할 수도 있습니다.

제 생각에는 이른 아침에 전체 백업을 한 다음 매시간마다 트랜잭션 로그 백업을 수행하는 것이 좋습니다. 훨씬 빨라야하며 원하는 시점으로 복원 할 수 있습니다. 또한 .trn 파일이 너무 커지지 않습니다 ...

도움이 되었기를 바랍니다.

잘. 복구 모델이 전체로 설정되어 있고 서버 백업이 아닌 SQL 백업을 사용하여 트랜잭션 로그를 백업하지 않으면 사용 가능한 모든 디스크 공간을 사용할 때까지 트랜잭션 로그가 계속 커집니다. (한 번 더 적은 동료가 시스템 드라이브에 SQL Server를 설치하고 트랜잭션 로그를 백업하지 않는 것을 보았습니다. Windows를 먹었습니다 .)

예, 특정 시점으로도 복원됩니다. 분까지. Twinkles처럼 사람들은 테이블 등을 떨어 뜨립니다.

전체 데이터베이스의 시간별 백업에 사용하는 것이 무엇인지, 그리고 전체 컴퓨터에 사용하는 것과 동일한 제품인지 모르겠습니다. 그렇다면 비 SQL 인식 백업 솔루션은 복원에 지원되지 않습니다. 예를 들어 VSS가 MDF 및 LDF 파일을 복사하는 데 걸리는 시간으로 인해 내부 타임 스탬프 불일치가 발생할 수 있습니다.

여러 ERP 시스템도 관리합니다. 그리고 문제는 종종 밤에 다른 시스템과 데이터를 동기화하는 장시간 실행되는 배치 작업이 있다는 것입니다. 그리고 때로는 1 시간 이상이 걸립니다. 따라서 충돌이 발생했을 때 수행하려는 작업은 일관된 데이터가있는 지점으로 이동하는 것입니다. (두 배치 작업 사이에서 올바른 것을 의미합니다.) 시간 만 볼 경우 현재 데이터베이스의 상태를 정확히 알지 못할 수도 있습니다.

물론 상황에 따라 다릅니다. 자동화 된 작업 등이없는 경우 시간별 백업으로 완전히 괜찮을 수 있습니다.

몇 가지 이유는 다음과 같습니다.

1. 데이터베이스 시스템은 일반적으로 초당 수천 건의 트랜잭션을 수행하고 있습니다. 데이터는 다른 파일 시스템의 여러 파일에 분산 될 수 있습니다. 복원 후 데이터베이스가 일관된 (일명 사용 가능한) 상태인지 확인하는 것은 쉬운 일이 아닙니다. 백업 솔루션이 작업에 달려 있다면 큰 도움이되지만 작업에 베팅하기 전에 이에 대해 확신하는 것이 좋습니다.
2. 예 : 누군가 실수로 중요한 데이터가있는 테이블을 삭제합니다. 특정 시점 복구 기능이있는 데이터베이스 백업이있는 경우 전체 시스템을 복원하지 않고도 데이터를 신속하게 복원 할 수 있습니다.
3. 데이터베이스가 전체 복구 모드 인 경우 SQL Server의 트랜잭션 로그가 커집니다. 트랜잭션 로그의 저장 공간은 트랜잭션 로그가 백업 된 경우에만 재사용됩니다. 트랜잭션 로그를 정기적으로 백업하지 않으면 남은 공간이 없을 때까지 파일 시스템이 채워집니다. 이 시점에서 새로운 거래를 시작할 수 없기 때문에 모든 것이 즉시 중단 됩니다.

데이터베이스가 한 시간 안에 백업 할 수있는 것 이상으로 커지면 다른 모델이 필요합니다.

데이터베이스의 전체 백업은 로그를 자르지 만 "SQL 인식"이어야합니다.이 시나리오에서는 SQL 서버에 백업 대상과 자르는 내용을 알려주는 백업 소프트웨어이기 때문입니다.

다른 사람들이 언급했듯이 "전체"복구 모델에 데이터베이스가 있으면 전체 SQL 인식 백업을 수행 할 때까지 트랜잭션 로그가 무한대로 커집니다.

복구 는 백업이 아니라 실제로 문제입니다. 그리고 그것은 기술적 결정이 아니며 사업 결정입니다!

비즈니스 소유자가 1 시간 또는 그 이상의 데이터베이스 트랜잭션을 잃어도 괜찮다면 (다시 실행하기가 매우 어렵거나 불가능할 수 있습니다!) 모델이 작동합니다. 백업에서 전체 데이터베이스를 복원하는 동안 몇 시간 동안 시스템이 다운 된 상태에서 정상이면 모델이 작동합니다.

그러나 비즈니스에서 ERP 시스템을 운영에 중요한 자산으로 간주하는 경우 (모두 아님) 중요한 서비스에 대해 허용 가능한 최대 복구 시간 (일명 RTO, 복구 시간 목표)을 설정하는 것이 비즈니스 결정입니다.

또한 비즈니스 소유자 또는 시스템 이해 관계자는 RPO (Recovery Point Objective)라고하는 사고에서 손실 될 위험이있는 데이터의 양을 정의해야합니다.

"데이터를 잃어 버릴 수 없습니다! ERP 시스템은 연중 무휴 24 시간 이용 가능해야합니다!"라고 대답하면 비용 효율성이 낮을 것입니다. 이러한 완전 이중화 논스톱 시스템 구축과 관련된 비용을 제시하면보다 합리적인 수치를 얻게됩니다 ..;)

요점은 거래 손실을 피할 수 있다면 잠재적으로 수백 또는 수천 시간의 근무 시간을 절약 할 수 있다는 것입니다. 그것은 모든 회사에서 엄청난 비용을 절약하고 회사의 규모에 따라 커집니다.

모든 사람들이 이것에 대해 큰 반응을 보였지만 다른 중요한 메모를 추가하고 싶습니다 ... 또는 두 개.

SQL Server 복구 모델의 특정 사항과 데이터 손실에 대한 비즈니스 요구 사항을 아는 것이 매우 중요합니다. 그러나이 경우 백업 제품이 SQL Server에서 작동하는 방식을 이해해야합니다. (위의 설명에 따르면 VSS 복사를 통해 디스크 볼륨을 백업하는 것처럼 들립니다. 이는 SQL Server 백업이 추가로 필요하거나 필요하지 않을 수 있음을 의미합니다.)

최근에 비슷한 제품을 평가 한 후에 물어봐야 할 중요한 사항은 다음과 같습니다.

• 전체 복구에서 데이터베이스의 특정 시점으로 복원은 어떻게 수행됩니까?
• 전체 복구에서 새 데이터베이스에 대한 초기 백업은 어떻게 처리됩니까?
• 백업 제품이 특정 시점으로 복원하기 위해 SQL Server 로그 백업이 필요합니까? (제 경우에는 대답이 그렇습니다.)
• 스토리지 인프라가 정상적인 SQL로드 외에 VSS 사본 / 차등 (주어진 간격으로)의 데이터 볼륨을 처리 할 수 ​​있습니까?

이것이 도움이 되길 바랍니다.

우리 팀이 최근에 평가 한 경험은 위의 질문에 대한 매우 흥미로운 답변을 제공했습니다. 한 가지 확실한 것은 VSS 백업 제품을 사용하면 백업이 더 복잡하다는 것입니다.

다른 많은 사람들이 이미 말했듯이 타사 도구를 사용하여 VM 또는 스토리지를 백업 / 스냅 샷하는 경우 여전히 유효한 백업이 없을 위험이 있습니다. SQL Server 백업을 관리하는 모든 타사 도구는 VSS를 사용하여 SQL Server를 구현하고 연결합니다. 이렇게하면 SQL Server가 데이터 파일에 대한 모든 I / O를 중지하도록 요청하여 일관된 스냅 샷을 만들 수 있습니다. 그렇지 않은 경우 다양한 상태의 많은 트랜잭션을 가질 수 있으며 복원시 해당 트랜잭션을 롤 포워드 또는 백 워드 할 수 있는지 알 수 없습니다.

나는 모든 타사 VM / 스토리지 스냅 샷 도구로 작업하지는 않았지만, 내가 작업 한 것은 시스템 데이터베이스가 위치한 스토리지를 스냅 샷 할 수 없었습니다. SQL Server는 이러한 데이터베이스를 정지시킬 수 없습니다. 그들은 모두 BACKUP DATABASE 명령을 실행 한 다음 백업 파일 자체를 스냅하는 것과 같은 스트리밍 방식으로 해당 데이터베이스를 백업했습니다.

무엇보다도, 전체 복구 모델에 있고 BACKUP LOG 문을 정기적으로 발행하지 않으면 디스크에 여유 공간이 없을 때까지 트랜잭션 로그가 계속 커집니다.

실제로 궁금한 점이 있으며, 위에서 놓쳤을 수도 있습니다 ...이 백업에서 여러 번 성공적으로 복원 했습니까? 복원 된 데이터의 일관성에 만족하십니까? 개인적으로도 충분하지는 않지만 여전히 주사위 굴림처럼 느껴지며 백업 및 복구와 관련하여 DBA가 결코 취하지 않는 좋은 일입니다.

트랜잭션 로그는 단순히 복구 메커니즘이 아니라는 점을 인식하십시오. 적절한 로그 유지 관리는 전체 데이터베이스 성능 (예 : 트랜잭션 처리량)에서 중요한 역할을 할 수 있습니다.

로그 파일을 자주 백업하면 몇 가지 작업이 수행됩니다.

1. 실제 로그 파일에서 VLF 수를 줄여 성능에 좋습니다.
2. 데이터베이스를 복구해야하는 경우 로그 백업을 사용하는 것이 좋습니다.
3. 전체 백업보다 훨씬 빠릅니다.

매시간 전체 백업을 수행 할 수 없다면 더 빈번한 로그 백업의 이점을 확신 할 수 없습니다. 결국 전체 백업은 전체 복원을 위해 필요한만큼의 로그도 백업합니다.

반면, 앱이 매시간 전체 백업 사이에 많은 트랜잭션을 생성하면 원래 개발자가 더 세분화 된 로그 유지 관리를 제안한 이유를 설명 할 수 있습니다. 많은 트랜잭션이 로그에서 VLF 수를 증가시켜 로그가 잘릴 때까지 성능이 저하 될 수 있습니다. 나는 이것을 응용 프로그램 내에서 ( 쿼리가 만료 되기 직전에) '쿼리 시간 초과 만료' 오류 로 표현하는 것을 보았습니다 .

트랜잭션 로그 유지 관리와 관련된 권장 사항은이 문서 8 트랜잭션 로그 처리를 개선하는 단계에 잘 설명되어 있습니다. 또한이 기사에서는 효과적인 데이터베이스 유지 관리를위한 주요 팁에 대해 매우 유용한 VLF 수 (<200)를 언급했습니다.

다른 사람들은 이미 트랜스 로그 백업 등에 대한 대부분의 이유를 제시했습니다. 이미 서버를 백업 할 때 이것이 왜 좋은 전략인지에 대해서는 의문의 여지가 있습니다.

위에 있지 않은 몇 가지 이유가 있습니다. 타사 앱이 백업을 수행하지 못하면 복원 할 수 있습니까? 백업을 복원하려고 했습니까? 템플릿으로 구축 한 새 서버 (DR 생각)는 어떻습니까? 데이터 정렬이 다른 도메인의 다른 서버는 어떻습니까? 또는 SQL 인스턴스?

때로는 타사 앱이 가장 빠른 복원 방법이 아닌 경우를 제외하고 중복 백업을 수행합니다. 타사 앱이 저장하는 저장 용량이 영향을 받거나 자체 이유로 손상되는 경우가 있습니다.