[보안] 보안과 같이 가는 백업의 중요성..

보안과 따로 갈 수 없는 백업의 방식과 백업시 주의점.

                                      오늘과 내일 홍석범(antihong at tt.co.kr)

이른바 “정보보호” 의 마인드가 확산되면서 해킹이나 크래킹에 대비한 정보보호의 측면

으로 많은 논의가 되고 정보가 공유되고 있지만 정작 매우 중요한 백업에 대한 구체적 방

식 및 주의점에 대해서는 많은 정보가 공유되고 있지 않는 실정이다. 실무적으로 시스템

을 담당하는 이들은 사전에 백업의 중요성을 인식하지 못하다가 중요한 데이터를 훼손당

하거나 긴급하게 데이터를 복구하여야 할 필요성이 있을 경우에서야 비로소 백업의 중요

성을 인식하여 소 잃고 외양간 고치는 격으로 백업을 실시하거나, 설사 백업을 하더라도

사전 지식이나 올바른 정책 없이 실시하여 매우 비효율적인 방법으로 백업을 하는 경우

가 많이 있다.

따라서 이 섹션에서는 일반적으로 폭넓게 사용하고 있는 리눅스를 중심으로 보안이라는

화두와 결코 따로 갈 수 없는 백업의 방식과 백업시 주의점에 대해 알아보도록 하겠다.

1. 백업정책 설정시 고려할 점.

백업을 실시할 경우 어떤 방법으로 어떤 매체를 이용해 어떤 주기로 할 것인지 이른바

“백업정책” 을 설정하여야 하는데. 이때 고려하여야 할 점에 대해 알아보기로 하자.

(1) 호환성 – 자신이 운영하는 시스템에서 백업의 대상이 되는 데이터가 각기 다른 운영

체제와 다른 시스템과 호환이 될 필요가 있다면 백업 후 데이터의 호환성이나 이식성을

고려하여야 한다.

(2) 자동 백업 – 사실 백업이라는 절차가 만일의 사고에 대비하여 꼭 필요한 절차이기는

하지만 손이 많이 가는 작업이기는 하다. 특히 백업을 하여야 할 대상이 여러 시스템이거

나 하나의 시스템내에서도 일괄 백업이 아닌 일부의 데이터에 대해서만 백업을 할 필요

가 있다면 일련의 백업작업의 자동화는 필수라고 할 수 있을 것이다.

(3) 비용 – 데이터의 유실이나 사고 발생시에는 백업의 소중함을 더 없이 인식하지만 평

소에는 백업이 마치 사치라고 생각하는 사람이 있을 수도 있다. 따라서 가급적이면 적은

비용으로 백업을 할 수 있다면 좋을 것이다.

(4) 작업의 편리성 – 요즘에는 편리하게 백업정책을 설정하고 복잡한 설정도 쉽게 할 수

있으며 백업 상황등을 GUI 환경으로 볼 수 있는 백업유틸리티나 상용 솔루션들이 많이

나와 있다. 그러나 이러한 X-Windows 기반의 프로그램의 경우 일반 데스크탑에서는 유

용하나 보안을 중요시하는 서버 시스템의 경우 X-Windows 자체를 사용하지 않는 경우

가 있으므로 이 부분은 신중하게 검토할 필요가 있다.

(5) 네트워크 백업 – 이 부분은 자동백업과 함께 가장 중요한 부분중의 하나라고 판단된

다. 일반적으로 백업은 백업매체의 자체백업(또는 1차 백업이라 한다.) 뿐만 아니라 일정

주기로 2차,3차 백업을 하게 되는데, 이러한 2차,3차 백업이 자동으로 되려면 네트워크

를 통한 백업이 가능하여야 한다.

(6) 저장 매체의 선택 – 백업의 매체에 따라 저장방식이 다른 경우가 있으므로 신중히 선

택되어야 한다. 고전적인 방식의 테이프나 추가의 하드 디스크, 다시쓸 수 있는 CD등 다

양한 매체가 있을 수 있다. 위의 여러 가지 사항 및 자신이 관리하는 시스템의 특성을 고

려하여 저장매체를 선택하여야 할 것이다.

권장할 만한 방식.

위의 여러 가지 상황을 고려하여 이식성이 높고 여러 옵션이 지원되며 백업 화일을 이용

해 복구시에서도 강력한 기능을 제공하는 tar 를 이용하여, 하드 디스크에 저장하는 방식

을 권장한다. tar는 “Tape ARchiver” 에서 나온 말에서도 알 수 있듯이 초기에 주로

테이

프 백업을 위해 자주 쓰였던 유틸리티인데, 이는 리눅스를 포함한 변종의 유닉스 계열에

