Backup Exec 성능 향상 및 문제 해결

문제

Backup Exec 성능 향상 및 문제 해결

솔루션

성능 향상:
백업 작업은 시스템 그룹에서 실행됩니다.  이러한 시스템은 데이터가 포함된 디스크에서 백업 저장소에 이르기까지 다양한 크기의 파이프라인에 비유할 수 있습니다.  이러한 파이프에서 어느 한 부분이라도 정체될 경우 이는 일반 백업 프로세스의 속도를 느리게 하는 병목 지점이 됩니다.  이 문서의 목적은 시스템에서 백업 또는 복원 성능 문제를 일으키는 병목 지점을 찾는 것입니다.


백업 및 복원의 처리량 성능에 영향을 미치는 변수는 많습니다.  이러한 변수는 다음과 같습니다.

하드웨어
디스크 컨트롤러의 속도와 디스크 드라이브, 테이프 드라이브, 디스크 컨트롤러, SCSI 버스에서 발생하는 하드웨어 오류 또는 잘못된 배선/종단에 의해 성능이 저하될 수 있습니다. 컨트롤러가 테이프 백업 하드웨어에 사용 가능한 컨트롤러인지 확인하십시오.  


SCSI BIOS 설정이 다음과 같이 올바르게 설정되었는지 확인하십시오.

• 테이프 장치가 68핀 너비의 SCSI 케이블 커넥터에 연결된 경우 초기 Wide Negotiation이 Yes로 설정되어 있습니다.
• 테이프 드라이브가 SCSI RAID 컨트롤러에 연결되지 않았습니다.
  
   

시스템

• 백업을 수행하는 미디어 서버, 또는 백업되는 원격 시스템의 용량과 속도는 성능에 큰 영향을 미칩니다.
• 백업 중의 시스템 활동도 성능에 영향을 미칩니다.
• 단편화된 디스크는 백업하는 데 더 많은 시간이 소요됩니다. 심각하게 단편화된 하드 디스크는 데이터를 테이프에 쓰는 속도뿐만 아니라 전체적인 시스템 성능에도 영향을 미칩니다. 파일이 단편화된 경우 각 데이터 세그먼트가 디스크의 서로 다른 위치에 존재하므로 디스크에서 데이터에 액세스하는 데 더 오래 걸리고 따라서 백업 시간도 더 길어집니다. 정기적으로 디스크 조각 모음을 수행해야 합니다.

메모리
사용 가능한 메모리의 크기는 백업 속도에 영향을 미칩니다. 메모리 부족, 잘못된 페이지 파일 설정, 하드 디스크 여유 공간 부족은 과도한 페이징을 유발하여 성능을 저하시킬 수 있습니다.


파일 형식
하드웨어 압축을 사용하는 경우 일반적인 파일은 2:1의 비율로 압축됩니다. 백업되는 파일의 형식에 따라 압축률이 더 높아지거나 낮아집니다. 비압축의 경우 테이프 장치는 정격 속도로 실행되며 평균 압축의 경우 백업 속도가 두 배로 빨라집니다. 이미지 및 그림 파일은 디스크에 완전히 압축되어 있습니다. 따라서 백업 중에 하드웨어 압축이 실행되지 않으므로 테이프 드라이브는 고유(비압축) 정격 속도로 동작합니다. 하드웨어 압축은 백업 소프트웨어가 아닌 테이프 장치에 의해 수행됩니다.


압축
성공적인 압축은 테이프 드라이브의 데이터 전송 속도를 고유 속도의 두 배까지 높여 줍니다. 압축률은 입력 데이터에 따라 큰 폭으로 달라집니다.  Microsoft Paint와 같은 그래픽 프로그램의 이미지 파일의 압축률은 4.5:1 이상이지만 이진 파일의 압축률은 1.5:1 정도에 불과합니다. 이미 압축된 데이터 또는 랜덤 데이터(예: 암호화된 데이터 또는 MPEG 파일)는 더 압축하려고 시도할 경우 5% 정도 크기가 커질 수 있습니다. 이로 인해 드라이브의 처리량이 낮아질 수 있습니다.


