私はpacket.netにサーバーを持ち、バックアップを処理する/ BACKUPフォルダにマウントされた外部ボリュームを接続しました。昨日、プライマリパーティションに問題があるというメールが届きました。ほとんどいっぱいですか?どういうわけか、リンクされたボリュームが切断され、マウント/BACKUP(私の意見では)アンマウントされ、このフォルダに複数のバックアップが作成され、ローカルドライブに「移行」されました。外部ボリュームを再接続すると、/ BACKUPフォルダが自動的にマウントされます。その中のすべてのファイルを削除しましたが、プライマリパーティションにはまだ90%がいっぱいになっています。
df を確認すると、次のような結果が表示されます。
[root@packet /]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 74824932 64793724 6207284 92% /
devtmpfs 4069428 0 4069428 0% /dev
tmpfs 4081476 4 4081472 1% /dev/shm
tmpfs 4081476 123644 3957832 4% /run
tmpfs 4081476 0 4081476 0% /sys/fs/cgroup
tmpfs 816296 0 816296 0% /run/user/10003
tmpfs 816296 0 816296 0% /run/user/0
/dev/mapper/volume-1cb9df94p1 61795116 53704 58579352 1% /BACKUP
この3つのバックアップがどこに行ったのか知りたくて大容量フォルダを検索してみました。
[root@packet /]# du -a / | sort -n -r | head -n 5
26593808 /
17031172 /var
13973568 /var/www
13968748 /var/www/vhosts
8188140 /var/www/vhosts/xxxxxxx.com
したがって、/フォルダは26 GB(正確でなければならない)と非常に大きいように見えますが、dfでは64 GBを占めているように見え、3つのバックアップ(それぞれ約12 GB)が消えたようです...回避策この問題?
答え1
それでも/BACKUPフォルダにあるようです。ドライブをマウントすると、フォルダの内容がマウントポイントによって非表示になります。アンインストール後、ファイルだけunmount /BACKUP
でなく必要な隠しファイルも削除します。rm /BACKUP/*