Skip to main content

💾 数据存储折腾手记

liblaf9/19/25About 7 min

写代码一时爽, 数据管理火葬场. 我是仓鼠, 我时常会陷入一种 “数据焦虑”: 我的代码、我的数据集、我的实验结果… 它们还安全吗? 🤯 万一哪天硬盘暴毙, 服务器被黑, 我会不会一夜回到解放前?

为了睡个好觉, 我折腾了一些数据存储和备份方案. 它不一定是最优解, 但目前还凑合.

Warning

本文充斥着我的直觉, 主观臆断和偏执, 请谨慎食用! 如有雷同, 那说明我很棒了.

📁 需求分类

我的数据体量不算大, 考虑到未来的增长先按 2TB 算.

我把存储分为三类:

  1. Daily: 日常频繁读写的存储
  2. Archive: 基本不写入, 但需要时不时读取
  3. Backup: 定期写入, 只在数据丢失时才会动用

至于代码, 它们有最好的归宿 — GitHub. 我相信 GitHub 的专业性和安全性, 所以本文的讨论不包含代码.

🏷 信任鄙视链

我对存储的可靠性有一套自己的 “迷信” 排序, 从高到低大概是这样的:

企业级服务 > 企业级硬件 + 我自己用 > 消费级硬件 + 我自己用 > 企业级硬件 + 公用 > 消费级硬件 + 公用

简单说就是: 我相信大公司, 相信我自己, 但不太敢相信别人 (比如公用环境).

具体来说:

  1. ✅ 100% 可靠 (我认为):
    1. 企业级服务, 比如 OneDrive, 清华云盘. 微软和清华 ITS, 我放心. 就是容量还不够大.
  2. 👍 比较可靠, 基本不担心:
    1. Microsoft 365 Developer Program 提供的 5TB OneDrive. 虽然续期有可能翻车, 但我相信巨硬的稳定性, 而且到期后仍留有充裕的时间用于转移数据.
    2. 自用的消费级硬件, 比如健康的 SSD, PSSD. 我相信自己, 但也怕哪天脑子一抽误删东西.
    3. 实验室的数据服务器 (RAID6). RAID6 还是靠谱的. 虽然权限管理比较严格, 但我总担心会不会有误操作, 或者被攻击.
  3. 🚽 公厕:
    1. 实验室的计算服务器. 服务器的用户包括同学们 和匿名黑客. 尽管我是管理员, 但共享环境的可靠性取决于最不靠谱的那个人, 而你永远不知道他是谁 (甚至可能是我自己).
    2. 百度网盘: What can I say? 🤷

🔁 3-2-1 原则

我听闻备份的 “3-2-1 原则” (3 份拷贝, 2 种介质, 1 份异地). 但我是穷学生. 不过这个原则确实值得参考.

🗂 数据集

我平时这样处理数据集:

  • Daily: 直接拷贝到项目目录下, 简单粗暴.
  • Archive: 我会用 .tar.zst 格式以最高压缩率狠狠压缩它, 然后扔进清华云盘. 我的 CPU 算力不值钱, 但云盘空间寸土寸金, 必须狠狠地压缩. 同时还会记录压缩文件的哈希值 (我偏爱 blake3) 以备校验.

因为我相信清华云盘, 所以不再额外 backup.

🔬 实验和中间结果: Git + DVC

这部分是我的得意之作, 它解决了困扰我多年的代码与数据版本同步难题.

我开发了一个名为 🍒 Cherries 的 Python 小工具来自动化许多流程. 一次完整的 “experiment run” 大概是这样:

  1. 运行脚本: 像往常一样 python src/30-compute.py. 我喜欢用数字前缀来命名脚本 (10-gen.py, 20-preprocess.py), 这样这样按文件名排序, 依赖关系一目了然.
  2. Inputs: 在实验开始前, Cherries 自动调用 dvc add [inputs], 并启用 Comet 进行 experiment tracking
  3. Tracking: 代码运行时, Comet 会记录 stdout 和 stderr, 方便在网页端查看
  4. Outputs: 跑完后, Cherries 再次调用 dvc add [outputs]
  5. Git Commit: 自动生成 git commit, message 中包含运行参数, inputs + outputs 路径和 Comet URL 等 metadata. 由于 DVC 的存在, 这次 commit 实际上已经锁定了本次实验的完整输入、输出和代码版本.
  6. Local Snapshots: Cherries 会把 source code, inputs, outputs, run.log 都拷贝一份到本地的 .cherries/ 目录下, 方便快速对比近几次实验的异同.

