Einrichtungsassistent

Beim ersten Öffnen von Restow läuft einmalig ein Einrichtungsassistent mit dem Titel „Ersteinrichtung“. Die Schritte heißen Sprache, Setup-Token, Hinweis, Betriebsmodus, Organisation und Admin, Mail-Transport und Überprüfung. Der Assistent lässt sich nach Abschluss nicht erneut ausführen: Er legt den ersten Administrator, die Einstellungen der Installation, die Zustimmung zum Hinweis für Betreiber und einen Audit-Eintrag in einer einzigen Transaktion an und sperrt sich selbst in dem Moment, in dem diese Transaktion committet wird. Wird er mittendrin unterbrochen, bleibt von der Einrichtung nichts zurück, und Sie beginnen von vorn. Ein verlorenes Admin-Konto wird danach über die Kommandozeile des Servers wiederhergestellt, niemals über den Assistenten (siehe Admin-Zugang wiederherstellen).

Schritt 1: Sprache

Der Assistent beginnt mit zwei Karten, English und Deutsch, jede in ihrer eigenen Sprache beschriftet. Die Karte, die zur Sprache Ihres Browsers passt, ist vorausgewählt, und der ganze Assistent wechselt in dem Moment in die gewählte Sprache, in dem Sie sie anklicken, sodass Sie den Rest der Einrichtung in ihr lesen. Sie ist auch die Sprache der Mails und Berichte Ihrer eigenen Organisation, des Mandanten, den die Einrichtung anlegt. Der Sprachumschalter im Kopfbereich funktioniert in jedem Schritt, wie auf jeder Anmeldeseite; gespeichert wird die Sprache, die beim Abschluss aktiv ist.

Schritt 2: Setup-Token

Der zweite Schritt, „Bestätigen Sie, dass Sie diesen Server betreiben“, fragt nach dem Setup-Token. Es ist ein Einmal-Code, der beweist, dass Sie diesen Server betreiben: Nur wer das Log des Servers lesen kann, sieht es. Die Adresse einer frischen Installation zu kennen, reicht also nicht, um sie zu übernehmen. Es verliert seine Gültigkeit, sobald die Einrichtung abgeschlossen ist. Der Server prüft das Token beim Speichern der Einrichtung erneut, unabhängig davon, was der Browser tut.

Wo Sie es finden. Das Installationsskript gibt es am Ende der Installation aus (ab 0.2.0). Bis die Einrichtung abgeschlossen ist, schreibt außerdem der api-Container bei jedem Start ein einmaliges Token in sein Log. So zeigen Sie es auf dem Server an:

cd /opt/restow && sudo docker compose logs api | grep 'SETUP TOKEN'

/opt/restow ist das Verzeichnis des Installationsskripts; nehmen Sie das Verzeichnis mit Ihrer Compose-Datei, wenn Sie ein anderes gewählt oder von Hand installiert haben.

Das Token sieht aus wie K7PQX-3MZRA-T9WHE-2BNCV (vier Gruppen zu fünf Zeichen); Groß- und Kleinschreibung und Bindestriche spielen keine Rolle. Jeder Neustart der api erzeugt ein neues Token, verwenden Sie also das zuletzt ausgegebene. Startet die api neu, während Sie im Assistenten sind, bemerkt der Assistent das und fragt nach dem neuen Token; Ihre Eingaben bleiben erhalten.

Unbeaufsichtigte Installationen. Um das Token vorab festzulegen, setzen Sie RESTOW_SETUP_TOKEN in der .env (mindestens 16 Zeichen, Leerzeichen und Bindestriche nicht mitgezählt; zum Beispiel openssl rand -hex 16). Der Assistent fragt dann nach diesem Wert, und das Token wird nie ins Log geschrieben. Mit einem kürzeren Wert startet die api nicht. Nach Abschluss der Einrichtung hat die Variable keine Wirkung mehr. Ein Skript, das die Einrichtung ausführt, sendet das Token im Header X-Restow-Setup-Token und die Zustimmung zum Hinweis für Betreiber im Body von POST /api/v1/setup als "disclaimer": {"version": "...", "accepted": true}, mit der Fassung, die GET /api/v1/setup/state meldet.

