服务器根目录下的data目录，是存放业务核心数据的专用仓库，能否删除取决于它承载的数据类型，多数情况下删除等于销毁业务数据。很多站长初次接触服务器时都会困惑：根目录下这个data文件夹到底是干什么用的？它占了好几个G的空间，能不能直接删掉腾地方？本文就把data目录的真实身份讲透。
服务器data目录到底是什么文件夹
业内专家指出，data目录并不是Linux系统的原生标准目录（原生标准是/var、/etc、/usr）,它通常由以下几种途径产生：
- 网站程序自动创建：例如Nginx的缓存目录、MySQL的数据库存放路径、Docker的默认数据卷根目录，都可能叫data
- 管理员手动创建：为了方便区分系统盘和数据盘，运维人员习惯把数据盘挂载点命名为
/data - 面板默认生成：宝塔面板、WDCP等面板在安装时会生成
/www目录，但部分云镜像会额外创建一个空的/data用于挂载数据盘 - 应用安装残留：某些Java应用、Tomcat中间件默认会在根目录下建data目录存放日志和临时文件
判断data目录的身份有个快速方法：执行ls -lah /data看它的属主和内容结构，如果里面有mysql、docker、backup这类子目录，基本就是业务数据目录；如果只有一两个空文件夹或者lost+found,那多半是刚挂载的数据盘入口。
data目录和www目录的区别
很多服务器上同时存在/data和/www,不少人分不清两者的分工：
| 目录 | 典型用途 | 可否替换 |
|---|---|---|
| /www | 网站源代码、站点配置文件 | 通常由宝塔等面板固定使用 |
| /data | 数据库文件、备份包、对象存储 | 路径可自定义，按业务需求挂载 |
行业共识认为，www目录偏向代码层，data目录偏向数据层，如果你的站点崩溃需要重建，www里的代码还能从Git仓库拉取，但data里的数据库文件一旦丢失,整个业务的用户数据就归零了。
服务器data目录可以删除吗
这是站长问得最多的问题，回答之前必须搞清楚data里面装的是什么，先确认内容再动手,这是铁律。
承载关键服务的data目录
以下情况绝对不可直接删除,否则服务崩溃甚至数据永久丢失：
- MySQL/MariaDB的数据目录：默认路径通常在
/var/lib/mysql，但不少运维会把MySQL的datadir指向/data/mysql，删除后所有数据库表结构、用户记录全部消失，且几乎无法恢复 - Docker的数据卷目录：路径一般在
/var/lib/docker/volumes或自定义的/data/docker，如果你用Docker跑过MySQL、Redis、ES等容器，删除data目录相当于把容器内的所有数据格式化 - 备份文件的存放目录：很多人习惯把网站压缩包、数据库dump文件放在
/data/backup，删除后等于主动放弃了数据回滚的安全网
可以安全清理的data目录
如果data目录符合以下特征,清理通常不会伤筋动骨：
- 程序临时缓存目录：例如部分Java应用会在
/data/temp存放临时文件，定期清空不会影响运行 - 下载缓存：某些镜像源或更新服务会把安装包缓存到
/data/cache，删除后下次更新会自动重新下载 - 已经明确迁移走的空目录：比如从
/data迁移到了/data2，原目录只剩下空壳，这时可以留着也可以删
判断是否可删除的实操步骤
不确定data目录能不能动的时候,按照以下流程检查：
- 执行
du -sh /data/，列出data下各子目录的占用空间 - 执行
lsof +D /data，查看是否有进程正在使用该目录中的文件 - 执行
cat /etc/mysql/mysql.conf.d/mysqld.cnf（不同系统路径略有差异），检查MySQL的datadir是否指向/data - 执行
docker info | grep "Docker Root Dir"，查看Docker的数据根目录 - 如果以上都没发现关联，再用
find /data -type f | head -20看看里面到底是什么类型的文件
服务器data目录占用空间太大怎么处理
空间告急是最常见的运维场景，data目录往往是罪魁祸首，与其着急删除,不如先做体检再决定处理方式。
定位空间消耗的源头
用一条命令就能看清data里谁在吃空间：
du -h --max-depth=2 /data 2>/dev/null | sort -hr | head -20
执行后会按占用大小列出data目录下的所有子目录,接下来针对大头逐项排查：
- 数据库binlog日志：MySQL的binlog会无限累积，如果data/mysql下binlog文件特别多，可以修改配置限制保留天数
- 容器日志文件：Docker容器默认会以JSON格式记录全部标准输出，日积月累轻松占满几十GB
- 旧备份文件：很多自动备份脚本只做备份不清理旧档，备份目录里躺着半年的压缩包也不稀奇
- 核心转储文件：进程崩溃时生成的core文件可能单个体积就有几个GB，散落在data目录下
安全释放空间的具体方案
找到占用大户后,按照顺序操作：
- 设置MySQL binlog自动清理，在my.cnf中加入
expire_logs_days = 7（MySQL 8.0使用binlog_expire_logs_seconds） - 为Docker容器配置日志轮转，在/etc/docker/daemon.json中设置
log-opts的max-size为100m，重启Docker生效 - 调整备份策略，保留最近3份完整备份即可，旧的可以转移到对象存储或直接删除
- 若data目录中确实有已废弃的项目残留文件，确认无引用后手动清理
服务器data目录迁移到数据盘的方法
很多云服务器默认系统盘只有40GB，根目录下的data很容易占满系统盘，导致网站无法写入新数据,正确做法是把data目录迁移到大容量数据盘。
迁移前需要做哪些准备
迁移本身并不复杂,但有两个要点不能忽略：
- 停机或维护模式：迁移过程中数据库文件不能有写入操作，否则数据会不一致
- 目标路径必须有足够空间：检查新数据盘是否已挂载，且剩余容量要大于data目录的当前总大小
完整迁移步骤
以将/data从系统盘迁移到新数据盘/dev/vdb1为例：
- 挂载新数据盘：
mount /dev/vdb1 /mnt - 同步数据（保留权限属性）：
rsync -avxP /data/ /mnt/ - 重命名原目录做备份：
mv /data /data_old - 把新盘挂载到原路径：
umount /mnt && mount /dev/vdb1 /data - 在/etc/fstab中添加开机自动挂载，防止重启后失效
- 确认所有服务正常后，再删除
/data_old
迁移后必须检查的权限问题
迁移后如果网站或数据库无法启动，大概率是权限问题，执行chown -R mysql:mysql /data/mysql这类操作时，要注意属主名和之前保持一致，同时检查目录权限是否为755，数据库目录通常为700或750，不要粗暴地统一改成777。
关于data目录的常见疑问与解答
服务器data目录可以删除吗？删了网站会不会出问题？
能否删除取决于该目录是什么程序的存储路径，如果data目录被MySQL、Docker或其他数据库程序占用，删除后服务直接崩溃，数据无法恢复，绝大多数情况下，data目录是业务核心数据存放地,建议保留并做好定期备份。
根目录data文件夹越来越大正常吗？
属于常见现象，日志、binlog、备份文件、缓存都会持续累积，建议每月执行一次du -sh /data/排查大文件，对日志类文件配置轮转机制，对备份类文件设置保留策略，长期不清理,data目录占满磁盘会导致数据库宕机。
如何备份服务器data目录？
数据库类的data目录建议使用官方工具导出备份，例如MySQL用mysqldump，纯文件类的data目录可以直接用rsync增量同步到另一台机器或对象存储，备份周期根据数据更新频率来定,核心业务至少保证每日一次全量备份。