Join Log in
Score:0
gl_off avatar Ubuntu

Backup: No space left on device. But space is there?

cn flag
gl_off

Ubuntu 21.10, graphical backup interface that comes with Gnome 40.4.0. I started getting "No space left on the device" when I am doing the backup. This happened after I added a few files which are at the order of 100 GB.. What might be the problem?

  • The local disk on which I want to backup my home has 1.5 TB free
  • The full size of my home (which I have already backed up is 454 GB) so, the size should not be the problem
  • Where should I find the duplicity log files i.e. what the front-end is doing? There is nothing in /var/log
  • It is not writing anything in my home or in /tmp so the problem is not in filling either of those..

Any ideas are welcome..

EDIT1: The outputs of blkid and df -h as requested:

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

EDIT2: Output of 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
57
0 + 0
Simon Sudler avatar
us flag
Simon Sudler
Plase at the output of `df -h` and `blkid`... it is hard to guess what is going on in your system
1
Reply
in flag
matigo
You're right that there appears to still be a great deal of space. Could you [edit] your question to include the Terminal output of `df -I /`? I wonder if you've run out of inodes ...
3
Reply
FedKad avatar
cn flag
FedKad
Can you replace `df -h` output with `df -hTi` output in your original question?
0
Reply
gl_off avatar
cn flag
gl_off
@matigo Good idea. But I thought zero inodes on vfat is expected. Here is how the device is mounted: `root@igtp:~# cat /proc/mounts | grep sdb /dev/sdb1 /media/gl/Ubuntu\040Back vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0`
0
Reply
jp flag
Dan
I'm not sure how duplicity stores its data, so this is just a theory. But if it stores the first version of a file as-is, it's highly possible the limitation is due to the disk format being a FAT filesystem. The FAT format has a limitation on the file size of 4GB, so anything larger than that will fail. Since you mentioned that you added a few files that are over 100GB, I have a suspicion it's due to that, but I can let others here confirm or deny.
0
Reply
gl_off avatar
cn flag
gl_off
Thanks @Dan I was assuming that all new external hard drives come pre-formatted with exFAT... How silly of me - it is indeed FAT32. Ok, I'll forma it with ext4 and try again.
0
Reply
jp flag
Dan
Feel free to self-answer if that was the solution of your problem :D
0
Reply
Score:0
gl_off avatar Ubuntu
cn flag
gl_off

Solution: Format the backup hard drive in a filesystem that supports big files.

Details:

  • The backup drive was a 4 TB Seageate which was formatted to fat32.
  • Formatting it to ext4 and rerunning the backup did succeed BUT:
  • Each of the backup files were around 50MB in size.
    • This should not be a problem for fat32 file system
    • The backup does not save big temporary files on the backup storage while backing up - I have monitored the fat32 filesystem utilization while the backup was running before it was failing and it did not increase.
  • I tried to reproduce the problem by formatting the hard drive back to fat32 and re-runnig the backup but I was not allowed to (fat32 does not support disks bigger than 2 TB - how was it formatted in fat32 in the first place?!)

So, bottom line, starting from scratch and formatting to ext4 works, but if that is the actual solution to this particular problem - I could not confirm.

P.S.: Thanks @Dan for the pointer

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.