파일
디스크에 있는 파일의 총 수와 각 파일의 상대적 크기는 백업 성능에 영향을 미칩니다. 백업 속도는 디스크에 적은 수의 큰 파일이 있는 경우 가장 빠르고 많은 수의 작은 파일이 있는 경우 가장 느립니다. 동일한 디렉터리 경로에 포함된 많은 파일을 백업하는 것이 여러 디렉터리 위치에 흩어진 파일을 백업하는 것보다 더 효과적입니다.


블록 크기
블록 크기가 크면 압축률이 향상되므로 드라이브의 처리량이 높아지고 테이프 용량을 확보하는 데 도움이 됩니다. 블록 크기와 버퍼 크기가 적절히 설정되었는지 확인하십시오. 처리량은 드라이브의 최대 처리량에 이를 때까지 압축률에 비례하여 높아집니다. 블록 크기를 기본 설정보다 크게 늘리지 않는 것이 좋습니다.


네트워크
원격 디스크의 백업 속도는 물리적 연결의 속도에 의해 제한됩니다. 원격 서버의 하드 디스크가 백업되는 속도는 다음과 같은 요인에 따라 달라집니다.

• 네트워크 카드 제조업체/모델
• 어댑터의 모드/프레임 유형 구성
• 연결 장비(허브, 스위치, 라우터 등)
• Windows 설정
• 미디어 서버의 로컬 디스크 드라이브는 네트워크를 통한 원격 서버 백업보다 일반적으로 더 빠르게 백업할 수 있습니다.

느린 네트워크 백업의 일반적인 원인은 네트워킹 구성입니다.
"전이중" 및 "자동 검색"과 같은 기능은 환경에 따라 지원되지 않을 수도 있습니다. 서버 측에 대해 수동으로 속도를 100MB로 설정하고 이중을 반이중/전이중으로 설정합니다. 스위치에서 서버가 연결된 이더넷 포트를 찾고 SWITCH PORT(스위치 포트) 설정을 100MB 및 반이중/전이중으로 설정합니다. 백업 서버 스위치 포트, 그리고 백업되는 시스템에 대한 모든 스위치 포트에 대해 이를 수행합니다.

참고: 스위치 대신 허브가 배치된 경우 전이중은 지원되지 않을 수 있습니다. 장치 기능에 대한 자세한 내용은 OEM에 문의하십시오.

참고: 스위치와 네트워크 카드의 설정은 일치해야 합니다. 예를 들어 스위치 포트가 100 half(100 반이중)로 설정되어 있다면 서버의 NIC도 100 half(100 반이중)로 설정되어야 합니다.
전이중 백업이 반이중 백업보다 느리다면 NIC, 드라이버 및 스위치 조합에서 전이중이 지원되지 않는 것입니다. 업데이트된 드라이버, 펌웨어 또는 기타 지원 문서는 NIC 및 스위치 제조업체에 문의하십시오.
또 다른 일반적인 원인은 NIC 드라이버입니다. 운영 체제 서비스 팩이 NIC 드라이버를 덮어쓰는 경우가 많습니다. 서비스 팩이 적용되면서 드라이버를 덮어쓴 경우 OEM(Original Equipment Manufacturer) 드라이버를 다시 설치하십시오.


디버깅
문제 해결을 위해 실행한 디버깅이 시스템 성능에 영향을 미치는 경우도 있습니다.
서비스 애플릿을 통해 수행되는 디버깅은 임시 작업이므로 해당 서비스를 순환시키거나 시스템을 재부팅하면 중지됩니다. 디버깅이 Windows 레지스트리를 통해 구성된 경우 지속적인 디버깅이 가능합니다. 서비스를 디버깅 모드로 두면 로그가 커질 수 있습니다. 따라서 문제를 해결한 후에는 서비스의 디버깅 모드를 해제하거나 오래된 디버그 파일을 삭제하거나 로그 디렉터리를 압축하도록 구성하는 것이 좋습니다. 시스템에서 수행할 디버깅 방법을 결정할 때 이러한 부분을 감안해야 합니다.
디버깅 실행을 중지하는 방법에 대한 자세한 내용은 관련 문서 섹션을 참조하십시오.


Backup Exec 데이터베이스
BEDB(Backup Exec 데이터베이스)를 다른 응용 프로그램에 사용되는 기존 SQL 인스턴스에 설치하는 경우에도 성능 문제가 발생할 수 있습니다. 이러한 문제는 특히 CASO(Central Administration Server Option) 환경에서 두드러지게 나타납니다. 다른 응용 프로그램이 리소스 문제를 일으키고 인스턴스 내의 모든 가용 리소스를 사용할 수 있습니다.


