[Growi] 백업 스크립트를 아예 못 쓰면...

개시하다

앞서 다음과 같은 기사가 공개됐다.
https://zenn.dev/nekoniki/articles/44252c08f725f811be38
간단하게 설명하자면'Growi 도구Wiki로 만들어졌다'는 것이다. 최근에 나는 백업 설정이 매우 성대하다는 것을 알아차렸기 때문에 상세한 상황을 기사에 쓰고 싶다.
나는 나 자신과 같은 일을 조금이라도 줄여도 좋다고 생각한다.

컨디션

Docker

CentOS Linux release 7.6.1810

구성은 다음과 같다.

/
├── opt
│   └── docker
│       └── growi
│           ├── backup.sh
│           └── backup
└── home

다른 것도 많은데 여기서 생략하겠습니다.

백업 스크립트(최초)

당초Docker 19.03.5의 내용은 다음과 같다.
backup.sh

docker exec -d {mongodb コンテナ名} mongodump --archive=mongodb.archive
docker cp {mongodb コンテナ名}:/mongodb.archive /opt/docker/growi/backup/growi_`date "+%Y%m%d"`.archive
find ./ -mtime +7 -name "*.archive" | xargs ls -ltrh
rsync -av /opt/docker/growi/backup/ {マウント先パス}

의도

backup.sh 데이터가 포함된 Growi부터 매일 mongodb시간 스탬프를 받아서 dump에 /opt/docker/growi/backup 형식으로 저장

백업은 지난 7일이면 충분하며 7일이 지나면 삭제

마지막 회피 장소로 지정된 경로.archive에서 동기화

이런 느낌이야.
이것rsync은 매일 심야에 활동한다.
※ 눈치가 빠른 사람은 이럴 때 많은 일을 한 것을 알아차릴 수 있다.

무슨 일이 있었는지

한마디로'후원은 사라지지 않고 계속될 것'이라는 컨디션이다.crontab 이하는 말할 것도 없고 마운트 지점도 매일/opt/docker/growi/backup 남은 상태가 계속되고 있다.

Why?

원인은 주로 두 가지가 있다.

① .archive 명령 오류와xargs 경로 지정

첫 번째 이유는 다음 명령이다.

find ./ -mtime +7 -name "*.archive" | xargs ls -ltrh

find의 결과를 find ./ -mtime +7 -name "*.archive"에 맡겼지만 관건xargs에서 집행된 것은 xargs 명령이었다.
※ ls 아래 내용을 참고하세요.
https://www.atmarkit.co.jp/ait/articles/1801/19/news014.html
이는 단서가 있는 것으로,'삭제 대상만 추출했는지 확인'을 위해 당분간xargs이 아닌rm -rf이다.
이를 잊은 결과'매일 7일 이상 업데이트ls 파일.archive'이라는 무의미한 처리를 반복했다.
또한 간단히 지정ls된 경로도 문제가 있고, 셸 실행find된 경로 지정도 가능하지만 ./한 경우cron부터 조개껍질이 실행되기 때문에 home 이외의 경로/opt/docker/growi/backup를 말아 넣을 가능성이 있다..archive 패스 방법을 전혀 몰라서 솔직히 위험하다.
이 처리는 아래와 같이 정확하다.

find /opt/docker/growi/backup -mtime +7 | xargs rm -rf

절대 경로로 백업 디렉터리를 지정하기로 결정했기 때문에 파일 이름을 사용하지 않고 업데이트 날짜에만 추출합니다.
그리고 cron의 결과를 find에 맡기고 실시xargs한다.

② rm-rf의 옵션 부족

이렇게 수정된 경우에도 "Mount 측"은 이전 백업을 유지합니다.
이 원인은 아래의 기술이다.

rsync -av /opt/docker/growi/backup/ {マウント先パス}

rsync는 아래 내용을 참고하십시오.
https://www.atmarkit.co.jp/ait/articles/1702/02/news031.html
백업의 동기화 자체는 이미 얻었지만'동기화 원본에서 비동기화 원본을 삭제하는 파일'을 지정하지 않았기 때문에'과거의 백업이 rsync에서 사라지더라도 목적지를 마운트하면 과거의 데이터를 보존할 수 있다'는 것이다.
이것은 /opt/docker/growi/backup에 rsync를 더해서 해결한다.

rsync --delete -av /opt/docker/growi/backup/ {マウント先パス}

백업 스크립트 재검토

지금까지의 결과에 따라 다음과 같음--delete이 수정되었다.
backup.sh

docker exec -d {mongodb コンテナ名} mongodump --archive=mongodb.archive
docker cp {mongodb コンテナ名}:/mongodb.archive /opt/docker/growi/backup/growi_`date "+%Y%m%d"`.archive
find /opt/docker/growi/backup -mtime +7 | xargs rm -rf
rsync --delete -av /opt/docker/growi/backup/ {マウント先パス}

총결산

이번에 backup.sh에 대한 백업용 스크립트를 정리했습니다. 백업을 계속할지 여부입니다.Growi의 규모가 커지면 백업 크기도 바보가 되지 않아 서버를 압박한다.
사고가 나기 전에 눈치채고 수정을 했으니 정말 다행이다.
근본적으로 한 사람이 이 각본을 제작하고 운용한다.
핵심 부분을 여러 사람이 검증을 바탕으로 사용하면 이번과 같은 오류와 지식 부족을 막을 수 있다는 게 좋은 교훈이다.