Lizenz und Editionen

Backup und Restore sind in jeder Edition vollständig enthalten, ohne Postfach-Obergrenze. Eine Lizenz drosselt nie, wie viel Sie schützen oder zurückholen können. Die Zahl der Postfächer und die Zahl der Mandanten begrenzt die Software technisch nicht. Business ist für eine Organisation lizenziert, Service Provider für beliebig viele Mandanten (nur Ihre eigenen Kunden); Sie nutzen die Lizenz in dem Umfang, für den Sie sie erworben haben. Diese Zahlen sind eine Ehrenregel aus den Lizenzbedingungen und werden nie im Code durchgesetzt. Restow zeigt die Zahl der geschützten Postfächer auf der Karte Geschützte Postfächer im Reiter Status der Übersicht (und in GET /api/v1/usage) für Ihre eigene Übersicht; nichts begrenzt sie.

Editionen

Edition	Mandanten	Preis (netto)	Was dazukommt
Community	Einer	Kostenlos, kein Lizenzschlüssel, Apache 2.0	Mehrere Provider-Administrationen mit Rollen, seit 0.3.1 (Mandanten-Administrationen und Nutzer lassen sich in jeder Edition einladen). Microsoft-365- und IMAP-Backup, nicht-destruktiver Restore, wöchentliche Restore-Prüfung (Verifizierung per Stichproben-Rücklesung), Alarme, das Archiv (SHA-256-Hash-Kette mit Kettenprüfung, Suche über Betreff, Adressen und Nachrichtentext importierter Mail, gespeist durch Mail-Import mit Archivierung, Export als EML in einer ZIP-Datei oder als MBOX), Endpoint-Backup für Server und Clients (Linux und macOS), Proxmox-VE-Backup von VMs und Containern (eine Preview, seit 0.3.1, in jeder Edition), Mail-Datei-Import und -Export, Fehlererklärungen, die Opt-in-Update-Prüfung, einfaches Betriebsprotokoll (Jobverlauf, Fehler), REST-API. Alles, was mit 0.4.0 kam, gehört ebenfalls zu jeder Edition: die Sicherung von Freigaben (SMB und NFS, ohne Agent), unveränderbare Backups (S3 Object Lock je Repository, eine Löschverzögerung für Verzeichnisse), die Ransomware-Erkennung mit angehaltener Aufbewahrung, die Benachrichtigungsmatrix, Backup und Restore von SharePoint Online, Richtlinien für Agenten, Datei-Restore für die Restore-Rolle, die Erweiterungen für Proxmox VE (Fortschritt, Startprüfungen, Datei-Restore von Containern und, als Preview, von VMs), Updates, die laufende Sicherungen abwarten oder sauber anhalten, das Verschieben der Datenbank auf einen anderen Datenträger mit einer Warnung bei wenig Speicherplatz und das Speicherwachstum im Dashboard. Jedes Lesen und jeder Restore wird in das hashverkettete Audit-Log geschrieben, ohne Ansicht.
Business	Eine Organisation	Einmalige Lizenz: 595 € Listenpreis ab allgemeinem Release; 476 € im Vorverkauf. Freiwilliges Update-Jahr: 295 € pro Jahr	Ein zeitlich unbefristetes Recht, die Business-Module für eine Organisation zu nutzen. Die für den GoBD-konformen Einsatz ausgelegte Schicht des Archivs: Empfang von Exchange-Online-Journalberichten und von Kopien, die ein Mailanbieter weiterleitet (beides braucht ein eigenes TLS-Zertifikat), seit 0.4.4 die Erfassung aus den Postfächern (Graph für Microsoft 365, IMAP-Archivierung für IMAP und Google Workspace; zeitnah, nicht vollständig), durchgesetzte Aufbewahrung, Legal Hold. Die Audit-Log-Ansicht (Liste, Filter, Details eines Eintrags, Prüfung der Hash-Kette) und zeitgesteuerte Berichte per E-Mail (alles verfügbar), seit 0.3.1 dazu den Audit-Log-Export (CSV, JSON mit Hashes). Anmeldung mit Microsoft und Single Sign-on (SSO), Vier-Augen-Freigabe und ein signierter Wiederherstellungsnachweis sind geplant, ohne Termine. Das Provider-Team gehört seit 0.3.1 zu jeder Edition.
Service Provider	Beliebig viele (Ihre eigenen Kunden)	Einmalige Lizenz: 1.950 € Listenpreis ab allgemeinem Release; 1.560 € im Vorverkauf. Freiwilliges Update-Jahr: 595 € pro Jahr	Alles aus Business, für beliebig viele Mandanten (Ihre eigenen Kunden), dazu mehrere Mandanten mit Mandantenverwaltung, die mandantenübergreifende REST-API, delegierte Mandanten-Administrationen, die Provider-Übersicht über alle Mandanten (Mandantenberichte) und die Beschränkung einzelner Teammitglieder auf ausgewählte Mandanten (alles verfügbar), und seit 0.4.0 Alle Mandanten unter Jobs, das jeden Mandanten mit seinen Jobs, was läuft und wartet und wie die neuesten Sicherungen endeten auflistet. White Label ist geplant.

