IT/모바일
저자: 브라이언 윌슨, 역 한빛리포터 2기 서성용
때로는 간단하고 저렴한 솔루션이 근사한 기술을 이기기도 한다.
나는 ISP에서 장기 백업을 하기위해 아직도 테이프 백업 시스템을 사용하고 있지만 각 서버에는 두 개의 동일한 디스크 드라이브를 장착했다. RAID-1 미러는 자료를 두개의 드라이브 모두에 저장하여 갑작스런 시스템 재해로부터 자료를 보호할 수 있는 확실한 방법이다. 하지만 경험에 비추어 볼 때 하드 드라이브가 고장나거나 중요한 파일을 실수로 지우는 것 중 어떤 것이 더 흔한가?
RAID-1을 사용하는 대신 나는 "synchro" 라 불리는 펄 스크립트를 이용하여 매일 밤마다 두 개의 드라이브를 동기화한다. 이 기사에서는 이런 식으로 백업을 해야하는 이유를 설명하고, 독자들과 함께 스트립트를 공유하고자 한다.
RAID 기술
RAID는 성능을 향상시킬 수 있으나, 오직 적절한 조건에서만 그렇다. 최고의 결과를 위하여 두 개 이상의 드라이브와 스카시 컨트롤러가 사용되는 것이 일반적인 방식이다. 필자의 경우엔 EIDE 컨트롤러를 가지고 있다. EIDE는 CPU가 자료를 전송할 때 많은 일을 처리하도록 요구하므로 CPU가 병목점이 된다. EIDE 드라이브를 가지고 리눅스의 소프트웨어 RAID-1을 테스트한 결과, 성능 타격은 우리가 감당할 수 있는 것 이상이었다. 따라서 이것은 우리에게 적절한 선택사항이 아니라고 할 수 있다.
RAID-0 (스트라이핑)은 사용 가능한 용량을 증가시킬 수는 있으나 신뢰도의 향상은 가져다주지 못한다. RAID-0 (이 문제에 관한 한 RAID-4와 -5)에서는 자료가 여러 개의 드라이브에 분산되어 저장되기 때문에 여러 개의 물리적인 파티션이 하나의 거대한 논리적인 파티션으로 결합된다. 필자는 NNTP 뉴스 캐시를 저장하기 위해 40GB 드라이브에 리눅스 소프트웨어 RAID-0을 사용하여 거대한 파일시스템을 만든다. 이때 신뢰성은 문제되지 않는다. 왜냐하면 그것은 단지 캐시일 뿐이라서 드라이브 한 쌍 전체를 잃어버리는 것조차도 단지 뉴스를 읽는 것을 좀 느리게 할 뿐이기 때문이다. 이때 캐시에 대한 성능도 별 문제가 되지 않는데 동시에 뉴스서버에 접속하는 사람들의 수가 그렇게 많지 않기 때문이다. RAID-4와 RAID-5는 중복되거나 소프트웨어로 구현하기 위해서는 보다 많은 CPU 시간을 요구한다.
RAID는 신뢰도를 증가시킬 수 있다. 0보다 높은 RAID 수준에서 제공되는 잉여 설정을 통해 자료는 여러 개의 드라이브에 분산되기 때문에 하나의 드라이브에서 고장이 나도 자료는 유실되지 않는다. 필자는 예전에 하드웨어 RAID 컨트롤러를 사용했었다. Vortex SCSI-RAID 컨트롤러와 같은 것을 사용하고 싶지만 ISP는 작은 예산으로 운영되기 때문에 내가 하고 싶은 대로 다 할 수는 없다. 그리고 나는 하드웨어 RAID 컨트롤러와 같은 흔하지 않은 것들을 위한 긴급 교체용 부품을 보유하고 있는 것 보다 필요할 때면 언제든 동네 할인점에 뛰어갈 수 있는 것이 훨씬 더 실용적이라는 것을 알게되었다.
RAID 설치(하드웨어 혹은 소프트웨어) 방법은 아주 복잡하여 ISP 직원에게 보다 많은 작업을 하도록 요구한다. 가령 전화벨이 울릴 때 복잡한 시스템은 아주 불안정해 지는데, 왜냐하면 모뎀 회선을 받아들일 서버가 실행되고 있지 않기 때문이다.
프로젝트의 목적과 요구사항
내 서버는 두 번의 드라이브 고장에도 살아남았다. 두 번 모두 드라이브가 고장나기 전날부터 리눅스가 경고 메시지를 뿌리기 시작했고 그 덕택에 우리는 테이프 백업과 교체용 부품을 준비할 수 있었다. 드라이브는 갑자기 고장나지만 그 전에 이미 충분히 경고를 한다. 이것은 우리가 RAID-1 미러를 가지고 있어야 하는 필요성을 감소시켰다. 따라서 여러분은 이러한 로그 메시지를 계속 주시해야 할 것이다.
지금까지 우리가 경험한 가장 흔한 문제는 하드웨어 고장이 아니었다. 그것은 사람의 실수였다. 파일은 우리 회사 내부의 직원이나 고객에 의해서 지워지거나 잘못 수정되었고 그 때마다 즉시 복구되어야만 했다. 이 경우에 RAID 시스템은 전혀 필요가 없다. "delete" 명령은 즉시 그리고 효과적으로 미러의 두 개 드라이브 모두에서 파일을 지울 것이다. 여러분에게는 여전히 백업 테이프를 돌려야 하는 일이 남아 있으며 이것은 좀처럼 일찍 끝나는 작업은 아니다.
나는 모든 시스템 파일에 대해 리비전 제어(RCS 혹은 CVS)를 사용해보았다. 이것은 누구나 변경사항을 검사할 수 있는 한 이러한 변경사항에 대한 철저한 역추적을 가능케 한다. 하지만 어떤 것들은 여전히 그냥 지나쳐가기 때문에 보통 고객들의 파일에 대해서는 별 도움이 되지 못한다.
그래서 나의 목표는 항상 온라인으로 백업 파일시스템을 유지해서 실수로 수정되거나 지워진 파일들을 교체하고 흔하게 볼 수 없는 하드웨어 고장에도 대처할 수 있는 완벽한 드라이브를 갖는 것이다.
느린 미러
내 서버에 적용한 해결법은 데이터를 하루에 한번씩 두 번째 드라이브에 복사하는 것이었다. 그것은 파일을 복사하는데 하루가 걸리는 RAID-1 미러와 비슷하다.
이러한 접근은 완벽하지는 않다. RAID-1으로는 복구용 드라이브에 있는 파일은 언제나 최신 상태를 유지할 수 있지만 결국 이 시스템은 매일매일 하는 테이프 백업과 마찬가지 상태이다. 이것 역시 지워지거나 변경된 파일들 눈에 띄지 않은 채로 하루 이상 지속될 때는 도움이 되지 못한다(결국 두 번째 드라이브에서 사라지는 것으로 끝날 것임). 이 작은 스크립트는 좋은 테이프 백업 방법을 대치하는 것이 아니라 그에 추가되는 것임을 유의하라.
선행조건
synchro 스크립트의 핵심은 rsync 명령이다. synchro가 하는 임무는 서버들 중 어떤 특정 서버를 위해 적절한 인자를 자동으로 rsync에 전달하는 것이다. 그렇기 때문에 나는 각각의 서버에 대한 rsync 명령 파일을 만들 필요가 없다.
우선 용어부터 알아보자. 파티션은 하드 드라이브의 조각이고 디바이스 이름으로 언급되기도 한다. 리눅스에서 첫번째 IDE 드라이브에 대한 파티션 이름은 대개가 /dev/hda1, /dev/hda2... 계속 이런 식으로 진행된다. SCSI 드라이브는 /dev/sda1, /dev/sda2... 같은 식이다. 파일시스템은 포맷된 파티션이다. mount 명령은 디렉토리 구조 어딘가에 파일시스템을 마운트하기 위해 사용되고 "마운트 지점"으로 언급되기도 한다. 예를 들어 파티션 /dev/hda7에 위치한 파일시스템은 /home 에 마운트될 수 있고 /home 파일시스템으로 언급되기도 한다.
나는 원본 자료를 갖고 있는 파티션이나 파일시스템을 소스로 부르고 복사할 장소를 목적지라 부르겠다.
synchro는 펄(Perl)로 쓰여졌으며 펄의 최근 버전에서(5.x나 그 이상) 작동한다. 그것은 mount와 선택적으로 fsck를 포함한 몇몇 시스템 명령을 호출한다. 이때 여러분은 디폴트로 잘 설치되지 않는 rsync 명령을 필요로 할 것이다. 만약 인기 있는 리눅스 배포판을 사용하고 있다면 rsync 명령은 CD-ROM안에 있을 것이다. 그렇지 않으며 주요한 FTP 사이트에서 구할 수도 있다.
rsync를 사용하는 것의 좋은 점은 변경된 파일들만을 복사한다는 것이다. 만약 주어진 파일시스템이 하루가 지나도록 변경되지 않는다면 보통의 copy나 tar 명령을 사용하는 것보다 수천 배는 빠를 수 있다.
설정
분산 방식에서처럼 synchro는 하드 드라이브 두 개 모두 같은 방식으로 파티션되리라고 계산할 것이다. 나는 첫번째 드라이브를 /dev/hda에 두었고 두 번째 컨트롤러에 연결된 드라이브는 /dev/hdc에 두었다. 따라서 그 예는 아래와 같다.
나는 목적지를 결정하는 코드를 get_dest라는 서브루틴에 넣었다. 만약 다른 요구사항("a"와 "c" 이외의 다른 드라이브 같은 것들)을 필요로 한다면 [70-94] 라인의 코드를 바꾸어서 필요에 맞게 수정할 수 있다.
명령 라인에서 파일시스템의 목록을 명시적으로 넘겨줄 수도 있고 [45-52] 라인에 목록을 지정해둘 수 있다. 디폴트로 /boot, /, /var, 그리고 /home을 검색해 본다. 명령 라인은 (스크립트 안에) 내장된 목록을 오버라이딩한다.
synchro는 "extras" 라 불리는 내장된 목록을 사용해서 대개 복사되어서는 안되는 것(/dev 디렉토리와 같은 것)을 제외시킨다. rsync 명령은 /dev 디렉토리를 적절하게 다루지 못한다. 예를 들어 만약 rsync에게 /dev/hda1을 복사하라고 하면 단순히 디바이스 파일을 복사하는 것이 아니라 포맷되지 않은 전체 파티션을 복사하려고 할 것이다. 파일시스템 이름이 "extras+ 엔트리와 맞아 떨어지면 오른쪽 부분 (=> 기호 다음부분)이 rsync 명령에 추가된다.
[55-58] 행에 있는 디폴트는 모든 시스템에서 잘 작동한다.
필자는 임시 마운트 지점으로 /mnt/synchro를 사용한다. 스크립트는 디렉토리가 존재하지 않으면 이 디렉토리를 생성한다. 만약 다른 지점을 사용하고 싶다면 [68] 라인을 변경하면 된다.
초기 설치
synchro는 도움말을 의미하는 -h를 주고 실행하면 다음과 같이 출력될 것이다.
이 스크립트는 두 개의 하드 드라이브에 대해 파티션을 동기화한다.
synchro는 절대로 /dev 파일을 백업하지 않기 때문에 설치하는 동안 tar 명령 파이프라인을 이용해서 /dev 파일들을 복사해둔다. 보통 /dev 파일은 하드웨어를 변경하지 않는 이상 바뀌지 않기 때문에 대개 이것은 한번만 해주면 된다. 아래와 같은 명령어가 사용된다.
계정을 삭제하는 것과 같은 중대한 변화를 수행할 계획이라면 때때로 아래와 같은 명령 라인 모드를 이용해서 /home의 사본을 만들어 두는 것이 좋다.
다음은 synchro가 무슨 일을 하는지 요약한 것이다. 괄호 안에 있는 것은 라인 번호이다.
필자는 이와 같은 매일 매일의 rsync 방법을 이용하는 것 외에도 하드웨어로 지원되는 RAID-1을 사용하고 싶어한다는 사실을 주저하지 않고 인정할 것이다. 그러나 빠듯한 IT 예산은 그것을 허용치 않는다. 필자는 이 스크립트의 다양한 변종들을 지금까지 여러 해 동안 사용해왔다. 그리고 여러분도 이것의 유용함을 발견하기 바란다.
브라이언 윌슨은 이 기사의 대부분을 Marin 갑(岬)에서 금문교를 내려다보며 작성했다. 그는 자전거를 타는 것이 유익한 것처럼 랩탑과 법인체의 다운사이징에도 명백하게 각각의 장점이 있다고 주장한다.
때로는 간단하고 저렴한 솔루션이 근사한 기술을 이기기도 한다.
나는 ISP에서 장기 백업을 하기위해 아직도 테이프 백업 시스템을 사용하고 있지만 각 서버에는 두 개의 동일한 디스크 드라이브를 장착했다. RAID-1 미러는 자료를 두개의 드라이브 모두에 저장하여 갑작스런 시스템 재해로부터 자료를 보호할 수 있는 확실한 방법이다. 하지만 경험에 비추어 볼 때 하드 드라이브가 고장나거나 중요한 파일을 실수로 지우는 것 중 어떤 것이 더 흔한가?
RAID-1을 사용하는 대신 나는 "synchro" 라 불리는 펄 스크립트를 이용하여 매일 밤마다 두 개의 드라이브를 동기화한다. 이 기사에서는 이런 식으로 백업을 해야하는 이유를 설명하고, 독자들과 함께 스트립트를 공유하고자 한다.
RAID 기술
RAID는 성능을 향상시킬 수 있으나, 오직 적절한 조건에서만 그렇다. 최고의 결과를 위하여 두 개 이상의 드라이브와 스카시 컨트롤러가 사용되는 것이 일반적인 방식이다. 필자의 경우엔 EIDE 컨트롤러를 가지고 있다. EIDE는 CPU가 자료를 전송할 때 많은 일을 처리하도록 요구하므로 CPU가 병목점이 된다. EIDE 드라이브를 가지고 리눅스의 소프트웨어 RAID-1을 테스트한 결과, 성능 타격은 우리가 감당할 수 있는 것 이상이었다. 따라서 이것은 우리에게 적절한 선택사항이 아니라고 할 수 있다.
RAID-0 (스트라이핑)은 사용 가능한 용량을 증가시킬 수는 있으나 신뢰도의 향상은 가져다주지 못한다. RAID-0 (이 문제에 관한 한 RAID-4와 -5)에서는 자료가 여러 개의 드라이브에 분산되어 저장되기 때문에 여러 개의 물리적인 파티션이 하나의 거대한 논리적인 파티션으로 결합된다. 필자는 NNTP 뉴스 캐시를 저장하기 위해 40GB 드라이브에 리눅스 소프트웨어 RAID-0을 사용하여 거대한 파일시스템을 만든다. 이때 신뢰성은 문제되지 않는다. 왜냐하면 그것은 단지 캐시일 뿐이라서 드라이브 한 쌍 전체를 잃어버리는 것조차도 단지 뉴스를 읽는 것을 좀 느리게 할 뿐이기 때문이다. 이때 캐시에 대한 성능도 별 문제가 되지 않는데 동시에 뉴스서버에 접속하는 사람들의 수가 그렇게 많지 않기 때문이다. RAID-4와 RAID-5는 중복되거나 소프트웨어로 구현하기 위해서는 보다 많은 CPU 시간을 요구한다.
RAID는 신뢰도를 증가시킬 수 있다. 0보다 높은 RAID 수준에서 제공되는 잉여 설정을 통해 자료는 여러 개의 드라이브에 분산되기 때문에 하나의 드라이브에서 고장이 나도 자료는 유실되지 않는다. 필자는 예전에 하드웨어 RAID 컨트롤러를 사용했었다. Vortex SCSI-RAID 컨트롤러와 같은 것을 사용하고 싶지만 ISP는 작은 예산으로 운영되기 때문에 내가 하고 싶은 대로 다 할 수는 없다. 그리고 나는 하드웨어 RAID 컨트롤러와 같은 흔하지 않은 것들을 위한 긴급 교체용 부품을 보유하고 있는 것 보다 필요할 때면 언제든 동네 할인점에 뛰어갈 수 있는 것이 훨씬 더 실용적이라는 것을 알게되었다.
| 스크립트 보기 |
프로젝트의 목적과 요구사항
내 서버는 두 번의 드라이브 고장에도 살아남았다. 두 번 모두 드라이브가 고장나기 전날부터 리눅스가 경고 메시지를 뿌리기 시작했고 그 덕택에 우리는 테이프 백업과 교체용 부품을 준비할 수 있었다. 드라이브는 갑자기 고장나지만 그 전에 이미 충분히 경고를 한다. 이것은 우리가 RAID-1 미러를 가지고 있어야 하는 필요성을 감소시켰다. 따라서 여러분은 이러한 로그 메시지를 계속 주시해야 할 것이다.
지금까지 우리가 경험한 가장 흔한 문제는 하드웨어 고장이 아니었다. 그것은 사람의 실수였다. 파일은 우리 회사 내부의 직원이나 고객에 의해서 지워지거나 잘못 수정되었고 그 때마다 즉시 복구되어야만 했다. 이 경우에 RAID 시스템은 전혀 필요가 없다. "delete" 명령은 즉시 그리고 효과적으로 미러의 두 개 드라이브 모두에서 파일을 지울 것이다. 여러분에게는 여전히 백업 테이프를 돌려야 하는 일이 남아 있으며 이것은 좀처럼 일찍 끝나는 작업은 아니다.
나는 모든 시스템 파일에 대해 리비전 제어(RCS 혹은 CVS)를 사용해보았다. 이것은 누구나 변경사항을 검사할 수 있는 한 이러한 변경사항에 대한 철저한 역추적을 가능케 한다. 하지만 어떤 것들은 여전히 그냥 지나쳐가기 때문에 보통 고객들의 파일에 대해서는 별 도움이 되지 못한다.
 |
