한빛출판네트워크

제공: 한빛 네트워크
저자: Paddy Sreenivasan, 이상화 역
원문: http://www.oreillynet.com/pub/a/databases/2006/07/13/lamp-data-protection.html

LAMP 애플리케이션을 기반으로 하는 웹, 기업용 애플리케이션이 점점 성장추세에 있다. LAMP 애플리케이션이란 L (Linux 혹은 BSD 기반 운영체제) , A (Apache 웹서버), M (DBMS로 MySQL 혹은 PostgreSQL을 사용), P (개발 언어로 PHP, Perl 혹은 Python )로 이루어진 OPEN 기반의 구조를 말하며 미들웨어로 JBoss를 사용하기도 한다. 이러한 계층구조는 다음과 같은 공통적인 속성을 지닌다.

• 오픈소스 기반이기 때문에 많은 커뮤니티와 개발자들이 포진해 있다.
• 이기종간의 플랫폼에서 사용 가능하며 매우 통합이 잘되어 있다.

종종 LAMP 애플리케이션에서 간과하는 부분이 애플리케이션 데이터 보호와 환경설정 데이터 보호에 관한 부분이었다. 이 기사에서는 LAMP 애플리케이션 데이터를 보호 하기 위해 오픈소스 툴을 이용하는 방법에 대해 설명하고 있다. 애플리케이션 보안과 LAMP 애플리케이션 서버의 보안 문제는 이 기사에서는 다루지 않는다. 또한 실제로 적용 전에 데이터복구 시나리오를 반드시 테스트 해보는 것이 좋다.

1. LAMP 애플리케이션 데이터 특성들

데이터 보호 관점으로 부터 LAMP 애플리케이션과 환경설정 파일의 주요한 특성들 중 하나는 파일시스템, MySQL 혹은 PostgreSQL이 같은 곳에 존재 한다는 것이다. 아파치 환경설정 파일은 보통 /etc/httpd/ 디렉토리에, PHP 환경설정 파일은 보통 /etc/php/에 위치한다. MySQL, PostgreSQL 데이터, 인덱스, 환경설정 파일들 또한 일반적으로 파일시스템에 존재한다. 또다른 LAMP 애플리케이션의 특성은 많은 서버들에 분산되어 있다는 점이다. 분산된 LAMP 애플리케이션 서버는 일반적으로 가용성과 확장성을 보장 한다. 기업용 애플리케이션과 웹 애플리케이션은 고가용성을 요구하며 복구를 위한 최소한의 장애시간을 보장 받기를 원한다.

이러한 LAMP 애플리케이션의 특성들은 주기적인 백업을 어렵게 만든다. 시스템 관리자는 전체 LAMP 애플리케이션 계층의 데이터 일관성을 확보하기 위해 LAMP 애플리케이션의 모든 계층안에 있는 데이터에 관심을 기울일 필요성을 느끼게 된다.


그림1. LAMP 애플리케이션과 데이터

데이터 보호 솔루션의 종류는 애플리케이션 성능, 애플리케이션 가용성, 복구해야 할 장애의 종류, 솔루션의 비용 문제들과 관련되어 있다. 데이터를 백업하기 위한 주요한 요구사항의 하나는 필요한 데이터 일관성의 수준과 상관 있다. 여기에는 데이터 일관성의 두 개의 수준이 존재한다.

• 애플리케이션 일관성 : 백업된 데이터는 완벽한 일관성을 가지고 있어야 한다. 즉, 백업된 데이터를 복구 한 후에 애플리케이션은 어떠한 내부의 복구 작업이 필요 없어야 한다.
• Crash 일관성 : 백업된 데이터는 애플리케이션 장애 혹은 비정상적으로 종료 되었을 경우 저장 공간에 있는 데이터와 동일해야 한다. 데이터 복구 후에 애플리케이션은 내부적인 복구작업이 필요하다.

매우 적은 수의 애플리케이션만이 일시적인 I/O 장애에 대해 복구 능력을 가지고 있다. 데이터베이스 서버는 그러한 능력을 가지고 있어야 한다.

백업에 대한 복구는 보통 운영자의 실수, 디스크/파일시스템 장애, 버그에 의한 애플리케이션 데이터 변질, 애플리케이션 호스트 장애 때문에 종종 발생한다. 당신이 선택한 데이터 보호 솔루션은 장애 대해 무엇을 복구 할 것인가와 얼마나 빠른 시간에 데이터를 복구할 수 있는가와 같은 문제에 달려있다.

