印度节点上 logrotate 把正在写的日志转走后，我丢了六小时审计
在印度孟买的一台 4C8G 的应用节点上，Ubuntu 22.04，跑一个每天写 8GB 左右业务日志的 Go 服务。某天照例用 logrotate 做切割，配置里 `daily`、`rotate 7`、`compress`、`postrotate` 发 `USR1` 让进程重开文件。结果第二天查审计事件，发现切割点之后六小时的日志完全找不到，旧文件里也没有，新文件里只有切割后的内容。
印度 — 印度 社区
印度机房用 tar 打包备份，gzip 把 40GB 数据压成了 11GB 的坏包
去年在孟买那台备份机上做过一次全量归档，Ubuntu 20.04，两块 4TB 的 SATA 盘做 mdadm RAID1，/data 目录大约 40GB，主要是日志、上传文件和几个 PostgreSQL 的 base backup。目标是打成 tar.gz 放到 /backup，再从另一条链路同步出去。
印度机房用 inotify 等文件事件，等来的却是丢失的 tail
上个月在孟买机房的 Ubuntu 20.04 那台日志中转机上，有个目录要实时收上游推来的日志分片，一天大概 15 万个小文件、30GB 左右。我第一版用 `inotifywait -m -r -e create,moved_to` 监听，脚本里拿到文件名就 `tail -f` 读几行入库。跑了两天发现漏文件，高峰期能丢 3% 左右，日志里查不到任何报错。
印度机房用 rsync 增量备份，删掉的文件在目标端活了三个月
印度机房一台备份机，Debian 11，源目录 1.8TB 左右，约 42 万个文件，主要是应用日志和上传件。目标是一块 4TB 的外挂盘，xfs。每天凌晨跑一次同步，跑完我只看 rsync 的退出码和尾部几行，一直是 0，就默认没事。
印度机房用 apt 升级内核，重启后网卡名从 eth0 变成 eno1
印度孟买机房的几台老 HP 服务器，Ubuntu 18.04 升到 20.04，顺手把内核从 4.15 带到 5.4。升级完不重启一切正常，`ip a` 还是 eth0、eth1，脚本里写死的网卡名也跑得好好的。等到周末维护窗口统一 reboot，两台机器直接失联，带外 console 进去一看，网卡变成了 eno1、eno2，配置文件里的 eth0 找不到，网络没起来。
印度机房用 curl 探活，DNS 缓存把故障藏了四十分钟
印度机房，Ubuntu 22.04，主机上跑一个后端服务，前面一层 Nginx 反代到内部两个上游节点。上游节点 IP 变化比较频繁，节点重启后由内部 DNS 重新分配地址。探活脚本每 30 秒跑一次，用 curl 请求 `/healthz`，连续三次失败就发告警。脚本跑了大半年没出过事。
在印度机房用阿里云 OSS 同步备份，multipart 分片把 200GB 传成了 340GB
深夜两点，备份窗口只剩四小时。印度孟买机房一台存储节点，Debian 12，内核 6.1，要往阿里云 OSS 推 200GB 的数据库全量备份，工具用 ossutil 1.7.16。现象很怪：本地 `du -sh` 是 200GB，OSS 控制台显示占用 340GB，而且上传速度在后半段掉到 3MB/s，日志里反复出现 `PartUploadFailed, retrying part 37`。
印度机房里用 screen 恢复会话，滚屏日志截断了一半
在孟买那台 4C8G 的 KVM 上跑一个数据补录脚本，Ubuntu 20.04，Python 3.8，输出量不算大，一天大概 1.2G 的 stdout。之前一直用 `nohup python backfill.py > run.log 2>&1 &`，SSH 断了进程还在，但输出只有落盘之后才能看，想实时盯进度就得 tail。后来换成了 screen，想的是断线之后重新 attach 能直接看
印度机房用 tmux 跑长任务，SSH 断了进程也没了
印度机房那台跑批的机器，Ubuntu 20.04，OpenSSH 8.2，Mumbai 区域，跨公网连过去 RTT 稳定在 90ms 上下。备份加校验的脚本要跑四十分钟，我图省事直接 `ssh` 上去敲命令，结果链路抖了一下，终端卡死，重连之后进程已经没了。日志停在中间，`/tmp` 里半截文件还在，白跑。
在印度机房用 cron 跑备份，PATH 让我丢了三天日志
印度孟买机房，Ubuntu 22.04，内核 5.15，四台跑日志聚合的机器。上周发现一台机器上 /var/log/app/ 里连续三天的备份文件全是 0 字节，但 cron 日志里每条任务都显示执行成功。数据量不大，每天约 1.2 GB 的文本日志，压完 180 MB 左右，文件时间戳正常，就是内容为空。
在印度机房用 du 和 find 找大文件，硬链接把统计翻了一倍
上周在孟买那台备份机上遇到一个空间问题：df 显示 /data 用了 87%，但业务那边说这个分区只存了不到 40% 的备份数据。系统是 Ubuntu 20.04，ext4，分区 8T，上面跑的是自己写的增量备份脚本，用 rsnapshot 的思路做的硬链接快照，保留了 14 天的日备。
在印度机房用 iostat 看盘，%util 骗了我一下午
孟买机房一台 8 核 32G 的采集机，Ubuntu 20.04，系统盘和一块 2T 的数据盘都是云上挂的云盘（不是本地 NVMe，这点很关键）。现象：采集进程写盘时断时续，写入延迟从平时 2ms 跳到 300ms 以上，但 `top` 里 wa 只有 5% 上下，`iostat -x 1` 里数据盘 `%util` 长期 60~70%，看着“没打满”。我先按老习惯怀疑是应用层批量写太大，调了 b
在印度机房用 ncdu 清磁盘，删完 df 还是 100%
印度机房一台跑日志归档的机器，Ubuntu 20.04，/var 分区 500G，报警时 df 显示 98%。用 ncdu 扫了一遍，/var/log 下有个归档目录占了 210G，里面是三个月前的 .tar.gz，确认没人要，直接 rm -rf 清掉了。
在印度机房用 logrotate 切日志，copytruncate 把 inode 弄丢了
印度孟买机房的采集节点，Ubuntu 20.04，logrotate 3.14，每天凌晨切一次 Nginx 和自研采集器的日志，单文件峰值大约 4.2 GB。现象是切换之后，采集器还往旧文件描述符里写，新文件一直是 0 字节，直到进程重启才恢复；同时 `du` 看到的磁盘占用比 `df` 少了将近 3 GB，`lsof | grep deleted` 里挂着一堆已删但未释放的文件。
印度机房用 jq 清洗日志，字段顺序和编码把我坑了
印度节点上跑的是采集脚本，从一台边缘机拉 Nginx access log，再转成 JSON 投给下游。数据量不大，每天大概 120 万行，机器是 4C8G 的 Ubuntu 20.04，jq 版本 1.6。现象是：同一个脚本在本地跑结果正常，到印度这台机器上，中文 User-Agent 会被截断成乱码，偶尔还出现整条记录丢字段。
印度机房 NTP 漂移：日志时间戳集体偏 47 秒
印度机房一批新增的采集节点，Ubuntu 22.04，chrony 默认配置，跑了大约两周后开始出现日志时间戳整体偏移。不是时区问题，UTC 数值本身错了：同一批 12 台机器里，有 5 台比参考机快 40 到 50 秒，另外 7 台正常。数据量不大，每台每天约 300MB 的日志，但下游按时间窗口做 join，偏移 47 秒足够让一批本该对齐的记录错位，排查时先怀疑时区，浪费了半天。
在印度机房把 rsync 换成 bbcp，大文件传输快了三倍
上个月要把一批约 1.2TB 的备份文件从孟买机房的旧存储节点挪到浦那的新节点，两边都是 CentOS 7，内核 3.10，走的是同城专线。一开始用 rsync -avz 直接跑，平均速率只有 18MB/s 左右，传了快十个小时才走完三分之一，而且中途断了一次，重跑还得从头比对，时间全耗在扫描上。
在印度机房跑备份脚本，夏令时把 cron 挪了一小时
去年在一台印度本地的备份机上排一个很怪的问题。环境是 Ubuntu 20.04，cron 里挂了一条每天 02:00 跑的全量备份，数据量不大，PG 大概 40GB，打出来的 dump 大约 9GB，直接 gzip 后 rsync 到另一台机器。现象是：三月的某个周一，备份文件的时间戳变成 03:00 之后，第二天又变成 01:00 之后，隔一天才稳回 02:00。没有报错，备份也完整，就是时间对
在印度用 systemd 管 Python 服务，重启后端口被占的排查
上周在孟买机房的一台 Ubuntu 22.04 机器上，部署了一个 FastAPI 服务，用 systemd 托管，跑在 8000 端口，日均请求量不大，QPS 峰值 40 左右。上线两周没出事，直到运维做了一次例行内核升级重启，服务起不来了，`systemctl status` 显示 `Address already in use`。
在印度跑日志采集，Filebeat 时区字段差半小时的排查过程
印度区服务器的系统时区是 IST（UTC+5:30），这个半小时偏移在日志采集链路上会以很隐蔽的方式暴露出来。我用 Filebeat 7.17 往 Elasticsearch 7.17 推 nginx access 日志，单机每天约 400 万行，压测阶段就发现时间戳对不上。