블로그 테마를 고치기 전에 원본을 통째로 받아 뒀습니다. 결국 되돌릴 일은 없었지만, 그 파일이 있어서 마음 놓고 고쳤습니다. 백업을 어떻게 받았고 무엇을 확인했는지 적습니다.
왜 필요했나
10만 자가 넘는 테마 파일에서 두 군데를 고치는 작업이었습니다. 인증키가 적힌 줄과, 자료를 받아 오는 함수 하나.
양은 적지만 잘못되면 블로그 화면이 통째로 안 나옵니다. 그리고 편집기에는 ‘되돌리기’가 몇 단계밖에 없습니다. 저장하고 창을 닫으면 그마저도 사라집니다.
‘비슷한 파일’은 백업이 아니다
처음엔 이미 갖고 있던 사본을 백업으로 쓰려고 했습니다. 예전에 정리해 둔 파일이 있었으니까요.
확인해 보니 224자가 달랐습니다. 그 사본은 인증키 등을 가려 둔 상태였고, 그 외에도 손댄 곳이 있었습니다. 이걸로 되돌리면 원래대로가 아니라 ‘비슷한 상태’가 됩니다.
그래서 편집기에서 지금 내용을 그대로 꺼내 저장했습니다. 길이가 정확히 일치하는지 확인하고 나서야 백업으로 인정했습니다.
고친 뒤에 확인한 것
바꾼 파일을 넣기 전에 로컬에서 먼저 검사했습니다.
- 인증키가 없는지 — 0건
- 원래 API 주소가 없는지 — 0건
- 대신 넣은 주소가 있는지 — 있음
- 예비 화면 코드가 살아 있는지 — 있음
이걸 다 통과한 다음에야 붙여 넣었습니다. 붙여 넣고 나서 확인하면 이미 늦습니다.
넣은 뒤에도 한 번 더
저장한 다음 실제 공개 페이지를 받아서 검사했습니다. 편집기에서 잘 보이는 것과 방문자에게 나가는 것이 같다는 보장이 없어서입니다.
여기서 한 번 헛다리를 짚었습니다. 엉뚱한 주소를 검사하고 “적용이 안 됐네”라고 판단했습니다. 알고 보니 다른 블로그 주소였습니다. 설정에서 실제 주소를 확인하고서야 맞았습니다.
백업 파일도 관리해야 한다
작업이 끝나고 알아차린 게 있습니다. 그 백업 파일 안에는 예전 인증키가 그대로 들어 있습니다. 고치기 전 상태니 당연합니다.
즉 비밀이 담긴 파일이 하나 더 생긴 셈입니다. 공유 폴더에 두면 안 되고, 되돌릴 일이 없다고 판단되면 지워야 합니다. 백업을 만드는 것까지만 생각하고 그 뒤는 안 챙기기 쉽습니다.
정리
백업은 파일을 하나 만드는 일이 아니라 되돌릴 수 있는 상태를 만드는 일입니다. 길이가 맞는지 확인하지 않으면 파일만 있고 되돌릴 수는 없습니다.
공식 안내는 백업을 어떻게 설명하나
Blogger 도움말의 "블로그 백업 또는 가져오기" 문서는 테마 사본 저장 순서를 이렇게 안내합니다. Blogger에 로그인해 블로그를 고르고, 왼쪽 메뉴의 테마로 들어가 '맞춤설정' 버튼 옆 화살표에서 백업을 선택한 뒤 대화상자의 다운로드를 누르면 됩니다. 같은 문서는 글은 별도 백업이라고 구분합니다. 글 내용은 Google 테이크아웃으로 받고, 글·페이지·댓글은 설정의 콘텐츠 가져오기에서 올려 되살립니다. 따라서 테마 백업만 있다고 글까지 지켜지는 것은 아닙니다. 한편 이 문서에는 테마를 복원하는 방법이 적혀 있지 않았으므로, 복원 절차는 이 글에서 단정하지 않습니다. (Blogger 도움말: 블로그 백업 또는 가져오기)
미국 사이버보안 인프라보안국(CISA)의 중소기업용 안내는 백업 원칙을 더 일반적으로 설명합니다. 중요한 파일은 3개 사본을 두고, 하드디스크와 클라우드처럼 서로 다른 두 종류의 저장 매체에 나누며, 하나는 장소 밖에 보관하라고 합니다. 백업은 물리적 보안, 암호화, 오프라인 사본으로 보호하라고 하고, 데이터를 전체와 일부 모두 복원할 수 있는지, 최소 7일 전 상태로 되돌릴 수 있는지, 복구 시험을 일정에 따라 하는지 확인하라고 합니다. (CISA: 사업 데이터 백업)
| 공식 안내의 내용 | 이 글의 경험과 이어지는 점 |
|---|---|
| 테마와 글은 별도 백업 (Blogger 도움말) | 테마 파일만 받아 두면 글 내용까지 지켜지지는 않음 |
| 복구 시험으로 복원 가능 여부 확인 (CISA) | 길이가 같은지 대조해 "되돌릴 수 있는 사본"인지 확인 |
| 백업을 물리적 보안·암호화·오프라인으로 보호 (CISA) | 예전 인증키가 든 백업 파일 자체도 보관 위치를 관리해야 함 |
확인 자료
공식 문서 기준일: 2026-10-18