What is AMANDA?
AMANDA, the Advanced Maryland Automatic Network Disk Archiver
"Single server can backup multiple hosts to various media."
"Amanda is a designed to backup multiple files, databases and applications across a local network and store data on a wide variety of devices including tape, disk and optical based storage"
"Optimized for efficient utilization of network and hardware resources"
Copyright (c) 1991-1998 University of Maryland at College Park All Rights Reserved.
History
- University of Maryland's Computer Science Department
- Supported by Zmanda
License
Freely distributable source and executable. University of Maryland (BSD style) license and GPL
Features of Amanda
- Server-Client(Agent) 아키텍쳐
- Single Backup Server <-> Multiple Client
- "All Configuration are done one a server"
- Single Backup Server <-> Multiple Client
- C & Perl
- 표준 백업 S/W를 기반으로 구성 (Extensible)
- GNU tar
- dump/restore
- Others
- 개방형 File 및 Tape 포맷
- Recover에 mt 또는 GNU tar로 가능 (without Amanda)
- Support Windows (32bit/64bit)
- Multiple Machines을 Holding Disk(Optional)에 병렬 Dump(백업) 처리
- 완료된 Dump들은 가능한 빨리 vtate/tape로 Copy
- 백업된 파일과, Media에서 파일의 위치에 대한 카탈로그 유지관리
- Generic Interface를 통해 Tape Changer 지원
- Device API 제공 (a pluggable interface to storage devices)
- Server와 Client간 Secure Backup 지원
- by OpenSSH
- DMZ or Internet 구간 보안
- 암호화 백업 아카이브 지원
- on Amanda Client 또는 on AManda Server
- GPG 또는 Any Encryption 프로그램 가능
- 압축 백업 아카이브 지원
- 네트워크 상에서 "전송 전" 혹은, "전송 후" 선택 가능
- 예)
- gzip
- bzip2
- others
- Kerberos5 지원 (Authentication)
- Fault Tolerance (Down, Hang, Timeout...)
- Skip Clinet
- 스케쥴된 Backup Run 불가한 상황 극복 (예: 노트북, 랩탑, 기타 등등)
- Backup media error
- 백업 데이타는 "Holding Disk(Buffering)"에서 유지 (Optional)
- Media 문제가 해결되면, 다시 Media로 Flush된다.
- Client의 여러 케이스(예: Timeout)에 대해 Operation Re-try 처리
- Skip Clinet
- 상세 보고서(Report) 지원
- email
- Data Balance 정보
- Client 백업 상태 요약
- Amanda의 Subsystem, Media, Network성능 요약 정보
- 각각의 Backup Run에 따른 Media Usage
- Error 메세지
- email
- Validate Backup Data
- "amcheckdump" Command
- Storage로부터 Backup을 읽어, 각각에 적용된 Application으로 해석 될 수 있는지 확인
- 예: 백업본이 GNU tar 이미지라면, GNU tar로 parsing.
- --timestamp
- Server/Client 설정 검사 도구 지원
- "amcheck"
- 백업 스케쥴의 동적 조정
- 유지보수 (Host, Disk 추가/제거)
- Backup Normalization
- 백업 Cycle내에서 Full /. Incremental 백업을 자동 배치 (Intelligently)
- Resource 최적화를 위해 "Backup Level" 조절
- Pre/Post User 스크립트 지원
- Pre-Backup
- Post-Backup
- Pre-Restore
- Post-Restore
- IPv6 friendly
- Span Tapes 지원 (Split 지원)
- 단일 백업이 하나의 tape(vtape)을 초과할 경우, 자동 분할 저장
- Simple/Robust Data-Recovery
- 모든 Media와 백업 정보를 Database로 관리
- Amanda Command로 열람 가능
- 백업 데이터는 권한만 있다면 어떤 Client에서도 복구 될 수 있다.
- Native Format로 저장되므로, Amanda 없이 OS Tool만으로 복구 가능
System Requirements
Host
- "Backup Server Host" (Can be a Client Host)
- "Backup Client Hosts"
- 저장매체에 접근이 가능해야 한다.
- 저장매체 예)
- Disk (Local, NAS, SAN)
- 대용량 Tape드라이브(라이브러리)
Holding Disk
- Dump에대한 버퍼링 (실제로 tape에 쓰기 전)
- 병렬(Parallel) Backup Run 가능
- Size는 가장 큰 Disk Partition으로부터 생성되는 Dump Output보다 커야 -> 최상의 성능 기대
- Optional (Recommended)
- Disable -> Sequentially
Client side tested systems
AIX 3.2 and 4.1
BSDI BSD/OS 2.1 and 3.1
DEC OSF/1 3.2 and 4.0
FreeBSD 6, 7 and 8
GNU/Linux 2.6 on x86, m68k, alpha, sparc, arm and powerpc
HP-UX 9.x and 10.x (x >= 01)
IRIX 6.5.2 and up
NetBSD 1.0
Nextstep 3 (!)
OpenBSD 2.5 x86, sparc, etc (ports available)
Solaris 10
Ultrix 4.2
Mac OS X 10
Windows: XP Pro (Server pack 2), 2003 server, Vista, 2008 server R2, Windows 7 (!)
Siver side tested systems
- (!)를 제외한 나머지
Scheduler
Q: "Will Amanda support my ACME Tape Drive 2000 Ultra Professional?"
A: "Does your Operating System Support it?"
Traditional Scheduling
- 대부분 백업 솔루션들은 기본적으로 동일한 백업 스케쥴링을 제공.
- 매주 일요일 또는 격주나 매월 마지막날 Full 백업 수행
- (추가) 각 Full 백업 사이에는 다른 레벨을 가지는 증분백업을 수행
- 이러한 방법론의 최대 문제
- Resources Load Balancing 개념이 없음
- CPU, Network, I/O
- Full 백업 완료 지연
- 예) 종종 시스템 관리자는 일요일 예약된 Full 백업이 월요일 아침까지 계속되는 상황 경험
- 정기적인 Full 백업 이외에는 대부분 사용률 저조
- Manual 하게 Load를 조정(Distribute Full Backup) 가능 하나 현실적이지 못함
- 환경 변화 대응 느림
- 신규 Client나, 제거 Client가 Manual하게 유지해왔던 LB 균형을 깨뜨림
- Resources Load Balancing 개념이 없음
Amadan Scheduling
- Optimize Load Balancing of Backup
- Static한 스케쥴을 지정하는 것 대신, 특정 조건을 셋업
- "Client A,B, C는 매주 일요일에, D, E, F는 수요일에 Full 백업을 수행하고, 나머지 요일은 증분 백업을 수행해라"
- "Dump사이클 기간은 7일이며, 최소한 1번의 Full 백업을 수행하고, 그외에는 증분 백업을 수행해라."
- 아래의 목적을 위해 Amanda는 Full 백업과 증분 백업의 최적 조합을 찾는다. => "Optimal Backup Level"
- 각 Backup Run 마다, Backup 데이타의 총량을 가능한 '작게(Small)' 하여 수행
- 이를 위한 고려사항
- 각 Client마다 보고된, 백업 되어야할 데이터 총량
- 가장 최근 수행된 Backup(Since last backup) 기준으로 변화된 데이터 양 정보 기반
- Dump Cycle(Maximum Time between Full Backups)
- 각각의 Backup에 대한 Backup Media(tape or disk) 가용성 (Client별 상이한 Backup Media)
- 각 Client마다 보고된, 백업 되어야할 데이터 총량
- Optimal Backup Level 계산
- 모든 Backup 단위는 "Estimate phase"를 가지고 시작된다.
- "Estimate phase"
- 어떤 File이 변경되었고, 변경된 파일들의 Total size는 얼마인지 결정하는 프로세스
- 다소 시간 소요 발생 -> 특히 많은 Client수 또는 많은 Filesystem수를 가질때 소요시간 증가
- (거의 변화가 없는 Filesystem 또는 File 변경이 거의 없는 대상이라면 Bypass 처리 가능)
Example - Amanda Scheduling
(그림1)
(그림2)
- (그림2)는 (그림1)의 Client들에 대한 백업을 Amanda가 어떻게 스케쥴링 하는지를 보여주는 예제
- (가정 상황)
- 각가가의 /home 디렉토리는 100GB를 소비
- Tape의 용량은 200GB
- 데이타 변화률은 15%
- Dump Cycle은 4일
- 각각의 Backup Run은 DailySet1 부터 DailySet4로 Label된 Tape에 기록
- 모든 증분 백업은 Level-1이며, 최근 Full 백업 기준으로 변경분을 의미 (=차등백업)
아래 (표1)은 각 Backup Run으로 생성된 Backup Size
Filesystem DailySet1 DailySet2 DailySet3 DailySet4 DailySet1 DailySet2 DailySet3 DailySet4 /home1 100.0 15.0 27.75 40.84 100.0 15.0 27.75 40.84 /home2 - 100.0 15.0 27.75 40.84 100.0 15.0 27.75 /home3 - - 100.0 15.0 27.75 40.84 100.0 15.0 /home4 - - - 100.0 15.0 27.75 40.84 100.0 Total 100.0 115.0 142.75 183.59 183.59 183.59 183.59 183.59
- 실제로 Amanda는 Tape의 용량을 최대한 활용하기 위해, 증분 백업의 Level을 0~9까지 모두 활용한다. (Tape 효율성 최대화)
Appendix
- Dump Cycle
- Short
- 예) 3~4일
- 장점: Incremental Backup 수가 적기에 Resotre가 상대적으로 쉽다.
- 단점: 더 많은 Tape 및 Time 소요.
- Long
- 장점: 여러 Tape에 Load를 보다 효과적으로 분산 가능
- 단점: 많은 증분 백업으로 인해 Restore에 더 많은 단계를 필요로 함
- Short
Tape Management
- Amanda는 vpate, ptape, disk, optical 등 모두 tape으로 추상화
- 모든 tape은 사용되기 전에 "amlabel" 명령을 통해 label처리가 되어야 한다.
- label과정을 쉽게 하기 위해, default template이 제공된다.
- custom template 작성 가능
- Labling의 목적은 동일 tape에 Overwriting 방지 (유효한 백업 이미지 보전)
- Amanda의 tape 식별자 정도 개념
- 각각의 Backup Run 단위마다 New Tape으로 시작
- 동일 tape에 여분이 있더라도, 다른 시점의 Backup Run은 반드시 Next Tape의 첫부분부터 기록
- 백업 보존 정책에 따라, 각 Tape의 만료 일자 추적
- 만료되 Tape은 새로운 Backup의 기록을 위해 재사용된다. (Rotate)
- 필요하다면, 특정 tape들은 재사용하지 않도록 설정 가능. (만료되지 않도록)
- DVD-RW와 같은 Optical Media를 대상으로 Archiving 할때 유용
- 만료되 Tape은 새로운 Backup의 기록을 위해 재사용된다. (Rotate)
- 단일 Backup Run에, 매우 큰 대용량 데이타 백업에 대해 Mulitple Tape 사용 지원 (Span Multiple Tapes)
- >= version 2.5
- (2.5 이전 Old Version: Large Filesystem을 작은 Chunks로 관리자가 쪼개야 했음)
- 하나의 Backup Run에 대해 최대(max) 사용가능한 tape 설정 (runtapes 1)
- "part_size"로 백업데이타를 Split (Recommanded: 1/10 of Tape-Size)
- LEOM (Logical End-Of-Midium) 지원/미지원 둘다 가능 (LEOM 지원 권장)
- Amanda는 백업 초기단계에 "end of volume" 감지 가능 (with LEOM, without LEOM)
- vtape의 경우, VFS Device는 LEOM 기본 지원 -> Tape Spanning 자동 활성 (enabled)
Setup Virtual Tapes
- Virtual Tapes(vtapes)은 tape를 Emulating 함을 의미
- "chg-disk" Tape Changer (Recommended)
Pre-Requirements
- vtapes 저장소로 사용할 독립된 Physical HDD 또는 Partition를 결정 (성능)
- Dedicated HDD 권장
- holdingdisk와 vpates는 동일한 Physical HDD여서는 안된다. (성능)
- vpates 저장소는 Amanda에 의해 Backup대상에 포함되어서는 안된다.
Length and number of tapes
- HDD를 어떻게 vtapes으로 분할할지 결정하기 위해 아래의 사항들에 대해 평가/추정 필요.
- 백업되어야 할 데이터의 Total amount
- Full백업 당, 허용 가능한 Level-1이상의 증분백업의 개수
- Full백업 대비, 증분백업의 Size (="데이터 변화율%")
- total tapecycle (백업 데이터 유지 기간과 연관)
- 앞선 수치들의 장기적 변화 추이
- 넉넉한 공간을 확보(Cost↑, Utilization↓)를 통해 "Oversubscribing"을 방지하는 것이 권장되나, oversubscribing을 허용했을 경우, Backup Failure 방지를 위한 주의/감시 체계 필요.
Safe Calculation
- Available Space를 tapes으로 분할 지침
available space * 0.9 >= tapelength * tapecycle
- Usage가 Full에 근접할 경우, 급격한 성능 저하가 "0.9"의 이유
- 성능을 위한 보수적 수치
- 필요에 따라 조정 가능
- Amanda가 하나의 Tape용량(tapelength)를 모두 채우는 일은 드물다.
Oversubscribing
- 실제 존재하는 Resouce보다 더 많은 백업 대상을 수용
- vtape의 Length와 Cycle값 조정
available space * oversubscription factor = tapelength * tapecycle
- 1.0 <= oversubscription factor <= tapecycle
- 각 Backup Run에 사용된 Tape의 유휴 용량이 충분할때 가능한 방법
- 예) DLE의 모든 항목을 Full백업 수행이 가능할만큼 Tapesize가 클 때,
- Amanda는 Space의 초과여부는 고려하지 않음.
Example
- (가정 상황)
- 15GB Storage (available space)
- 15 Tape Cycle
- 2GB Tape Length
- oversubscription factor = 2.0
- DLE중 하나의 Usage가 급격히 증가...
T01 | T02 | T03 | T04 | T05 | T06 | T07 | T08 | T09 | T10 | T11 | T12 | T13 | T14 | T15 |
1.9GB | 1.6GB | 1.4GB | 1.7GB | 1.8GB | 1.9GB | 1.2GB | 1.7GB | 1.8GB | 0.3GB | 0.5GB | 0.9GB | 0.4GB | 0.6GB | 0.4GB |
- (결과)
- T01~T09 총량
- 1.9+1.6+1.4+1.7+1.8+1.9+1.2+1.7+1.8 = 15 (GB)
- T10부터 T15까지는 Dump데이터가 tape으로 flush되지 못한채, Holdingdisk에 남겨지게 됨.
- 이 현상은 Tape Cycle가 끝나고 다시 시작하는(reuse) T01이 될때까지 계속된다. (Backup Failure)
- T01~T09 총량
- oversubscription factor 에 대한 가이드
- 2.0은 매우 높은 수치.
- 상황에 따라 적절한 값은 달라지지만, 대개 1.1~1.5가 보통
Redundancy
- 모든 vtapes을 단일 대상에 두는 것은 대규모 데이터 손실에 취약
- RAID 장비 기반도 안전하지 않음
- Solution => RAIT
Tape Configuration
Device Management
"Amanda dose not use any Proprietary driver for tape or optical devices."
Amanda는 단지, tape의 속성을 정의한 "tapetype"을 지정
예) LTO-3범용 tape 저장 장치에 대한 tapetype Definition이 미리 준비 되어 있음
Virtual Tape
- Amanda는 백업 기록을 위한 Target Media로 Disk를 사용할 수 있는 기능 제공
- 임의의 전용 디렉토리가 "vtapte"으로 불리는 Virtual Tape로 사용된다.
- 완전히 Physical Tape을 사용하는 방식과 동일하게 운영
- Physical Tape Library 인프라 투자 결정에 대한 평가나 테스트 가능
- 현재는 Production환경에서도 Disk에 백업을 기록/보관도 충분
- RAIT 지원
- "Redundant Array of Inexpensive Tapes"
- RAIT 목적은 "중복성" 증가 (D2D2T, D2D2C)
- 여러 Disk에 데이터가 저장되는 RAID 기술과 유사
- virtual tape & physical tape
- 2,3,5 Tapte Set 지원
- 예) 3개의 Tape Set
- 2개의 Tape는 데이터 저장
- 1개는 Parity 비트 저장
- 단일 Tape 대비 2배의 용량/성능
- 실패율 감소 (1/00 -> 1/10000 : 두 Tape모두가 유실/손상 되지만 않는다면 복구 가능)
- 예) 5개의 Tape Set
- 4배의 용량/성능
- 예) 2개의 Tape Set
- 용량/성능 증가는 없다.
- Output에 대한 중복(Replicate)
- 저장 매체 타켓을 다르게 할 수도 있다. (vtape + tape)
- 동일한 타겟
- 정확히 똑같은(매체, 방식 등등) 두개의 "Clone"이 만들어 지므로 DR 대비, On-Site, Off-Site로 분리 배치 가능
- 상이한 타겟
- Tape는 장비 보관용에 유리, Disk는 신속한 복원에 유리
- 예) 3개의 Tape Set
'OS' 카테고리의 다른 글
[동영상] TCP/IP의 원리 (0) | 2012.05.12 |
---|