restic 실전 입문: 암호화 백업부터 복원 검증까지
로컬 파일을 암호화 스냅샷으로 저장하고 실제 복구까지 점검하는 절차를 정리했다. 저장소 암호, 보존 정책, 원격 권한의 운영 한계도 짚는다.
restic은 파일을 암호화한 스냅샷으로 보관하고 중복 데이터를 줄이는 명령줄 백업 프로그램이다. 공식 GitHub API를 2026년 9월 28일(한국시간) 확인한 결과 스타 36,296개, archived=false, 마지막 push 2026년 9월 25일 20:08 UTC, 라이선스 BSD-2-Clause였다. 최신 정식 GitHub 릴리스 v0.19.1은 2026년 7월 5일 08:13 UTC에 게시됐다. 관심도를 나타내는 스타는 보안이나 복구 성공을 보증하지 않는다.
해결하는 문제
단순 파일 복사는 특정 시점의 상태와 실제 복원 가능성을 관리하기 어렵다. restic은 저장소에 시간별 스냅샷을 기록하고 로컬 디렉터리 또는 지원하는 원격 저장소에 보관한다. 개인 개발자의 작업 파일이나 서버 설정 파일을 주기적으로 백업하고 다른 위치에 되살릴 때 적합하다. 다만 데이터베이스의 트랜잭션 일관성까지 자동 보장하지 않는다. 운영 DB는 서비스가 권장하는 일관된 덤프를 만든 뒤 백업해야 한다.
설치 전제
아래는 macOS(Homebrew 설치됨) 또는 Debian/Ubuntu(패키지 관리자 사용 가능)의 POSIX 셸과 로컬 저장소를 전제로 한 공식 문서 기준 예제다. 작성자가 직접 실행하지 않았다. 패키지 저장소의 버전은 v0.19.1과 다를 수 있으므로 설치 후 버전을 확인하고 옵션 차이가 있으면 해당 버전 도움말을 확인한다. Windows는 공식 설치 문서의 Scoop/WinGet와 PowerShell 명령을 사용한다. 저장소를 원본과 다른 물리 디스크에 두어야 동일 디스크 장애를 피할 수 있다.
# macOS: Homebrew가 있을 때
brew install restic
restic version
# Debian/Ubuntu에서는 별도로: sudo apt-get update && sudo apt-get install restic첫 저장소와 백업
다음 경로는 기존 자료가 없는 시험용 경로일 때만 사용한다. 이미 같은 이름의 디렉터리가 있으면 다른 이름으로 바꾼다. init에서 암호를 두 번 입력하고 이후 명령에도 같은 암호를 제공한다. 암호를 잃으면 저장소의 데이터를 복원할 수 없으므로 안전한 별도 장소에 보관한다. 시험 저장소를 원본과 같은 홈 디렉터리에 두는 것은 연습용이며 실제 장애 대비 배치는 아니다.
mkdir -p "$HOME/restic-demo-src"
printf 'backup test\n' > "$HOME/restic-demo-src/example.txt"
restic -r "$HOME/restic-demo-repo" init
restic -r "$HOME/restic-demo-repo" backup "$HOME/restic-demo-src"
restic -r "$HOME/restic-demo-repo" snapshots정상적이면 저장소 생성 안내, 백업 후 새 스냅샷 ID, 스냅샷 목록의 시간·백업 경로가 차례로 표시된다. -r은 저장소 경로다. 운영 자동화에서는 공식 문서의 RESTIC_REPOSITORY 또는 --repository-file로 저장소 위치를 지정할 수 있다. 암호는 매번 입력하는 대신 엄격한 파일 권한을 갖춘 --password-file 또는 비밀 관리 도구와 연결된 --password-command를 고려한다. 암호를 인수에 직접 쓰거나 공유 로그에 남기지 말고 환경변수와 암호 파일도 프로세스·백업 범위의 노출 위험을 점검한다.
복원 검증
스냅샷 목록만 확인하지 말고 원본이 아닌 새 폴더에 복원한다. latest는 가장 최근 스냅샷을 가리키므로 여러 호스트와 경로가 섞인 저장소에서는 snapshots로 목적에 맞는 스냅샷 ID를 찾아 바꾼다. 절대경로로 백업한 파일은 대상 디렉터리 아래에 원래 경로 구조가 이어진다.
restic -r "$HOME/restic-demo-repo" check
restic -r "$HOME/restic-demo-repo" restore latest --target "$HOME/restic-demo-restore"
find "$HOME/restic-demo-restore" -type f -name example.txt -exec cat {} \;마지막 출력이 backup test인지 확인한다. check는 저장소 구조를 점검하지만 기본 검사만으로 모든 파일 데이터를 읽어보는 것은 아니다. 중요한 자료는 공식 문서의 데이터 검사 옵션과 주기적인 실제 복원 테스트를 별도로 계획한다. 복구를 기존 원본 경로에 곧바로 덮어쓰지 않는다.
정책과 비용
스냅샷은 반복 백업할수록 누적된다. 공식 문서는 restic forget --keep-daily 5 --dry-run으로 보존 정책의 대상을 미리 살피는 예를 제공한다. forget으로 스냅샷 참조를 지우는 작업과 prune으로 미사용 데이터를 정리하는 작업은 다르다. 운영 저장소에서 실제 삭제나 --prune을 적용하기 전에 보존 기간, 다른 호스트의 스냅샷, 독립적인 사본을 확인해야 한다. 여기에는 파괴적 정리 명령을 넣지 않았다. 저장 공간과 원격 전송량에는 비용이 들고 큰 저장소 점검은 시간이 걸린다. 백업 서비스나 SSH 계정의 쓰기·삭제 권한은 저장소 암호와 별개다. 저장소 삭제에 대비해 권한 분리와 별도 사본을 둔다.
오류와 되돌리기
암호 입력 뒤 저장소를 열 수 없다면 -r 경로·저장소 접근 권한·암호를 확인한다. 파일이 누락됐다면 백업 입력 경로, 읽기 권한, exclude 설정을 확인하고 backup --dry-run으로 범위를 미리 본다. 잠금 오류가 나면 실제 다른 백업·정리 작업이 진행 중인지 조사한 뒤 처리해야 하며 동작 중인 잠금을 임의로 풀지 않는다. check 오류가 나면 원본과 다른 사본을 보존한 상태에서 공식 문제 해결 절차를 검토한다.
연습 후 파일을 정리할 때는 각 경로가 실제 시험 데이터인지 확인한 후 수동으로 제거한다. 이 문서에는 삭제 명령을 넣지 않았다. Homebrew 설치는 brew uninstall restic, Debian 계열 설치는 sudo apt-get remove restic으로 되돌릴 수 있다. 프로그램 제거가 저장소를 자동 삭제하지는 않지만 저장소나 암호를 잃으면 복원할 수 없다.