2. 일관성(Consistent)있는 MySQL 백업

MySQL은 DB를 백업하기 위한 두 가지 도구를 제공한다. 이러한 도구들은 오픈소스이며 MySQL 배포본에 포함되어 있다. mysqldump는 논리적 백업을 수행하고 mysqlhotcopy는 물리적 백업을 수행한다. 논리적 백업본은 데이터베이스 데이터를 재생성하기위한 MySQL 문을 포함하고 있으며 물리적 백업본은 데이터베이스 데이터, 인덱스, 그리고 로그를 가지고 있다. 두 개의 툴은 동일한 시간 또는 동일한 일관성 측면에서 모든 테이블을 백업하지 않기 때문에 참조 무결성을 보장하지는 않는다.

MySQL을 백업하기 위한 도구는 DB내 테이블에 의해 사용되는 스토리지 엔진(storage engine)에 의존한다. InnoDB, BDB, Solid 그리고 미래의 Falcon을 포함하는 트랜잭션을 보장하는 스토리지 엔진은 데이터베이스 애플리케이션 가용성에 영향을 미치지 않으면서 백업을 수행할 수 있다. 이러한 백업들은 보통 hot 또는 live 백업이라고 한다. 트랜잭션을 지원하지 않는 MyISAM, ARCHIVE, MERGE와 같은 스토리지 엔진들은 디스크에 로그를 남기던 활성 데이터베이스를 플러싱(flushing)하거나 읽기 락(lock)을 획득해야 한다.

mysqldump를 이용한 논리적 풀(full) 백업

논리적인 백업은 데이터베이스, 테이블 재생성을 하기 위해 CREATE TABLE, INSERT INTO와 같은 SQL 문장으로 이루어져 있다. mysqldump 툴은 MySQL 데이터베이스의 논리적 백업본 또는 모든 스토리지 엔진을 위한 테이블을 생성한다. 필요한 명령어 옵션은 스토리지 엔진의 트랜잭션 지원여부에 따라 달라진다.

mysqldump [options] db_name [tables]

mysqldump [options] --databases db_name1 [db_name2 db_name3...]

mysqldump [options] --all-databases

mysqldump의 일반적인 옵션은 --opt와 --extended-insert 이다. 이 옵션은 최적화된 SQL 문장을 생성시키며 복구 작업과 적은 수의 파일을 백업할 때 속도를 향상시킨다. --opt 옵션은 정확한 DDL 문장(CREATE TABLE)을 생성하는데 필요하다. --lock-all-tables 과 --flush-logs 옵션은 데이터베이스의 모든 테이블에 lock을 걸거나 데이터를 flush 시킨다. 모든 대기중인 트랜잭션은 커밋되어 버린다. 이러한 옵션들은 MyISAM, ARCHIVE, MERGE과 같은 트랜잭션을 지원하지 않는 스토리지 엔진을 위해 필요한 선택사항들이다. 백업 진행 도중에 활성화된 데이터베이스내의 모든 테이블의 읽기 lock을 획득하는 것은 좋은 방법은 아니다.

만약 데이터 일관성을 위해 복제의 방법이나 스냅샷을 이용한다면 모든 테이블에 읽기 lock을 걸거나 log를 flush 시킬 필요가 없게 된다. --single-transaction 옵션은 InnoDB와 BDB 같은 트랜잭션을 지원하는 스토리지 엔진을 위한 일관성을 보장하는 백업 본을 생성하게 한다. lock-all-tables option 또는 the single-transaction 옵션도 사용된다. --master-data=2 는 이진의 로그파일명을 작성하고 백업 출력 위치를 지정할 수 있다. 이것은 특정 시점의 복구를 가능케 한다.

예를 들어 MyISAM 테이블을 포함하는 전체 데이터 베이스를 백업 받으려면 다음과 같다.

mysqldump --opt --extended-insert --lock-all-tables --flush-logs
--routines --triggers --master-data=2 --all-databases

논리적 백업의 장점은 다른 데이터베이스 서버로 데이터 이관이 가능하다는 점이다. 논리적 백업은 서버 구조와 파일시스템에 무관하기 때문이다. 또한 논리적 백업본으로 부터 DROP TABLE 문장과 같은 관리자의 실수도 복구할 수 있다. 이것은 물리적(raw) 백업에 비교하여 가장 중요한 장점이다.

