← 전체 글로 돌아가기

서버 운영

Nginx 설정을 고치기 전에 백업 파일을 남기는 이유

nginx.conf나 sites-available 파일을 수정하기 전에 백업을 남기면, 실수했을 때 복원까지 30초면 끝난다.

Nginx 설정을 잘못 고치면 사이트가 통째로 내려간다. 그래서 고치기 전에 반드시 백업 파일을 먼저 만든다.

sudo cp /etc/nginx/sites-available/example.com \
       /etc/nginx/sites-available/example.com.bak.$(date +%Y%m%d)

날짜를 접미사로 붙이면 여러 날짜 백업이 쌓여도 헷갈리지 않는다.

수정 전에 항상 확인하는 것

백업을 만들고 나서는 현재 설정이 유효한지 먼저 확인한다.

sudo nginx -t

syntax is ok / test is successful 두 줄이 나오면 현재 설정은 정상이다. 이 상태를 기록해두면 수정 후 문제가 생겼을 때 어디서 틀렸는지 좁히기 쉬워진다.

도메인 쪽을 건드릴 예정이라면 DNS도 미리 확인한다.

dig example.com +short
curl -I https://example.com

수정 전 응답 코드와 수정 후 응답 코드를 비교하면 변경이 제대로 반영됐는지 바로 알 수 있다.

수정 후 검증 순서

  1. sudo nginx -t로 문법 확인
  2. 통과하면 sudo systemctl reload nginx로 적용 (restart가 아닌 reload — 무중단)
  3. curl -I https://example.com으로 실제 응답 코드 확인

reload 후에도 기존 응답과 달라진 게 없으면 캐시가 낀 것이다. curl-H 'Cache-Control: no-cache'를 붙이거나 다른 네트워크에서 확인한다.

복원이 필요할 때

설정이 꼬였으면 백업으로 덮어쓰고 reload하면 끝이다.

sudo cp /etc/nginx/sites-available/example.com.bak.20260623 \
       /etc/nginx/sites-available/example.com
sudo nginx -t && sudo systemctl reload nginx

백업 없이 수정하면 이 단계가 없다. 기억에 의존해 원래 설정을 다시 쓰거나, 서비스가 내려간 채로 원인을 찾아야 한다. 백업 하나가 복원 시간을 수십 분 단축시킨다.