Spielstände vom Android-Handheld automatisch aufs NAS sichern (Syncthing)

Ein kaputter Spielstand fühlt sich schlimmer an als ein verlorenes Spiel. Das Spiel kannst du neu dumpen, also wieder von deinem eigenen Modul auslesen. Deinen Fortschritt nicht. Mir ist genau das mit einem Pokémon-Spielstand auf meinem Android-Handheld passiert: 5 von 14 Abschnitten der Save-Datei waren kaputt. Gerettet hat mich nur ein Backup, das zufällig noch auf meinem 3DS lag. Seitdem sichert mein Handheld jeden Spielstand automatisch aufs NAS, mit einem Jahr Versionen. In diesem Guide richtest du das gleiche Setup mit Syncthing ein, und zwar so, dass das Backup nie etwas auf deinem Handheld überschreiben kann.

Kurz erklärt

• Syncthing: ein kostenloses Open-Source-Tool, das Ordner direkt zwischen deinen Geräten abgleicht. Es läuft ohne Cloud, die Daten gehen verschlüsselt von Gerät zu Gerät.
• Send Only und Receive Only: zwei Ordner-Modi. Das Handheld schickt nur (Send Only) und nimmt keine Änderungen an. Der Server empfängt nur (Receive Only). So fließen Daten in genau eine Richtung.
• Versioning: Bevor Syncthing auf dem Server eine Datei ersetzt oder löscht, legt es die alte Fassung in einen versteckten Ordner .stversions. Kommt ein kaputter Save an, ist der gute von vorher noch da.
• Die Android/data-Sperre: Seit Android 11 darf keine App in die privaten Ordner anderer Apps unter Android/data schauen, auch Syncthing nicht. Emulatoren, die dort speichern, musst du umstellen.
• Für wen: Du hast ein Android-Handheld wie AYN Thor*, Retroid Pocket* oder AYN Odin* und einen NAS oder Home-Server, auf dem Docker läuft.

So sieht das Setup aus

Auf dem Handheld legst du drei Ordner als Send Only an. Auf dem Server landen sie als Receive Only in einem eigenen Backup-Ordner. Mein Beispiel ist ein AYN Thor mit Android 13, das Prinzip ist auf jedem Android-Handheld gleich.

Ordner auf dem Handheld (Send Only)	Ordner auf dem NAS (Receive Only)	Was gesichert wird
/sdcard/RetroArch	Backups/handheld-saves/RetroArch	nur saves/ und states/
/sdcard/Azahar	Backups/handheld-saves/Azahar	alles außer installierten Spielen, Logs, Shadern, Cheats und GPU-Treibern
/sdcard/Saves	Backups/handheld-saves/Saves	alles (Sammelordner für andere Emulatoren)

/sdcard ist der interne Speicher, den du auch im Dateimanager siehst. Nutzt du einen anderen Emulator als RetroArch oder Azahar, passt du die Tabelle einfach an deine Ordner an.

Du nutzt schon RomM für deine Spielesammlung? Das kollidiert nicht. RomM speichert nur die Saves aus seinem eigenen Browser-Player, und zwar in seinem assets-Ordner. Syncthing schreibt in einen komplett getrennten Backup-Ordner. Weil das Handheld nur sendet, kann von dort aus auch nie ein Save auf dem Handheld überschrieben werden. Bei mir läuft Syncthing als kleiner Container direkt neben RomM auf einem Minisforum MS-A2*, die Backups landen auf einem UniFi UNAS Pro*. RomM brauchst du für diesen Guide aber nicht.

Das brauchst du