성능 문제 해결:
다음 목록은 Backup Exec 성능을 개선하기 위해 수행할 수 있는 가능한 문제 해결 단계입니다.  관심 있는 시나리오를 살펴보십시오.  시나리오는 다음과 같습니다.

• 디스크로 로컬 백업
• 테이프로 로컬 백업
• 디스크로 원격 백업
• 테이프로 원격 백업
  
   

디스크로 로컬 백업:

• 기준선을 확인합니다. 이전 작업 로그를 검토하고, 이전 작업의 속도 및 백업 중에 소요된 전체 시간을 기록해 둡니다.
  1. Backup Exec에서 Job Monitor(작업 모니터)로 이동합니다.
  2. 아래쪽의 "Job History(작업 기록)" 창에서 Job log(작업 로그)를 선택합니다.
  3. 실제 바이트 수 전송률이 아닌 작업이 완료되는 데 소요된 총 시간을 관찰합니다.
  4. 이 시간을 이전 로그와 비교합니다.
  5. 작업을 완료하는 데 소요된 시간이 이전보다 늘어났거나 예상 속도에 미치지 못한다면 문제 해결 단계를 계속 진행합니다.
     
      

1. 문제의 범위를 좁힙니다.  
   • 하나의 작업에서 여러 드라이브 또는 에이전트가 백업되는 경우 작업을 각 드라이브 또는 에이전트당 하나의 작업과 같이 여러 개의 작은 작업으로 분할합니다.
     예를 들어 백업 작업에서 C, D, E와 Exchange 에이전트를 백업하는 경우 C에 하나, D에 하나, E에 하나, 그리고 Exchange에 하나, 총 4개의 작업을 생성합니다.
     1. 이렇게 하려면 Backup(백업)을 누릅니다.
     2. C$ drive(C$ 드라이브)를 선택합니다.
     3. 작업을 예약합니다.
     4. Submit(제출)을 누릅니다.
     5. 각 드라이브와 에이전트에 대해 이 절차를 따릅니다.  
     6. 특정 작업에 대해서만 속도가 느린 경우 해당 작업에 대해 문제 해결 단계를 계속 진행합니다.  
        
         
2. 문제의 범위를 좁힙니다.  위 작업 중 어느 한 작업이 느린 경우 이 작업을 더 세부적으로 분할하여 특정 데이터 부분이 성능 문제를 일으키는지 여부를 확인할 수 있습니다.  특정 데이터 세트가 문제로 확인되는 경우가 있습니다.  
   
   권장 방법:
   1. 데이터가 다른 곳으로 재연결되지 않는지 확인합니다.  일부 파일 시스템은 디렉터리에서 원격으로 데이터를 마운트하도록 허용합니다.  이 디렉터리의 파일은 원격 서버에 위치할 수 있으며, 이 경우 백업 속도가 느려질 수 있습니다.
   2. 백업의 이 부분에 작은 파일과 디렉터리가 많이 있는지 확인합니다.  많은 수의 작은 파일과 디렉터리는 백업 속도를 저하시킵니다. 이는 예상 가능한 현상입니다.
      
       
3. B2D 디스크 처리량을 테스트합니다.  
   1. "Windows Copy(Windows 복사)"를 사용합니다.
      백업 작업에서 최소 2GB의 데이터를 한 드라이브에서 B2D 디스크의 다른 드라이브로 끌어다 놓습니다.  
   2. 이 성능을 백업과 비교합니다. 성능이 일치하면 병목 지점은 B2D 폴더가 위치한 디스크 하위 시스템일 가능성이 높습니다.  
   3. 보다 빠른 디스크 하위 시스템으로 B2D 폴더를 옮기거나 디스크 하위 시스템 문제 해결을 계속 진행합니다.
      
       
