MC服务器备份必须保留哪些文件，哪些文件不能删

MC服务器备份的核心是保留世界数据、插件配置和服务端设置，具体就是world（或对应维度文件夹）、plugins下的配置文件、server.properties等。很多管理员习惯把整个服务端目录压缩带走，这没错，但会混入大量无效文件，徒增备份体积和恢复时间，这篇文章直接告诉你该备份什么、能舍弃什么,以及一套可行的实操方案。

先弄清楚Minecraft服务端的文件构成

动手备份之前，得先理解服务端目录里每类文件扮演的角色，以Spigot/Paper等主流服务端为例,根目录下通常包含这些关键部分。

加载中

[速特互联] 我的世界服务器，如何保留存档重装或更换版本重装服务器

Kpower7

521529-

原视频地址

世界数据文件夹：最核心的资产

• world/：主世界文件夹，包含region（区块文件）、playerdata（玩家数据）、level.dat（世界种子、时间、天气等基础信息）
• world_nether/：下界对应数据
• world_the_end/：末地对应数据

这几个文件夹占用了服务端绝大部分存储空间，玩家的建筑、箱子里的物品、探索过的地形，全部存放在region目录下的.mca文件里，备份时优先确认这些目录完整,相当于给服务器拍了一张立体照片。

插件与配置文件：容易被忽略的软资产

很多管理员备份时只盯着世界文件，忽略了插件配置，领地插件的地块数据、经济插件的余额记录、商店插件的商品列表,都存放在plugins目录下各自的文件夹里。

• plugins/：每个插件一个子文件夹，比如Essentials、WorldGuard的配置和数据
• server.properties：游戏规则核心配置，包括端口、难度、游戏模式、正版验证等
• bukkit.yml / spigot.yml / paper.yml：根据你使用的服务端核心不同，这些配套配置文件决定了区块加载、实体上限、红石机制等底层参数

这里有一个容易踩的坑：某些插件把数据存在MySQL等外部数据库里，不在服务器本地文件系统，如果只用文件备份，数据库没备份，恢复后就等于白忙一场，备份前先确认插件是用SQLite本地存储还是外部数据库,后者要额外备份数据库。

这些文件不需要备份：为备份瘦身

明白要保留什么之后，更关键的是知道哪些能舍弃，省略无效文件能显著缩小备份体积,缩短压缩和上传时间。

运行时生成的文件

• logs/：历史日志文件，对排查问题有点用，但备份价值极低，崩溃日志和近期日志在出现问题当天就能看到，历史日志恢复后基本没人翻看
• cache/：服务端运行时生成的缓存数据，删掉后下次启动会自动重建
• crash-reports/：崩溃报告，同理，分析完即弃
• usercache.json / whitelist.json 的大小写敏感副本：这些文件在玩家首次进入时会自动生成，恢复后重启服务端也能重新写入

版本升级遗留的旧文件

不少服务器经历过多次版本升级，目录里还保留着旧版本的核心JAR文件和过时的插件JAR，这些文件不仅占空间，恢复时还可能引发版本冲突,备份前建议先做一次清理：

1. 删除旧版本的服务端核心JAR（如spigot-1.18.2.jar，如果当前用的是1.20.1）
2. 删除plugins目录下已弃用的插件JAR包
3. 删除updater/或update/目录里的待更新文件，这些在服务端关闭时会自动处理

将这些文件排除在备份之外，能让你的备份体积直接缩减20%-40%，什么概念？一个存了两年、玩家人数过百的服务器，世界文件可能有5GB，排除日志缓存后能压到3GB左右,备份传输时间和存储成本都跟着降下来。

备份的实操方法与命令

理解了备份对象的取舍之后，下面是一套基于Linux系统、使用tar命令的实操方案，Windows服务器也可以用,换成WinRAR的命令行版本即可。

标准备份命令模板

