백업·복구 (설정·릴리스·DB 덤프)

5. 자주 하는 실수 (Tip)

❌ 실수 1: 백업만 하고 복구를 해 본 적이 없다

장애 날 열어 보니 깨져 있거나 빠진 파일이 있습니다. ✅ 분기마다 다른 폴더에 실제로 풀고 검증 서버에서 기동해 봅니다.

❌ 실수 2: 운영 폴더에 바로 풀어 덮어쓴다

현재 상태가 사라져 무엇이 달랐는지 알 수 없습니다. ✅ 다른 폴더에 풀고 diff -r 로 비교한 뒤 필요한 것만 옮깁니다.

❌ 실수 3: 같은 서버에만 둔다

디스크나 서버가 죽으면 백업도 죽습니다. ✅ rsync 로 다른 서버나 NAS 에 복사본을 둡니다.

❌ 실수 4: 체크섬 없이 옮긴다

잘린 파일이 백업으로 남습니다. ✅ 만들 때 .sha256 을 함께 만들고 옮긴 뒤 -c 로 확인합니다.

❌ 실수 5: 열린 파일을 그대로 복사한다

쓰는 중인 DB 파일이나 로그는 불완전합니다. ✅ DB 는 덤프 도구로, 로그는 백업 대상에서 뺍니다.

❌ 실수 6: 백업 파일에 시각이 없다

어느 것이 최신인지, 언제 것인지 모릅니다. ✅ 이름에 날짜_시각, 안에 MANIFEST 를 둡니다.

❌ 실수 7: 보관 정리를 안 해 백업 디스크가 찬다

정리 안 된 백업이 백업 실패의 원인이 됩니다. ✅ -mtime +N -delete 를 스크립트 끝에 넣고 원격 쪽도 같이 정리합니다.

❌ 실수 8: cron 백업이 멈춘 것을 모른다

몇 달째 같은 파일이 최신입니다. ✅ 최신 파일 시각을 점검 항목에 넣고 로그의 [ERROR] 를 확인합니다.

❌ 실수 9: 비밀번호 든 설정을 아무나 읽는 곳에 둔다

백업 폴더가 755 이면 DB 비밀번호가 공개됩니다. ✅ 백업 폴더 700, 파일 600, 앱 계정 소유로 두고 원격도 같게 합니다.

❌ 실수 10: 앱 폴더 밖 설정을 빼먹는다

유닛·nginx·cron 이 없어 재구축이 며칠 걸립니다. ✅ /etc 의 앱 관련 파일도 묶음에 넣거나 별도 tar 로 함께 보관합니다.