这样下来:

  • 代码与数据存储分离: 代码 push 到 GitHub, 而数据通过 DVC push 到我自己的存储后端. 我可以公开代码, 同时将数据保密. 除非有外星科技能从 DVC 的 MD5 指针恢复原文件 😉
  • 版本控制: git checkout 到任何一个历史 commit, DVC 就会自动拉取对应版本的数据, 复现当时的工作区.
  • 自动化: 结合 pre-commit hooks, git push 时 DVC 会自动上传数据, git pull 或 checkout 时会自动下载, 全程无感.

我选用 SSH 作为 DVC 远程存储, 数据存在我自己的 PC 上. 美中不足的是, DVC 目前还不支持压缩. 为了保险起见，我还会用 Restic Profile 定时备份数据到清华云盘. Restic 真心好用: snapshots 创建和清理都很方便, 支持块级去重和压缩. 我甚至每小时做一次快照. 反正我的 CPU 算理不值钱, 但云盘空间寸土寸金, 必须狠狠地压缩.

❓ Why not Git LFS?

Git LFS 其实是个不错的选择, 但我最终没选它, 原因有二:

  1. 对文件夹支持不优雅: 如果有一个包含 1000 帧的动画文件夹, Git LFS 会生成 1000 个 pointer, 而 DVC 只需要一个 .dvc 文件.
  2. 需要 self-host service: GitHub 那点免费额度, 分分钟就用光了. Gitea 用 docker compose 起起来是挺方便的, 几分钟就能上线使用. 但额外维护一个服务也是要花时间的. 而 DVC 可以依赖于 SSH / WebDAV 存储, 我本就需要 SSH 和 WebDAV, 所以没有额外的负担.

💾 Filesystem

我参考了 Filesystems | CachyOS 和 File systems - ArchWiki, 最终选择了 Btrfs.

Why Btrfs?

我尤其喜欢以下这两个功能:

✅ Pros

  • Transparent compression. BTRFS supports transparently compressing files to allow for significant space savings with no user intervention.
  • Snapshot functionality. BTRFS leverages its COW nature to allow for the creation of snapshots of subvolumes that take up very little actual space.

Btrfs 的 snapshot 非常好用, 配合 snap-pac 可以 to perform a pre and post snapshot before and after pacman transactions. 与 Limine-Snapper-Sync 配合可以直接在 Limine boot manager 界面直接从 snapshot 启动.

❌ Cons

  • Worse on rotational drives due to aforementioned fragmentation.

目前我的所有硬盘都是 SSD, 所以 Btrfs 的 fragmentation 问题对我影响不大. 另外听说 Btrfs 的 RAID 支持有点问题, 但我基本上每台机器只有一块盘, 用不上 RAID.

🤔 Why not …?

Why not ext4?

EXT4 (fourth extended filesystem) is the most commonly used Linux filesystem.

❌ Cons
  • Lacks many of the advanced features other filesystems offer.

ext4 久经历史考验. 但 ext4 不支持 transparent compression 和 snapshot. 也许我有了 HDD 会用 ext4, 毕竟 HDD 不大可能会拿来做系统盘, 更可能是数据盘, 这时 snapshot functionality 就没那么重要了.

Why not ZFS?

ZFS is an advanced filesystem originally developed by Sun Microsystems in 2005. ZFS has many features, but is licensed under CDDL which means it cannot be included inside the linux kernel and requires a separate module installed.

✅ Pros
  • Pooled storage (zpool)
  • Snapshots using COW
  • Compression
  • Raid-Z support
  • ARC cache allows insanely fast read times on commonly accessed files.

ZFS 简直太强大了, 拥有我梦想的所有功能.

❌ Cons
  • Very complicated to use and understand due to features like zpool and ARC.
  • ARC requires a lot of ram to be effective.
  • Not included in the linux kernel therefore dependent on a third party kernel module (OpenZFS)

但 ZFS 配置有些复杂, 还有 license 问题. 虽然尝试配置成功了, 但还是害怕维护成本所以放弃了.

Copyright © 2025 liblaf MIT Licensed