백업 확인 모범 사례?

관리자가 자동 ​​백업 시스템을 만들고 잊어 버린 경우가 일반적입니다. 시스템이 관리자 통지에 실패한 후에 만 ​​해당 결함으로 인해 백업 시스템이 고장 났거나 백업을 복원 할 수없고 복원 할 현재 백업이 없습니다. 따라서 이러한 상황을 피하는 모범 사례는 무엇입니까?

소방 훈련을 실행하십시오 ... 2 개월마다 XYZ 시스템이 다운되었다고 말하는 것이 좋습니다 ... 실제로 새로운 VM 등으로 온라인으로 가져 오는 움직임을 겪습니다. 정직하게 유지하고 잡는 데 도움이됩니다. 실수.

soapbox 모드 : ON

정기적으로 테스트되지 않은 백업은 그다지 가치가 없다고 말합니다.

저의 이전 작업에서는 모든 시스템 (생산, 테스트, 개발 모니터링 등)을 6 개월마다 테스트 복원해야한다는 정책이있었습니다.

이것은 또한 문서를 최신 상태로 유지하기 위해 가장 후배 관리자의 일이었습니다. Junior는 특정 시스템에서 얼마나 많은 작업을 수행했는지에 따라 정의되며 언젠가는 실제로 "그룹 관리자"였습니다.

우리는 복원 된 호스트에서 실제로 무언가를 실행할 필요가 없기 때문에 디스크 공간을 제외한 모든 사양이 낮은이 하드웨어 (Intel 및 IBM / AIX 상자 하나) 전용 하드웨어를 가지고있었습니다.

처음 몇 차례의 작업은 상당히 많았지 만 백업의 중요한 부분 인 복원 프로세스를 간소화했습니다.

관리자가 백업 작업이 중단되었다는 것을 알지 못하고 작동하는 백업이 제대로 작동하지 않는다는 사실을 언급하는 것처럼 보이기 때문에 백업 주위에 일종의 모니터링 스크립트를 작성하는 것이 좋습니다.

자체 개발 한 백업 솔루션을 구축 할 때 다음과 같이합니다.

• 데이터를 백업하는 스크립트를 작성하십시오.
• 테스트 복원을 수행하여 스크립트가 올바르게 작동하는지 확인하십시오.
• 스크립트 또는 다른 방법을 통해 백업 상태 (성공, 실패, 실행, 실행되지 않음)를 추적하는 방법을 구현하십시오.
• 추적 상태를 모니터링합니다 (이메일, 데이터베이스 등)

이 모든 것이 끝나면 괜찮을 것입니다. 추가로 할 일은 정기적 인 테스트 복원을 수행하는 것입니다. 그 원인에 기부 할 여분의 하드웨어가 있다면.

내가 일하는 곳에서는 따뜻한 사이트가 있으며 한 달에 한 번 시스템이나 데이터베이스를 무작위로 선택하고 따뜻한 사이트로 이동하여 베어 메탈에 대한 테스트 복원 연습을 수행하여 데이터를 복구 할 수 있습니다.

솔직히 말해서 데이터가 매우 중요한 경우 백업 관리를 위해 일부 소프트웨어에 투자하는 것이 가장 좋습니다. 저렴하고 간단한 것에서부터 엔터프라이즈 급에 이르기까지 수백 가지의 제품이 있습니다.

회사 백업을 위해 crontab에서 실행되는 손으로 쓴 스크립트 세트에 의존하는 경우 조만간 화상을 입을 수 있습니다.

우리는 '생산'시스템의 60 % 크기의 '참조'버전을 가지고 있으며, 변경 사항을 최종 테스트하기 위해이를 사용하고,이 시스템으로 '생산'백업을 복원합니다. 백업을 테스트하고 두 환경이 서로 나란히 있는지 확인합니다. .

한 가지 방법은 "복구"작업을 정기적으로 실행하도록 스크립트하는 것입니다 (예 : 가장 최근 백업에서 특정 텍스트 파일을 가져 와서 내용을 이메일로 보내는 작업). 가능하다면 데이터를 생성하거나 백업 한 상자와 다른 상자를 사용하여 수행해야합니다. 장점은 암호화 / 암호 해독, 압축 및 저장 메커니즘이 모두 작동하는지 확인할 수 있다는 것입니다.

소규모 DB 또는 브릭 수준 사서함 백업에서 일종의 소규모 복구를 수행하고 내용을 확인하는 것이 가능하지만 약간 더 복잡하지만 전자 메일 및 데이터베이스 서버와 같은 특수 백업에는 조금 더 복잡합니다.

이 접근 방식은 또한 비상시 데이터를 복구 할 수 있도록주기적인 전체 복원을 대체하지 않아야합니다. 일상적인 백업 작업의 무결성에 대해 조금 더 확신 할 수 있습니다.