mysqldump는 MySQL 서버뿐만 아니라 다른 서버에서도 실행시킬 수 있다. 논리적 백업의 단점이라면 백업본의 크기가 실제의 데이터베이스 크기보다 커진다는 것이다. 또한 논리적 백업본 내의 모든 SQL 문장들이 복구 프로세스에 의해서 재실행되어야 하기 때문에 복구 시간이 문제될 수 있다.

mysqlhotcopy를 사용한 물리적(RAW) 백업

물리적 백업은 이진 형식의 데이터베이스로 구성되어 있으며 서버의 구조에 따라 달라질 수 있다. mysqlhotcopy 명령은 데이터, 인덱스, 데이터 사전 파일을 동일 서버 혹은 원격의 서버로 복사하는 Perl 스크립트로 되어있다. 이 명령의 장점은 MySQL이 데이터베이스 테이블 데이터, 인덱스, DBA로 부터 설정된 데이터 디렉토리에 존재하는 로그 파일들을 저장할 수 있다는 사실에 있다. mysqlhotcopy 명령은 트랜잭션을 지원하지 않는 스토리지 엔진을 위해서만 작동 되며 트랜잭션을 지원하는 스토리지 엔진은 관련된 테이블이 데이터베이스 데이터 디렉토리에 저장되어 있지 않으므로 작동되지 않는다.

이 명령은 테이블/데이터베이스에 대해 읽기 lock을 획득하며 백업하는 동안 데이터베이스를 디스크로 내리는 작업을 한다.

mysqlhotcopy --flushlog db_name_1 ... db_name_n /path/to/new_directory

물리적 백업본으로 부터 복구 작업은 논리적 백업같이 SQL 문장을 실행시키지 않으므로 좀더 빠르다. raw 백업본의 크기는 데이터베이스 데이터, 로그의 크기와 동일하다. 하지만 raw 백업은 앞서 말한 관리자의 실수를 복구하기 힘들다.

대부분의 트랜잭션을 지원하는 엔진은 물리적 백업본을 생성할 수 있는 명령을 지원한다. SOLID 스토리지 엔진은 이진 백업을 할 수 있는 백업 명령어를 가지고 있으며 InnoDB는 테이블을 물리적 백업할 수 있는 상업적인 도구(ibbackup)를 지원한다. InniDB는 또한 테이블, 데이터 사전, mysqldump명령을 사용하는 MyISAM을 백업할 수 있는 innobackup 스크립트를 제공하고 있다.

증분(Incremental) 백업

MySQL 서버는 모든 이벤트(MySQL 문장들) 또는 갱신된 모든 정보를 가지고 있는 이진 로그들을 가질 수 있다. 이진방식으로 로깅하는 것은 증분가능한 MySQL 백업본이 만들어 진다. 이진 로그는 데이터베이스내 모든 데이터의 변경사항을 추적하고 데이터베이스를 복원하기 위해 재현이 가능하다. 그러나 이러한 데이터베이스 로깅 방법은 성능을 저하시킬 수 있다.

성능 감소를 최소화하기 위해서 MySQL의 데이터 디렉토리와 다른 위치에 이진 로그를 넣을 수 있도록 환경 설정을 할 수 있다 이것은 가용성을 증가시킬 수 있다. 다음과 같은 명령어로 이진 로그를 활성화 시킬 수 있다.

# mysqld --log-bin=backup_logs

MySQL은 서버가 재시작할 때 이진 로그들을 순환시키거나 mysqladmin flush-logs 사용하여 수동으로 로그들을 순환 시킴으로서 증분 백업의 마지막 위치를 기록할 수 있다.

3. 스냅샷을 사용한 데이터 일관성

MySQL 데이터베이스 데이터 디렉토리를 논리적 볼륨 매니저(LVM)이나 엔터프라이즈 볼륨 관리 시스템(EVMS)를 이용하여 논리적인 볼륨에 저장할 수 있다. 데이터나 인덱스파일을 저장하기 위해 논리적인 볼륨을 이용하는 것은 물리적인 디스크의 제약을 뛰어 넘을 수 있다. (동일하게 파일시스템 growfs 명령어를 사용하여 파일시스템을 추가할 수 있다.)

미러링된 논리적인 볼륨은 가용성을 향상 시키며 LVM, EVMS 둘다 논리적인 볼륨의 내용을 다른 논리적인 볼륨으로 스냅샷을 만들수 있는 기능을 가지고 있다. 스냅샷 볼륨은 copy-on-wirte(COW) 볼륨이기 때문에 원본 볼륨의 데이터 블록이 변경되면 스냅샷의 내용도 덮여 쓰여지게 된다.

