获取服务器文件

凌晨两点，服务我盯着终端里跳动的器文光标，scp 命令已经重试了七次。服务第八次按下回车时，器文屏幕终于吐出一行进度条——那个 4.7GB 的服务数据库备份文件，正以每秒 3MB 的器文速度爬向本地磁盘。这速度够我泡杯速溶咖啡，服务再刷完半集剧。器文

获取服务器文件这件事，服务本质上就三种路子：scp 硬拷、器文rsync 同步、服务或者写个脚本走 API 拉取。器文但现实永远比 man page 复杂。服务上个月我给客户迁移 WordPress，器文站点文件散落在十几个目录里，服务主题、插件、上传图片混在一起，tar 打包时忘了排除缓存目录，结果压缩包膨胀到 2GB，传到一半对方机房断网——白等四十分钟。

后来学乖了。先跑 du -sh 摸清家底，再用 rsync --exclude 精准过滤，最后加个 --partial 参数。断点续传这功能，平时觉得鸡肋，真碰上电信光缆被挖掘机铲断时，能救你半条命。

但工具链只是表象。真正让人头疼的，是权限和路径的暗坑。有回帮朋友调试阿里云服务器，他给了 root 密码，我顺手 cd /var/www 想看看站点结构，结果 ls 直接报 permission denied。查了半小时才发现，那台机器启用了 SELinux，Apache 的文档根目录被强制标了 httpd_sys_content_t 标签，普通 root 在 shell 里也碰不得。最后用 semanage 改上下文才解开——这玩意儿在 Ubuntu 上根本不存在，纯属 CentOS 系特产。

你要是只在自己笔记本上折腾，可能永远遇不到这些破事。但生产环境就像个脾气古怪的老房东，每台机器都有自己不可言说的规矩。去年冬天给某电商平台做日志分析，他们的文件分散在三台负载均衡器后面，每台机器上 /data/logs 的软链接指向不同挂载点。用 find 遍历时，符号链接循环差点把 inode 表撑爆。后来改成 readlink -f 先解析真实路径，才稳住局面。

有个小技巧值得说：别老盯着 ls -lh 看文件大小。用 stat 看 Birth time（创建时间）能帮你判断这文件是不是该清理的残留物。上周清理监控系统，发现有个 300MB 的核心转储文件，创建时间是三个月前某个凌晨——正好是内核 panic 的时段。删掉它，磁盘告警立刻解除。

最后提个反直觉的观察：wget 和 curl 虽然能下载，但碰上需要认证的私有仓库，反而容易踩雷。我见过有人用 curl -u 硬传密码，结果 shell history 里明文躺着账号。宁可花五分钟配个 SSH key，也别图一时方便。

文件到手后别急着撒手。先 md5sum 校验一下，再 file 命令确认格式没被传输过程搞坏——尤其是从 Windows 服务器拉下来的文件，换行符和编码经常悄悄变异。有次客户给的 CSV 用 GBK 编码，我直接 iconv -f GBK -t UTF-8 转完才发现，里面夹杂着 BOM 头，又花十分钟用 sed 剥掉。

说到底，获取文件只是手段，真正考验人的是对异常情况的预判。下次执行 scp 前，多问自己一句：如果网络断了怎么办？如果目标路径不存在怎么办？如果磁盘满了怎么办？想清楚这三个问题，你就能少熬几个像今晚这样的夜。