본문 바로가기
리눅스

snapper (software)

by 다움위키 2023. 12. 9.

Snapper는 Btrfs 서브볼륨과 씬-프로비저닝된 LVM 볼륨의 스냅샷을 관리하는 데 도움이 되는 오픈수저의 Arvin Schnell에 의해 만들어진 도구입니다. 그것은 스냅샷을 생성하고 비교하고 스냅샷 사이를 되돌릴 수 있고, 자동 스냅샷 타임라인을 지원합니다.

Installation

우분투 공식 저장소에서 설치할 수 있습니다:

  • sudo apt install snapper

그래픽 사용자 인터페이스를 가진 도구를 역시 설치할 수 있습니다:

  • sudo apt install snapper-gui

Creating a new configuration

Btrfs 서브볼륨에 대한 스내퍼 구성을 생성하기 전에, 서브볼륨이 반드시 존재하고 있어야 합니다. 만약 그렇지 않으면, 스내퍼 구성을 생성하기 전에 서브볼륨을 생성해야 합니다.

/path/to/subvolume의 Btrfs 서브볼륨에 대해 config라는 새로운 스내퍼 구성을 생성하기 위해, 다음을 실행하십시오:

# snapper -c config create-config /path/to/subvolume

이것은 다음일 것입니다:

  • /usr/share/snapper/config-templates의 기본 템플릿을 기반으로 /etc/snapper/configs/config에 구성 파일을 만듭니다.
  • 이 구성에 대한 앞으로 스냅샷이 저장될 /path/to/subvolume/.snapshots에 서브볼륨을 만듭니다. 스냅샷의 경로는 /path/to/subvolume/.snapshots/#/snapshot이며, 여기서 #은 스냅샷 번호입니다.
  • /etc/conf.d/snapper에서 SNAPPER_CONFIGS에 config를 더합니다.

예를 들어, /에 마운트된 서브볼륨에 대한 구성 파일을 생성하기 위해, 다음을 실행하십시오:

# snapper -c root create-config /

이 시점에서, 구성이 활성화됩니다. 만약 cron 데몬이 실행 중이면, 스내퍼는 자동 타임라인 스냅샷을 생성할 것입니다. 만약 cron 데몬을 사용하지 않으면, systemd 서비스와 타이머를 사용해야 할 것입니다. #Enable/disable를 참조하십시오.

역시 snapper-configs 매뉴얼을 참조하십시오.

Taking snapshots

Automatic timeline snapshots

스냅샷 타임라인은 시간별, 일별, 주별, 월별 및 연별 스냅샷을 구성가능한 숫자로 유지하게 생성될 수 있습니다. 타임라인이 활성화될 때, 기본적으로 스냅샷은 한 시간에 한 번 생성됩니다. 하루에 한 번 스냅샷은 타임라인 정리 알고리듬에 의해 청소됩니다. 자세한 내용에 대해 snapper-configs 메뉴얼에서 TIMELINE_* 변수를 참조하십시오.

Enable/disable

만약 크론 데몬이 있으면, 이 기능이 자동으로 시작되어야 합니다. 비활성화하려면, 이 기능을 원하지 않는 서브볼륨에 해당하는 구성 파일을 편집하고 다음을 설정하십시오:

TIMELINE_CREATE="no"

만약 크론 데몬이 없으면, 제공된 시스템 단위를 사용할 수 있습니다. 자동 스냅샷 타임라인을 시작하기 위해 snapper-timeline.timer를 시작하고 활성화하십시오. 추가적으로, 주기적으로 이전 스냅샷을 정리하기 위해 snapper-cleanup.timer를 시작하고 활성화하십시오.

만약 크론 데몬이 있고 systemd 장치도 활성화하면, 중복 스냅샷이 생성될 수 있습니다.

Set snapshot limits

기본 설정은 시간당 10개, 매일 10개, 월간 10개, 및 연간 스냅샷 10개를 유지할 것입니다. 구성, 특히 /와 같은 사용량이 많은 서브볼륨에서 이것을 변경하기를 원할 수 있습니다. #Preventing slowdowns를 참조하십시오.

다음은 시간별 5개의 스냅샷, 일별 7개의 스냅샷, 월간 및 연간 스냅샷이 없는 /etc/snapper/configs/config라는 구성의 예제 섹션입니다:

TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="5"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

Change snapshot and cleanup frequencies

