バックアップ: デバイスに空き容量がありません。でも、空き容量はありますか?

バックアップ: デバイスに空き容量がありません。でも、空き容量はありますか?

Ubuntu 21.10、Gnome 40.4.0 に付属するグラフィカル バックアップ インターフェイス。バックアップ中に「デバイスに空き容量がありません」というメッセージが表示されるようになりました。これは、100 GB 程度のファイルをいくつか追加した後に発生しました。何が問題なのでしょうか?

  • 自宅のバックアップをしたいローカルディスクには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 にフォーマットされた 4 TB の Seageate でした。
  • ext4 にフォーマットしてバックアップを再実行すると成功しましたが、次の問題が発生しました。
  • 各バックアップ ファイルのサイズは約 50 MB でした。
    • これはFAT32ファイルシステムでは問題にならないはずです
    • バックアップ中に、バックアップ ストレージに大きな一時ファイルが保存されることはありません。バックアップが失敗する前にバックアップの実行中に fat32 ファイルシステムの使用率を監視しましたが、増加していませんでした。
  • ハード ドライブを fat32 にフォーマットし直してバックアップを再実行することで問題を再現しようとしましたが、できませんでした (fat32 は 2 TB を超えるディスクをサポートしていません。そもそもどうやって fat32 にフォーマットしたのでしょうか?!)

つまり、最初から始めて ext4 にフォーマットすると機能しますが、それがこの特定の問題に対する実際の解決策であるかどうかは確認できませんでした。

PS: 指摘してくれてありがとう@Dan

答え2

私もこれを入手したばかりですが、バックアップ ハード ドライブはすでに ext4 だったので、コメントしたいと思いました (評判が足りず、コメントできません)。

単に別のバックアップ場所を選択するだけで、うまくいきました (はい、新しいバックアップが開始されました)。すべてのディスク、パーティション、i ノードに十分なスペースがありました (80%/1TB 以上が空き)。既存のディレクトリの名前を変更し、同じ名前で新しいディレクトリを作成すると、うまくいきました。

もし誰かがこれに遭遇し、より詳しい情報を持っているなら、コメントする意味があるかもしれませんhttps://answers.launchpad.net/deja-dup/+question/694803

ありがとうございます。お役に立てれば幸いです。

関連情報