Emulator-opslag verloren: kun je je voortgang terugkrijgen?

Als je emulator-opslag verloren is gegaan in een browsergebaseerde emulator, is het korte antwoord: herstel is zelden mogelijk. Browseremulators slaan speldata op in IndexedDB — een gestructureerde sleutel-waardedatabase die in je browser is ingebouwd — en niet als bestand op je harde schijf. Zodra die opslag wordt gewist of nooit goed is weggeschreven, is de data weg.

IndexedDB maakt deel uit van de Web Storage-specificatie en is afgeschermd per oorsprong (protocol + domein + poort) en per browserprofiel. Dat betekent dat opslag die is aangemaakt op https://retrogamespace.com in Chrome volledig losstaat van opslag in Firefox, Safari, of zelfs een ander Chrome-profiel op dezelfde computer. De browser biedt geen ingebouwde gebruikersinterface om deze data te bekijken of te exporteren; dat wordt volledig beheerd door de webapplicatie die in het tabblad draait.

Vanuit het perspectief van de emulator is het wegschrijven van een opslag eenvoudig: wanneer het geëmuleerde spel zijn SRAM (battery-backed save RAM) doorspoelt, serialiseert de emulator dat geheugengebied en slaat het op in IndexedDB. Bij het laden van de pagina wordt het weer ingelezen. Alles werkt correct zolang IndexedDB die record bewaart — en er zijn meerdere veelvoorkomende redenen waarom dat niet het geval is.

Er zijn vier duidelijk te onderscheiden oorzaken achter het verdwijnen van browseropslag, en elke oorzaak heeft een andere kans op herstel. Weten welke jou heeft getroffen, bepaalt je volgende stap.

• Browsedata wissen: Chrome, Firefox, Edge en Safari bieden allemaal een optie om 'sitedata' of 'cookies en sitedata' te verwijderen. IndexedDB valt onder sitedata. Als je die optie hebt geselecteerd — zelfs als je alleen cookies wilde verwijderen — werd elke IndexedDB-database voor elke oorsprong tegelijkertijd gewist. Dit is de meest voorkomende oorzaak op desktop en gebeurt zonder enige waarschuwing.
• Incognito- of privébrowsemodus: Browsers slaan IndexedDB bewust niet op schijf op wanneer een privévenster wordt gesloten. Elke opslag die tijdens die sessie is aangemaakt, bestond alleen in RAM en werd op het moment dat je het venster sloot weggegooid. Er is geen herstelbare kopie.
• iOS Safari opslagquotum-verwijdering: Apple's WebKit-engine op iOS hanteert onder bepaalde omstandigheden een inactiviteitsregel van 7 dagen voor websiteopslag, en het besturingssysteem kan sitedata verwijderen wanneer de apparaatopslag kritiek laag is. Safari op iPhone en iPad is de meest genoemde omgeving voor onverklaarbaar verlies van emulatorvoortgang.
• Ander browserprofiel of andere browser: Omdat IndexedDB per oorsprong en per profiel is afgeschermd, krijg je een volledig lege database wanneer je wisselt van je werk-Chrome-profiel naar je persoonlijke Chrome-profiel, of van Chrome naar Firefox. Je oude opslag bestaat nog steeds — in het andere profiel — en kan worden hersteld door simpelweg terug te wisselen.

Een vijfde randgeval dat het vermelden waard is: sommige browserextensies die 'privacy'- of 'anti-tracking'-functies aanbieden, wissen periodiek sitedata op een vast schema. Als je geen van de vier bovenstaande oorzaken kunt aanwijzen, controleer dan je geïnstalleerde extensies op opslag-wisgedrag.

Om te proberen verloren emulatoropslag te herstellen, moet minstens één van de volgende voorwaarden van toepassing zijn. Geen van deze voorwaarden geldt universeel, dus lees ze elk aandachtig door voordat je er tijd in steekt.

1. Je hebt een .srm-bestand geëxporteerd vóór het verlies: Als je eerder de export- of downloadfunctie van de emulator hebt gebruikt om een .srm-bestand (SRAM-dump) op je apparaat op te slaan, staat dat bestand nog op je harde schijf. Door het opnieuw te importeren via de importfunctie van de emulator, herstel je je voortgang tot het punt waarop de export is gemaakt.
2. Je opslag staat in een ander browserprofiel: Open de profielwisselaar van je browser en zoek naar andere profielen. Navigeer in elk profiel naar de emulatorsite. Als je opslag verschijnt, exporteer het dan onmiddellijk als .srm-bestand en importeer het vervolgens in je primaire profiel.
3. Je hebt een cloud- of synchronisatieback-up: Als de emulator die je gebruikte is gekoppeld aan een cloudsynchronisatieservice, controleer dan de webinterface of app van die service op opgeslagen save states of SRAM-bestanden. Cloudsynchronisatie voor RGS is gepland voor een toekomstige versie — zie de siteblog voor de huidige beschikbaarheid.
4. Je gebruikt Android Chrome en hebt nog niet opnieuw opgestart: Chrome op Android slaat IndexedDB-schrijfacties tijdelijk in het geheugen op voordat ze naar schijf worden weggeschreven. In het korte tijdsvenster tussen een crash en een herstart kan een geforceerde synchronisatie — door de pagina opnieuw te bezoeken — de laatste sessie herstellen. Dit is een onbetrouwbaar randgeval, geen procedure om op te rekenen.

