앱 서버·DB 백업 안 하면 생기는 일

백업을 안 하면 실제로 생기는 일

아래 네 가지는 특별한 상황이 아니라 운영하다 보면 누구나 마주칠 수 있는 일입니다. 공통점은 "그날이 오기 전까지는 아무 문제 없어 보인다"는 것. 그래서 미룹니다.

백업 없을 때 데이터 손실로 이어지는 사고

백업이 없으면

관리자 실수 삭제 → 복구 불가
해킹·랜섬웨어 → 데이터 암호화·삭제
클라우드 결제 중단 → 인스턴스째 삭제
서버 이전·디스크 고장 → 그대로 손실

백업이 있으면

지운 데이터를 특정 시점으로 되돌림
깨끗한 백업에서 서비스 재구축
다른 위치의 백업으로 즉시 복구
새 서버에 복원 후 계속 운영

같은 사고라도 백업 유무에 따라 '몇 시간 복구'와 '서비스 종료'로 갈립니다.

무엇을 백업해야 하나

대상	왜	우선순위
데이터베이스	회원·주문·콘텐츠 등 핵심	1순위
업로드 파일	이미지·첨부 등 사용자 생성 파일(스토리지)	1순위
설정·환경변수	서버 설정, 환경변수, 인증서 — 재구축 시 필요	2순위
소스 코드	Git 원격 저장소에 보관(로컬에만 있으면 백업 아님)	상시

얼마나 자주 — 백업 주기 = 잃어도 되는 시간

기준은 단순합니다. "사고가 나면 며칠 치를 잃어도 괜찮은가?" 백업 주기가 곧 최대 손실 기간입니다. 월 1회 백업은 최악의 경우 한 달 치를 잃는다는 뜻입니다.

백업 주기별 최대 데이터 손실 기간

실시간/수시간

몇 시간

매일

최대 1일

주 1회

최대 7일

월 1회

최대 30일

주문·결제·활발한 커뮤니티는 매일(또는 더 자주), 변동이 적은 서비스는 주 1회 + 큰 변경 전 수동 백업. 어느 쪽이든 자동이어야 합니다.

3-2-1 원칙

백업의 기본 원칙 3-2-1

벌의 복사본
(원본 + 백업 2)

서로 다른
매체/위치

물리적으로 떨어진
원격 보관

핵심은 마지막 '1'입니다. 같은 서버 안에만 둔 백업은 그 서버가 사라지면 함께 사라집니다. 반드시 다른 곳(다른 계정·다른 클라우드·오프사이트)에 한 벌을 두세요.

환경별 백업 방법

Firebase 계열: Firestore는 예약 내보내기(스케줄 export)로 Cloud Storage 버킷에 자동 백업하고, 그 버킷을 다른 위치에도 복제해 둡니다. 함께 보안 규칙로 데이터가 열려 있지 않은지 점검하고, 요금이 새는지는 서버비 줄이기로 확인하세요.

일반 서버(MySQL 등): cron으로 매일 덤프 → 압축 → 원격 스토리지 업로드. 오래된 백업은 자동 정리합니다.

# 매일 새벽 3시 자동 백업 예시 (crontab)
0 3 * * * mysqldump -u user -p'pass' dbname \
  | gzip > /backup/db_$(date +\%Y\%m\%d).sql.gz \
  && rclone copy /backup remote:appmonster-backup \
  && find /backup -name "db_*.gz" -mtime +30 -delete

복구 테스트 — 안 해보면 백업이 아닙니다

가장 많이 빠뜨리는 단계입니다. 백업 파일이 쌓여 있어도 실제로 복구가 되는지 한 번도 확인 안 했다면, 정작 사고 때 열리지 않을 수 있습니다. 최소 1회는 테스트 환경에 복구해 데이터가 온전한지 확인하고, 이후에도 주기적으로 점검하세요.

최소 백업 체크리스트

지금 바로 확인

되어 있어야 할 것

DB가 자동으로 백업된다
업로드 파일도 함께 백업된다
백업이 다른 위치에도 있다(3-2-1)
오래된 백업이 자동 정리된다
복구 테스트를 한 번이라도 했다

위험 신호

"호스팅이 알아서 해주겠지"
백업이 같은 서버 안에만 있음
사람이 기억해서 수동으로만 함
최근 것만 있고 과거 시점이 없음
복구를 한 번도 안 해봄

백업은 오래된 앱 보안 점검의 필수 항목이기도 합니다.

자주 묻는 질문

호스팅 업체가 알아서 백업해주지 않나요?

업체·요금제마다 다릅니다. 백업을 제공해도 보관 기간이 짧거나, 복구가 유료이거나, 같은 인프라 안에만 있어 계정 자체가 정지되면 함께 못 쓰는 경우가 있습니다. 내가 직접 통제하는 백업을 한 벌은 반드시 따로 두세요.

백업하면 비용이 많이 드나요?

보통 생각보다 적습니다. 압축한 DB 덤프와 파일은 용량이 크지 않고, 원격 스토리지 비용은 월 몇 천 원 수준인 경우가 많습니다. 데이터를 통째로 잃는 비용에 비하면 매우 쌉니다.

백업은 얼마나 오래 보관해야 하나요?

최근 것만 두면 '며칠 전 섞인 오류'를 되돌릴 수 없습니다. 일 단위 최근 7~30일, 주/월 단위로 더 긴 시점 몇 개를 남기는 식으로 여러 시점을 보관하는 것을 권합니다. 보관 주기는 자동으로 정리되게 설정하세요.

클라우드(Firebase)를 쓰는데도 백업이 필요한가요?

필요합니다. 클라우드도 실수 삭제·규칙 오류·요금 중단으로 데이터가 사라질 수 있습니다. Firestore 예약 내보내기로 버킷에 백업하고, 그 버킷을 다른 위치에도 복제해 두세요.

무료 점검부터 시작하세요

지금 백업이 자동으로·원격에 돌고 있는지, 복구가 실제로 되는지 모르겠다면 현재 구성을 점검해 드립니다.

무료 점검 문의 → appmonster.co.kr

문의: appmonster.kr@gmail.com