다시 설치하기 위해 홈 서버를 백업하고 있고, 전체 파일 시스템 트리를 백업하기 위해 rsync를 사용하고 있습니다. 이것은 내가 사용하는 rsync 명령입니다.
rsync -aAXH --info=progress2 --exclude=dev/ --exclude=proc/ --exclude=sys/ --exclude=tmp/ --exclude=run/ --exclude=mnt/ --exclude=media/ --exclude=lost+found --exclude=srv/ / /srv/dev-disk-by-label-data/backup/pensieroprofondo/debian10/btrfs/
명확히 하자면, 다른 디스크에 있는 /것을 제외하고 의 모든 항목은 동일한 디스크에 있습니다(다른 파티션에 있음에도 불구하고) /srv/dev-disk-by-label-data/.
루트 파일 시스템은 이 작업 전에 60-70%가 찼던 작은 SSD(128GB)에 설치되어 있습니다(정확히 기억이 나지 않습니다). 지난 몇 년 동안 디스크가 꽉 차서 백업을 위해 rsync 명령을 실행하는 것 외에는 지난 며칠 동안 다른 작업을 수행하지 않았습니다. 이제 시스템 디스크가 완전히 가득 차서( df -h사용된 111G 중 108G 보고) 약간 사용할 수 없게 되고(예: nginx에서 내부 서버 오류 발생) rsync 명령 실행이 다시 실패하지만(실제로 오류가 발생하지 않음) 진행이 종료됩니다. 0%입니다.) 적어도 나는 여전히 ssh로 접속할 수 있다.
아직 공간이 정리되었는지 확인하기 위해 다시 시작할 기회가 없었지만, 그럼에도 불구하고 이것이 내가 하고 있는 일의 의도된 동작이라고 생각하지 않습니다. rsync가 소스 디스크 공간의 30-40%를 차지하는 이유는 무엇입니까? 도움이 된다면 스크린 세션에서 rsync 명령을 실행하겠습니다.
답변1
내 데이터베이스 백업(전체 1.8T와 같이 많은 여유 공간이 있고 단일 백업 파일이 100GB에 불과한 별도의 논리 볼륨에 있음)을 NFS로 재동기화할 때도 동일한 문제가 발생했습니다. 여유 공간(예: ~60TB의 여유 공간), 루트 파티션( /다른 별도의 논리 볼륨에 있음, 총 200GB) 공간 사용량이 ~68%에서 100%로 증가하고 결국 rsync가 실패했음을 발견 했습니다.
rsync: write failed on "some NFS path": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]
NFS에 동기화할 때 rsync일부 임시 파일이 파티션에 기록되는 것 같습니다 /. Google을 검색했는데 모두 임시 파일/디렉토리가 rsync 대상에 존재할 것이라고 말하지만 제 경우에는 전혀 관련 없는 위치에 저장되어 있습니다. rsync 대상이나 소스가 아닌 경로입니다. 그리고 rsync가 실패한 후 공간이 복구되었습니다 /(68%로 떨어졌습니다).
하지만 더 놀랐던 점은 rsync를 백업하기 전에 한 번 확인했는데 성공했다는 것입니다. rsync가 시작되었을 때 /공간 사용량은 ~였고 22%rsync도 /rsync가 끝나면 파티션에 "무언가"를 썼고 공간 사용량은 ~입니다. 사용량 /에 도달했으며 68%절대 출시되지 않습니다! , 실패한 rsync가 /공간 사용량으로 시작되는 것을 볼 수 있습니다 68%.
아직 조사 중인데 뭔가 발견하면 업데이트하겠습니다.
고쳐 쓰다:
마침내 왜 이런 일이 발생했는지 알아냈습니다. 간단히 말해서, autofs프로세스가 종료되어 NFS 경로가 /net/some_host/path/to/backup절대 /파티션 경로가 되었습니다(그래서 rsync가 데이터를 /파티션에 복사했습니다). 다시 시작한 후에는 autofsrsync가 성공할 수 있으며 /파티션 공간을 차지하지 않습니다.
따라서 대상 경로가 원본 디스크에 속하는지 주의 깊게 확인하시기 바랍니다.