4. 시스템 처리량을 테스트합니다.  
   • NTBackup(Windows 백업)에서 비슷한 백업을 생성하고 디스크로 백업을 실행합니다. Exchange, SQL 또는 기타 데이터베이스 백업이 아닌 파일 기반 작업만 수행된다고 가정합니다.
     1. NTBackup을 시작하려면 시작 > 실행으로 이동합니다.
     2. ntbackup 을 입력합니다.
     3. 작업을 비교합니다.
     4. Exchange, SQL, 또는 기타 데이터베이스 에이전트가 Backup Exec에서 백업되는 경우 Backup Exec 내에서 최대 2GB의 데이터를 에이전트가 상주하는 위치에 백업하는 B2D 작업을 생성한 후 "NTBackup"을 사용하여 동일한 테스트를 수행합니다.
     5. 로컬인 경우 "ntbackup"을 사용하여 Exchange를 백업한 후 성능을 비교하는 것도 가능합니다.
     6. 성능이 비슷하다면 Backup Exec가 시스템 능력 수준에서 수행되는 것입니다.
     
      

테이프로 로컬 백업:

1. 기준선을 확인합니다.
2. 이전 작업 로그를 검토하고, 이전 작업의 속도 및 백업 중에 소요된 전체 시간을 기록해 둡니다.
   1. Backup Exec에서 Job Monitor(작업 모니터)로 이동합니다.
   2. 아래쪽의 "Job History(작업 기록)" 창에서 Job log(작업 로그)를 선택합니다.
   3. 실제 바이트 수 전송률이 아닌 작업이 완료되는 데 소요된 총 시간을 관찰합니다.
   4. 이 시간을 이전 로그와 비교합니다. 작업을 마치는 데 소요되는 시간이 이전보다 훨씬 더 늘어났거나 예상 속도에 미치지 못한다면 문제 해결 단계를 계속 진행합니다.
      
       
3. 일시적인 하드웨어 문제를 해결합니다.
4. 서버 및 테이프 드라이브/라이브러리의 전원을 껐다가 켭니다.
   1. 백업 서버를 먼저 끈 후 경우에 따라 테이프 드라이브 또는 라이브러리를 끕니다.
   2. 몇 초 정도 기다린 후 테이프 드라이브/라이브러리의 전원을 켜고 "준비" 상태가 되거나 모든 움직임이 멈출 때까지 기다립니다.
   3. 그런 다음 서버의 전원을 켭니다.
   4. 백업 작업을 다시 실행하고 속도를 확인합니다.
      
       
5. SCSI 하위 시스템을 확인합니다.  
   • 디스크 컨트롤러의 속도와 디스크 드라이브, 테이프 드라이브, 디스크 컨트롤러, SCSI 버스에서 발생하는 하드웨어 오류 또는 잘못된 배선/종단에 의해 성능이 저하될 수 있습니다. 컨트롤러가 테이프 백업 하드웨어에 사용 가능한 컨트롤러인지, SCSI BIOS가 올바르게 설정되어 있는지 확인합니다.  추가로 다음을 확인합니다.
     • 테이프 장치가 68핀 너비의 SCSI 케이블 커넥터에 연결된 경우 초기 Wide Negotiation이 Yes로 설정되어 있습니다.
     • 테이프 드라이브가 SCSI RAID 컨트롤러에 연결되지 않았습니다.
       
        
   • "확인 작업"의 성능을 통해 SCSI 하위 시스템의 상태를 알 수 있습니다. "확인 작업"은 미디어 서버에서 데이터를 읽고 메모리 내 작업만 수행하므로 일반적으로 그 성능은 SCSI 하위 시스템의 속도에 의해 제한됩니다. "확인 성능"은 "확인 작업"을 포함하는 작업의 로그를 보면 알 수 있습니다.  "확인 속도"가 낮다면 SCSI 하위 시스템이 성능 병목 지점일 가능성이 높습니다.
     
      
6. 문제의 범위를 좁힙니다.
   • 하나의 작업에서 여러 드라이브 또는 에이전트가 백업되는 경우 작업을 각 드라이브 또는 에이전트당 하나씩 별도의 작업으로 분할합니다.
     예를 들어 백업 작업에서 C, D, E와 Exchange 에이전트를 백업하는 경우 C에 하나, D에 하나, E에 하나, 그리고 Exchange에 하나, 총 4개의 작업을 생성합니다. 특정 작업에 대해서만 속도가 느린 경우 해당 작업에 대해 문제 해결 단계를 계속 진행합니다.
     
      
