0

Good morning, I've a "little" problem in my backup machine. It can not be able to do the backups, because it detect 96% space used. But it is not true.

I launched some commands on the physical machine, here I give you the outputs.

ubuntu@BACKUP:~$ sudo df -h Filesystem Size Used Avail Use% Mounted on udev 992M 0 992M 0% /dev tmpfs 200M 21M 180M 11% /run /dev/xvda1 20G 4.8G 15G 25% / tmpfs 1000M 0 1000M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1000M 0 1000M 0% /sys/fs/cgroup /dev/mapper/vg_data-lv_data_backup 640G 580G 30G 96% /data/backup /dev/mapper/vg_data-lv_data_archive 640G 49G 559G 9% /mnt/lv_data_archive tmpfs 200M 0 200M 0% /run/user/1000 

As you can see, in /dev/mapper/vg_data-lv_data_backup there are 30GB disappeared. I know it is an ext4 partition and it reserves 5% space for root commands. But it doesn't justify this wrong space...

Here other commands:

root@BACKUP:/data# du -h -d1 /data/backup 16K /data/backup/lost+found 531G /data/backup/BackupPC 50G /data/backup/DumpDB 580G /data/backup 

ubuntu@BACKUP:~$ sudo lsof +L1 | numfmt --field=7 --to=iec --invalid='ignore' COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME systemd-j 388 root txt REG 202,1 319K 0 52456 /lib/systemd/systemd-journald (deleted) dhclient 1010 root txt REG 202,1 476K 0 4269 /sbin/dhclient (deleted) lxcfs 1202 root txt REG 202,1 19K 0 24454 /usr/bin/lxcfs (deleted) systemd-l 1233 root txt REG 202,1 605K 0 52482 /lib/systemd/systemd-logind (deleted) agetty 1476 root txt REG 202,1 44K 0 4308 /sbin/agetty (deleted) agetty 1482 root txt REG 202,1 44K 0 4308 /sbin/agetty (deleted) BackupPC 1625 backuppc txt REG 202,1 1.9M 0 6550 /usr/bin/perl (deleted) 

root@BACKUP:/data# dumpe2fs -h /dev/mapper/vg_data-lv_data_backup dumpe2fs 1.42.13 (17-May-2015) Filesystem volume name: <none> Last mounted on: /data/backup Filesystem UUID: 8f2689b8-6ed0-47d2-833c-904097eb6a34 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 42598400 Block count: 170393600 Reserved block count: 7869498 Free blocks: 57647530 Free inodes: 40094191 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 983 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Tue Aug 22 12:04:28 2017 Last mount time: Fri Dec 15 12:20:05 2017 Last write time: Fri Dec 15 12:20:05 2017 Mount count: 16 Maximum mount count: -1 Last checked: Tue Aug 22 12:04:28 2017 Check interval: 0 (<none>) Lifetime writes: 5450 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: fd48ebc6-99be-468a-8c2d-3aa600ce2412 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x00011b23 Journal start: 30397 

Thank you

1
  • 2
    What is 5% of 640 GB? Commented May 29, 2018 at 12:30

1 Answer 1

1

As you wrote, ext4 reserves 5% of the space for root. Not for root "commands", but for files. 5% of 640 Gb are 32 Gb, which modulo rounding errors is the amount of disk space you are looking for. These Gb are physically on disk, but not available to normal users, hence not shown in the "available" column of df.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.