만약 제공된 systemd 타이머를 사용하면, 스냅샷과 청소 빈도를 변경하기 위해 이것을 편집할 수 있습니다.

예를 들어, snapper-timeline.timer를 편집할 때, 시간별이 아닌 매 5분마다 빈도를 지정하기 위해 다음을 더하십시오:

[Timer]
OnCalendar=
OnCalendar=*:0/5

snapper-cleanup.timer를 편집할 때, OnUnitActiveSec을 변경해야 합니다. 매일이 아닌 매시간 청소를 수행하도록 만들기 위해, 다음을 추가하십시오:

[Timer]
OnUnitActiveSec=1h

Manual snapshots

Simple snapshots

기본적으로 스내퍼는 다른 스냅샷과 특별한 관계를 가지지 않는 simple 유형의 스냅샷을 만듭니다.

서브볼륨의 스냅샷을 수동으로 생성하기 위해 다음을 수행하십시오:

$ sudo snapper -c config create --description desc

위의 명령은 청소 알고리듬을 사용하지 않으므로, 스냅샷은 영구적으로 또는 삭제될 때까지 저장됩니다.

청소 알고리듬을 설정하기 위해, create 뒤에 -c 플래그를 사용하고 number, timeline, pre, 또는 post를 선택하십시오. number는 구성 파일에서 설정한 숫자를 초과한 스냅샷을 주기적으로 제거하도록 스내퍼를 설정합니다. 예를 들어 정리를 위해 number 알고리듬을 사용하는 스냅샷을 만들려면 다음을 수행하십시오:

$ sudo snapper -c config create -c number

timeline 스냅샷의 작동 방식에 대해 #Automatic timeline snapshots를 참조하시고 pre 및 post 작동 방식은 #Pre/post snapshots을 참조하십시오.

Pre/post snapshots

simple 스냅샷 외에도 pre/post 스냅샷을 생성할 수도 있으며 여기서 pre 스냅샷은 항상 해당하는 post 스냅샷을 가집니다. 이들 쌍의 목적은 시스템 수정 전후에 스냅샷을 생성하는 것입니다.

pre/post 스냅샷 쌍을 생성하기 위해, 먼저 pre 스냅샷을 생성하십시오:

$ sudo snapper -c config create -t pre -p

인쇄된 스냅샷 번호를 기록해 두어야 하는데, 왜냐하면 post 스냅샷에서 필요하기 때문입니다.

그런-다음 시스템 수정을 수행하십시오 (*예를 들어*, 새로운 프로그램을 설치, 업그레이드 등.).

이제 post 스냅샷을 생성하십시오:

$ sudo snapper -c config create -t post --pre-number N

여기서 N은 해당하는 pre 스냅샷 번호입니다.

대안적인 방법은 pre/post 스냅샷으로 명령을 래핑하는 create에 --command 플래그를 사용하는 것입니다:

$ sudo snapper -c config create --command cmd

여기서 cmdpre/post 스냅샷을 래핑하기를 원하는 명령입니다.

Snapshots on boot

스내퍼가 root 구성의 스냅샷을 얻도록 하기 위해, snapper-boot.timer를 활성화하십시오.

Managing snapshots

List snapshots

주어진 구성 config에 대해 생성된 스냅샷을 나열하기 위해 다음을 수행하십시오:

$ sudo snapper -c config list

List configurations

생성되어 온 모든 구성을 나열하기 위해 다음을 수행하십시오:

$ sudo snapper list-configs

Delete a snapshot

스냅샷 번호 N을 삭제하기 위해 다음을 수행하십시오:

$ sudo snapper -c config delete N

한 번에 여러 스냅샷을 삭제할 수 있습니다. 예를 들어, root 구성의 스냅샷 65와 70을 삭제하기 위해 다음을 수행하십시오:

$ sudo snapper -c root delete 65 70

스냅샷 범위를 삭제하기 위해, 이 예제에서 root 구성의 스냅샷 65와 70 사이의 스냅샷을 삭제하기 위해 다음을 수행하십시오:

$ sudo snapper -c root delete 65-70
pre 스냅샷을 삭제할 때, 항상 해당하는 post 스냅샷을 삭제되어야 하고 그 반대도 마찬가지입니다.

Access for non-root users

각 구성은 루트 사용자로 생성되고, 기본적으로, 오직 루트 사용자가 볼 수 있고 접근할 수 있습니다.

