Rsync와 inotifywait를 사용한 백업 ver AWS

반년 전에 Rsync를 처음 사용했을 때는 cron텝을 이용하여 주기적인 백업을 구현했었다.

그런데 이게 최소 1초고, 복잡한 복구 스케쥴을 구성하기 벅찼다보니

RTO / RPO( 리커버리 타임, 포인트) 상 이래저래 문제점이 많이 있던 작품이었다.

cron 대신 파일 시스템 이벤트 모니터링 도구인 inotifywait를 사용하여 파일 변화 감지 후 자동으로 rsync 명령어를 실행하는 방법이 있다.

 

inotify-tools는 파일 시스템 이벤트를 모니터링하고 조치하는 프로그램이다.

파일 생성, 수정, 삭제 여부등을 감시할 수 있고 이걸 알람으로 보낼수도 있다.

이를 이용해서 파일에 변경사항이 있으면 rsync를 실행하도록 설정한다면 

cron을 이용한 스케쥴링보다 훨씬 합리적인 백업을 할 수 있을 것이다.

 

 

 

일전에 AWS S3버킷과 IDC 온프레미스의 스토리지를 Storage gateway로 연동하는 작업을 했었다.

https://raid-1.tistory.com/193

그런데 이 연동은 캐싱이라

연결이 끊기면 온프레쪽에 서로의 데이터가 안남는다.

이것을 보완하기위해 Rsync와 inotifywait를 사용한 백업을 구현하여 따로 해당 캐싱 스토리지 내용물을

변동사항이 있을 때마다 다른 디렉토리에 백업해놓을 것이다.

그것이 오늘의 포스트다.

 

 

 

0. 환경 설명

 

AWS 쪽에서 파일 게이트웨이를 IDC와 구축되있다.

S3 <--------> Storage

IDC의 storage1 서버는 파일 게이트웨이에 마운트하고있다

(NFS 클라이언트로 /image 디렉토리를 갖고)

내 중간 목표는 AWS상에 S3버킷에 내용물이 추가되면

IDC의 온프레미스에서 /image_backup 디렉토리에 rsync로 복사하는 것이다.

그리고 최종 목표는 그 반대방향도 구현해서 쌍방향 스토리지 싱크하는 것이다.

 

 

1. 먼저 inotify-tools를 설치

 

https://zetawiki.com/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_inotify-tools_%EC%84%A4%EC%B9%98

 

[root@zetawiki ~]# inotifywait
-bash: inotifywait: command not found

 

yum epel 저장소 추가
epel = Extra Packages for Enterprise Linux→ 엔터프라이즈 리눅스를 위한 추가 패키지

확인
yum repolist
rpm -qa epel-release
yum list epel-release

설치
yum install epel-release

 

이노티파이 툴 설치

yum install inotify-tools

 

다음과 같이 명령어가 잘 실행되는 것으로 잘 설치된 것 확인 가능.

 

 

 

2. rsync 설치

sudo yum install rsync

 

 

 

3. 동기화할 디렉토리를 만든다.

mkdir /image /image_backup

 

 

 

4. rsync 명령어를 만들어둔다.

예를 들어, /image 디렉토리를 /image_backup에 동기화하려면 다음과 같이 입력하게 만들고 싶은 것이다.

rsync -avz /image /image_backup

 

후에

–delete 옵션 추가하기로 함

–delete 옵션은 소스에 없는 것들은 타겟에서도 지우라는 명령입니다. 이때 소스에 없는 파일과 디렉토리는 타겟에서도 지우는 기능

 

-b 옵션과 같이 못쓰므로 주의. (디렉토리를 지우지 못한다)_

원인은 -b 옵션 때문인데 -b 옵션은 타겟에서 파일을 지욱 때 만약을 대비하기 위해 파일을 ~가 끝에 붙은 이름으로 변경해서 백업하는 기능입니다. 이 옵션으로 인해 지우지 못하게 됩니다.

-b 옵션을 제거하면 문제가 해결됩니다.

 

 

 

 

 

5.쉘스크립트 작성

 inotifywait 명령어를 사용하여 디렉토리의 파일 변경 사항을 모니터링하는 쉘 스크립트를 만든다.

vi /image_backup.sh

 

bash
#!/bin/bash
while inotifywait -r -e modify,create,delete,move /image; do
    rsync -avz /image /image_backup
done

 

 

위 쉘 스크립트는 /image 디렉토리의 파일 변경 사항을 모니터링하고,

변경 사항이 발생하면 rsync 명령어를 실행하여 /image 디렉토리를 /image 디렉토리와 동기화한다.

 

 

6. 위 스크립트를 권한주기 & 실행.

chmod +x /image_backup.sh
/image_backup.sh

 

 

