8.4. Red Hat Enterprise Linux 관련 정보

8.4.2.1. tar

tar 유틸리티는 UNIX 시스템 관리자들이 자주 사용하는 도구로서, 소스 코드와 파일을 시스템 간에 공유하는데 인기있게 사용되는 아카이빙 방식입니다. Red Hat Enterprise Linux에서 구현된 tar는 가장 많은 기능을 제공하는 tar 구현 방식 중 하나인 GNU tar입니다.

tar를 이용하여 다음과 같이 간단하게 명령 하나 만으로도 전체 디렉토리 내용을 백업할 수 있습니다:

tar cf /mnt/backup/home-backup.tar /home/

이 명령은 /mnt/backup/ 디렉토리에 home-backup.tar라는 아카이브 파일을 생성합니다. 이 아카이브 파일에는 /home/ 디렉토리 내용이 포함되어 있습니다.

아카이브 파일 용량은 백업되는 데이터 용량과 거의 비슷합니다. 백업되는 데이터의 유형에 따라서 아카이브 파일을 압축하게되면 용량을 크게 줄일 수 있습니다. 아카이브 파일을 압축하시려면 이전 명령에 다음과 같은 옵션 하나만 추가하시면 됩니다:

tar czf /mnt/backup/home-backup.tar.gz /home/

home-backup.tar.gz 아카이브 파일은 이제 gzip을 이용하여 압축되었습니다[1]

tar와 함께 사용할 수 있는 옵션은 다양합니다. 보다 자세한 내용은 tar(1) 맨페이지를 참조하시기 바랍니다.

8.4.2.2. cpio

cpio 유틸리티는 또 다른 유닉스 프로그램입니다. 데이터를 한 장소에서 다른 장소로 이동시키는데 기능을 하며 백업 프로그램으로 유용하게 사용 가능합니다.

cpio의 작업 방식은 tar와는 약간 차이가 있습니다. tar와는 달리 cpio는 처리할 파일 이름을 표준 입력으로 읽어들입니다. 따라서 cpio에 사용될 파일 목록을 생성하기 위해서는 일반적으로 다음과 같이 find 명령을 사용하여 그 출력 결과를 파이프를 사용하여 다시 cpio 명령의 표준 입력으로 이용합니다:

find /home/ | cpio -o > /mnt/backup/home-backup.cpio

이 명령은 /mnt/backup/ 디렉토리에 /home/ 디렉토리의 내용을 담은 home-backup.cpio이라는 cpio 아카이브 파일을 생성합니다.

	힌트
	find는 다양한 파일 선택 기능을 제공하므로 보다 쉽게 복잡한 백업을 생성하는 것도 가능합니다. 예를 들어 다음 명령을 입력하시면 작년에 액세스되지 않은 파일만 백업합니다:

find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio
            

cpio와 find와 사용 가능한 옵션은 다양합니다. 보다 자세한 정보는 cpio(1) 맨페이지와 find(1) 맨페이지를 참조하시기 바랍니다.

8.4.2.3. dump/restore: 마운트된 파일 시스템에서는 사용하지 마십시오!

dump와 restore 프로그램은 같은 이름을 가진 유닉스 프로그램와 동등한 리눅스 프로그램입니다. 따라서 유닉스 경력이 있는 시스템 관리자 분들은 Red Hat Enterprise Linux에서 dump와 restore를 백업 프로그램으로 사용하시길 선호하십시나. 그러나 dump 프로그램을 사용하실때에는 한가지 주의하실 사항이 있습니다. 다음은 이 문제에 대한 리눅스 토발즈의 설명입니다:

From:	 Linus Torvalds
To:	 Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc:	 Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 


Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
Russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

		Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.

이러한 문제로 인해, 마운트된 파일 시스템에서는 dump/restore를 사용하지 마시기 바랍니다. dump는 애초에 마운트되지 않은 파일 시스템을 백업하도록 개발되었습니다. 따라서 umount 명령을 이용하여 파일 시스템을 마운트 해제한 상태에서는 dump는 훌륭한 백업 기술이라 할 수 있습니다.

