서버 운영
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
수정 전 응답 코드와 수정 후 응답 코드를 비교하면 변경이 제대로 반영됐는지 바로 알 수 있다.
수정 후 검증 순서
sudo nginx -t로 문법 확인- 통과하면
sudo systemctl reload nginx로 적용 (restart가 아닌 reload — 무중단) 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
백업 없이 수정하면 이 단계가 없다. 기억에 의존해 원래 설정을 다시 쓰거나, 서비스가 내려간 채로 원인을 찾아야 한다. 백업 하나가 복원 시간을 수십 분 단축시킨다.