데이터베이스의 일관성있는 복제본을 생성하려면 먼저 MySQL 데이터베이스 데이터 디렉토리를 포함하고 있는 논리적인 볼륨의 스냅샷을 생성해야 한다. 스냅샷을 생성하기 전에 읽기 잠금을 미리 획득 하며 테이블의 내용을 비우는 작업이 필요하다. 읽기 잠금을 획득하기 위해서 운영중인 데이터베이스에서 약간의 시간이 소요된다. 스냡샷 자체가 copy-on-wirte(COW) 볼륨 이기 때문에 스냅샷 작업은 오랜 시간이 소요되지는 않는다. 스냅샷 작업 이후에 읽기 잠금이 풀리게 되며 백업 프로세스 동안에는 다시 잠기지는 않는다. 트랜잭션이 가능한 스토리지 엔진에서는 읽기 잠금이 필요하지는 않다. 백업 복사본을 복원할 때 데이터베이스는 트랜잭션 로그의 내용을 바탕으로 변경작업을 반영한다. 트랜잭션이 가능한 스토리지 엔진에서 읽기 잠금을 획득하려면 모든 진행중인 트랜잭션이 커밋 되어야 하며 이는 성능에 커다란 영향을 미치게 될 것이다.

다음은 스냅샷을 이용한 작업이다.

1. 데이터베이스에서 읽기 잠금을 획득하고 로그를 모두 비운다. 이단계는 만약 데이터베이스가 트랜잭션 가능한 스토리지 엔진이 아닐 경우 혹은 특정한 테이블만 백업 받을 경우 반드시 필요한 단계이다.

   mysql> FLUSH TABLES WITH READ LOCK
   

2. 데이터 베이스 데이터 디렉토리가 존재하는 논리적인 볼륨(다음의 예에서는 /dev/mysqlvolume)을 위한 스냅샷을 생성한다. 다음 LVM 명령어는 50MB 크기의 스냅샷 볼륨 mysqlbackup을 생성한다. 보통 스냅샷의 크기는 원본의 15% ~ 20% 내외 이다. 만약 데이터베이스가 운영중이라면 좀더 큰 볼륨 크기를 필요로 할것이다.

   # lvcreate -L50M -s -n mysqlbackup /dev/mysqlvolume
   

3. 1단계에서 획득하였던 읽기 잠금을 해제한다.

   mysql> UNLOCK TABLES
   

4. 다른 디렉토리로 스냡샷 볼륨을 마운트 한다.

   # mount /dev/mysqlbackup /backup
   

5. 네트워크 기반의 백업 명령을 이용하여 /backup의 데이터베이스 백업 파일과 애플리케이션을 테이프, 디스크, 광학 장치와 같은 백업 장치로 백업 받는다.
6. 스냅샷의 논리적인 볼륨을 제거한다.

   # lvremove -f /dev/mysqlbackup
   

   LVM대신에 EVMS를 사용하는 것은 부가적인 장점을 제공하고 백업 절차를 좀더 손쉽게 만든다. EVMS는 스냅샷 볼륨을 늘릴 수 있다. 이것은 초기 스냅샷의 사이즈가 적을 경우에 유용하다.
   
   EVMS는 영구적인 스냅샷 볼륨도 만들수 있다. 단계 1에서 다시 초기화시키고 백업의 마지막 단계에서 스냅샷을 제거하지 않는다. 스냅샷 볼륨은 데이터 백업본처럼 사용되며 스냅샷 롤백도 빠른 복원 매커니즘이다.
   
   데이터 스냅샷을 통해 파일 시스템을 동결하거나 푸는 작업을 사용하는 것은 데이터베이스와 애플리케이션 파일을 위한 좀더 나은 데이터 일관성을 제공한다. 데이터베이스와 애플리케이션 파일의 일관성있는 뷰를 얻기 위해서 LVM 스냅샷과 연동하는 XFS, GFS와 같은 파일시스템의 특징이다.
   
   만약 파일 시스템을 동결하려면 2단계 전에 수행하고 2단계 이후에 풀어야 한다. LAMP 애플리케이션과 파일 시스템 데이터를 위해 ext2fs 파일시스템을 사용하고자 한다면 메타데이터 저널링(journaling)을 활성화시켜야 하며 동결 작업을 건너 뛰어야 한다.
   
   백업을 위한 선행 작업으로 /var/lib/mysql XFS 파일시스템을 동결시키려면

   # xfs_freeze -f  /var/lib/mysql
   

   XFS 파일시스템의 동결을 풀려면

   # xfs_freeze -u /var/lib/mysql
   