Den aktuellen Stand jeder Funktion zeigen die Roadmap und die Preisseite. Die Preise gelten nur für Unternehmer (§ 14 BGB), zuzüglich Umsatzsteuer, soweit sie anfällt.

Was „Einmalkauf“ bedeutet

Die Lizenz selbst ist ein Einmalkauf und unbefristet. Für Updates gelten eigene, freiwillige Bedingungen:

Eine Lizenz wird einmal gekauft. Nichts verlängert sich automatisch; es gibt kein Abo.
Lizenzen aus dem Vorverkauf enthalten alle Updates der Versionsreihe 1.x. Ab Version 1.0 enthält eine Lizenz 12 Monate Updates, gerechnet ab Übermittlung des Lizenzschlüssels. Danach ist ein Update-Jahr freiwillig: Business 295 €, Service Provider 595 € netto pro Jahr, jeweils für ein Jahr gekauft. Update-Jahre gibt es ab Version 1.0. Es gibt keinen Preis pro Postfach, Nutzer oder Mandant. Lizenzen aus dem Vorverkauf brauchen ein Update-Jahr erst für eine spätere Versionsreihe 2.x.
Nach einer Lücke kostet das nächste Update-Jahr den normalen Preis, ohne Nachzahlung und ohne Aufschlag. Es gilt für jede Version, die bis zu seinem Ende erscheint, auch die aus der Lücke.
Ohne Update-Jahr läuft jede bis dahin erschienene Version dauerhaft weiter, mit allen Modulen der Edition; es gibt kein Nach-Hause-Telefonieren und keine Abschaltung. Sie erhält keine Sicherheitsupdates mehr: Diese erscheinen nur in neuen Versionen, für ältere gibt es keine. In später erschienenen Versionen bleiben die Business- und Service-Provider-Module aus, bis Sie ein Update-Jahr kaufen.
Endet die Entwicklung, wird das mindestens zwölf Monate vorher angekündigt, und die Business- und Service-Provider-Module werden danach als Open Source unter der Lizenz des Kerns (Apache 2.0) veröffentlicht; Ihre Installation läuft ohne Lizenzschlüssel weiter.
Eine Lizenz enthält die Software und die oben beschriebenen Updates. Support, Einrichtung, Betrieb und ein SLA sind nicht enthalten; solche Leistungen brauchen einen gesonderten Vertrag.

Early Access

Bis zum allgemeinen Release werden Lizenzen als Early Access zum Vorverkaufspreis verkauft:

Eine im Vorverkauf gekaufte Lizenz gilt dauerhaft, auch nach dem allgemeinen Release, und enthält alle Updates der Versionsreihe 1.x.
Als in Entwicklung gekennzeichnete Funktionen werden nachgeliefert, ohne Zusage eines Zeitpunkts.
Während der Beta darf Restow nicht Ihre einzige Sicherung sein.
Eine im Vorverkauf gekaufte Lizenz können Sie innerhalb von 30 Tagen ohne Angabe von Gründen zurückgeben. Dieses Rückgaberecht ist freiwillig.

Verbindlich sind die Lizenzbedingungen.

Lizenzen

Restow ist ein Repository und ein Release, veröffentlicht in zwei Builds:

Vollständige Images (ghcr.io/restow-backup/restow und ghcr.io/restow-backup/restow-web): der Kern plus die Business- und Service-Provider-Module. Welche davon aktiv sind, entscheidet ein Lizenzschlüssel zur Laufzeit; ohne Schlüssel läuft die Installation als Community.
Community-Images (ghcr.io/restow-backup/restow-community und ghcr.io/restow-backup/restow-web-community): nur der Kern, ohne jeden Code aus ee/.

Beide Builds nutzen dasselbe Datenbankschema; Sie wechseln, indem Sie RESTOW_IMAGE und RESTOW_WEB_IMAGE in .env ändern und docker compose up -d ausführen (siehe Erste Schritte als Administrator).

Der Kern (alles außerhalb von ee/: Backup, Restore, das Archiv, Endpoint-Backup samt Agent, Mail-Datei-Import und -Export, die Integrations-API, die Web-Oberfläche) ist Open Source unter der Apache License 2.0. Die Business- und Service-Provider-Module in ee/ sind quelloffen einsehbar (source-available) unter der Lizenz in ee/LICENSE: Ihre Nutzung im Produktivbetrieb setzt einen gültigen Lizenzschlüssel unter den Restow-Lizenzbedingungen voraus (verbindlich; englische Übersetzung). Der Quellcode liegt im Repository.

Installation → Über. Jede Installation zeigt unter Installation → Über ihren Produktnamen, die Version, den Commit, die Lizenz des Kerns (Apache-2.0), einen Link zum Quellcode des laufenden Releases und die Lizenzen von Drittanbietern. In den vollständigen Images wird der Lizenzschlüssel im selben Tab verwaltet, und der Menüeintrag Installation → Lizenz (für Provider-Administratoren) öffnet genau diesen Bereich.

Gesperrte Funktionen bleiben in den vollständigen Images sichtbar. Ohne Schlüssel erscheinen die Menüeinträge von Business- und Service-Provider-Funktionen ausgegraut mit einem Schloss, das zu Installation → Über führt (dem Bereich, den Installation → Lizenz öffnet), und ihre API-Routen antworten mit 403 und urn:restow:problem:edition-required. Es gibt keine Banner, Pop-ups oder Zähler.

Die Community-Images haben keine Lizenzeinstellungen. Sie zeigen keinen Lizenzbereich und keine gesperrten Einträge von Business oder Service Provider: Diese Funktionen (zum Beispiel die Audit-Log-Ansicht) gibt es dort nicht. Das Provider-Team gibt es: mehrere Administrationen mit Rollen gehören zum Kern. Kernfunktionen, die nur eine kostenpflichtige Edition anbietet, etwa ein zweiter Mandant, die Beschränkung eines Teammitglieds auf ausgewählte Mandanten, Provider-API-Schlüssel, die Übersicht (Reiter Status) über alle Mandanten, die Statistik aller Mandanten oder zeitgesteuerte Zusammenfassungsberichte, antworten mit 403 und urn:restow:problem:feature-unavailable. Um sie zu nutzen, wechseln Sie zu den vollständigen Images und installieren einen Schlüssel.

