我的服务器应用备份及恢复演练

近期因为服务器的硬盘健康度只剩下5%问题，咨询了论坛里的各位老哥，其实应该没啥关系的。但是由于是当作主力机使用，还是找服务商申请更换了一块硬盘。然后由于自己疏忽，没有提前对备份过的文件做模拟恢复演练，导致硬盘更换以后，进行恢复时出现了一系列故障，好在最后也都解决了。但隔了两周时间，我好像又忘记当时恢复过程时遇到的一些问题以及如何解决，现在打算在另外一台VPS上进行模拟恢复，如果能够遇到相同的问题那最好，我可以尝试解决并记录下来。

首先是备份，勤备份是一个非常好的习惯，只有丢过数据的人才能懂得。数据备份后一定要多方保存，比如本地，移动硬盘，nas，网盘等，养成不要把鸡蛋放在一个篮子里的好习惯。我这边的服务目前跑的程序基本是通过docker进行部署的，部分通过一款名为1panel的面板工具，但是其本质还是docker应用，它自带了备份和恢复，我就按照其使用方法进行管理。

一、备份

1panel应用程序备份

屏幕截图 2025-06-03 104053

通过面板，点击备份即可启动脚本执行备份命令，然后下载即可，如果需要还原到某个版本只要在操作这边点击恢复。当然这些操作都需要谨慎执行，操作前养成先点击备份，再执行操作的好习惯。

docker应用备份

其实现在已经有docker的管理面板工具，但是因为自己写脚本或者执行命令也挺方面的，主要是懒。写了脚本就让它每周进行备份即可。

以wallos的应用为例子，一个是备份镜像（其实不需要每次都进行备份），另一个是进行数据备份，参考脚本如下：

#!/bin/bash

# === 配置 ===
BACKUP_DIR="/home/test/docker-app/backup"
DATE=$(date +%F)
IMAGE_NAME="bellamy/wallos:latest"

# 创建备份目录
mkdir -p "$BACKUP_DIR"

# === 1. 备份挂载目录 ===
tar -czf "$BACKUP_DIR/wallos_data_$DATE.tar.gz" /home/test/docker-app/wallos/db /home/test/docker-app/wallos/logos

# === 2. 备份镜像 ===
docker save -o "$BACKUP_DIR/wallos_image_$DATE.tar" $IMAGE_NAME

当然这个例子举的不是很恰当，其实docker-compose文件和数据文件夹都在同一目录下，只要把这个文件夹压缩迁移过去，然后再执行启动命令即可，这里是为了练习学写脚本，强行走”错路”。

数据存储

备份后的数据，如果不能够进行较好的保存的话，其实相当于没有备份。其实最好的备份策略是参照同城异地三中心策略，我目前采用的是电脑一份，移动硬盘一份，NAS一份，onedrive一份，mega网盘一份，115一份。如果这样子还丢的话，那我也认了吧，其实也不是什么特别重要的数据

二、演练恢复

找了手头空闲的一台3C4G50G的VPS作为本次恢复模拟演练的测试机器，系统是debian12版本，先按照1panel官方的安装教程安装了1panel（会同时帮忙安装好docker）

#debian的安装方法，其他的系统参照官方文档
curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && bash quick_start.sh

1panel应用恢复

之前是这个wordpress的恢复出现了问题，现在再来尝试一下，分别先安装好mysql和wordpress应用，可以先不管版本，然后直接进行数据覆盖，先恢复mysql再恢复wordpress。

安装好的服务如下：

屏幕截图 2025-06-03 113553

接下来每个应用右边导入备份按钮上传备份文件，上传完成后点击恢复，可以看到应用正常恢复，磁盘也不断在读写，耐心等待跑完即可。然后再进行wordpress的恢复，相同的操作方法。

恢复完成后，应该可以看见系统版本和运行时间就变成了原先备份时间点的状态。不过很可惜这个wordpress恢复失败了，遇到了上次类似的问题。

屏幕截图 2025-06-03 113959

当时我是如何解决的…有点忘记了。只能再次想想办法。

再尝试一下，先恢复wordpress然后再恢复mysql试试，先都进行删除,发现还是不行，因为应用依赖于数据库，所以必须是恢复mysql先。然后

恢复wordpress时还是提示如下错误

屏幕截图 2025-06-03 145234

意思是找不到记录，是否意味着数据库没有连接上，我本地试一下是否能够正常远程访问数据库。

我通过dbeaver和phpmyadmin都是能够正常连接上数据库，并查询出之前产生的数据记录，这说明这个数据库是恢复正常了的，那问题还是出在wordpress上。

屏幕截图 2025-06-03 150050

后面尝试在一开始配置参数的时候就按照原先的数据库设置写入到配置中后，然后再进行恢复发现能够恢复正常，但是wordpress会报错，这时候点击重启即可。

屏幕截图 2025-06-03 150633

屏幕截图 2025-06-03 150651

environment:
            WORDPRESS_DB_HOST: ${PANEL_DB_HOST}:${PANEL_DB_PORT}
            WORDPRESS_DB_NAME: ${PANEL_DB_NAME}
            WORDPRESS_DB_PASSWORD: ${PANEL_DB_USER_PASSWORD}
            WORDPRESS_DB_USER: ${PANEL_DB_USER}
            WORDPRESS_DEBUG: 0

看它的compose文件中是直接从面板里的参数进行读取的，所以一开始没有配置好的话，哪怕后面进行数据恢复，这个数据库这块还是无法连上的..基于docker，但是感觉不像真正的docker那么好用，不过好在问题都解决了，以后再出现这种问题，我已经会很快解决的。

docker应用恢复演练

docker应用恢复其实是比较简单的，哪怕是通过命令行一样，差不多思路就是恢复docker容器，然后恢复应用数据。

这里演示的wallos，因为其文件格式以及数据都是相对规范的，其实把整个文件夹压缩一下，然后移过去就行了。

version: '3.0'

services:
  wallos:
    container_name: wallos
    image: bellamy/wallos:latest
    ports:
      - "18180:80"
    environment:
      TZ: 'Asia/Shanghai'
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    restart: unless-stopped

备份：

tar -czf wallos_backup.tar.gz ~/docker-app/wallos

tar: Removing leading `/' from member names

这是错误，而是一个正常提示，说明 tar 在打包文件时自动去掉了路径前导的 /，以避免还原时将文件强制解压到根目录。它的目的是防止安全问题和意外覆盖系统文件。

传输：

scp -P SSH-PORT wallos_backup.tar.gz  root@IP:/root

解压及恢复：

tar -xzf wallos_backup.tar.gz -C ~/
cd到wallos的目录
docker-compose up -d

浏览器打开ip:18180出现下面这个页面表示恢复成功了。

屏幕截图 2025-06-03 154512

总结

总体上来说，通过这些即时的备份，后续哪怕数据真发生了不可恢复性的丢失，我最多也只是损失一部分内容，总体上来说是可以接受的，这应该是每个服务器管理员都需要考虑的高性价比事情。后续我会通过脚本直接scp或者rclone定期将备份的文件同步到网盘以及其他服务器，果然还得是脚本。不过这样子就少了很多折腾的乐趣，重复的执行命令虽然枯燥，但是这是你跟服务器直接对话，增加了解的好机会，同时加强命令“语感”，提升操作能力。我会在做好备份策略的同时，不定期去手动备份，最后希望大家的服务器都能好好的，稳定的给我们提供服务。