4. 리플레케이션(replication)을 사용한 데이터 일관성

MySQL은 마스터 서버에 대한 복제 슬레이브(slave)를 생성할 수 있다. 마스터 서버는 슬레이브를 다중 생성할 수 있고 복제된 서버는 마스터 서버의 역할을 할 수 있다 마스터 서버에서 실행되는 모든 트랜잭션은 슬레이브 서버에서 비동기적으로 재현되어 진다. MySQL 명령어들은 실행을 위해 슬레이브 서버로 보내어 진다. 만약 MySQL 명령어를 수행하는데 느려지면 슬레이브 서버는 마스터의 뒷편에서 복제 서버가 된다.

MySQL 5.1은 열단위(row-based) 복제를 지원한다. 마스터 서버는 테이블 열들이 각각의 문장(statement)들에 의해 어떻게 영향을 받는지 알려주는 이진 로그를 생성하며 슬레이브로 이진 로그를 복제한다. 열단위 복제는 저장되어 있는 루틴과 트리거, 함수의 복제를 수행 할 수 있다. 문장 단위의 복제는 로그를 좀더 작게 만들고 감사(audit)를 쉽게 한다.

MySQL 5.1에는 "혼합된" 복제 방법들이 존재한다. 기본적으로 문장 단위의 복제를 하면서 함수(function)를 사용하는 MySQL 문장을 위한 열 단위 복제 방법을 통해 마스터 서버와 슬레이브 서버에서 실행되어질 때 서로 다른 결과를 줄 수 있게 하는 것이다.

복제는 종종 고가용성이나 로드밸런싱을 위해 사용되어지나 백업의 목적도 있다. 복제된 슬레이브 서버는 데이터베이스 일관성을 가지고는 있지만 이전에 설명한 백업 명령어들로 백업을 받아야 한다.

백업을 위한 복제된 슬레이브 서버가 있다고 가정하고 다음과 같이 백업한다.

1. 슬레이브를 중지 시키고 복제가 중단되었는지 슬레이브 상태를 점검한다.

   mysql> STOP SLAVE;
   

2. 마스터 로그파일과 위치를 확인한다.

   mysql> SHOW SLAVE STATUS;
   

3. 이전에 설명한 MySQL 백업을 수행한다.
4. 2 단계에서 확인한 값을 사용하여 CHANGE MASTER MySQL 문장을 백업 파일에 더한다. 이단계는 마스터 로그파일과 로그파일의 위치를 저장하기 위한 단계이며 이것은 복구 작업을 좀더 쉽게 만들어 준다.
5. 디스크, 테이프 다른 미디어와 같은 곳으로 데이터베이스 파일, 애플리케이션 파일을 백업하기 위해 아만다(Amanda)를 사용한다.
6. 슬레이브를 재시작한다.

   mysql> START SLAVE;
   

복제를 사용한 백업은 사용자의 실수 또한 복제의 일부분이기 때문에 에러에 대한 복원을 보장하지는 않는다. 복제 솔루션은 스냅샷 솔루션보다 추가적인 MySQL 호스트를 필요로 하기 때문에 비용이 비싸지만 가용성과 로드 밸런싱 측면에서 복제를 사용한다면 백업을 좀더 쉽게 수행할 수 있다.

5. PostgreSQL 백업

PostgreSQL은 다양한 버전의 동시성(concurrency) 제어를 제공한다. 다양한 버전의 동시성 제어는 일관성있는 데이터베이스 백업을 좀더 쉽게 만든다. 스냅샷은 물론 가능하며 이것은 PostgreSQL 서버가 장애시 복구할 수 있다는 것을 의미한다.

논리적 백업

두 개의 명령어 pg_dump와 pg_dumpall를 통해 논리적 백업을 생성한다. 파일시스템의 한계 때문에 파일 크기 제한을 피하기 위해 Unix 명령어 split로 출력하기도 한다. 이러한 명령어는 운영중인 PostgreSQL postmaster 서버를 제외한 모든 서버에서 가능하다. 예를 들면 Postgres 데이터베이스를 pg_backup으로 시작하는 여러 개의 파일로 백업 받을 수 있다.

# pg_dump postgresdb | split -b 1024m - pg_backup

물리적(raw) 백업 : 연속적인 아카이빙

