데이터베이스 개발자 Tip & 강좌

SQLER의 개발자들이 만들어가는 데이터베이스 사용자 Tip & 강좌 게시판입니다. SQL서버, Oracle, MySQL 등 여러 클라우드/오픈소스 기반 데이터베이스 개발 및 운영 관련 팁과 쿼리 노하우를 이곳에서 가장 먼저 접하실 수 있습니다. 많은 도움 되시길 바랍니다.

SQL Server 네트워크 백업 트러블슈팅(UNC 설정)

 

  • Version : SQL Server 2005, 2008, 2008R2, 2012

 

SQL Server에서 데이터베이스를 백업 할 때 로컬에 있는 하드디스크 뿐만 아니라 네트워크에 있는 다른 서버의 드라이브에도 백업 할 수도 있다.

그런데 네트워크에 있는 서버의 디스크를 네트워크 드라이브로 잡아서 해당 드라이브에 백업하려고 하면 백업 실패가 발생 한다. 이럴 때 UNC 방식을 사용하면 백업 작업을 수행 할 수 있다.

 

[UNC란?]

네트워크에서 UNC는 컴퓨터 내의 공유 폴더 또는 파일이 저장되어 있는 장치를 명시하지 않고도 그 파일을 확인하기 위한 방법이다. 윈도우 운영체제에서 UNC 형식은 다음과 같아.

\\Servername\Sharename\path\filename

 

 

[네트워크 드라이 백업]

실습을 통해 네트워크 백업하는 방법을 알아 보자. 우선 공유 드라이브를 가진 서버의 IP를 확인 한다. 실습에서는 2개의 가상화 서버로 진행 하였다. 192.168.237.166의 SQL_Backup 폴더가 공유 드라이브 이다.

 

 

데이터베이스가 있는 컴퓨터(원본 서버)에서 다음 스크립트를 진행하여 백업을 진행 하였다.

백업 오류가 발생하였다. 에러 원인은 운영체제에서 액세스 거부가 되었다고 한다.

BACKUP DATABASE SW_TEST TO DISK = '\\192.168.237.166\SQL_Backup\SW_Test.bak'

 

 

 

가장 먼저 커맨드 명령을 통하여 net use 명령으로 해당 경로를 등록 하였다.

 

그리고 백업을 진행 하자. 만약 실패한다면 다음 사항을 확인 해야 한다.

SQL Server 시작계정 권한이 해당 네트워크 드라이브 경로에 접근 권한이 있어야 한다. (해당 네트워크 서버에 계정/비번이 동일해야 한다.)

SQL Server의 시작계정과 공유 폴더의 접근 권한을 확인하여 보안 정책을 설정 하도록 하자.

 

그리고 네트워크 백업을 진행 하자. 만약 실패 한다면 다음 사항을 확인 해야 한다.

SQL Server가 외부에서 등록한 UNC의 경로를 인식하지 못하여 생기는 문제가 발생 할 수 있기 때문에 다음과 같이 xp_cmdshell을 사용해서 net use를 실행 한다.

    exec xp_cmdshell 'net use \\192.168.237.166\SQL_Backup password /USER:Administrator'

 

 

UNC 설정이 완료되면 네트워크 백업을 진행 하여보자.

BACKUP DATABASE SW_TEST TO DISK = '\\192.168.237.166\SQL_Backup\SW_Test.bak'

 

 

성공적인 백업이 되었음을 알 수 있다.

 

[네트워크 드라이브에서 복원]

기존의 백업 방법과 동일하다. 단지 백업 대신 복원 명령을 사용한다.

RESTORE DATABASE SW_TEST FROM DISK = '\\192.168.237.166\SQL_Backup\SW_Test.bak' WITH REPLACE, RECOVERY

 

 

 

[네트워크 백업을 사용 하는 경우]

  • 로컬 디스크에 공간이 부족하여 큰 드라이브가 필요 할 때
  • 2차 백업용으로 복사 파일을 보관 할 때
  • 공유 드라이브로 전체 백업을 관리 할 때

 