• Ein Android-Handheld mit Android 11 oder neuer (getestet mit AYN Thor, Android 13)
• Einen NAS oder Home-Server mit Docker und dem Compose-Plugin. Docker startet Programme in abgeschotteten Containern, Compose beschreibt so einen Container in einer kleinen Textdatei. docker compose version sollte eine Version ausgeben. Wie du so einen Server aufsetzt, steht in meinem Guide Homelab starten.
• Einen Ordner auf dem NAS für die Backups. Läuft Docker auf einem eigenen Server, bindest du die NAS-Freigabe dort ein (z. B. per SMB oder NFS unter /mnt/nas). Läuft Docker direkt auf dem NAS, nimmst du einfach den lokalen Pfad des Ordners, auf einer Synology* z. B. /volume1/....
• Terminal-Zugriff auf den Server per SSH (oder eine Docker-Weboberfläche wie Portainer, siehe Schritt 1)
• Handheld und Server im selben Heimnetz für die Einrichtung
• Einen Dateimanager auf dem Handheld, der versteckte Dateien zeigen und Textdateien bearbeiten kann, z. B. Material Files
• Optional: einen PC mit ADB (Android Debug Bridge, das Kommandozeilen-Tool, mit dem du ein Android-Gerät per USB steuerst). ADB steckt in den Platform Tools von Google. Auf dem Handheld schaltest du dafür USB-Debugging ein: in den Einstellungen unter „Über das Gerät“ sieben Mal auf die Build-Nummer tippen, dann in den Entwickleroptionen „USB-Debugging“ aktivieren. Du brauchst ADB nur für die Varianten per Befehl.

Die Befehle und Einstellungen beziehen sich auf Syncthing 2.1 und Syncthing-Fork 2.1, die zum Zeitpunkt des Schreibens aktuellen Versionen.

Schritt 1: Syncthing auf dem Server mit Docker Compose

Leg auf dem Server einen Ordner für die Konfiguration an. Wichtig: Der gehört auf die lokale Platte des Servers, nicht auf die Netzwerkfreigabe. Syncthing speichert dort seine Datenbank, und Datenbanken über SMB oder NFS sind eine bekannte Quelle für Fehler. Alle Pfade unten sind Beispiele. Ersetz /mnt/nas/Backups überall durch den Pfad zu deinem Backup-Ordner.

sudo mkdir -p /opt/syncthing/data
sudo mkdir -p /mnt/nas/Backups/handheld-saves
cd /opt/syncthing
sudo nano docker-compose.yml

In die docker-compose.yml kommt:

services:
  syncthing:
    image: syncthing/syncthing:2
    container_name: syncthing
    hostname: nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - STGUIADDRESS=127.0.0.1:8384
    volumes:
      - /opt/syncthing/data:/var/syncthing
      - /mnt/nas/Backups/handheld-saves:/backups
    network_mode: host
    restart: unless-stopped

Speichern und schließen kannst du in nano mit Strg+O, Enter und Strg+X. Was die einzelnen Teile machen:

• syncthing/syncthing ist das offizielle Image des Syncthing-Projekts. Der Tag 2 bleibt auf der Major-Version 2 und holt dir trotzdem Bugfixes.
• PUID und PGID sind die User- und Gruppen-ID, mit denen Syncthing im Container läuft. Default ist 1000. Syncthing muss in den Backup-Ordner schreiben dürfen. Wie das geht, steht direkt unter dieser Liste.
• network_mode: host empfiehlt die offizielle Doku. Im normalen Docker-Netz sieht Syncthing nur eine interne Container-Adresse und findet dein Handheld im Heimnetz schlechter. Im Host-Modus nutzt Syncthing direkt die Ports des Servers: 22000/tcp und 22000/udp für die Übertragung, 21027/udp zum Finden von Geräten im LAN.
• STGUIADDRESS=127.0.0.1:8384 bindet das Web-UI nur an den Server selbst. Aus dem Netz kommt niemand an die Oberfläche, Port 8384 musst du nirgends freigeben.
• /var/syncthing ist das Home-Verzeichnis im Container. Darin liegen unter config die Konfiguration und die Datenbank, deshalb zeigt es auf die lokale Platte.
• /backups ist das Ziel auf dem NAS. Im Container heißt der Ordner einfach /backups, das brauchst du gleich in Schritt 3.

Jetzt die Rechte für den Backup-Ordner. Schau nach, wem er gehört:

ls -ln /mnt/nas/Backups

Die zwei Zahlen nach den Rechten in der Zeile handheld-saves sind User-ID und Gruppen-ID. Steht dort 0 0, gehört der Ordner root, weil du ihn mit sudo angelegt hast. Dann übergib ihn an den Syncthing-User:

sudo chown 1000:1000 /mnt/nas/Backups/handheld-saves

