Linux下Node.js日志备份方法是什么

线上 Node.js 服务跑着跑着，突然磁盘满了——但凡跑过线上的人，多少都遇到过这种场景。事后复盘，多半是日志文件没有做轮转和清理。日志备份这件事，平时不显眼，关键时刻却能救命。

要搭建一套靠谱的日志备份体系，核心就三件事：确定日志在哪儿、选对轮转策略、做好远程备份。下面一步步拆开来说。

核心思路与准备

在做日志备份之前，有几个基础工作得先落实。

首先得知道日志文件到底在哪儿。常见的位置包括：应用自定义的 ./logs/ 目录、系统级的 /var/log/、PM2 管理的 ~/.pm2/logs/，以及 systemd 服务日志。路径定位不准，后续所有操作都是白搭。

其次是策略选择。系统自带的 logrotate 可以解决日志轮转和本地归档，这是最轻量的方案；如果需要远程备份，再加上 tar/rsync 做周期性打包同步；如果日志量特别大，那就得考虑集中式日志方案，比如 ELK 或 Fluentd。

最后是权限和安全。备份目录权限建议设为 700，日志文件和备份文件都要遵循最小权限原则。涉及敏感信息的日志，打包后用 GPG 加密一下，更稳妥。

方法一：使用 logrotate 做日志轮转与本地归档

logrotate 是 Linux 系统自带的日志轮转工具，对于 Node.js 直接写文件日志的场景来说，是最省心的方案。它能控制单文件大小和保留天数，轮转后还能让应用继续写入新文件，不中断服务。

配置起来也不复杂，创建一个 /etc/logrotate.d/nodejs 文件，写入以下内容：

/var/log/nodejs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 node node
    sharedscripts
    postrotate
        # 根据进程管理方式选择其一
        systemctl reload my-nodejs.service >/dev/null 2>&1 || true
        # 或 kill -USR1 $(cat /var/run/nodejs.pid) 2>/dev/null || true
    endscript
}

这里有几个关键参数需要说明一下：daily 表示按天轮转，rotate 7 保留最近 7 天的日志，compress 对旧日志进行压缩。postrotate 脚本段的作用是通知应用重新打开日志文件，具体方式取决于进程管理方式——systemd 服务用 systemctl reload，直接管理进程用 kill -USR1，如果使用 PM2，则安装 pm2-logrotate 插件统一处理轮转策略。

配置写完后，先用 sudo logrotate -d /etc/logrotate.d/nodejs 校验语法，确认无误再用 sudo logrotate -f /etc/logrotate.d/nodejs 强制执行一次，看看效果。

方法二：使用 Shell 脚本配合 tar/rsync 做周期性备份

如果 logrotate 不能满足需求，比如需要将日志备份到远程服务器，或者想自定义归档策略，写一个 Shell 脚本是最灵活的方式。

本地打包脚本可以这样写：

#!/bin/bash
set -e

LOG_DIR="/var/log/nodejs"
BACKUP_DIR="/backup/nodejs"
DATE=$(date +%Y%m%d)

mkdir -p "$BACKUP_DIR/$DATE"
tar -czf "$BACKUP_DIR/$DATE/app-$DATE.tar.gz" -C "$LOG_DIR" .

# 可选：加密
# gpg --symmetric --cipher-algo AES256 "$BACKUP_DIR/$DATE/app-$DATE.tar.gz"

# 清理30天前备份
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +30 -delete

如果需要远程同步，rsync 是增量备份的好帮手：

#!/bin/bash
BACKUP_DIR="/backup/nodejs"
REMOTE_USER="backup"
REMOTE_IP="192.168.1.100"
REMOTE_DIR="/remote/backup/nodejs"

rsync -a vz --delete "$BACKUP_DIR/" "$REMOTE_USER@$REMOTE_IP:$REMOTE_DIR"

脚本写好之后，通过 crontab 设置定时任务：

# 每天 02:00 本地打包
0 2 * * * /usr/local/bin/backup_logs.sh

# 每天 03:00 远程同步
0 3 * * * /usr/local/bin/backup_logs_remote.sh

首次执行记得先手动跑一遍脚本，确认目录、权限和网络连通性都没问题，再交给定时任务。

方法三：应用内轮转与集中式日志

如果不想依赖系统工具，或者想让日志切分更细粒度，可以在应用内部实现轮转。Winston 配合 winston-daily-rotate-file 插件，按天或按大小切分日志，配置非常直观：

const winston = require('winston');
const { DailyRotateFile } = require('winston-daily-rotate-file');

const logger = winston.createLogger({
  transports: [
    new DailyRotateFile({
      filename: '/var/log/nodejs/app-%DATE%.log',
      datePattern: 'YYYY-MM-DD',
      zippedArchive: true,
      maxSize: '20m',
      maxFiles: '14d'
    })
  ]
});

Pino 也有类似的插件，实现方式大同小异。

如果日志量已经大到本地存储都吃力了，那就得考虑集中式日志方案——把日志发送到 ELK Stack（Elasticsearch+Logstash+Kibana）或 Fluentd，既减轻本地存储压力，又方便检索和可视化。

恢复与校验及注意事项

恢复步骤其实很简单：本地归档的话，用 tar -xzvf /backup/nodejs/app-2025-09-30.tar.gz -C /var/log/nodejs 解压到对应目录就行；远程备份的话，先用 rsync -a vz user@ip:/remote/backup/nodejs/ /backup/nodejs/ 回灌到本地，再解压使用。

校验和监控是比较容易被忽略的环节。建议定期解压抽查，验证备份文件的完整性和文件大小。同时用 Monit 之类的工具监控日志体积，一旦异常增长能及时告警，脚本层面也可以检查备份是否生成并发送通知。

安全方面，备份目录权限设为 700，敏感日志打包后 GPG 加密。保留周期按合规要求来，本地一般 7-14 天，远程可以 30 天或更长。

最后注意一下进程管理方式的差异——直接运行的服务用 systemctl reload 或 kill -USR1 通知重新打开日志；PM2 管理的服务，安装 pm2-logrotate 插件统一处理轮转策略，省心不少。