디스크는 멀쩡한데 설정 파일 하나 잘못 건드린 뒤 부팅이 안 되는 상황, 생각보다 자주 발생합니다. 이때 무엇보다 가장 헷갈리는 지점은 “백업은 해놨는데 어떤 방식으로 되돌려야 하는지”입니다. 이 글은 FreeBSD에서 실제로 복구까지 이어지는 백업 방법을 상황별로 상세하게 정리합니다.
1. 백업 방식 선택이 먼저인 이유
백업을 시작하려고 할 때 가장 먼저 막히는 부분은 “어떤 방법을 써야 하는지”입니다. FreeBSD에서는 ZFS, dump, rsync 세 가지가 대표적이며 목적이 서로 다릅니다.
ZFS는 스냅숏 기반으로 상태를 그대로 보존하는 방식이고, dump는 파일시스템 단위 백업, rsync는 파일 단위 복사입니다. 이 세 가지는 서로 대체가 아니라 역할 분담에 가깝습니다.
실무에서는 “빠르게 되돌려야 하는가” vs “다른 서버로 옮겨야 하는가” 기준으로 선택이 갈립니다. 대부분 조건보다 복구 시나리오를 먼저 생각해야 덜 헤맵니다.
여기서 갈리는 핵심은 ‘백업 목적’입니다. 단순 보관인지, 장애 복구인지에 따라 완전히 달라집니다.
2. ZFS 스냅숏: 되돌리기 중심 전략
업데이트 직전이나 설정 변경 전에 스냅숏을 찍어두고 싶은 상황에서 ZFS가 가장 많이 사용됩니다. 특히 패키지 업데이트 후 문제가 생겼을 때 여기서 막히는 경우가 많습니다.
ZFS에서는 snapshot → send/receive 방식으로 백업이 진행됩니다. snapshot은 특정 시점 상태를 저장하고, send는 이를 다른 저장소로 전송합니다.
복구 시에는 rollback 명령으로 해당 시점으로 즉시 되돌릴 수 있습니다. 이 과정은 파일 단위가 아니라 파일시스템 전체 상태를 복원하는 개념입니다.
겉보기에는 간단하지만 실제로는 “스냅숏 시점 관리”를 놓치는 경우가 많습니다. 언제 찍었는지 모르면 복구 시점 선택에서 막힙니다.
놓치기 쉬운 포인트는 스냅숏을 ‘주기적으로’ 관리하지 않으면 쓸모없는 기록이 된다는 점입니다.
3. dump/restore: 시스템 단위 복구용
서버를 통째로 복구해야 하는 상황에서 dump를 고려하게 됩니다. 특히 디스크 교체 후 복원 과정에서 여기서 멈추는 경우가 많습니다.
dump는 UFS 파일시스템을 기준으로 백업하며, restore를 통해 동일 구조로 복구합니다. 전체 백업(레벨 0)과 증분 백업(레벨 1~9)을 구분해서 사용할 수 있습니다.
이 방식은 시스템 구조를 그대로 유지할 수 있다는 장점이 있지만, 복구 과정이 직관적이지 않다는 점이 단점입니다.
처음 접하면 명령어보다 “복구 순서”에서 더 많이 막히는 특징이 있습니다. 실제로는 백업보다 복구 절차 이해가 더 중요합니다.
헷갈리기 쉬운 부분은 dump 파일만 있으면 끝이라고 생각하는 점인데, 복구 환경 준비가 따로 필요합니다.
4. rsync: 파일 기반 증분 백업
웹 서버나 NAS처럼 파일 변경이 잦은 환경에서는 rsync를 많이 사용합니다. 하지만 초기 설정 후 동기화가 꼬이는 지점에서 멈추는 경우가 많습니다.
rsync는 변경된 파일만 전송하는 증분 백업 방식입니다. 네트워크를 통한 원격 백업에도 적합합니다.
주로 cron과 함께 사용해 자동화하며, –delete 옵션을 통해 동기화 상태를 유지할 수 있습니다.
다만 이 옵션을 잘못 쓰면 기존 데이터가 삭제되는 문제가 발생할 수 있습니다. 편리하지만 실수 여지가 있는 도구입니다.
여기서 갈리는 핵심은 “백업인지 동기화인지”를 명확히 구분하는 것입니다.
5. 복구 실패가 발생하는 대표 원인
백업은 했는데 복구가 안 되는 상황은 특정 패턴으로 반복됩니다. 특히 실제 장애 상황에서 여기서 막히는 경우가 많습니다.
대표적으로는 경로 불일치, 권한 문제, 파일시스템 차이(ZFS vs UFS)가 있습니다. 단순히 파일만 복사했다고 해결되지 않는 이유입니다.
또한 백업 시점과 복구 시점이 맞지 않아 데이터 충돌이 발생하기도 합니다.
겉으로 보면 백업 문제 같지만 실제로는 복구 설계 부족인 경우가 많습니다. 이 차이를 인지하는 것이 중요합니다.
놓치기 쉬운 포인트는 “복구 테스트를 하지 않은 백업은 없는 것과 같다”는 점입니다.
6. 운영 환경에서 실제로 쓰이는 자동화 패턴
수동으로 백업을 하다 보면 어느 순간부터 빠뜨리는 일이 생깁니다. 특히 일정 관리에서 자주 놓치게 됩니다.
실무에서는 ZFS snapshot + cron + rsync 조합을 많이 사용합니다. 로컬에서는 스냅숏, 외부 백업은 rsync로 분리하는 방식입니다.
예를 들어, 매일 스냅숏 생성 → 주 1회 외부 서버로 전송 같은 구조가 일반적입니다.
이 구조의 장점은 “빠른 복구 + 외부 보관”을 동시에 만족한다는 점입니다. 하나의 방법만 쓰는 것보다 안정성이 높습니다.
헷갈리기 쉬운 부분은 자동화만 설정하고 실패 로그를 확인하지 않는 경우입니다.
FAQ
Q1. ZFS만 쓰면 다른 백업은 필요 없나요?
A. 스냅숏은 동일 스토리지 내 보호에 강하지만, 물리 장애에는 취약합니다. 외부 백업이 함께 필요합니다.
Q2. dump는 요즘에도 사용하나요?
A. ZFS 환경에서는 사용 빈도가 줄었지만, UFS 기반 시스템에서는 여전히 유효한 방식입니다.
Q3. rsync만으로 시스템 전체 복구가 가능한가요?
A. 가능은 하지만 부트 환경, 권한, 디바이스 파일 등에서 문제가 발생할 수 있어 추가 작업이 필요합니다.
Q4. 백업 주기는 어떻게 잡는 게 좋나요?
A. 데이터 변경 빈도에 따라 다르지만, 중요한 데이터는 하루 단위 스냅숏이 일반적입니다.
Q5. 가장 안전한 조합은 무엇인가요?
A. ZFS 스냅숏 + 외부 rsync 백업 조합이 현실적으로 많이 사용됩니다.
마무리
FreeBSD 백업은 방법보다 “복구까지 이어지는 구조”가 더 중요합니다. 하나의 도구에 의존하기보다 역할을 나누는 방식이 안정적입니다.
지금 사용 중인 환경에서 어떤 방식이 맞는지 먼저 점검하고, 최소 한 번은 복구 테스트까지 진행해 보는 것이 다음 단계입니다.
※ 본 글은 일반적인 시스템 운영 기준을 바탕으로 작성되었으며, 실제 적용 시에는 서버 환경, 파일시스템, 운영 정책에 따라 결과가 달라질 수 있습니다.