서도 모두 사용이 가능하고 Shell Script 등을 이용하면 복잡해 보이는 백업정책도 쉽고

단순하게 세울 수 있으며 백업후 복구가 필요한 시점에서도 강력한 기능을 발휘할 수 있

다.

그리고, 예전에는 주로 테이프 백업을 선호하였지만 요즘에는 고속의 고용량, 저가의 하

드 드라이브가 보편화되면서 테이프보다는 하드 드라이브를 추가 장착하여 백업매체로

써 널리 이용하는 추세이다.

2. 백업의 방식

그럼, 이제 구체적으로 어떻게 백업할 것인지 백업의 방식에 대해 이야기 해 보도록 하

자.

먼저, 어떤 데이터를 어떤 주기로 백업할 것인가를 선택하여야 할 것이다.

모든 데이터를 매일 백업하는 것은 비효율적이므로 꼭 백업이 필요한 데이터만 적당한

주기로 백업하는 것이 불필요한 백업으로 인한 디스크 공간을 절약할 수 있고 백업작업

으로 이한 필요이상의 프로세스를 줄일 수 있다.

백업을 할 대상은, 다른 서버에서 복사(이식)가 가능한 바이너리나 기본설정화일들은 굳

이 백업할 필요가 없으며 각 시스템마다 고유한 시스템 설정(Configuration) 과 실제 데

이터는 반드시 백업하여야 할 것이다.

일반적으로 리눅스의 경우 대부분의 설정은 /etc 디렉토리에 있으며, 각종 데이터

는 /home 이하에, 그리고 기타 부가적으로 설치하는 프로그램은 /usr/local 에 있으니

자신의 시스템 고유의 설정을 고려하여 각각의 디렉토리이하에 대해 적절히 백업을 하

면 된다. 이를테면 메일 서버의 경우 추가적으로 /var/spool/mail 이하의 데이터가 매우

중요하므로 백업시 추가하여야 할 것이다. 백업 디렉토리 설정시 주의할 점은 backup

이 되는 파일을 다시 백업하여 무한루프에 빠지는 실수를 주의하여야 하고 실시간으로

시스템내 프로세스에 대한 정보가 저장되는 /proc 역시 백업을 하는 실수를 범하지 말아

야 한다.

그럼. 예제를 통해 실제로 백업을 하는 명령어를 알아보도록 하자.

cd /backup

tar cvpfz /backup/home.tar.gz /home –exclude=/home/test        

     [ 스크립트 1 ]

위의 명령에서 사용한 옵션에 대해 하나씩 알아보도록 하자.

먼저 백업파일은 /backup 이라는 디렉토리에서 생성하기를 원하므로 /backup 으로 이

동한후 tar 명령을 이용해 백업을 시작한다.

“c” 는 Create a new archive 의 뜻으로 백업시 새로운 파일을 생성하며

”v” 는 Verbosely list files processed 의 뜻으로 백업시 백업이 진행되고 있는 상황

     및 디렉토리 리스트를 보여주며

“f” 는 archive file is local 의 뜻이며 명령어 이후의 이름이

    생성될 파일의 이름이라는 뜻이며

“p” 는 Preserve-Permissions 의 뜻으로 이전 데이터의 Permission 정보를

    그대로 보존한다는 뜻이며

“z” 는 filter the archive through gZip의 뜻으로 gzip 으로 압축한다는 뜻이다.

일반적으로 tar로 백업시 사용되는 확장자 규칙은 압축되지 않고 단순히 하나의 파일로

패킹(packing) 한 파일의 경우에는 “tar” 를, gzip 으로 압축된 파일의 경우에는

”tar.gz”

나 “tgz” 를 확장자로 한다. 따라서 확장자가 home.tar.gz 나 home.tgz 일 경우 tar 로

packing (즉 단순히 하나의 파일로 묶기만 함) 된후 gzip 으로 압축되었음을 뜻한다.

[스크립트 1] 과 같이 실행되었을 경우에는

/backup 디렉토리에 /home/test 이하를 제외한 /home 이하의 모든 파일들이

home.tar.gz 라는 이름으로 생성된다. 제외할 디렉토리나 파일이 더 있을 경우에는 —

exclude 옵션을 계속 이어서 쓰면 된다.

그리고 백업시 “z” (압축) 옵션의 사용에 유의하여야 한다. 단순히 하나의 파일로 압축백

업시에는 때에 따라 데이터의 일부가 손상되는 경우가 있는데, 이때에는 백업된 파일 전

체가 깨어져 복구를 할 수 없게 되는 경우가 있다. 백업시 압축을 하지 않고 단순히 tar

로 Packing한(묶은) 경우에는 설사 파일이 깨어지거나 손상되었다 하더라도 파일의 복