8.4.2.4. AMANDA (Advanced Maryland Automatic Network Disk Archiver)

AMANDA는 메릴랜드 대학에서 개발된 클라이언트/서버 기반 백업 프로그램입니다. 클라이언트/서버 아키텍쳐를 이용하여 한개의 백업 서버로도 다양한 클라이언트 시스템을 백업 가능합니다. 서버는 상대적으로 여유 공간이 많고 속도가 빠른 디스크를 갖춘 강력한 시스템에 원하시는 백업 장치를 설정하시면 됩니다. 클라이언트 시스템에는 AMANDA 클라이언트 소프트웨어만 설치하시면 됩니다.

이 방법을 사용하면 한개의 시스템에 백업에 필요한 모든 자원을 모여 있으므로 백업 서비스가 필요한 모든 시스템에 추가 하드웨어를 둘 필요가 없습니다. AMANDA는 또한 백업 관리 작업을 중앙 집중식으로 처리하므로 시스템 관리자의 작업이 훨씬 수월해집니다.

AMANDA 서버는 시스템 관리자가 지정간 주기에 맞추어 여러 백업 매체를 교체하여 사용합니다. 모든 매체는 AMANDA가 적절한 매체가 준비되었는지 탐지 가능하게 해주는 데이터로 미리 포맷되어 있습니다. 또한 AMANDA에는 매체를 자동으로 바꾸어주는 로봇 유닛이 갖추어져, 완전한 자동 백업 작업을 수행 가능합니다.

AMANDA는 실제 백업 작업에 tar이나 dump를 사용합니다. (dump raised in 8.4.2.3 절에서 설명된 dump 관련 문제점으로 인해, Red Hat Enterprise Linux에서는 tar 사용이 권장됩니다). 따라서 AMANDA으로 백업한 파일은 AMANDA가 없이도 복구 가능합니다.

AMANDA는 보통 데이터 센터의 백업 스케쥴에 맞추어 하루에 한번 정도 실행되도록 설정됩니다. AMANDA 서버는 클라이언트 시스템에 접속하여 클라이언트로 하여금 백업해야할 예상 용량을 보고하도록 지시합니다. 모든 용량 정보가 모이면, 서버는 스케쥴을 잡고 어느 시스템을 먼저 백업할 것인지 자동으로 순서를 결정합니다.

실제 백업 작업이 시작되면, 클아이언트에서 서버 상 디스크로 네트워크를 통해 데이터가 보내집니다. 일단 백업 작업을 마치면, 서버는 디스크에서 백업 매체로 자료를 쓰기 시작합니다. 동시에 다른 클라이언트는 자신의 백업을 서버의 디스크로 보내기 시작합니다. 따라서 계속적으로 백업 매체에 데이터를 쓰기 가능합니다. 데이터가 백업 매체에 쓰여지는 즉시 서버의 디스크에서 삭제됩니다.

모든 백업이 완료되면 시스템 관리자가 쉽고 빠르게 백업 현황을 볼 수 있도록 이메일로 리포트를 보내줍니다.

데이터를 복구해야할 경우 AMANDA는 파일 시스템, 날짜, 파일 이름을 확인할 수 있는 프로그램이 있습니다. 파일 검색을 마치면, AMANDA는 올바른 백업 매체를 찾아 원하는 데이터를 검색한 후 복구합니다. 앞서 설명했듯이 AMANDA는 AMANDA를 이용하지 않고서도 파일을 복구할 수 있도록 설계되었습니다. 따라서 올바른 매체를 찾아 수동으로 복구하는데 시간은 조금 더 걸리더라도 AMANDA 없이도 파일을 복구 가능하다는 큰 장점이 있습니다.AMANDA AMANDAf

여기까지 AMANDA에 대한 가장 기본적인 내용을 다루어 보았습니다. AMANDA에 대한 보다 상세한 정보를 원하신다면, amanda(8) 맨페이지를 참조하시기 바랍니다.