Cliffhanger : 백업이 옳아 요… 여기… 그렇죠?

내 작업에서 백업의 우선 순위는 놀라 울 정도로 낮습니다. 백업 전략은 얼마 전에 구현되었으며 그 이후로 백업이 정상이라고 가정합니다. 시스템 관리자에게 물어 보면 모든 것이 백업되었다고 말할 것입니다.

그러나 특정 백업을 요청할 때 절반이없는 백업 :

• 디스크가 가득 찼습니다
• 테이프 고장
• 누군가 백업 작업을 비활성화 한 것 같습니다
• 네트워크 연결이 중단되었습니다
• 몇 년 전에 디스크를 주문했지만 재무 부서에서 구매 주문을 승인하지 않았습니다.
• 파일이 손상되었습니다
• 파일에 잘못된 데이터베이스가 포함되어 있습니다
• 트랜잭션 로그 백업 만 (전체 백업 없이는 사용할 수 없음)

몇 주 전에 서버 중 하나가 너무 많은 RAID 디스크를 잃어 버려 재난이 가까워졌습니다. 운 좋게도 한 번의 디스크는 여러 번 시도해도 여전히 데이터를 복사 할 수있을 정도로 친절했습니다.

그러나 그 재난 이후에도 시스템 관리자가 상황을 개선하도록 설득 할 수없는 것 같습니다. 사람들의 시선을 여는 데 도움이되는 팁이 있습니까? 우리가 절벽의 가장자리를 따라 걷고있는 것 같습니다.

항상 이런 것들을 맨 위에서 고정시켜야합니다.

현재 백업 전략이 경영진에 의해 뒷받침되고 이해됩니까? 그렇지 않으면 쓸모가 없습니다.

경영진은 문제와 관련된 위험에 대해 알고 있어야합니다 (법적 생존을 위해 법적으로 가져와야하는 재무 데이터 또는 수집하는 데 몇 년이 걸리는 고객 데이터를 잃는가?). 누군가와 같은 행동을 취하게하는 것

관리 할 수없는 경우 데이터 검색 및 데이터 무결성이 회사의 보고서에 매우 중요한 비즈니스 컨트롤러 또는 기타 재무 상태를 시도하십시오. 필요한 경우 그들은 "폭풍을 시작할 수 있습니다"...

어디서부터 시작해야합니까? 이것은 일어나고있는 재앙입니다. Sysadmins 기본 작업 기능은 데이터를 백업하고 복구 할 수 있도록하는 것입니다. 다른 모든 것은 부차적입니다. 그렇지 않다면 아닙니다.

수행 할 수있는 몇 가지 작업은 다음과 같습니다.

1. 복원을위한 KPI 추적 복원 요청 횟수를 보여주는 보고서를 작성할 수 있어야합니다. 100 % 미만은 철저히 조사해야합니다. 경영학 사랑보고 그리고 이것은 어려운 증거입니다.

2. 모든 시스템 및 백업 전략, 테이프 순환, 일정, 에스컬레이션 경로, 테스트 복원 등 모든 백업 및 복원 작업에 대한 절차가 문서화되어 있어야합니다.

3. 시스템 관리자에게 문의하고 우려 사항을 말하십시오. 복원이 작동하지 않는다는 증거로 무장하십시오. 기쁨이 없으면 더 높아집니다.

진지하게-소란을 걷어차십시오. 이런 것들이 회사를 파괴 할 수 있습니다.

매년 최소한의 재해 복구 테스트를 제안하십시오. 테스트를 성공적으로 수행하는 데 필요한 작업은 단점을 드러내야합니다.

제가 일하는 곳에는 매우 훌륭한 IT 부서가 있습니다. 매년 유럽 전역의 모든 사무실에서 모여 데이터 센터의 임대 서버에 '복원 페스트'를 수행하여 직원이 하루에 일을했을 때 일어날 일을 효과적으로 시뮬레이션합니다. 밤에는 사무실이 불타 버렸습니다.

