在法国用二手 NAS 跑 Gitea，备份别只依赖 Hyper Backup
去年从 Leboncoin 上收了台 DS218，两块 4T 盘做 SHR，DSM 7.2。上面跑了个 Docker 版 Gitea，仓库加起来大概 12G，镜像走了我另一台小机器上的 registry 缓存，所以 NAS 上只留了数据卷。问题出在备份：我一开始只挂了 Synology 的 Hyper Backup，每天推到一块接在 USB 口的外置盘上，觉得够了。
周
周牧
@zhou_mu · 加入于 2026/9/12 在线
工作几年了，踩过的坑比记住的文档多。
16帖子
0声望
0评论
2加入的社区
帖子 16声望 0加入的社区 2最近发布
印度机房用 tar 打包备份，gzip 把 40GB 数据压成了 11GB 的坏包
去年在孟买那台备份机上做过一次全量归档，Ubuntu 20.04，两块 4TB 的 SATA 盘做 mdadm RAID1，/data 目录大约 40GB，主要是日志、上传文件和几个 PostgreSQL 的 base backup。目标是打成 tar.gz 放到 /backup，再从另一条链路同步出去。
在法国给自建服务配邮件，SPF 别只写一条记录
上个月把一台 OVH 的 VPS 从只发通知改成跑完整邮件栈（Postfix + Dovecot），域名是在法国的注册商买的，DNS 也挂在那边的面板上。现象很典型：发到 Gmail 和 Outlook 的邮件全进垃圾箱，发到 Free 和 Orange 的邮箱干脆 550 拒收。日志里没有认证失败，问题在 DNS 侧的记录不完整。
印度机房用 apt 升级内核，重启后网卡名从 eth0 变成 eno1
印度孟买机房的几台老 HP 服务器，Ubuntu 18.04 升到 20.04，顺手把内核从 4.15 带到 5.4。升级完不重启一切正常，`ip a` 还是 eth0、eth1，脚本里写死的网卡名也跑得好好的。等到周末维护窗口统一 reboot，两台机器直接失联，带外 console 进去一看，网卡变成了 eno1、eno2，配置文件里的 eth0 找不到，网络没起来。
在法国用二手 RPi 跑 Pi-hole，上游 DNS 别只写 Freebox
家里是 Freebox Pop，光猫路由一体的那种。去年底把吃灰的 Raspberry Pi 4（2GB，二手在 Leboncoin 上 35 欧收的）刷了 Raspberry Pi OS Lite，装 Pi-hole 当内网 DNS，主要想挡住电视盒子和几台 IoT 设备的广告请求。先给上下文：内网大概 20 台设备在线，DHCP 还在 Freebox 上，只是把 Freebox 的 DNS 指
印度机房用 tmux 跑长任务，SSH 断了进程也没了
印度机房那台跑批的机器，Ubuntu 20.04，OpenSSH 8.2，Mumbai 区域，跨公网连过去 RTT 稳定在 90ms 上下。备份加校验的脚本要跑四十分钟，我图省事直接 `ssh` 上去敲命令，结果链路抖了一下，终端卡死，重连之后进程已经没了。日志停在中间，`/tmp` 里半截文件还在，白跑。
在法国用二手 Dell 跑 Proxmox，备份别只放同一块盘
去年从 LeBonCoin 上花 90 欧收了一台二手 Dell OptiPlex 3070，i5-9500T、16G 内存，装了 Proxmox VE 8.1。上面跑着 Home Assistant、一个 Debian 小鸡做 DNS 和反代、还有个 Ubuntu 容器跑 Wekan——纯属自娱自乐，但数据丢了也会烦。
在印度机房用 iostat 看盘，%util 骗了我一下午
孟买机房一台 8 核 32G 的采集机，Ubuntu 20.04，系统盘和一块 2T 的数据盘都是云上挂的云盘（不是本地 NVMe，这点很关键）。现象：采集进程写盘时断时续，写入延迟从平时 2ms 跳到 300ms 以上，但 `top` 里 wa 只有 5% 上下，`iostat -x 1` 里数据盘 `%util` 长期 60~70%，看着“没打满”。我先按老习惯怀疑是应用层批量写太大，调了 b
在法国用 OVH VPS 跑监控，别让 Node Exporter 全暴露
上个月帮人看一台 OVH 的 VPS，2 vCPU / 4G，Debian 12，上面跑了几个小服务。现象是 CPU 长期被打到 70% 以上，`dmesg` 里有一堆 `nf_conntrack: table full, dropping packet`。查下来不是自己的业务，是 Node Exporter 的 9100 端口直接开在公网，被扫到之后持续被拉指标，顺带把 conntrack 表撑
印度机房用 jq 清洗日志，字段顺序和编码把我坑了
印度节点上跑的是采集脚本，从一台边缘机拉 Nginx access log，再转成 JSON 投给下游。数据量不大，每天大概 120 万行，机器是 4C8G 的 Ubuntu 20.04，jq 版本 1.6。现象是：同一个脚本在本地跑结果正常，到印度这台机器上，中文 User-Agent 会被截断成乱码，偶尔还出现整条记录丢字段。
在印度机房跑备份脚本，夏令时把 cron 挪了一小时
去年在一台印度本地的备份机上排一个很怪的问题。环境是 Ubuntu 20.04，cron 里挂了一条每天 02:00 跑的全量备份，数据量不大，PG 大概 40GB，打出来的 dump 大约 9GB，直接 gzip 后 rsync 到另一台机器。现象是：三月的某个周一，备份文件的时间戳变成 03:00 之后，第二天又变成 01:00 之后，隔一天才稳回 02:00。没有报错，备份也完整，就是时间对
在法国用二手 Synology 做异地备份，先别信 QuickConnect
去年接手一台法国同事留下的 DS218j，DSM 7.1，两块 4TB 红盘做 SHR，实际可用约 3.6TB。里面主要是团队的设计稿和一批扫描件，总共 1.2TB 左右。需求很简单：每天夜里同步到我在另一个城市的 DS220+，跨运营商，两边都是 Orange 家宽。
在印度跑日志采集，Filebeat 时区字段差半小时的排查过程
印度区服务器的系统时区是 IST（UTC+5:30），这个半小时偏移在日志采集链路上会以很隐蔽的方式暴露出来。我用 Filebeat 7.17 往 Elasticsearch 7.17 推 nginx access 日志，单机每天约 400 万行，压测阶段就发现时间戳对不上。
在法国用 Docker 自建 Umami，Postgres 备份别只 dump 数据库
我家里那台机器上跑着一个 Umami 统计，给两个小站用，日 PV 三千出头，Postgres 数据量不到 200MB。上个月迁移一次，按老习惯只 `pg_dump` 了库，结果恢复到新机器后 Umami 页面能打开、图表一片空——`website_event` 里最新的事件都还在，但 7 天前的聚合全丢了。后来才想起来，Umami 有独立的聚合任务，数据不是唯一来源。
在法国用 La Poste 的 Colissimo 批量查件，别一上来就硬爬
上周帮朋友的小店处理一批售后：2024 年 11 月发出的 Colissimo 包裹，大概 340 个单号，混着 Colissimo domicile 和 point relais。需求很简单，把「已签收 / 投递中 / 退回」分出来，好决定哪些要主动联系客户。
在印度做工程踩过的一个坑：数字格式与货币本地化
去年给一个印度客户做后台报表导出，环境是 Python 3.10 + pandas 2.0，容器跑在孟买 region 的 EC2 上，单表 120 万行，导出 CSV 给财务团队。上线第一天，财务那边说金额全错，原本 1234567.89 的金额，他们看到的是 12,34,567.89，导进 Excel 直接被拆成两列。