공개 후 운영Backup · 복원
백업
백업은 홈페이지 내용을 따로 복사해 두었다가 문제가 생기면 그 시점으로 되돌리는 안전장치예요.
장부를 한 권 더 써서 금고에 넣어 두는 것과 같아요.
조금 더 자세히
실수로 지운 글, 해킹, 서버 문제가 생겨도 백업이 있으면 다시 살릴 수 있어요.
얼마나 자주 할지는 얼마나 자주 바뀌는지에 달려 있어요. 거의 안 바뀌는 소개형이면 바뀔 때마다, 예약 · 글이 매일 쌓이면 더 자주 남겨요.
백업은 홈페이지와 다른 곳에 보관해야 해요. 같은 서버에만 있으면 서버 문제 때 백업도 함께 사라져요. 실제로 되돌려지는지 가끔 확인하는 것도 중요해요.
홈페이지 백업에는 무엇이 들어가야 하나요?
홈페이지 백업에는 파일만이 아니라 데이터베이스와 설정까지 들어가야 해요. 화면을 만드는 파일만 남겨 두면, 예약 · 회원 · 주문 · 글처럼 매일 쌓이는 정보는 되돌릴 수 없어요.
자주 놓치는 건 설정이에요. 도메인 연결 기록(DNS), 리다이렉트 규칙, 문의 메일 설정은 평소엔 안 보이지만, 사라지면 홈페이지가 열려도 메일이 안 오거나 옛 주소가 끊겨요.
직접 개발한 홈페이지라면 소스 코드는 보통 깃허브 같은 코드 저장소에 따로 남아 있어요. 그래도 데이터베이스와 손님이 올린 사진은 그 저장소에 없으니 따로 백업해야 해요.
표는 옆으로 밀어서 볼 수 있어요
| 항목 | 예 | 빠지면 생기는 일 |
|---|---|---|
| 파일 | 소스 코드 · 디자인 · 설정 파일 | 화면을 다시 만들어야 해요 |
| 데이터베이스 | 예약 · 회원 · 주문 · 게시글 | 쌓인 기록이 사라져요 |
| 올린 자료 | 사진 · 메뉴판 · 첨부 파일 | 글은 있는데 사진이 비어요 |
| 연결 설정 | DNS 기록 · 리다이렉트 · 메일 설정 | 메일이 안 오고 옛 링크가 끊겨요 |
| 계정 목록 | 도메인 · 호스팅 · 관리자 계정이 어디 있는지 | 복구할 사람이 어디서 시작할지 몰라요 |
3-2-1 백업 규칙은 무엇인가요?
3-2-1 규칙은 사본을 3개 두고, 2가지 다른 저장 방식에 나눠 담고, 그중 1개는 다른 장소에 두라는 널리 쓰이는 백업 원칙이에요. 법으로 정한 규칙은 아니지만, 한 번의 사고로 모든 사본을 잃지 않게 해 주는 쉬운 기준이에요.
작은 가게 홈페이지라면 ‘지금 서버의 원본 + 호스팅 회사의 자동 백업 + 다른 클라우드 저장소의 사본’ 정도로 맞출 수 있어요. 핵심은 마지막 사본이 서버와 다른 회사, 다른 계정에 있다는 점이에요.
랜섬웨어처럼 파일을 잠가 버리는 공격은 연결된 저장소까지 함께 잠글 수 있어요. 그래서 평소에는 홈페이지와 연결되지 않은 사본을 하나쯤 두는 게 안전해요.
사본을 둔 계정도 따로 지켜야 해요. 홈페이지 관리자 계정과 백업 계정이 같은 비밀번호라면, 한쪽이 털렸을 때 사본까지 함께 지워질 수 있어요. 백업 계정에는 다른 비밀번호와 2단계 인증을 써 주세요.
백업은 얼마나 자주, 얼마나 오래 보관해야 하나요?
백업 주기는 ‘문제가 생기면 며칠치까지 잃어도 괜찮은가’로 정해요. 한 달에 한두 번 글을 바꾸는 소개형이면 바꿀 때마다, 예약이 매일 들어오면 적어도 하루 단위로 남겨야 잃는 기록이 줄어요.
보관 기간도 중요해요. 해킹은 바로 알아채지 못하는 경우가 많아서, 가장 최근 백업 하나만 있으면 이미 오염된 시점을 되돌리게 될 수 있어요. 며칠 전, 몇 주 전처럼 여러 시점을 함께 남겨 두세요.
백업에 손님 이름 · 연락처가 들어 있다면 그 백업도 개인정보예요. 암호를 걸어 보관하고, 볼 수 있는 사람을 줄이고, 개인정보 처리방침에 적은 보관 기간이 지나면 백업에서도 지워야 해요.
주기와 함께 ‘언제’ 돌릴지도 정해요. 손님이 적은 새벽 시간에 자동으로 돌게 해 두면 홈페이지가 느려지지 않고, 사람이 깜빡할 일도 없어요.
백업이 실제로 되돌려지는지 어떻게 확인하나요?
백업은 실제로 되돌려 봐야 쓸 수 있는지 알 수 있어요. ‘백업 완료’ 알림만 믿고 있다가, 정작 필요한 날 파일이 깨져 있거나 일부가 빠진 걸 아는 경우가 많아요.
업체에 맡겼다면 복원 시험을 직접 할 필요는 없지만, 마지막으로 복원을 시험한 날짜는 물어볼 수 있어요. 대답이 바로 나오지 않는다면 한 번 시험해 달라고 요청해 보세요.
- 01백업 목록에서 가장 최근 날짜가 예정대로 남아 있는지 확인해요.
- 02백업 크기를 지난번과 비교해요. 갑자기 크게 줄었다면 일부가 빠졌을 수 있어요.
- 03운영 중인 홈페이지가 아닌 테스트 공간에 백업을 되돌려 봐요.
- 04첫 페이지 · 사진 · 게시글 · 예약 기록이 모두 보이는지 확인해요.
- 05되돌리는 데 걸린 시간을 기록해 둬요. 실제 사고 때 얼마나 기다려야 하는지 알 수 있어요.
- 06결과와 다음 확인 날짜를 적어 두고, 분기에 한 번 정도 반복해요.
백업을 맡길 때 무엇을 확인해야 하나요?
가장 흔한 실수는 ‘호스팅이 알아서 해 주겠지’ 하고 확인하지 않는 거예요. 요금제에 따라 백업 주기, 보관 기간, 복원 비용이 모두 달라서, 직접 물어보고 답을 적어 두는 게 좋아요.
해지할 때 백업을 받을 수 있는지도 꼭 확인하세요. 업체를 바꾸는 순간 그 업체 서버에만 있던 백업은 함께 사라질 수 있어요.
‘얼마나 빨리 되돌릴 수 있나’도 함께 물어보세요. 백업이 있어도 되돌리는 데 며칠이 걸린다면 그동안 예약 · 주문을 받을 수 없어요. 급한 장애 때 응대 시간과 복원에 걸리는 시간을 미리 알아 두면 실제 사고 때 덜 당황해요.
- 얼마나 자주 백업하고, 몇 시점까지 보관하나요?
- 백업은 홈페이지 서버와 다른 곳에 있나요?
- 데이터베이스와 올린 사진도 함께 백업하나요?
- 되돌려야 할 때 어디로 요청하고, 얼마나 걸리고, 비용이 드나요?
- 백업 파일의 암호나 접근 권한은 누가 갖고 있나요?
- 계약을 끝낼 때 마지막 백업을 넘겨받을 수 있나요?
작은 가게에서는 백업이 언제 실제로 필요해지나요?
가장 흔한 순간은 사람의 실수예요. 직원이 관리자 화면에서 메뉴를 정리하다 지난 공지를 통째로 지우거나, 업데이트 뒤 화면이 깨졌을 때 백업이 있으면 바로 전 상태로 돌아갈 수 있어요.
예약을 받는 홈페이지라면 서버 문제가 생긴 날 그날 들어온 예약 목록이 가장 중요해요. 마지막 백업 이후 들어온 예약은 되돌릴 수 없으니, 예약 알림 문자나 메일을 함께 남겨 두면 빈칸을 채울 수 있어요.
온라인 결제를 받는다면 주문 · 결제 기록은 결제 대행사(PG) 관리 화면에도 남아요. 홈페이지 데이터가 사라져도 그 기록으로 주문을 맞춰 볼 수 있으니, 결제 대행사 관리자 계정도 계정 목록에 꼭 넣어 두세요.
이시모 유지관리 구독에서는 매달 보안 업데이트와 함께 백업을 남겨요. 예약 · 주문처럼 기록이 매일 쌓이는 홈페이지라면 미팅에서 백업 주기를 따로 확인해 주세요.
예를 들면
- 직원이 관리자 화면에서 갤러리 사진을 통째로 지웠는데, 전날 백업으로 되돌린 공방.
이것만 확인하세요
- 백업을 누가, 얼마나 자주 하는지
- 백업이 홈페이지와 다른 곳에 보관되는지
- 되돌려야 할 때 누구에게 연락하는지
우리 가게엔?
모든 홈페이지에 필요해요.
이시모에서는
유지관리 구독에서 매달 보안 업데이트와 함께 백업을 남겨요. 문제가 생기면 백업해 둔 시점으로 되돌릴 수 있어요.
유지관리 보기자주 묻는 질문
참고한 자료
마지막으로 고친 날