Stehen dort andere Zahlen, z. B. weil dein NAS die Rechte vorgibt, trag genau diese Zahlen als PUID und PGID in die Compose-Datei ein. Bei einer SMB-Freigabe legen die Mount-Optionen uid= und gid= fest, wem die Dateien gehören. chown funktioniert dort meist nicht.

Läuft auf dem Server eine Firewall wie ufw, gib die drei Syncthing-Ports fürs Heimnetz frei. Ersetz 192.168.1.0/24 durch dein Netz:

sudo ufw allow from 192.168.1.0/24 to any port 22000
sudo ufw allow from 192.168.1.0/24 to any port 21027 proto udp

Starten, Logs prüfen und testen, ob Syncthing ins Backup schreiben darf:

cd /opt/syncthing
sudo docker compose up -d
sudo docker compose logs -f syncthing

# Schreibtest mit der PUID/PGID aus der Compose-Datei
sudo docker exec -u 1000:1000 syncthing touch /backups/schreibtest
sudo docker exec -u 1000:1000 syncthing rm /backups/schreibtest

In den Logs sollte eine Zeile mit 127.0.0.1:8384 auftauchen. Mit Strg+C beendest du die Log-Anzeige, der Container läuft weiter. Meldet der Schreibtest Permission denied, stimmen PUID/PGID und Ordnerrechte noch nicht überein.

Weil das Web-UI nur lokal lauscht, öffnest du es über einen SSH-Tunnel. Der leitet Port 8384 vom Server über deine SSH-Verbindung auf deinen PC um. Auf deinem PC:

ssh -L 8384:127.0.0.1:8384 dein-user@dein-server

Lass das Fenster offen und ruf im Browser http://localhost:8384 auf. Syncthing warnt beim ersten Start, dass kein Passwort gesetzt ist. Setz unter Aktionen → Einstellungen → GUI einen Benutzer und ein Passwort, auch wenn das UI nur lokal erreichbar ist.

Du verwaltest Docker über eine Weboberfläche wie Portainer oder den Synology Container Manager statt per Terminal? Dann legst du die Compose-Datei dort als Stack bzw. Projekt an. Für das Web-UI trägst du statt 127.0.0.1 die LAN-IP des Servers ein (seine Adresse im Heimnetz), z. B. STGUIADDRESS=192.168.1.10:8384. Das UI ist dann im ganzen Heimnetz erreichbar. In dem Fall ist das Passwort Pflicht, und ins Internet weiterleiten solltest du den Port nie.

Schritt 2: Syncthing-Fork auf dem Handheld

Die offizielle Syncthing-App für Android wurde 2024 eingestellt. Der Nachfolger, den die meisten nutzen, heißt Syncthing-Fork. Das Projekt hat inzwischen den Maintainer gewechselt und wird jetzt unter researchxxl/syncthing-android auf GitHub weiterentwickelt. Du bekommst es hier:

• über F-Droid (Paketname com.github.catfriend1.syncthingfork)
• als APK von den GitHub-Releases, gleicher Paketname. Mit Obtainium (einer App, die Updates direkt von GitHub holt) kannst du diese Releases verfolgen lassen.

Im Google Play Store gibt es Syncthing-Fork auch, dort aber unter dem älteren Paketnamen com.github.catfriend1.syncthingandroid. Die ADB-Befehle unten nutzen den Namen der F-Droid- und GitHub-Version. Hast du die App aus dem Play Store, ersetz den Paketnamen entsprechend. Weil die Paketnamen verschieden sind, geht ein Wechsel zwischen den Quellen nur über eine Neuinstallation.

Ich nenne die Menüpunkte so, wie sie in der englischen App heißen. Steht dein Handheld auf Deutsch, steht die deutsche Bezeichnung in Klammern dahinter. Beim ersten Start fragt Syncthing-Fork nach ein paar Rechten. Zwei davon brauchst du wirklich.

Zugriff auf alle Dateien

Ohne dieses Recht sieht Syncthing deine Emulator-Ordner nicht. Tipp im Einrichtungsdialog auf Grant storage permission („Speicherzugriff gewähren“). Android öffnet dann die Systemseite, auf der du den Schalter für den Zugriff auf alle Dateien („Allow access to manage all files“) für Syncthing-Fork einschaltest. Später findest du ihn in den Android-Einstellungen unter Apps und dem Punkt für speziellen App-Zugriff. Wie das Menü genau heißt, hängt vom Hersteller ab.

