백업 및 복구 관련 최상의 방법(SharePoint Server 2010)

  • 아티클

 

적용 대상: SharePoint Foundation 2010, SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 문서에서는 Microsoft SharePoint Server 2010의 백업 및 복구 작업을 성공적으로 수행하고 데이터 손실 또는 연속성 격차에 대해 환경을 보호하는 데 사용할 수 있는 최상의 방법에 대해 설명합니다. 여기에는 성능, 품질 보증, 보안 및 운영과 관련된 최상의 방법이 포함되어 있습니다.

이 문서의 내용:

  • 성능 관련 최상의 방법

  • 품질 보증 관련 최상의 방법

  • 절차 관련 최상의 방법

성능 관련 최상의 방법

백업 및 복원 작업은 해당 작업이 실행되는 동안 서버 리소스를 사용하고 서버의 성능을 제한할 수 있습니다. 다음과 같은 최상의 방법을 따르면 리소스 사용을 줄이고 서버와 백업 또는 복원 작업의 성능을 높일 수 있습니다.

SQL Server와 백업 위치 간 대기 시간 최소화

일반적으로 백업 시에는 먼저 네트워크 드라이브가 아닌 데이터베이스 서버의 로컬 디스크를 사용한 다음 나중에 네트워크상의 공유 폴더로 데이터를 복사하는 것이 가장 좋습니다. 네트워크 드라이브와 데이터베이스 서버 간의 대기 시간이 1밀리초 이하인 네트워크 드라이브는 성능이 우수한 것입니다.

I/O 병목 현상을 방지하기 위해서는 개별 디스크에서 Microsoft SQL Server 2008 서비스 팩 1(SP1) 및 누적 업데이트 2가 실행되는 디스크로 주 백업을 수행합니다.

대부분의 백업 작업은 해당 작업을 완료하기 위해 사용할 수 있는 모든 I/O 리소스를 소비하도록 디자인되어 있습니다. 따라서 디스크 작업이 대기 중인 상황이 발생하여 대기 시간이 일반적인 I/O 요청 대기 시간보다 길어질 수 있습니다. 이와 같은 현상은 일반적인 것이며 문제로 간주되지 않습니다.

프로세스 충돌 방지

사용자가 시스템에 액세스해야 하는 시간대에는 백업 작업을 실행하지 않도록 합니다. 모든 데이터베이스의 백업이 동시에 진행되지 않도록 시차를 두고 백업을 수행하는 것이 좋습니다.

데이터베이스 크기를 작게 유지하여 복구 시간 개선

데이터베이스 크기를 작게 유지하여 백업 및 복구 시간을 모두 개선합니다. 이를 위해 웹 응용 프로그램에 대해 하나의 큰 콘텐츠 데이터베이스가 아닌 여러 개의 콘텐츠 데이터베이스를 사용합니다.

크기가 큰 데이터베이스에 대해 증분 백업 사용

