我遇到了一个问题,我的服务器本周已经满了。
➜ ~ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 20G 19G 0 100% /
devtmpfs 7.9G 0 7.9G 0% /dev
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 7.9G 102M 7.8G 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/sda3 1.8T 94G 1.6T 6% /home
现在大部分已经无法使用了。
不幸的是,我的托管提供商不想为我缩减/dev/sda3
和扩展/dev/root/
,而且我是服务器管理的新手,我知道我会通过试验把事情搞砸。或者,我还想知道是什么填满了根文件系统(我不能简单地在 中搜索/
)并看看如何停止它。
我该如何一步一步地完成而不丢失数据?如果需要,我可以进入救援模式。我的托管商是 Kimsufi。
谢谢!
答案1
关于评论中的讨论,听起来你正在运行一个依赖于 中的大型(或至少是相当大的)数据库的服务器/var
。在这样的计算机上,重要的是要么将其/var
(或其子目录)拆分成足够大的分区来容纳数据库,要么确保根目录(/
)足够大。事实上,许多服务器使用单独/var
分区比使用单独/home
分区做得更好——尽管你的df
输出显示 上有 94GB /home
,所以这似乎不是你的情况。尽管如此,如果你正在运行 MySQL 服务器,20 GB 的根目录(/
)并且没有单独的/var
分区听起来不够,所以你的问题是可以理解的。你可能需要咨询 MySQL 专家,以获取有关数据库可能会消耗多少磁盘空间的建议。
无论如何,可以对某些文件系统进行“实时”调整大小;但是增加尺寸比减少文件系统的大小,看起来你需要执行每个操作中的一个。如果你可以以身份登录root
,你应该能够/home
从常规启动中卸载并缩小它。请注意,这是 Ubuntu 的非标准配置,因此你需要启用直接root
登录——并且你可能希望在之后禁用它们。(参见这个问题及其答案更多信息。)根据分区的布局,可能还存在其他复杂情况。请参阅这个问题及其答案有关在登录时调整大小的一些信息。如果您的/home
分区位于根 ( /
) 分区之后,您可能需要考虑缩小/home
,创建一个新的分区,将 的内容/var
(或/var
占用大量磁盘空间的 子目录)移动到新分区,然后将其挂载在/var
(或其子目录,视情况而定)。因为有如此多的程序在 上运行/var
,以这种方式移动所有/var
可能需要从应急磁盘进行操作,但您可以从 子目录的主安装中执行此操作/var
。
话虽如此,我同意之前的评论,对于一个新手来说,这可能不是最好的尝试。如果你必须这样做,我强烈建议你设置一台尽可能与你当前配置相匹配的计算机(或虚拟机),以便你可以练习。最好是消灭一台(或两台或三台)虚拟机,而不是消灭你的真实服务器!
另一种历史悠久但有点丑陋的方法是将一个或多个目录重新定位到现存的分区,并依赖符号链接而不是挂载新分区。您可以执行以下操作:
/
在根 ( ) 分区上找到占用大量空间的目录。对于 MySQL,我期望它是/var/lib/mysql
。- 在分区上创建目标目录
/home
— — 例如,/home/var/lib/mysql
。将其所有权和权限与原始/var/lib/mysql
目录匹配。 - 关闭所有正在使用的软件
/var/lib/mysql
。我认为应该sudo service mysql stop
这样做,但我不是 100% 确定。 - 输入
sudo mv /var/lib/mysql/* /home/var/lib/mysql/
。这会将文件从 移动/var/lib/mysql
到/home
分区。 - 键入
sudo rmdir /var/lib/mysql
以删除该目录。(如果无法删除,则可能是某些文件未移动。也许它们是点文件。您必须修复此问题。) - 输入
sudo ln -s /home/var/lib/mysql /var/lib/mysql
。这将创建一个符号链接,以便使用的程序/var/lib/mysql
仍然能够访问新位置的文件。 - 重新启动 MySQL。
sudo service mysql start
应该可以这样做。
警告:我对 MySQL 不够熟悉,因此无法 100% 确信此过程可正常工作。使用符号链接可能会使其不合适。此外,我在输入此过程时尚未对其进行测试,因此我可能在一条(或多条)命令中犯了错误。
由于我不是 MySQL 专家,因此可能存在一些专门针对 MySQL 的更好的方法来执行此操作(假设这确实是导致问题的程序。)