Klappt der Schalter nicht, geht es auch per ADB vom PC aus:

adb shell appops set --uid com.github.catfriend1.syncthingfork MANAGE_EXTERNAL_STORAGE allow
adb shell appops get --uid com.github.catfriend1.syncthingfork MANAGE_EXTERNAL_STORAGE

In der Ausgabe des zweiten Befehls sollte allow stehen. Bist du unsicher, welchen Paketnamen deine App hat, prüf ihn vorher mit adb shell pm list packages | grep -i sync.

Akku-Optimierung ausschalten

Android beendet Apps im Hintergrund gern, um Akku zu sparen. Dann synct Syncthing irgendwann einfach nicht mehr. Im Einrichtungsdialog gibt es dafür die Seite Battery Optimization („Akku-Optimierung“), nimm Syncthing-Fork dort aus. Die Standortberechtigung kannst du überspringen. Die brauchst du nur, wenn Syncthing nur in bestimmten WLANs laufen soll.

Schritt 3: Geräte koppeln und Ordner anlegen

Handheld und Server koppeln

1. Im Web-UI des Servers: Aktionen → Eigene Kennung. Du siehst die Device-ID als Text und als QR-Code. Die Device-ID ist der eindeutige Name eines Syncthing-Geräts.
2. In Syncthing-Fork auf dem Handheld: Tab Devices („Geräte“), dann + (Add Device, „Gerät hinzufügen“). Scann den QR-Code oder tipp die ID ab und gib dem Gerät einen Namen wie „NAS“.
3. Nach ein paar Sekunden meldet das Web-UI des Servers, dass ein neues Gerät verbinden will. Klick auf Gerät hinzufügen und speichere.

Finden sich die zwei nicht, trag die Adresse des Servers von Hand ein. Öffne in Syncthing-Fork das Gerät und ersetz unter Addresses („Adressen“) den Eintrag dynamic durch tcp://192.168.1.10:22000 mit der LAN-IP deines Servers.

Erst Ignore-Regeln, dann syncen

Ignore-Regeln sagen Syncthing, welche Dateien es auslassen soll. Sie stehen in einer Textdatei .stignore im jeweiligen Ordner. Im Azahar-Ordner liegen neben den Saves auch installierte 3DS-Spiele. Bei mir waren das 1,9 GB. Fängt Syncthing an zu senden, bevor die Regeln stehen, landet all das auf dem NAS. Die Regeln für jeden Ordner findest du weiter unten. Bring sie auf einem von zwei Wegen rein, bevor der erste Sync startet.

Weg A (am sichersten): .stignore vor dem Hinzufügen anlegen. Syncthing liest eine vorhandene .stignore beim ersten Scan und überschreibt sie nicht. Leg im Dateimanager im Ordner, z. B. /sdcard/RetroArch, eine neue Datei mit dem Namen .stignore an (mit Punkt am Anfang, ohne .txt), füg die Regeln ein und speichere. Viele Dateimanager blenden Dateien mit Punkt am Anfang aus, schalte also „versteckte Dateien anzeigen“ ein. Alternativ speicherst du die Regeln auf dem PC als Textdatei und schiebst sie per ADB rüber:

adb push stignore-retroarch.txt /sdcard/RetroArch/.stignore
adb push stignore-azahar.txt /sdcard/Azahar/.stignore

Nutzt du Git Bash unter Windows, setz MSYS_NO_PATHCONV=1 vor den Befehl. Sonst biegt Git Bash den Pfad /sdcard/... in einen Windows-Pfad um.

Weg B: Ordner pausiert anlegen. Im Bildschirm zum Anlegen eines Ordners gibt es den Schalter Pause Folder („Ordner pausieren“). Schalte ihn ein, bevor du auf Create („Erstellen“) tippst. Das Feld Ignore Patterns („Ausschlussmuster“) erscheint erst, wenn der Ordner gespeichert ist. Öffne den Ordner also danach noch einmal, trag die Regeln ein, speichere und heb erst dann die Pause auf.

Ordner 1: RetroArch

