💾 备份与存储.
10 篇 · 全部文章 →
- RSP 升级翻车实录：版本号显示 PL20，服务却起不来 SAP B1 的 RSP 从 PL18 升到 PL20，升完服务直接罢工。恢复的关键只有一句话：卸载时保住数据库。另附升级后两个差点酿成事故的静默陷阱。
- 备份下载下来不算完：用 Docker 把官网备份完整还原一遍，才敢说"可恢复" 官网刚经历过一次托管套餐误停的惊魂，趁热做了一次真正的恢复演练：把 cPanel 全量备份在本地 Docker 里从零拉起来——数据库导入 MariaDB 容器、站点文件挂载进版本匹配的 Drupal 容器。一路踩过 Windows 只读陷阱、localhost 变 Unix socket、PHP 8 跑不动老代码三个坑之后，网站在 localhost:8080 完整渲染出来，这份备份才算真的"验过货"。
- 买了 8TB 硬盘导出监控录像，DVR 死活只认 2TB 为了导出一段监控录像，特意买了一块 8TB 的移动 SSD，插到 DVR 上却先报"无法识别磁盘"，再报"分区格式不支持"——最后才搞清楚，问题根本不在格式化方法，而在这台 DVR 从设计上就只支持 2TB。
- 备份连续三晚静默失败：SAP B1 RSP 备份监控的教训 RSP 定时备份连续三个晚上产出 0 B 的失败备份，没有任何告警。全靠每周人工检查 Backup History 才发现。
- 给生产服务器 RAID5 在线扩容：68 小时还没跑完的 Background Initialization 插盘五分钟，扩容三天半。真正的代价不是操作本身，而是 background initialization 期间被拖垮的生产性能——用户开始报卡，我们只能白天暂停晚上继续。
- 不可变备份不做恢复演练等于没做：Veeam + Wasabi Object Lock 灾难演习全记录 建好 immutable 仓库只是第一步。我们模拟了"Veeam 服务器被毁"的最坏场景，从裸 bucket 一路恢复到文件级对比——中间果然埋着一个不演练就不会知道的坑。
- Veeam 备份到 Wasabi 突然 403：Compliance 和 Object Lock 不是同一个东西 备份任务报 S3 AccessDenied 403，排查半天发现是 Wasabi 桶开了 Compliance 模式——而 Veeam 只支持 Object Lock。两个"不可变"功能，选错一个就是全线失败。
- 选灾备方案前，先把现有备份的"盲区"列出来 拿着服务器清单去找 Datto、Druva 报价灾备方案时，才发现现有备份体系里藏着两个说不清楚的盲区——一台服务器根本没被真正备份，一个数据库的大小从来对不上账。
- Synology Active Backup 备份某台机器一直失败：又是防火墙策略 全公司只有 R&D 那台机器备份失败。机器没问题、agent 没问题——问题在它待的网段根本到不了 NAS。
- 自建邮件服务器存储爆满，根因是一个员工的 Outlook 设置 自建邮件服务器的磁盘空间告急，第一反应是清理垃圾邮件或扩容磁盘。但真正占用空间的，是一个用 POP3 收信的账号——多年来一直把邮件"留一份在服务器上"，从来没有人配置过自动清理。