RE9 (Resident Evil Requiem) save slots not restoring correctly — encrypted restore only recovers autosave, decrypted restore recovers nothing #11

Open
opened 2026-06-28 05:05:29 -05:00 by ProGarion12 · 0 comments
ProGarion12 commented 2026-06-28 05:05:29 -05:00 (Migrated from git.etawen.dev)

Describe the bug

When attempting to restore RE9 save data (either my own backups or modified saves from a PC transfer), manual save slots do not restore correctly. Restoring an encrypted backup only recovers the autosave, while restoring a decrypted backup recovers nothing at all. This happens even when restoring a completely unmodified backup of the original PS5 save.

Not sure if this is expected behaviour for RE9 specifically or a broader issue, but wanted to report it with as much detail as possible.

Game details

  • Game: Resident Evil Requiem (RE9)
  • PS5 Title ID: PPSA31246 (European version)
  • PS5 game version: 1.200.000

PS5 save file structure

On PS5, RE9 save slots are stored as folders within Garlic Save Manager, each containing a data0XXSlot.bin and a sce_sys subfolder. The slot mapping is as follows:

  • Autosave → sdimg_SAVESERVICE-LINE-0-1Slot / data001Slot.bin
  • Manual Slot 1 → sdimg_SAVESERVICE-LINE-0-10Slot / data010Slot.bin
  • Manual Slot 2 → sdimg_SAVESERVICE-LINE-0-11Slot / data011Slot.bin
  • Manual Slot 3 → sdimg_SAVESERVICE-LINE-0-12Slot / data012Slot.bin

There are also two profile-related saves:

  • sdimg_SAVESERVICE-LINE-0--1
  • sdimg_SAVESERVICE-LINE-0-0

For reference, on PC the .bin files sit directly in the save directory (win64_save) with no additional folder structure, which is a notable difference from the PS5 layout.

Steps to reproduce

  1. Back up RE9 save data via Garlic Save Manager
  2. Delete the existing save data
  3. Attempt to restore the backup (tested both encrypted and decrypted)

Results:

  • Restoring decrypted backup → nothing restores, all slots appear empty in-game
  • Restoring encrypted backup → only the autosave (data001Slot.bin) carries over; manual slots 1–3 (data010Slot.bin, data011Slot.bin, data012Slot.bin) are all missing in-game, despite the correct folder and file structure being visible in Garlic

Additional testing — ruling out modified saves as the cause

This issue was originally discovered while attempting to transfer a PC save to PS5. However, through further testing I was able to confirm the issue is not related to any save modification:

  • Replacing just the .bin file inside a PS5 slot folder (rather than the full folder) wipes the slot entirely in-game, leaving a blank save — this happened with both the modified PC save and an unmodified PS5 backup
  • Restoring the full sdimg_SAVESERVICE-LINE-0-10Slot folder (unmodified, original PS5 backup) via Garlic also failed to restore the save correctly, confirming the issue is reproducible with completely untouched saves

Expected behaviour

Restoring a backup should recover all save slots, including manual saves, as they were at the time of the backup.

Question

Is this expected behaviour for RE9, or is there a known issue with how Garlic Save Manager handles this game's save structure? Any guidance would be appreciated.

**Describe the bug** When attempting to restore RE9 save data (either my own backups or modified saves from a PC transfer), manual save slots do not restore correctly. Restoring an encrypted backup only recovers the autosave, while restoring a decrypted backup recovers nothing at all. This happens even when restoring a completely unmodified backup of the original PS5 save. Not sure if this is expected behaviour for RE9 specifically or a broader issue, but wanted to report it with as much detail as possible. **Game details** - Game: Resident Evil Requiem (RE9) - PS5 Title ID: PPSA31246 (European version) - PS5 game version: 1.200.000 **PS5 save file structure** On PS5, RE9 save slots are stored as folders within Garlic Save Manager, each containing a `data0XXSlot.bin` and a `sce_sys` subfolder. The slot mapping is as follows: - Autosave → `sdimg_SAVESERVICE-LINE-0-1Slot` / `data001Slot.bin` - Manual Slot 1 → `sdimg_SAVESERVICE-LINE-0-10Slot` / `data010Slot.bin` - Manual Slot 2 → `sdimg_SAVESERVICE-LINE-0-11Slot` / `data011Slot.bin` - Manual Slot 3 → `sdimg_SAVESERVICE-LINE-0-12Slot` / `data012Slot.bin` There are also two profile-related saves: - `sdimg_SAVESERVICE-LINE-0--1` - `sdimg_SAVESERVICE-LINE-0-0` For reference, on PC the `.bin` files sit directly in the save directory (`win64_save`) with no additional folder structure, which is a notable difference from the PS5 layout. **Steps to reproduce** 1. Back up RE9 save data via Garlic Save Manager 2. Delete the existing save data 3. Attempt to restore the backup (tested both encrypted and decrypted) **Results:** - Restoring **decrypted** backup → nothing restores, all slots appear empty in-game - Restoring **encrypted** backup → only the autosave (`data001Slot.bin`) carries over; manual slots 1–3 (`data010Slot.bin`, `data011Slot.bin`, `data012Slot.bin`) are all missing in-game, despite the correct folder and file structure being visible in Garlic **Additional testing — ruling out modified saves as the cause** This issue was originally discovered while attempting to transfer a PC save to PS5. However, through further testing I was able to confirm the issue is not related to any save modification: - Replacing just the `.bin` file inside a PS5 slot folder (rather than the full folder) wipes the slot entirely in-game, leaving a blank save — this happened with both the modified PC save and an unmodified PS5 backup - Restoring the full `sdimg_SAVESERVICE-LINE-0-10Slot` folder (unmodified, original PS5 backup) via Garlic also failed to restore the save correctly, confirming the issue is reproducible with completely untouched saves **Expected behaviour** Restoring a backup should recover all save slots, including manual saves, as they were at the time of the backup. **Question** Is this expected behaviour for RE9, or is there a known issue with how Garlic Save Manager handles this game's save structure? Any guidance would be appreciated.
Sign in to join this conversation.
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
git-etawen-dev-earthonion/garlic-savemgr#11
No description provided.