1221 서버 관리 실전: 백업, 복구, 모니터링
✅ 1. 백업 (Backup)의 중요성과 대상
- 백업은 서버 운영 중 발생할 수 있는 데이터 손실(하드웨어 장애, 해킹, 사용자 실수 등)에 대비하여, 데이터와 설정 파일의 복사본을 별도의 저장 공간에 보관하는 가장 기본적인 재해 복구(Disaster Recovery) 활동입니다.
- "백업이 없는 서버 관리는 존재하지 않는다"고 할 만큼, 아무리 강조해도 지나치지 않은 필수적인 작업입니다.
➕ 무엇을 백업해야 하는가?
-
데이터베이스 (Database):
- 가장 중요하고 핵심적인 백업 대상. 웹사이트의 모든 콘텐츠(게시글, 회원 정보 등)가 담겨 있습니다.
- 데이터베이스는 실시간으로 데이터가 변경되므로, 파일 시스템을 그냥 복사하는 방식은 데이터 정합성을 깨뜨릴 수 있습니다. 반드시 데이터베이스 덤프(Dump) 도구를 사용해야 합니다.
-
웹사이트 파일 (Website Files):
- 사용자가 업로드한 파일(이미지, 첨부파일 등)이 저장되는 디렉토리. (e.g., WordPress의
/wp-content/uploads) - HTML, CSS, JavaScript 등 웹사이트의 소스 코드. (단, Git으로 관리된다면 우선순위는 낮음)
- 사용자가 업로드한 파일(이미지, 첨부파일 등)이 저장되는 디렉토리. (e.g., WordPress의
-
서버 설정 파일 (Configuration Files):
- 웹 서버(e.g.,
/etc/nginx/conf.d/), PHP, 데이터베이스 등의 설정 파일. - 서버를 새로 구축해야 할 때, 이 설정 파일들이 있으면 복구 시간을 크게 단축할 수 있습니다.
- 웹 서버(e.g.,
✅ 2. 데이터베이스 백업 및 복구 (MariaDB/MySQL 기준)
➕ 2-1. 백업 (덤프 생성)
-
mysqldump는 데이터베이스의 스키마(구조)와 데이터를 SQL 문장으로 변환하여 하나의 파일(.sql)로 만들어주는 표준 백업 도구입니다. -
기본 명령어:
mysqldump -u [사용자명] -p [데이터베이스명] > [백업파일_이름].sql- 예시:
mysqldump -u my_app_user -p my_app_db > my_app_db_backup_20251221.sql
- 예시:
-
자동화: 위 명령어를 셸 스크립트(
.sh)로 만들고, Cron을 사용하여 매일 새벽과 같이 정해진 시간에 자동으로 실행되도록 예약하는 것이 일반적인 운영 방식입니다.
➕ 2-2. 복구 (덤프 복원)
-
백업된
.sql파일을 사용하여 데이터베이스를 특정 시점으로 복원합니다. -
기본 명령어:
mysql -u [사용자명] -p [데이터베이스명] < [백업파일_이름].sql- 예시:
mysql -u my_app_user -p my_app_db < my_app_db_backup_20251221.sql
- 예시:
-
중요: 복원 작업은 현재 데이터베이스를 백업 파일의 내용으로 덮어쓰므로, 매우 신중하게 실행해야 합니다.
✅ 3. 파일 백업 및 복구
- 웹사이트 파일과 설정 파일은
tar나zip과 같은 압축 명령어를 사용하여 백업하는 것이 일반적입니다.
➕ 3-1. 백업 (압축)
-
tar는 여러 파일과 디렉토리를 하나의 파일로 묶고, 압축하는 리눅스의 표준 도구입니다. -
기본 명령어:
# c: 생성, z: gzip 압축, v: 과정 표시, f: 파일 이름 지정 tar -czvf [백업파일_이름].tar.gz [백업할_디렉토리_경로]- 예시:
tar -czvf www_backup_20251221.tar.gz /var/www/html
- 예시:
➕ 3-2. 복구 (압축 해제)
-
기본 명령어:
# x: 해제, z: gzip 압축 해제, v: 과정 표시, f: 파일 이름 지정 tar -xzvf [백업파일_이름].tar.gz -C [복구할_위치]- 예시:
tar -xzvf www_backup_20251221.tar.gz -C /var/www/
- 예시:
-
백업 파일 보관: 생성된 백업 파일(DB, 파일)은 현재 서버가 아닌, AWS S3, Google Drive, 별도의 백업 서버 등 물리적으로 분리된 안전한 공간에 전송하여 보관해야 합니다.
✅ 4. 서버 모니터링 (Server Monitoring)
- 모니터링은 서버가 정상적으로 동작하고 있는지, 성능에 문제는 없는지를 지속적으로 관찰하고 측정하는 활동입니다. 장애가 발생하기 전에 이상 징후를 미리 발견하고 대응하는 것이 주 목적입니다.
➕ 무엇을 모니터링해야 하는가?
-
시스템 리소스:
- CPU 사용률: CPU가 과도하게 사용되고 있지는 않은가?
- 메모리(RAM) 사용량: 메모리가 부족하여 스왑(Swap)이 발생하고 있지는 않은가?
- 디스크 사용량: 디스크 공간이 가득 차서 서비스가 멈출 위험은 없는가?
- 네트워크 트래픽: 비정상적인 트래픽 급증이 발생하지는 않았는가?
- 관련 명령어:
top,htop,free -h,df -h
-
서비스 상태:
- 웹 서버(Nginx) 프로세스: 정상적으로 실행 중인가?
- WAS(Tomcat) 프로세스: 정상적으로 실행 중인가?
- 데이터베이스(MariaDB) 프로세스: 정상적으로 실행 중인가?
- 관련 명령어:
systemctl status nginx
-
애플리케이션 성능 (APM):
- APM (Application Performance Monitoring): 애플리케이션 내부의 동작을 상세하게 모니터링하는 전문 도구. (e.g., Pinpoint, New Relic, Datadog)
- 어떤 API 요청이 느린지, 어떤 DB 쿼리가 병목을 유발하는지 등을 분석할 수 있습니다.
- 모니터링 시스템:
Zabbix,Prometheus/Grafana와 같은 오픈소스 도구나,AWS CloudWatch와 같은 클라우드 서비스를 사용하여 이러한 지표들을 자동으로 수집하고, 시각화하며, 임계치 초과 시 알림(Alert)을 받도록 구성하는 것이 일반적인 운영 방식입니다.
📌 요약
- 백업은 데이터 손실에 대비하는 최후의 보루이며, 데이터베이스(mysqldump)와 웹사이트 파일(tar)을 대상으로 정기적으로 수행해야 합니다.
- 백업 파일은 반드시 물리적으로 다른 서버나 클라우드 스토리지(S3)에 안전하게 보관해야 합니다.
- 모니터링은 장애를 사전에 예방하고 시스템의 건강 상태를 지속적으로 확인하는 중요한 활동입니다.
- 웹 마스터는 시스템 리소스(CPU, 메모리, 디스크)와 핵심 서비스(Nginx, DB)의 상태를 주기적으로 점검하고, 이상 징후 발생 시 원인을 파악하고 대응할 수 있어야 합니다.