큰 상사를 참여시켜 재난이 닥쳤을 때, 그해에 보너스를받지 못했거나 (혹은 더 나빠진) 그와 비슷한 재난 복구 운동을 조직하는 것이 현명 할 것임을 상기 시키십시오. 시간이 오래 걸리거나 비용이 많이 들지 않아야합니다. 관리자는 오프 사이트 백업 테이프와 함께 보내져 동일한 사무실 환경을 조성하라는 지시를받습니다.

경영진이 회사 데이터가 영구적으로 손실 될 위험이 높다는 사실을 알게되면 스파크가 날 것입니다 (전략적으로 관리자에게 배치 된 로켓에서).

관리자를 탓하기는 쉽지만 오스카르는 그 점을 잘 알고 있습니다. 경영진이 백업을 우선 순위로 삼는 데 드는 비용을 들이지 않는다면, sysadmins는 일반적으로 운이없고 자신이 가진 자원으로 최선을 다합니다.

당신이 그 운이 좋지 않은 관리자 중 한 명이라면 (그리고 일부 고객과의 계약을 위해이 보트를 이용했다면), 관리가 브리핑되고, 반복적으로, 그리고 후행 확인 가능한 방식으로 이루어 지도록하는 것이 중요합니다. 사업에 대한 위험.

나의 전략은 끊임없이 문제를 해결하는 것입니다. 그렇게하면 문제가 해결되는 경우도 있지만 대부분 내가보고 한 사람이 "내가 브리핑을하지 않았다"는 변명을 숨길 수없는 경우가 대부분입니다. 컨설턴트로서 나는 보통 한 가지 더 나아갈 수 있습니다. 상사에게 취약점이 있다는 것보다 더 고위 경영진을 간략하게 소개 할 수 있습니다. 이것은 책임을 주변에 퍼뜨 리거나 적어도 나보다 높은 수준으로 집중시킵니다.

동시에, 고객이 제공 할 수있는 모든 리소스로 위험을 최소화하기 위해 창의력을 발휘하고 열심히 노력해야합니다.

어떤 경우에는 관리자가 위험에 처할 수 있지만, 위험을 파악하고이를 완화하기에 충분하지 않거나, 이러한 위험에 대해 경고하지 않는 사람들을 고용하는 경우 관리자가 항상 책임을집니다.

영국 북서쪽으로 퍼져있는 약 200 대의 서버에 대한 책임은 수동으로 확인하기에는 너무 많습니다.

백업이 완료되면 백업 로그를 살펴보고 백업이 작동했는지 여부를 확인하고 백업 결과와 함께 중앙 데이터베이스에 레코드를 기록하는 (VBScript) 스크립트를 실행하도록 백업을 구성합니다. 그런 다음 본사에서이 데이터베이스를 쿼리하고 백업에서 오류를보고했거나 사이트의 보고서가없는 사이트 목록을 제공하는 스크립트를 실행합니다.

결과적으로 책상에 앉으면 백업을 확인해야하는 모든 사이트 목록이 나타납니다.

모든이의 요점은 기본 가정은 백업이 실패하고, 백업이 내 VBScript를이 오류를 감지되지 않을 경우에만 작동 한 것으로 간주된다는 것이다 및 내 데이터베이스에이 결론의 I를 썼다. 이렇게하면 백업 실패가 눈에 띄지 않게됩니다.

일부 서버는 Backup Exec, 일부 NTBackup을 사용하고 일부는 네트워크를 통해 다른 서버로 파일을 복사합니다. 오류를 확인하기 위해 VBScript를 쉽게 조정할 수 있으므로 서버의 백업 유형은 중요하지 않습니다. 내 스크립트는 실제로 매우 기본적입니다. 백업 보고서를 텍스트 파일로 열고 "실패 실패", "전체 테이프 녹화", "CRC 오류"등과 같은 문구에 대해 grep합니다. 전문 프로그래머가 할 것이라고 확신합니다. 더 매끄러운 직업. 그러나 모든 것이 간단하고 강력하며 백업 실패 보고서를보고 싶은지 아닌지를보고 의식적으로 보고서를 무시하기로 결정한 경우에만 오류를 알리지 않을 것입니다.

JR

PS 백업 실패의 99 %는 사용자가 백업 테이프 변경을 잊었 기 때문입니다. 당신은 단지 lusers를 사랑하지 않습니다 :-)

테스트되지 않은 백업은 백업이 아닙니다.