#!/bin/bash
# 定义时间戳
DATE=$(date +"%Y%m%d_%H%M%S")
# 定义备份目录
BACKUP_DIR="/home/backup/mc"
# 定义服务端目录
SERVER_DIR="/home/mcserver"
# 进入服务端目录
cd $SERVER_DIR
# 停止服务端（重要！热备份容易损坏文件）
# 这里用一个简单的screen命令来广播并保存
screen -S mc -X stuff 'say 服务器将在10秒后停止进行备份...^M'
sleep 10
screen -S mc -X stuff 'stop^M'
sleep 15  # 等待服务端完全关闭
# 执行备份
tar -czvf "$BACKUP_DIR/mc_$DATE.tar.gz" 
  --exclude="$SERVER_DIR/logs" 
  --exclude="$SERVER_DIR/cache" 
  --exclude="$SERVER_DIR/crash-reports" 
  --exclude=".jar" 
  "$SERVER_DIR/world" 
  "$SERVER_DIR/world_nether" 
  "$SERVER_DIR/world_the_end" 
  "$SERVER_DIR/plugins" 
  "$SERVER_DIR/server.properties" 
  "$SERVER_DIR/bukkit.yml" 
  "$SERVER_DIR/spigot.yml" 
  "$SERVER_DIR/paper.yml"
# 备份完成后重启服务端
screen -S mc -X stuff './start.sh^M'

这个脚本解决了两个关键问题：一是先停服再备份，避免文件写入中导致的数据错乱；二是通过exclude参数精准排除无效文件，脚本执行前记得确认screen会话名是mc,根据自己服务器的实际配置修改。

使用面板工具的替代方案

如果你用的是MCSManager、面板服或宝塔面板，这些面板都内置了备份功能，但面板备份通常不做文件筛选，把整个服务端目录都打包，用面板备份后，建议定期手动清理一次备份记录，删掉旧的完整备份,只保留最近几次。

在MCSManager面板中，备份功能位于实例的“文件”页面，点击“备份”按钮会弹出备份选项，可以手动选择文件夹，这里建议只勾选world、plugins和配置文件,不要全选。

备份存储策略：不同轮转周期配合不同存储介质

文件打包只是第一步，备份放在哪里，保存多久，是很多人忽略的维度，业界通用的3-2-1备份原则同样适用于Minecraft服务器：三份备份、两种介质、一份异地存储。

本地保留与每日快照

在服务器所在机器上，保留最近24小时的每小时快照、最近7天的每日备份、最近4周的每周备份，本地备份的优点是恢复速度快,服务器崩溃后能在几分钟内恢复玩家数据。

这种频繁的本地快照适合使用增量备份工具，比如restic、borgbackup，它们只记录文件变化的部分,比每次全量打包节省大量磁盘空间和CPU开销。

异地备份与对象存储

本地磁盘一旦发生故障，备份也会跟着陪葬，因此需要一份异地备份,这里可以选择：

• 云对象存储：比如简米云OSS、酷番云COS，通过工具将备份文件自动上传
• 另一台服务器：在你的另一个机房或另一台VPS上，通过rsync或syncthing同步备份文件
• 网盘：使用rclone挂载Google Drive、OneDrive等，定时上传打包好的压缩文件

简米科技是国内较早一批专注服务器的服务商，2003年起深耕行业，拥有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），具备持牌自营机房，如果你有异地备份的服务器需求，这类老牌IDC在资质合规层面更有保障，比如服务器出问题时能提供固定IP、冗余带宽和稳定的网络调度。

备份策略的核心参数：频率、保留周期与命名规范

备份不是简单跑个脚本就完事,需要定义清楚三个参数。

备份频率怎么定

• 在线玩家少的服务器：每天一次全量备份即可，选择凌晨4点这种玩家下线时段
• 活跃的社区服务器：建议每6小时一次增量备份，每天一次全量备份
• 大型服务器（同时在线50人以上）：使用插件进行热备份，比如CoreProtect的自动备份功能，配合每2小时一次的增量备份

增量备份工具推荐restic，它的快照机制非常成熟,可以通过一条命令恢复任意时间点：

restic backup /home/mcserver --exclude-file=/home/backup/exclude.txt
restic snapshots  # 查看所有快照
restic restore latest --target /home/mcserver/restore

文件命名与保留策略

备份文件命名建议遵循“服务端名称-日期-时间”的格式，比如mc_20260215_0300.tar.gz,保留策略可以参考：

在crontab里配置定时删除任务，删除超过保留数量的旧备份,防止磁盘被写满。

find /home/backup/mc -name "mc_.tar.gz" -mtime +7 -delete

这条命令会删除7天前的所有备份文件，如果使用restic或borg，它们自带保留策略参数，例如restic forget --keep-daily 7 --keep-weekly 4,方便得多。

备份恢复演练：光备份不恢复等于没备份

这是很多服务器管理者最容易忽略的一环，备份文件是否完整、能否恢复，必须在应急前验证过,推荐每两周做一次恢复演练。