테스트 복원을 수행 할 때 "이것은 멋지다, 파일이 복원 됨, 파일이 누락 된 것 같지 않은 것, 크기가 일치하는 것"또는 "이것이 멋지다"라는 시점에서 실제로 편안하지 않다. 나는 애플리케이션을 시작했다. ..가 충돌하지 않고 적절한 데이터를 표시합니다. "

서버 / 클러스터를 처음부터 복원 한 다음 실제로 프로덕션에 사용하려고합니다 . 1 분이 아니라 1 시간이 아니라 영구적 입니다. 복원이 완료되었다고 주장하는 경우 프로덕션을 시작하지 않을 이유가 없습니다. 이것은 "더러운"시스템이 아니며 잊혀져 야합니다. 이것은 실제 재난 후에 직면하게 될 시스템입니다. 따라서 "좋아 보인다"단계를 통과하면 함께 살아라. 다음날 밤에 백업하십시오. 원래는 잊어 버리십시오. 당신은 아마 것이다 이 방법을 사용하여 일부 결함을 발견, 당신은 할 것 강제 하기 위해 그들 모두를 해결 . 동일한 시스템을 다음에 복원 할 경우 100 % 성공할 수 있습니다.

여기에는 백업 소프트웨어 및 서버가 포함됩니다. 예, 이것도 복원해야합니다.

복원 전용 하드웨어를 구입할 예산이 없습니까?

• 예산이 절대적으로 필요하다는 점을 지적하십시오. 모든 경우에 의사 결정자에게 유효한 전체 복원 테스트가 아직 수행되지 않았 음을 상기시킵니다. (그렇습니다. 엉덩이를 덮기위한 증거를 수집하십시오. 거친 세상.)
• 대부분의 조직에서는 일부 시스템을 다른 하드웨어로 마이그레이션해야 할 때가 있으므로 기회를 활용하십시오. 원래 하드웨어를 잃어버린 것처럼 항상 마이그레이션을 위해 "백업에서 복원"방법을 선택하십시오. 예, 더 많은 가동 중지 시간을 의미합니다. 죄송합니다. 최소한 백업이 유용하다는 확신이있을 것입니다.
• 마이그레이션이 없습니까? 어쩌면 2 주 동안 일부 하드웨어를 빌려서 두 가지 복원 테스트를 수행 할 수 있습니다 (빌린 하드웨어로 복원, 일주일 이상 기다렸다가 빌린 상태에서 원래 상태로 복원, 라이브). 일반적으로 일부 새 시스템에 대해 구매 한 새 하드웨어가 있고 올바르게 배치하면 2 주 동안 철저한 테스트를 제공하여 쉽게 빌릴 수 있습니다. 새 하드웨어가 이전 하드웨어와 100 % 일치하지 않으면 테스트가 더욱 향상됩니다. 실제 재난 발생시 동일한 하드웨어를 사용하는지 어떻게 알 수 있습니까?
• 현재 새로운 시스템이 구현되고 있습니까? 지금 복원을 테스트 할 수 있습니까? 추가 하드웨어를 사용하지 말고 신속하게 다시 구현하는 방법에 대한 새로운 지식이 있으므로 새 시스템을 덮어 쓰십시오. 아직 중요한 데이터가없는 경우 작동합니다. 다시 새로 설치 한 버전이 아니라 복원 된 버전의 프로덕션으로 이동하십시오.

1. 소방 훈련.
2. 6 개월마다 모든 백업을 테스트하는 정책은 매우 좋습니다.
3. 테스트 할 때는 백업 할 각 응용 프로그램이나 시스템을 살펴 봐야합니다. 이상적으로 "성공"또는 "복구 가능"백업을 구성하는 것은 백업에 대한 서비스 설명 또는 SOP (운영 설명서)에 보존 시간, bladibla와 같은 기타 세부 사항과 함께 나열되어야합니다.

일부 백업 유형은 스크립트 (예 : 데이터베이스)로 쉽게 복원 테스트 할 수있는 반면 다른 백업 유형은 수동 입력 (Active Directory 복원)이 필요합니다. 이 작업을 최대한 자동화하고, 어떤 종류의보고가 있는지 확인하고, "누군가"도 정기적으로 수동 테스트를 수행해야합니다. 격리 된 환경 (제품의 축소 사본)을 통해 복원 테스트를보다 쉽게 ​​수행 할 수 있습니다.

백업을 테스트하지는 않지만 BackupRadar.com을 개발 한 시스템에 중앙 집중식 백업 확인 및보고 구성 요소가 있습니다. 해당 구성 요소에 도움이되는지 확인하십시오. 성공 / 실패 이메일 사본을 백업 정책에 첨부하고 백업 소프트웨어가이를 전송할 수있는 경우 스크린 샷도 첨부합니다.

고마워, 패트릭

백업 활동이 기록되어 있는지 확인한 다음 실패를 찾는 로그를 구문 분석하고이를 증류하여 매일 이메일로 보내도록 펄 (물론)로 무언가를 작성하십시오.