Prüf zuerst in RetroArch, wo deine Saves liegen: Settings → Directory → Save Files und Save States. Bei mir zeigen beide in /sdcard/RetroArch (saves und states). Zeigt der Pfad bei dir auf Android/data, stell ihn wie in Schritt 5 auf einen Ordner im normalen Speicher um. Liegt er an einer anderen Stelle, nimm diesen Ordner statt /sdcard/RetroArch.

Dann in Syncthing-Fork: Tab Folders („Ordner“), + (Add Folder, „Ordner hinzufügen“). Wähle unter Directory („Verzeichnis“) deinen RetroArch-Ordner. Gib eine eindeutige Folder ID („Ordner-ID“) wie handheld-retroarch ein, das ist der interne Name, über den beide Seiten den Ordner zuordnen. Stell Folder Type („Ordnertyp“) auf Send Only („Nur senden“) und aktivier das Teilen mit deinem NAS.

Die Ignore-Regeln für RetroArch sichern nur Saves und Save States:

// Nur Spielstände sichern, alles andere ignorieren
!/saves
!/states
*

So liest Syncthing diese Regeln:

• Syncthing prüft von oben nach unten, und die erste passende Zeile entscheidet. Die Ausnahmen müssen deshalb über dem * stehen. Steht * oben, ist alles ignoriert, und die Ausnahmen darunter greifen nie.
• Ein ! am Anfang heißt „nicht ignorieren“.
• Ein / am Anfang heißt „nur direkt im Hauptordner“. !/saves meint also RetroArch/saves samt Inhalt, aber keinen anderen Ordner namens saves irgendwo tiefer.
• Zeilen mit // am Anfang sind Kommentare.

Ordner 2: Azahar (3DS)

Azahar legt alles in einen User-Ordner, den du beim ersten Start der App gewählt hast. Bei mir ist das /sdcard/Azahar. Die 3DS-Saves liegen darin unter sdmc/Nintendo 3DS/.../title/<Gruppe>/<Titel-ID>/data. Installierte Spiele, Updates und DLCs liegen direkt daneben im Ordner content. Den willst du nicht sichern, weil du ihn jederzeit aus deinem eigenen Dump neu installieren kannst. Leg den Ordner wie bei RetroArch an (Folder ID z. B. handheld-azahar, Send Only, Weg A oder B) mit diesen Regeln:

// Installierte Spiele, Updates und DLCs (neu installierbar)
title/*/*/content
// Kram, den Azahar selbst neu erzeugt
/log
/shaders
/cheats
/gpu_drivers

title/*/*/content hat keinen Schrägstrich am Anfang und greift deshalb in jeder Tiefe. Ein * steht für genau eine Ordnerebene, hier die zwei Ebenen der Titel-ID. Die Saves in sdmc, nand, sysdata, config und states bleiben im Backup. Der Effekt bei mir: Der Azahar-Ordner war auf dem NAS nur 760 KB groß statt der 1,9 GB, die die Spiel-Installation allein ausmacht.

Ordner 3: Saves (Sammelordner)

Leg mit dem Dateimanager den Ordner /sdcard/Saves an und darin einen Unterordner pro System, z. B. nds. Hier landen alle Emulatoren, die sonst unter Android/data speichern würden (dazu gleich in Schritt 5). Diesen Ordner fügst du ohne Ignore-Regeln als Send Only hinzu, Folder ID z. B. handheld-saves.

Ordner auf dem Server annehmen

Sobald du einen Ordner auf dem Handheld freigibst, fragt das Web-UI des Servers, ob du ihn hinzufügen willst. Klick auf Hinzufügen und stell im Dialog ein:

• Allgemein → Ordnerpfad: Syncthing schlägt einen Pfad unter /var/syncthing vor, also auf der lokalen Platte. Ersetz ihn durch /backups/RetroArch (bzw. /backups/Azahar und /backups/Saves). Das ist der Pfad im Container, auf dem NAS landet er in deinem Backup-Ordner.
• Erweitert → Ordnertyp: Nur empfangen (Receive Only)
• Dateiversionierung: siehe Schritt 4, am besten direkt im selben Dialog

Die Ignore-Regeln brauchst du auf dem Server nicht. Was das Handheld ignoriert, schickt es gar nicht erst los.

Schritt 4: Versioning einschalten