7. 문제의 범위를 좁힙니다.
   • 위 작업 중 어느 한 작업이 느린 경우 이 작업을 더 세부적으로 분할하여 특정 데이터 부분이 성능 문제를 일으키는지 여부를 확인할 수 있습니다.  특정 데이터 세트가 문제로 확인되는 경우가 있습니다.  
     
     권장 방법:
     데이터가 다른 곳으로 재연결되지 않는지 확인합니다.  일부 파일 시스템은 디렉터리에서 원격으로 데이터를 마운트하도록 허용합니다.  이 디렉터리의 파일은 원격 서버에 위치할 수 있으며, 이 경우 일반 백업 속도가 느려질 수 있습니다. 백업의 이 부분에 작은 파일과 디렉터리가 많이 있는지 확인합니다.  많은 수의 작은 파일과 디렉터리는 백업 속도를 저하시키며 이는 예상 가능한 현상입니다.
     
      
8. 시스템 처리량을 테스트합니다.
   • NTBackup(Windows 백업)을 열고 드라이브/에이전트의 백업 작업을 실행합니다.
     1. NTBackup을 시작하려면 시작 > 실행으로 이동합니다.
     2. ntbackup 을 입력합니다.
     3. 백업에 테이프 드라이브를 사용합니다.
        1. Backup(백업)을 누릅니다.
        2. "Backup Destination(백업 저장소)" 필드로 이동합니다.
        3. 백업에 사용할 테이프 드라이브를 선택합니다.
           • 드라이브가 보이지 않으면 이 드라이브에 대한 시만텍 드라이버를 제거하고 OEM 드라이버를 설치합니다. 이 작업에는 두 번의 재부팅이 필요합니다.
           • 되도록 전체 드라이브나 에이전트를 백업하고, 아닌 경우 최소한 2GB의 데이터를 백업합니다.
             참고: 불량 섹터가 있는 드라이브 또는 수백만 개의 작은 파일이 있는 드라이브와 같이 드라이브의 일부 영역이 실제 문제인 경우도 있습니다. 로그를 검토하고 Backup Exec 로그와 속도를 비교해 봅니다.  속도가 비슷하다면 백업이 시스템의 능력 수준에서 실행되고 있는 것입니다.
             
              
9. 성공적인 압축은 테이프 드라이브의 데이터 전송 속도를 고유 속도의 두 배까지 높여 줍니다. 압축률은 입력 데이터에 따라 큰 폭으로 달라집니다. Microsoft Paint와 같은 그래픽 프로그램의 이미지 파일의 압축률은 4.5:1 이상이고, 이진 파일의 압축률은 1.5:1입니다. 이미 압축된 데이터 또는 랜덤 데이터(예: 암호화된 데이터 또는 MPEG 파일)는 더 압축하려고 시도할 경우 5% 정도 크기가 커질 수 있습니다. 이로 인해 드라이브의 처리량이 낮아질 수 있습니다. 하드웨어 압축 성능이 예상보다 떨어지는 경우 소프트웨어 압축으로 전환하고 반대의 경우 하드웨어 압축으로 전환합니다.
   1. 이렇게 하려면 "Backup job properties(백업 작업 등록 정보)"를 편집하면 됩니다.
   2. Settings(설정) > General(일반)을 누릅니다.
   3. "Compression Type(압축 유형)" 드롭다운 메뉴에서 다른 압축 유형을 선택합니다.
      
       

디스크로 원격 백업:

• 기준선을 확인합니다.

1. 이전 작업 로그를 검토하고, 이전 작업의 속도 및 백업 중에 소요된 전체 시간을 기록해 둡니다.
   1. Job Monitor(작업 모니터)로 이동합니다.
   2. Job History(작업 기록) > Job Log(작업 로그)를 선택합니다.
   3. 실제 바이트 수 전송률이 아닌 작업이 완료되는 데 소요된 총 시간을 관찰합니다.
   4. 이 시간을 이전 로그와 비교합니다.
   5. 작업을 마치는 데 소요되는 시간이 이전보다 훨씬 더 늘어났거나 예상 속도에 미치지 못한다면 문제 해결 단계를 계속 진행합니다.
      
       