Er is geen methode om IndexedDB-gegevens rechtstreeks uit de browserinternals te halen zonder ontwikkelaarstools, en zelfs dan alleen als de database nog niet is verwijderd. In Chrome kun je DevTools openen (F12), naar Application → Storage → IndexedDB gaan en controleren of er nog een database voor de site bestaat. Als er vermeldingen zichtbaar zijn, zijn de eigen import- en exportfuncties van de emulator de juiste manier om ze op te halen — probeer de onbewerkte LevelDB-bestanden die Chrome intern gebruikt niet te bewerken, want dat kan andere browsergegevens beschadigen.

De harde waarheid over het herstellen van IndexedDB-speelopslag is dat zodra de databaserecord is verwijderd, er geen prullenbak, geen schaduwkopie en geen serverbackup is om op terug te vallen. Anders dan een bestand dat je van je bureaublad hebt verwijderd, gaat IndexedDB-data niet via de bestandsverwijderingspipeline van het besturingssysteem op een voor de gebruiker toegankelijke manier.

Herstel is concreet niet mogelijk in de volgende situaties: de optie 'Sitegegevens wissen' of een vergelijkbare optie is gebruikt in de browser; de sessie vond plaats in een privé- of incognitovenster; iOS Safari heeft de gegevens verwijderd wegens inactiviteit of opslagdruk; of een privacyextensie heeft de opslag volgens een schema gewist. In elk van deze vier gevallen zijn de onderliggende bytes overschreven of zijn ze nooit opgeslagen in permanente opslag.

Forensische schijfherstelprogramma's (zoals die welke worden gebruikt om bestanden te herstellen) helpen hier niet. Chrome, Firefox en Safari slaan IndexedDB allemaal op als compacte binaire indelingen (LevelDB in het geval van Chrome) die voortdurend worden herschreven tijdens normaal browsergebruik. Tegen de tijd dat je merkt dat de speelopslag ontbreekt, zijn de fysieke sectoren die de gegevens ooit bevatten vrijwel zeker al overschreven.

We zullen geen externe 'IndexedDB-herstel'-programma's aanbevelen die online circuleren. De exemplaren die we hebben onderzocht, scannen óf op generieke bestandssignaturen die niets te maken hebben met speelopslag, óf ze vereisen dat je browserinternals overdraagt aan een closed-source applicatie. Geen van beide benaderingen is betrouwbaar voor dit gebruik, en beide brengen reëel risico met zich mee.

De enige betrouwbare bescherming tegen een verdwenen browserspeelopslag is het bewaren van een kopie van je speelopslag buiten IndexedDB. Dat betekent regelmatig een .srm-bestand exporteren — bij voorkeur na elke betekenisvolle speelsessie — en het ergens opslaan waar het niet onderhevig is aan het wissen van browsergegevens.

• Exporteer .srm-bestanden regelmatig: Gebruik de exportfunctie van de emulator na elke sessie en sla het resulterende bestand op in een map op je harde schijf of in cloudopslag. Een .srm-bestand is klein (doorgaans 8 KB voor een Super Nintendo-spel met standaard SRAM) en downloadt binnen enkele seconden.
• Bewaar minimaal twee gedateerde kopieën: Bestanden een datumachtervoegsel geven (bijv. zelda-lttp-2024-11-03.srm) maakt het eenvoudig om terug te gaan naar een eerder herstelpunt als een speelopslag beschadigd raakt. Één recente back-up is beter dan geen; twee gedateerde back- ups geven je een herstelpunt zelfs als de meest recente export een probleem bevat.
• Speel nooit in incognitomodus voor spellen die je belangrijk vindt: Incognito is geschikt voor testen of eenmalige sessies. Het is niet geschikt voor een RPG-speelsessie van meerdere uren, omdat de browser alle opslag onvoorwaardelijk verwijdert zodra het venster wordt gesloten.
• Bezoek op iOS de emulatorsite minimaal één keer per 7 dagen: De WebKit-opslagverwijderingstimer van Apple wordt bij elk bezoek gereset. Regelmatige activiteit verkleint het risico dat iOS je gegevens wist — maar sluit het niet volledig uit.
• Houd de RGS-cloudsyncfunctie in de gaten: Zodra cloudsync beschikbaar is, kunnen speelopslagens server-side worden bewaard en gesynchroniseerd tussen apparaten. Totdat die functie er is, blijft .srm-export de enige cross-device back-upmethode op deze site. Bekijk de RGS-blog voor aankondigingen over de release.
• Vermijd browserextensies die sitegegevens wissen: Als je een privacyextensie gebruikt, controleer dan de instellingen op een eventueel automatisch schema voor het wissen van opslag en schakel die functie uit of voeg retrogamespace.com toe aan de allowlist.

Een platformspecifieke opmerking voor iOS-gebruikers: vanaf iOS 17 kun je een website als Progressive Web App aan je beginscherm toevoegen. Opslag die binnen een beginscherm-PWA wordt aangemaakt, bevindt zich in een apart quotacontainer ten opzichte van de standaardbrowser en valt niet onder dezelfde 7-daagse verwijderingsregel die van toepassing is op Safari-tabbladen. Als je regelmatig op iPhone of iPad speelt, is het toevoegen van de site aan je beginscherm een zinvolle structurele verbetering — maar geen volledige oplossing. Je moet nog steeds .srm-bestanden exporteren, omdat de PWA-container handmatig kan worden gewist of wanneer de app van het beginscherm wordt verwijderd.