특정 사용자에 대해 주어진 config에 대한 스냅샷을 나열하도록 하려면, 간단히 /etc/snapper/configs/config 파일에서 ALLOW_USERS 값을 변경하십시오. 이제 일반 사용자로 snapper -c config list를 실행할 수 있습니다.

결국, 사용자로 .snapshots 디렉토리를 탐색할 수 있기를 원할 수 있지만, 이 디렉토리의 소유자는 루트로 남겨 두어야 합니다. 따라서, 다음과 같이 관심 있는 사용자를 포함한 그룹에 대해 그룹 소유자를 변경해야 하는데, 예를 들어, users 그룹에 대해,

# chmod a+rx .snapshots
# chown :users .snapshots

Tips and tricks

Incremental backup to external drive

다음 패키지는 외부 드라이브에 점진적으로 백업을 보내기 위해 btrfs send 및 btrfs receive을 사용합니다. 구현, 기능 및 요구 사항의 차이점을 보려면 해당 설명서를 참조하십시오.

  • btrbk – Btrfs 서브볼륨의 스냅샷 및 원격 백업을 만들기 위한 도구입니다.
  • buttersink – Buttersink는 Btrfs 스냅샷에 대한 rsync와 같습니다.
  • snap-sync – 스내퍼 스냅샷을 외부 드라이브 또는 원격 시스템에 백업하기 위해 사용하십시오.
  • snapsync – 스내퍼에 대한 동기화 도구.

다음 패키지는 스내퍼 스냅샷을 Btrfs가 아닌 파일 시스템에 백업하는 것을 허용합니다.

  • snapborg – 스내퍼 스냅샷을 borg 백업과 통합하는 보그매틱-계열 도구입니다.

Suggested filesystem layout

다음 레이아웃은 스내퍼 롤백과 함께 사용하기 위한 것이 아니라, 해당 명령으로 /를 복원할 때 발생하는 고유한 문제를 완화하기 위한 것입니다. 아치 포럼 스레드를 참조하십시오.

다음은 루트에 마운트된 서브볼륨 @을 이전 스냅샷으로 쉽게 복원하기 위한 제안된 파일 시스템 레이아웃입니다:

파일시스템 레이아웃
서브볼륨 마운트-지점
@ /
@home /home
@snapshots /.snapshots
@var_log /var/log
subvolid=5
  |
  ├── @ -|
  |     contained directories:
  |       ├── /usr
  |       ├── /bin
  |       ├── /.snapshots
  |       ├── ...
  |
  ├── @home
  ├── @snapshots
  ├── @var_log
  └── @...

서브볼륨 @...은 자체의 서브볼륨을 가져야 하는 임의의 다른 디렉토리에 마운트됩니다.

  • (루트 /에 마운트된) @의 스냅샷을 얻을 때, 다른 서브볼륨은 스냅샷에 포함되지 않습니다. 심지어 서브볼륨이 @ 아래에 중첩되더라도, @의 스냅샷에는 그것이 포함되지 않을 것입니다. @ 이외에 스냅샷을 유지하기를 원하는 추가 서브볼륨에 대한 스내퍼 구성을 생성하십시오.
  • Btrfs 제한으로 인해, 스냅샷 볼륨에는 스왑 파일이 포함될 수 없습니다. 스왑 파일을 또 다른 서브볼륨에 넣거나 스왑 파티션을 만드십시오.

만약 시스템을 @의 이전 스냅샷으로 복원하기를 원하면, 이들 다른 서브볼륨은 영향을 받지 않고 남겨질 것입니다. 예를 들어, 이것은 /home을 변경하지 않고 유지하면서 @를 이전 스냅샷으로 복원할 수 있는데, 왜냐하면 그것은 /home에 마운트된 서브볼륨이기 때문입니다.

이 레이아웃은 스냅퍼 유틸리티에게 /의 정기적인 스냅샷을 얻는 것을 허용하는 동시에, 만약 그것이 부팅할 수 없게 되면 우분투 라이브 시디로부터 /을 쉽게 복원할 수 있도록 합니다.

이 시나리오에서, 초기 설정 후, 스내퍼를 변경할 필요가 없고, 예상대로 작동할 것입니다.

Configuration of snapper and mount point

서브볼륨 @이 루트 /에 마운트되어 있다고 가정합니다. 역시 /.snapshots가 마운트되지 않고 폴더로 존재하지 않는다고 가정합니다. 이것은 다음 명령으로 확인될 수 있습니다:

