Restic: 스냅샷 나열 시 백업 크기 출력(향상)

제안해 주셔서 감사합니다. 크기가 어떻게 될 것으로 예상하십니까? 모든 데이터가 중복 제거되므로 특정 스냅샷의 "크기"를 결정하기가 쉽지 않습니다. 그것이 해당 스냅샷에서 참조된 모든 데이터의 크기입니까? 아니면 스냅샷을 찍을 때 리포지토리에 아직 저장되지 않은 데이터(새 데이터)입니까?

이것은 아주 좋은 제안입니다. 오른쪽의 숫자는 리포지토리에 추가된 Blob의 누적 크기여야 합니다. 모든 백업 실행에서 가장 흥미로운 양적 매개변수입니다.

오늘 밤 내 증분으로 얼마나 많은 공간이 낭비되었습니까? 앗, 어젯밤보다 10배 더 많네요. 여기에 쓰레기를 남겼습니다(또는 제외를 넣는 것을 잊었습니다). 청소하는 것이 좋습니다. ;)

@zcalusic 제안에 +1

"새" blob(특정 스냅샷에 의해 추가됨)의 크기 문제는 시간이 지남에 따라 관련성이 낮아집니다. 왜냐하면 이러한 blob은 이후 스냅샷에서 참조되기 때문입니다. 또한 이전 스냅샷이 제거되면 특정 스냅샷에서 참조하는 Blob 수가 늘어납니다.

백업이 완료된 직후에 이 정보를 인쇄하는 것이 중요하다고 생각하며, 저장소의 스냅샷 데이터 구조에 기록할 수도 있습니다. 나는 특정 스냅샷에 대해 일종의 '세부 정보' 보기를 추가할 계획을 세웠고 거기에 새 얼룩의 수와 크기를 표시하는 것이 좋은 생각이라고 생각하지만 개요(명령 snapshots ) 그것은 충분히 관련이 없습니다. 거기에서 나는 restic이 특정 스냅샷의 전체 크기를 표시해야 한다고 생각합니다(복구할 경우 얻을 수 있는 것). 왜냐하면 변경되지 않기 때문입니다.