DPM 2010에서 사용할 수 있는 데이터베이스처럼 크기가 큰 데이터베이스에는 증분 백업을 사용합니다. 데이터베이스의 크기가 큰 경우에는 증분 백업이 전체 백업보다 복원 속도가 빠르고 효율적일 수 있습니다. 백업 유형에 대한 자세한 내용은 백업 개요(SQL Server)(https://go.microsoft.com/fwlink/?linkid=203863&clcid=0x412)를 참조하십시오.

백업 시 압축 사용

경우에 따라 압축을 사용하여 백업 크기(30% 감소)와 시간(25% 감소)을 개선할 수 있습니다. 백업 압축은 SQL Server 2008 Enterprise에 처음 도입되었습니다. 백업 압축이 SQL Server의 성능에 미치는 영향에 대한 자세한 내용은 백업 압축(SQL Server)(https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x412)을 참조하십시오.

SQL Server 백업 및 복원 최적화 권장 사항 준수

SQL Server 백업을 사용하는 경우 전체, 차등 및 트랜잭션 로그(전체 또는 대량 로그 복구 모델의 경우) 백업을 조합하여 사용하면 복구에 걸리는 시간을 최소화할 수 있습니다. 차등 데이터베이스 백업을 사용하면 일반적으로 전체 데이터베이스 백업을 수행할 때보다 빠르게 작업을 완료할 수 있고 데이터베이스를 복구하는 데 필요한 트랜잭션 로그의 양도 줄일 수 있습니다.

전체 복구 모델을 사용하는 경우에는 유지 관리 문제가 발생하지 않도록 트랜잭션 로그 파일을 정기적으로 자르는 것이 좋습니다.

SQL Server 백업 및 복원 성능을 최적화하는 방법에 대한 자세한 권장 지침은 SQL Server의 백업 및 복원 성능 최적화(https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x412)를 참조하십시오.

RAID를 사용하려는 경우 RAID 10 사용

디스크 백업 장치에 RAID(Redundant Array of Independent Disks)를 사용할지 여부를 결정할 때는 신중을 기해야 합니다. 예를 들어 RAID 5는 패리티 정보를 유지 관리해야 하므로 쓰기 속도가 단일 디스크의 경우와 비슷한 정도로 느립니다. 그러나 백업 장치에 RAID 10을 사용하면 백업 속도를 향상시킬 수 있습니다. 백업에 RAID를 사용하는 방법에 대한 자세한 내용은 최대 SQL Server I/O 처리량을 위한 RAID 구성(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x412)(영문일 수 있음)을 참조하십시오.

백업 또는 복원 성능을 높이도록 SharePoint 성능 구성

백업 또는 복원 효율과 성능을 높이도록 중앙 관리 및 Windows PowerShell의 설정을 구성할 수 있습니다.

Export-SPWeb Windows PowerShell cmdlet을 사용하는 경우 NoFileCompression 매개 변수를 사용할 수 있습니다. 기본적으로 SharePoint Server 2010에서는 웹 응용 프로그램, 사이트 모음, 목록 또는 문서 라이브러리를 내보낼 때 파일 압축을 사용합니다. 이 매개 변수를 사용하면 내보내기 및 가져오기를 수행하면서 파일 압축을 해제할 수 있습니다. 파일 압축은 최대 30% 더 많은 리소스를 사용할 수 있지만 내보낸 파일에서는 25% 정도 적은 디스크 공간을 사용하게 됩니다. 내보내기를 수행할 때 NoFileCompression 매개 변수를 사용하는 경우 동일한 콘텐츠를 가져올 때도 이 매개 변수를 사용해야 합니다.

또한 NoLogFile 매개 변수도 사용할 수 있습니다. SharePoint Server 2010에서는 기본적으로 콘텐츠를 내보낼 때마다 로그 파일을 만듭니다. 이 매개 변수를 사용하면 로그 파일 만들기 기능을 해제하여 리소스를 절감할 수 있습니다. 하지만 로그는 문제 해결에 사용할 수 있기 때문에 로그 파일은 항상 만드는 것이 좋습니다. 그뿐만 아니라 로그를 만들 때는 많은 리소스가 사용되지 않습니다.

참고

이러한 설정은 중앙 관리를 통해서는 사용할 수 없습니다.

Backup-SPFarm cmdlet을 사용하는 경우 BackupThreads 매개 변수를 사용하여 SharePoint Server 2010에서 백업 도중 사용할 스레드의 수를 지정할 수 있습니다. 지정하는 스레드의 수가 많을수록 백업 작업에서 많은 리소스를 사용하게 되지만 사용 가능한 리소스가 충분한 경우에는 작업 완료 속도가 빨라집니다. 그러나 각각의 스레드는 로그 파일에 개별적으로 보고되므로 사용하는 스레드의 수가 적으면 로그 파일을 해석하기가 쉬워집니다. 기본적으로 세 개의 스레드가 사용되며 사용 가능한 최대 스레드의 수는 10개입니다.

참고

이 설정은 중앙 관리의 기본 백업 및 복원 설정 페이지에 있는 백업 및 복원 섹션에서도 사용할 수 있습니다.

사이트 모음 크기를 고려하여 사용할 도구 선택

업무상 팜 수준 백업이나 데이터베이스 수준 백업 이외에 사이트 모음 백업이 추가로 필요한 경우 사이트 모음의 크기를 기준으로 사용할 도구를 선택합니다.

  • 15GB 미만: Windows PowerShell 명령 Backup-SPSite를 사용합니다. 자세한 내용은 사이트 모음 백업(SharePoint Server 2010)을 참조하십시오.

  • 15~100GB: SharePoint 제품 및 기술 도구, SQL Server 도구 또는 다른 데이터베이스 백업 도구를 사용하여 사이트 모음이 포함된 콘텐츠 데이터베이스를 보호합니다. 자세한 내용은 사이트 모음 백업(SharePoint Server 2010)을 참조하십시오.

  • 100GB 초과: 기본 제공되는 백업 및 복구 도구 대신 Microsoft SQL Server 2005 또는 DPM 2010 등의 차등 백업 솔루션을 사용합니다.

품질 보증 관련 최상의 방법

다음 최상의 방법을 따르면 팜 환경의 백업 품질을 확보하고 데이터 손실 가능성을 줄이는 데 도움을 얻을 수 있습니다.

적당한 저장 공간이 있는지 확인

시스템에 백업을 보관할 디스크 공간이 충분한지 확인합니다.

정기적인 백업 품질 테스트

백업을 정기적으로 테스트하여 일관성을 확인합니다. 복구 작업 실습을 통해 백업 내용을 확인하고 전체 환경을 복원할 수 있는지 검토합니다. 지리적으로 분산된 환경의 경우에는 원격 팜을 설정하여 재해 복구를 준비합니다. 이렇게 하면 데이터베이스 연결 명령을 통해 데이터베이스 복사본을 원격 팜으로 업로드하고 사용자를 리디렉션하여 환경을 복원할 수 있습니다. 주기적으로 데이터 복구 작업을 시험 수행하여 파일이 제대로 백업되는지 확인합니다. 시험 복원을 수행하면 소프트웨어로는 확인할 수 없는 하드웨어 문제를 파악할 수 있습니다.

ULS 추적 로그 백업

SharePoint Server 2010 도구에서는 ULS 추적 로그를 백업하지 않습니다. 이 데이터는 성능 분석, 문제 해결, 서비스 수준 계약 준수 모니터링 등과 법률, 규정 또는 업무상 용도에 유용하게 활용할 수 있습니다. 따라서 일상적인 유지 관리 작업을 수행하면서 이 데이터를 보호해야 합니다. ULS 로그를 백업하는 방법에 대한 자세한 내용은 로그 백업 또는 보관(SharePoint Server 2010)를 참조하십시오.

백업 파일 복사본을 외부에 저장

화재나 지진 등의 재해가 발생하는 경우 데이터가 손실되지 않도록 하려면 백업의 중복 복사본을 서버가 아닌 별도의 위치에 유지합니다. 이렇게 하면 중요한 데이터가 손실되지 않도록 손쉽게 보호할 수 있습니다. 백업 미디어의 복사본 세 개를 보관하고 적절하게 제어할 수 있는 외부 환경에 최소한 하나 이상의 복사본을 보관하는 것이 가장 좋습니다. 여기에는 모든 백업 및 복구 자료, 문서, 데이터베이스 및 트랜잭션 로그 백업, 사용 현황 및 추적 로그 백업이 포함되어야 합니다.

절차 관련 최상의 방법

다음 절차 관련 최상의 방법을 사용하여 개선된 설명서, 향상된 편의성 및 높은 품질 보증 수준을 바탕으로 백업 및 복원 작업을 손쉽게 계획하고 수행할 수 있습니다.

FQDN 서버 이름 사용

다른 도메인에 있는 서버를 참조하는 경우에는 항상 정규화된 도메인 이름(FQDN)을 사용합니다.

정확한 레코드 유지

SharePoint Server 2010을 배포할 때는 만드는 계정 및 선택하는 컴퓨터 이름, 암호, 설치 옵션을 기록하여 안전한 위치에 이 정보를 보관합니다.

복구 환경 준비 상태 유지

원격 팜을 설정하여 복원 테스트 및 재해 복구에 대비합니다. 이렇게 하면 데이터베이스 연결 명령을 통해 데이터베이스 복사본을 원격 팜으로 업로드하고 사용자를 리디렉션하여 환경을 복원할 수 있습니다. 마찬가지로 데이터베이스 복원 및 문서 복구를 신속하게 수행할 수 있도록 프로덕션 환경과 동일한 버전의 소프트웨어가 실행되는 대기 환경을 설정할 수도 있습니다.

백업 작업 예약

백업을 예약하려면 Windows 작업 스케줄러를 사용하여 Windows PowerShell 스크립트 파일을 통해 백업을 실행하면 됩니다

SQL FILESTREAM 공급자와 BLOB 저장소 함께 사용

SQL FILESTREAM 공급자가 사용되는 BLOB 저장소를 활용하는 상황에서 해당 RBS(원격 BLOB 저장소)가 정의된 콘텐츠 데이터베이스를 백업하는 경우 SharePoint 도구나 SQL Server 도구를 사용하면 RBS와 콘텐츠 데이터베이스가 모두 백업 및 복원됩니다. 다른 복원 방법에는 RBS를 사용하지 않는 것이 좋습니다.