# vi /root/.bashrc 여기에 alias 명령어로 연결한 목록을 재부팅시에도 오토로 실행시킨다.

.bashrc 파일은 사용자가 이미 로그인한 상태에서 새 셸(터미널)을 열 때마다 실행되는 셸 스크립트다.

 

만약 해당파일이 존재한다면 해당 파일을 실행하여라.

vi /root/.bashrc

if [ -f /image_backup.sh ]; then
    /image_backup.sh
fi

저장 후 source ~/.bashrc 라고 입력하면 환경변수류의 설정파일이 모두 적용된다. (alias포함)

Bash 셸을 시작할 때마다 .bashrc 류가 자동으로 실행된다

 

 

7. 트러블슈팅

 

아니근데이거 백그라운드로 돌아가게 바꿔야지

포어그라운드 돌아가니까 아무 작업도 못한다.

 

 

https://raid-1.tistory.com/41

 

실행중인 작업 관리

 

Ctrl + z 정지 -> stop 상태 [1]+ stopped
jobs %1      1번작업을 확인
fg %1          포어그라운드로 실행
bg %1         백그라운드로 실행
ps -ef          작업 목록 상세 확인 PID

ps aux        모든 사용자의 실행중인 프로세스 목록 

kill -18 PID 작업 재실행

 

잠깐 ctrl+z 눌러서 정지 후

 

해당 정지중 작업 1번을 백그라운드로 실행 ㄱㄱ

 

작업목록에서 잘 실행중이다.

 

 

 

 

 

8. 백그라운드로 실행 명령어 삽입

아까 bashrc에 & 를 집어넣으면 백그라운드로 실행시켜준다고 한다.

그래서 추가해줬다.

 

 

아까와 달리 바로 백그라운드로 가서 다른 작업을 할수 있게 되었다.

source ~/.bashrc

 

 

 

 

 

9. 일방통행 결과 확인

 

AWS to IDC 

 

지금 구현한 것은 AWS상에 S3버킷에 내용물이 추가되면

IDC의 온프레미스에서 /image_backup 디렉토리에 rsync로 복사하는 것이다.

 

/image에다가 touch로 파일 하나 만들자마자

inotify-tool로 변화가 감지되자 바로 트리거 돼서 스크립트가 실행된다.

그래서 이전에 넣어두었던 다른 파일들도 (이제서야) rsync로 복사해오기 시작한다.

 

 

AWS 상에도 만든 test 파일들이 올라온다.

 

근데 해당 설정은 IDC 쪽에서만 inotify가 변화를 인식해서 rsync 하는 것이기 때문에 

AWS에서 수정되어 /image 디렉토리

 

 

 

 

10. 반대방향 스크립트 구성

 

 IDC to AWS

 

최종 목표는 그 반대방향도 구현해서 쌍방향 스토리지 싱크하는 것이기 때문에

반대방향 스크립트 하나를 또 만들어 한쌍으로 돌려야 한다.

 

(이부분 실패했으니 따라하지 말것)

 

#!/bin/bash
while inotifywait -r -e modify,create,delete,move /image_backup; do
    rsync -avz /image_backup /image
done

 

chmod +x /image_backup_reverse.sh

vi /root/.bashrc

if [ -f /image_backup_reverse.sh ]; then
    /image_backup_reverse.sh &
fi

 

 

touch /image_backup/wowwow

와 루프돌고 난리났다.

쌍방이 디렉토리의 변화를 인지하고 계속 백업하다가 이사단이 났다!!!

컨트롤 C!!! 컨트롤 Z!!!!

 

 

 

 

11. 트러블슈팅2

 

무슨일이 일어났는지 살펴보니,

/image 안에는 /image_backup 파일이 전부 들어가있고, 그 안에는 또 /image 파일이 전부들어가있고

무한 인셉션 루프로 엘레베이터 양면 거울마냥 안으로 들어가는 구조가 형성되었다.....

(ctrl+c 를 길게 누르면 멈추는줄 모르고 한번만 눌러도 안멈춤... 그래서 800개가 넘는 /image_backup/image/image_backup/...파일이 생성돼버렸다)

 

이거 쓰고있는 웹써버라 복구해야하는데..

 

 

원상 복구

 

 

빨리 한쪽 주석처리하자..

 

아익

kill $(jobs -p)

삭제도 IDC에서 하면 안된다.

일단 스크립트 다 내리고 차분히 하나하나 삭제해서 복구해야한다.

스크립트안내리면 삭제에도 반응해서 rsync가 작동한다.

vi /root/.bashrc

 

 

다수의 시도 끝에 loop를 해결 못하고

포기하고 다음엔 아래의 것을 따라해보기로 계획했다.