나는 즉시 rdiff-backup의 통계 플래그를 상기시켰습니다(https://www.systutorials.com/docs/linux/man/1-rdiff-backup-statistics/ 참조). 때때로 2개의 스냅샷 사이에 일종의 델타를 보는 것이 좋습니다.

사실, 하지만 그것은 다른 것입니다. 실시간으로 계산되고 두 개의 스냅샷을 비교합니다. 이와 같은 것을 추가할 수도 있지만 snapshots 개요 목록에 대해 그렇게 하는 것은 너무 비쌉니다(적어도 현재 데이터 구조에서 사용할 수 있는 정보로는).

스냅샷의 '고유한' 데이터 크기와 스냅샷의 전체 크기(중복 제거된 데이터 포함)를 아는 것이 유용할 수 있습니다.

IMO 새 스냅샷에 사용된 추가 공간의 양을 알면 매우 유용할 것입니다. 이것은 백업 중에 계산되고 스냅샷의 메타데이터에 저장된 물리적 저장 공간일 수도 있습니다. 일부 스냅샷이 제거되면 이 메타데이터는 이후의 모든 스냅샷에서 무효화되어야 합니다.

이 방향으로 다른 작업이 수행되지 않더라도 그러한 기능에 감사할 것이라고 생각합니다. 그러나 일부 이전 백업이 제거된 후 이 "추가 크기"를 다시 계산하는 옵션도 좋습니다. 이것이 Mac OS의 Time Machine에서 BackupLoupe 가 하는 일이라고 생각합니다. (Time Machine의 중복 제거는 매우 기본이지만 "스냅샷 크기"를 정의하는 문제는 동일합니다).

내가 직접 알고 싶은 가장 기본적인 사항은 스냅샷 X의 내용을 복원할 경우 대상 디스크에서 사용하는 디스크 공간의 양입니다.

이 있다면 가급적 나는 또한 파일의 서브 세트, 예를 들어,이 정보를 얻을 수있을 것입니다 size 등의 동일한 유형을했다 명령을 /를 같은 옵션 제외 restore 명령을 사용합니다. 또는 restore 명령에 실제로 복원하는 대신 이와 같은 통계만 보고하도록 하는 옵션이 있는 경우.

이 문제를 지적해 주신 @rawtaz 에게 감사드립니다.

계량 스토리지(Backblaze B2)에 백업을 저장하고 있습니다. 백업을 실행할 때마다 생성하는 새 데이터의 양을 알고 싶습니다. 이것은 백업 프로세스 중에 계산하기 쉬워야 할 것 같습니다. restic이 백업을 마무리하는 과정에서 단순히 그것을 기록한다면 나는 기쁠 것입니다. 그러나 이것을 스냅샷의 속성으로 저장하는 것도 유용할 것 같습니다(나중에 쿼리할 수 있도록).

리포지토리를 광범위하게 다시 검색해야 하는 작업에는 관심이 없습니다. 추가 비용이 발생하기 때문입니다.

소식이 있나요?

안녕하세요

나는 이 제안을 두 번째로 하고 싶다. 기존 스냅샷에 대한 '복원하면 이 스냅샷의 크기'와 스냅샷이 생성될 때 '이 스냅샷이 추가된 양' 외에 세 번째 제안이 있습니다.

또한 '다음 스냅샷을 제거하면 저장소 크기가 얼마나 줄어들까요?'라는 질문에 답할 수 있으면 도움이 됩니다. 이것은 스냅샷을 삭제할지 여부를 결정할 때 restic forget --prune --dry-run 에서 유용합니다. 예를 들어, 최근 리포지토리에 40개의 스냅샷 중 20개를 드롭했는데 크기가 1.1GB에서 1.0GB로 줄었습니다. 이렇게 하면 100MB만 절약할 수 있다는 것을 알았다면 이전 스냅샷을 보관했을 것입니다.

@mholt 는 일부 통계를 보여주기 위해 #1729를 만들었습니다. 아마도 그는 이 PR의 진행 상황에 대해 말할 수 있을 것입니다.

@dimejo 완료되었습니다. 검토/병합되기를 기다리기만 하면 됩니다. :)

여기에서 정말 오래된 문제로 건너뛰지만 나에게 스냅샷을 생각할 때 2개의 중요한 크기 필드가 있습니다.

• 스토리지의 스냅샷 크기
• 복원 크기

예

$ restic snapshots
ID        Date                 Host        Tags        Directory    Snapshot Size   Restore Size 
--------------------------------------------------------------------------------------------------
5b969a0e  2016-12-09 15:10:32  localhost               myfile       10 MB           57 GB

최소한 단일 스냅샷이 사용하는 공간과 복원을 수행하는 데 필요한 공간을 알 수 있습니다.

@fd0이 이미 지적했듯이 restic snapshots 호출할 때마다 크기를 인쇄하는 것은 비용이 많이 드는 명령입니다. 그러나 restic stats 를 사용하여 개별 스냅샷 또는 전체 저장소의 크기를 인쇄할 수 있습니다.

백업이 완료된 직후에 이 정보를 인쇄하는 것이 중요하다고 생각하며, 저장소의 스냅샷 데이터 구조에 기록할 수도 있습니다. 나는 특정 스냅샷에 대해 일종의 '세부 정보' 보기를 추가할 계획을 세웠고 거기에 새 얼룩의 수와 크기를 표시하는 것이 좋은 생각이라고 생각하지만 개요(명령 snapshots ) 그것은 충분히 관련이 없습니다. 거기에서 나는 restic이 특정 스냅샷의 전체 크기를 표시해야 한다고 생각합니다(복구할 경우 얻을 수 있는 것). 왜냐하면 변경되지 않기 때문입니다.

좋은 아이디어! 이 개선 사항이 대기열에 있습니까? 리포지토리에서 중복 제거된 데이터의 전체 크기도 이러한 개요에 도움이 됩니다.

이 기능에 대한 업데이트가 있습니까? 각 스냅샷 크기 와 복원 크기를 볼 수 있어 매우 유용합니다.

+1

지금은 아닙니다. 업데이트가 있는 경우 이번 호에 표시됩니다.