$ sudo umount /.snapshots
$ sudo rm -r /.snapshots

그런-다음 /에 대한 새 구성을 만드십시오. 스내퍼 create-config는 루트 서브볼륨 @를 부모로 갖는 서브볼륨 .snapshots을 자동으로 생성하는데, 즉, 제안된 파일 시스템 레이아웃에 필요하지 않고, 삭제될 수 있습니다.

$ sudo btrfs subvolume delete /.snapshots

서브볼륨을 삭제한 후, /.snapshots 디렉터리를 다시 만드십시오.

$ sudo mkdir /.snapshots

이제, /.snapshots를 @snapshots에 마운트합니다. 예를 들어, /dev/sda1에 있는 파일 시스템에 대해:

$ sudo mount -o subvol=@snapshots /dev/sda1 /.snapshots

이 마운트를 영구적으로 만들려면, fstab에 항목을 추가하십시오.

또는 기존 fstab 항목이 있으면 스냅샷 서브볼륨을 다시 마운트하십시오:

$ sudo mount -a

폴드에 750 허가권을 부여하십시오.

이렇게 하면 스내퍼가 생성하는 모든 스냅샷이 @ 서브볼륨 외부에 저장되므로, @는 스내퍼 스냅샷을 잃지 않고 언제든지 쉽게 교체될 수 있습니다.

Restoring / to its previous snapshot

스내퍼의 스냅샷 중 하나를 사용하여 /를 복원하기 위해, 먼저 라이브 우분투 리눅스 USB/CD로 부팅하십시오.

최상위 서브볼륨을 마운트합니다 (subvolid=5). 즉, 임의의 subvolid 마운트 플래그를 생략하십시오.

/mnt/@snapshots/*/info.xml에서 복구하기를 원하는 스냅샷을 찾으십시오.

각 파일을 쉽게 탐색하기 위해 vi를 사용할 수 있습니다:

# vi /mnt/@snapshots/*/info.xml

다음 파일을 보기 위해 :n를 사용하시고 처음 파일로 되돌아 가기 위해 :rew를 사용하십시오.

<description> 태그와 <date> 태그를 탐색하고, 복원하려는 스냅샷을 찾으면 <num> 번호를 기억하십시오.

이제, @를 또 다른 위치 (예를 들어, /@.broken)로 옮겨서 현재 시스템의 복사본을 저장하십시오. 대안적으로, btrfs subvolume delete를 사용하여 간단히 @를 삭제하십시오.

가져온 읽기-전용 스냅샷 스내퍼의 읽기-쓰기 스냅샷을 생성하십시오:

# btrfs subvolume snapshot /mnt/@snapshots/#/snapshot /mnt/@

여기서 #는 복원하려는 스내퍼 스냅샷의 번호입니다. /는 이제 이전 스냅샷으로 복원되었습니다. 시스템을 재시작하십시오.

위에서 제안된 레이아웃에 대해 만들어진 자동 롤백 도구 snapper-rollback을 사용할 수도 있습니다. 시스템과 일치하도록 /etc/snapper-rollback.conf에서 구성 파일을 편집하십시오.

Deleting files from snapshots

만약 스냅샷 자체의 삭제없이 과거 스냅샷에서 특정 파일이나 폴더를 삭제하려를 원하면, snapperS는 스내퍼에 이 기능을 추가하는 스크립트입니다. 이 스크립트는 역시 스내퍼가 현재 지원하지 않는 여러 다른 방법으로 과거 스냅샷을 조작하기 위해 사용될 수 있습니다.

만약 추가 스크립트의 사용없이 하나의 파일을 제거하기를 원하면, 스냅샷 서브볼륨을 읽기-쓰기로 만드는 것이 필요하며, 다음과 같이 설정할 수 있습니다:

$ sudo btrfs property set /path/to/.snapshots/<snapshot_num>/snapshot ro false

ro=false를 확인하기 위해:

# btrfs property get /path/to/.snapshots/<snapshot_num>/snapshot
ro=false

이제 평소처럼 /path/to/.snapshots/<snapshot_num>/snapshot에서 파일을 수정할 수 있습니다. 쉘 루프를 스냅샷을 대량으로 작업하기 위해 사용할 수 있습니다.

Preventing slowdowns

