把服务器日志远程备份到 FTP/SFTP，依然是目前性价比最高的方案之一，配置得当且校验完备，基本不会丢日志；多数团队的备份失败，都和权限、被动模式、磁盘配额这三件事有关，和协议本身关系不大。
日志是服务器的黑匣子,出了问题第一反应就是翻日志，可日志文件有个特点：平时不起眼，出事时发现磁盘满了、文件被覆盖了、或者压根没开日志，远程备份日志到 FTP/SFTP 服务器，解决的不只是磁盘空间问题，更是给黑匣子上了保险。
日志备份为什么绕不开 FTP/SFTP
市面上的备份方式很多：对象存储、云盘、NAS、数据库同步，但放到”服务器日志”这个具体场景里，FTP/SFTP 的优势非常直接。
- 成本低：FTP/SFTP 服务端几乎不需要额外投入，一台轻量服务器就能扛住，折合下来租用价格每月也就一杯咖啡钱，相比对象存储按流量计费，日志天天传、积少成多，流量费累积起来反而肉疼。
- 通用性强：不管服务器在华北、华东还是海外节点，只要 21 端口或 22 端口通着，脚本一写就能跑，不依赖任何云厂商的专有 API。
- 脚本友好：命令行工具 lftp、curl、sftp 都是老牌工具，配合 crontab 或任务计划程序，几行就能搞定自动化。
业内专家指出,相当一部分企业的数据泄露并非加密不够，而是备份账号权限过大，FTP/SFTP 方案天然支持最小权限配置，反而比某些”全家桶”备份软件更可控。
ftp sftp 区别：日志备份该选谁
很多人在选型时卡在 ftp sftp 区别上，两者名字像，本质差别很大。
| 对比项 | FTP | SFTP |
|---|---|---|
| 加密方式 | 明文传输（FTPS 可加 TLS） | SSH 加密通道，天然安全 |
| 默认端口 | 21 | 22 |
| 服务端依赖 | 需单独装 FTP 服务（vsftpd 等） | 系统自带 sshd 即可 |
| 防火墙配置 | 需要开放数据端口，被动模式要配端口段 | 只开放 22，简单直接 |
| 传输效率 | 略高，适合大文件批量传递 | 有加解密开销，日志文件小几乎无感 |
给个结论：只要服务器开了 SSH，优先用 SFTP，少装一个服务就少一个攻击面，防火墙规则也更省心，FTP 更适合内网环境、或者需要和已有 FTP 服务对接的场景。
日志文件和普通文件备份的差异
日志备份不能像备份源代码那样”整个目录拷走就完事”，日志有两个特性：
- 高频追加：应用一直在写，备份时容易读到半截内容，tar 打包时可能报 file changed as we read it。
- 滚动轮转：logrotate 按天或按大小切分文件，旧日志后缀是 .1、.2，新日志不带后缀，备份脚本要搞清楚哪个是当前活跃文件，哪些是已经轮转的归档。
日志备份脚本设计上要加一条：先触发 logrotate，再备份轮转后的文件，这样既不会和写入中的文件抢 IO，备份出来的数据也是完整的。
Linux 定时备份文件到 FTP 服务器：完整配置
Linux 场景是日志备份的主战场，这套配置在大多数发行版上都能直接用，不需要装额外的付费软件，也顺便回答了不少朋友纠结的”ftp 备份软件哪个好”图形界面的 FileZilla、WinSCP 确实好用，但定时场景下，命令行工具的稳定性和可维护性远超鼠标点来点去。
第一步：写好备份脚本
先建目录和脚本文件：
mkdir -p /opt/backup-scripts vim /opt/backup-scripts/log_backup.sh
脚本里做三件事：打包含日志、清理本地旧文件、上传到远端。
#!/bin/bash # 日志备份脚本，兼容 bash 和 sh BACKUP_DIR="/var/log/backups" TODAY=$(date +%F) LOG_SRC="/var/log/nginx" # 按实际日志路径修改 mkdir -p "$BACKUP_DIR" # 打包，排除正在写入的 .log 文件，优先取轮转后的归档 tar czf "$BACKUP_DIR/logs_$TODAY.tar.gz" $LOG_SRC/.log. 2>/dev/null # 本地只保留最近 7 份 find "$BACKUP_DIR" -name ".tar.gz" -mtime +7 -delete
注意 .log. 这种匹配模式，目的是避开正在活跃写入的 access.log 本身，只打包前一天轮转出来的历史文件。
第二步：上传到远端 FTP/SFTP
以 SFTP 为例，用密钥登录比密码更安全，也方便定时任务无人值守。
# 生成密钥对（如果还没有） ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" # 把公钥追加到远端服务器的 authorized_keys ssh-copy-id backup_user@remote_server
脚本里追加上传部分：
# 上传到远端 /backup 目录 sftp -i /root/.ssh/id_ed25519 backup_user@remote_server <<EOF put /var/log/backups/logs_$TODAY.tar.gz /backup/logs_$TODAY.tar.gz bye EOF # 校验退出码 if [ $? -eq 0 ]; then echo "$(date '+%F %T') upload ok" >> /var/log/backups/upload.log else echo "$(date '+%F %T') upload failed" >> /var/log/backups/upload.log fi
如果远端是纯 FTP 服务、不支持 SFTP，就用 lftp 替代：
lftp -u username,password -e "put /var/log/backups/logs_$TODAY.tar.gz -o /backup/logs_$TODAY.tar.gz; bye" ftp://remote_server
密码写在命令行里有风险,可以写到 ~/.netrc 并设置 600 权限，或者用环境变量引用。
第三步：配置 crontab
crontab -e
加一行,每天凌晨 2 点执行：
0 2 /opt/backup-scripts/log_backup.sh >> /var/log/backups/cron.log 2>&1
凌晨 2 点通常是业务低峰期，备份对磁盘 IO 的影响最小，如果怕任务重入，用 flock 加个锁：
0 2 flock -xn /tmp/log_backup.lock -c "/opt/backup-scripts/log_backup.sh"
Windows 服务器日志备份方案：任务计划程序
Windows 服务器同样有日志备份需求，系统事件日志、IIS 日志、应用日志，都适合走 FTP/SFTP 远程备份，Windows 自带的任务计划程序配合 WinSCP 命令行，能实现和 Linux 相同的效果。
操作路径：
- 下载 WinSCP 便携版，解压到
C:toolswinscp。 - 编写批处理脚本
backup_logs.bat：
@echo off set today=%date:~0,4%%date:~5,2%%date:~8,2% "C:toolswinscpwinscp.com" /command "open sftp://backup_user@remote_server/ -hostkey=""ssh-ed25519 密钥指纹""" "put C:logsapp_%today%.log /backup/" "exit"
- 用
wevtutil导出系统事件日志：
wevtutil epl System C:logssystem_%today%.evtx
打开任务计划程序,创建基本任务：触发器选”每天”，时间设 02:00，操作选”启动程序”，指向这个 bat 文件，任务计划程序会在后台静默运行，不弹窗不打扰。
这套 Windows 服务器日志备份方案还有一个额外好处：任务计划程序自带”错过任务后尽快运行”选项，就算服务器当时休眠或关机，开机后也会补跑。
ftp 备份失败原因排查
配置好只是开始,真正折磨人的是它某一天突然不跑了，ftp 备份失败原因无非那几类，按概率排序，挨个排查。
登录被拒（530/权限错误）
先手动执行一次上传命令,看报错信息。
530 Login incorrect：账号密码错误，或者账号被限制只能从特定 IP 登录。Permission denied (publickey,password)：SFTP 密钥不匹配，公钥没正确追加到远端。
数据连接失败（425/426）
FTP 的数据连接和主连接是分开的，防火墙没放行数据端口是最常见原因，vsftpd 开启被动模式时，需要把
pasv_min_port 到 pasv_max_port 这段端口在防火墙里放行，SFTP 不存在这个问题这也是推荐 SFTP 的另一个理由。
远端写入失败（550/磁盘满）
- 目录不存在或拼写错误,FTP 回到家目录后相对路径不同。
- 远端磁盘满了,
df -h看一下。
上传中断、文件不完整
网络抖动导致中断,lftp 有内置重试机制：
lftp -e "set net:max-retries 5; set net:timeout 30; put ...; bye"
校验是最后一道防线
脚本里加上 md5 比对，确保远端文件和本地一致，上传完成后立刻下载回来做哈希比对，脚本才有闭环：
md5sum /var/log/backups/logs_$TODAY.tar.gz # 远端执行 md5sum 对比，不一致则触发告警
告警通道可以接邮件,或者发到聊天群机器人，告警信息写清楚时间、文件名、失败原因，别让排查的人猜。
备份策略与安全加固
远端保留策略
只传不删是大忌,日志会无限堆积填满远端磁盘，常见做法是远端按天存，保留最近 30 份，在远端服务器上配个 crontab 每天清理：
find /backup -name "logs_.tar.gz" -mtime +30 -delete
本地保留 7 天、远端保留 30 天、重要日志再做一份冷备行业共识是至少保留两个不同位置的副本。
最小权限和账号隔离
备份账号只给写权限,不给删权限远端保留策略的清理任务单独用一个管理账号跑，备份账号本身做不了破坏操作，SFTP 场景下，在 sshd_config 里给备份用户加上 ForceCommand internal-sftp 和 ChrootDirectory，把它限制在固定目录里，即使被攻破也拿不到系统 shell。
Q&A：服务器 FTP 备份常见问题
问题 1：用 FTP 备份日志，会不会把带宽占满影响业务？
主流传输工具都支持限速,lftp 的 --rate-limit 选项可以限制上传速率，rsync 用 --bwlimit，把速率限制在空闲带宽的一半以内，业务高峰期几乎无感。
问题 2：日志备份脚本跑完了，本地的日志文件能直接删吗？
建议保留至少 7 天的本地副本再删，多一层冗余就多一层保障，本地删早了、远端又出问题，日志就彻底没了。
问题 3：FTP 和 SFTP 哪个好？
SFTP 的加密通道更强，不额外开放端口，配置成本更低；FTP 的传输效率略高，但需要处理被动模式和防火墙端口段，且明文传输存在被嗅探的风险，内外网环境不同，主流选择仍然是 SFTP。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/578807.html