PostgreSQL 8.1부터는 클러스터 데이터 디렉토리 밑에 있는 pg_xlog 디렉토리에 있는 Write-Ahead Logs(WALs)내에 데이터베이스 파일에 가해지는 모든 변경사항을 추적할 수 있다. 이러한 다른 디렉토리에 들어 있는 WALs을 데이터베이스가 재사용하기 전에 네트워크 백업 명령을 통해 디렉토리로 복사해야 한다.

/backup/postgres/WAL 디렉토리로 복사하기 위해 postgresql.conf에 다음과 같은 쉘 명령어를 추가해야 한다.

archive_command = "cp -i %p /backup/postgres/WAL/%f < /dev/null"

주의 : postgresql.conf, pg_hba.conf, pg_ident.conf 와 같은 환경설정 파일들은 분리해서 백업 받아 놓는 것이 좋다, 물리적 온라인 백업을 하기 위해서는 데이터베이스 관리자로 작업해야 한다.

1. SELECT pg_start_backup("backup_id1"); SQL문장을 실행한다. 백업 라벨, 명령어 실행 시간, 첫번째 WAL 세그먼트 파일과 같은 백업 정보가 /backup/postgres/backup_id1에 있을 것이다.
2. /usr/local/pgsql/data 데이터베이스 데이터 디렉토리의 파일시스템 백업을 수행한다. WAL 파일들은 제외한다. 아카이브 명령어가 이런 파일들을 백업할 것이다.
3. SELECT pg_stop_backup(); 을 수행하여 백업이 완료되었다는 것을 확인한다. 백업을 중지시키면 WAL 아카이브 위치 안에 있는 백업 히스토리 파일을 생성한다. WAL 파일은 백업 히스토리 파일의 일부로 사용된다.

백업 중지 명령을 수행한 후에 WAL 아카이브가 끝나게 된다. 이제 WAL 밑에 있는 모든 파일들과 데이터베이스 데이터 디렉토리를 네트워크 백업 명령을 이용하여 모두 백업 받는다.

증분 백업

자동으로 아카이브된 WAL 로그들은 증분 백업이 가능하다. 네트워크 백업 명령을 이용하여 WAL 아카이브 디렉토리를 증분 백업 받을 수 있다.

6. 네트워크 기반 백업과 복구

복제와 스냅샷같은 일관성있는 데이터 복사를 수행한 뒤에 이 백업본을 테이프, 디스크, 광학장치, NAS 와 같은 다양한 미디어로 백업하기 위해 네트워크 기반의 백업 명령과 복구 명령을 사용할 수 있다.

Amanda는 가장 유명한 오픈소스 백업과 아카이빙 툴이다. Amanda는 수백의 개발자와 수만 명의 사용자를 가지고 있는 활성화된 SourceForge 프로젝트이다. 1991 이후부터 공공 도메인의 일부였으며 다양한 리눅스, BSD 배포본에 포함되어 있다. 가장 최근의 패키지는 Amanda 다운로드 페이지에 존재한다. 이 글을 쓰는 시점에서 Amanda 2.5가 가장 최근의 버전이다.

Amanda는 LAMP 애플리케이션에서 운영되는 다양한 서버를 백업 받을 수 있다. Amanda는 LAMP 애플리케이션내에서 구동 되거나 독립적인 Amanda 백업 서버로 운영될 수 있다. Amanda는 백업 동안에는 활성화 되며 다른 시간에는 대기하고 있을 것이다.

Amanda의 주요한 특징은 일관성있는 백업창이다.Amanda는 LAMP 애플리케이션이 구동되는 다양한 백업 클라이언트로부터 같은 양의 데이터를 백업하려고 시도한다.Amanda는 같은 양의 백업크기를 저장하기위해 백업 반복 주기내에서 각 클라이언트의 전체 백업본을 골고루 분포 시킨다. 시스템 관리자를 위해서는 Amanda는 백업 환경 설정을 조절할 필요 없는 일관성 있는 백업창을 제공한다. 그림 2는 Amanda에 의해 매일 백업되고 있는 세개의 클라이언트들을 보여주고 있다. 첫번째 백업 주기때 Amanda는 모든 파일시스템에 대해서 전체백업을 수행한다. 백업 매체의 일일 가용 능력과 각 클라이언트 파일시스템의 데이터 변경사항의 양을 기준으로 Amanda는 백업을 수행할 때는 백업 레벨(전체, 증분 백업 레벨 1-9)의 백업계획을 세우게 된다. 전체 백업 레벨은 0이며 모든 파일시스템은 적어도 Amanda 환경 파라미터에 설정된 백업 반복 주기에 의한 하나의 전체 백업본을 가지고 있다. 그림이 보여주는 바와 같이 백업되는 데이터의 양은 거의 같은 크기이다.


