Vorhandene SIHub-Daten nach MariaDB übernehmen

Eine neue SIHub-Installation benötigt keine SQLite-Datei. Für eine bisherige Installation liest der Migrationshelfer einmalig eine unveränderte SQLite-Sicherung und übernimmt Konten, Passwort-/API-Key-Hashes, Agenten, Wissen, Gespräche und Konfiguration in MariaDB. Der produktive Betrieb verwendet danach ausschließlich DATABASE_URL für MariaDB.

Bei einer Neuinstallation führst du keinen der SQLite-Sicherungs-, Kopier- oder Importbefehle dieser Seite aus. Nutze die Apache-Erstinstallation. Eine fehlende oder ungültige DATABASE_URL wird in /etc/sihub/sihub.env korrigiert; dafür ist keine SQLite-Datei erforderlich. Der interaktive Helfer apache2/configure-database.py prüft deine vorhandene MariaDB-Verbindung und schreibt die Adresse mit korrekt kodiertem Passwort, ohne Datenbankkonten oder Daten zu verändern.

Plane ein Wartungsfenster und stoppe den bisherigen SIHub-Dienst sowie eigene Wartungs-/Voice-Schreiber. Notiere deren alten Startweg. Übertrage keine laufende SQLite-Hauptdatei allein; nutze eine konsistente Sicherung. Die folgende Sicherung verwendet direkt die Python-Standardbibliothek und funktioniert unabhängig vom neuen SIHub-Startcheck. Ersetze ALT_DB_PFAD durch den tatsächlichen Pfad, beispielsweise /var/www/SIHub/instance/aihub.sqlite3 oder /var/lib/sihub/sihub.sqlite3.

sudo install -d -m 0700 /var/backups/sihub-migration
sudo python3 - <<'PY'
import os, sqlite3
from pathlib import Path
source = Path('ALT_DB_PFAD')
destination = Path('/var/backups/sihub-migration/source.sqlite3')
if not source.is_file():
    raise SystemExit('Tatsächlichen alten DB-Pfad eintragen.')
fd = os.open(destination, os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0o600)
os.close(fd)
with sqlite3.connect(source.as_uri() + '?mode=ro', uri=True) as old:
    with sqlite3.connect(destination) as copy:
        old.backup(copy)
        if copy.execute('PRAGMA integrity_check').fetchone()[0] != 'ok':
            raise SystemExit('Integritätsprüfung fehlgeschlagen; Migration nicht starten.')
print('Geschützte Quelldatenbanksicherung erstellt.')
PY

Eine vorhandene Sicherung wird nicht überschrieben. Bewahre die alte DB und Betreiberdatei geschützt und getrennt auf. Die folgenden zwei Wege sind Alternativen.

Direkter Betrieb mit Apache2

MariaDB 10.6+ und die Python-Voraussetzungen aus apache2/README.md werden benötigt; ein vorhandener MariaDB-10.6-Server kann verwendet werden. Die Vorlage für neue Server wählt MariaDB 10.11. Stoppe den alten SIHub-Dienst, beispielsweise sudo systemctl stop sihub, und bestätige, dass Port 5090 frei ist.

Falls die bisherige Betreiberdatei bereits /etc/sihub/sihub.env ist, bleibt sie an diesem Ort. Falls deine alte Installation stattdessen eine .env im Checkout verwendet, kopiere diese nur bei noch nicht vorhandener Zieldatei geschützt nach /etc/sihub/sihub.env; Sitzungsschlüssel und Anbieterzugänge müssen mitgenommen werden.

cd /var/www/SIHub
sudo install -d -m 0700 /etc/sihub
# Nur beim Wechsel von einer bisherigen .env und nur bei fehlender Zieldatei:
sudo sh -c 'test ! -e /etc/sihub/sihub.env && install -m 0600 -o root -g root /var/www/SIHub/.env /etc/sihub/sihub.env'

Bei vorhandener Zieldatei überspringst du das Kopierkommando. Prüfe den Eigentümer und Modus; die Datei muss root gehören und Modus 0600 haben. Der nächste Aufruf sichert die bisherige Betreiberdatei automatisch, erzeugt den neuen lokalen MariaDB-DSN und erhält vorhandene Sitzungs-/Anbieterschlüssel. Livebetrieb bleibt während der Übernahme ausgeschaltet.

