Sicherheit & Datensicherung

Selbst hosten heißt: Deine Daten liegen bei dir, und damit auch die Verantwortung dafür. Tunetorch macht es dir so einfach wie möglich. Es gibt genau ein Verzeichnis, das du sichern musst, und der Server schickt von sich aus nichts nach draußen.

Datenschutz

Tunetorch sammelt keine Telemetrie. Der Server schickt weder Nutzungsstatistiken noch Absturzberichte an uns oder an Dritte. Es gibt kein Tracking und keine Werbung, auch nicht in der Android-App. Musik, Playlists, Hörverlauf, Statistiken und Konten liegen in der Datenbank auf deinem Server, und nur dort.

Nach draußen verbindet sich der Server nur für Funktionen, die du selbst einschaltest. Das sind genau diese vier, und die Tabelle nennt jeden Dienst, an den sie sich wenden:

Deine Musik, deine Bibliothek und deine Nutzungsdaten gehen bei keiner davon mit.

Das CD-Rippen ist ab Werk aus. Beim Einschalten fragt die Oberfläche ausdrücklich nach, und die AccurateRip-Prüfung lässt sich getrennt abschalten. Sie gehört auch ohne Pro dazu, weil sie die Qualität des Rips sichert. Eine Free-Installation ohne CD-Rippen baut also keine einzige Verbindung ins Internet auf.

Auch im Browser bleibt alles bei dir: Die Oberfläche lädt nichts von fremden Servern. Bilder aus der Internet-Bildsuche holt der Server ab, nicht dein Browser.

Innerhalb deines Servers gilt:

• Persönliche Auswertungen gehören zum jeweiligen Konto. Andere Benutzer sehen sie nicht.
• Private Notizen sieht nur, wer sie geschrieben hat, auch der Admin nicht.
• Der Zähler für die beliebtesten Titel speichert nur, wie oft ein Titel lief, ohne Bezug zu einem Konto. Er ist damit anonym.

Was gesichert werden muss

/app/data. Mehr nicht.

/app/data/
├── db/                   die Datenbank: Titel, Alben, Interpreten, Konten, Playlists, Statistiken
├── backups/              Sicherungskopien der Datenbank (siehe unten)
├── audio/                hochgeladene Originaldateien + Metadaten-Sicherung
├── cover/                Cover in vier Größen
├── interpret_hero/       Künstlerbilder
├── person_hero/          Personenfotos
├── jwt/                  Signaturschlüssel der Anmeldung
├── lizenz/               Zustand der Pro-Lizenz
├── redis/                dauerhafte Sperren
└── logs/                 Server-Logs

Nicht sichern musst du audio_cache/ (umgewandelte Fassungen, die jederzeit neu entstehen können), temp/ und upload_temp/.

Liegt deine Sammlung in einem eingehängten Ordner (/app/musik), sicherst du diesen wie gewohnt separat. Tunetorch schreibt dort nie hinein.

Ein Backup anlegen

Am einfachsten geht es so, wenn du einen Bind-Mount nutzt:

docker compose stop tunetorch
tar czf tunetorch-backup-$(date +%F).tar.gz ./tunetorch-daten
docker compose start tunetorch

Sicherst du im laufenden Betrieb, etwa mit Borg, restic oder rsync, solltest du wissen: Die Datenbank arbeitet im WAL-Modus und ist dadurch robust. Eine Momentaufnahme mitten in einem Schreibvorgang kann trotzdem unvollständig sein. Am sichersten läuft ein Backup nachts, nach den Wartungs-Tasks.

Der nächtliche Task „Datenbank komprimieren“ hilft dem Backup. Er gibt ungenutzten Speicherplatz frei und hält den Unterschied zwischen zwei Sicherungen klein.

Wiederherstellen

Verzeichnis zurückspielen, Container starten. Tunetorch erkennt den Stand der Datenbank und spielt nötige Änderungen selbst ein.

Der Anmelde-Schlüssel gehört mit ins Backup. Fehlt jwt/, erzeugt Tunetorch beim Start einen neuen, und alle bisherigen Anmeldungen werden ungültig. Daten gehen dabei nicht verloren, aber alle müssen sich neu anmelden.

