데이터 삭제의 공포를 극복하는 법: 크론(cron)으로 구축한 나만의 자동 백업 루틴

"새벽 3시의 실수, 그리고 모든 데이터가 날아갔던 그날"

서버 관리자로 일하며 가장 등골이 서늘했던 순간을 꼽으라면 단연 '데이터 삭제'입니다. 실수로 명령어를 잘못 입력해 운영 중이던 데이터베이스를 날려버렸던 그날, 저는 쥐구멍에라도 숨고 싶었습니다. 다행히 전날 받아둔 백업본이 있어 복구할 수 있었지만, 그때 깨달았습니다. 백업은 귀찮은 작업이 아니라, 서버 관리자의 생명줄이라는 것을요.

그 사건 이후로 저는 모든 백업 과정을 자동화했습니다. 사람의 기억력은 믿을 것이 못 되기 때문이죠. 오늘은 리눅스 서버에서 가장 신뢰할 수 있는 자동화 도구인 '크론(cron)'을 활용해, 제가 직접 구축하고 개선해온 실전 백업 루틴을 공유합니다.

📑 목차: 실패 없는 서버 백업을 위한 5단계

• 1. cron, 단순한 스케줄러가 아닌 보험
• 2. 실패를 줄이는 백업 스크립트 작성 노하우
• 3. MySQL 백업: 비밀번호 관리의 늪에서 탈출하기
• 4. 모니터링: 백업이 실패했는지 어떻게 알까?
• 5. 나의 최종 백업 철학: 3-2-1 전략

1. cron, 단순한 스케줄러가 아닌 보험

cron은 리눅스 시스템에서 가장 완벽한 '성실한 직원'입니다. 한 번 설정해두면 서버가 켜져 있는 한 단 한 번도 빠지지 않고 정해진 명령을 수행하죠. 제가 처음 크론을 설정할 때 했던 실수는 경로 설정이었습니다. 시스템 환경 변수가 일반 셸 환경과 달라 명령어 실행에 실패하는 경우가 잦았거든요. 반드시 절대 경로(/usr/bin/tar 등)를 사용하는 습관이 사고를 예방하는 가장 쉬운 방법입니다.

2. 실패를 줄이는 백업 스크립트 작성 노하우

단순히 백업 파일을 만드는 것에서 끝나면 안 됩니다. 제가 사용하는 스크립트에는 항상 '오래된 백업본 삭제' 기능이 포함되어 있습니다. 무한정 늘어나는 백업 파일은 결국 서버의 디스크 용량을 꽉 채워 시스템 다운을 유발하기 때문이죠.

# 7일이 지난 백업 파일은 자동 삭제
find /backup -name "*.tar.gz" -mtime +7 -exec rm {} \;

이 한 줄의 코드가 제가 밤잠을 설치지 않게 해주는 가장 강력한 안전장치입니다.

3. MySQL 백업: 비밀번호 관리의 늪에서 탈출하기

데이터베이스 백업 시 쉘 스크립트 안에 비밀번호를 그대로 노출하는 것은 해킹의 지름길입니다. 제가 정착한 방법은 .my.cnf 파일을 사용하는 것입니다. 홈 디렉토리에 별도의 파일을 만들어 권한을 600으로 설정하고 비밀번호를 저장해두면, mysqldump 명령어가 알아서 이를 읽어 들입니다. 이 디테일이 서버 보안의 핵심입니다.

4. 모니터링: 백업이 실패했는지 어떻게 알까?

백업 설정보다 중요한 것은 '백업이 잘 되었는지 확인하는 것'입니다. 저는 성공/실패 여부를 로그 파일에 기록하고, 한 달에 한 번은 직접 백업본을 다른 곳에 복구해보는 '모의 복구'를 진행합니다. 복구 테스트를 해보지 않은 백업본은 쓰레기와 다름없다는 사실을 잊지 마세요.

5. 나의 최종 백업 철학: 3-2-1 전략

마지막으로 제가 강조하고 싶은 것은 '3-2-1 원칙'입니다. 데이터는 3개를 유지하고, 2개의 다른 매체에 저장하며, 그중 1개는 반드시 물리적으로 떨어진 다른 곳(클라우드 등)에 보관하세요. 서버가 위치한 건물이 정전이나 화재가 발생해도 데이터는 살아남아야 합니다.

맺음말: 백업은 귀찮음을 이기는 의지입니다.
처음 크론을 설정하고 며칠간은 로그 파일을 매일 확인했습니다. '오늘도 잘 실행되었을까?' 이 과정을 거치며 시스템에 대한 자신감이 생겼죠. 여러분도 오늘 당장 crontab -e를 열고 첫 줄을 작성해보세요. 지금의 귀찮음이 훗날 데이터 복구 과정에서 흘릴 눈물을 대신해줄 것입니다.