Zum Hauptinhalt springen

Migrationsleitfaden

Dieses Handbuch erklärt, wie Sie zwischen Versionen von duplistatus aktualisieren. Migrationen erfolgen automatisch – das Datenbankschema aktualisiert sich selbst, wenn Sie eine neue Version starten.

Manuelle Schritte sind nur erforderlich, wenn Sie benutzerdefinierte Benachrichtigungsvorlagen angepasst haben (Version 0.8.x hat Vorlagenvariablen geändert) oder externe API-Integrationen aktualisiert werden müssen (Version 0.7.x hat API-Feldnamen geändert, Version 0.9.x erfordert Authentifizierung).

Übersicht​

duplistatus migriert Ihr Datenbankschema bei einem Upgrade automatisch. Das System:

  1. Erstellt eine Sicherung Ihrer Datenbank vor Änderungen
  2. Aktualisiert das Datenbankschema auf die neueste Version
  3. Bewahrt alle vorhandenen Daten (Server, Sicherungen, Konfiguration)
  4. Überprüft, ob die Migration erfolgreich abgeschlossen wurde

Sicherung Ihrer Datenbank vor der Migration​

Vor dem Upgrade auf eine neue Version wird empfohlen, eine Sicherung von Ihrer Datenbank zu erstellen. Dies stellt sicher, dass Sie Ihre Daten wiederherstellen können, falls während des Migrationsprozesses etwas schiefgeht.

Wenn Sie Version 1.2.1 oder später ausführen​

Verwenden Sie die integrierte Datenbanksicherungsfunktion:

  1. Navigieren Sie zu Einstellungen → Datenbankwartung in der Weboberfläche
  2. Wählen Sie im Abschnitt Datenbanksicherung ein Sicherungsformat aus:
    • Datenbankdatei (.db): Binärformat – schnellste Sicherung, behält alle Datenbankstrukturen exakt bei
    • SQL-Dump (.sql): Textformat – lesbare SQL-Anweisungen
  3. Klicken Sie auf Sicherung herunterladen
  4. Die Sicherungsdatei wird auf Ihren Computer mit einem Zeitstempel-Dateinamen heruntergeladen

Weitere Details finden Sie in der Dokumentation zur Datenbankwartung.

Wenn Sie eine Version vor 1.2.1 ausführen​

Sicherung​

Sie müssen die Datenbank manuell sichern, bevor Sie fortfahren. Die Datenbankdatei befindet sich unter /app/data/backups.db im Container.

Für Linux-Benutzer​

Wenn Sie Linux verwenden, müssen Sie sich keine Gedanken über das Starten von Hilfcontainern machen. Sie können den nativen cp-Befehl verwenden, um die Datenbank direkt aus dem laufenden Container auf Ihren Host zu extrahieren.

Docker oder Podman verwenden:​
# Replace 'duplistatus' with your actual container name if different
docker cp duplistatus:/app/data/backups.db ./duplistatus-backup-$(date +%Y%m%d).db

(Wenn Sie Podman verwenden, ersetzen Sie einfach docker durch podman im obigen Befehl.)

Für Windows-Benutzer​

Wenn Sie Docker Desktop unter Windows ausführen, haben Sie zwei einfache Möglichkeiten, dies ohne Verwendung der Befehlszeile zu bewältigen:

Option A: Docker Desktop verwenden (Am einfachsten)​
  1. Öffnen Sie das Docker Desktop Dashboard.
  2. Gehen Sie zur Registerkarte Containers und klicken Sie auf Ihren duplistatus Container.
  3. Klicken Sie auf die Registerkarte Dateien.
  4. Navigieren Sie zu /app/data/.
  5. Klicken Sie mit der rechten Maustaste auf backups.db und wählen Sie Speichern unter..., um die Datei in Ihre Windows-Ordner herunterzuladen.
Option B: PowerShell verwenden​

Wenn Sie das Terminal bevorzugen, können Sie PowerShell verwenden, um die Datei auf Ihren Desktop zu kopieren:

docker cp duplistatus:/app/data/backups.db $HOME\Desktop\duplistatus-backup.db
Wenn Sie Bind Mounts verwenden​

Wenn Sie Ihren Container ursprünglich mit einem Bind Mount eingerichtet haben (z. B. haben Sie einen lokalen Ordner wie /opt/duplistatus dem Container zugeordnet), benötigen Sie überhaupt keine Docker-Befehle. Kopieren Sie die Datei einfach mit Ihrem Dateimanager:

  • Linux: cp /path/to/your/folder/backups.db ~/backups.db
  • Windows: Kopieren Sie die Datei einfach im Datei-Explorer aus dem Ordner, den Sie während der Einrichtung festgelegt haben.

Wiederherstellen Ihrer Daten​

