对 Symantec Ghost 的 GHO 格式研究

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

This topic created in 38 days ago, the information mentioned may be changed or developed.

五一假期结束，公司运维紧急找到我，说是 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

备份

格式

14 replies • 2026-05-30 10:48:04 +08:00

ysc3839

May 6 via Android

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

Nyarime

May 6

@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 功能，底层写入仍然是按扇区顺序