구가 가능하기 때문에 백업시 압축을 할 것인지 여부를 신중히 선택하여야 한다.

아울러 현재까지 최신 안정 커널인 Kernel 2.2 리눅스의 경우, 하나의 파일은 최대 2G

가 최대 사이즈인데, 특정 파티션 이하에 많은 파일이 있어 하나의 파일로 백업하였는데,

2G를 넘을 경우에는 적당히 분산하여 백업을 하여야 한다.

이때에는 아래와 같은 방법이 가능할 것이다.

tar cvfpz home_a_h.tar.gz /home/[a-h]*

tar cvfpz home_i_p.tar.gz /home/[i-p]*

tar cvfpz home_q_z.tar.gz /home/[q-z]*

/home 이하의 디렉토리에 많은 하부 디렉토리 및 파일이 있을 때에는 전체 디렉토리를

백업할 경우 2기가를 초과하여 백업파일이 제대로 생성되지 않으므로, 이를 /home 이하

의 디렉토리명이나 피일 이름의 이니셜로 구분하여 3등분하면서 백업을 하는 것이다.

그럼, 실제로 백업을 하는 스크립트를 분석해 보자.

#!/bin/sh                         ……………… (1)

cd /backup                       ……………… (2)

rm -f *.tar.gz                    ………………. (3)