Ein falsches oder veraltetes Token wird abgelehnt (urn:restow:problem:setup-token-invalid); kopieren Sie das Token erneut aus dem Log.

Schritt 3: Hinweis für Betreiber

Der Assistent fährt mit einem Hinweis mit dem Titel „Ihre Verantwortung als Betreiber“ fort (in der Schrittleiste: Hinweis). Sie müssen ihn akzeptieren, bevor Sie weitermachen können, und ohne die Zustimmung speichert der Server die Einrichtung nicht. Er sagt, dass Restow ein Werkzeug für Backup und Archivierung ist, das Ihre Daten auf Speicher schreibt, den Sie betreiben, und dass die Hardware- und Speicherebene Ihre Verantwortung als Betreiber ist. Seine Punkte: Restow ersetzt keine Backup-Strategie (bewahren Sie eine unabhängige Kopie auf, halten Sie sich an die 3-2-1-Regel), Hardware und Speicher, Ransomware und Löschen (Daten sind nur unveränderbar, wenn der Speicher sie dazu macht, mit WORM oder Object Lock; seit 0.4.0 kann Restow Object Lock für Sie auf einem S3-Repository setzen und verzögert das Löschen in Verzeichnissen, was der Speicher nicht durchsetzt: siehe Unveränderbare Backups und den Hinweis für Betreiber), Verschlüsselungsschlüssel, Netzwerk und Zugriff, regelmäßige Restore-Tests, Archiv und GoBD (die Archivfunktionen sind für den GoBD-konformen Einsatz ausgelegt; ob Ihr gesamtes Verfahren konform ist, liegt in Ihrer Verantwortung, und Restow leistet keine Rechts- oder Steuerberatung) sowie keine Gewährleistung über die Lizenzbedingungen hinaus. Der vollständige Text steht im Assistenten; Hinweis für Betreiber erklärt, was er abdeckt.

Setzen Sie den Haken, um fortzufahren. Die Zustimmung wird zusammen mit der Einrichtung gespeichert: Restow speichert, welche Fassung des Textes akzeptiert wurde, wann und von welcher Client-Adresse, vermerkt den neuen ersten Administrator als die Person, die zugestimmt hat, und schreibt die Zustimmung in das Audit-Log.

Schritt 4: Betriebsmodus

Wählen Sie, wie Restow erreicht wird:

Lokaler Modus: erreichbar über IP-Adresse oder localhost, keine öffentliche Domain. Administrationen melden sich mit dem Notfall-Passwort und einem Code aus einer Authenticator-App an.
Öffentlicher Modus: erreichbar über Ihre eigene Domain per HTTPS. Das schaltet Passkeys und Self-Service-Restore frei.