Vor jedem Schema-Update sichert Tunetorch selbst

Ändert ein Update den Aufbau der Datenbank, legt Tunetorch vorher eine Kopie der Datenbank unter /app/data/backups/ ab. Bei einem normalen Neustart passiert das nicht, nur wenn sich wirklich etwas ändert.

docker exec -it tunetorch tt db-sicherungen

Name                                     Art      Schema      Größe
auto-schema23-20260819-1930.db           auto         23     11.4 MB
manuell-schema22-20260810-1200.db        manuell      22     11.2 MB

auto-Kopien entstehen vor einer Umstellung und zeigen den Stand davor. Die zwei neuesten bleiben erhalten. manuell-Kopien legst du selbst mit tt db-sichern an, und Tunetorch löscht sie nie.

Zurückspielen, wenn nach einem Update etwas nicht stimmt:

docker exec -u root -it tunetorch tt db-einspielen auto-schema23-20260819-1930.db

Der Befehl sichert zuerst den aktuellen Stand, hält den Server an, spielt die Kopie zurück und startet ihn wieder. Danach brauchst du noch das alte Image. Sonst stellt der neue Server beim Start dieselbe Änderung gleich wieder um. Trag also in der docker-compose.yml die vorherige Version ein statt latest.

Ältere Versionen liegen dafür auf Docker Hub bereit: Ein abgelöster Stand bleibt dort mindestens ein halbes Jahr erreichbar, und für jeden Datenbank-Aufbau bleibt dauerhaft eine Version liegen. Willst du einen bestimmten Stand länger aufheben, speicherst du ihn selbst: docker save tunetorch/tunetorch:0.1.0 | gzip > tunetorch-0.1.0.tar.gz, und zurück mit docker load < tunetorch-0.1.0.tar.gz.

Warum -u root: Nur so darf der Befehl den laufenden Server anhalten. Ohne das bricht er ab und sagt dir, warum.

Drei Dinge sind diese Kopien nicht:

• Kein Ersatz für dein Backup. Sie liegen im selben Verzeichnis wie die Datenbank. Geht der Datenträger kaputt, sind sie mit weg. Außerdem enthalten sie nur die Datenbank, keine Musik und keine Cover.
• Nicht automatisch aktuell. Zwischen zwei Updates entsteht keine neue Kopie. Willst du einen Stand von heute Mittag, legst du ihn mit tt db-sichern oder in den Server-Einstellungen selbst an (siehe unten).
• Kein automatisches Zurückrollen. Geht eine Umstellung schief, bleibt der Server stehen und fasst nichts an. Was zurückgespielt wird, entscheidest du.

Sicherung aus der Oberfläche

Eine manuell-Kopie legst du auch ohne Kommandozeile an: Server-Einstellungen → System & Wartung → Datenbank-Sicherung → Sicherung jetzt erstellen. Darunter stehen alle vorhandenen Kopien mit Zeitpunkt, Art und Größe. Das lohnt sich vor größeren Umbauten, etwa bevor du im Metadaten-Assistenten Alle anwenden drückst; dort bietet dir die Rückfrage denselben Knopf an. Das Recht dazu haben nur Admins.

Zurückspielen und Herunterladen gehen bewusst nur am Server. Zum Zurückspielen hält Tunetorch kurz an, das kann die Oberfläche nicht selbst. Und die Kopie enthält die ganze Datenbank samt Anmeldedaten, sie gehört nicht in einen Download-Link. Den passenden tt db-einspielen-Befehl zeigt die Liste gleich mit an.

Metadaten-Sicherung

Neben jeder hochgeladenen Originaldatei legt Tunetorch eine kleine Textdatei mit ihren Metadaten ab. Im Betrieb liest Tunetorch sie nie. Sie ist nur eine Rückversicherung, falls die Datenbank verloren geht, die Musikdateien aber noch da sind.

Anmeldung

