Tag: snapper

Snapper 설치.

우분투 18.04 에 제공되는 Snapper 는 0.5.4 인데, 최신판은 0.8.9 이다. 0.5.4 가 공개된 게 18년 1월 29일이었으니, 딱 2년이 지났다. 무슨 차이가 있는지는 잘 알 수 없지만, 아무튼 이렇게 개발이 활발하게 이뤄지고 있다면, 최신판을 설치하는게 좋지 않겠나. Launchpad PPA 는 없는 듯 하지만, 다행히 OBS 에서 폭넓게 각종 배포판을 지원하고 있다. 언젠가 OBS 사용법도

Snapper, 용어 설명 및 기초 개념.

tldr; 중요한 점은 한가지다.스냅샷은 자동생성되고, 자동생성된 스냅샷들은 시간이 지남에 따라 알아서 지워진다.물론, 수동생성한 스냅샷은 자동삭제되지 않는다. Snapper 에 의해 생성된 Snapshot 은 크게 두가지다. apt 등을 실행했을 때 자동생성되는 스냅샷과, 한시간에 한번씩 만들어지는 스냅샷. 이 두 스냅샷은 영구 보존되는게 아니고, 미리 설정한 기준에 의해 시간이 지남에 따라 예전 것들부터 자동 삭제된다. 진작에 알아봤어야 하는 걸,

Snapshot/Snapper: var 디렉토리 처리 문제.

tldr; 세련된 해결책은 아닐 듯 하지만, /var/lib/dpkg 디렉토리를 루트에 포함시키는 방법을 택해봤다. 아직까지 Snapper 를 제대로 쓰고 있진 않지만, 그저 분위기만 보고 있는 상황에선, 예전에 쓴 글 대로 @snapshots 서브볼륨을 따로 만들고 .snapshots 에 마운트해서 사용하는 방법이 제일 좋아 보인다. (이 문장.. 너무 길다.) 또, Btrfs Ubuntu server 에서처럼, 서브볼륨은 Flat 으로 설정(FS Root 아래에

OpenSuse: 왜 서브볼륨 마운트가 필요할까?

** 글을 쓰기 시작할 때만 해도 이 글에 대한 답을 구하지 못했었다. 그런데, 글을 쓰던 중, 답이 보였다. tldr;var, home 등 서브볼륨이 초기 root 디렉토리인 @ 산하에 있음에도 서브볼륨 마운트가 필요한 이유는, Snapper 때문이다.Snapper 가 실행되면서 루트 디렉토리가 수시로 바뀌기 때문에, 최초엔 @ 산하에 있어서 서브볼륨 마운트를 하지 않더라도 같은 결과가 나오지만, 나중엔 반드시 마운트를

Snapper 가 생성한 btrfs subvolume 순차 삭제 (Recursive Deletion)

예를 들어, 아래와 같이 Btrfs Subvolume 이 있다고 가정해본다. 눈에 확 들어오지는 않기 때문에, 위 상황을 아래와 같이 표현해 보도록 한다. @snapshot 이라는 서브볼륨이 있고, 그 아래에 이름이 1,2,3… 인 ‘디렉토리‘들이 있으며, 각각 디렉토리안에 snapshot 으로 명명된 서브볼륨들이 존재한다.toplevel 271(@snapshots) 하에 숫자로된 디렉토리/snapshot 들이 있음을 볼 수 있다. (눈에 잘 안들어와서 그렇지.) 지금 나는, 저

snapper, 사용법 및 config 이름 고치기.

자세한 사용법은 알아내는 대로 정리해보기로 하고..일단은 꼭 필요한 내용을 먼저 기록한다.다른 글에서도 이에 대해 정리했다. (다소 이 글과 중복된 내용이긴 하지만..) Snapper 의 기본은 루트 디렉토리에 대한 보관이다. 그런데, 자주 바뀌는 파일들(프로그램 파일, 캐시, /var/log, /var/tmp 등등은 굳이 보관할 필요도 없을 뿐더러, 성능 문제도 있다.이런 디렉토리들을 서브볼륨으로 만들고 Snapper 가 root 를 snapshot 할 때

꽃삽질 : Snapper, Btrfs snapshot 의 문제점 돌아가기

Snapper 기본 설정의 문제점 파악 Btrfs Snapshot 을 사용하면, 손쉽게 복사본(?)을 만들 수 있다. 완전한 복사본이라 말하기엔 애매한 부분도 있지만, 아무튼 충분히 원하는 효과를 얻을 수는 있다. 문제는, 단순히 ‘보관’을 위한 작업을 위해서는 Snapshot 이 최선의 방법이지만, 만약, 이전 상태로 되돌아가려고 한다면(Rollback), 조금 더 복잡한 방법을 생각해내야 한다는 데에 있다. 이런 필요에서 나온게 Snapper 라는