Wenn Sie Ihre Datenbank aus einer vorherigen Sicherung wiederherstellen müssen, führen Sie die folgenden Schritte basierend auf Ihrem Betriebssystem aus.

WICHTIG

Stoppen Sie den Container vor der Wiederherstellung der Datenbank, um Dateikorruption zu verhindern.

Für Linux-Benutzer​

Die einfachste Möglichkeit zur Wiederherstellung besteht darin, die Sicherungsdatei in den internen Speicherplatz des Containers "zurückzuspielen".

Docker oder Podman verwenden:​
# stop the container
docker stop duplistatus

# Replace 'duplistatus-backup.db' with your actual backup filename
docker cp ./duplistatus-backup.db duplistatus:/app/data/backups.db

# Restart the container
docker start duplistatus
Für Windows-Benutzer​

Wenn Sie Docker Desktop verwenden, können Sie die Wiederherstellung über die GUI oder PowerShell durchführen.

Option A: Docker Desktop (GUI) verwenden​
  1. Stellen Sie sicher, dass der duplistatus-Container aktiv ist (Docker Desktop erfordert, dass der Container aktiv ist, um Dateien über die GUI hochzuladen).
  2. Gehen Sie zur Registerkarte „Dateien" in Ihren Container-Einstellungen.
  3. Navigieren Sie zu /app/data/.
  4. Klicken Sie mit der rechten Maustaste auf die vorhandene backups.db und wählen Sie „Löschen".
  5. Klicken Sie auf die Schaltfläche „Importieren" (oder klicken Sie mit der rechten Maustaste in den Ordnerbereich) und wählen Sie Ihre Sicherungsdatei von Ihrem Computer aus.

Benennen Sie die importierte Datei in genau backups.db um, wenn sie einen Zeitstempel im Namen hat.

Starten Sie den Container neu.

Option B: PowerShell verwenden​
# Copy the file from your Desktop back into the container
docker cp $HOME\Desktop\duplistatus-backup.db duplistatus:/app/data/backups.db

# Restart the container
docker start duplistatus
Wenn Sie Bind Mounts verwenden​

Wenn Sie einen lokalen Ordner dem Container zuordnen, benötigen Sie keine speziellen Befehle.

  1. Stoppen Sie den Container.
  2. Kopieren Sie Ihre Sicherungsdatei manuell in Ihren zugeordneten Ordner (z. B. /opt/duplistatus oder C:\duplistatus_data).
  3. Stellen Sie sicher, dass die Datei genau backups.db benannt ist.
  4. Starten Sie den Container.
docker logs <container-name>
Hinweis

Wenn Sie die Datenbank manuell wiederherstellen, können Berechtigungsfehler auftreten.

Prüfen Sie die Container-Protokolle und passen Sie die Berechtigungen bei Bedarf an. Weitere Informationen finden Sie im Abschnitt Troubleshooting weiter unten.

Automatischer Migrationsprozess​

Wenn Sie eine neue Version starten, werden Migrationen automatisch ausgeführt:

  1. Sicherungserstellung: Eine mit Zeitstempel versehene Sicherung wird in Ihrem Datenverzeichnis erstellt
  2. Schema-Update: Datenbanktabellen und Felder werden nach Bedarf aktualisiert
  3. Datenmigration: Alle vorhandenen Daten werden beibehalten und migriert
  4. Verifizierung: Der Migrationserfolg wird protokolliert

Überwachung der Migration​

Prüfen Sie Docker-Protokolle, um den Migrationsverlauf zu überwachen:

Suchen Sie nach Nachrichten wie:

  • "Found X pending migrations"
  • "Running consolidated migration X.0..."
  • "Migration X.0 completed successfully"
  • "Database backup created: /path/to/backups-copy-YYYY-MM-DDTHH-MM-SS.db"
  • "All migrations completed successfully"

Versionsspezifische Migrationshinweise​

Upgrade auf Version 0.9.x oder höher (Schema v4.0)​

Warnung

Authentifizierung ist jetzt erforderlich. Alle Benutzer müssen sich nach dem Upgrade anmelden.

Was ändert sich automatisch​

  • Datenbankschema wird von v3.1 zu v4.0 migriert
  • Neue Tabellen erstellt: users, sessions, audit_log
  • Standard-Admin-Konto wird automatisch erstellt
  • Alle vorhandenen Sitzungen ungültig gemacht

Was Sie tun müssen​

  1. Anmelden mit Standard-Admin-Anmeldedaten:
    • Benutzername: admin
    • Passwort: Duplistatus09
  2. Passwort ändern wenn aufgefordert (erforderlich bei der ersten Anmeldung)
  3. Benutzerkonten erstellen für andere Benutzer (Einstellungen → Benutzer)
  4. Externe API-Integrationen aktualisieren, um Authentifizierung einzubeziehen (siehe Rückwärts inkompatible API-Änderungen)
  5. Audit-Log-Aufbewahrung konfigurieren, falls erforderlich (Einstellungen → Audit-Log)

