Btrfs 스냅샷과 Snapper로 시스템 안전망 만들기

패키지 업데이트 한 번 잘못 걸리면 로그인 화면조차 뜨지 않는 상황, 리눅스를 쓰다 보면 한 번쯤 겪게 돼요. NixOS나 불변 배포판들이 세대(generation) 개념으로 이 문제를 해결한다면, 전통적인 배포판 진영에서는 Btrfs 스냅샷이 같은 문제에 대한 답을 내놔요. openSUSE가 기본으로 채택하면서 유명해진 이 조합인데, 그렇다면 Btrfs 스냅샷과 Snapper는 실제로 어떻게 시스템 안전망을 만들어줄까요?

Btrfs는 Copy-on-Write 구조로 스냅샷을 가능하게 한다

Btrfs는 ext4 같은 전통적인 파일시스템과 달리 Copy-on-Write(CoW) 구조로 설계됐어요. 파일을 수정할 때 원본을 덮어쓰지 않고 변경된 블록만 새로 쓰는 방식이라, “현재 상태를 그대로 가리키는 포인터”를 만드는 것만으로도 스냅샷 생성이 가능해져요. 그래서 스냅샷 생성이 사실상 즉시 끝나고, 변경되지 않은 데이터는 중복 저장되지 않아 공간도 효율적으로 쓸 수 있어요.

결론부터 말하면 스냅샷은 파일을 통째로 복사하는 백업이 아니라, 이 시점의 파일시스템 상태를 기억해두는 저비용 체크포인트에 가까워요.

Snapper는 스냅샷을 자동화하는 도구다

Snapper는 Btrfs의 스냅샷 기능을 언제 찍고 언제 지울지 관리해주는 도구예요. Btrfs 자체는 스냅샷 기능만 제공할 뿐, 스케줄링과 정리는 별도 도구가 맡아야 하는데 그 역할을 Snapper가 해줘요.

# 패키지 설치/업데이트 전후 자동 스냅샷 생성
transactional-update 또는 zypper 트랜잭션 훅에 의해 자동 실행

# 수동으로 스냅샷 목록 확인
snapper list

# 특정 스냅샷과 현재 상태의 차이 확인
snapper diff 42..43

openSUSE에서는 zypper로 패키지를 설치하거나 업데이트할 때마다 Snapper가 자동으로 전/후 스냅샷을 생성해요. 문제가 생기면 부트로더(GRUB) 메뉴에 스냅샷 목록이 자동으로 추가되기 때문에, 재부팅만으로 이전 상태로 돌아갈 수 있어요.

실제 장애 복구는 재부팅 한 번으로 끝난다

실제 장애 복구는 재부팅 한 번과 명령어 하나로 끝나요. 시스템 업데이트를 실행하면 Snapper가 업데이트 전 스냅샷을 자동으로 만들어두는데, 이후 그래픽 드라이버 충돌로 로그인 화면 진입에 실패했다고 해봐요. 그러면 재부팅 후 GRUB 메뉴에서 “Snapshot 43 이전 상태로 부팅”을 선택하면 되고, 정상적으로 이전 상태로 부팅되는 걸 확인한 뒤 snapper rollback으로 해당 스냅샷을 기본 부팅 대상으로 확정하면 돼요.

이 과정이 별도의 백업 매체나 복구 USB 없이 몇 분 안에 끝난다는 점이 Btrfs+Snapper 조합의 가장 큰 실용적 가치예요.

다른 배포판에서도 openSUSE 없이 쓸 수 있다

openSUSE가 아니어도 Btrfs와 Snapper 조합은 충분히 구성할 수 있어요.

openSUSE: 설치 시 기본으로 완전히 통합돼 있어서 별도 설정이 거의 필요 없어요.
Fedora, Debian, Arch 등: Btrfs를 루트 파일시스템으로 선택하고 Snapper를 직접 설치하면 유사하게 구성할 수 있지만, 부트로더 통합은 수동 설정이 필요해요.
ext4 사용자: 이 기능 자체를 아예 쓸 수 없기 때문에, 스냅샷이 중요하다면 설치 단계에서 파일시스템으로 Btrfs를 선택해야 해요.

결국 실험적인 사용자에게 특히 유용한 안전망이다

Btrfs 스냅샷과 Snapper는 이것저것 실험적으로 설치해보고 싶은데 시스템이 망가질까 걱정되는 사람에게 특히 유용한 안전망이에요. 롤백이 가능하다는 심리적 안정감 덕분에 실제로 더 적극적으로 시스템을 다뤄볼 수 있게 되는, 생각보다 실사용 임팩트가 큰 기능이에요. openSUSE의 Leap과 Tumbleweed 중 어떤 걸 쓰든 이 안전망은 동일하게 작동한다는 점도 큰 장점이에요.