EmuMMC备份思路

EmuMMC

Warn

本文假设我们使用的是 File-based EmuMMC

由于游戏一般通过DBI安装到 SDCard 上，所以会直接安装到 emuMMC上，而emuMMC是一个 emuMMC/SD00 这样的文件夹，内部包含和本机NAND闪存结构一致的那些文件，大气层和EmuMMC通过扇区直接读写的方式访问，因此会提前创建好 EmuMMC的那些文件，如00,01,02...。随着游戏安装越来越多，体积会变得很大，假如我们的SD卡能达到256GB，那么 emuMMC 会达到 200GB甚至更大。

那么问题就来了，备份的过程非常漫长，即便对游戏内容进行删除和卸载，这些文件的体积不会缩小，只会变得更大。

典型的结构：

SD卡根目录/
├── emuMMC/
│   ├── emummc.ini
│   │
│   └── SD00/
│       ├── file_based
│       │
│       ├── eMMC/
│       │   ├── BOOT0
│       │   ├── BOOT1
│       │   ├── 00
│       │   ├── 01
│       │   ├── 02
│       │   ├── ...
│       │   └── 07 / 14 / 其他编号
│       │
│       └── Nintendo/
│           ├── Album/
│           ├── Contents/
│           └── save/
│
├── atmosphere/
├── bootloader/
└── Nintendo/

备份思路

第一次全量备份是必不可少的，但是我们只需要一次全量的备份。很多开发者为了体验不同的分区方式、或者测试 SD卡的文件系统等，不得不进行反复备份和恢复。

很可惜 emuMMC 不支持压缩空间。

这时有一个技巧，只要有第一次的全量备份，那么后面如果需要这些数据可以及时恢复。

如果仅仅为了方便各种测试，可以重做一个，通过Hekate重新做一份 emuMMC，这个时候，Hekate 会从 系统的 NAND 复制一份出来重新初始化到SD卡，文件体积就小的多，假设 Switch 1 代的 NAND 是32GB，那么复制出来的不会超过 32GB。

另外，很多人选择只备份存档，这些游戏，只要游戏本体还在，随时可以再安装一遍，相比反复去拷贝这些膨胀的文件，省去不少时间。