시간이 지남에 따라 많은 시스템 업데이트가 발생하는 /와 같은 자주 쓰이는 파일 시스템에 큰 기간 동안 많은 스냅샷을 보관하는 것은 심각한 속도 저하를 초래할 수 있습니다. 다음과 같은 방법으로 예방할 수 있습니다:

  • /var/cache/apt, /var/tmp, 및 /srv와 같이 스냅샷으로 만들 가치가 없는 항목에 대한 서브볼륨 만들기
  • #Automatic timeline snapshots을 사용할 때 시간별/일별/월별/연간 스냅샷의 기본 설정을 편집하십시오.

updatedb

기본적으로, updatedb는 스내퍼에 의해 생성된 .snapshots 디렉토리도 인덱싱합니다 (mlocate를 참조하십시오). 만약 많은 스냅샷을 가지면, 이것은 심각한 속도 저하와 과도한 메모리 사용을 초래할 수 있습니다. /etc/updatedb.conf을 편집함으로써 updatedb를 색인을 생성으로부터 막을 수 있습니다:

PRUNENAMES = ".snapshots"

Disable quota groups

만약 예를 들어 snapper ls가 결과를 반환하기 위해 몇 분이 걸리면 이것으로부터, quota 그룹으로 인해 상당한 속도 저하가 발생했다는 보고를 받을 수 있습니다. 관련 문서를 참조하십시오.

quota 그룹이 활성화되었는지 여부를 확인하려면 다음 명령을 사용하십시오:

$ sudo btrfs qgroup show /

Quota 그룹은 그 경우에 다음처럼 비활성화될 수 있습니다:

$ sudo btrfs quota disable /

Count the number of snapshots

만약 quota 그룹을 비활성화해도 속도 저하에 도움이 되지 않으면, 스냅샷 개수를 점검해 보는 것이 도움이 될 수 있습니다. 이 작업은 다음과 같이 수행될 수 있습니다:

$ sudo btrfs subvolume list -s / | wc -l

Preserving log files

/의 스냅샷이 /var/log 디렉토리를 제외하도록 그것에 대한 서브볼륨을 생성하는 것을 권장합니다. 그렇게 하면 /의 스냅샷이 복원되더라도 로그 파일은 이전 상태로 되돌아가지 않을 것입니다. 이렇게 하면 남겨진 로르로부터 문제를 더 쉽게 해결할 수 있습니다.

Troubleshooting

Snapper reinstall

스내퍼를 지웠다가 다시 설치하고, 설정을 하려면, 오류가 발생합니다:

Creating config failed (creating btrfs subvolume .snapshots failed since it already exists).

아마도 이전에 스내퍼를 설치했다고 지웠다면, 이미, @snapshots 서브볼륨이 /.snapshots 디렉토리에 마운트되어 있을 것입니다.

  • sudo umount /.snapshots
  • sudo rm -rf /.snapshots
  • sudo snapper -c root create-config /
  • sudo mount -a
  • sudo snapper ls

Snapper logs

스내퍼는 모든 활동을 /var/log/snapper.log에 기록합니다 – 문제가 있다고 생각되면 먼저 이 파일을 확인하십시오.

만약 시간별/일별/주별 스냅샷에 문제가 있음면, 지금까지 가장 일반적인 원인은 cronie 서비스 (또는 사용 중인 크론 데몬)가 실행되지 않았기 때문입니다.

IO error

만약 스냅샷을 생성하려고 할 때 'IO Error'가 발생하면 스냅샷을 생성하려는 서브볼륨과 결합된 .snapshots 디렉토리가 서브볼륨인지 확인하십시오.

또 다른 가능한 원인은 .snapshots 디렉토리에 소유자로 루트가 없기 때문입니다(/var/log/snapper.log엣 Btrfs.cc(openInfosDir):219 - .snapshots must have owner root를 찾을 수 있을 것입니다).

Orphaned snapshots causing wasted disk space

스냅샷은 디스크에 여전히 존재하지만 스내퍼에 의해 추적되지 않는, 'lost'를 얻게 되는 스냅샷이 있을 수 있습니다. 이로 인해 많은 양의 저장소가 낭비되고, 설명되지 않은 디스크 공간이 발생할 수 있습니다. 이를 확인하려면, 다음 출력을 비교하십시오:

$ sudo snapper -c <config> list

$ sudo btrfs subvolume list -o <parent subvolume>/.snapshots 

첫 번째 목록에 없는 두 번째 목록에서 임의의 서브볼륨은 고아이고 수동으로 삭제될 수 있습니다.

External Resources