Wenn Sie gesperrt sind​

Verwenden Sie das Admin-Wiederherstellungstool:

docker exec -it duplistatus /app/admin-recovery admin NewPassword123

Weitere Informationen finden Sie im Admin Recovery Guide.

Upgrade auf Version 0.8.x​

Was ändert sich automatisch​

  • Datenbankschema auf v3.1 aktualisiert
  • Hauptschlüssel für Verschlüsselung generiert (gespeichert in .duplistatus.key)
  • Sitzungen ungültig gemacht (neue CSRF-geschützte Sitzungen erstellt)
  • Passwörter mit neuem System verschlüsselt

Was Sie tun müssen​

  1. Benachrichtigungsvorlagen aktualisieren, falls Sie diese angepasst haben:
    • Ersetzen Sie {backup_interval_value} und {backup_interval_type} durch {backup_interval}
    • Standard-Vorlagen werden automatisch aktualisiert

Sicherheitshinweise​

  • Stellen Sie sicher, dass die Datei .duplistatus.key gesichert ist (hat 0400-Berechtigungen)
  • Sitzungen verfallen nach 24 Stunden

Upgrade auf Version 0.7.x​

Was ändert sich automatisch​

  • machines Tabelle in servers umbenannt
  • machine_id Felder in server_id umbenannt
  • Neue Felder hinzugefügt: alias, notes, created_at, updated_at

Was Sie tun müssen​

  1. Externe API-Integrationen aktualisieren:
    • totalMachines → totalServers in /api/summary ändern
    • machine → server in API-Antwortobjekten ändern
    • backup_types_count → backup_jobs_count in /api/lastbackups/{serverId} ändern
    • Endpunkt-Pfade von /api/machines/... zu /api/servers/... aktualisieren
  2. Benachrichtigungsvorlagen aktualisieren:
    • {machine_name} durch {server_name} ersetzen

Siehe Rückwärts inkompatible API-Änderungen für detaillierte API-Migrationschritte.

Checkliste nach der Migration​

Nach dem Upgrade bestätigen:

  • Alle Server werden korrekt im Dashboard angezeigt
  • Sicherungsverlauf ist vollständig und zugänglich
  • Benachrichtigungen funktionieren (NTFY/E-Mail testen)
  • Externe API-Integrationen funktionieren (falls zutreffend)
  • Einstellungen sind zugänglich und korrekt
  • Sicherungsüberwachung funktioniert korrekt
  • Erfolgreich angemeldet (0.9.x+)
  • Standard-Admin-Passwort geändert (0.9.x+)
  • Benutzerkonten für andere Benutzer erstellt (0.9.x+)
  • Externe API-Integrationen mit Authentifizierung aktualisiert (0.9.x+)

Fehlerbehebung​

Migration schlägt fehl​

  1. Prüfen Sie den Speicherplatz (Sicherung erfordert Speicherplatz)
  2. Bestätigen Sie Schreibberechtigungen im Datenverzeichnis
  3. Überprüfen Sie Container-Protokolle auf spezifische Fehler
  4. Stellen Sie bei Bedarf aus einer Sicherung wieder her (siehe Rollback unten)

Daten fehlen nach der Migration​

  1. Bestätigen Sie, dass die Sicherung erstellt wurde (Datenverzeichnis prüfen)
  2. Überprüfen Sie die Container-Protokolle auf Nachrichten zur Sicherungserstellung
  3. Prüfen Sie die Integrität der Datenbankdatei

Authentifizierungsprobleme (0.9.x+)​

  1. Bestätigen Sie, dass das Standard-Admin-Konto vorhanden ist (Protokolle prüfen)
  2. Versuchen Sie Standard-Anmeldedaten: admin / Duplistatus09
  3. Verwenden Sie das Admin-Wiederherstellungstool, wenn gesperrt
  4. Bestätigen Sie, dass die Tabelle users in der Datenbank vorhanden ist

API-Fehler​

  1. Überprüfen Sie Rückwärts inkompatible API-Änderungen auf Endpunkt-Updates
  2. Aktualisieren Sie externe Integrationen mit neuen Feldnamen
  3. Fügen Sie Authentifizierung zu API-Anfragen hinzu (0.9.x+)
  4. Testen Sie API-Endpunkte nach der Migration

Probleme mit Master Key (0.8.x+)​

  1. Stellen Sie sicher, dass die Datei .duplistatus.key zugänglich ist
  2. Bestätigen Sie, dass die Dateiberechtigungen 0400 sind
  3. Prüfen Sie die Container-Protokolle auf Fehler bei der Schlüsselerzeugung

Podman-DNS-Konfiguration​

