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

1. Server-Client(Agent) 아키텍쳐
   
   1. Single Backup Server <-> Multiple Client
      
   2. "All Configuration are done one a server"
2. C & Perl
3. 표준 백업 S/W를 기반으로 구성 (Extensible)
   1. GNU tar
   2. dump/restore
   3. Others
4. 개방형 File 및 Tape 포맷
   1. Recover에 mt 또는 GNU tar로 가능 (without Amanda)
5. Support Windows (32bit/64bit)
6. Multiple Machines을 Holding Disk(Optional)에 병렬 Dump(백업) 처리
   1. 완료된 Dump들은 가능한 빨리 vtate/tape로 Copy
7. 백업된 파일과, Media에서 파일의 위치에 대한 카탈로그 유지관리
8. Generic Interface를 통해 Tape Changer 지원
9. Device API 제공 (a pluggable interface to storage devices)
   1. Amanda는 실제로 Device와 직접 통신 하지 않는다.
   2. Bundled drivers
      1. tapes
      2. virtual tapes on disk
      3. DVD-RW
      4. RAIT (D2D2T, D2D2C)
      5. Amazon S3
   3. Bundled 'amvault' (Not Stable)
      1. Copy Amanda dumps from one volume to another
      2. 예) Copy to Removable Media
   4. Cloud Storage (S3)
10. Server와 Client간 Secure Backup 지원
    1. by OpenSSH
    2. DMZ or Internet 구간 보안
11. 암호화 백업 아카이브 지원
    1. on Amanda Client 또는 on AManda Server
    2. GPG 또는 Any Encryption 프로그램 가능
12. 압축 백업 아카이브 지원
    1. 네트워크 상에서 "전송 전" 혹은, "전송 후" 선택 가능
    2. 예)
       
       1. gzip
       2. bzip2
       3. others
13. Kerberos5 지원 (Authentication)
14. Fault Tolerance (Down, Hang, Timeout...)
    1. Skip Clinet
       1. 스케쥴된 Backup Run 불가한 상황 극복 (예: 노트북, 랩탑, 기타 등등)
    2. Backup media error
       1. 백업 데이타는 "Holding Disk(Buffering)"에서 유지 (Optional)
       2. Media 문제가 해결되면, 다시 Media로 Flush된다.
    3. Client의 여러 케이스(예: Timeout)에 대해 Operation Re-try 처리
15. 상세 보고서(Report) 지원
    1. email
       1. Data Balance 정보
       2. Client 백업 상태 요약
       3. Amanda의 Subsystem, Media, Network성능 요약 정보
       4. 각각의 Backup Run에 따른 Media Usage
       5. Error 메세지
16. Validate Backup Data
    1. "amcheckdump" Command
    2. Storage로부터 Backup을 읽어, 각각에 적용된 Application으로 해석 될 수 있는지 확인
       
       1. 예: 백업본이 GNU tar 이미지라면, GNU tar로 parsing.
       2. --timestamp
17. Server/Client 설정 검사 도구 지원
    1. "amcheck"
18. 백업 스케쥴의 동적 조정
    1. 유지보수 (Host, Disk 추가/제거)
19. Backup Normalization
    1. 백업 Cycle내에서 Full /. Incremental 백업을 자동 배치 (Intelligently)
    2. Resource 최적화를 위해 "Backup Level" 조절
20. Pre/Post User 스크립트 지원
    1. Pre-Backup
    2. Post-Backup
    3. Pre-Restore
    4. Post-Restore
21. IPv6 friendly
22. Span Tapes 지원 (Split 지원)
    1. 단일 백업이 하나의 tape(vtape)을 초과할 경우, 자동 분할 저장
23. Simple/Robust Data-Recovery
    1. 모든 Media와 백업 정보를 Database로 관리
    2. Amanda Command로 열람 가능
    3. 백업 데이터는 권한만 있다면 어떤 Client에서도 복구 될 수 있다.
    4. 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

"Amanda is a 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 균형을 깨뜨림

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)
• 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에 더 많은 단계를 필요로 함

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 할때 유용
• 단일 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

Linux 설치시 설치상태나, 설치 단계에서부터 몇가지 체크하고 모니터링 할게 있어서, SSH로 접근 하면 좀 편하지 않을까 싶어서, Ananconda가 Load되면서 SSH를 뛰울 수 있는 방법이 없나~ 하다가... 아주 썩 깔끔한 방법은 아니지만, 우선 급한대로 원하는 결과만(?) 만들어 내어 일단 메모해둔다. (보안같은 부분은 추가적으로 해줘야 한다.. SSH가 root로 비번도 없이 로그인 되니... pass를 미리 설정하던지, Allow인자를 활용하던지.. 아무튼, 꼭 보안은 별도로 신경 써줘야 한다...)