2. 문제의 범위를 좁힙니다. 하나의 작업에서 여러 드라이브 또는 에이전트가 백업되는 경우 작업을 각 드라이브 또는 에이전트당 하나씩 별도의 작업으로 분할합니다.
   예를 들어 백업 작업에서 C, D, E와 Exchange 에이전트를 백업하는 경우 C에 하나, D에 하나, E에 하나, 그리고 Exchange에 하나, 총 4개의 작업을 생성합니다.
   1. 이렇게 하려면 Backup(백업)을 누릅니다.
   2. C$ drive(C$ 드라이브)를 선택합니다.
   3. 작업을 예약합니다.
   4. Submit(제출)을 누릅니다.
   5. 각 드라이브와 에이전트에 대해 이 절차를 따릅니다. 특정 작업에 대해서만 속도가 느린 경우 해당 작업에 대해 문제 해결 단계를 계속 진행합니다.
      
       
3. 문제의 범위를 좁힙니다.  
   위 작업 중 어느 한 작업이 느린 경우 이 작업을 더 세부적으로 분할하여 특정 데이터 부분이 성능 문제를 일으키는지 여부를 확인할 수 있습니다.  특정 데이터 세트가 문제로 확인되는 경우 다음 문제 해결 단계를 따릅니다.
   • 데이터가 다른 곳으로 재연결되지 않는지 확인합니다.  일부 파일 시스템은 디렉터리에서 원격으로 데이터를 마운트하도록 허용합니다.  이 디렉터리의 파일은 원격 서버에 위치할 수 있으며, 이 경우 일반 백업 속도가 느려질 수 있습니다. 백업의 이 부분에 작은 파일과 디렉터리가 많이 있는지 확인합니다.  많은 수의 작은 파일과 디렉터리는 백업 속도를 저하시키며 이는 예상 가능한 현상입니다.
     
      
4. 네트워크 처리량을 테스트합니다.
   • 백업 서버에서 500MB - 1GB의 데이터를 원격 서버로 복사하고 이 복사 작업에 소요된 시간을 기록해 둡니다.
     1. 이렇게 하려면 시작 >실행으로 이동하여 다른 서버로의 경로를 생성하면 됩니다.
     2. <\\원격 서버 이름\c$> 를 입력합니다.
     3. 드라이브가 표시되면 데이터를 복사합니다.
        동일한 단계에 따라 원격 서버에서 백업 서버로 데이터를 복사하고 소요된 시간을 기록해 둡니다. "data backed up(백업된 데이터)"을 "time(시간)"별로 나누어 MB/분 단위의 속도를 구한 다음 이를 Backup Exec의 성능과 비교합니다.  Backup Exec의 성능이 파일 복사 테스트와 비슷하다면 백업이 네트워크 능력 수준에서 실행되고 있는 것입니다.  이 속도가 느리다면 네트워크 구성 요소의 문제를 해결하는 데 집중하십시오.  Backup Exec의 성능이 파일 복사 테스트보다 느리다면 네트워크는 병목 지점이 아닐 가능성이 높습니다.
        
        네트워크가 병목 지점으로 의심되는 경우 다른 원격 서버로, 또는 완전한 별개의 두 서버 사이에서 동일한 테스트를 수행하여 성능 문제가 전반적인 네트워크와 관련된 것인지, 또는 네트워크의 특정 서버와 관련된 것인지 확인합니다.
        
         
5. 시스템 처리량을 테스트합니다.
   • 3번 항목의 단계를 수행했지만 네트워크 문제가 발견되지 않은 경우에만 다음을 수행합니다.
     • NTBackup(Windows 백업)을 사용하여 원격 서버를 백업합니다.
       1. 시작 > 실행으로 이동합니다.
       2. ntbackup 을 입력합니다.
       3. NTBackup에서 원격 서버가 보이지 않으면 서버의 드라이브에 매핑된 드라이브를 생성하고(느린 속도의 원인이 Exchange 또는 SQL과 같은 에이전트 백업이 아니라는 가정하에) 다시 시도합니다.
       4. 단계를 수행하고 최소 2GB의 데이터를 백업합니다.
       5. 로그를 검토하고 Backup Exec 로그와 비교해 봅니다. 이렇게 하면 문제의 범위를 좁히고 서버 또는 Backup Exec에 문제가 있는지 여부를 알 수 있습니다.
       6. 원격 백업이 NTBackup에서 동작하지 않는 경우 원격 서버에서 NTBackup을 로컬로 열어 실행합니다(해당 서버의 한 드라이브에서 다른 드라이브로 백업).

테이프로 원격 백업
"테이프로 로컬 백업" 섹션에 언급된 모든 항목을 여기에 적용할 수 있습니다. 추가로 다음 항목을 참조합니다.

