Node.js在Linux系统中如何实现数据备份与恢复

Node.js 在 Linux 的数据备份与恢复实践

一 备份范围与策略

在动手之前，得先想清楚要保护什么。一个典型的 Node.js 应用，需要备份的对象通常包括这几块：

• 明确备份对象：首先是应用代码与核心配置，它们通常位于类似 /var/www/my_node_app 的目录下。别漏了依赖清单 package.json，它是重建环境的关键。数据库（如 MySQL、MongoDB）自然是重中之重。最后，那些运行时产生的数据，比如用户上传的文件（uploads/）、会话文件、缓存等，同样需要纳入保护范围。这里有个小建议：代码本身最好用 Git 管理，生产环境则更侧重于部署制品或镜像，备份的重心可以放在配置文件和动态数据上。
• 选择备份方式：
  • 对于文件系统，tar 命令适合做全量打包，而 rsync 则是实现增量同步或远程备份的利器。
  • 数据库则各有各的工具，比如 MySQL 的 mysqldump，MongoDB 的 mongodump。
• 制定周期与保留：策略需要平衡安全与成本。例如，采用“每日全量备份，保留最近7天”的策略，对于关键数据，强烈建议同步一份到远端或云端存储。
• 自动化与验证：手动备份靠不住。用 cron 定时任务来自动执行是标准做法。更关键的是，定期做恢复演练和数据校验（比如检查文件校验和、数据库条目数），否则备份可能只是一堆无法使用的“死数据”。以上这些思路，在 CentOS、Ubuntu、Debian 等主流 Linux 发行版上都是通用的。

二 数据库备份与恢复

数据库是应用的心脏，它的备份恢复必须可靠。这里我们分别看看 MySQL 和 MongoDB 的典型操作，并探讨如何用 Node.js 进行流程编排。

• MySQL 示例（使用系统工具，Node.js 负责编排）
  • 备份：
    • 命令：核心就是 mysqldump 命令：mysqldump -u [username] -p[password] [database_name] > /backup/db_$(date +%F).sql
    • Node.js 编排：我们可以用子进程来调用这个命令，实现更灵活的集成：

      const { exec } = require('child_process');
      const db = 'mydb', user = 'root', pass = '******', out = `/backup/db_${new Date().toISOString().slice(0,10)}.sql`;
      exec(`mysqldump -u ${user} -p${pass} ${db} > ${out}`, (err) => {
        if (err) console.error('备份失败:', err);
        else console.log('备份成功:', out);
      });

  • 恢复：
    • 命令：恢复操作使用 mysql 客户端：mysql -u [username] -p[password] [database_name] < /backup/db_YYYY-MM-DD.sql
    • 注意：恢复前，一个良好的习惯是先创建一个空数据库，或者确保目标库已清空，以避免因表结构或权限问题导致的冲突。
• MongoDB 示例（工具：mongodump/mongorestore）
  • 备份：mongodump --uri="mongodb://[user]:[pass]@[host:port]/[db]" --out /backup/mongo_$(date +%F)
  • 恢复：mongorestore --uri="mongodb://[user]:[pass]@[host:port]/[db]" /backup/mongo_YYYY-MM-DD/[db]
• 安全建议：直接在命令行里写密码是大忌。应该使用配置文件、环境变量或数据库支持的专用凭据文件来传递密码。同时，务必设置备份文件的权限为 600，确保只有所有者可读可写。

三 文件与日志的备份与恢复

除了数据库，应用文件和日志同样需要可靠的备份机制。

• 代码与静态资源（文件系统）
  • 全量打包：tar -czvf /backup/app_$(date +%F).tar.gz -C /var/www my_node_app
  • 增量/远程同步：rsync -a vz --delete /var/www/my_node_app/ user@remote:/backup/my_node_app/
  • 恢复：
    • 解压：tar -xzvf /backup/app_YYYY-MM-DD.tar.gz -C /restore
    • 同步回源：rsync -a v /backup/my_node_app/ /var/www/my_node_app/
• 日志备份与轮转
  • 系统工具 logrotate（推荐）：这是管理日志文件大小和历史的瑞士军刀。
    • 新建一个配置文件，例如 /etc/logrotate.d/nodejs：

      /var/log/nodejs/*.log {
          daily
          rotate 7
          compress
          missingok
          notifempty
          create 640 node node
          postrotate
              kill -USR1 $(cat /var/run/node.pid 2>/dev/null || pidof node) || true
          endscript
      }

    • 测试与生效：先用 logrotate -d /etc/logrotate.d/nodejs 进行调试，确认无误后使用 logrotate -f /etc/logrotate.d/nodejs 强制执行一次。
  • 远程归档：可以使用 rsync 将经过轮转压缩的旧日志目录，同步到专门的备份服务器进行长期归档。
  • 恢复：如果需要查阅历史日志，只需将归档的日志文件拷贝回 /var/log/nodejs/ 目录。如果应用正在运行，可能需要重启应用以重新打开日志文件句柄。

四 自动化与落地脚本

零散的备份命令难以维护，我们需要一个一体化的自动化方案。

• 全量+数据库的一体化备份脚本（示例）

  #!/usr/bin/env bash
  set -Eeuo pipefail
  
  APP=/var/www/my_node_app
  BACKUP=/backup
  DATE=$(date +%F)
  mkdir -p "$BACKUP"
  
  # 1) 代码与静态资源
  tar -czf "$BACKUP/app_$DATE.tar.gz" -C "$APP" .
  
  # 2) 数据库（MySQL）
  mysqldump -u root -p'******' mydb > "$BACKUP/db_$DATE.sql"
  
  # 3) 打包并清理旧备份（保留7天）
  tar -czf "$BACKUP/full_$DATE.tar.gz" -C "$BACKUP" app_$DATE.tar.gz db_$DATE.sql
  rm -f "$BACKUP"/{app_*,db_*}
  "$BACKUP"/full_*.tar.gz
  find "$BACKUP" -type f -mtime +7 -delete

• 定时执行（crontab）
  • 例如，设置每天凌晨2点执行：0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
• 恢复步骤
  • 解包：tar -xzvf /backup/full_YYYY-MM-DD.tar.gz -C /restore
  • 恢复代码：tar -xzvf /restore/app_YYYY-MM-DD.tar.gz -C /var/www/my_node_app
  • 恢复数据库：mysql -u root -p mydb < /restore/db_YYYY-MM-DD.sql
  • 重启应用：systemctl restart my_node_app 或 pm2 restart my_node_app。

五 误删与灾难恢复建议

当意外真的发生，比如文件被误删，冷静和正确的第一步操作至关重要。

• 立即保护与评估：首先，立即停止对涉及磁盘的任何写入操作，这是提高恢复成功率的关键。然后评估数据被新内容覆盖的风险，恢复的可能性与数据被覆盖的程度直接相关。
• 文件级恢复工具：
  • extundelete（适用于 ext3/ext4 文件系统）：在卸载分区后扫描并尝试恢复。
    • 示例步骤：umount /dev/sdb1
    • /usr/local/extundelete/bin/extundelete /dev/sdb1 --inode 2
    • 恢复出的文件默认会放在当前目录的 RECOVERED_FILES/ 文件夹里。
  • TestDisk：这款工具更侧重于分区表或分区结构的恢复，当整个分区丢失时它能派上大用场。
• 重要提示：所有恢复操作，都应尽可能在只读挂载的磁盘或事先创建的磁盘镜像副本上进行，避免对原始介质造成二次破坏。对于关键业务服务器，一个稳妥的做法是先对故障磁盘做完整的镜像备份，再在镜像上尝试各种恢复手段。