1. 환경

2. initrd.img 풀어 해치기~

3. ssh 데몬 실행을 위한 준비
(다행이 Anaconda 이미지에 sshd 바이너리나 기본적인 설정파일은 미리 준비되어 있었다.)

4. Anaconda 로딩 시, sshd 자동 실행 처리
(이부분이 참... 원래 init 스크립트가 그냥 bash 쉘 스크립트였는데, CentOS6부터 바꼈는지, 컴파일 되어 있다..ㅡ.ㅡ;; 어쨌든, 훼이크성 편법이지만, 부팅중 실행되는 바이너리 중 하나를 바꿔치기 해서 /usr/sbin/sshd가 실행되도록 임시 처리 했다.... 만만한게 auditd 였다.. 추후 정상적인 init프로세스에 추가 할수 있는 방법을 찾으면 수정..)

5. SSH 설정작업은 끝... 작업했던 디렉토리 내용을 다시 initrd.img로 묶어준다.

6. 이제 다시 설치를 시도해서, 설치 과정중 해당 서버로 SSH접속을 시도해본다.

- Password는 없이 바로 로그인 된다.

- 다른 사전 작업이 필요하다면, 각자 처리 해둔다.

이상, 끝..... 서두에 이야기 했듯이... sshd를 실행하는 것이 정상적이진 않다... 시간이 되는대로 CentOS 6 Anaconda의 init과정을 좀 파봐야 겠다... 뭔가 나오면 그때 문서 업데이트하기로 하고 오늘은 이정도로만....

오늘 예전에 같이 동고동락(?)했던 SE분께 놀러 갔다가 딱 걸렸다..ㅡ.ㅡ;; 그쪽 고객중에서 사내 업무에 필요한 관계로, LiveCD를 커스터마이징하는 방법을 요청 했다고....

뭐 대충 보니, LiveCD에 각종 드라이버나, 유지보수 할수 있는 도구들을 담아두고, 유사시에 LIveCD를 응급복구 용도로 사용할려는 것 같다. 이전에는 WindowsPE를 커스트마이징 해서 사용해 온듯 하나, 라이센스 문제가 불거저 더이상 사용하지 못하게 된것 같기도 하고...

아무튼, 이야기를 들어보니, LIveCD의 커널에 특정 하드웨어(Disk 드라이버나 NIC 드라이버) 모듈을 추가 하는 작업은 아니라, 단순히 Linux OS에서 사용할 유틸리티 파일들을 추가 해두려는 것이라, 바로 테스트 해봤다.

Linux 기반에 원격설치서비스(RIS)구축을 해본적이 있어, "벌거 있겠어?? 그놈이 그놈이겠지.." 했는데, 역시나, 쉬운게 없다..ㅡ.ㅡ;;

먼저 맞닥드린건, Fedora16이라는 최신 시스템...ㅡ.ㅡ;; 그간 관심밖에 있었던 Linux 부팅 프로세스가 엄청 낯설었다.... (정말 이 분야에서도 이제 퇴출될 날이 곧.........) 부트 프로세스에 대해 대충이라도 파악하기 위해, initramfs의 init 스크립트를 한참 봤다... 대략 "이런식이구나..." 보구 나니, 표현과 디렉토리 구조, 그리고 패키징 포맷정도가 달라지고 이전과 개념적으로는 거의 비슷....

해서 오늘의 목적인 "Root-Image 파일에 원하는 유틸리티를 빨랑 박아 넣고 끝내자~~" 로 패스...

# cd /usr/local/src

# mkdir /mnt/tmp

# mount Fedora16-LiveCD.iso /mnt/tmp
mount: warning: /mnt/tmp/ seems to be mounted read-only.

(나중에 ISO 이미지 생성시, 필요하므로 미리 복사해둠...)
# cp -a /mnt/tmp iso-src

# ls -al /mnt/tmp/
total 30
dr-xr-xr-x. 5 4294967295 4294967295   224 Mar 25 20:33 .
drwxr-xr-x. 3 root       root        4096 Mar 25 23:57 ..
dr-xr-xr-x. 3 4294967295 4294967295    84 Mar 25 19:16 EFI
-r--r--r--. 1 4294967295 4294967295 18092 Mar 25 19:17 GPL
dr-xr-xr-x. 2 4294967295 4294967295   444 Mar 25 19:16 isolinux
dr-xr-xr-x. 2 4294967295 4294967295   200 Mar 25 19:18 LiveOS

