Let’s Bootc! [10] - 데이터의 불변성은 어떻게 설정할까?

Summary 불변성을 유지하는 시스템에서 사용자 데이터를 효과적으로 관리하기 위한 방법으로, 퍼블릭 클라우드나 GitHub의 한계를 극복하기 위해 홈서버에 S3 호환 오브젝트 스토리지를 구축하고, restic을 통해 백업 데이터를 암호화하는 방안을 제안합니다. 또한, systemd user timer를 활용하여 백업을 자동화하고, 복원 가능성을 확보하기 위한 리허설을 권장합니다. 최종 목표는 새로운 하드웨어에 기존 환경을 손쉽게 복원하는 것입니다.

[9] 데이터의 불변성은 어떻게 설정할까?

사실 빌드 시점에 시스템을 불변(Immutable) 상태로 구성하더라도, 우리가 실제로 컴퓨터를 사용하다 보면 다양한 데이터가 쌓이기 마련입니다. KDE 데스크탑 설정과 같은 각종 시스템 설정값부터 Obsidian에서 작성하는 문서나 일기 같은 개인 파일들, 그리고 시스템 로그 데이터까지 모두 어딘가에 저장되어야 합니다.

결국 컴퓨터라는 것은 단순히 OS와 프로그램만 유지된다고 해서 완성되는 것이 아닙니다. 시스템에 나의 활동 흔적과 데이터가 온전하게 남아 있어야 비로소 ‘나의 시스템’이라고 부를 수 있기 때문입니다.

현재의 bootc(Bootable Container) 환경에서는 설정이나 애플리케이션 영역만 불변성을 유지하고 있습니다. 그렇다면 이 시점에서 우리는 사용자 데이터를 어떻게 관리해야 할까요? 다음과 같은 일반적인 방법들이 있을 것입니다:

1. 구글 드라이브(Google Drive), 원드라이브(OneDrive), 아이클라우드(iCloud) 등 퍼블릭 클라우드 활용
2. GitHub 전체에 데이터를 올려서 관리하는 방법 하지만 이번 시간에는 이런 방식들 외에, 조금 더 나은 데이터 관리 방안을 간단하게 제안해보는 시간을 가져보겠습니다.

/var가 가변이라는 것의 실질적 의미

[3]번에서 설명했듯이 bootc 환경에서 /var는 가변 영역입니다. 여기에 로그, 설정값, 사용자 데이터 등이 쌓입니다. 루트 파일시스템은 이미지 기반으로 관리되고 읽기 전용 성격을 갖지만, /var와 홈 디렉토리는 그렇지 않습니다.

이 구조가 의미하는 바는 명확합니다. 시스템 자체를 백업하는 대신, 사용자 데이터가 존재하는 홈 디렉토리를 백업의 단위로 삼아야 한다는 것입니다. 불변 OS와 가변 데이터의 경계를 명확히 구분하는 셈입니다.

그래서 복원 시에도 동일한 bootc 이미지를 재설치한 뒤 데이터를 다시 주입하는 방식으로 동작합니다. “시스템은 이미지로, 데이터는 별도로"라는 원칙이 여기서 나옵니다.

왜 퍼블릭 클라우드나 GitHub만으로는 부족한가

다른 컴퓨터를 사용하게 되었을 때 내 데이터가 없으면 어떤 일이 벌어질까요? 매번 똑같은 인증 과정을 거쳐야 합니다. SSH 키를 다시 생성하고, 브라우저에 다시 로그인하고, 애플리케이션 설정을 처음부터 만져야 합니다.

퍼블릭 클라우드 서비스는 특정 폴더 단위의 동기화에는 적합하지만, 홈 디렉토리 전체를 대상으로 하기에는 구조적으로 맞지 않습니다. SSH 키나 API 토큰 같은 민감한 파일이 제3자 서버에 평문으로 저장되는 것도 부담입니다.

GitHub Private 저장소는 어떨까요? GitHub 문서에 따르면 50 MiB 초과 파일은 경고가 발생하고 100 MiB를 넘으면 업로드가 차단됩니다. 저장소 크기는 1 GB 미만을 권장하고 5 GB 이상은 강하게 비권장으로 안내합니다. Git LFS를 사용하더라도 플랜별로 파일당 2 GB에서 5 GB까지 제한이 존재합니다. GitHub 문서 자체가 “Git은 백업 도구로 설계되지 않았다"고 명시하고 있습니다.

결국 전체 홈 디렉토리 백업이 목표라면, 이 방식들은 구조적으로 한계가 있습니다.

Self-hosted S3라는 선택지

그래서 저는 홈서버에 S3 호환 오브젝트 스토리지를 직접 구축하고 백업 데이터를 저장하는 방식을 제안합니다. 이 방식은 대용량 데이터와 잦은 변경에 유리하며, S3 API 기반 백업 도구와 호환되므로 자동화가 쉽습니다.

미니 PC나 홈서버를 이미 운영 중이라면 고려해볼 만한 오픈소스 S3 구현체들이 있습니다.

Garage는 경량 오브젝트 스토어로 단일 노드 및 소규모 클러스터에 적합합니다. 문서가 비교적 간결하고, 홈서버 환경에 빠르게 적용할 수 있다는 장점이 있습니다. 단일 서버 기준으로는 가장 손쉬운 후보 중 하나입니다.

