☰

백업: 장치에 남은 공간이 없습니다. 그런데 공간이 있나요?

tag-icon • tag-icon backup duplicity
백업: 장치에 남은 공간이 없습니다. 그런데 공간이 있나요?

Ubuntu 21.10, Gnome 40.4.0과 함께 제공되는 그래픽 백업 인터페이스. 백업을 수행할 때 "장치에 남은 공간이 없습니다"라는 메시지가 표시되기 시작했습니다. 100GB 정도의 파일 몇 개를 추가한 후에 이런 일이 발생했습니다. 무엇이 문제일까요?

  • 집을 백업하려는 로컬 디스크의 여유 공간은 1.5TB입니다.
  • 내 집의 전체 크기(이미 백업해 놓은 것은 454GB)이므로 크기가 문제가 되지 않습니다.
  • 이중성 로그 파일, 즉 프런트 엔드가 수행하는 작업은 어디에서 찾아야 합니까? /var/log에는 아무것도 없습니다
  • 내 집이나 /tmp에 아무 것도 쓰지 않아서 문제는 그 중 하나를 채우는 것이 아닙니다.

어떤 아이디어라도 환영합니다..

편집1:요청에 따른 blkid 및 df -h의 출력:

root@igtp:~# blkid
/dev/nvme0n1p1: UUID="F497-2C34" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="6df88602-8014-4894-8d4c-65b1b5cec43f"
/dev/nvme0n1p2: UUID="03387746-74e5-4e55-b57d-19400ddd6994" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b11921f6-d0ae-430d-8a68-42f47b5a0a3c"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop14: TYPE="squashfs"
/dev/loop15: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
/dev/loop17: TYPE="squashfs"
/dev/loop18: TYPE="squashfs"
/dev/loop19: TYPE="squashfs"
/dev/loop20: TYPE="squashfs"
/dev/loop21: TYPE="squashfs"
/dev/loop22: TYPE="squashfs"
/dev/loop23: TYPE="squashfs"
/dev/loop24: TYPE="squashfs"
/dev/loop25: TYPE="squashfs"
/dev/loop26: TYPE="squashfs"
/dev/loop27: TYPE="squashfs"
/dev/loop28: TYPE="squashfs"
/dev/loop29: TYPE="squashfs"
/dev/loop30: TYPE="squashfs"
/dev/loop31: TYPE="squashfs"
/dev/loop32: TYPE="squashfs"
/dev/loop33: TYPE="squashfs"
/dev/sdb1: LABEL_FATBOOT="Ubuntu Back" LABEL="Ubuntu Back" UUID="52B2-40B7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="9828faf4-dd30-4b07-8597-5143c7d6fbd3"
root@igtp:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1,6G  4,7M  1,6G   1% /run
/dev/nvme0n1p2  938G  485G  406G  55% /
tmpfs           7,7G   66M  7,6G   1% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           7,7G     0  7,7G   0% /run/qemu
/dev/nvme0n1p1  511M  5,3M  506M   2% /boot/efi
tmpfs           1,6G   13M  1,6G   1% /run/user/1000
/dev/sdb1       2,0T  557G  1,5T  28% /media/gl/Ubuntu Back
root@igtp:~# i

편집2: 출력 df -hTi:

tmpfs          tmpfs   2,0M  1,9K  2,0M    1% /run
/dev/nvme0n1p2 ext4     60M  741K   59M    2% /
tmpfs          tmpfs   2,0M   113  2,0M    1% /dev/shm
tmpfs          tmpfs   2,0M     5  2,0M    1% /run/lock
tmpfs          tmpfs   2,0M     1  2,0M    1% /run/qemu
/dev/nvme0n1p1 vfat       0     0     0     - /boot/efi
tmpfs          tmpfs   391K   246  391K    1% /run/user/1000
/dev/sdb1      vfat       0     0     0     - /media/gl/Ubuntu Back

답변1

해결책: 대용량 파일을 지원하는 파일 시스템으로 백업 하드 드라이브를 포맷하세요.

세부:

  • 백업 드라이브는 fat32로 포맷된 4TB Seageate였습니다.
  • ext4로 포맷하고 백업을 다시 실행하면 성공했지만:
  • 각 백업 파일의 크기는 약 50MB였습니다.
    • fat32 파일 시스템에서는 문제가 되지 않습니다.
    • 백업은 백업하는 동안 백업 스토리지에 큰 임시 파일을 저장하지 않습니다. 백업이 실패하기 전에 백업이 실행되는 동안 fat32 파일 시스템 활용도를 모니터링했는데 증가하지 않았습니다.
  • 하드 드라이브를 다시 fat32로 포맷하고 백업을 다시 실행하여 문제를 재현하려고 했지만 허용되지 않았습니다(fat32는 2TB보다 큰 디스크를 지원하지 않습니다. 처음에 어떻게 fat32로 포맷했습니까?!).

따라서 결론적으로 처음부터 시작하여 ext4로 포맷하면 작동하지만 이것이 이 특정 문제에 대한 실제 해결책인지는 확인할 수 없습니다.

추신: 조언을 주신 @Dan에게 감사드립니다.

답변2

나도 이것을 방금 얻었기 때문에 차임하고 싶었지만 내 백업 하드 드라이브는 이미 ext4였습니다(그리고 평판이 충분하지 않아 논평할 수 없습니다).

다른 백업 위치를 선택했더니 제대로 작동했습니다(새 백업이 시작되었습니다). 모든 디스크, 파티션, inode에는 충분한 공간이 있었습니다(80%/1TB 이상 여유 공간). 기존 디렉터리의 이름을 바꾸고 같은 이름으로 새 디렉터리를 만들었더니 제대로 작동했습니다.

누군가 이 문제를 겪고 더 많은 정보를 가지고 있다면 이에 대해 논평하는 것이 합리적일 수 있습니다.https://answers.launchpad.net/deja-dup/+question/694803

감사합니다. 도움이 되었기를 바랍니다.

관련 정보