서버 백업이 실패할 때 원인을 찾기

서버를 운영하다가 백업이 실패했다는 알림을 받으면, 빨리 대응해야 한다. 하지만 서두르지 말고 한 단어만 붙잡지 말고 전체 흐름에서 원인을 좁혀야 한다.

문제 상황을 정의하기

백업 문제가 반복된다면, 확인 순서를 고정해 두는 편이 낫다. 매번 다르게 접근하면 같은 실수를 반복하게 된다.

확인 범위를 정하기

백업 문제가 반복된다면, 확인 순서를 고정해 두는 편이 낫다. 매번 다르게 접근하면 같은 실수를 반복하게 된다.

• 먼저 볼 값: 로그
• 같이 비교할 값: 정상 상태
• 남겨둘 기록: 시스템 명령 출력, HTTP 상태 코드, 수정 내역

로그에서 뭐를 봐야 하는가

운영 환경의 흐름을 먼저 끊어서 본다. 특히 디스크 공간이 애매하면, 다른 부분을 고쳐도 백업은 계속 실패한다.

sudo ss -lntp
df -h
sudo journalctl -n 80

이 세 명령으로 포트, 디스크 사용량, 시스템 로그를 확인하자. 디스크가 가득 찼다면, 그게 첫 번째 원인이다.

작게 바꿔볼 것들

서버 운영 쪽 문제는 화면만 보고 판단하면 놓치는 게 많다. 로그, 응답, 설정 중 하나를 증거로 잡아야 한다.

하나씩 작게 변경하고 테스트하면, 어디가 문제인지 명확해진다.

권한을 확인해 보기

백업 스크립트를 실행하는 계정, 백업 디렉토리의 소유자, 각 파일의 권한이 맞는지 확인하자. 권한이 없으면 아무리 설정을 고쳐도 백업이 안 된다.

실패했을 때 다음 후보

정상 상태를 먼저 정해 두는 게 좋다. 그래야 시간대나 프로세스 상태가 맞는지 빠르게 판단할 수 있다.

다음에 남길 기록

TypeScript 쪽 문제는 화면만 보고 판단하면 놓치는 게 많다. 로그, 응답, 설정 중 하나를 증거로 잡아야 한다.

다음 순서로 체크하자:

1. 원래 증상이 같은 조건에서 다시 나는지 확인한다.
2. 로그나 응답에서 바뀐 부분을 한 줄로 설명해 본다.
3. 공개 화면, 빌드 결과, 실제 요청 중 하나로 마지막 확인을 한다.

해결 자체보다 기록이 중요하다

해결하는 것도 중요하지만, 어떤 값이 달라졌는지 설명할 수 있는 상태가 더 중요하다. 관련 기록을 남겨 두면, 다음에 비슷한 문제가 나올 때 훨씬 빠르게 대응할 수 있다.