진짜 무서운 얘기가 있어요.

서장

프로젝트(ProjectZ로 가정)에서 웹 응용 프로그램을 개발했습니다.
이 웹 애플리케이션에서는 데이터를 저장하는 DB로 사용됩니다PostgreSQL.
환경을 구축할 때 프로젝트 멤버 A씨가 다음과 같이 말했다.
만일의 경우를 대비해서 DB 백업부터 해두죠

사전 준비

A씨 말이 맞습니다.
일반적인 운용에서 사용하지 않더라도 DB 백업을 미리 진행해야 한다.
예를 들어 DB 백업이 최종 수단으로 매우 유용하므로 운영 과정에서 데이터를 잘못 손상시키거나 애플리케이션 오류로 인해 예상치 못한 데이터를 쓴 경우 데이터를 원래대로 복원해야 합니다.
프로젝트Z에서 psql 명령을 통해 DB의 백업을 가져와 클라우드 서비스의 대상 저장 장치에 저장합니다.
클라우드 서비스로 이번에 아주어(※)를 선택했기 때문에 아주어 블로브 스토어를 백업 보존지로 활용하기로 했다.
※ AWS, GCP 등 모두 가능

이루어지다

pg_DB 백업을 가져오기 위해 dump 명령을 정기적으로 실행하고 Azure Blob Storage로 저장하는 작업을 az 명령으로 수행하기 때문에 스크립트화하기로 결정했습니다.
또한 저장된 백업을 복구하는 복구 스크립트와 복구 데이터가 올바른지 확인하는 검사 스크립트도 만들었습니다.
backup.sh

# 引数やエラー処理などは一部省略

DATE=`date "+%Y%m%d"`
pg_dump -Fc -h projectz.$ENV.postgres.server.com projectz > project-backup-$DATE.dump
az login --service-principal --username <user> --password <passwd>
az storage blob upload --name project-backup-$DATE --file project-backup-$DATE.dump
echo "ok."

recover-check.sh

# 引数やエラー処理などは一部省略

DATE=$1
az login --service-principal --username <user> --password <passwd>
az storage blob download --name project-backup-$DATE --file project-backup-$DATE.dump

# create temporary postgres for check and restore data
az postgres server create --name recover-check-projectz
pg_restore -C -h restore-check-projectz.postgres.database.azure.com -d postgres project-backup-$DATE.dump

# start application and test access by curl
./start-app.sh --db=restore-check-projectz.postgres.database.azure.com
curl localhost

backup.sh를 실행한 후 Azure Blob Storage에 백업 파일이 있는데 그걸로 recopver-check.sh를 실행하면 잘 curl도 통과했으니 문제 없겠죠
정기적으로 실행하고 싶으니까 크론 자동실행을 이용하면 편리할 거야
그래서 A 씨는 아래처럼 크론에서 자동으로 집행할 수 있었다.

$crontab -e
0 17 * * * /myscript/backup.sh

A: "Azure Blob Storage에서 자세히 보면 Cron으로 실행되고 백업 데이터의 파일 이름이 표시됩니다. 괜찮습니다!"
A씨는 크론을 수행하며 Azure Blob Storage에 백업 파일이 있는지 확인하고DBのバックアップを取得する 임무를 마무리 지었다.

이변

그 후 며칠이 지나자 프로젝트 Z의 개발 환경에서 조작 프로그램 오류로 인해 데이터가 부족했다.
"이제야 데이터를 백업할 차례입니다."A씨는 득의양양하게 대답했다.
이 프로젝트에서는 백업 스크립트를 테스트할 수도 있고 개발 환경에서 DB 백업 스크립트를 실행해서 백업을 얻을 수도 있기 때문에 원상태로 복구할 계획입니다.
백업 날짜를 선택하고 복구 스크립트를 실행했지만 오류가 발생했습니다.
예?왜??
자세히 살펴보니 백업 파일의 내용이 없고 파일 크기가 0인 파일은 Azure Blob Storage에 저장되어 있었다.

무슨 일이 생겼어요?

Blob Storage에 백업 파일이 제대로 저장되지 않은 이유는 무엇입니까?
내가 그 이유를 설명할게.
우선 스크립트 자체는 문제없다.
백업 스크립트와 복구 스크립트 등을 수동으로 실행하는 것은 예상과 일치하는 동작입니다.
문제는 크론이 스크립트를 시작할 때 고려가 부족하다는 것이다.
수동 실행 시 다른 운용 프로그램 설명서에 ENV라는 환경 변수를 설정하였으나 크론 시작 시 환경 정보를 설정하지 않았습니다. pgdump 명령이 실패했습니다.
더욱이 스크립트가 끝나지 않고 az 명령에 동작하기 때문에 빈 디렉터리는 az 명령을 통해 Blob Storage에 업로드됩니다.
이번에는 파일 이름만 확인했기 때문에 az 명령을 실행할 때 성공했다고 착각했습니다.

처리하다.

ProjectZ는 우선 임시 처리로 백업합니다.sh 내에서 ENV 환경 변수가 없어도 이동할 수 있도록 수정합니다.
또 이런 문제가 다른 이유에서도 발생할 수 있다는 점을 고려해 저장된 데이터를 확인할 때도 데이터 크기에 맞춰 확인할 수 있도록 운용 프로그램을 업데이트했다.

교훈.

이번 사례에서 어떻게 해야 할지 생각해 보자.
일단 크론으로 스크립트를 자동화하는 것 자체가 좋아요.
다만, 문제는 귀찮아서 시험을 생략한 것이다.
만들어진 것은 과대평가가 없으니 잘 테스트해야 한다.
또 프로젝트Z에서 사용한 복구 검사 스크립트는 DB 구축에서 시작(※)돼 시간이 좀 걸렸다.
그래서 게으르지만 이건 안 좋아요.
기본적으로 매번 테스트를 할 필요는 없지만 최초의 한 번 정도는 정식으로 운용하여 테스트를 진행할 것을 구상해야 한다.
※) 경비 삭감을 위해 테스트용 DB를 상시 미가동
또 이번에는 다행히 개발 환경에서 문제를 알아차리지 못했다.
이런 일도 있기 때문에 가능하면 본격적으로 사용할 것을 개발했으면 좋겠다.
이번에는 환경 변수의 설정 오류이기 때문에 수정만 하면 되지만 이외에도 도구의 버전 업그레이드 등이 발생할 수 있습니다.
평소에 쓸모없는 물건일수록 정기적인 유지보수에 주의해야 한다!