MinIO는 S3 호환 오브젝트 스토어로 널리 사용됩니다. 설치와 운영이 비교적 단순하며, 단일 노드 구성도 쉽습니다. 다만 커뮤니티 버전이 유지보수 모드로 전환되었고 소스 코드 기반 배포 중심으로 변경되었다는 점을 고려해야 합니다.

SeaweedFS는 분산 스토리지 시스템으로 S3 API 게이트웨이를 제공합니다. 장기적으로 스케일아웃을 고려하는 경우에 유리하지만, 설정은 다른 후보보다 복잡할 수 있습니다.

단일 노드 홈서버에서 단순하고 안정적으로 운영하려면 Garage가 가장 무난한 선택이라고 생각합니다. 확장성과 분산 구성이 필요해질 가능성이 있다면 SeaweedFS를 고려할 수 있습니다.

백업 데이터의 암호화: restic

저장소를 어디에 두든, 백업 데이터는 암호화되어야 합니다. 홈서버를 사용하더라도 데이터 유출 가능성은 항상 존재하기 때문입니다. 저장소는 평문으로 운용하지 않는다는 원칙을 세워야 합니다.

restic는 백업 시점에 데이터 전체를 암호화하는 도구입니다. 저장소에는 복호화 키가 남지 않으며, 복원 시 비밀번호가 필요합니다. 비밀번호 분실 시 복원이 불가능하므로 비밀번호 보관 정책이 가장 중요합니다.

restic의 또 다른 장점은 스냅샷 기반 증분 백업입니다. 매번 전체 데이터를 다시 저장하지 않고, 변경된 블록만 저장합니다. 홈 디렉토리 전체를 백업하더라도 저장소 공간을 효율적으로 사용할 수 있습니다. 스냅샷은 시간별 복원을 가능하게 하므로, “어제 오후 3시 상태로 돌아가고 싶다"는 요구도 충족할 수 있습니다.

홈 디렉토리 전체 백업에는 SSH 키, API 토큰, 브라우저 프로필, 로그인 정보가 포함될 수 있습니다. 이 데이터는 복원 편의성과 맞바꾼 민감성입니다. 따라서 저장소 접근 정책을 강화하고, 백업 파일 접근이 가능한 계정 수를 최소화해야 합니다.

비밀번호는 최소 16자 이상의 길이를 권장합니다. 기억하기 어려운 경우 비밀번호 관리자에 보관하되, 반드시 복수의 안전한 보관 수단을 마련해야 합니다. 비밀번호를 분실하면 백업 데이터는 복구할 수 없습니다.

자동화: systemd user timer

백업이 수동으로만 이루어진다면, 언젠가 잊게 됩니다. 그래서 systemd user timer로 정기 백업을 자동화하는 것을 권장합니다.

systemd user timer는 사용자 세션 범위에서 동작하므로 루트 권한이 필요하지 않습니다. 불변 OS 환경에서 시스템을 건드리지 않고 사용자 영역에서 백업 자동화를 구현할 수 있다는 장점이 있습니다.

백업 자동화는 두 가지 유닛으로 구성됩니다. 하나는 실제 백업을 수행하는 service 유닛이고, 다른 하나는 주기를 정의하는 timer 유닛입니다. 두 유닛은 사용자 홈 아래 ~/.config/systemd/user에 위치시키는 것이 일반적입니다.

Tailscale이나 동일 네트워크 접근만 허용하는 환경에서는 네트워크 연결 여부를 조건으로 추가하는 것이 안전합니다. 조건이 만족되지 않으면 백업은 실행되지 않고 다음 스케줄로 넘어갑니다.

하루 1회 백업이 기본입니다. 데이터 변경이 잦다면 6시간 또는 3시간 간격으로 줄일 수 있습니다. 백업 성공 여부는 주기적으로 수동 확인하는 것이 안전합니다.

복원의 관점에서

백업 전략에서 가장 중요한 것은 복원 가능성입니다. 백업이 아무리 잘 되어 있어도 복원이 안 되면 의미가 없습니다.

복원은 새 하드웨어에 동일 bootc 이미지를 설치한 뒤, 단일 스크립트를 실행하는 것으로 완료됩니다. 스크립트는 저장소에 접속하여 최신 스냅샷을 가져온 후 홈 디렉토리에 복원합니다. 이것이 “스크립트 1회 실행 복원"의 의미입니다.

최소 분기 1회는 복원 리허설을 수행하는 것을 권장합니다. 최신 스냅샷을 별도 디렉토리에 복원해 정상성을 확인하고, SSH 키, 브라우저 설정, 주요 애플리케이션 설정이 복원되는지 확인해야 합니다. 복원 실패는 대부분 암호화 비밀번호 분실이나 저장소 손상에서 발생합니다.

정리

bootc 환경에서 시스템은 이미지로 관리되지만, 데이터는 가변입니다. 이 경계를 인식하고 “시스템은 이미지로, 데이터는 별도로"라는 원칙을 세우면, 하드웨어에 종속되지 않는 운영이 가능해집니다.

Self-hosted S3와 restic를 조합하면 대용량 홈 디렉토리 전체를 암호화하여 백업할 수 있습니다. systemd user timer로 자동화하면 백업을 잊어버릴 일도 없습니다. 네트워크 접근은 Tailscale이나 내부망으로 제한하여 보안을 유지합니다.

결국 이 모든 것의 목표는 단순합니다. 새 노트북을 샀을 때, bootc 이미지를 설치하고 스크립트 한 번 실행하면 어제까지의 내 환경이 그대로 돌아오는 것입니다. 그것이 “나의 시스템"을 진정으로 소유한다는 의미라고 생각합니다.