나를 위해 백업을 수행하는 rsnapshot이 있습니다. 그러나 각 백업은 소스 데이터의 전체 크기입니다. 하드 링크를 생성하지 않고, 교반될 때마다 단일(변경되지 않은) 파일의 새 복사본을 생성합니다. inode 번호를 서로 확인하고 하드 링크를 계산하여(없음) 각 백업마다 새 파일이 생성되는지 확인했습니다.
문제는 rsync 단계에서 발생하는 것 같습니다. rsync는 매번 모든 파일을 전송하는 것처럼 보입니다. 그 이유는 ">f..T......"내가 이해한 바로는 백업과 다른 타임스탬프를 기반으로 완전히 새로운 파일을 전송하고 생성하기 때문입니다. 실제로 타임스탬프는 예를 들어 로컬 시스템에서 상당히 다릅니다.
Access: 2024-03-18 10:14:28.285098766 +0000
Modify: 2023-11-23 21:04:36.000000000 +0000
Change: 2024-03-10 21:11:26.107904822 +0000
Birth: 2023-12-02 19:22:02.022412357 +0000
그리고 백업에 있는 동일한 파일은 다음과 같습니다.
Access: 2024-03-18 10:14:29.369122130 +0000
Modify: 2024-03-18 10:14:30.609148859 +0000
Change: 2024-03-18 10:14:31.817174900 +0000
Birth: 2024-03-18 10:14:29.369122130 +0000
그 결과 각 백업에 오랜 시간이 걸리고 많은 디스크 공간을 차지하게 되는데, 이는 제가 예상했던 것과 정반대입니다.
--time백업의 타임스탬프를 "수정"하기 위해 rsnapshot/rsync 구성을 추가하면 이 문제를 해결할 수 있다고 생각합니다 . 그러나 그것은 "즉시" 작동하는 방식과 동일하지 않으므로 그렇게 하기가 꺼려집니다.
내 구체적인 질문은 다음과 같습니다.
- 이 경우 백업의 타임스탬프가 잘못되었나요? 그들은 실제로 무엇이어야 하는가?
- 여기서 무엇이 잘못될 수 있나요? 첫 번째 백업에 있어야 하는 것처럼 첫 번째 백업을 만드는 단계를 놓친 것 같습니다
--time. --time기본적으로 존재하지 않기 때문에 구성에 추가하는 것은 나쁜 생각입니까?
답변1
내 질문에 대답하려면 다음을 수행하십시오.
이 문제는 전적으로 내 rsnapshot.conf에 --times비슷한 내용이 없기 때문에 발생합니다.
특히 기본 rsnapshot.conf는 (github를 통해) 제공되었으며 #rsync_short_args -a주석 처리를 제거할 만큼 충분히 이해가 되었지만 내 버전은 rsync_short_args -r, ( --recursive)로 모든 파일을 백업에 복사할 수 있었지만 원래 버전에 표시된 것처럼 타이밍이 부적절했습니다. 문제의.
또한 내 배포판과 함께 다운로드된 기본 rsnapshot.conf를 확인했으므로 -a이 사건을 전적으로 내 잘못으로 간주하겠습니다.