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

得亏系统没格,不然跟搜狐上这个《 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
@ysc3839 Ghost 是基于块存储备份的,而且它内部确实会解析文件系统结构 简单说,它是一个文件系统感知的块级备份工具。存储格式是扇区流,但备份和恢复过程中都会解析文件系统结构来做智能优化
存储层面:GHO 文件存的是分区的原始扇区数据,按 32KB 一个 block 切片后压缩( Fast LZ 或 zlib )。解压出来就是一个完整的分区镜像,可以直接 dd 到磁盘。所以本质是基于块的备份 但 Ghost 不是无脑 dump 每个扇区,它会解析源分区的文件系统( NTFS/FAT/ext2/3 ),识别哪些块是”已使用”的,只备份有数据的块。这就是为什么一个 100GB 的分区如果只用了 20GB ,GHO 文件远小于 100GB 的原因
这也解释了你提到的两个现象:
- 恢复时允许目标分区大小不一致:因为 Ghost 知道文件系统结构,它可以在恢复时调整文件系统的元数据( NTFS 的 \(Bitmap 、\)MFT 、BPB 中的分区大小字段等),把数据块写到新位置。本质上是在做一个”带文件系统感知的块级克隆+resize”
- 恢复时显示文件名:Ghost 解析了文件系统的目录结构( NTFS 的 MFT ),可以在恢复过程中展示当前正在写入哪个文件对应的扇区。这纯粹是 UI 功能,底层写入仍然是按扇区顺序
题外话,最新版本是 12.0.0.13027 ,也许已经修复了 oom 问题
GHOST? 现在还用? 感觉是上世纪的东西了
@mercury233 博通在新版本加了混淆,11.5 的 Ghostexp.exe 才 2.9MB ( 12.0 是 10.8MB ),小很多
请问 Ghost 备份文件是基于块还是基于文件系统进行存储? 如果是基于块,那 Ghost 程序在恢复 NTFS 分区时,允许目标分区大小与备份时不一致,以及恢复时会显示文件名,是如何实现的?难不成是 Ghost 内部再去解析文件系统结构?