그림2 : 매일 백업되는 데이터의 총량

Amanda는 데이터 압축, 암호화, 백업을 위해 플랫폼 유틸리티를 사용한다. GNU tar나 파일시스템 덤프, Schily tar, 클라이언트에서 사용하는 어떤 툴이라도 사용될 수 있다. Amanda는 백업 미디어상에서 툴의 데이터 포맷을 사용한다. 이러한 특징은 Amanda를 사용하지 않더라도 복구가 가능할 수 있다. 모든 Amanda백업 미디어는 dd나 mt 로 읽는 것이 가능하다. 사실 Amanda 미디어 파일 헤더는 텍스트 문자열로 미디어를 복구 할 수 있는 명령어를 포함하고 있다.

다음과 같이 dd명령어를 사용하여 Amanda 테이프 파일 헤더를 볼 수 있다.

# dd if= bs=32k count=1
AMANDA: FILE 20060228 natasha /boot  lev 1 comp N program /bin/gtar

백업본을 복원하기 위해 테이프를 시작점에 위치시키고 실행 시킨다.

dd if= bs=32k skip=1 |   /bin/gtar -f...  -
1+0 records in
1+0 records out

Amanda 는 테이프들, 디스크들, 광학 미디어, 미디어 체인저, RAIT에 백업 가능하다. RAIT는 테이프의 이중 어레이라고 할 수 있다. RAID의 개념과 비슷하며 여러 다중화된 미디어 볼륨들 사이에서 백업 데이터를 분산시키고 패러티는 다른 미디어 볼륨에 저장한다. 두 개의 볼륨셋으로 구성된 RAIT는 두개의 미디어 볼륨을 사용하는 미러링 백업 데이터와 동일하다. 즉각적인 복구가 필요할 때 디스크로 백업 할 수도 있고 동시에 테이프로도 가능하다.

Amanda 는 백업을 수행하는 방법에 대한 유연성있고 다양한 환경설정이 가능하다. 개인 파일의 레벨까지 내려 간다. 사용자는 압축의 종류와 암호화를 설정, 백업이 Amanda 클라이언트나 서버에서 실행될 것인지 그리고 각 각의 백업 장치를 위해 네트워크가 사용될 것인지를 결정할 수 있다.

유연성있는 환경설정의 어려움을 줄이기 위해서 환경설정 툴은 최초 Amanda 유저에게 사용 가능하다. Amanda는 LAMP 애플리케이션을 위한 데이터 일관성 매커니즘과 복제와 같은 스냅샷을 제공한다. Amanda 서버는 확장이 용이하고 수백 개의 LAMP 애플리케이션을 백업할 수 있다. 일관성 있는 백업을 하기위한 데이터를 준비하기 위한 명령어는 Amanda 백업 전에 선 백업 액션으로 실행되어 진다. 이것은 Amanda를 사용하여 백업이 되는 플랫폼 의 명령어를 이용하기 때문이며 같은 Amanda 환경설정을 가지고 서로 다른 LAMP 애플리케이션을 위한 서로 다른 암호화 정책을 사용할 수 있다.

Amanda 개발자들은 새로운 백업 프로그램을 쉽게 추가할 수 있는 애플리케이션 API위에서 작업하게 된다. 몇몇 Amanda 사용자들은 파일시스템의 임시공간에 MySQL DB를 포함한 LAMP 애플리케이션을 백업한다. Amanda의 백업은 파일시스템 디렉토리를 백업 받을 수 있기 때문에 임시 디렉토리부터의 복구 시간을 단축해 주며 장기적인 요청을 위한 Amanda 미디어로 부터 복구를 빠르게 해준다. Amanda 사용자와 개발자는 프로젝트 문서를 위한 Amanda wiki 를 사용할 수 있다.

7. 복구 프로세스