|
|
|
||
|
|
 |
| 러닝 리눅스 3판 | ||
|
||
|
|
|
느린 미러
내 서버에 적용한 해결법은 데이터를 하루에 한번씩 두 번째 드라이브에 복사하는 것이었다. 그것은 파일을 복사하는데 하루가 걸리는 RAID-1 미러와 비슷하다.
이러한 접근은 완벽하지는 않다. RAID-1으로는 복구용 드라이브에 있는 파일은 언제나 최신 상태를 유지할 수 있지만 결국 이 시스템은 매일매일 하는 테이프 백업과 마찬가지 상태이다. 이것 역시 지워지거나 변경된 파일들 눈에 띄지 않은 채로 하루 이상 지속될 때는 도움이 되지 못한다(결국 두 번째 드라이브에서 사라지는 것으로 끝날 것임). 이 작은 스크립트는 좋은 테이프 백업 방법을 대치하는 것이 아니라 그에 추가되는 것임을 유의하라.
선행조건
synchro 스크립트의 핵심은 rsync 명령이다. synchro가 하는 임무는 서버들 중 어떤 특정 서버를 위해 적절한 인자를 자동으로 rsync에 전달하는 것이다. 그렇기 때문에 나는 각각의 서버에 대한 rsync 명령 파일을 만들 필요가 없다.
우선 용어부터 알아보자. 파티션은 하드 드라이브의 조각이고 디바이스 이름으로 언급되기도 한다. 리눅스에서 첫번째 IDE 드라이브에 대한 파티션 이름은 대개가 /dev/hda1, /dev/hda2... 계속 이런 식으로 진행된다. SCSI 드라이브는 /dev/sda1, /dev/sda2... 같은 식이다. 파일시스템은 포맷된 파티션이다. mount 명령은 디렉토리 구조 어딘가에 파일시스템을 마운트하기 위해 사용되고 "마운트 지점"으로 언급되기도 한다. 예를 들어 파티션 /dev/hda7에 위치한 파일시스템은 /home 에 마운트될 수 있고 /home 파일시스템으로 언급되기도 한다.
나는 원본 자료를 갖고 있는 파티션이나 파일시스템을 소스로 부르고 복사할 장소를 목적지라 부르겠다.
synchro는 펄(Perl)로 쓰여졌으며 펄의 최근 버전에서(5.x나 그 이상) 작동한다. 그것은 mount와 선택적으로 fsck를 포함한 몇몇 시스템 명령을 호출한다. 이때 여러분은 디폴트로 잘 설치되지 않는 rsync 명령을 필요로 할 것이다. 만약 인기 있는 리눅스 배포판을 사용하고 있다면 rsync 명령은 CD-ROM안에 있을 것이다. 그렇지 않으며 주요한 FTP 사이트에서 구할 수도 있다.
rsync를 사용하는 것의 좋은 점은 변경된 파일들만을 복사한다는 것이다. 만약 주어진 파일시스템이 하루가 지나도록 변경되지 않는다면 보통의 copy나 tar 명령을 사용하는 것보다 수천 배는 빠를 수 있다.
"synchro"는 다른 파일시스템들을 인식한다. 나는 보통의 리눅스 ext2fs와 Reiser 저널링 파일시스템인 reiserfs를 가지고 이 사실을 테스트 해보았다. 나는 하나의 사소한 변경으로 fsck 명령이 reiserfs에 대해 정확한 검사를 하도록 했다. 또한 /sbin/fsck.reiserfs에 두줄짜리 스크립트를 만들었는데 그 내용은 다음과 같다.
#!/bin/sh echo "Yes" | reiserfsck $*이제 누군가 fsck -t reiserfs 명령을 사용할 때 fsck 명령은 Reiser 파일시스템을 어떻게 검사해야 하는지를 안다. |
분산 방식에서처럼 synchro는 하드 드라이브 두 개 모두 같은 방식으로 파티션되리라고 계산할 것이다. 나는 첫번째 드라이브를 /dev/hda에 두었고 두 번째 컨트롤러에 연결된 드라이브는 /dev/hdc에 두었다. 따라서 그 예는 아래와 같다.
원본 파일시스템 파티션 백업된 곳
/ /dev/hda1 /dev/hdc1
/home /dev/hdc7 /dev/hda7
이 시스템은 내가 파일을 복구해야 할 때 복구해야할 파일들을 찾아내는데 기억하기 쉽도록 해준다. 만약 파일이 /home에서 제거되었다면 마운트를 사용해 /home 파일시스템이 /dev/hdc7에 있는지를 알아보고 그렇다면 mount /dev/hda7 /mnt/synchro 명령을 내려 백업 사본을 잠시동안 이용할 수 있도록 해준다. 보통 모든 백업 파일시스템은 마운트되지 않은 채로 있다.
나는 목적지를 결정하는 코드를 get_dest라는 서브루틴에 넣었다. 만약 다른 요구사항("a"와 "c" 이외의 다른 드라이브 같은 것들)을 필요로 한다면 [70-94] 라인의 코드를 바꾸어서 필요에 맞게 수정할 수 있다.
명령 라인에서 파일시스템의 목록을 명시적으로 넘겨줄 수도 있고 [45-52] 라인에 목록을 지정해둘 수 있다. 디폴트로 /boot, /, /var, 그리고 /home을 검색해 본다. 명령 라인은 (스크립트 안에) 내장된 목록을 오버라이딩한다.
synchro는 "extras" 라 불리는 내장된 목록을 사용해서 대개 복사되어서는 안되는 것(/dev 디렉토리와 같은 것)을 제외시킨다. rsync 명령은 /dev 디렉토리를 적절하게 다루지 못한다. 예를 들어 만약 rsync에게 /dev/hda1을 복사하라고 하면 단순히 디바이스 파일을 복사하는 것이 아니라 포맷되지 않은 전체 파티션을 복사하려고 할 것이다. 파일시스템 이름이 "extras+ 엔트리와 맞아 떨어지면 오른쪽 부분 (=> 기호 다음부분)이 rsync 명령에 추가된다.
[55-58] 행에 있는 디폴트는 모든 시스템에서 잘 작동한다.
필자는 임시 마운트 지점으로 /mnt/synchro를 사용한다. 스크립트는 디렉토리가 존재하지 않으면 이 디렉토리를 생성한다. 만약 다른 지점을 사용하고 싶다면 [68] 라인을 변경하면 된다.
초기 설치
synchro는 도움말을 의미하는 -h를 주고 실행하면 다음과 같이 출력될 것이다.
이 스크립트는 두 개의 하드 드라이브에 대해 파티션을 동기화한다.
Usage: synchro [options] [filesystem...] 용법: synchro [옵션] [파일시스템...] -d dryrun - 어떤 조치를 수행하지 않고서도 실행될 수 있는 명령을 보여줄 것 -f fsck - 목적 할당에서 fsck 명령을 수행할 것 -h 이 메시지를 보여주고 종료할 것 -n -n 옵션을 rsync에게로 넘겨주어 파일을 복사하지 않고 보고할 것 -v -v 옵션을 rsync에게로 넘겨주어 파일을 복사하는 동안 보고 할 것 [[/font]]synchro를 새로운 시스템에 설치할 때 처음에는 -d 옵션을 주고 실행시켜 그것이 어떤 명령을 실행할지 확인한다. 그리고 그것이 적절하다고 생각되면 한번만 수동으로 실행해서 모든 것을 복사한다. 그리고 나서 -v 옵션으로 다시 실행한다. 이번에는 무엇인가가 바뀌었다면 어떤 파일인지 보고할 것이다.
synchro는 절대로 /dev 파일을 백업하지 않기 때문에 설치하는 동안 tar 명령 파이프라인을 이용해서 /dev 파일들을 복사해둔다. 보통 /dev 파일은 하드웨어를 변경하지 않는 이상 바뀌지 않기 때문에 대개 이것은 한번만 해주면 된다. 아래와 같은 명령어가 사용된다.
mount /dev/hdc1 /mnt/synchro tar cvf - /dev | (cd /mnt/synchro; tar xpf -)정확하게 작동하는지 확인한 후에 /etc/crontab에 항목을 추가하여 그것을 하루에 한번씩 실행시킨다. -f 옵션을 사용해 실행될 때마다 목적지 파일시스템이 점검되도록 한다. 필자는 이것을 명령 라인 옵션을 만들어서 원하지 않을 경우엔 여러분이 강제로 실행할 필요가 없도록 했다.
계정을 삭제하는 것과 같은 중대한 변화를 수행할 계획이라면 때때로 아래와 같은 명령 라인 모드를 이용해서 /home의 사본을 만들어 두는 것이 좋다.
synchro -v /home-v는 rsync에 전달되어 변경된 파일의 목록을 출력할 것이다.
다음은 synchro가 무슨 일을 하는지 요약한 것이다. 괄호 안에 있는 것은 라인 번호이다.
- 명령 라인 옵션[29]와 파일시스템 [39-40]이 있다면 읽어들인다. 만약 파일시스템이 주어지지 않았다면 기본 내부 목록 [45-52]을 사용한다.
- 마운트 포인트가 없으면 생성한다[94-100].
- mount 명령을 실행하여 파일시스템 타입과 파티션 이름의 목록을 작성한다. [105-113]
- 파일시스템의 목록을 순환한다[121-156]. 각각의 파일시스템에 대해서
- "extras" 목록에서 extra 옵션을 가져온다. [124]
- 2 단계에서 info를 사용하여 목적지 이름을 결정한다. [128-130]
- fsck 명령으로 목적지 파일시스템을 검사한다. [132-139]
- 목적지 파일 시스템을 마운트한다. [141-144]
- rsync를 사용하여 내용을 동기화한다. [146-150]
- 목적지 파일시스템을 언마운트한다. [152-155]
필자는 이와 같은 매일 매일의 rsync 방법을 이용하는 것 외에도 하드웨어로 지원되는 RAID-1을 사용하고 싶어한다는 사실을 주저하지 않고 인정할 것이다. 그러나 빠듯한 IT 예산은 그것을 허용치 않는다. 필자는 이 스크립트의 다양한 변종들을 지금까지 여러 해 동안 사용해왔다. 그리고 여러분도 이것의 유용함을 발견하기 바란다.
브라이언 윌슨은 이 기사의 대부분을 Marin 갑(岬)에서 금문교를 내려다보며 작성했다. 그는 자전거를 타는 것이 유익한 것처럼 랩탑과 법인체의 다운사이징에도 명백하게 각각의 장점이 있다고 주장한다.
TAG :
최신 콘텐츠