Bring the web documentation in line with develop in every language

- English pages describe backups, the manifest, ROCm GPUs, OCI host directories and storage as develop does, and say user instead of operator
- New paragraph on host directories mounted with everything the host has mounted inside them, and a new update rule for host directories
- The Proxmox Backup Server section of the post-install page is translated into every language
- Spanish and the other six languages follow the updated English

web/messages/de/docs/backup-restore/destinations/index.json

@@ -76,7 +76,7 @@
   },
   "sameArchive": {
     "heading": "Das Archivlayout ändert sich nicht mit dem Ziel",
-    "body": "Innerhalb eines der drei Ziele ist das gleiche <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> Layout vorhanden, das in <em>Funktionsweise</em> beschrieben wird. Ein aus einem lokalen Archiv extrahierter <code>.tar.zst</code>, ein aus PBS wiederhergestellter <code>.pxar</code> und ein mit <code>borg extract</code> extrahiertes Borg-Archiv ergeben alle einen identischen Verzeichnisbaum. Der Wiederherstellungscodepfad (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) liest die gleichen drei Nutzlasten, ohne zu wissen, von welchem Ziel sie kamen."
+    "body": "Unabhängig davon, wo das Backup gespeichert ist, enthält es immer dieselben drei Blöcke, die in <em>Funktionsweise</em> beschrieben sind: das Dateisystem (<code>rootfs/</code>), die Metadaten (<code>metadata/</code>) und das Manifest (<code>manifest.json</code>). Das Entpacken eines lokalen <code>.tar.zst</code>-Archivs, das Wiederherstellen eines <code>.pxar</code> aus PBS oder das Entpacken eines Borg-Archivs ergeben alle einen identischen Verzeichnisbaum. Die Wiederherstellung liest daher immer dieselben Dateien, unabhängig davon, von welchem Ziel das Backup stammt."
   },
   "extractStandalone": {
     "heading": "Extrahieren eines Backups außerhalb von ProxMenux",

web/messages/de/docs/backup-restore/destinations/pbs.json

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Repository-Auswahl",
-    "intro": "ProxMenux entdeckt PBS-Repositories aus zwei Quellen in jedem Backup. Der Bediener wählt einen aus einem einheitlichen Menü aus; die Auswahl bestimmt <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> und <code>HB_PBS_FINGERPRINT</code> für den Lauf.",
+    "intro": "ProxMenux ermittelt bei jedem Backup PBS-Repositories aus zwei Quellen. Der Benutzer wählt eines aus einem einheitlichen Menü aus; für diesen Lauf bestimmt die Auswahl, an welchen Server und welchen Datenspeicher das Backup gesendet wird, mit welchem Passwort es sich authentifiziert und welcher <em>Fingerabdruck</em> das Zertifikat validiert.",
     "sourceRows": [
       {
         "source": "Proxmox storage.cfg (automatisch erkannt)",
@@ -46,7 +46,7 @@
     "backupIdTitle": "Backup-ID-Bezeichnung",
     "backupIdBody": "Die Standard-Backup-ID ist <code>hostcfg-HOSTNAME</code>. Vor dem Upload wird sie bestätigt oder bearbeitet. Zeichen außerhalb von <code>[A-Za-z0-9_-]</code> sowie abschließende Bindestriche werden entfernt. Die Wiederverwendung derselben ID bei weiteren Läufen ist beabsichtigt: PBS behandelt die ID als <em>Gruppe</em>. Jedes weitere Backup erscheint als neuer Eintrag in dieser Gruppe und nutzt die Deduplizierung mit früheren Backups.",
     "pxarTitle": "Warum die Quelle die vollständige Staging-Wurzel ist",
-    "pxarBody": "Die <code>.pxar</code>-Quelle ist die gesamte <code>staging_root</code> - <code>rootfs/</code>, <code>metadata/</code> und <code>manifest.json</code> zusammen. Frühere Versionen bestanden <code>$staging_root/rootfs</code> als Quelle; Das ließ <code>metadata/</code> aus dem Archiv und die Kompatibilitätsprüfung der Wiederherstellung hatte nichts zu lesen, was selbst bei Wiederherstellungen des gleichen Hosts zu Cross-Host-Warnungen führte. Alte Backups, die mit der Rootfs-only-Quelle erstellt wurden, werden immer noch korrekt über den <code>_rs_check_layout</code>-Fall-3-Zweig wiederhergestellt, der einen flachen <code>etc/var/root/usr</code>-Baum zurück in eine <code>rootfs/</code>-Hierarchie wickelt."
+    "pxarBody": "Das <code>.pxar</code>-Archiv packt das gesamte Arbeitsverzeichnis: das Dateisystem des Hosts (<code>rootfs/</code>), die Metadaten (<code>metadata/</code>) und das Manifest (<code>manifest.json</code>). Bei der Wiederherstellung vergleicht ProxMenux das Manifest mit dem Zielhost, um festzustellen, ob beide gleichwertig sind, ob sich die Hardware geändert hat oder ob es sich um eine andere Maschine handelt, und passt den Ablauf entsprechend an. Ältere Backups, die von früheren ProxMenux-Versionen erstellt wurden und nur das Dateisystem packten, werden weiterhin korrekt wiederhergestellt: Die Wiederherstellung erkennt dieses alte Format und ordnet es automatisch neu an."
   },
   "encryption": {
     "heading": "Clientseitige Verschlüsselung",
@@ -63,7 +63,7 @@
     "recoveryTitle": "Schlüssel auf PBS hinterlegen — der Betreiber entscheidet",
     "recoveryBody": "Direkt nach Auswahl der Schlüsseldatei fragt ProxMenux ausdrücklich <em>Schlüssel auf PBS hochladen?</em> und bietet zwei Antworten. <strong>Erst wenn der Betreiber Ja wählt, wird ein Wiederherstellungsartefakt auf PBS hochgeladen.</strong> Vorgabe ist <em>Nein, nur lokal behalten</em>: Die Schlüsseldatei bleibt am kanonischen lokalen Pfad, ProxMenux lädt kein Wiederherstellungsartefakt auf PBS hoch und der Betreiber sorgt selbst für eine externe Kopie. Die Schaltfläche <em>Schlüsseldatei herunterladen</em> in der PBS-Zielzeile des Monitors stellt sie bei Bedarf bereit. Bei <em>Ja, hochladen</em> wird zweimal eine Wiederherstellungspassphrase abgefragt und auf Übereinstimmung geprüft. ProxMenux schützt die Schlüsseldatei damit mittels AES-256-CBC und PBKDF2 (600.000 Iterationen, zufälliges Salt) und erzeugt <code>pbs-key.recovery.enc</code>. Jedes weitere verschlüsselte Backup lädt diese Hülle als zugehörige Backup-Gruppe auf PBS hoch. Dabei werden weder die Passphrase noch die Schlüsseldatei im Klartext an PBS gesendet. Die Entscheidung lässt sich jederzeit im Monitor ändern: Der Schalter in der PBS-Zielzeile wählt Ja oder Nein und übernimmt je nach Zustand sofort Upload starten, Upload stoppen oder Passphrase aktualisieren.",
     "blobUploadTitle": "Gepaarte Backup-Gruppe auf PBS",
-    "blobUploadBody1": "Ist die Hinterlegung auf <em>Ja, hochladen</em> gesetzt, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie heißt wie die Host-Gruppe, ergänzt um <code>-keyrecovery</code>. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. <strong>Die Hülle verlässt den Host niemals im Klartext</strong>: Noch vor der Übertragung verschlüsselt der Host sie mit AES-256-CBC und PBKDF2 (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
+    "blobUploadBody1": "Lautet die Antwort <em>Ja, hochladen</em>, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie trägt denselben Namen wie die Host-Gruppe, endet aber auf <code>-keyrecovery</code>. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. <strong>Die Hülle verlässt den Host niemals im Klartext</strong>: Noch bevor ein Byte übertragen wird, verschlüsselt der Host sie selbst mit AES-256-CBC und PBKDF2 (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
     "envelopeSecurityTitle": "Ist das Hochladen der keyrecovery-Datei in PBS ein Sicherheitsrisiko?",
     "envelopeSecurityBody": "Die keyrecovery-datei ist verschlüsselt in transit und in ruhe. Die Wiederherstellungspassphrase verlässt den Host nie: Verschlüsselung geschieht lokal vor dem Upload, und PBS sieht immer nur das bereits verschlüsselte Ergebnis. Ein PBS-Administrator - oder jeder, der Zugriff auf den Datenspeicher hat - kann die KeyRecovery-Datei herunterladen, aber ohne die Wiederherstellungspassphrase können sie die Keyfile nicht lesen: Es ist undurchsichtiger Geheimtext. Das Rekonstruieren der Keyfile erfordert beide Teile gleichzeitig, die KeyRecovery-Datei und die Passphrase, und nur der Operator hält beide.",
     "blobUploadConstraintTitle": "Warum zwei Gruppen statt einer einzigen verschlüsselten",
@@ -73,7 +73,7 @@
     "recoverTitle": "Wiederherstellung auf einem neu installierten Host",
     "recoverBody": "Fehlt die lokale Schlüsseldatei am kanonischen Pfad, etwa nach einer Neuinstallation oder ausdrücklichem Löschen, versucht die Wiederherstellung drei Quellen der Reihe nach und stoppt bei der ersten brauchbaren Schlüsseldatei. Erstens wird eine zum gewählten PBS-Repository passende, von PVE verwaltete Datei unter <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code> ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe <code>-keyrecovery</code> vorhanden ist, deren neuester Snapshot heruntergeladen und die Wiederherstellungspassphrase zum Entschlüsseln abgefragt. Funktioniert beides nicht oder lehnt der Betreiber die Optionen ab, fragt der dritte Schritt nach dem absoluten Pfad der Schlüsseldatei auf diesem Host und kopiert sie an den kanonischen Pfad. Der Monitor bietet denselben Importablauf im Backup-Detaildialog. Oben erscheint ein gelbes Feld, wenn Wiederherstellen, Herunterladen oder Inhalt anzeigen eine nicht installierte Schlüsseldatei benötigen. Ist eine Datei installiert, passt aber nicht zum Backup, meldet PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Dieselben drei Aktionen zeigen dann ein strukturiertes gelbes Feld mit dem erforderlichen Manifest-Fingerabdruck an, damit der Betreiber die passende Schlüsseldatei für dieses Backup erkennen und importieren kann.",
     "monitorManagementTitle": "Schlüsseldatei im Monitor verwalten",
-    "monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung direkt in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Es gibt drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Datei in den Browser des Betreibers; <em>Hochladen</em> ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; <em>Löschen</em> entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Jede Aktion nutzt dieselben Flask-Endpunkte wie die Terminaloberfläche. Die Wirkung auf Dateien und den PBS-Zustand ist deshalb bei beiden Oberflächen identisch."
+    "monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Die Zeile bietet drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Schlüsseldatei in den Browser des Benutzers, <em>Hochladen</em> ersetzt die installierte Schlüsseldatei durch eine vom Benutzer bereitgestellte (die bisherige Datei wird erst überschrieben, nachdem die neue korrekt an ihrem Pfad angekommen ist), und <em>Löschen</em> entfernt die Schlüsseldatei vom Host. Direkt daneben befindet sich der Schalter für die Wiederherstellungshülle: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, ein Passphrase-Feld, das bei Auswahl von Ja erscheint, und eine Schaltfläche, die dem aktuellen Zustand folgt: <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Die Steuerelemente im Monitor und der Dialog in der Shell führen im Hintergrund dasselbe aus, sodass das Ergebnis auf dem Datenträger und auf PBS identisch ist, unabhängig davon, welches von beiden verwendet wird."
   },
   "restoreAccess": {
     "heading": "Abruf auf der Wiederherstellungsseite",

web/messages/de/docs/backup-restore/how-it-works.json

@@ -121,7 +121,7 @@
       }
     ],
     "schemaTitle": "Validierung des Schemas",
-    "schemaBody": "Das Manifest bestätigt gegen <code>scripts/backup_restore/schema/manifest.schema.json</code>. Das Ausführen von <code>build_manifest.sh --validate</code> löst eine Python-seitige JSON-Schemavalidierung aus (erfordert <code>python3</code> + <code>jsonschema</code>). Wenn das Modul nicht vorhanden ist, wird die Überprüfung still übersprungen - die Validierung ist in erster Linie eine Entwicklerhilfe, keine Laufzeitabhängigkeit."
+    "schemaBody": "ProxMenux liefert eine Vorlage mit, die beschreibt, welche Felder das Manifest enthalten muss und welche Form jedes Feld hat. Beim Erstellen eines Backups kann das Manifest automatisch mit dieser Vorlage abgeglichen werden, sodass ein Collector, der fehlerhaftes JSON oder ein falsch geschriebenes Feld erzeugt hat, sofort erkannt wird. Die Prüfung ist für die Entwicklung von ProxMenux selbst gedacht: Auf einem System, auf dem sie nicht installiert ist, funktioniert das Backup wie gewohnt, und das Manifest wird trotzdem erzeugt."
   },
   "applications": {
     "heading": "Das Anwendungsinventar",

web/messages/de/docs/backup-restore/scheduled-jobs.json

@@ -127,7 +127,7 @@
   },
   "notifications": {
     "heading": "Benachrichtigungen",
-    "body": "Jeder geplante Lauf feuert die gleichen <code>hb_notify_lifecycle</code>-Ereignisse ab wie der interaktive Fluss (<code>start</code>, <code>complete</code>, <code>fail</code>). Wenn Benachrichtigungskanäle im Monitor konfiguriert sind, tauchen unbeaufsichtigte Jobs auf die gleiche Weise wie manuelle Backups auf - ein Benutzer muss das Protokoll nicht überprüfen, um zu wissen, ob ein Job erfolgreich war."
+    "body": "Jeder geplante Lauf löst dieselben <code>hb_notify_lifecycle</code>-Ereignisse aus wie der interaktive Ablauf (<code>start</code>, <code>complete</code>, <code>fail</code>). Sind im Monitor Benachrichtigungskanäle konfiguriert, melden unbeaufsichtigte Jobs ihre Ergebnisse auf die gleiche Weise wie manuelle Backups – ein Benutzer muss das Protokoll nicht prüfen, um zu wissen, ob ein Job erfolgreich war."
   },
   "whereNext": {
     "heading": "Wohin Sie als nächstes gehen",