In der Beta 0.4.7 wird in jeder Edition jedes Lesen und jeder Restore in das hashverkettete Audit-Log geschrieben. Die Audit-Log-Ansicht (Liste, Filter, Details eines Eintrags, Prüfung der Hash-Kette) und seit 0.3.1 der Audit-Log-Export (CSV, JSON mit Hashes) sind Funktionen von Business und Service Provider und verfügbar. Das Betriebsprotokoll (Jobverlauf und Fehler) bleibt in Community. Mehrere Administrationen mit Rollen gibt es in jeder Edition; ein Mitglied auf bestimmte Mandanten zu beschränken ist Service Provider. Die Release-Notes von 0.4.0 sagen, dass alles, was sie hinzufügen, zu jeder Edition (dem Community-Kern) gehört, sofern nicht anders gekennzeichnet, und kennzeichnen einen Punkt anders: Alle Mandanten in Jobs, eine Ansicht von Service Provider. Anmeldung mit Microsoft, Single Sign-on (SSO) und White Label kamen nicht mit 0.4.0; sie sind geplant (siehe die Roadmap).

Der Lizenzschlüssel

Business und Service Provider werden durch einen Ed25519-signierten Lizenzschlüssel freigeschaltet, gebunden an die Installations-ID dieser Installation und vollständig offline gegen einen in den Release-Images eingebauten öffentlichen Schlüssel geprüft. RESTOW_LICENSE_PUBLIC_KEY ersetzt diesen Schlüssel; die Variable ist nur für Entwicklung und Tests des vollständigen Builds gedacht. Installieren Sie einen Schlüssel in den vollständigen Images unter Installation → Lizenz → Schlüssel installieren; Restow nennt dafür Ihre Installations-ID. Es gibt kein Nach-Hause-Telefonieren und kein Ablaufdatum: Ein Schlüssel schaltet eine laufende Installation nie ab, und eine Lizenz schaltet den Funktionsumfang einer Edition frei, keine Postfachzahl. Es gibt also nichts, was die Software drosseln könnte. Seit 0.4.5 sagt ein Schlüssel außerdem, welche Releases er abdeckt, siehe Updates und der Lizenzschlüssel. Nach dem Entfernen eines Schlüssels läuft die Installation wieder als Community; das Entfernen wird selbst im Audit-Log erfasst.

RESTOW_EDITION wirkt nur zusammen mit RESTOW_DEMO=true, für die öffentliche Demo. Überall sonst wird die Variable ignoriert; eine Produktivinstallation bekommt ihre Edition aus einem installierten Schlüssel.

Die Lizenzprüfung arbeitet offline, nimmt nie Kontakt zum Lizenzgeber auf und schaltet nie eine Installation ab. Die einzige Stelle, an der ein Schlüssel entscheidet, ob etwas startet, ist ein Release, das der Schlüssel nicht abdeckt, und dann läuft die installierte Version einfach weiter (siehe unten). Restore wird nie begrenzt, mit oder ohne Schlüssel.

Updates und der Lizenzschlüssel

Seit 0.4.5 kann ein Business- oder Service-Provider-Schlüssel sagen, welche Releases er abdeckt. Das gilt nur für die vollständigen Images; der Community-Build braucht keinen Schlüssel und prüft nichts. Ein abgedecktes Release arbeitet dauerhaft mit allen Modulen der Edition des Schlüssels. Ob ein Release abgedeckt ist, wird nur geprüft, wenn es über den Updater installiert wird und wenn es startet, bevor es die Datenbank anfasst, nie während Restow läuft.

Was ein Schlüssel abdeckt

Schlüssel	Deckt ab
Beta-Lizenz: jeder bisher ausgestellte Schlüssel und jeder Schlüssel, der vor 0.4.5 installiert wurde	Jedes 0.x-Release und jedes Release der Versionsreihe 1.x, dauerhaft.
Ein Schlüssel mit Update-Zeitraum (`updates_until`): Ab 1.0 enthält eine Lizenz 12 Monate Updates, danach folgt ein freiwilliges Update-Jahr (Was „Einmalkauf“ bedeutet)	Jedes Release, das bis zum Ende des letzten Tages des Update-Zeitraums (UTC) erschienen ist, gleich welche Version.
Eine Verlängerung (ein weiteres Update-Jahr)	Ein neuer Schlüssel derselben Edition, dessen Update-Zeitraum ein Jahr nach dem vorigen endet.

