You load a save state, notice you picked the wrong slot, and overwrite the clean one anyway. That is the exact moment a RetroArch save state backup stops being nerdy housekeeping and becomes the difference between a quick rollback and replaying three hours of Pokémon, Metroid, or a very cursed ROM hack.
RetroArch makes save states fast enough to be dangerous. One button can preserve a perfect boss kill. The same button can replace it with a state from 0.4 seconds before you fell into lava. If you play across devices, test cores, use shaders, or keep a library that spans decades of consoles, your saves deserve more than blind faith in Slot 0.
What a RetroArch save state backup actually protects
RetroArch handles two different kinds of progress file, and mixing them up is how people back up the wrong thing with great confidence.
Save files are the battery-style saves the original game would have written to a cartridge or memory card. Think `.srm`, `.sav`, memory-card images, or other core-specific files. They are usually your long-term progress: a JRPG party, a completed campaign, a career mode, the thing you would be properly annoyed to lose.
Save states are snapshots of the emulator at one precise instant. They can include the game’s memory, CPU state, timing, and more. They are brilliant for practising a speedrun section, surviving an old game with no checkpoints, or testing whether a patch has broken your modded run. They are also more fragile than normal saves. A state made with one core version, ROM revision, or emulator setting may not load cleanly after a major change.
Back up both, but do not treat them as identical. Your normal save is the long-haul insurance policy. Your save-state collection is the stack of quick-reload checkpoints you will absolutely need five minutes after deciding to “just see what happens”.
Find the folders before you start copying stuff
RetroArch can be configured to store files in different places, so there is no single universal folder worth memorising. The useful answer is inside RetroArch itself: open Settings, then Directory, and check Save Files and Save States.
Those two entries tell you where RetroArch is actually writing progress. If either setting is blank or points to a general RetroArch directory, files may be sitting alongside other configuration data. If you use a portable install, they may live beside the application folder. If you have changed directories per core or per content folder, things can get more spicy.
Before building a backup routine, make a test state in a game you can recognise. Close RetroArch properly, then inspect the configured save-state folder and confirm a newly modified file is there. Do the same with an in-game save where possible. This takes two minutes and prevents the classic backup achievement: preserving a tidy empty folder for six months.
Keep game names visible
A folder full of cryptic filenames is not much use during a panic restore. If your setup allows it, organise saves and states by content directory or use clear ROM filenames. Avoid repeatedly renaming ROMs after you have created a pile of states, because RetroArch often associates state filenames with the content name.
Also keep the ROM, core name, and any major patch version noted somewhere sensible for games you care about. A save state is not a magic cartridge. It has context.
The safest RetroArch save state backup routine
For a solo machine, a simple versioned copy is enough. The key word is versioned. A backup that silently replaces yesterday’s good state with today’s corrupted state is just a delayed disappointment.
A practical routine has four parts:
- Copy both the Save Files and Save States folders to storage outside the device.
- Keep multiple dated versions instead of one mirrored folder.
- Back up before updating RetroArch, changing cores, installing a major mod, or trying unfamiliar settings.
- Test a restore on a non-critical file, because a backup you have never restored is mostly decorative.
You do not need to archive every quick save forever. That way lies a digital loft full of 18 versions of the same corridor. Keep more versions around active projects, challenge runs, and games with unstable mods. For an old completed game, one clean in-game save and a handful of meaningful states are normally plenty.
If you prefer doing it manually, zip a dated copy of both folders after a session worth keeping. Use names that tell future-you what happened, such as `Castlevania-before-Dracula-clean` rather than `backup_final_FINAL2`. Future-you is tired, annoyed, and has no patience for your past naming choices.
Why ordinary cloud sync can make this worse
Putting your RetroArch folder in a cloud-sync service sounds sensible. Sometimes it is. But synchronisation is not version history, and it is definitely not a referee when two devices make different choices.
Imagine you play on a desktop, leave RetroArch open, then launch the same game on a handheld PC. Both installations write to the same state slot. A sync client sees two changed files and does what sync clients do: it guesses, creates a conflict copy, or lets the newest timestamp win. None of those options knows which state contains your 40-hour RPG run and which one is you pausing in a menu last Tuesday.
The risk rises when RetroArch is still open while files are being copied or synced. Save states can update at awkward moments, and a half-uploaded or conflicting file is not a restore point you want to discover during a power cut.
If you sync manually, close RetroArch first, let the copy finish, and only then open the game elsewhere. Treat one device as the active writer. It is less glamorous than pretending every machine is psychic, but it avoids the save-file equivalent of two people editing the same spreadsheet whilst shouting over Discord.
Version history beats a single backup
The real value of a proper backup system is not merely having a copy. It is having the copy from before the mistake.
Say a core update makes an older state refuse to load. Or a friend borrows your setup and saves over the wrong slot. Or a dodgy cheat leaves a game in a bizarre state where every NPC has forgotten your name and the music now sounds like a washing machine. You want to choose a point from yesterday, last week, or before the experiment - not discover that every backup dutifully copied the broken file.
That is why automatic history is useful for emulator players, especially anyone juggling multiple games and machines. If one of its supported emulator presets fits your setup, Checkpoint64 can watch the selected save folders, check for changes every 30 seconds, retain prior versions, and restore a chosen one without making you schedule a weekly folder-copy ritual. Free plan, actually free; more space can be a pay-once upgrade, not another monthly bill squatting in your bank statement.
There is still a trade-off. Automated backup does not make every state compatible forever. Keep your RetroArch version and core details stable for a game you are actively playing, and do not assume a state will survive arbitrary changes to cores, BIOS files, patches, or emulator settings.
Restore without turning one mistake into two
When a state goes bad, stop launching and saving. Every new action can overwrite evidence of the good version you are trying to recover.
Close RetroArch. Copy the chosen backup version back into the correct Save States folder, preserving the filename if you want RetroArch to see it in the expected slot. If the issue is the game’s actual progress rather than a quick snapshot, restore the matching file from the Save Files folder too. Then reopen RetroArch, load the same core and ROM setup, and test the restored state.
If it fails, do not immediately write a new state over it. Try an older version, confirm the core has not changed, and check whether you restored the save file when you meant to restore a state, or vice versa. Those are different drawers in the same filing cabinet.
Your best backup is the one made before the boss fight, the core update, the mod experiment, and the mate who says, “Don’t worry, I know which slot it is.” Make that copy while everything still works.