스냅숏 명령을 걸었는데 저장소가 SQLite 였다

목표

k3s 서버 한 대의 저장소가 SQLite(kine) 임을 확인하고, etcd 스냅숏이 거절되는 이유를 본 뒤 --cluster-init 재시작으로 내장 etcd 로 옮깁니다.
스냅숏을 토큰과 함께 백업하고 --cluster-reset 으로 복원해, 스냅숏 이후의 변경이 사라지고 이전 데이터가 어디에 남는지 기록합니다.

왜 중요한가

k3s 는 한 대로 시작하면 etcd 대신 SQLite 를 씁니다. 가볍고 빠르지만 여러 서버가 공유할 수 없고, k3s etcd-snapshot 같은 etcd 도구가 동작하지 않습니다.
그래서 "백업을 붙이자" 는 날에 처음으로 저장소가 무엇인지 확인하게 되고, 그때 선택지는 파일을 통째로 복사하는 SQLite 백업이거나 etcd 로 옮기는 것입니다.
etcd 로 옮기는 것은 재시작 한 번이지만, 복원은 "그 시점으로 되돌리기" 라서 스냅숏 이후에 만든 것은 사라집니다. 그리고 서버 토큰이 없으면 스냅숏은 쓸모가 없습니다.
이 실습은 그 세 가지 — 저장소 확인, 이전, 복원이 되돌리는 범위 — 를 진짜 k3s 에서 한 번씩 겪게 합니다. etcd 를 처음부터 쓰는 k0s 실습과 달리 저장소를 바꾸는 과정 자체를 다룹니다.

단계

1. 네임스페이스 k3s-ds 에 ConfigMap marker(stage=sqlite)를 만드세요. 그리고 /root/k3s-ds/datastore.json 에 datastore(sqlite 또는 etcd), db_files(/var/lib/rancher/k3s/server/db 의 파일 이름을 정렬한 배열), kine_table(state.db 안의 테이블 이름 중 kine 이 쓰는 것), kine_endpoint(k3s 로그의 Kine available at 뒤의 주소), marker_uid(marker 의 UID)를 적으세요.
2. 지금 상태에서 k3s etcd-snapshot save 를 실행하고 표준 출력과 표준 오류를 함께 /root/k3s-ds/snapshot-refused.txt 에 저장하세요. 그리고 /root/k3s-ds/sqlite-backup.txt 에 SQLite 저장소를 백업하려면 복사해야 하는 디렉터리와 파일의 절대 경로를 한 줄에 하나씩 적으세요.
3. /etc/rancher/k3s/config.yaml 에 cluster-init: true 를 적고 k3s 를 재시작하세요. marker 가 살아 있는지 확인하고 /root/k3s-ds/migrate.json 에 marker_uid(재시작 뒤 marker 의 UID), sqlite_file_now(db 디렉터리에서 원래 state.db 가 바뀐 이름), node_roles(노드의 node-role.kubernetes.io/ 라벨 이름을 정렬한 배열, 예: ["control-plane"]), member_name(db/etcd/name 파일의 내용)을 적으세요.
4. marker 의 stage 를 snapshotted 로 바꾼 다음 k3s etcd-snapshot save --name lab-before 로 스냅숏을 뜨세요. /root/k3s-ds/snapshot.json 에 name(만들어진 스냅숏 이름 전체), path(파일 절대 경로), size(바이트, 정수), sha256(파일의 SHA-256)을 적으세요.
5. /root/k3s-ds/backup/ 디렉터리에 4단계의 스냅숏 파일(같은 이름)과 서버 토큰 파일(token 이라는 이름, 권한 600)을 복사하세요. /root/k3s-ds/token-backup.json 에 token_source(토큰 원본의 절대 경로), token_sha256(토큰 파일의 SHA-256), snapshot_sha256(백업한 스냅숏의 SHA-256)을 적으세요. 토큰 값 자체는 어디에도 적지 않습니다.
6. 스냅숏 뒤에 네임스페이스 k3s-ds 에 ConfigMap after-snap(x=1)을 만들고 marker 의 stage 를 changed 로 바꾸세요. /root/k3s-ds/after.json 에 after_uid(after-snap 의 UID), after_created(그 creationTimestamp), marker_stage(지금 marker 의 stage)를 적으세요.
7. k3s 를 멈추고 k3s server --cluster-reset --cluster-reset-restore-path=<4단계 스냅숏 경로> 로 복원한 뒤(출력 전체를 /root/k3s-ds/reset.log 에 저장) k3s 를 다시 시작하세요. /root/k3s-ds/restore.json 에 old_dir(복원이 이전 etcd 데이터를 옮긴 디렉터리 이름), restart_hint(reset.log 에서 k3s 가 다음에 할 일을 알려 준 문장 중 restart without 이 든 부분까지의 첫 문장), after_snap_exists(불리언), marker_stage(복원 뒤 marker 의 stage), member_name(복원 뒤 db/etcd/name 의 내용)을 적으세요.
8. /root/k3s-ds/report.json 에 datastore_now(sqlite 또는 etcd), lost_objects(복원으로 사라진 ConfigMap 이름을 정렬한 배열), marker_stage(지금 값), snapshot_dir(스냅숏이 저장된 디렉터리 절대 경로), restore_needs_token(다른 서버에서 복원할 때 원래 토큰이 필요한지, 불리언), member_name_changed(복원 전후 etcd 멤버 이름이 바뀌었는지, 불리언)를 적으세요.

참고

VM 안에 k3s v1.35.8+k3s1 한 대가 있습니다(traefik·metrics-server 는 끔). 재시작은 systemctl restart k3s 입니다.
3단계 뒤 k3s etcd-snapshot 명령은 config.yaml 의 cluster-init 을 모르는 키라며 경고를 한 줄 냅니다. 무해합니다(실측).
복원 명령은 문서 절차대로 systemctl stop k3s 로 서비스를 멈춘 뒤에 실행합니다.
흔한 실수: 스냅숏만 백업하고 /var/lib/rancher/k3s/server/token 을 빠뜨리는 것.
흔한 실수: --cluster-reset 을 서비스 인자나 config.yaml 에 넣는 것. 복원은 한 번 따로 실행하는 명령이고, k3s 는 reset-flag 파일로 연속 초기화를 막습니다.
[Cluster Datastore](https://docs.k3s.io/datastore) · [High Availability Embedded etcd](https://docs.k3s.io/datastore/ha-embedded) · [etcd-snapshot](https://docs.k3s.io/cli/etcd-snapshot) · [Backup and Restore](https://docs.k3s.io/datastore/backup-restore)

단계 8개

이 클러스터의 저장소는 무엇인가
스냅숏 명령을 걸었는데 저장소가 SQLite 였다
재시작 한 번으로 etcd 로 옮긴다
이름을 붙여 스냅숏을 뜬다
스냅숏만으로는 복원할 수 없다
스냅숏 뒤에 생긴 것들
복원하자 스냅숏 뒤의 변경이 사라졌다
무엇이 남고 무엇이 사라졌나