Paul Randal 은 SharePoint SQL 데이터베이스의 모범 사례에 대해 정말 좋은 질문을했습니다. 현재 고객이 SharePoint 설치를 유지 관리하는 동안 SharePoint 데이터베이스에 가장 적합한 SQL 복구 모델에 대한 질문을 받았습니다.
간단한 복구 모델을 사용하는 것이 내 관행입니다 (나는 DB 관리자가 아닙니다 :))). SharePoint 데이터베이스가 정기적으로 백업되고 항목 수준별로 타사 도구 백업이있는 경우 실제로 전체 로그를 보유 할 필요는 없습니다.
여기에 뭔가 빠졌습니까? 이것이 올바른 접근입니까? SharePoint DB 로그를 사용하여 데이터를 복구 한 적이 있습니까?
답변:
그것은 당신이 잃어버린 데이터의 양과 필요한 관리 노력의 양에 전적으로 달려 있습니다. 간단한 복구 모델을 사용하고 일요일에 일주일에 한 번 백업을하는 경우 ... 토요일 11:59에 충돌이 발생하면 일주일의 작업이 손실됩니다. 백업 빈도를 늘리거나 차등을 적용하면 데이터 손실량이 줄어 듭니다.
정기적 인 전체 / 차등 백업을 수행하지만 트랜잭션 로그와 함께 전체 복구 모델을 사용하면 마지막 백업을 복원 한 다음 충돌 직전의 시점으로 트랜잭션 로그를 재생할 수 있으며 데이터 손실이 거의 없습니다.
폴 랜달의 말하기 ... 그는 단지 TechNet의 잡지 이번 달 정확하게이 주제에 대한 좋은 기사를 쓴 :) http://technet.microsoft.com/en-us/magazine/dd822915.aspx
데이터베이스 만 백업해도 모든 공유 지점 정보를 얻을 수있는 것은 아닙니다. 물론 데이터베이스의 모든 것을 얻을 수 있지만 모든 사용자 정의 및 모양과 느낌이 손실됩니다. 이것은 관리자에게는 중요하지 않지만 사용자가 불행 할 것이라고 확신합니다.
옵션에는 백업 소프트웨어의 공유 지점 데이터베이스를 읽을 수있는 백업 에이전트를 가져 오거나 구성 정보를 가져 와서 SQL 데이터베이스 백업을 안전한 곳에 보관하는 스크립트 백업을 수행하는 것이 포함됩니다.
http://technet.microsoft.com/en-us/library/cc288330.aspx 정보가 있습니다.
백업을 테스트하십시오. 그것들을 복원하십시오. 무엇이 바뀌고 무엇이 효과가 없는지보십시오. 우리의 첫 복원은 예전만큼 좋지 않았습니다. 다행스럽게도 손실되거나 파괴 된 데이터를 복구하려는 것이 아니라 프로덕션 서버와 동일한 테스트 서버를 만드는 과정의 일부에 불과했습니다.
관련성 편집 이 글을 다시 읽었을 때주의가 산만 해져서 내 대답의 답을 놓쳤다는 것을 알게되었습니다. 트랜잭션 로깅을 사용하여 전체 백업을 수행하면 훨씬 더 정밀한 시점으로 롤백 할 수 있습니다. 이것은 DBA로서 더 많은 기술이 필요하지만 그렇게 어렵지는 않습니다. 업데이트가 많지 않고 하루 종일 작업을 잃어 버린 것이 세상의 끝이 아니라면 아마 괜찮을 것입니다. 다른 옵션으로는 단순 백업을 더 자주 실행하는 것이 있습니다. 자정, 오전 10시, 오후 2시, 오후 6시 또는 조직의 작업주기에 적합한 모든 것을 말하십시오. 그러면 더 많은 디스크가 소모되지만 데이터 손실 위험이 줄어 듭니다. 모든 백업과 마찬가지로 사용자가 허용하는 것과 관리자가 제공 할 수있는 것 사이의 균형입니다.
Sharepoint는 SQL 데이터베이스이므로 SQL 데이터베이스처럼 취급해야하므로 매장 설정시 모든 일반 SQL 설정 예방 조치를 취하십시오. 백업의 경우 데이터베이스를 정기적으로 백업해야 할뿐만 아니라 모든 SP 정보를 보유한 12- 하이브를 백업해야합니다.
자세한 내용은이 스레드를 확인하십시오. http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea