긴 Borg 백업 공백을 피하려면 성공적인 백업 후에 보존 정책에 따른 prune을 실행하되, 저장소 compact는 더 드물게 기본 백업 시간대를 피해 예약하세요. Borg 1.4는 아카이브 삭제와 물리적 공간 회수를 분리하므로 모든 borg prune 후에 borg compact를 실행할 필요는 없습니다.
이 가이드는 현재 Borg 1.4.x 안정 버전의 명령 모델을 기준으로 합니다. Borg 2에서는 여러 영역에서 저장소 및 아카이브의 의미가 변경되므로, 다른 주요 버전용 자동화를 복사하기 전에 설치된 버전을 확인하세요.
Borg 버전 및 저장소 확인
borg --version
borg info /mnt/backup/borg-repo
borg list /mnt/backup/borg-repo
Borg FAQ에 따르면 Borg는 저장소 전체에 잠금을 사용하며 한 번에 하나의 프로세스만 쓰기 권한을 가질 수 있습니다. 장시간 실행되는 compact가 다음 예약 백업과 겹치면 백업은 잠금이 해제될 때까지 대기하거나 잠금 시간 초과 시 실패합니다.
먼저 드라이 런으로 보존 정책 정의
borg prune은 아카이브 기록을 삭제하므로 주의가 필요합니다. Borg의 prune 문서에서는 --dry-run 및 --list로 테스트할 것을 강력히 권장합니다.
borg prune --dry-run --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo
하나의 저장소에 여러 시스템이나 데이터 세트의 백업이 포함되어 있다면 아카이브 필터가 필수입니다. 제한적인 필터가 없으면 Borg 1.4는 저장소의 모든 아카이브를 동일한 보존 규칙의 대상으로 간주합니다.
성공적인 백업 후에만 Prune 실행
#!/bin/sh
set -eu
REPO=/mnt/backup/borg-repo
ARCHIVE='{hostname}-{now:%Y-%m-%d_%H-%M}'
borg create --stats "$REPO::$ARCHIVE" /srv/data
borg prune --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' "$REPO"
스케줄러가 실행되었다는 이유로 prune하지 말고, 새 백업이 성공적으로 완료되고 보존 정책이 이미 검증된 후에 prune하세요.
prune이 즉시 공간을 확보하지 않는 이유 이해하기
Borg 1.2부터 compact는 일반 저장소 쓰기 명령과 분리되었습니다. Borg의 분리된 compact 참고 사항에서는 아카이브를 삭제하거나 prune해도 저장소 디스크 공간이 즉시 모두 회수되지는 않는다고 설명합니다.
borg create
|
새 아카이브 커밋
|
borg prune
|
보존 집합에서 오래된 아카이브 제거
|
borg compact
|
사용되지 않은 세그먼트 공간 회수
이는 일정 예약에 유용합니다. 매일 백업할 때 부분적으로 사용된 저장소 세그먼트를 다시 기록하는 전체 비용을 부담할 필요가 없기 때문입니다.
prune보다 compact를 덜 자주 예약하기
- backup: 매일 밤;
- prune: 각 백업 성공 후 또는 주 몇 회;
- compact: 한가한 시간에 주 1회;
- 전체 저장소 검사: 별도의, 더 드문 일정으로 실행합니다.
# 일일 백업 + prune
0 1 * * * /usr/local/sbin/borg-backup
# 주간 compact
0 4 * * 0 /usr/local/sbin/borg-compact
백업이 몇 시간씩 자주 실행된다면 compact 작업을 더 멀리 예약하거나 명시적인 종속성이 있는 타이머를 사용하세요.
강제로 최대한 다시 기록하기 전에 기본 compact 임계값 사용
현재 compact 문서에서는 기본적으로 10% 임계값을 사용합니다.
borg compact --progress /mnt/backup/borg-repo
유지 관리 시간을 짧게 하는 것이 우선순위라면 이 기본값으로 시작하는 것이 좋습니다. 다음 명령을 자동으로 사용하지 마세요. --threshold 0여유 공간이 생길 때마다 다시 기록하므로 대규모 저장소에서는 상당히 느려질 수 있습니다.
유지 관리 작업이 다음 백업과 충돌하지 않도록 하기
작업이 다른 Borg 프로세스를 기다려도 문제가 없다면, 제한 시간이 있는 잠금 대기를 설정하세요:
borg --lock-wait 1800 create /mnt/backup/borg-repo::'{hostname}-{now}' /srv/data
매우 긴 잠금 대기 시간을 적절한 일정 관리의 대안으로 사용하지 마세요. 백업이 실제로 시작하고 완료되는 시간을 모니터링하세요.
여러 클라이언트가 하나의 저장소를 공유한다면 일정을 분산하세요. Borg FAQ에서는 클라이언트 간 중복 제거가 중요하지 않을 때 여러 저장소를 사용하면 잠금 경합을 줄일 수 있다고 설명합니다.
보고로 인해 prune이 느려질 때 빠른 통계 사용하기
Borg 1.4.5에 추가됨 --quick-stats 생성, 삭제, prune 작업을 수행할 때 필요하지 않은 느린 저장소 전체 통계 수집을 피합니다.
borg prune --quick-stats --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo
compact가 필요하기 전에 여유 공간 확보하기
저장소 파일 시스템의 여유 공간이 0이 될 때까지 기다리지 마세요. 파일 시스템이 완전히 가득 차면 Borg가 일반적인 저장소 쓰기 작업을 안정적으로 수행할 수 없습니다.
df -h /mnt/backup
borg info /mnt/backup/borg-repo
더 폭넓은 NAS 백업 계획을 세울 때 ZimaOS 3-2-1 백업 가이드는 저장소 보존이 백업 설계의 한 계층일 뿐이라는 점을 상기시켜 주는 유용한 자료입니다.
신뢰하기 전에 일정 검증하기
- 모든 백업에서 새 아카이브가 생성되었나요?
- 성공한 백업 후에만 prune이 실행되었나요?
- 보존 세트가 드라이 런 계획과 일치했나요?
- 주간 compact가 다음 백업 전에 완료되었나요?
- compact 후 여유 공간이 늘었나요?
- 어떤 작업이 Borg 잠금을 기다리느라 예상보다 오래 걸렸나요?
compact가 다음 백업과 반복해서 겹치면 compact 실행 빈도를 줄이고, 기본 임계값을 유지하며, compact를 더 한산한 시간대로 옮기거나, 서로 관련 없는 작업을 별도의 저장소로 분리하세요.
간격이 짧은 Borg 유지 관리 패턴
일일
01:00 borg create
|
+-- 성공 --> borg prune
|
+-- 실패 --> 이전 아카이브 유지, 알림
주간
04:00 borg compact
주기적
borg check
선택한 파일 복원 테스트
핵심 규칙은 간단합니다. prune은 보존 정책을 적용하고, compact는 저장 공간을 회수합니다. 둘은 같은 빈도로 실행할 필요가 없습니다.
지원 및 팁
더 읽어보기

Home Assistant가 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않음
각 네트워크 경로를 개별적으로 테스트하고, 인터페이스와 라우팅 상태를 확인한 다음, 직접 IP 연결과 검색 기능을 구분하여 실패한 계층만 복구하세요.

보호되지 않은 데이터를 남기지 않고 Home Assistant를 폐기하는 방법
교체 또는 보관을 입증하고, 모든 신뢰 경로를 폐기하며, 데이터를 저장하는 각 장치를 안전하게 삭제하고, 문서화된 보호 복구 사본만 보존하세요.

홈 서버에서 Home Assistant 자동 업데이트를 사용해야 할까요?
가정에 미치는 영향, 호환성 위험, 관찰 시간, 복구 준비 상태를 고려해 수동 업데이트, 알림만 제공, 또는 단계적 자동 업데이트를 선택하세요.