tar cvfpz apache.tar.gz /usr/local/apache/* …….. (4)

tar cvfpz home.tar.gz /home/* –exclude=/home/test  …….. (5)

tar cvfpz etc.tar.gz /etc/*                ……….. (6)

tar cvfpz mail.tar.gz /var/spool/mail/*   ……….. (7) ,

chown backup.backup *.tar.gz           ………….. (8)

chmod 700 *.tar.gz                       ………….. (9)

ls -alh | mail -s www50_backup backup at tt.co.kr …….. (10)

df -sh | mail -s www50_df backup

at tt.co.kr   ………. (11)

[ 스크립트2 ]

(1) 번은 시작되는 내용이 Shell Script 임을 정의한다.

(2) 백업작업이 이루어지는 파티션인 /backup 으로 이동한다.

(3) 새롭게 백업을 하여아 하므로 기존의 백업된 파일을 모두 삭제한다.

(4) – (7) 번까지는 백업을 해야 할 디렉토리 이하에 대해 데이터를 각각 백업한다.

(8) 백업된 파일의 소유권을 backup 으로 설정한다.

(9) 백업된 파일의 권한을 700 으로 설정한다.

(10) 백업이 제대로 되었는지 확인하기 위해 현재의 디렉토리내 백업 파일의 리스트등의

   정보를 백업담당자인 backup at

tt.co.kr 에게 메일로 발송한다.

(11) 혹 파티션이 가득 찰수도 있으니 현재의 파티션 사용 정보를 백업담당자에게

   메일로 발송한다.

별도의 설명이 필요하지 않을 정도로 간단한 스크립트이다.

Shell 스크립트는 실행되어야 할 명령어를 순서대로 나열하기만 하면 된다.

위 예에서는 Full Backup을 보여주고 있는데, 필요에 따라 적절히 “증가분 백업” 도 이용

하기 바란다. 증가분(변경분) 백업은 풀백업을 받은 후 기존의 백업 데이터와 비교하여

이미 백업된 이후 변경되거나 추가된 부분만 백업하는 방식이다.

예를 들어 설명해 보도록 하자.

아래의 예는 백업을 단순화 하기 위해 /home 에 대해서만 백업하는 예를 들겠다.

백업정책은 일주일을 단위로 풀백업을 받고 이후 매일 증가분 백업을 하기로 한다.

#!/bin/sh                          ………..(1)

TODAY=`date +”%d %b %Y”`       ……….. (2)

PREVIOUSDAY=`cat FULL_BACKED_DAY`   ………… (3)

tar cvfpzG _modified_home.tgz -N “$PREVIOUSDAY” /home ……….(4)

[ 스크립트3 ]

먼저 위의 스크립트를 실행하기에 앞서 [스크립트 2]를 참고하여 일주일을 단위로(정기

적으로 백업을 하는 방법은 이후에 설명할 CRON을 이용하면 된다.) /home 에 대해 Full

Backup을 실행하기로 한다.(이때 백업 스크립트 제일 하단에

echo `date +”%d %b %Y”` > FULL_BACKED_DAY 를 추가한다)

이후 매일 위의 [스크립트3] 스트립트를 실행하면 풀백업이후 추가 및 변경된 파일과 디

렉토리만 선별하여 별도로 백업을 하게 되는 것이다.

(1) 실행되는 스크립트가 Shell 스크립트임을 정의한다.

(2) 현재의 시각을 -N 옵션이 이해할 수 있는 13 Jan 2001 형태로 TODAY 라는 변수에

대입한다.

(3) 이전에 Full 백업시의 시각인 FULL_BACKED_DAY를 읽어 PREVIOUSDAY 라는

변     수에 대입한다.

(4) /home 디렉토리 이하에 대해 Full 백업시의 시각 이후로 변경, 추가된 파일에

대해서만 modified_home.tgz 라는 파일로 저장한다.

증가분 백업 스크립트는 다소 복잡하기는 하지만 각자의 환경에 따라 [스크립트 2] 스크

립트와 적절히 혼합하여 사용한다면 프로세스의 유발을 최소화하여 유용하게 사용이 가

능할 것이다.  

그럼, 이의 스크립트를 매주 또는 매일 일일이 실행할 필요 없이 자동으로 실행할 수 있

는 방법은 무엇일까? 이 물음에 해답을 줄 수 있는 것이 바로 cron을 이용하는 것이다.

cron 은 일종의 일정관리 데몬으로서 기본 설정파일인 crontab 에서 정해진 시각에 따

라 주기적으로 명령을 수행한다. crontab 은 아래와 같이 7개의 구성요소로 이루어지는

데, 6번째 필드(User)는 생략되어도 무방하다.

분 | 시 | 날짜 | 달 | 요일 | 사용자 | 명령어

각 항목은 정수로 나타낼 수도 있고 또한 몇 개의 항목은 와일드카드 문자로 인식되는

“*” 문자로 표현이 가능한데, * 는 “매” 의 의미이다. 즉 시간 항목에 * 이 있다면 매시간

이라는 뜻이고 날짜 항목에 * 이 있으면 매일이라는 뜻이 되는 것이다. 그리고 하나의 필

드에 중복된 시간을 나타내고자 하면 콤마로 구분하면 되고, 연속된 시간을 나타내고자

하면 하이픈(-)을 이용하여 일정 기간을 나타낼 수 있다.

참고로 분은 0-59, 시는 0-23, 날짜는 0-31, 달은 0-12(0또는 12는 12월, 1은 1월), 요일

은 0-7(0과 7은 일요일, 1은 월요일)로 나타낸다.

그럼, crontab 파일을 열어보자.

01 * * * * root run-parts /etc/cron.hourly

02 2 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

0 0 * * 1 root rdate -s time.bora.net && clock -w

위 설정에서 각각의 의미를 알아보도록 하자.

첫줄은 매시 1분에 /etc/cron.hourly 디렉토리내의 스크립트를 실행한다는 의미이고

두번째줄은 매일 02시 2분에 /etc/cron.daily 내의 스크립트를 실행한다는 의미이며

세번째줄은 매월, 매일 새벽 4시 22분에 /etc/cron.weekly 디렉토리내 스크립트를 실행

하는 것처럼 보이지만 5번째 필드인 <요일> 필드값이 *이 아닌 0 이므로 1주일에 1회 일

요일(0이므로) 에 /etc/cron.weekly 디렉토리내의 스크립트를 실행하라는 의미이다.

네번째줄은 같은 방식으로 직접 해석해 보기 바란다.

다섯번째줄과 같이 매일, 매주 0시0분, 매주 월요일(1) 에 rdate -s time.bora.net &&

clock -w 라는 명령어를 실행하라는 형식으로 직접 명령어를 지정해 줄 수도 있다.

각 디렉토리내 실행 스크립트는 정기적으로 시스템에 의해 실행이 되어야 하므로 실행

(eXecute) 권한이 있어야 함은 당연하다. 따라서 위에서 작성한 스크립트를 700 정도의

적당한 실행권한을 부여하여 해당 디렉토리에 설정해 주면 될 것이다.

또는 직접 /etc/crontab를 편집하여 실행시간을 정의할 수도 있다.

기타 tar나 crontab 에 대한 부가적인 명령어 옵셥은 man 페이지나 HOWTO 문서를 참

고하기 바란다.

3. 2차 및 3차 백업에 대해

서버 자체에서의 1차 백업은 짧은 기간에 정기적으로 이전의 백업을 삭제하고 새롭게 백

업을 받으므로 데이터의 훼손이나 삭제사실을 늦게 발견하였을 경우에는 이미 삭제된 데

이터로 백업을 받아 복구할 수 없는 경우가 발생한다. 또는 자체 백업이 되는 서버에 장애

가 있거나 백업 데이터 자체가 훼손이 되는 경우도 있다. 이러한 경우에 대비하여 반드시

2차백업을, 가능하다면 3차백업까지 설정 하여 운영하는 것이 필요한데, 2차 백업은 1차

백업의 내용을 ftp로 전송하거나, rsync를 이용하여 특정 디렉토리 이하에 대해 동기화

를 하는 방법등이 있다. 일반적으로 백업 주기를 타이트하게 설정시 1차백업은 월,수,금

새벽에 진행하고, 2차 백업은 화,목,토 새벽에, 그리고 3차백업은 2차백업서버에 접속하

여 수,일 새벽정도에 하는 것이 권장할 만한 방법이다.

ftp를 이용한 2차 백업서버로의 전송은 expect 스크립트를 이용해 ftp 작업을 자동화 할

수 있으며 ncftpget을 이용, 스크립트를 작성하는 방법도 있다.

## Expect script를 이용하는 방법

#!/usr/bin/expect                     …………..(1)

spawn ftp data.tt..co.kr                …………(2)

expect “Name :”                      …………..(3)

send “backup\\r”                        ………….(4)

expect “Password:”                    …………(5)

send “tomorrow\\r”                    ………….(6)

expect “ftp>”                         ………..(7)

sleep 1                               ………… (8)

send “bin\\r”                           …………(9)

expect “200 Type set to I.”            …………(10)

sleep 1                                ………..(11)

expect “ftp>”                          ………..(12)

send “get /backup/home.tar.gz /home/pr/data_home.tar.gz\\r” ……….(13)

expect ” Kbytes/sec)”                  …………(14)

sleep 1                                 ………..(15)

expect “ftp>”                           ………….(16)

send “quit\\r”                          ………..(17)

expect “221 Goodbye.”                  …………(18)

interact                                ………….(19)

(1)먼저 expect 스크립트라는 것을 정의한후

(2)백업을 받으려는 서버인 data.tt.co.kr 에 ftp로 접속한다.

(3)”Name :” 이라는 응답이 오기를 기대(expect)한다.

(4) 데이터 서버에 접속하기 위해 username 인 backup 을 입력후 엔터를 입력한다.

(5) username을 입력했으므로 Password: 라는 반응이 오기를 기다린다.

(6) username 에 해당하는 암호인 tomorrow를 입력한다.

(이 부분은 각자의 환경에 따라 다를 것이다)

(7) ftp> 라는 반응이 오기를 기다린다.

(8) 1초간 대기를 한후

(9) binary 로 전송을 받아야 하므로 bin 입력을 한다.

(10) 서버로부터 200 Type set to I 라는 반응이 오기를 기다린후

(11) 1초간 대기를 한후

(12) ftp> 라는 반응이 오기를 기대(expect) 한후

(13) 원격지 데이터 서버의 /home/pr/data_home.tar.gz를 백업서버의

   /backup디렉토리에 home.tar.gz 라는 파일로 저장한다.

(14) 사버로부터 Kbytes/sec) 라는 메시지가 출력되면

(15) 1초간 대기를 (sleep)한 후

(16) ftp> 메시지가 오기를 기다린 후

(17) quit를 입력하여 접속을 끊고

(18) 221 Goodbye 메시지가 나오기를 기대한 후

(19) 이후 명령어입력 정보를 기다린다.

만약 전송받는 파일의 사이즈가 클 경우에는 sleep 1 대신에

set timeout -1 를 지정하여야 정상적으로 ftp 전송이 가능하다.

그러나 expect 보다는 ncftpget을 이용하는 방법이 더 간단하고 빠르게 전송할 수 있다.

#!/bin/sh

rm -f *.tar.gz        ………………(1)

ncftpget -u backup -p ‘tomorrow’

data.tt.co.kr /home/data_backup ‘/backup/home.tar.gz’ ……….(2)

이 두줄로 간단하게 처리가 되는데 이는

(1) 기존의 백업받았던 데이터를 삭제후

(2) ncftpget을 이용해 data.tt.co.kr 에 접속하여 /backup 디렉토리의 home.tar.gz 라

는 파일을 백업서버의 /home/data_backup 디렉토리이하에 home.tar.gz 라는 파일로

ncftp전송한다는 뜻이다.

expect 보다는 ncftpget 이 좀더 빠르고 간단하므로 ncftpget을 사용하기를 권장한다.

ncftpget 과 비슷한 방법으로 rsync 라는 패키지를 이용하는 방법이 있는데, 이는 rpm

으로도 기본 제공되므로 쉽게 이용이 가능하며 백업뿐만이 아니라 Clustering 으로도 적

용 가능하다.

설정방법은

(1) 먼저 데이터 서버의 /etc/inetd.conf 에

rsync stream tcp nowait root /usr/bin/rsync rsyncd –daemon를 추가 설정후

killall -HUP inetd 로 INETD를 재설정한다.

rsync 는 포트 873을 이용하며 –daemon은 데몬 모드로 작동한다는 뜻이다.

(2) /etc/rsyncd.conf 에 아래와 같이 설정한다.

[mail]

path = /backup

comment = mail 서버

uid = root

gid = root

use chroot = yes

read only = yes

hosts allow = 211.11.22.33

max connections = 1

[mail] rsync의 서비스명으로 어떠한 이름을 설정하여도 된다.

    단, 백업서버에서 데이터 전송시 필요한 설정이다.

path  데이터를 동기화할(즉, 백업으로 전송할) 디렉토리를 설정한다.

    여기에서는 /backup 이하의 디렉토리에 대해 2차 백업을 할 것이다.

comment 서비스명에 대한 설명이다.

uid  파일을 전송하는 사용자의 uid로 기본값은 nobody이다.

gid  파일을 전송하는 사용자의 gid로 기본값은 nobody이다.

use chroot 위의 path를 최상위 디렉토리로 사용하여 이외의 디렉토리는 접근할 수 없

도록

   하는 설정으로 보안상 필요하므로 꼭 설정한다.

read only 읽기전용모드로 설정한다는 의미이다.

hosts allow 기본값은 모든 접속을 받아들이므로 보안을 유지하려면 반드시 백업서버의

IP            를 설정하여야 한다.

max connections 백업서버에서 전송시 동시접속자수를 뜻한다. 1정도면 적당하다.

timeout 클라이언트에서의 접근시 타임아웃시간이다.

아래는 데이터를 백업할 2차 백업서버에서의 설정 내용이다.

#!/bin/sh                                       …………… (1)

cd /mail_backup                                         ………… (2)

rm -rf *                                        …………. (3)

/usr/bin/rsync -av data.tt.co.kr::mail /mail_backup    ………….. (4)

chown root.root *                                  ……………. (5)

chmod 700 *                                       ………….. (6)

(1) shell 스크립트임을 정의한다.

(2) 백업을 받을 디렉토리인 /mail_backup 으로 이동후

(3) 기존의 백업받았던 데이터를 삭제한다.

(4) rsync을 이용해 서버에 접속하여 데이터를 받아온다.

이때 -a는 아카이브 모드로서 파일의 속성이나 퍼미션 및 소유권등의 정보

를 보존하여 동기화한다는 의미이며 -v 는 verbose 의 의미로 동기화의 진행상황을

자세하게 보여준다. 데이터 서버에서 서비스명을 [mail] 로 했으므로

data.tt.co.kr::mail 로 설정되었으며 동기화한 데이터는 /mail_backup 이라는 디렉토리

에     저장된다.

(5),(6)은 위에서 설명되었으며 보다 세부적인 rsynhc에 대한 내용은

HOWTO를 참고하기 바란다.

2차 백업을 좀더 효율적으로 하기 위해서는 데이터 서버에 이더넷 카드를 2장 설치하여

eth0 은 일반 서비스로 이용하고 eth1은 사설 IP를 할당하여 백업서버와 Direct 로 연결

하여 백업시 이용하는 방법도 있다. 이 경우에는 2차 백업시 별도의 이더넷 카드로 전송

이 되므로 백업 작업시 발생하는 이더넷 카드에서의 트래픽이 서비스에 영향을 주지 않

아 병목현상을 피할수 있고, 사설 IP를 이용하므로 백업서버의 보안도 일정 정도 강화할

수 있다.

단, 이러할 경우 백업서버는 데이터서버와 근거리에 위치하여야 하고, 사설 IP를 할당하

므로써 백업서버에 직접 접근시 사설 IP로 접근하여야 하는 단점이 있기는 하다.

4. 백업 복구 방법

이제 어렵게 백업한 파일을 복구할 필요가 생기게 되었다.

백업 파일로부터의 복구방법은 그리 복잡하지 않은데, 복구시에는 백업때와는 달리 c 옵

션대신 eXtract 의 의미인 x를 사용하는 것만 주의하면 된다.

예를 들어보면,

tar zxvpf /backup/etc.tar.gz 와 같이 할 경우 현재의 디렉토리에

압축된 파일에 들어있는 모든 파일을 복구하며 p옵션을 주었으므로 원래 파일의 소유자

와 퍼미션도 그대로 복구된다.

백업 파일에 있는 모든 파일을 복구하는 것이 아니라 특정 디렉토리나 파일에 대해서만

복구하려면 아래와 같이 하면 된다.

tar zxvpf /backup/home.tar.gz etc/passwd home/tt/public_html

현재의 디렉토리가 /home/user 라면 위와같은 경우 현재의 디렉토리에 원래

의 /etc/passwd 파일이 /home/user/etc/passwd 파일로 복원이 되고 원래

의 /home/tt/public_html 이하의 파일들이 /home/user/home/tt/public_html 로 복원

되는 것이다. 특정 파일을 지정할 경우에는 특정파일이 복구되고, 디렉토리를 지정할 경

우에는 디렉토리 이하의 디렉토리 및 파일들이 복원된다. 이때 주의할 점은 백업이 풀릴

파일을 지정시 /etc/passwd 와 같이 원래의 절대경로를 설정하면 백업에서 풀리면서 현

재의 설정 파일에 백업본이 그대로 overwrite를 되므로 주의하여야 한다는 점이다. 따라

서 복구시 / 를 입력하지 않는다.

5. 백업 및 복구시 주의점.

(1) 데이터의 변화주기 및 경중을 고려하여 백업주기를 다르게 설정한다.

백업할 데이터가 홈페이지 관련 데이터일 경우 일반적인 HTML 이나 관련 GIF등의 이미

지 파일들은 자주 변경이 되지는 않으며 주로 작업자의 PC에서 작업후 서버에 업로드를

하므로 작업자의 PC에 저장되어 있는 경우가 많다. 그러므로 이의 데이터들은 매일 또

는 수시로 백업을 받을 필요는 없으며 변경된 내용만을 백업하거나 일정주기마다 백업

을 하면 된다. 그리고 백업이 동작시 일반 데이터뿐만 아니라 zip 이나 asf 또는 mpeg 등

과 같이 파일자체가 압축되어 있는 형식의 경우에는 파일자체의 사이즈가 크고 백업시

많은 부하를 유발하게 되므로 이러한 파일의 경우에는 꼭 백업할 필요가 없다면 데이터

의 경중을 고려하여 백업에서 제외하거나 백업일정을 적당히 조정할 필요가 있다.

요즘은 회원제 운영이 보편화되면서 대부분의 홈페이지에서 각종 데이터베이스를 연동

하여 사용하는 경우가 많은데, 데이터 베이스의 경우 회원의 ID / PW 등의 각종 회원 데

이터가 보관되고 정보가 자주 변경되므로 수시로 백업을 할 필요가 있다.

각 데이터베이스 프로그램의 경우 별도의 백업 명령어(msqldump., mysqldump등) 가

있으므로 tar 가 아닌 dump 명령어를 이용하는 것도 권장할 만 한다.

(2) 1차 백업시 백업 파티션은 별도의 디스크로 구성한다.

시스템 인스톨시 하나의 물리적인 디스크를 여러 파티션으로 논리 분할하여 이용하는

경우가 많은데, 이때 백업 파티션의 경우에는 반드시 별도의 물리적인 파티션 분할을 이

용하여 별도로 디스크를 구성하는 것이 중요하다. 이는 만약 데이터가 보관된 하드 디스

크가 물리적인 결함으로 복구가 불가능할 경우 이 디스크에 있던 데이터는 물론이고 복

구시 필요한 백업까지도 함께 복구가 불가능하여 백업으로서의 의미가 상실되기 때문이

다.

일반적인 데이터는 빠른 연산이 필요하므로 SCSI 를 이용하고 백업디스크는 비용부담

이 적은 고용량의 IDE 방식도 무난하다.

(3) 백업된 데이터에 대한 보안설정도 중요하다.

일반적으로 백업 스크립트는 root 소유로 작동하므로 백업된 파일이 생성될 때에는 root

소유로 백업 화일이 생성된다. 그러나 일반적으로 umask 는 022 로 설정되어 있으므로

생성된 백업파일은 644로 저장된다. 644일 경우 아래와 같이 일반 사용자가 백업된 파일

에 접근하여 심지어는 접근이 불가능한 shadow 파일에도 접근이 가능하게 되어 보안상

문제가 될 수 있다.

따라서 백업 파티션을 별도로 구성하여 백업이 끝난 후에는 반드시 백업 파티션을

umount하여 일반 사용자가 접근할 수 없도록 하고 백업을 시작하기 전에 mount를 하면

될 것이다. 또는 생성된 파일의 권한을 700 정도로 제한하여도 된다. 그리고 백업작업 중

간에 일반 사용자가 백업 파일을 복사할 수도 있으므로 백업시작 스크립트에 umask를

066으로 설정하여 생성되는 파일의 소유권을 600 으로 하고 백업이 끝난후에 umask를

다시 022로 재설정하여 일반 사용자의 비정상적인 접근을 차단할 수 있다.

[user@www user]$id

uid=500(user) gid=500(user)

[user @www user]$ cat /etc/shadow

cat: /etc/shadow: 허가 거부됨

[user@www user]$ ls -la /backup/etc.tar.gz

-rw-r–r–   1 root  root    954039 12월 12 04:22 /backup/etc.tar.gz

[user@www user]$ cp /backup/etc.tar.gz .

[user@www user]$ tar zxvfp etc.tar.gz etc/shadow

etc/shadow

[user@www user]$ cat etc/shadow

root:$1$V.120Zso3$cD/aUqQr2EBY0:11295:0:99999:7:-1:-1:134540356

bin:*:11266:0:99999:7:::

daemon:*:11266:0:99999:7:::                      

(4) 2차, 3차 백업서버는 가급적 네트워크에서 격리할 필요가 있다.

만약 1차 백업이 되고 있는 데이터 서버가 해킹을 당해 데이터가 유실되었다면 2차나 3

차 백업이 되고 있는 서버의 데이터로 복원을 하여야 한다. 그런데, 만약 2차,3차 백업서

버도 기존의 서버와 같은 설정으로 되어 있어 같은 방식으로 해킹을 당해 데이터가 유실

되었다면? 해결책이 없는 것이다. 따라서 최후의 보루라 할 수 있는 2차,3차 백업 서버는

기존의 서버와 환경설정을 다르게 하고 관리자 암호등 접근권한도 다르게 설정 할 필요

가 있다.

그리고 백업서버는 일체의 제공 서비스 없이 백업만을 담당하므로 불필요한 서비스는 띄

워놓을 필요가 없으며 백업이 작동할 때 이외에는 네트워크에 연결되어 있을 필요가 거

의 없으므로 백업이 끝난 후에는 네트워크에서 격리할 필요가 있는데, 이는 ipchains 등

을 이용하여 자체 방화벽을 구성하여 외부에서의 접근을 일체 차단할 수도 있겠지만 다

음과 같이 아예 네트워크에서 격리를 할 수도 있다.

백업 시작전 : /etc/rc.d/init.d/network start 로 Netwok 연결

백업 종료후 : /etc/rc.d/init.d/network stop 로 Network 차단.

2차,3차 백업서버는 네트워크에서의 격리뿐만 아니라 물리적으로도 격리 할 필요가 있

다.

화재나 천재지변등 피치 못할 사정으로 사고 발생시 백업서버가 원 DATA가 위치한 서버

와 공동으로 위치할 경우 돌이킬 수 없는 문제가 벌생할 수 있으므로 가능한대로 백업 서

버는 다른 건물로, 같은 건물의 경우라면 다른층에 위치하는 것이 좋다.

부득이 같은 층에 있다면 멀리 위치시켜 예기치 못한 서고의 가능성을 분산시키는 것이

필요하다.

(5) 백업 담당자를 지정, 운영한다.

보안담당자도 없는데 백업담당자가 필요하겠냐고 생각할 수 있겠지만, 전담자까지는 없

더라도 담당자는 지정을 하여 정기적으로 체크를 함으로써 보다 책임성 있고 신뢰성 있

는 백업체계를 유지할 필요가 있다. 백업이 되고 있는줄 알고 복구를 할 일이 있어 백업

서버를 살펴 보니 corn 데몬이 죽어 있다거나 설정한 스크립트가 실행권한이 없어 실행

이 되고 있지 않는 경우도 있으니 백업 담당자가 수시로 체크를 하여야 한다. 백업 체크

일지를 두거나 정기적으로 체크하는 스크립트를 만들어 자동으로 체크여부를 알려주는

것도 좋은 방법이 될 것이다.

(6) tar 이외 cp를 이용하는 방법도 고려할 만 하다.

TAR를 이용하여 Packing 이나 압축없이 cp를 이용하는 방법도 있는데,

이는 일주일에 1회정도

cp -ap /etc /backup/ 와 같이 /etc 디렉토리 전체를 풀복사한후

cp -aufp /etc/ /backup/etc/ 로 풀복사 이후 새롭게 생성이나 변경, 수정된 파일이나

디렉토리만 복사하는 방법도 있다.

(7) 라우터와 스위칭의 설정파일도 백업을 잊지 않는다.

서버뿐만이 아니라 라우터와 스위칭의 Configuration File 도 설정 변경시 백업을 할 필요

가 있다. 특히 라우터나 스위칭의 경우 설정 변경시 원치 않던 설정까지 변경되는 경우가

있고 라우터의 장애시에는 라우터 밑단에 연결되어 있는 모든 네트워크가 영향을 받으므

로 반드시 백업을 받아둘 필요가 있다. 다만 설정이 자주 변경되지는 않으므로 정기적으

로 백업을 할 필요는 없고, 설정이 변경될 때만 그때 그때마다 설정파일을 Copy &

Paste 로 복사를 해 두면 된다.