백업본으로 부터 복구 하기 위해서 Amanda 복구 명령 amrecover와 amrestore가 있다. amrecover 명령은 사용자가 인덱스 데이터베이스를 찾을 수 있게 하거나 복구할 백업본을 선택할 수 있게 한다. Amanda 클라이언트 소프트웨어가 설치되어 있는 서버는 이 명령어를 사용할 수 있다. 보통 임시 디렉토리 위치로 백업본을 내린다. 애플리케이션 파일들도 각각 mysqldump, pg_dump를 사용하여 MySQL, PostgreSQL 데이터베이스와 같은 LAMP 애플리케이션 서버위의 위치로 복원이 가능하다. 기억할 것은 전체 백업을 수행하려면 반드시 데이터베이스와 애플리케이션이 작동하지 않는 시점에 해야 한다.

다음은 백업 파일 mysql_backup을 mysqldump을 사용한 데이터 베이스 database1을 완전 복원하는 것이다.

# mysql database1 < mysql_backup

다음은 pg_backup로 시작하는 백업 파일을 pg_dump을 사용한 PostgreSQL 데이터 베이스를 완전 복원하는 것이다.

PostgreSQL 데이터 베이스를 물리적 백업본(raw)으로 부터 복구 하려면 PostgreSQL 클러스터 데이터 디렉토리를 재생성 해야 한다. 보통 백업본으로 부터 파일을 복원하기 전에 존재하는 데이터를 백업 받는다. pg_xlog 하위 디렉토리는 아카이브 되지 않은 WAL을 포함하고 있다. 복구 프로세스는 클러스터 데이터 디렉토리에 있는 recovery.conf 파일을 사용한다. 이 파일은 아카이브된 WAL 로그들의 위치를 가지고 있다. 다음은 recovery.conf 파일의 예이다.

restore_command = "cp /backup/postgres/WAL/%f %p"

증분 복원

Amanda에 의해 복원된 임시 디렉토리에 있는 MYSQL 이진 로그파일들로 부터 증분 복원을 수행할 수 있다. 증분 복원은 이진 로그파일에 있는 시작점과 끝점의 시간을 통해 이루어 진다. 로그 위치는 백업 파일을 사용하여 관리자의 실수를 수정할 때 사용한다.

다음은 2006년 5월 1일에 변경되어진 MySQL 데이터베이스를 증분 복원하는 것이다.

# mysqlbinlog --stop-date="2006-05-01 12:00:00" backup-logs.[0-9]* |
     mysql -u  -p 

PostgreSQL 증분 복원은 클러스터 디렉토리에 있는 파일에 설정되어 되어 있다. 복구를 위한 종료 시간 또는 트랜잭션 ID를 통해 가능하다. postmaster 프로세스가 재시작되면 아카이브된 WAL를 특정 종료 시점까지 복원하기 위해 restore_command 설정을 사용한다.

LAMP 애플리케이션을 위해 데이터 복구 절차를 테스트 해보는 것은 중요하다.

8. 백업 보안

보안은 데이터 보호 프로세스에서 중요한 문제이다. 데이터는 백업 미디어내에서 암호화되어 안전해야 한다. 백업을 위한 키를 추적하거나 안전한 위치에 보관해야 한다. LAMP 애플리케이션, Amanda 서버위에서 운영되고 있는 백업 클라이언트를 암호화 하는 Amanda의 유연성은 데이터를 암호화 하기 위한 많은 선택사항을 제공한다. OpemSSH 또는 네트워크 터널링을 통해 백업시 암호화된 통신을 사용한다.

MySQL, PostgreSQL 데이터베이스 백업과 복원을 위한 유저는 최소한의 권한을 가지고 있어야 한다. 예를 들어 mysqlhotcopy , mysqldump 명령을 사용하기 위한 최소한의 권한은 SELECT, RELOAD, LOCK TABLES 이다.

9. 결론

몇몇 오픈소스 데이터 보호 툴이 LAMP 애플리케이션에서 사용 가능하다. 이러한 툴은 LAMP 애플리케이션을 위한 안전한 백업을 도와줄 것이다. 웹 애플리케이션을 위한 LAMP 기술, 데이터웨어 하우징 애플리케이션, 기업용 애플리케이션에 대한 사용량이 증가하기 때문에 이러한 애플리케이션을 사용하여 고객의 데이터를 보호 하는 것이 필요하다.

데이터 베이스 참조 일관성을 유지하면서 백업을 생성하거나 백업 미디어로 인터넷을 이용하여 저장하는 것과 같은 많은 새롭고 흥미 진진한 오픈 소스 개발이 데이터 보호 분야에서 이루어 지고 있으며 이것은 개개인의 요구사항에 맞게 LAMP 백업 솔루션을 지원 되야 한다.

참고

• MySQL backup tools
• MySQL backup forums
• PostgreSQL backup tools
• Amanda forums