Tunetorch speichert die Anmeldung in geschützten Cookies (HttpOnly), nicht im Speicher des Browsers. Ein Skript auf der Seite kommt deshalb nicht an deine Anmeldedaten heran.

Die Refresh-Laufzeit zählt ab der letzten Nutzung, nicht ab dem Login: Wer Tunetorch innerhalb dieser Zeit wieder öffnet, bekommt eine frische Anmeldung und bleibt angemeldet. Abgemeldet wirst du erst, wenn du so lange gar nicht da warst.

Beide Laufzeiten lassen sich in den Server-Einstellungen ändern (Access höchstens 1 Tag, Refresh höchstens 90 Tage). Die Obergrenzen verhindern, dass ein versehentlich zu hoher Wert eine gestohlene Anmeldung beliebig lange gültig hält.

Beim Abmelden sperrt der Server beide Token. Sie sind sofort wertlos, selbst wenn jemand sie abgefangen hätte. Die Sperrliste liegt auf der Festplatte und übersteht einen Neustart. In der Android-App passiert das beim Entfernen einer Server-Verbindung: Sie meldet dich zuerst beim Server ab und löscht danach die Daten auf dem Gerät. Sonst blieben die Token bis zum Ablauf gültig, obwohl auf dem Gerät nichts mehr davon zu sehen ist.

Mit dem Schalter Angemeldet bleiben entscheidest du beim Login, ob du nach dem Schließen des Browsers angemeldet bleibst.

Brute-Force-Schutz

Fehlgeschlagene Anmeldeversuche werden pro IP-Adresse gezählt. Gibt es im eingestellten Zeitraum zu viele, sperrt Tunetorch die Adresse für eine bestimmte Zeit.

Außerdem dauert die Antwort bei einem falschen Benutzernamen genauso lange wie bei einem falschen Passwort. An der Antwortzeit lässt sich also nicht ablesen, ob es ein Konto gibt.

Dafür muss TT_TRUSTED_PROXIES stimmen. Hinter einem Reverse-Proxy sähe der Server sonst nur dessen IP und würde bei einer Sperre alle aussperren. Ist der Wert zu hoch, lässt sich die IP des Aufrufers dagegen fälschen. Siehe Konfiguration.

Härtung im Browser

• Strenge Content-Security-Policy: Die Oberfläche lädt nichts von fremden Servern. Schriften und Diagramme bringt Tunetorch selbst mit.
• X-Frame-Options: DENY: Die Oberfläche lässt sich nicht in fremde Seiten einbetten (Schutz vor Clickjacking).
• Referrer-Policy: no-referrer, X-Content-Type-Options: nosniff und HSTS, wenn HTTPS aktiv ist.
• CORS ist ab Werk aus, weil Oberfläche und API von derselben Adresse kommen.
• Kein Eintrag in Suchmaschinen: Der Server liefert eine robots.txt, die alles sperrt, und markiert jede Antwort mit X-Robots-Tag: noindex, nofollow. Deine Bibliothek taucht damit nicht in Suchergebnissen auf, auch keine einzelnen Cover oder Titel. Das gilt automatisch und lässt sich nicht aus Versehen abschalten.

Vorschaubilder aus der Internet-Bildsuche laufen über den Server, nicht direkt über den Browser. So bleibt die strenge Policy erhalten, und dein Browser nimmt keinen Kontakt zu fremden Servern auf.

Zugriff aus dem Internet

Willst du unterwegs hören, brauchst du einen Reverse-Proxy mit gültigem TLS-Zertifikat. Ohne HTTPS

• verwirft der Browser die Anmelde-Cookies (die Anmeldung scheint zu scheitern),
• lässt sich die PWA nicht installieren,
• gehen deine Musik und dein Passwort unverschlüsselt durchs Netz.

Ein Beispiel für Caddy und Nginx steht unter Konfiguration.

Statt einen Port zu öffnen, kannst du auch ein VPN ins Heimnetz (WireGuard, Tailscale) oder einen Tunnel nutzen. Dann brauchst du gar keine Portfreigabe.

Weiter geht's

• Server verwalten
• Fehlerbehebung