Bom dia, tenho um "pequeno" problema na minha máquina de backup. Não é possível fazer os backups, porque detecta 96% do espaço utilizado. Mas isso não é verdade.
Eu lancei alguns comandos na máquina física, aqui eu te dou as saídas.
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
Como você pode ver, em / dev / mapper / vg_data-lv_data_backup há 30GB desaparecidos. Eu sei que é uma partição ext4 e reserva 5% de espaço para comandos raiz. Mas isso não justifica esse espaço errado ...
Aqui estão outros comandos:
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
Obrigado
Como você escreveu, o ext4 reserva 5% do espaço para o root. Não para "comandos" raiz, mas para arquivos. 5% de 640 Gb são 32 Gb, que erros de arredondamento do módulo é a quantidade de espaço em disco que você está procurando. Esses Gb estão fisicamente no disco, mas não estão disponíveis para usuários normais, portanto, não são mostrados na coluna "disponível" de df .