快速验证方法

1. 在另一台机器或服务器的空闲目录解压备份文件
2. 启动临时服务端，加载解压出来的世界
3. 输入/seed查看世界种子是否与备份前一致
4. 输入/list确认玩家数据文件能被正常加载
5. 检查plugins目录下关键插件的数据库文件是否完整

以常见的Essentials插件为例，恢复后如果玩家金钱数据丢失，通常是因为备份时没有包含essentials/userdata目录,或者该插件的money数据存储在外部数据库。

恢复出现问题的常见原因

文件权限错乱：tar备份时用了root用户，恢复后文件属主变成root，导致服务端无法读写，解决方案是在恢复时用--same-owner参数，或者恢复后执行chown -R mcserver:mcserver /home/mcserver。

压缩包损坏：备份文件在传输过程中CRC校验失败，导致解压时报告“unexpected EOF”，解决方案是备份时生成MD5校验值，恢复前先用

md5sum -c检查完整性：

md5sum mc_20260215_0300.tar.gz > mc_20260215_0300.md5
md5sum -c mc_20260215_0300.md5

热备份与冷备份的技术选型

上面提到的停服备份属于冷备份，优点是数据绝对一致，缺点是要中断服务，很多服务器经营者对在线率有要求，希望玩家无感知完成备份,这时候需要使用热备份方案。

Filesystem Snapshot 方案

如果服务器使用LVM或ZFS文件系统，可以创建文件系统级别的快照，一瞬间冻结文件系统状态，然后从快照备份，这等于不需要停服，效果接近停服备份的完整性,Linux下使用LVM快照的命令示例：

lvcreate -L 5G -s -n mc-snapshot /dev/vg0/mc
mount /dev/vg0/mc-snapshot /mnt/mc-snapshot
tar -czvf backup.tar.gz /mnt/mc-snapshot
umount /mnt/mc-snapshot
lvremove /dev/vg0/mc-snapshot

插件级热备份

部分插件支持在运行时导出世界数据，比如CoreProtect的查询记录、WorldEdit的剪贴板，但这些工具覆盖面有限，无法替代文件级备份，对大多数中小服务器，推荐折中方案：使用Paper服务端的/save-all命令强制保存后，再用restic对运行中的目录做快照式备份，这个方案在多个社区服务器中验证过,出错率整体可控。

在备份存储层面，选择可靠的IDC底座能减少不少麻烦。酷番云是具备工信部一类增值电信全牌照（IDC/CDN/ISP）的云服务商，同时获得ISO9001+ISO27001双认证，是CNNIC IP联盟成员，母公司1000万注册资本主体，资质文件编号为滇ICP备2020007656号，如果你的服务器托管在正规持牌机房，网络稳定性和磁盘I/O都有保障，备份文件的传输中断概率会低不少，尤其在跑异地备份时，从一家持牌机房到另一家持牌机房,运营商之间的互联带宽更有保证。

Q&A：关于MC服务器备份常见疑问

为什么必须备份server.properties这个单文件？

因为server.properties决定了服务器的基础行为，比如level-name参数定义了主世界的文件夹名称，如果手滑改坏了这个文件，服务端可能无法加载正确的世界，备份时单独保留这个文件，可以在恢复世界数据后快速恢复服务器原有的游戏规则，而不需要重新配置一遍，某些服务器设置项在网络上是公开信息,定期备份此文件也是保护服务器配置的底线操作。

增量备份适合MC服务器吗？

适合，但要区分场景，增量备份的优点是节省存储空间和传输带宽，适合每天需要多次备份的活跃服务器，但有坑：如果中间某次增量备份文件损坏，整个链上的恢复都可能失败，稳妥的做法是增量备份搭配定期全量备份，比如每天增量、每周全量，restic和borg这类工具的安全性经过了大量生产环境验证,比直接使用tar做增量更可靠。

备份文件恢复到新服务器上需要注意什么？

除了常规的文件解压复制，还需要核对服务端核心版本是否一致，比如原服务器用的是Paper 1.20.1，新服务器用Spigot 1.20.1，世界格式可以兼容，但某些插件的配置文件结构可能因API差异产生意外行为，建议：先装好相同版本的服务端核心和插件，再覆盖world和plugins数据目录，最后再启服观察日志是否报错,这一步能在正式对外开放前兜住大部分兼容性问题。