Creo que me pegué un tiro en el pie. Hace mucho tiempo intenté hacer una copia de seguridad de una vieja máquina Linux en un nas usando el comando mount bind:
montar --bind / /mnt/src tar -C /mnt/src -c . > /mnt/backup_to_nas/full-backup- date '+%d-%B-%Y'.tar.gz --exclude=tmp --exclude=mnt
Entonces me di cuenta de que nunca había desmontado /mnt/src
Mi pregunta es ¿esto ocupa el doble de espacio en el / que tengo? Lamentablemente, me he quedado sin espacio y no estoy seguro de si estoy persiguiendo mi cola tratando de eliminar archivos para recuperar espacio.
df -h muestra:
[root@web-server mnt]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 4.0K 1.9G 1% /dev/shm
tmpfs 1.9G 194M 1.7G 11% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/vda2 7.6G 7.6G 0 100% /
/dev/vda1 190M 171M 5.3M 98% /boot
/dev/vdb 230G 152G 67G 70% /usr/local
tmpfs 379M 0 379M 0% /run/user/0
tmpfs 379M 0 379M 0% /run/user/2527
tmpfs 379M 0 379M 0% /run/user/2543
10.50.1.104:/data 9.1T 8.0T 610G 94% /mnt/backup
tmpfs 379M 0 379M 0% /run/user/2539
10.75.0.199://volume1/ICCBackups 32T 4.2T 28T 14% /mnt/backup_to_nas
tmpfs 379M 0 379M 0% /run/user/500
lsblk muestra:
[root@web-server mnt]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 8G 0 disk
├─vda1 253:1 0 200M 0 part /boot
└─vda2 253:2 0 7.8G 0 part /mnt/src
vdb 253:16 0 232.8G 0 disk /usr/local
hizo una comprobación de espacio en la raíz:
du -xhs * | ordenar -rh
134G home
15G data
6.9G mnt
186M run
170M boot
52M etc
848K ARC-History.pdf
16K lost+found
8.0K export
8.0K backup
4.0K media
4.0K check_permissions.py
0 sys
0 proc
0 lib64
0 lib
0 dev
0 bin
No entiendo por qué algunas carpetas grandes como /home son más grandes que lo que informa df -h, así que hice un montaje | Regresé a casa y obtuve:
[root@web-server mnt]# mount | grep home
/dev/vdb on /home type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /usr/local/home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vdb on /home/workers/public_html/VM-SYSTEMS type ext4 (rw,relatime,data=ordered)
/dev/vdb on /usr/local/home/workers/public_html/VM-SYSTEMS type ext4 (rw,relatime,data=ordered)
Parece que si pudiera descubrir cuáles son y cómo reubicarme, podría conseguir algo de espacio para respirar:
/dev/vda2 on /home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /usr/local/home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
Por otra parte, todo esto para decir: ¿mi comando mount --bind de / into /mnt/src ocupaba doble espacio? ¿Hay algo que no entendí (probablemente) al hacer esto? Hice un lsof /mnt/src y parece que todo lo está usando.
pero comencé con esto para informar, no estoy seguro si es relevante:
[root@web-server mnt]# lsof /mnt/src
lsof: WARNING: can't stat() ext4 file system /var/www/html/net-status/bw-mon (deleted)
Output information may be incomplete.
lsof: WARNING: can't stat() ext4 file system /usr/local/www/net-status/bw-mon (deleted)
Output information may be incomplete.
Así que no estoy seguro de por dónde empezar a eliminar archivos grandes, ya que los encuentro en /? (¿aunque parezca que /home está en otro lugar?). ls -lh no lo muestra como un enlace simbólico.
[root@web-server /]# ls -lh
total 1.2M
-rw------- 1 root root 847K Jul 27 2020 ARC-History.pdf
drwxr-xr-x 3 root root 4.0K Sep 13 17:21 backup
lrwxrwxrwx 1 root root 7 May 11 2018 bin -> usr/bin
dr-xr-xr-x. 5 root root 3.0K Aug 16 18:06 boot
-rw-r--r-- 1 root root 3.3K May 12 2019 check_permissions.py
-rw------- 1 root root 0 Sep 13 17:33 core.20448
-rw------- 1 root root 0 Sep 13 17:46 core.28055
drwxr-xr-x 7 root root 4.0K Sep 13 17:16 data
drwxr-xr-x 18 root root 3.1K Sep 12 18:08 dev
drwxr-xr-x. 148 root root 12K Aug 31 17:26 etc
drwxr-xr-x 3 root root 4.0K Apr 2 2015 export
drwxr-xr-x 22 root root 4.0K Aug 27 18:06 home
lrwxrwxrwx 1 root root 7 May 11 2018 lib -> usr/lib
lrwxrwxrwx 1 root root 9 May 11 2018 lib64 -> usr/lib64
drwx------. 2 root root 16K Mar 31 2015 lost+found
drwxr-xr-x. 2 root root 4.0K Apr 12 2018 media
drwxr-xr-x. 6 root root 4.0K Feb 9 2023 mnt
drwxr-xr-x. 7 root root 4.0K Aug 25 15:13 opt
dr-xr-xr-x 225 root root 0 Nov 8 2021 proc
dr-xr-x---. 26 root root 12K Aug 25 15:19 root
drwxr-xr-x 48 root root 1.5K Sep 13 17:01 run
lrwxrwxrwx 1 root root 8 May 11 2018 sbin -> usr/sbin
-rw-r--r-- 1 root root 0 May 15 2019 searchresults.txt
drwxr-xr-x. 2 root root 4.0K Apr 12 2018 srv
dr-xr-xr-x 13 root root 0 Nov 29 2021 sys
drwxrwxrwt. 16 root root 244K Sep 13 17:49 tmp
drwxr-xr-x. 14 root root 4.0K May 11 2018 usr
drwxr-xr-x. 25 root root 4.0K Aug 9 20:21 var
drwxr-xr-x 2 root root 4.0K Aug 9 2015 zaphod-data
EDITAR: Miré el archivo fstab que arrojó algo de luz sobre dónde están las cosas:
UUID=c9d6c99f-d7a5-4117-93ba-029cc34d8b61 / ext4 defaults 1 1
UUID=19fcad32-0fcb-423a-87e9-586d03d2e406 /boot ext4 defaults 1 2
#LABEL=/home /home ext4 defaults 1 2
#192.41.211.105:/export/images /export/images nfs rsize=32768,wsize=32768,actimeo=0,bg,intr
LABEL=local-web-server /usr/local ext4 defaults 1 2
/usr/local/home /home none bind 0 0
/usr/local/www /var/www/html none bind 0 0
/usr/local/data /data none bind 0 0
/tmp/rrdweather /home/weather/public_html/weather_rrd none bind 0 0
/usr/local/data /data none bind 0 0
/home/workers/Site/VM-SYSTEMS /home/workers/public_html/VM-SYSTEMS none bind 0 0
#/home/workers/public_html/WebCalendar-1.2.3 /home/workers/public_html/WebCalendar none bind 0 0
#/home/workers/public_html/WebCalendar-1.2.0 /home/workers/public_html/WebCalendar~ none bind 0 0
/home/workers/public_html/net-status /usr/local/www/net-status none bind 0 0
/tmp/bw-mon /var/www/html/net-status/bw-mon none bind 0 0
/var/lib/smokeping/images /var/www/html/smokeping/images none bind 0 0
#mounting for our cheezy backup of web-server
10.50.1.104:/data /mnt/backup nfs
Edición 2: Entonces me di cuenta de que si hacía el comando de clasificación en /mnt/src obtenía información más precisa...
[root@web-server src]# du -xhs * | sort -rh
4.8G usr
707M var
421M opt
397M backup
168M root
150M tmp
52M etc
848K ARC-History.pdf
16K lost+found
12K mnt
8.0K export
4.0K zaphod-data
4.0K sys
4.0K srv
4.0K run
4.0K proc
4.0K media
4.0K home
4.0K dev
4.0K data
4.0K check_permissions.py
4.0K boot
0 searchresults.txt
0 sbin
0 lib64
0 lib
0 core.28055
0 core.20448
0 bin
Me muestra tal vez espacio para borrar en usr (no tengo idea de qué, no soy un gurú de Linux), var tenía algunas cosas interesantes que pude borrar (registros antiguos). Todavía estoy trabajando en ello, pero supongo que el quid de lo que estoy preguntando es ¿debería realmente desmontar ese /mnt/src? ¿O está bien dejarlo funcionar así ya que cada vez que intento emitir el comando dice que está ocupado?
Respuesta1
El problema
/mnt/srcno ocupa espacio, pero debes desmontarlo para no confundir algunas herramientas, incluidas las que realizan copias de seguridad. Por ejemplo lsblk, elige mostrar la primera montura coincidente y muestra /mnt/srcen lugar de /cuál /dev/vda2no es óptima.
La mayoría de los sistemas Linux ejecutansistemadentonces asumo que este sistema está funcionandosistemad.
sistemadse vuelve a montar / comocompartidomount en lugar del valor predeterminado del kernel de Linux deprivado. Consulte la documentación del kernel sobre la propagación de montajes aquí:Subárboles compartidos. Eso significa que cuando posteriormente se agregan (o eliminan y vuelven a agregar) montajes adicionales, el mecanismo de propagación /también los monta automáticamente , y/mnt/srcdesde sucompartido(en vez deesclavo) intentar desmontarlos /mnt/srctambién los desmontará de/, ya sea fallando (debido a que los procesos lo usan) o causando posibles daños si tienen éxito (también desaparecerán de su punto de montaje original).
¿Qué se debería haber hecho?
Realice siempre estos montajes de unión utilizando elprivadoopción de propagación. Mientras lo hace, cuando sea para fines de copia de seguridad, también haga que el montaje de enlace se (re) monte como solo lectura:
mount --bind --make-private -o ro / /mnt/src
De esa manera no habrá más interacción con otrosmonturassucederá y esto se puede desmontar en cualquier momento con un simple gesto umount /mnt/srcsin ningún efecto secundario.
¿Qué se puede hacer para solucionar el problema actual?
Entonces, para hacer esto correctamente sin afectar los puntos de montaje originales reales, se deben configurar todos los montajes problemáticos comoprivadopara que puedan desmontarse sin afectar el punto de montaje original.
Hago un ejemplo aquí (todo comoraízusuario) imitando el caso de OP donde después de haber hecho:
# mkdir -p /mnt/src
# mount --bind -o ro / /mnt/src
Y luego (en un lugar que no pueda ser perjudicial):
# mkdir -p /root/intheway
# mount -t tmpfs tmpfs /root/intheway
conduciendo entonces a:
# umount /mnt/src
umount: /mnt/src: target is busy.
identificar montajes problemáticos usando
findmnt:# findmnt --kernel --submounts --list -o +PROPAGATION /mnt/src TARGET SOURCE FSTYPE OPTIONS PROPAGATION /mnt/src /dev/vda2 ext4 ro,relatime,errors=remount-ro shared /mnt/src/root/intheway tmpfs tmpfs rw,relatime,inode64 sharedEstablecer todos los encontradoscompartidose monta comoprivado, incluido
/mnt/src:# mount --make-private /mnt/src/root/intheway # mount --make-private /mnt/srcdesmontarlos (en orden inverso al orden en que se montan si hay varias profundidades), terminando con
/mnt/src# umount /mnt/src/root/intheway # umount /mnt/src
Esto no interrumpió el montaje (compartido) que estaba en el camino:
# findmnt --kernel --list -o +PROPAGATION /root/intheway
TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/root/intheway tmpfs tmpfs rw,relatime,inode64 shared