1. 네트워크 처리량을 테스트합니다.
   • 백업 서버에서 500MB - 1GB의 데이터를 원격 서버로 복사하고 이 복사 작업에 소요된 시간을 기록해 둡니다.
     1. 이렇게 하려면 시작 > 실행으로 이동하여 다른 서버로의 경로를 생성하면 됩니다.
     2. <\\원격 서버 이름\c$> 를 입력합니다.
     3. 드라이브가 표시되면 데이터를 복사합니다.
     4. 동일한 단계에 따라 원격 서버에서 백업 서버로 데이터를 복사하고 소요된 시간을 기록해 둡니다.
     5. 시간을 기록해 두고 "data backed up(백업된 데이터)"을 "time(시간)"별로 나누어 MB/분 단위의 속도를 구한 다음 이를 Backup Exec의 성능과 비교합니다.  
         Backup Exec의 성능이 파일 복사 테스트와 비슷하다면 백업이 네트워크 능력 수준에서 실행되고 있는 것입니다.  이 속도가 느리다면 네트워크 구성 요소의 문제를 해결하는 데 집중하십시오.  Backup Exec의 성능이 파일 복사 테스트보다 느리다면 네트워크는 병목 지점이 아닐 가능성이 높습니다.
        
        네트워크가 병목 지점으로 의심되는 경우 다른 원격 서버로, 또는 완전한 별개의 두 서버 사이에서 동일한 테스트를 수행하여 성능 문제가 전반적인 네트워크와 관련된 것인지, 또는 네트워크의 특정 서버와 관련된 것인지 확인합니다.
        
         
2. 시스템 처리량을 테스트합니다.
   • 이 섹션의 1번 항목에 설명된 단계를 수행했지만 네트워크 문제가 발견되지 않은 경우에만 다음을 수행합니다.
     • NTBackup을 사용하여 원격 서버를 백업합니다.
     1. 시작 > 실행으로 이동합니다.
     2. ntbackup 을 입력합니다.
     3. NTBackup에서 원격 서버가 보이지 않으면 서버의 드라이브에 매핑된 드라이브를 생성하고(느린 속도의 원인이 Exchange 또는 SQL과 같은 에이전트 백업이 아니라는 가정하에) 다시 시도합니다.
     4. 비슷한 단계를 수행하고 최소 2GB의 데이터를 백업합니다.
     5. 로그를 검토하고 Backup Exec 로그와 비교해 봅니다. 이렇게 하면 문제의 범위를 좁히고 서버 또는 Backup Exec에 문제가 있는지 여부를 알 수 있습니다.

참고: NTBackup에서 원격 백업이 불가능한 경우 원격 서버에서 NTBackup을 로컬로 열어 실행합니다(해당 서버의 한 드라이브에서 다른 드라이브로 백업). 이는 적절한 비교가 가능하도록 사용자가 Backup Exec를 통해 동일한 데이터를 디스크로 백업하는 작업을 실행해야 함을 의미합니다. 대부분의 경우 디스크 백업 작업은 테이프 백업 작업보다 빠릅니다.

References
"How to resolve hardware communication/detection issues with Backup Exec(Backup Exec에서 하드웨어 통신/검색 문제를 해결하는 방법)"

https://support.veritas.com/docs/237047

"How to correct slow backup performance, slow virus or pre-job scans, and agent initialization problems on fragmented Windows 2000 and Windows 2003 Server Hard Disk Partitions(단편화된 Windows 2000 및 Windows 2003 Server 하드 디스크 파티션에서 백업 성능 저하, 바이러스 또는 사전 작업 검사 속도 저하 및 에이전트 초기화 문제를 해결하는 방법)"
https://support.veritas.com/docs/237444

"How to enable or disable 'debug logging' in Backup Exec for Windows Servers(Backup Exec for Windows Servers에서 '디버그 로깅'을 실행 또는 실행 중지하는 방법)"
https://support.veritas.com/docs/254212

"How to Enable Debug Logs using BEUtility feature of Backup Exec 10.x and 11.d for Windows Servers(Backup Exec 10.x 및 11d for Windows Servers의 BEUtility 기능을 사용하여 디버그 로그를 실행하는 방법)" at: https://support.veritas.com/docs/275639