일부 클라이언트의 백업 전략을 준비 중이며 원격 백업의 중복성에 기울어지고 있습니다 (내부 / 위치 백업에 이미 rdiff-backup 사용).
자주 전체 백업을하는 것이 합리적입니까? 이중화는 앞으로 증가하므로 각 증가 백업은 이전 증가에 의존하고 모든 백업은 마지막 전체 백업에 크게 의존합니다. 그것이 부패되면 나쁜 일이 일어납니다. 관련 질문 : Duplicity는 증가 백업의 일관성을 테스트합니까?
내가 가정 않는 , 너무 자주마다 전체 백업을 원하는 이중성은 그 전체 백업을 생성 않습니다 얼마나 효율적으로? 파일 서명을 확인하고 이전의 전체 백업 / 증분에서 변경되지 않은 데이터를 복사 할 수 있습니까? 기본적으로 새로운 '변경된'데이터를 전송하고 기존의 변경되지 않은 데이터를 병합하는 새로운 '전체'아카이브를 작성합니까?
지금 당장은 전체 백업을 실행해야하지만 전체 백업을 일관되게 큰 대역폭으로 사용하면 일부 클라이언트에서이를 불합리하게 만들 수 있습니다.
답변:
자주 전체 백업을하는 것이 합리적이라고 생각합니다. 대부분의 컴퓨터는 몇 개월마다 하나씩 수행하도록 구성되어 있습니다. 그 숫자에 대한 마술은 없습니다. 올바른 가치는 보유한 데이터의 양, 데이터의 변경 속도, 가장 최근 스냅 샷 이외의 것으로부터 복원 할 가능성, 트래픽 및 스토리지 비용의 양에 따라 달라집니다 , 그리고 당신은 얼마나 편집증입니까. 다른 사람들은 매주 전체 백업을 원할 수 있습니다.
때때로 전체 백업을 수행하지 않으면 아카이브 크기와 복구 시간이 계속 증가합니다.
나는 이중성이 특별히 "check"명령 http://pad.lv/660895을 가지고 있다고 생각하지 않지만 , 그렇게하면 좋을 것입니다. 매번 테스트 복원을 수행하는 것이 매우 신중합니다.
관련 질문은 둘 이상의 백업 체인을 유지해야하는지 여부입니다. 다시, 그것은 비용에 달려 있습니다. 하나를 유지해야하는 한 가지 이유는 하드웨어 오류, OS 오류 또는 이중성 버그로 인해 현재 체인이 손상된 경우 해당 체인에서 복원 할 수 있기 때문입니다. 물론 이전 체인이 매우 오래된 경우이를 복구하는 것은 가치가 제한 될 수 있습니다.
전체 백업을 수행하면 항상 전체 데이터 사본이 업로드됩니다.
클라이언트 문제가 트래픽 요금이 아닌 사용 된 대역폭의 일부인 경우, 예를 들어 다음과 같이 실행할 수 있습니다 trickle.
요구하는 것을 합성 전체 백업 이라고하며 , 이는 증분 백업을 대상 측의 이전 전체 백업 (예 : 백업 서버)과 병합하여 전체 백업을 얻는 프로세스를 나타냅니다.
Duplicity에 익숙하지는 않지만 웹 사이트 에서 합성 전체 백업을 수행하지 않는 것으로 보입니다. 모든 증분을 기반으로하는 모든 증분을 다시 유지해야합니다. 그 경우 입니다 경우에, 당신은 아마, 모든 너무 자주 전체 백업을 강제하기 때문에 할 것입니다 :
합성 전체를 달성하는 한 가지 흥미로운 방법 은 --link-dest = DIR 옵션 과 함께 rsync 를 사용 하거나 rsnapshot을 사용하는 것 입니다. 각 증분 백업 간의 차이 만 저장하지만 각 백업은 전체 백업으로 나타납니다. 삭제하면 어떤 그들의를 자동으로 적절하게 증분을 병합합니다. 하드 링크의 마법을 통해이 작업을 수행하므로 diff는 파일 기반이됩니다 (파일이 변경되어 diff에 포함되거나 포함되지 않음).