Ohne Versioning ist das nur eine Kopie. Wird der Save auf dem Handheld kaputt, ist er Sekunden später auch auf dem NAS kaputt. Mit Versioning liegt die gute Fassung von vorher noch in .stversions.

Öffne auf dem Server jeden der drei Ordner (Bearbeiten), Tab Dateiversionierung, und wähle Stufenweise Dateiversionierung (Staggered). Als Höchstalter trägst du 365 Tage ein. Syncthing behält dann laut Doku:

• in der ersten Stunde eine Version alle 30 Sekunden,
• am ersten Tag eine Version pro Stunde,
• in den ersten 30 Tagen eine Version pro Tag,
• danach bis zum Höchstalter eine Version pro Woche.

Ältere Versionen löscht Syncthing selbst. Für Saves passt das gut: Du kommst an den Stand von heute Mittag, von letzter Woche und von vor drei Monaten. Platz kostet das kaum, Save-Dateien sind meist nur ein paar KB groß. In der Konfigurationsdatei heißt die Einstellung übrigens maxAge und steht dort in Sekunden (31536000 = 365 Tage). Im Web-UI gibst du Tage ein.

Die alten Versionen liegen in .stversions im jeweiligen Backup-Ordner, mit Zeitstempel im Namen, z. B. Pokemon Lazarus~20261023-153012.srm. Syncthing versioniert nur Dateien, die es wegen einer Änderung von einem anderen Gerät ersetzt oder löscht. Auf dem Server kommt jede Änderung vom Handheld, also greift das bei jedem Save.

Schritt 5: Emulatoren, die in Android/data speichern

Viele Emulatoren speichern ihre Saves in ihrem privaten App-Ordner unter Android/data/<paketname>. Seit Android 11 darf keine andere App dort hinein, auch nicht mit dem Zugriff auf alle Dateien. Syncthing sieht diese Saves also nie.

Die Regel für jeden Emulator: Such in den Einstellungen nach dem Speicherort für Saves (oft „Save directory“, „Save path“ oder „Memory cards“) und stell ihn auf einen Unterordner von /sdcard/Saves. Kopier vorhandene Saves vorher mit dem Dateimanager rüber, solange der Emulator geschlossen ist.

Beispiel: DS mit WatermelonDS (früher MelonDualDS)

WatermelonDS ist ein Android-Port des DS-Emulators melonDS, gebaut für Dual-Screen-Handhelds wie den Thor. Bis Version 0.7.0 (August 2026) hieß er MelonDualDS, du bekommst ihn über die GitHub-Releases. Hast du noch eine ältere Version, heißt die App bei dir MelonDualDS. Die Menüpunkte sind dieselben:

1. Settings → Save Files
2. Save next to ROM file ausschalten
3. Save file directory auf /sdcard/Saves/nds setzen
4. vorhandene .sav-Dateien in diesen Ordner kopieren

Bei mir zeigte Pokémon SoulSilver danach wie gewohnt „Weiter“ mit meinem alten Spielstand. Kurioses Detail: „Save next to ROM“ war bei mir eingeschaltet, trotzdem landeten die Saves in Android/data. Der Emulator durfte nicht in den ROM-Ordner schreiben, wenn er aus dem Frontend heraus gestartet wurde (der Startoberfläche für deine Spiele, bei mir Cocoon). Schau also mit dem Dateimanager nach, wo die Datei wirklich liegt, egal was die Einstellung sagt.

Die Ausnahme: DuckStation (PS1)

DuckStation speichert die Memory Cards unter Android/data. In der Android-Version habe ich keine Option gefunden, sie woanders hinzulegen, obwohl ich alle Einstellungs-Tabs durchgeschaut habe. Die Dateien sind dort sogar so geschützt, dass man sie per ADB nicht kopieren kann. Automatisch sichern lassen sich PS1-Saves damit nicht.

Ich bleibe trotzdem bei DuckStation. Für mich ist es genauer als RetroArch, läuft super und ist einfacher zu bedienen. Den Tausch gegen ein automatisches Backup mache ich bewusst nicht. Wenn es dir genauso geht: DuckStation hat im Seitenmenü einen Punkt „Transfer Data“, über den sich Saves und Einstellungen von Hand als ZIP exportieren lassen sollen. Den Export habe ich selbst noch nicht komplett durchgespielt. Prüf also, ob am Ende wirklich eine ZIP-Datei mit deinen Memory Cards da ist, und lies jeden Dialog genau, denn derselbe Punkt kann auch importieren und damit überschreiben.

