인프라·운영 추정
전체·증분 백업 보관 용량 계산하기
사용할 도구
원본×세대는 증분을 빠뜨리고 매일 전체 크기를 더하면 과대입니다. 세대 의미·함께 남길 전체와 증분·주기 내 관측점을 정하세요.
주간 전체·일간 증분·전체 두 세대
source: 100 GB
full interval: 168 hours
increment interval: 24 hours
retained full generations: 2
change per increment: 10%
compressed size: 100%
copies: 1
phase since latest full: 0 hours260GB로 전체2=200, 이전 체인 증분6=60입니다. 각 100GB×10%=10GB이며 전체 시각에 증분을 겹쳐 만들지 않아 한 주는 전체1·증분6입니다.
여기 두 세대는 복구점 둘이 아니라 전체2+증분6=8점입니다. 제품 세대가 총복구점이면 전체 세대 필드에 그대로 복사하지 말고 유지 대상을 보세요.
같은 두 세대도 주 후반 320GB
관측을 0→144시간으로 바꾸면 새 체인 증분6이 더해 전체2·증분12·320GB입니다. 같은 보존도 시점에 따라 달라 전체 직후가 최대는 아닙니다.
관측 위치는 다음 전체 전 증분 간격 배수, 예제 0~144시간 24단위입니다. 다음 전체는 새 주기입니다. 임시 파일·이전 체인 삭제 전 중첩은 모사하지 않아 운영 여유는 별도입니다.
기간 밖 전체가 기간 안 증분에 필요
기간 168·관측 144에서 최신 전체를 0으로 두면 가장 오래된 목표는 -24입니다. 이를 복원하려면 -168 전체와 후속 체인이 필요해 전체2·증분12·320GB를 유지합니다.
7일 이전 파일 일괄 삭제는 복원 의존성을 깨뜨릴 수 있습니다. 제품별 병합·합성 전체 등은 다르며 도구는 주기적 전체·증분 모델입니다. 수동 삭제 지시로 쓰지 마세요.
변경 10%는 증분 1회당 가정
증분은 원본×변경률, 매회 10GB이지 원본 복리 증가는 아닙니다. 같은 위치 반복 변경이 있어 변경량과 주간 순증가는 다릅니다.
24→12시간으로 바꿔도 10→5% 자동 변경은 없습니다. 새 간격마다 입력률이 적용됩니다. 간격별 변경 가정을 측정·명시하고 빈도와 총량 관계를 단정하지 마세요.
전체 보존 체인에 압축·사본 적용
260GB에서 압축 후50%면 130GB, 2사본이면260입니다. 여기엔 50을 넣으며 로그의 0.5배와 표기가 다릅니다. 전체·증분 같은 비율이고 중복 제거·공유 블록 절약은 추측하지 않습니다.
압축된 원본에 같은 압축을 다시 적용하면 과소입니다. 원본·변경·압축 후 비율의 단계를 맞추고 논리·물리 크기 구분도 확인하세요.
용량 충분과 복원 가능은 별도
정기 성공·체인 유지를 가정하며 누락·손상·키 분실·실패·설정은 검사하지 않습니다. 용량 추정 후 실제 시스템에서 복구 시험·시간을 확인하세요.
총량과 전체 수·증분 수·관측 위치·보존 방식을 남기세요. 두 세대를 구체 체인으로 펼치면 계산 근거를 설명할 수 있습니다.
오래된 전체 백업을 지우기 전에 증분 의존성을 확인하기
전체 백업이 보관 기간보다 오래됐다고 지우면 기간 안의 증분도 복원할 수 없게 될 수 있습니다. 변경분 체인은 기준 전체 백업이 필요합니다. 일일 양에 날짜를 곱한 것보다 커도 낭비가 아닐 수 있습니다. 보관할 복원 지점과 그것을 만드는 데 필요한 모든 파일을 구별하세요.
같은 보관 설정도 전체 백업 직후와 다음 전체 백업 직전에는 증분 수가 다릅니다. 260GB와 320GB 예는 한 시점만 보면 최대 용량을 적게 잡을 수 있음을 보여 줍니다. 합성 전체 백업, 중복 제거, 압축 블록 공유는 제품별 모델입니다. 실측으로 가정을 개선하되 이 단순 체인이 모든 제품을 재현한다고 하지는 마세요.
복사본이 늘면 용량도 늘지만 같은 장애로 함께 사라질 위치라면 기대한 보호가 아닐 수 있습니다. 계산은 위치, 권한 분리, 복원 절차를 검증하지 않습니다. 용량, 복원 가능성, 복구 시간, 남은 복원 지점은 각각 확인해야 합니다. 용량 추정만으로 백업 설계가 끝난 것은 아닙니다.