对 Symantec Ghost 的 GHO 格式研究

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

五一假期结束，公司运维紧急找到我，说是 1T 多的 GHO 系统备份无法通过 Ghost 还原，使用 GhostExp 也无法打开提示“Out of Memory”（ OOM ）。应该是 Norton Ghost 的浏览器在读取 GHO 文件时全加载进内存里了，不过现在跟 VMware 一样都是博通的了 undefined

得亏系统没格，不然跟搜狐上这个《 2.8TB 外贸数据生死救援！ GHOST 备份崩溃后，我们如何 100%恢复？》一样完蛋按某数据恢复工程师提供的思路，研究了 GHO 文件结构:

[File Header]                  (512 字节)
    │
    ├── [Record: Track 0]      (类型 0x0006)  → MBR + 引导扇区
    │
    ├── [Record: Partition]    (类型 0x0603)  → 分区描述符
    │
    ├── [FEEF Partition Header] (512 字节)    → 该分区的压缩参数
    │
    ├── [Compressed Data Blocks]              → 实际数据（ 32KB 对齐）
    │       ├── Block 1 (2B 长度 + 数据)
    │       ├── Block 2 ...
    │       └── ...
    │
    ├── [Record: Continuation] (类型 0x0703)  → 跨文件续卷标记（多文件时出现）
    │
    └── [Record: End]          (类型 0x0023)  → 文件结束标记

赛门铁克的压缩方法，是一个比较黑盒的自定义 LZ77 变种，每个块解压后固定 32KB：

[2 字节 stored_len] [1 字节 控制字节] [数据...]

附：哈希表（ 4096 条） h = ((-24993 * (b2 ^ (16 * (b1 ^ (16 * b0))))) >> 4) & 0xFFF 其中 b0 、b1 、b2 是当前 3 字节窗口，在 2000 年那会比较常见的一种轻量级高压缩比的老格式了，新的诺顿克隆精灵似乎用的是 i2v 格式，但我从小到大见过的 Ghost 镜像都是 gho 格式的

具体的代码已开源： https://github.com/nyarime/gho

gho

备份

格式

12 replies • 2026-05-06 19:00:54 +08:00

ysc3839

11h 26m ago via Android

请问 Ghost 备份文件是基于块还是基于文件系统进行存储？
如果是基于块，那 Ghost 程序在恢复 NTFS 分区时，允许目标分区大小与备份时不一致，以及恢复时会显示文件名，是如何实现的？难不成是 Ghost 内部再去解析文件系统结构？

Nyarime

11h 15m ago

@ysc3839 Ghost 是基于块存储备份的，而且它内部确实会解析文件系统结构
简单说，它是一个文件系统感知的块级备份工具。存储格式是扇区流，但备份和恢复过程中都会解析文件系统结构来做智能优化

存储层面：GHO 文件存的是分区的原始扇区数据，按 32KB 一个 block 切片后压缩（ Fast LZ 或 zlib ）。解压出来就是一个完整的分区镜像，可以直接 dd 到磁盘。所以本质是基于块的备份
但 Ghost 不是无脑 dump 每个扇区，它会解析源分区的文件系统（ NTFS/FAT/ext2/3 ），识别哪些块是"已使用"的，只备份有数据的块。这就是为什么一个 100GB 的分区如果只用了 20GB ，GHO 文件远小于 100GB 的原因

这也解释了你提到的两个现象：
1. 恢复时允许目标分区大小不一致：因为 Ghost 知道文件系统结构，它可以在恢复时调整文件系统的元数据（ NTFS 的 $Bitmap 、$MFT 、BPB 中的分区大小字段等），把数据块写到新位置。本质上是在做一个"带文件系统感知的块级克隆+resize"
2. 恢复时显示文件名：Ghost 解析了文件系统的目录结构（ NTFS 的 MFT ），可以在恢复过程中展示当前正在写入哪个文件对应的扇区。这纯粹是 UI 功能，底层写入仍然是按扇区顺序