sudo python3 apache2/prepare-env.py --mariadb-upgrade
sudo bash apache2/install.sh prepare --no-start
sudo install -o sihub -g sihub -m 0400 /var/backups/sihub-migration/source.sqlite3 /var/lib/sihub/legacy-import.sqlite3
sudo bash apache2/install.sh manage migrate-mariadb --sqlite /var/lib/sihub/legacy-import.sqlite3
sudo bash apache2/install.sh manage check-config
sudo systemctl enable --now sihub
curl --fail http://127.0.0.1:5090/health

prepare --no-start installiert Abhängigkeiten, erstellt die lokale MariaDB und bereitet leere Tabellen vor. Die App startet erst nach dem Import. Für eine vorhandene eigene/entfernte MariaDB trägst du stattdessen deren DSN per sudoedit /etc/sihub/sihub.env ein; die Zieltabellen müssen leer sein. Erstelle vor dem Import kein neues Admin- oder Demokonto. Die CLI druckt nur geprüfte Zeilenzahlen, keine Zugangsdaten.

Melde dich anschließend unter https://sihub.at/login mit dem übernommenen Konto an. Prüfe Agenten, Wissen, Versionen, Gesprächsverläufe und Exporte. Entferne die separate legacy-import.sqlite3 erst nach bestätigter Übernahme; die geschützte Quellsicherung bleibt für dein Rollback erhalten. Apache und das Zertifikat ändern sich wegen des Datenbankwechsels nicht.

Dockerbetrieb mit Telefonie-Stack

Bereite deploy/.env.production, das App-Image und die Dienste mariadb/redis nach Server-Setup vor. Übernimm alte Sitzungs-/Anbieter-/Redis-/Telefoniekeys geschützt in die neue Betreiberdatei. Die neue Datenbank heißt SIHub; MARIADB_PASSWORD muss mit dem Passwort in DATABASE_URL=mariadb+pymysql://sihub:...@mariadb:3306/SIHub übereinstimmen. MARIADB_ROOT_PASSWORD ist ein eigener Adminschlüssel. Ein bestehendes Redis-ACL muss weiterhin zum konfigurierten Redispasswort passen.

cd /var/www/SIHub
sudo install -o 10001 -g 10001 -m 0400 /var/backups/sihub-migration/source.sqlite3 /var/backups/sihub-migration/legacy-container.sqlite3
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps --volume /var/backups/sihub-migration/legacy-container.sqlite3:/restore/legacy.sqlite3:ro app python scripts/migrate_to_mariadb.py --sqlite /restore/legacy.sqlite3
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps app python manage.py check-config
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml up -d --wait app
curl --fail http://127.0.0.1:5090/health

Die App und der direkte Dienst dürfen nicht gleichzeitig Port 5090 belegen. Die Migration erwartet leere Zieltabellen, prüft Schema/Fremdschlüssel/Zeilenzahlen und schreibt den Datenimport in einer Transaktion. Bei einem Fehler bleibt die Quelle unverändert; kein teilweise importierter Datenbestand wird freigegeben. MariaDB-DDL erfolgt vor der Datentransaktion und kann leere Zieltabellen hinterlassen. Eine gefüllte Zieldatenbank wird abgewiesen und nicht gelöscht.

Rollback und anschließende Sicherung

Vor neuen Schreibzugriffen kann ein fehlgeschlagener Umstieg zurückgesetzt werden, indem du die neue SIHub-App stoppst und den notierten alten Software-/Konfigurationsstand mit der unveränderten Quelle startest. Sobald neue Daten in MariaDB geschrieben wurden, braucht ein Rollback eine geplante Rückübernahme; die alte SQLite-Datei enthält diese Daten nicht. Lösche deshalb weder Quelle noch alte Betreiberdatei während der Übernahme.

Erstelle nach erfolgreicher Prüfung eine frische MariaDB-Sicherung mit sudo bash apache2/backup-mariadb.sh oder sudo bash deploy/backup-mariadb.sh. Teste deren Wiederherstellung nach Betrieb und Restore. Die Übernahme ersetzt keine Liveprüfung von Telefonie oder Anbietern.