# cp /mnt/tmp/LiveOS/squashfs.img /usr/local/src/

# umount /mnt/tmp

# mount squashfs.img /mnt/tmp
mount: warning: /mnt/tmp/ seems to be mounted read-only

# ls -al /mnt/tmp/
total 5
drwx------. 3 root root   29 Mar 25 19:18 .
drwxr-xr-x. 3 root root 4096 Mar 25 23:57 ..
drwxr-xr-x. 2 root root   33 Mar 25 19:18 LiveOS

# tree /mnt/tmp/
/mnt/tmp/
└── LiveOS
    └── ext3fs.img

1 directory, 1 file

# cp /mnt/tmp/LiveOS/ext3fs.img /usr/local/src/

# umount /mnt/tmp

# mount ext3fs.img /mnt/tmp

# ls -al /mnt/tmp/
total 116
dr-xr-xr-x.   2 root root  4096 Mar 25 19:14 bin
dr-xr-xr-x.   5 root root  4096 Mar 25 19:18 boot
drwxr-xr-x.   4 root root  4096 Mar 25 19:10 dev
drwxr-xr-x. 116 root root 12288 Mar 25 19:18 etc
drwxr-xr-x.   2 root root  4096 Jul 29  2011 home
dr-xr-xr-x.  11 root root  4096 Mar 25 19:12 lib
dr-xr-xr-x.  11 root root 12288 Mar 25 19:18 lib64
drwx------.   2 root root 16384 Mar 25 18:50 lost+found
drwxr-xr-x.   2 root root  4096 Jul 29  2011 media
drwxr-xr-x.   2 root root  4096 Jul 29  2011 mnt
drwxr-xr-x.   2 root root  4096 Jul 29  2011 opt
drwxr-xr-x.   2 root root  4096 Mar 25 18:50 proc
dr-xr-x---.   2 root root  4096 Mar 25 19:14 root
drwxr-xr-x.  22 root root  4096 Mar 25 19:13 run
dr-xr-xr-x.   2 root root 12288 Mar 25 19:14 sbin
drwxr-xr-x.   2 root root  4096 Jul 29  2011 srv
drwxr-xr-x.   2 root root  4096 Mar 25 18:50 sys
drwxrwxrwt.   2 root root  4096 Mar 25 19:17 tmp
drwxr-xr-x.  13 root root  4096 Mar 25 19:08 usr
drwxr-xr-x.  17 root root  4096 Mar 25 19:13 var

# chroot /mnt/tmp

(설치)
# yum install [패키지]

(제거)
# yum remove [패키지]

# umount /mnt/tmp

# mkdir LiveOS

# mv ext3fs.img LiveOS/

(삭제 해주지 않으면, 이전 파일에 Append 됨. -noappend 옵션을 주면 되나, 수정전 원본은 삭제해준다.)
# rm squashfs.img

# mksquashfs LiveOS squashfs.img -keep-as-directory -all-root
Source directory entry LiveOS already used! - trying LiveOS_1
[===|

# cp squashfs.img iso-src/LiveOS

(ISO로 만들 Source 디렉토리 외부에 boot정보 파일이 있어야 mkisofs가 정상 작동...)
# cp -a iso-src/isolinue isolinux

# mkisofs -udf -V "Fedora16-LiveCD" -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-info-table -boot-load-size 4 -o Fedora16-LiveCD-New.iso iso-src
I: -input-charset not specified, using utf-8 (detected in locale settings)
Size of boot image is 4 sectors -> No emulation
  1.24% done, estimate finish Mon Mar 26 00:13:36 2012
  2.47% done, estimate finish Mon Mar 26 00:13:36 2012
  3.71% done, estimate finish Mon Mar 26 00:13:36 2012
  4.94% done, estimate finish Mon Mar 26 00:13:36 2012
  6.18% done, estimate finish Mon Mar 26 00:13:36 2012
  7.42% done, estimate finish Mon Mar 26 00:13:49 2012
  8.65% done, estimate finish Mon Mar 26 00:13:47 2012
  9.89% done, estimate finish Mon Mar 26 00:13:46 2012
 11.12% done, estimate finish Mon Mar 26 00:13:44 2012
 12.36% done, estimate finish Mon Mar 26 00:13:44 2012
 13.59% done, estimate finish Mon Mar 26 00:13:43 2012
 14.83% done, estimate finish Mon Mar 26 00:13:42 2012
 16.06% done, estimate finish Mon Mar 26 00:13:48 2012
.
.
.