Proxmox Backup Server 4.2는 2026년 4월 29일에 공개됐습니다. 공식 배포 안내를 확인한 뒤, 저장소가 가득 찼다면 먼저 prune과 garbage collection(GC) 작업 결과를 점검하세요. PBS의 저장소 상태와 파일 시스템 사용량을 함께 봐야 합니다. 스냅샷 목록이나 중복 제거 수치만으로 데이터를 지우거나, .chunks를 직접 삭제해서는 안 됩니다.
마지막 업데이트: 2026년 10월 28일. 버전 날짜와 유지 관리 절차는 Proxmox Backup Server 공식 문서 및 저장소 문서를 기준으로 확인했습니다.
이 글은 독립 PBS 인스턴스의 공간 증가 원인을 찾아야 하는 시스템 관리자에게 적합합니다.
여러 고객의 보존 정책과 작업을 관리하는 MSP는 고객별 위험을 분리해 확인할 수 있습니다.
다중 테넌트 백업 저장소를 운영하는 소규모 IDC 담당자는 용량 변경 전에 점검할 근거를 얻을 수 있습니다.
역할별로 먼저 분리할 문제
공간 부족은 한 가지 원인으로만 발생하지 않습니다. 예약한 작업이 실행되지 않았거나, 작업이 실패했거나, 보존 정책이 기대와 다를 수 있습니다. 반대로 PBS 작업은 정상이어도 저장소가 놓인 파일 시스템 자체에 여유 공간이 없을 수 있습니다. 이 상황을 구분하지 않으면 필요 없는 삭제 작업을 하거나, 작업 실패를 용량 확장만으로 해결하려고 할 수 있습니다.
독립 PBS 관리자는 prune과 GC의 예약 상태, 최근 실행 결과와 오류 기록을 대조해야 합니다. 작업 기록이 정상인데 파일 시스템 사용량이 계속 증가한다면, 저장소의 실제 점유와 백업 증가 추세를 별도로 살펴보세요.
MSP 운영자는 한 고객의 설정 변경이 다른 고객의 백업 데이터에 영향을 주지 않도록 해야 합니다. 고객별 보존 정책, 작업 기록, 용량 알림을 구분해 남기고, 소유자 확인 없이 공유 저장소에서 데이터를 삭제하지 마세요.
소규모 IDC 담당자는 datastore만 보는 것으로 점검을 끝내면 안 됩니다. 저장소가 올라간 파일 시스템이나 외부 저장소의 용량 상태와 경보를 확인하고, 해당 백엔드에 맞는 공식 절차를 적용해야 합니다.
prune과 GC의 역할부터 확인
prune은 보존 정책에 따라 남길 스냅샷을 정리합니다. GC는 저장소에서 더 이상 참조되지 않는 청크를 찾아 회수합니다. 따라서 prune이 끝났더라도 다른 스냅샷이 같은 청크를 참조하면 해당 데이터가 남을 수 있으며, GC가 아직 실행되지 않았다면 파일 시스템의 여유 공간도 기대만큼 바뀌지 않을 수 있습니다. 공식 유지 관리 안내에서 작업 기능과 상태를 확인하고, 실행 결과를 서로 다른 항목으로 기록하세요.
스냅샷 개수, datastore가 표시하는 사용량, 파일 시스템의 실제 사용량은 서로 다른 관점의 지표입니다. 중복 제거 수치는 저장소에서 데이터가 공유되는 상태를 설명하는 데 참고할 수 있지만, 특정 파일을 지워도 되는지 알려주는 삭제 목록은 아닙니다. 저장소가 차지하는 공간을 판단할 때에는 PBS 저장소 설명과 실제 파일 시스템 상태를 함께 대조하세요.
저장소 유형에 맞춰 상태 확인
| 저장소가 놓인 환경 | 확인할 관점 | 진행 전 주의사항 |
|---|---|---|
| ext4 또는 XFS 파일 시스템 | PBS datastore 상태와 파일 시스템 여유 공간을 각각 확인합니다. | PBS에서 보이는 저장소 사용량만으로 장치의 전체 여유 공간을 단정하지 않습니다. |
| ZFS 파일 시스템 | datastore가 있는 데이터셋의 점유 상태와 실제 여유 공간을 구분합니다. | 풀이나 데이터셋의 설정을 바꾸기 전에 현재 구성과 복구 경로를 확인합니다. |
| S3 기반 구성 | 해당 구성이 PBS 4.2 공식 문서에서 설명하는 저장 방식인지 먼저 확인합니다. | 다른 구현이나 별도 계층의 동작을 PBS 기본 기능으로 간주하지 않습니다. |
PBS 4.2의 저장 기능과 지원 범위는 공식 저장소 문서를 기준으로 판단해야 합니다. 파일 시스템 도구와 외부 저장소의 경보는 각 백엔드의 관리 화면이나 해당 시스템의 공식 안내를 따르세요. 커뮤니티에 올라온 임시 조치가 현재 환경에도 적용된다고 가정하지 마세요.
.chunks 안의 파일을 직접 이동하거나 삭제하지 마세요. 청크는 여러 스냅샷이 함께 참조할 수 있습니다. 데이터 손상 가능성과 복구 경로를 확인하지 못했다면 변경을 멈추고 공식 문서에 맞는 절차를 먼저 확보하세요.상태에 따라 정리와 확장 결정
아래 표는 조치의 순서를 정하기 위한 기준입니다. 특정 방법이 모든 백엔드에서 같은 결과를 보장하지 않으므로, 실제 변경은 저장소 유형과 복구 조건을 확인한 뒤 진행하세요.
| 확인된 상태 | 먼저 할 조치 | 다음 판단 |
|---|---|---|
| prune이 실행되지 않았거나 예약이 맞지 않음 | 예약 설정과 보존 정책을 검토하고 작업 기록을 확인합니다. | 정책이 의도와 일치할 때 작업을 실행하고 결과를 검증합니다. |
| prune은 끝났지만 GC가 아직 실행되지 않음 | GC 예약과 최근 결과, 관련 오류를 확인합니다. | 실행에 필요한 여유 공간과 저장소 상태를 확인한 뒤 공식 절차를 따릅니다. |
| GC가 실패했고 파일 시스템에도 여유 공간이 없음 | 오류와 저장소 상태를 보존하고 위험한 삭제를 중단합니다. | 안전하게 공간을 확보할 방법이나 저장소 확장 경로를 검토합니다. |
| 저장소 백엔드와 복구 방법을 확인하지 못함 | 데이터를 변경하지 말고 설정, 작업 로그, 알림을 기록합니다. | 백엔드별 공식 안내와 복구 조건을 확인한 후 조치합니다. |
파일 시스템이 실제로 부족하다면 원인 해결을 확인하기 전에 백업 정책을 완화하거나 데이터를 지우지 마세요. 저장소가 더 이상 GC를 수행하기 어려운 상태라면, 공간을 어떻게 확보할지와 실패 시 복구할 수 있는지를 먼저 평가해야 합니다. 공간을 늘리는 선택도 백업 데이터의 보호 방안과 저장소 구조가 확인된 뒤에 진행하세요.
변경 전후를 체크리스트로 검증
다음 항목을 순서대로 확인하세요. 위험한 저장소 변경을 시작하기 전에는 유지 보수 시간을 확보하고, 검증된 백업과 복구 경로가 있는지 확인해야 합니다.
- [ ] datastore별 prune 예약과 최근 실행 결과를 확인합니다.
- [ ] GC 예약, 최근 작업 상태, 오류 기록을 확인합니다.
- [ ] 스냅샷 목록과 PBS 저장소 상태를 파일 시스템 실제 사용량과 대조합니다.
- [ ] ext4, XFS, ZFS 또는 확인된 외부 저장 방식에 맞는 용량 표시와 경보를 확인합니다.
- [ ] MSP라면 고객별 보존 정책과 승인 기록을 분리해 보존합니다.
- [ ] 삭제나 확장 전에 복구 경로, 백업 상태, 변경 시간을 확인합니다.
- [ ] 변경 후 prune과 GC 결과, datastore 상태, 파일 시스템 여유 공간을 다시 확인합니다.
- [ ] 다음 백업이 계획대로 완료되는지 작업 기록을 확인합니다.
작업 로그는 어떤 조치를 했는지 추적할 수 있도록 변경 전후에 남기세요. PBS 관리 명령을 사용해야 하는 경우에는 명령과 적용 조건을 공식 명령 참고 문서에서 대조하고, 설치된 버전과 저장소 유형이 일치하는지 확인하세요. 커뮤니티 게시물에서 본 명령이나 파일 조작을 그대로 적용하는 방식은 피해야 합니다.
2026년 9월 22일에 게시된 공식 커뮤니티의 저장 공간 부족 사례는 개별 환경의 문제 기록입니다. 이 사례만으로 PBS 4.2에 보편적인 공간 부족 결함이 있다고 판단할 수는 없습니다. 해당 사례와 공식 기술 문서를 구분하고, 원인을 자신의 작업 기록과 저장소 상태에서 확인하세요.
용량 재산정과 백업 목표 검토
정리 작업을 마친 뒤에도 공간이 빠르게 줄어들거나 증가한다면, 보존 정책과 실제 백업 증가량을 기준으로 용량 계획을 다시 세우세요. 확인 기간을 정해 백업 데이터의 변화, 보존 대상의 수, 저장소의 실제 점유를 기록하고, 그 결과로 필요한 여유 공간을 판단합니다. 단일 커뮤니티 사례의 사용량을 다른 환경에 적용하거나 임의의 고정 증가율을 전제로 계산하지 마세요.
독립된 백업 목표를 서버로 구성하려면 저장 용량만 비교하지 말고 디스크 수와 구성, 장애 시 복구 방식, 백업 전송 대역폭, 별도 위치의 사본을 함께 검토해야 합니다. 물리 서버는 자체 백업 정책과 외부 사본을 운영할 기반이지, 관리형 백업 서비스와 같은 의미는 아닙니다. 서버의 저장 구성과 운영 조건을 살펴볼 때는 독립 서버 구성 안내와 데이터 처리 안내를 참고하고, 실제 선택지는 현재 제공되는 제품 정보를 기준으로 확인하세요.
자주 묻는 질문
스냅샷을 삭제했는데 디스크 공간이 그대로인 이유는 무엇인가요?
prune으로 스냅샷이 정리돼도 실제 청크가 즉시 회수된다고 단정할 수 없습니다. 다른 스냅샷이 같은 청크를 참조할 수 있고, GC가 아직 실행되지 않았을 수도 있습니다. prune과 GC 기록을 따로 확인한 다음 datastore 상태와 파일 시스템 사용량을 비교하세요. .chunks를 직접 지워 공간을 확보하려 해서는 안 됩니다.
prune과 GC는 어떤 차이가 있나요?
prune은 보존 정책에 맞지 않는 스냅샷을 정리하고, GC는 참조되지 않는 청크를 찾아 회수합니다. 서로 다른 단계이므로 prune 성공만으로 파일 시스템 여유 공간이 늘었다고 판단하지 마세요. GC 작업이 실행됐는지, 오류가 있었는지, 청크가 다른 스냅샷에 필요한지 확인해야 합니다. 자세한 절차는 공식 유지 관리 문서와 저장소 유형을 기준으로 검토하세요.
저장소가 가득 찰 때 정리와 확장 중 무엇을 먼저 해야 하나요?
먼저 작업이 실행되지 않은 것인지, 실패한 것인지, 보존 정책이 기대와 다른 것인지 구분합니다. 이어서 PBS 저장소 상태와 파일 시스템의 실제 여유 공간을 대조하세요. GC를 수행할 수 있고 안전한 복구 경로가 확인되면 공식 절차에 따라 정리를 검토합니다. 공간 부족으로 안전한 작업이 어려우면 백엔드와 복구 방안을 확인한 뒤 확장을 판단하세요.
디스크 공간이 부족해 GC가 실행되지 않으면 어떻게 해야 하나요?
작업 오류와 파일 시스템 상태를 기록하고, .chunks 파일을 임의로 지우거나 옮기지 마세요. 해당 저장 방식의 공식 안내를 확인하고, 유지 보수 시간과 복구 조건을 마련한 뒤 공간 확보나 확장을 검토해야 합니다. 안전한 절차를 확인할 수 없다면 변경을 멈추는 편이 낫습니다. 조치 후에는 GC 결과와 다음 백업의 완료 여부까지 점검하세요.
PBS 공간 문제를 해결할 때는 실제 증가량과 보존 정책부터 확인하고, 저장소 유형에 맞는 복구 경로를 정한 뒤 정리 또는 확장을 선택하세요. 공유 환경의 작업 간섭이나 저장 용량의 한계가 반복된다면 독립 백업 목표로 분리할 서버가 필요한지도 검토할 수 있습니다. OVN Cloud의 독립 서버 선택지는 현재 제품 정보를 기준으로 비교하고, 백업 사본과 운영 책임은 별도로 계획하세요.
자주 묻는 질문
- 백업 스냅샷을 지웠는데도 저장 공간이 줄지 않는 이유는 무엇인가요? 스냅샷 항목을 지운 것과 실제 디스크의 청크 데이터가 정리된 것은 같은 일이 아닙니다. 보존 정책에 따른 prune 결과와 garbage collection 작업 상태를 각각 확인하세요. 다른 스냅샷이 참조하는 청크는 남아 있을 수 있으므로, 목록이나 중복 제거 수치만 보고 파일을 직접 지우면 안 됩니다. 작업 로그와 파일 시스템 사용량까지 함께 비교해야 합니다.
- Proxmox Backup Server에서 prune과 GC는 어떻게 다르게 작동하나요? prune은 보존 정책에 맞지 않는 스냅샷을 정리하는 작업입니다. GC는 더 이상 참조되지 않는 청크를 찾아 저장소에서 회수하는 작업입니다. 따라서 prune이 성공했더라도 GC가 실행되지 않았거나 다른 스냅샷이 청크를 계속 참조하면 파일 시스템 사용량은 바로 줄지 않을 수 있습니다. 두 작업의 실행 기록과 결과를 따로 확인하세요.
- PBS 저장소가 거의 찼을 때 정리와 확장 중 무엇을 먼저 해야 하나요? 먼저 prune과 GC가 실행됐는지, 실패했다면 원인이 무엇인지 확인하세요. 보존 정책이 의도와 다르면 정책과 작업 상태부터 바로잡고, 실제 파일 시스템이 부족한지 저장소 상태와 대조합니다. GC를 실행할 여유가 있고 안전한 복구 경로가 확인된 경우에만 정리를 검토하세요. 공간 부족으로 작업을 수행하기 어렵다면 저장소 유형과 데이터 보호 방식을 확인한 뒤 확장을 계획합니다.
- PBS 디스크가 가득 차서 GC 작업을 실행할 수 없으면 어떻게 하나요? GC를 반복 실행하거나 청크 파일을 직접 삭제하지 마세요. 먼저 작업 오류와 파일 시스템의 실제 여유 공간을 확인하고, 저장소 백엔드별 공식 안내 및 복구 경로를 검토해야 합니다. 작업을 실행할 공간을 안전하게 확보할 수 있는지 확인할 수 없다면 운영 변경을 멈추고, 검증된 복구 계획이나 용량 확장 방안을 마련한 뒤 진행하세요. 이후 백업과 GC 결과를 다시 확인해야 합니다.