Emulator save lost: can you recover your progress?

If your emulator save lost situation happened in a browser-based emulator, the short answer is: recovery is rarely possible. Browser emulators store save data inside IndexedDB — a structured key-value database built into your browser — rather than as a file on your hard drive. When that storage is cleared or never written in the first place, the data is gone.

IndexedDB is part of the Web Storage specification and is sandboxed per origin (protocol + domain + port) and per browser profile. That means saves created on https://retrogamespace.com in Chrome are completely separate from saves in Firefox, Safari, or even a different Chrome profile on the same machine. The browser provides no built-in user-facing interface to browse or export this data; it is entirely managed by the web application running in the tab.

From the emulator's perspective, writing a save is straightforward: when the emulated game flushes its SRAM (battery-backed save RAM), the emulator serializes that memory region and commits it to IndexedDB. On page load, the emulator reads it back. Everything works correctly as long as IndexedDB retains that record — and there are several common reasons it does not.

There are four distinct causes behind a browser save disappeared event, and each one has a different likelihood of being recoverable. Knowing which one hit you determines your next move.

• Clearing browsing data: Chrome, Firefox, Edge, and Safari all include an option to delete 'site data' or 'cookies and site data'. IndexedDB is classified as site data. If you selected that option — even while targeting cookies — every IndexedDB database for every origin was wiped simultaneously. This is the most common cause on desktop and produces no warning.
• Incognito or private-browsing mode: Browsers explicitly do not persist IndexedDB to disk when a private window is closed. Any save written during that session existed only in RAM and was discarded the moment you closed the window. There is no recoverable copy.
• iOS Safari storage quota eviction: Apple's WebKit engine on iOS applies a 7-day inactivity rule to website storage under certain conditions, and the OS can evict site data when device storage is critically low. Safari on iPhone and iPad is the most frequently cited environment for unexplained emulator progress loss.
• Different browser profile or browser: Because IndexedDB is scoped per origin and per profile, switching from your work Chrome profile to your personal Chrome profile, or from Chrome to Firefox, gives you a completely empty database. Your old saves still exist — in the other profile — and can be recovered simply by switching back.

A fifth edge case worth mentioning: some browser extensions that advertise 'privacy' or 'anti-tracking' features periodically wipe site storage on a schedule. If you cannot identify any of the four causes above, check your installed extensions for storage-clearing behavior.

To attempt to recover emulator save data, you need at least one of the following conditions to be true. None of them apply universally, so read each one carefully before investing time.

1. You exported a .srm file before the loss: If you previously used the emulator's export or download function to save a .srm (SRAM dump) file to your device, that file is still on your hard drive. Re-importing it through the emulator's import function will restore your progress to whatever point the export captured.
2. Your saves are in a different browser profile: Open the browser's profile switcher and look for other profiles. Navigate to the emulator site in each one. If your save data appears, export it as a .srm immediately and then re-import it into your primary profile.
3. You have a cloud or sync backup: If the emulator you were using integrates with a cloud-sync service, check that service's web interface or app for any stored save states or SRAM files. Cloud sync for RGS is planned for a future release — see the site blog for current availability.
4. You are on Android Chrome and have not rebooted: Chrome on Android caches IndexedDB writes in memory before committing to disk. In the narrow window between a crash and a reboot, a forced sync triggered by revisiting the page may recover the last session. This is an unreliable edge case, not a procedure to count on.

在没有开发者工具的情况下，无法直接从浏览器内部提取 IndexedDB 数据，即便借助工具也只有在数据库尚未被删除时才有可能。在 Chrome 中，你可以打开开发者工具（F12），依次进入「应用程序 → 存储 → IndexedDB」，检查该网站的数据库是否仍然存在。如果其中显示有条目，则应使用模拟器自带的导入/导出工具来提取数据——切勿尝试直接编辑 Chrome 内部使用的原始 LevelDB 文件，因为这样做有损坏其他浏览器数据的风险。

关于 IndexedDB 存档恢复，有一个残酷的现实：一旦数据库记录被删除，就没有回收站、没有卷影副本、也没有服务器端备份可以依靠。与从桌面删除的文件不同，IndexedDB 数据不会以任何用户可访问的方式经过操作系统的文件删除流程。

具体而言，以下几种情况下存档无法恢复：在浏览器中使用了「清除网站数据」或类似选项；游戏在隐私/无痕窗口中进行；iOS Safari 因长时间未使用或存储压力而清除了数据；或隐私扩展按计划删除了存储内容。在以上四种情况中，底层数据要么已被覆写，要么从未被提交到持久存储中。

磁盘取证恢复工具（例如用于恢复已删除文件的工具）在此处毫无用武之地。Chrome、Firefox 和 Safari 均将 IndexedDB 以紧凑的二进制格式存储（Chrome 使用的是 LevelDB），这些格式在浏览器正常运行期间会被持续改写。当你发现存档丢失时，曾经存放这些数据的物理扇区几乎可以肯定已经被覆写。

我们不会推荐网络上流传的第三方「IndexedDB 恢复」工具。我们所检验过的此类工具，要么只是扫描与游戏存档数据毫无关联的通用文件特征，要么需要将浏览器内部数据交给一个闭源应用程序处理。这两种方式对于本使用场景都不可靠，并且都存在切实的风险。

防止浏览器存档意外消失，唯一可靠的方法是在 IndexedDB 之外保存一份存档数据的副本。这意味着需要定期导出 .srm 文件——最好在每次有实质进展的游戏过程结束后都导出一次——并将其保存到不受浏览器数据清除影响的地方。

• 定期导出 .srm 文件：每次游戏结束后使用模拟器的导出功能，将生成的文件保存到硬盘上的某个文件夹或云存储中。一个 .srm 文件体积很小（超级任天堂游戏使用标准 SRAM 时通常为 8 KB），下载只需几秒钟。
• 至少保留两份带日期的副本：在文件名中加入日期后缀（例如 zelda-lttp-2024-11-03.srm），便于在存档损坏时回退到更早的存档点。有一份近期备份总比没有好；两份带日期的备份则让你即使在最新导出文件出现问题时也有一个可用的恢复点。
• 对于你在意的游戏，切勿在无痕模式下游玩：无痕模式适合用于测试或一次性游戏。它不适合耗时数小时的 RPG 流程，因为浏览器会在窗口关闭时无条件丢弃所有存储数据。
• 在 iOS 上，至少每 7 天访问一次模拟器网站：Apple 的 WebKit 存储驱逐计时器会在每次访问时重置。定期访问可以降低——但不能完全消除——iOS 清除数据的风险。
• 关注 RGS 云同步功能：云同步上线后，存档将可以保存在服务器端并跨设备同步。在该功能推出之前，导出 .srm 文件仍是本网站唯一的跨设备备份方式。请关注 RGS 博客以获取发布公告。
• 避免使用会清除网站数据的浏览器扩展：如果你使用了隐私扩展，请检查其设置中是否存在自动清除存储的计划任务，要么禁用该功能，要么将 retrogamespace.com 添加到其白名单中。

针对 iOS 用户，有一点需要特别说明：自 iOS 17 起，你可以将网站以渐进式网络应用（Progressive Web App）的形式添加到主屏幕。在主屏幕 PWA 内创建的存储数据保存在一个独立的配额容器中，与标准浏览器分开，不受 Safari 标签页同样适用的 7 天驱逐规则限制。如果你经常在 iPhone 或 iPad 上游玩，将网站添加到主屏幕是一项有实质意义的结构性改善，但并非完整的解决方案。你仍然应该定期导出 .srm 文件，因为 PWA 容器在手动操作或从主屏幕移除应用时仍然可能被清除。