Alle bisher ausgestellten Schlüssel sind Beta-Lizenzen und decken weiter jedes 0.x- und 1.x-Release ab; das Installieren von 0.4.5 oder später ändert für sie nichts. Das Schlüsselformat restow-license-v1 hat seit 0.4.5 drei optionale Mitglieder und ignoriert Mitglieder, die es nicht kennt, sodass Schlüssel, die der Lizenzserver später ausstellt, weiter gültig bleiben:

Mitglied	Bedeutung
`series`	Die Hauptversionsreihe, die ein Schlüssel ohne Update-Zeitraum abdeckt (`"1"`, wenn sie fehlt; die Reihe 1 deckt auch jedes 0.x-Release ab).
`updates_until`	Der letzte Tag des Update-Zeitraums (`JJJJ-MM-TT`, UTC). Fehlt er: kein Update-Zeitraum.
`kid`	Die ID des Signaturschlüssels des Herstellers, damit der Schlüssel ohne Bruch bereits ausgestellter Schlüssel getauscht werden kann. Fehlt sie: der ursprüngliche Herstellerschlüssel.

Die sechs heutigen Mitglieder (edition, mailbox_limit, multi_tenant, licensee, installation_id, issued_at) bleiben Pflicht, und mailbox_limit behält seine Bedeutung (keine). Ein Schlüssel mit den neuen optionalen Mitgliedern lässt sich nur ab 0.4.5 prüfen: Eine Installation von vor 0.4.5 lehnt ihn als invalid_payload ab, aktualisieren Sie also zuerst mit dem Schlüssel, den Sie haben. Das genaue Format für den Aussteller steht in ee/licensing/KEY-FORMAT.md im Repository.

„Erschienen“ meint das Release-Datum, das die Images des Releases tragen: das Commit-Datum seines Release-Tags. Restow liest es als RESTOW_RELEASED_AT (beim Bauen in das Image geschrieben), GET /api/v1/status meldet es als releasedAt im Objekt version, und die Release Notes veröffentlichen dasselbe Datum in einer Zeile released: neben den Image-Digests, woher die Update-Prüfung es kennt, bevor etwas installiert wird. Ein Build ohne Release-Datum, etwa ein Entwicklungs-Build, gilt als abgedeckt.

Ist ein Update-Zeitraum zu Ende, arbeitet die installierte Version mit allen Modulen weiter, und ebenso jede Version, die bis zum Ende des Zeitraums erschienen ist: Sie können sie weiter installieren. Später erschienene Versionen können mit diesem Schlüssel die Business- oder Service-Provider-Module nicht betreiben. Ältere Versionen erhalten keine Sicherheitsupdates, siehe Was „Einmalkauf“ bedeutet.

Was die Lizenzseite zeigt

Installation → Lizenz zeigt die Update-Bedingungen des installierten Schlüssels in der Zeile Updates: alle 1.x (Beta-Lizenz) oder bis ein Datum. Ab 30 Tage vor dem Ende eines Update-Zeitraums und danach sagt ein kurzer Hinweis auf derselben Seite es: Jede bis dahin erschienene Version arbeitet dauerhaft mit allen Modulen weiter, und für spätere Versionen können Sie den Update-Zeitraum verlängern, indem Sie dort den neuen Schlüssel installieren. Es wird keine E-Mail verschickt.

Schlüssel installieren und verlängern