[네트워크 드라이브의 단점]

  • 랜카드 대역폭에 따라 백업 속도에 영향
  • 네크워크를 통한 백업이므로 중간에 손실(실패)이 발생
  • 백업이 오래 걸리는 동안 DB에 오버헤드가 발생

 

내가 생각하기엔 로컬 디스크가 허락한다면 로컬에 최대한 빠르게 저장한 다음(성능에 문제 없는 한도 내에서) 복사 전용 프로그램을 이용하여 로컬의 완전한 백업 파일을 공용 드라이브로 이동하는 것이 안전하고 빠를 것이라 생각한다. 이 때에는 네트워크의 부하나 기타 시스템의 영향도를 관리자가 제어할 수 있기 때문이다.

백업에 대한 시나리오는 자신이 운영하는 환경에 따라 잘 판단해서 효율적인 솔루션을 찾도록 하자.

 

[참고자료]

http://www.sqlserver-dba.com/2013/03/sql-backup-and-restore-to-unc.html

http://msdn.microsoft.com/ko-kr/library/ms179313.aspx

 

 


강성욱 / jevida@naver.com
Microsoft SQL Server MVP
Blog : http://sqlmvp.kr
Facebook : http://facebook.com/sqlmvp

No. Subject Author Date Views
1770 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (3/4) – 뷰(View)의 인덱스 확인 jevida(강성욱) 2016.09.27 972
1769 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (2/4) – 뷰(View) 확인 jevida(강성욱) 2016.09.27 1447
1768 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (1/4) – SQL 문 최적화 및 Worktables jevida(강성욱) 2016.09.27 932
1767 SQL Server DMV를 이용한 통계 정보 확인 jevida(강성욱) 2016.09.27 1456
1766 DMV를 이용한 플랜 캐시 사용 정보 확인 jevida(강성욱) 2016.09.27 1172
1765 SQL Server 테이블 및 인덱스 구조 아키텍처(4/4) – 비클러스터형 인덱스 구조 jevida(강성욱) 2016.09.27 1064
1764 SQL Server 테이블 및 인덱스 구조 아키텍처(3/4) – 클러스터형 인덱스 구조 jevida(강성욱) 2016.09.27 1362
1763 SQL Server 테이블 및 인덱스 구조 아키텍처(2/4) – 힙 구조 jevida(강성욱) 2016.09.27 1067
1762 SQL Server 테이블 및 인덱스 구조 아키텍처(1/4) – 테이블 및 인덱스 구성 jevida(강성욱) 2016.09.27 1123
1761 SQL Server 트랜잭션 로그 아키텍처(4/4) – 미리 쓰기 트랜잭션 로그 jevida(강성욱) 2016.09.27 1537
1760 SQL Server 트랜잭션 로그 아키텍처(3/4) – 검사점 및 로그의 활성 부분 jevida(강성욱) 2016.09.27 1048
1759 SQL Server 트랜잭션 로그 아키텍처(2/4) – 트랜잭션 로그 물리 아키텍처 jevida(강성욱) 2016.09.27 1094
1758 SQL Server 트랜잭션 로그 아키텍처(1/4) – 트랜잭션 로그 논리 아키텍처 jevida(강성욱) 2016.09.27 1246
1757 파일 및 파일 그룹 아키텍처 jevida(강성욱) 2016.09.27 797
1756 SQL Server 페이지 및 익스텐트 아키텍처(4/4) – 수정된 익스텐트 추적 jevida(강성욱) 2016.09.27 1128
1755 SQL Server 페이지 및 익스텐트 아키텍처(3/4) – 개체에서 사용하는 공간 관리 jevida(강성욱) 2016.09.27 970
1754 SQL Server 페이지 및 익스텐트 아키텍처(2/4) – 익스텐트 할당 및 빈공간 관리 jevida(강성욱) 2016.09.27 1225
1753 SQL Server 페이지 및 익스텐트 아키텍처(1/4) – 페이지 및 익스텐트 이해 jevida(강성욱) 2016.09.27 2729
1752 SQL Server Error Log 보관 주기 설정 jevida(강성욱) 2016.09.15 2159
» SQL Server 네트워크 백업 트러블슈팅(UNC 설정) jevida(강성욱) 2016.09.15 5027





XE Login