So prüfst du, ob es klappt

• Im Web-UI des Servers steht bei allen drei Ordnern Aktuell (Up to Date). Das Handheld steht unter Geräte als verbunden.
• Vergleich Anzahl und Größe: Unter Lokaler Status zeigt der Server Dateien und Größe. Der Azahar-Ordner sollte klein sein, ein paar hundert KB statt Gigabytes. Ist er riesig, greifen deine Ignore-Regeln nicht.
• Vergleich die Prüfsummen (md5, eine Art Fingerabdruck der Datei) auf beiden Seiten, siehe Befehle unten. RetroArch sortiert Saves standardmäßig in einen Unterordner pro Core (das Emulator-Modul, z. B. mGBA). Hast du das abgeschaltet, lass im ersten Befehl das */ weg. Bei mir waren beim ersten Sync alle 19 Save-Dateien byte-identisch.
• Teste eine Änderung: Spiel kurz, speichere im Spiel und schließ den Emulator. Kurz danach sollte die Datei auf dem NAS ein neues Änderungsdatum haben. Wie schnell, hängt von deinen Run Conditions („Ausführungsbedingungen“) in Syncthing-Fork ab, also den Regeln, wann die App syncen darf.
• Schau in .stversions: Nach der Änderung liegt dort die vorherige Fassung mit Zeitstempel im Namen. Der Ordner beginnt mit einem Punkt und ist deshalb versteckt, der dritte Befehl unten listet ihn trotzdem auf.

# Auf dem PC, Prüfsummen auf dem Handheld
adb shell "md5sum /sdcard/RetroArch/saves/*/*.srm"

# Auf dem Server, Prüfsummen im Backup
find /mnt/nas/Backups/handheld-saves/RetroArch/saves -type f -name '*.srm' -exec md5sum {} +

# Auf dem Server, alte Versionen ansehen
find /mnt/nas/Backups/handheld-saves/RetroArch/.stversions -type f

Einen Spielstand wiederherstellen

So holst du einen alten Stand zurück, wenn ein Save kaputt ist:

1. Emulator komplett schließen. RetroArch speichert die .srm standardmäßig alle 10 Sekunden automatisch. Läuft das Spiel noch, überschreibt es deinen wiederhergestellten Save sofort wieder.
2. Such in .stversions die passende Version raus und kopier sie auf deinen PC, z. B. über die Netzwerkfreigabe deines NAS im Explorer oder mit scp. Windows zeigt Ordner mit Punkt am Anfang auf einer Freigabe oft nur, wenn du „Ausgeblendete Elemente“ einschaltest. Bearbeite nichts im Backup-Ordner selbst, das ist ein Receive-Only-Ordner.
3. Entferne den Zeitstempel aus dem Namen: Pokemon Lazarus~20261023-153012.srm wird wieder Pokemon Lazarus.srm.
4. Benenne den kaputten Save auf dem Handheld um, statt ihn zu löschen, z. B. in Pokemon Lazarus.srm.corrupted-2026-10-23. So hast du ihn noch, falls die Wiederherstellung nicht klappt.
5. Kopier die alte Version an den Originalplatz, per USB-Dateiübertragung, Dateimanager oder adb push, z. B. adb push "Pokemon Lazarus.srm" /sdcard/RetroArch/saves/mGBA/. Prüf danach Größe und md5.
6. Erst jetzt den Emulator starten und das Spiel laden.

Das Handheld schickt den wiederhergestellten Save danach wieder aufs NAS. Das ist gewollt: Der Server legt den bisherigen Stand dabei in .stversions, es geht also nichts verloren.

Typische Fehler