https://blog.naver.com/dugurs/222507810118

rsync, lsyncd 서버간 파일 동기화

 

결국 실시간 동기화 안하기로 했고

그냥 단방향 rsync 실시간 백업서버 하나 만드는것으로 마무리 하려 했으나...

 

 

 

 

 

12. 해결

 

4시간동안 고뇌한 끝에 원인을 찾았다.

거울처럼 계속 디렉토리 만들고 파고드는 원인은 아마 끝에 붙은 / 슬레쉬다.

자꾸 image_backup 디렉토리 안에 image 디렉토리로 들어가서 무한 파고들기 루프가 발생하는것 같기에

(우리가 원하는건 내용물만 긁어오는건데...)

혹시 본인 이름이 상대방 디렉토리 내부에 들어가있는 게 루프의 원인이 아닐까 생각했다.

아마 rsync 시작지점이 부모폴더 포함이냐 아니냐가 루프의 관건인것 같다.

 

스크립트 목적지 뒤에 슬레쉬를 붙여줬다.

이러면 내부 내용물만 교환하지 않을까? 본인 이름이 들어간 디렉토리를 상대방에게 생성하지 않을 것이다.

 

 

#!/bin/bash
while inotifywait -r -e modify,create,delete,move /image; do
    rsync -avz --delete /image/ /image_backup/
done

 

#!/bin/bash
while inotifywait -r -e modify,create,delete,move /image_backup; do
    rsync -avz --delete /image_backup/ /image/
done

vi /root/.bashrc

 

source ~/.bashrc

if [ -f /image_backup.sh ]; then
    /image_backup.sh &
fi


if [ -f /image_backup_reverse.sh ]; then
    /image_backup_reverse.sh &
fi

 

 

13. 결과 확인

 

두 디렉토리 이상없이 rsync 잘 작동한다.

/image에 hhhhhh 생성후

양쪽 디렉토리 관찰.

저번처럼 내부로 디렉토리를 파고 반복돼서 들어가는 일은 없다.

 

/image   --------->   /image_backup

 

AWS 상에도 /image를 통해해당 파일이 올라온다.

 

파일 삭제도 반영된다.

/image   --------->   /image_backup

 

/image   <---------   /image_backup

 

 

 

14. 트러블슈팅

그런데 딱 하나만 안된다.

/image   <---------   /image_backup

 

/son 파일을 생성해보니 갑자기 원본에서 삭제된다.

rsync warning: some files vanished before they could be transferred (code 24) at main.c(1179) [sender=3.1.2]

이라는 경고 메세지가 뜨면서

만들었던 파일을 원본위치에서 갑자기 삭제하고 목적지에는 잘 전해준다.

도대체 이게 무슨일인가!

vi /root/.bashrc

source ~/.bashrc

 

 

그래서 도착지 파일을 원본이 다시한번 복사해온다는 웃긴 스크립트를 고안해보았다.

(지가 보내놓고)

 

집에 가고싶어서

/timetogo 라는 파일을 만들어봤다.

한번더 테스트를 해보니 /timetogo 뿐만 아니라 애꿏은 /son 도 같이 삭제됐다.

 

 

 

 

 

 

15. 최종 해결

 

/image   <--------->   /image_backup

 

rsync에서 

--delete 옵션 제거하면 된다.

나는 이게 있어서 삭제(rm)가 동기화 되는줄 알았더니

--delete 빼도 삭제가 동기화된다. (/image   <---------   /image_backup 만. 그 반대는 안된다)

 

 

왜 이런일이 발생했는지는 AWS file gateway에 nfs 마운트한 파일과 일반 디렉토리에 차이가 있나보다..

추측일 뿐이지만 rsync를 진행하는 단계에서 yy.qkdslo 이런 임시 파일을 생성하는데,

그때 상대방에게 파일이 없다는걸 어느방향으로든 감지하고 역으로 rsync 당하는것같다...

 

 

 image_backup에서 image 쪽으로 wait란 파일을 추가해서 넘겨도 이제 원본이 사라지지 않는다.

 

 

aws쪽에도 wait가 잘 넘어와있다.

 

 

============================================================================================

 

 

 

단점

 

aws S3버킷에 cherry_blossom 파일 업로드.

 

잠시 뒤에 NFS Storage 인 /image에 들어옴

 

아니 근데  /image_backup 에는 업데이트 안되네;;;; 분명 파일 새로 들어왔는데 inotify가 반응을 안한것...

 

그래서 /image쪽이나 /image_backup쪽에서 파일 만들어주니까 (둘다 됨)

다시 트리거가 작동해 sync를 맞춰서 cherrt~ 가 들어와서 같아진다.

트리거인 inotify가 문제인듯.