Im öffentlichen Modus legen Sie außerdem die öffentliche URL fest: genau die Adresse, die Browser öffnen (zum Beispiel https://restow.example.com), ohne Pfad. Sie bestimmt überall sonst in Restow die Passkey-Domain und die Entra-Redirect-URI. Sie können den Modus später in den Einstellungen ändern.

Zeitzone (seit 0.4.2)

Derselbe Schritt fragt nach der Zeitzone der Installation. Die Zeitzone Ihres Browsers ist vorausgewählt; wählen Sie eine andere aus der durchsuchbaren Liste, wenn der Server zu einer anderen gehört. Updates, die ein Inhaber für ein Datum und eine Uhrzeit plant, gelten in dieser Zeitzone, der Reiter Updates zeigt ihre Zeiten in ihr, und Ihre eigene Organisation sowie jeder später angelegte Mandant beginnt mit ihr für seine Zeitpläne (ein Mandant kann seine eigene in seinen Kundendaten ändern). Die Überprüfung am Ende zeigt sie.

Sie lässt sich später unter Installation → Server & Betrieb → Server ändern. Lassen Sie sie weg (ein Skript, das die Installation über POST /api/v1/setup einrichtet, darf timeZone auslassen), gilt RESTOW_TIME_ZONE, dann die Prozess-Zeitzone TZ, dann Europe/Berlin. Eine Installation, die vor 0.4.2 eingerichtet wurde, hat keine eigene Zeitzone und nutzt dieselbe Reihenfolge, bis ein Inhaber eine wählt. Siehe Die Zeitzone der Installation und Umgebungsvariablen.

Passkey-Bereitschaft

Restow bietet Passkeys erst an, sobald es nachweisen kann, dass die Domain sauber verbunden ist: Die öffentliche URL muss gesetzt sein, über HTTPS ausgeliefert werden, und die vom Browser gemeldete Origin muss genau dazu passen. Der Assistent prüft das live und zeigt einen der folgenden Gründe:

Angezeigter Grund	Was er bedeutet
Der lokale Modus bindet keine Domain, die WebAuthn aber voraussetzt.	Sie befinden sich im lokalen Modus.
Es ist keine gültige öffentliche URL gesetzt.	Das Feld für die öffentliche URL ist leer oder ungültig.
Die öffentliche URL wird nicht über HTTPS ausgeliefert.	Zertifikat oder Proxy sind noch nicht eingerichtet.
Der Browser meldet eine andere Origin als die konfigurierte URL.	DNS oder ein Proxy zeigen auf etwas anderes als das Eingegebene.

Solange die Passkey-Bereitschaft nicht erreicht ist, greift die Anmeldung auf den Notfall-Passwort-Weg mit Pflicht-Authenticator-App (TOTP) zurück. Das ist der vorgesehene Rückfall, kein eingeschränkter Modus.

Schritt 5: Organisation und erstes Admin-Konto

Zuerst der Name Ihrer Organisation, derjenigen, die diese Installation betreibt, zum Beispiel Ihr Unternehmen (ab 0.2.0). Restow richtet sie als Ihre eigene Organisation ein, den Ort für Ihre eigenen Sicherungen, und zeigt sie als solche an. Das Konto darunter hat die Rolle Provider-Administration: Es richtet Restow ein und legt Mandanten an. Geben Sie ihm einen Namen, eine E-Mail-Adresse und ein Notfall-Passwort (mindestens 12 Zeichen). Direkt nach der ersten Anmeldung richten Sie eine Authenticator-App ein. Von da an fragt Restow deren Code bei jeder Anmeldung zusammen mit dem Passwort ab. Sobald die Passkey-Bereitschaft erreicht ist, fügen Sie unter Anmeldesicherheit im Benutzermenü einen Passkey hinzu; zum Zeitpunkt der Einrichtung ist das optional.

Schritt 6: Mail-Transport

Wie Restow Benachrichtigungen versendet: Berichte, Warnungen, Einladungen. (Der Journal-Empfang des Archivs ist davon getrennt und nur empfangend; er hat mit dieser Einstellung nichts zu tun.) Wählen Sie einen Transport:

SMTP-Server: Host, Port, Verbindungssicherheit (STARTTLS auf 587, implizites TLS auf 465, oder unverschlüsselt nur für einen internen Relay), optional Benutzername/Passwort, Absenderadresse.
Microsoft Graph (Mail.Send): versendet als die Restow-Entra-App-Registrierung, als Anwendung. Erfordert die Anwendungsberechtigung Mail.Send mit Admin-Consent (siehe Erste Schritte und docs/MICROSOFT.md im Produkt-Repository); eine Exchange-Online-Application-Access-Policy kann sie auf ein einzelnes Absenderpostfach beschränken. Eine Mail.Send-Berechtigung, die Sie später erteilen, greift, sobald das zwischengespeicherte Token von Restow abläuft: Diese Mail holt nach einer Ablehnung kein neues Token, wie es Sicherungen seit 0.4.7 tun. Der Entra-Tenant ist eine Tenant-ID (eine GUID) oder eine verifizierte Domain wie contoso.onmicrosoft.com; seit 0.4.5 lehnt der Assistent alles andere mit 422 ab, wie es die Einstellungen schon taten („Geben Sie eine Tenant-ID (GUID) oder eine verifizierte Domain wie contoso.onmicrosoft.com ein.“).

Senden Sie eine Testnachricht an das Admin-Konto, bevor Sie fortfahren. Sie zeigt sofort, ob der Transport funktioniert, und eine fehlgeschlagene Testnachricht blockiert den Abschluss der Einrichtung nicht (korrigieren Sie den Transport bei Bedarf danach in den Einstellungen).

Später einrichten (ab 0.2.0). Der Schritt ist optional: Wählen Sie Später einrichten, um ohne Mail-Transport abzuschließen. Ohne ihn verschickt Restow keine Alarm- und Bericht-Mails, und Einladungen und Passwort-Links gehen nicht per Mail raus: Sie kopieren den Link und geben ihn selbst weiter. Richten Sie ihn später unter Installation → Installation → Benachrichtigungs-Mail (Benachrichtigungs-Mail) ein; bis dahin bleibt „Benachrichtigungsmail getestet“ in der Einrichtungsliste des Dashboards offen. Die Überprüfung zeigt den Mail-Transport dann als „Nicht eingerichtet“. Kommen Sie zu diesem Schritt zurück und wählen Weiter, wird das Formular geprüft und verwendet.

Schritt 7: Überprüfung

Prüfen Sie jeden Eintrag (Sprache, Betriebsmodus, öffentliche URL, Zeitzone, Organisation, Admin-Konto, Mail-Transport oder „Nicht eingerichtet“, Testergebnis) und schließen Sie dann ab. Restow meldet Sie automatisch an; schlägt dieser Schritt fehl, bleibt die Einrichtung selbst trotzdem gespeichert, und Sie melden sich manuell an.

Weiter: Erste Schritte (eine Quelle verbinden und Ihre erste Sicherung ausführen).

Admin-Zugang wiederherstellen

Hat ein Inhaber des Provider-Teams, zum Beispiel der letzte, seinen Passkey, seine Authenticator-App oder sein Passwort verloren, stellen Sie den Zugang auf dem Server wieder her, im api-Container:

docker compose exec api restow admin list
docker compose exec api restow admin recover --email owner@example.com

admin list zeigt die Administrationen der Installation mit Rolle, Anmeldeverfahren (Passwort, Authenticator-App, Zahl der Passkeys) und ob das Konto aktiv ist. admin recover fragt nach einer Bestätigung und nach einem neuen Passwort (verdeckte Eingabe, mindestens 12 Zeichen), entfernt dann die Authenticator-App und die Passkeys des Inhabers und beendet alle seine Sitzungen. Der Inhaber meldet sich mit dem neuen Passwort an und richtet vor allem anderen wieder eine Authenticator-App ein, wie der erste Administrator nach der Einrichtung. Die Wiederherstellung wird im Audit-Log als „Admin-Zugang über die Kommandozeile des Servers wiederhergestellt“ erfasst.

Das funktioniert nur für Inhaber. Jede andere Administration setzt ein Inhaber in der Web-Oberfläche zurück.
In Skripten übergeben Sie das neue Passwort über die Standardeingabe mit --password-stdin --yes (gelesen wird die erste Zeile; --yes überspringt die Bestätigung), zum Beispiel docker compose exec -T api restow admin recover --email owner@example.com --password-stdin --yes < new-password.txt. Löschen Sie die Datei danach.
Der Befehl nutzt die eigene Konfiguration des api-Containers und spricht direkt mit der Datenbank: Er braucht keine laufende api und öffnet keinen Port. Er gibt nichts Geheimes aus. docker compose exec api restow help listet die Optionen.

Wer im api-Container einen Befehl ausführen kann, kontrolliert ohnehin den Server, seine Datenbank und seine Schlüssel. Deshalb liegt die Wiederherstellung dort und nicht in der Web-Oberfläche.