• Saves tauschen, während das Spiel läuft: RetroArch schreibt die .srm alle 10 Sekunden neu. Immer erst schließen.
• Saves in Android/data: Syncthing sieht sie nicht, egal welche Rechte du gibst. Schau mit einem Dateimanager nach, wo jeder Emulator wirklich speichert.
• Ignore-Regeln in falscher Reihenfolge: * gehört nach unten. Steht es oben, wird gar nichts gesichert.
• Ordner ohne Ignore-Regeln gestartet: Dann schickt das Handheld zuerst alles los, bei Azahar inklusive installierter Spiele. Nimm Weg A oder B aus Schritt 3.
• Keine Schreibrechte im Backup-Ordner: Der Ordner auf dem Server bleibt leer und zeigt einen Fehler. Prüf PUID/PGID und den Schreibtest aus Schritt 1.
• Send Only heißt Einbahnstraße: Nichts vom Server überschreibt je einen Save auf dem Handheld. Umgekehrt landet aber auch ein kaputter oder gelöschter Save auf dem NAS. Genau dafür ist das Versioning da, schalte es nicht aus.
• Dateien im Backup-Ordner bearbeitet: Ein Receive-Only-Ordner meldet das als lokale Änderung. Der Button Lokale Änderungen zurücksetzen löscht hinzugefügte Dateien wieder. Arbeite immer mit Kopien außerhalb des Ordners.
• 0-Byte-Dateien: Ein abgebrochenes adb pull hinterlässt auf dem PC eine leere Datei, die wie ein Backup aussieht. Prüf bei jeder Kopie Größe oder Prüfsumme.
• Datenbank auf der Netzwerkfreigabe: Der Config-Ordner /var/syncthing gehört auf die lokale Platte des Servers, nur das Backup-Ziel auf den NAS.

Wichtig: nur eigene Dumps

Dieser Guide sichert deine Spielstände, keine Spiele. Nutze Emulatoren nur mit Spielen und BIOS-Dateien, die du selbst von deinen eigenen Modulen, Discs oder Konsolen gedumpt hast. Lade keine ROMs, BIOS-Dateien oder Keys aus dem Netz.

FAQ

Klappt das Backup auch unterwegs?

Ja, solange Syncthing-Fork laut deinen Run Conditions laufen darf. Syncthing findet deinen Server standardmäßig auch über das Internet: Die globalen Discovery-Server sagen dem Handheld, unter welcher Adresse der Server gerade erreichbar ist. Klappt keine direkte Verbindung, springen Relays ein, öffentliche Vermittlungsserver. Die Daten bleiben dabei Ende-zu-Ende verschlüsselt, das Relay sieht nur verschlüsselten Traffic. Nutzt du Tailscale (ein privates VPN zwischen deinen Geräten), kannst du in Syncthing-Fork zusätzlich die Tailscale-Adresse des Servers eintragen.

Kann ich Saves so auch zwischen zwei Handhelds teilen?

Mit diesem Setup nicht, und das ist Absicht. Zwei Geräte im Modus Send & Receive würden sich gegenseitig Saves überschreiben, und bei 10 Sekunden Autosave sind Konflikte vorprogrammiert. Dieses Setup ist ein reines Backup.

Kostet Syncthing viel Akku?

Syncthing-Fork hat eigene Run Conditions. Damit synct es zum Beispiel nur beim Laden, nur im WLAN oder nur einmal pro Stunde. Für ein Save-Backup reicht das locker, die Dateien sind winzig.

Fazit

Einmal eingerichtet, läuft das Backup von allein, und ein Jahr Versionen fängt kaputte Saves ab. Prüf nur bei jedem neuen Emulator einmal, ob er wirklich in /sdcard/Saves speichert und nicht in Android/data.

MappleBox Logbuch

Alle zwei Wochen eine Mail: was in meinem Homelab kaputt ging, neue Guides und ein Tool-Tipp. Als Dankeschön bekommst du das PDF „6 Abos, die ich selbst hoste“. Kein Spam, Abmeldung mit einem Klick.

E-Mail-AdresseEintragen

Du bekommst erst eine Mail zur Bestätigung. Details in der Datenschutzerklärung.

* Affiliate-Link: Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Für dich ändert sich am Preis nichts. Mehr dazu

Hat dir der Guide geholfen? Dann spendier mir gern einen Kaffee auf Ko-fi. Damit bleibt MappleBox werbefrei.

Weitere Guides

• Plex2Shell: So prüfst du deinen Plex-Server und machst das Update
• PHP-Sicherheitsupdate Oktober 2026: So prüfst du deine Version und updatest
• What’s Up Docker statt Watchtower: So bekommst du eine Push-Notification bei Docker-Updates