Wenn Sie Podman verwenden und nach einem Upgrade Probleme mit der Netzwerkkonnektivität haben, müssen Sie möglicherweise die DNS-Einstellungen für Ihren Container konfigurieren. Weitere Informationen finden Sie im Abschnitt zur DNS-Konfiguration des Installationshandbuchs.

Rollback-Verfahren​

Wenn Sie zu einer vorherigen Version zurückwechseln müssen:

  1. Container stoppen: docker stop <container-name> (oder podman stop <container-name>)
  2. Ihre Sicherung suchen:
    • Wenn Sie eine Sicherung über die Weboberfläche erstellt haben (Version 1.2.1+), verwenden Sie diese heruntergeladene Sicherungsdatei
    • Wenn Sie eine manuelle Volume-Sicherung erstellt haben, extrahieren Sie diese zunächst
    • Automatische Migrationssicherungen befinden sich im Datenverzeichnis (mit Zeitstempel versehene .db-Dateien)
  3. Datenbank wiederherstellen:
    • Für Sicherungen der Weboberfläche (Version 1.2.1+): Verwenden Sie die Wiederherstellungsfunktion in Einstellungen → Datenbankwartung (siehe Datenbankwartung)
    • Für manuelle Sicherungen: Ersetzen Sie backups.db in Ihrem Datenverzeichnis/Volume mit der Sicherungsdatei
  4. Vorherige Image-Version verwenden: Rufen Sie das vorherige Container-Image ab und führen Sie es aus
  5. Container starten: Starten Sie mit der vorherigen Version
Warnung

Das Zurückrollen kann zu Datenverlust führen, wenn das neuere Schema mit der älteren Version nicht kompatibel ist. Stellen Sie immer sicher, dass Sie eine aktuelle Sicherung haben, bevor Sie versuchen, ein Zurückrollen durchzuführen.

Fehlerbehebung bei Ihrer Wiederherstellung / Rollback​

Wenn die Anwendung nicht startet oder Ihre Daten nach einer Wiederherstellung oder einem Rollback nicht angezeigt werden, prüfen Sie die folgenden häufigen Probleme:

1. Dateiberechtigungen (Linux/Podman)​

Wenn Sie die Datei als root-Benutzer wiederhergestellt haben, hat die Anwendung im Container möglicherweise keine Berechtigung, sie zu lesen oder zu schreiben.

  • Das Symptom: Protokolle zeigen "Permission Denied" oder "Read-only database" ein.
  • Die Lösung: Setzen Sie die Berechtigungen von der Datei im Container zurück, um sicherzustellen, dass sie zugänglich ist.
# Set ownership (usually UID 1000 or the app user)
docker exec -u 0 duplistatus chown 1000:1000 /app/data/backups.db
# Set read/write permissions
docker exec -u 0 duplistatus chmod 664 /app/data/backups.db

2. Falscher Dateiname​

Die Anwendung sucht speziell nach einer Datei mit dem Namen backups.db.

  • Das Symptom: Die Anwendung startet, sieht aber „leer" aus (wie eine Neuinstallation).
  • Die Lösung: Prüfen Sie das Verzeichnis /app/data/. Wenn Ihre Datei duplistatus-backup-2024.db heißt oder die Erweiterung .sqlite hat, wird die App sie ignorieren. Verwenden Sie den Befehl mv oder die Docker Desktop GUI, um sie exakt in backups.db umzubenennen.

3. Container nicht neu gestartet​

Auf einigen Systemen kann die Verwendung von docker cp während der Ausführung des Containers die Verbindung der Anwendung zur Datenbank möglicherweise nicht sofort "aktualisieren".

  • Die Lösung: Führen Sie nach einer Wiederherstellung immer einen vollständigen Neustart durch:
docker restart duplistatus

4. Datenbankversion-Nichtübereinstimmung​

Wenn Sie eine Sicherung aus einer viel neueren Version von duplistatus in einer älteren Version der App wiederherstellen, könnte das Datenbankschema inkompatibel sein.

  • Die Lösung: Stellen Sie immer sicher, dass Sie die gleiche (oder eine neuere) Version des duplistatus-Images ausführen wie diejenige, die die Sicherung erstellt hat. Prüfen Sie Ihre Version mit:
docker inspect duplistatus --format '{{.Config.Image}}'

Datenbankschema-Versionen​

AnwendungsversionSchema-VersionWichtigste Änderungen
0.6.x und früherv1.0Initiales Schema
0.7.xv2.0, v3.0Konfigurationen hinzugefügt, machines → Server umbenannt
0.8.xv3.1Erweiterte Sicherungsfelder, Verschlüsselungsunterstützung
0.9.x, 1.0.x, 1.1.x, 1.2.x, 1.3.xv4.0Benutzerzugriffskontrolle, Authentifizierung, Audit-Protokollierung

Hilfe​