Ein neuer Schlüssel ersetzt den aktiven, auch solange der aktive noch gilt: So wird eine Verlängerung installiert, auf dieselbe Weise wie der erste Schlüssel. Die früheren Schlüssel bleiben im Verlauf der Installation, und jede Installation, jeder Austausch und jedes Entfernen steht im Audit-Log (license.installed, license.replaced, license.removed), mit den Update-Bedingungen des Schlüssels und der Angabe, ob sie die laufende Version abdecken.
Ein Schlüssel, der die laufende Version nicht abdeckt, wird abgelehnt, mit 422 urn:restow:problem:license-invalid und dem Grund outside_update_period: Seine Module blieben auf dieser Version aus. Installieren Sie ihn auf einer Version, die er abdeckt, oder einen Schlüssel, dessen Update-Zeitraum diese Version abdeckt.
Ein Schlüssel, der mit einem Herstellerschlüssel signiert ist, den diese Version nicht kennt, wird als unknown_signing_key abgelehnt: Aktualisieren Sie zuerst, installieren Sie den Schlüssel danach.

Update-Prüfung und Updater

Die Update-Prüfung markiert jedes angebotene Release, das der installierte Business- oder Service-Provider-Schlüssel nicht abdeckt, und sagt das ruhig auf der Seite Updates: Die Version liegt außerhalb des Update-Zeitraums, die installierte Version arbeitet weiter, und die neueste Version innerhalb des Zeitraums, falls eine angeboten wird, lässt sich wie gewohnt installieren. Der Updater weigert sich, ein nicht abgedecktes Release anzukündigen oder zu planen (409 urn:restow:problem:update-not-covered). Die Benachrichtigungsglocke und die Alarmregeln für Update verfügbar nennen nur das neueste abgedeckte Release. Siehe Updates.

Ein Release, das der Schlüssel nicht abdeckt, startet

Ein Update von Hand (docker compose pull, ein neues RESTOW_IMAGE) umgeht die Update-Prüfung. Die api der neuen Version prüft dann den installierten Schlüssel, bevor sie eine Datenbankmigration anwendet. Ist ein Business- oder Service-Provider-Schlüssel installiert und deckt die Version nicht ab, startet die api nicht und schreibt nichts in die Datenbank. Ihr Log nennt die Version, ihr Release-Datum, das Ende des Update-Zeitraums und das letzte Release-Datum, das der Schlüssel abdeckt. Es muss nichts zurückgespielt werden, denn keine Migration ist gelaufen. Entweder

gehen Sie auf die Version zurück, die Sie vorher betrieben haben, oder auf eine Version, die der Schlüssel abdeckt (setzen Sie die vorherigen Tags in RESTOW_IMAGE und RESTOW_WEB_IMAGE zurück, dann docker compose up -d), und installieren dort einen verlängerten Schlüssel; oder
Sie starten die neue Version als Community: Setzen Sie RESTOW_RUN_AS_COMMUNITY=1 in der .env und führen Sie docker compose up -d aus. Die Business- und Service-Provider-Module bleiben aus, und nichts wird verändert oder gelöscht (Archive, Legal Holds und weitere Mandanten bleiben unberührt in der Datenbank). Die Lizenzseite sagt, warum. Installieren Sie einen Schlüssel, der die Version abdeckt, sind die Module sofort wieder an; die Variable wirkt dann nicht mehr und kann entfernt werden.

Der Updater (opt-in) sieht, dass die api nicht startet, und stellt die vorherige Version selbst wieder her; da keine Migration lief, braucht es keinen Dump.

Die Prüfung hält nie eine Installation ohne Schlüssel an, nie die öffentliche Demo, nie einen Entwicklungs-Build und nie ein Release mit einer Beta-Lizenz (jeder bisher ausgestellte Schlüssel). RESTOW_RUN_AS_COMMUNITY wirkt nicht, solange der Schlüssel die laufende Version abdeckt. Restow liest die Uhr nie, um zu entscheiden, was funktioniert: Die Lizenzseite nutzt sie nur, um zu entscheiden, wann sie das Ende eines Update-Zeitraums erwähnt.