From a2b96bf6a4a4551c9c9c80a5e58a0dd817c62c73 Mon Sep 17 00:00:00 2001 From: MacRimi Date: Sun, 18 Oct 2026 19:02:17 +0200 Subject: [PATCH] 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 --- .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../de/docs/backup-restore/how-it-works.json | 2 +- .../docs/backup-restore/scheduled-jobs.json | 2 +- .../de/docs/oci-manager/hardware.json | 2 +- .../de/docs/oci-manager/lifecycle.json | 1 + .../de/docs/oci-manager/storage-network.json | 5 +- web/messages/de/docs/post-install/index.json | 11 + .../docs/backup-restore/creating-backups.json | 117 +++++++-- .../backup-restore/destinations/borg.json | 10 +- .../backup-restore/destinations/index.json | 2 +- .../backup-restore/destinations/local.json | 24 +- .../docs/backup-restore/destinations/pbs.json | 24 +- .../en/docs/backup-restore/how-it-works.json | 4 +- .../docs/backup-restore/scheduled-jobs.json | 2 +- web/messages/en/docs/monitor/access-auth.json | 6 +- .../en/docs/monitor/ai-assistant.json | 2 +- .../en/docs/monitor/dashboard/settings.json | 2 +- .../en/docs/monitor/dashboard/storage.json | 2 +- .../en/docs/monitor/dashboard/vms-lxcs.json | 2 +- .../en/docs/oci-manager/hardware.json | 247 ++++++++++++++---- .../en/docs/oci-manager/lifecycle.json | 1 + .../en/docs/oci-manager/storage-network.json | 184 ++++++++++--- .../en/docs/post-install/storage.json | 2 +- .../en/docs/post-install/updates.json | 4 +- .../en/docs/settings/beta-program.json | 4 +- .../en/docs/settings/proxmenux-monitor.json | 2 +- web/messages/en/guides/nvidia-manual.json | 2 +- .../docs/backup-restore/creating-backups.json | 2 +- .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 4 +- .../es/docs/backup-restore/how-it-works.json | 2 +- .../es/docs/oci-manager/hardware.json | 2 +- .../es/docs/oci-manager/lifecycle.json | 1 + .../es/docs/oci-manager/storage-network.json | 5 +- .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../fr/docs/backup-restore/how-it-works.json | 2 +- .../docs/backup-restore/scheduled-jobs.json | 2 +- .../fr/docs/oci-manager/hardware.json | 2 +- .../fr/docs/oci-manager/lifecycle.json | 1 + .../fr/docs/oci-manager/storage-network.json | 5 +- web/messages/fr/docs/post-install/index.json | 11 + .../docs/backup-restore/creating-backups.json | 2 +- .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../it/docs/backup-restore/how-it-works.json | 2 +- .../it/docs/oci-manager/hardware.json | 2 +- .../it/docs/oci-manager/lifecycle.json | 1 + .../it/docs/oci-manager/storage-network.json | 5 +- web/messages/it/docs/post-install/index.json | 11 + .../docs/backup-restore/creating-backups.json | 2 +- .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../pt/docs/backup-restore/how-it-works.json | 2 +- .../docs/backup-restore/scheduled-jobs.json | 2 +- .../pt/docs/oci-manager/hardware.json | 2 +- .../pt/docs/oci-manager/lifecycle.json | 1 + .../pt/docs/oci-manager/storage-network.json | 5 +- web/messages/pt/docs/post-install/index.json | 11 + .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../sk/docs/backup-restore/how-it-works.json | 2 +- .../sk/docs/oci-manager/hardware.json | 2 +- .../sk/docs/oci-manager/lifecycle.json | 1 + .../sk/docs/oci-manager/storage-network.json | 5 +- web/messages/sk/docs/post-install/index.json | 11 + .../backup-restore/destinations/index.json | 2 +- .../docs/backup-restore/destinations/pbs.json | 8 +- .../sv/docs/backup-restore/how-it-works.json | 2 +- .../docs/backup-restore/scheduled-jobs.json | 2 +- .../sv/docs/oci-manager/hardware.json | 2 +- .../sv/docs/oci-manager/lifecycle.json | 1 + .../sv/docs/oci-manager/storage-network.json | 5 +- web/messages/sv/docs/post-install/index.json | 11 + 75 files changed, 661 insertions(+), 198 deletions(-) diff --git a/web/messages/de/docs/backup-restore/destinations/index.json b/web/messages/de/docs/backup-restore/destinations/index.json index 1654efab..c5307911 100644 --- a/web/messages/de/docs/backup-restore/destinations/index.json +++ b/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 rootfs/ + metadata/ + manifest.json Layout vorhanden, das in Funktionsweise beschrieben wird. Ein aus einem lokalen Archiv extrahierter .tar.zst, ein aus PBS wiederhergestellter .pxar und ein mit borg extract extrahiertes Borg-Archiv ergeben alle einen identischen Verzeichnisbaum. Der Wiederherstellungscodepfad (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) 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 Funktionsweise beschrieben sind: das Dateisystem (rootfs/), die Metadaten (metadata/) und das Manifest (manifest.json). Das Entpacken eines lokalen .tar.zst-Archivs, das Wiederherstellen eines .pxar 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", diff --git a/web/messages/de/docs/backup-restore/destinations/pbs.json b/web/messages/de/docs/backup-restore/destinations/pbs.json index 2beffaef..cd954e2c 100644 --- a/web/messages/de/docs/backup-restore/destinations/pbs.json +++ b/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 HB_PBS_REPOSITORY, HB_PBS_SECRET und HB_PBS_FINGERPRINT 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 Fingerabdruck das Zertifikat validiert.", "sourceRows": [ { "source": "Proxmox storage.cfg (automatisch erkannt)", @@ -46,7 +46,7 @@ "backupIdTitle": "Backup-ID-Bezeichnung", "backupIdBody": "Die Standard-Backup-ID ist hostcfg-HOSTNAME. Vor dem Upload wird sie bestätigt oder bearbeitet. Zeichen außerhalb von [A-Za-z0-9_-] sowie abschließende Bindestriche werden entfernt. Die Wiederverwendung derselben ID bei weiteren Läufen ist beabsichtigt: PBS behandelt die ID als Gruppe. 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 .pxar-Quelle ist die gesamte staging_root - rootfs/, metadata/ und manifest.json zusammen. Frühere Versionen bestanden $staging_root/rootfs als Quelle; Das ließ metadata/ 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 _rs_check_layout-Fall-3-Zweig wiederhergestellt, der einen flachen etc/var/root/usr-Baum zurück in eine rootfs/-Hierarchie wickelt." + "pxarBody": "Das .pxar-Archiv packt das gesamte Arbeitsverzeichnis: das Dateisystem des Hosts (rootfs/), die Metadaten (metadata/) und das Manifest (manifest.json). 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 Schlüssel auf PBS hochladen? und bietet zwei Antworten. Erst wenn der Betreiber Ja wählt, wird ein Wiederherstellungsartefakt auf PBS hochgeladen. Vorgabe ist Nein, nur lokal behalten: 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 Schlüsseldatei herunterladen in der PBS-Zielzeile des Monitors stellt sie bei Bedarf bereit. Bei Ja, hochladen 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 pbs-key.recovery.enc. 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 Ja, hochladen 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 -keyrecovery. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. Die Hülle verlässt den Host niemals im Klartext: Noch vor der Übertragung verschlüsselt der Host sie mit AES-256-CBC und PBKDF2 (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS erhält ausschließlich die bereits verschlüsselte Hülle.", + "blobUploadBody1": "Lautet die Antwort Ja, hochladen, 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 -keyrecovery. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. Die Hülle verlässt den Host niemals im Klartext: Noch bevor ein Byte übertragen wird, verschlüsselt der Host sie selbst mit AES-256-CBC und PBKDF2 (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). 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 /etc/pve/priv/storage/<NAME>.enc ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe -keyrecovery 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 wrong key — manifest's key XX does not match provided key YY. 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: Herunterladen exportiert die aktuelle Datei in den Browser des Betreibers; Hochladen ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; Löschen entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für Schlüssel auf PBS hochladen?, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit Upload starten, Upload stoppen oder Passphrase aktualisieren. 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: Herunterladen exportiert die aktuelle Schlüsseldatei in den Browser des Benutzers, Hochladen 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 Löschen entfernt die Schlüsseldatei vom Host. Direkt daneben befindet sich der Schalter für die Wiederherstellungshülle: eine Ja/Nein-Auswahl für Schlüssel auf PBS hochladen?, ein Passphrase-Feld, das bei Auswahl von Ja erscheint, und eine Schaltfläche, die dem aktuellen Zustand folgt: Upload starten, Upload stoppen oder Passphrase aktualisieren. 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", diff --git a/web/messages/de/docs/backup-restore/how-it-works.json b/web/messages/de/docs/backup-restore/how-it-works.json index 6a8320b1..f6f2d198 100644 --- a/web/messages/de/docs/backup-restore/how-it-works.json +++ b/web/messages/de/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Validierung des Schemas", - "schemaBody": "Das Manifest bestätigt gegen scripts/backup_restore/schema/manifest.schema.json. Das Ausführen von build_manifest.sh --validate löst eine Python-seitige JSON-Schemavalidierung aus (erfordert python3 + jsonschema). 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", diff --git a/web/messages/de/docs/backup-restore/scheduled-jobs.json b/web/messages/de/docs/backup-restore/scheduled-jobs.json index dbe92ef5..7f540cc3 100644 --- a/web/messages/de/docs/backup-restore/scheduled-jobs.json +++ b/web/messages/de/docs/backup-restore/scheduled-jobs.json @@ -127,7 +127,7 @@ }, "notifications": { "heading": "Benachrichtigungen", - "body": "Jeder geplante Lauf feuert die gleichen hb_notify_lifecycle-Ereignisse ab wie der interaktive Fluss (start, complete, fail). 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 hb_notify_lifecycle-Ereignisse aus wie der interaktive Ablauf (start, complete, fail). 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", diff --git a/web/messages/de/docs/oci-manager/hardware.json b/web/messages/de/docs/oci-manager/hardware.json index 6f07b1aa..bedc75d7 100644 --- a/web/messages/de/docs/oci-manager/hardware.json +++ b/web/messages/de/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "Der Renderknoten, /dev/kfd und die Generation, die der Compute-Treiber in /sys/class/kfd/kfd/topology/nodes/*/properties meldet", - "Eine GPU-Generation, für die das ROCm-Image der Anwendung passende Rechenkernel enthält — die dort genannten RDNA2-GPUs und neuere — wird unverändert angeboten. Andere GPUs dieser Familien, etwa Radeon 680M und 780M, werden als experimentell angeboten und nie vorausgewählt: ROCm unterstützt sie nicht offiziell, die Anwendung meldet sie als Generation ihrer Familie (HSA_OVERRIDE_GFX_VERSION), und vor dem Download des größeren Images ist eine Bestätigung erforderlich. Ältere GPUs, etwa die integrierte Grafik eines Ryzen 5000U, werden nicht angeboten; Immich führt die Erkennung weiter auf der CPU aus." + "Eine GPU einer Generation, die das ROCm-Image der Anwendung unterstützt (die dort genannten RDNA2-GPUs und neuere), wird unverändert angeboten. Andere GPUs dieser Familien, etwa Radeon 680M und 780M, werden als experimentell angeboten und sind nie die vorgeschlagene Option. ROCm unterstützt sie nicht offiziell: Die Anwendung meldet sie als Generation ihrer Familie (HSA_OVERRIDE_GFX_VERSION), und das Installationsprogramm fragt vor dem Download des größeren Images nach einer Bestätigung. Eine ältere GPU, etwa die integrierte Grafik eines Ryzen 5000U, wird nicht angeboten, und Immich führt die Erkennung weiter auf der CPU aus" ], [ "NVIDIA", diff --git a/web/messages/de/docs/oci-manager/lifecycle.json b/web/messages/de/docs/oci-manager/lifecycle.json index 7fb24421..d669625b 100644 --- a/web/messages/de/docs/oci-manager/lifecycle.json +++ b/web/messages/de/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "Das neue Image wird Schicht für Schicht verifiziert, bevor der CT stoppt. Ein Download, der beschädigt ankommt, wird ein zweites Mal abgerufen; ein bereits zwischengespeichertes Image, das den Check nicht besteht, wird erneut heruntergeladen.", "Nach der Installation in Proxmox VE geänderte Einstellungen (Arbeitsspeicher, Swap, Kerne, CPU-Limit, CPU-Priorität, Start mit dem Knoten) bleiben erhalten und werden in den neuen Vertrag übernommen.", "Die LAN-Schnittstelle, die die Arr-Suite und Multi-Container-Anwendungen hinzufügen (net1) und die Startreihenfolge (startup) werden an den neuen Container zurückgegeben.", + "Ein Host-Verzeichnis wird an seinem Pfad und an dem Dateisystem erkannt, auf dem es liegt, nicht an dem Gerätenamen, den der Host seinem Datenträger gibt. Ein USB- oder Netzwerkdatenträger, der unter einem anderen Namen zurückkehrt, ist daher weiterhin dasselbe Verzeichnis. Ist sein Datenträger nicht angeschlossen, stoppt das Update, bevor der CT gestoppt wird, und nennt das fehlende Verzeichnis.", "Jeder andere Unterschied zwischen dem CT und seinem Vertrag stoppt das Update, bevor der CT gestoppt wird." ] } diff --git a/web/messages/de/docs/oci-manager/storage-network.json b/web/messages/de/docs/oci-manager/storage-network.json index 181d3bf3..47a08b4b 100644 --- a/web/messages/de/docs/oci-manager/storage-network.json +++ b/web/messages/de/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Speicher und Größe", - "body": "Ein Container-Datenträger wird mit der angegebenen Größe auf einem Proxmox-VE-Speicher erstellt. Die Standardinstallation verwendet local-lvm. Die erweiterte Installation fragt für jeden Pfad zuerst den Speicher und dann die Größe ab; vorgeschlagen wird der Speicher des rootfs. Der Datenträger erscheint als vm-VMID-disk-N und wird als mpN eingebunden." + "body": "Ein Container-Datenträger wird mit der angegebenen Größe auf einem Proxmox-VE-Speicher erstellt. Die Standardinstallation fragt einmal nach dem Speicher für den Container und seine Daten, wenn der Knoten mehr als einen hat; die erweiterte Installation fragt für jeden Pfad unmittelbar vor seiner Größe nach dem Speicher und schlägt den des rootfs vor. Der Datenträger erscheint als vm-VMID-disk-N und wird als mpN eingebunden." }, { "title": "Host-Verzeichnis", @@ -109,6 +109,9 @@ }, { "p": "Das rootfs ist den Binärdateien und dem Inhalt des Images vorbehalten. Eine Aktualisierung oder Neuerstellung ersetzt es, ohne eine der beiden Arten von Mountpoints anzutasten." + }, + { + "p": "Ein Host-Verzeichnis wird mit allem eingebunden, was der Host darin eingehängt hat. Ein Verzeichnis wie /mnt/pve zeigt seine Netzwerkfreigaben, Datenträger und Datasets im Container, und was der Host dort später ein- oder aushängt, erscheint oder verschwindet, ohne dass der Container neu gestartet wird. Ein schreibgeschützt hinzugefügtes Verzeichnis ist zusammen mit dem, was beim Start des Containers darin eingehängt ist, schreibgeschützt. Ein Dateisystem, das der Host danach einhängt, kommt mit den Berechtigungen an, mit denen der Host es einhängt, und wird beim Neustart des Containers ebenfalls schreibgeschützt." } ] }, diff --git a/web/messages/de/docs/post-install/index.json b/web/messages/de/docs/post-install/index.json index badbeab7..20221134 100644 --- a/web/messages/de/docs/post-install/index.json +++ b/web/messages/de/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Gemeinschaftsskripte", "body": "Das Menü bietet zwei Drittanbieterskripte aus dem Projekt community-scripts: Proxmox VE Post Install und Proxmox VE Microcode. Die Wrapper laden die Originalskripte mit wget | bash herunter und führen sie aus. ProxMenux pflegt sie nicht. Lesen Sie vor der Ausführung Externe Repositories für Details und Hinweise zur Vertrauenswürdigkeit." }, + "pbs": { + "heading": "Auf Proxmox Backup Server", + "body": "Auf einem Proxmox-Backup-Server-Host öffnet sich dasselbe Menü über Einstellungen nach der Installation von Proxmox im PBS-Menü. Automatisiert, Anpassbar, Verfügbare Updates anwenden und Optimierungen deinstallieren funktionieren wie unter Proxmox VE, mit diesen Unterschieden:", + "items": [ + "Repositories und Upgrade: Hat der Server kein Abonnement und ist nur das Enterprise-Repository von PBS aktiv, fragt ProxMenux, bevor es zum No-Subscription-Repository von PBS wechselt. Der Wechsel erfolgt über die Repository-API des Servers selbst, dieselbe wie unter Administration > Repositories. Mit aktivem Abonnement oder bereits eingerichtetem No-Subscription- oder Test-Repository bleiben die Quellen unverändert.", + "Anpassbare Liste: Optionen, die nur für Proxmox VE gelten, werden nicht angezeigt: Gast-Agent, VFIO IOMMU, Open vSwitch, vzdump-Backup-Geschwindigkeit, pigz, Appliance Manager, Ceph, Hochverfügbarkeit und OVH Real Time Monitoring.", + "Abonnement-Hinweis: Der Patch gilt für die Weboberfläche von Proxmox Backup Server, und Optimierungen deinstallieren stellt sie wieder her.", + "Figurine: wird ohne die Proxmox-VE-Aliase installiert.", + "Community-Skripte: Der Abschnitt bietet Proxmox Backup Server Post Install und Proxmox Backup Server Microcode anstelle der Proxmox-VE-Skripte an." + ] + }, "related": { "heading": "Verwandte Themen", "items": [ diff --git a/web/messages/en/docs/backup-restore/creating-backups.json b/web/messages/en/docs/backup-restore/creating-backups.json index dbefcdf7..b2a17ef5 100644 --- a/web/messages/en/docs/backup-restore/creating-backups.json +++ b/web/messages/en/docs/backup-restore/creating-backups.json @@ -19,8 +19,16 @@ "entryPoints": { "heading": "The two entry points", "rows": [ - { "entry": "ProxMenux Scripts (TUI)", "path": "menu → Utilities → Host Config Backup", "detail": "Dialog-based flow, SSH-friendly. The main menu presents the six options directly. Uses backup_menu in backup_host.sh." }, - { "entry": "ProxMenux Monitor (Web UI)", "path": "Backups tab → Create backup", "detail": "Wizard-style flow. Same six options presented as a two-step form (destination → profile). Same backend functions are invoked over the Flask API." } + { + "entry": "ProxMenux Scripts (TUI)", + "path": "menu → Utilities → Host Config Backup", + "detail": "Dialog-based flow, SSH-friendly. The main menu presents the six options directly. Uses backup_menu in backup_host.sh." + }, + { + "entry": "ProxMenux Monitor (Web UI)", + "path": "Backups tab → Create backup", + "detail": "Wizard-style flow. Same six options presented as a two-step form (destination → profile). Same backend functions are invoked over the Flask API." + } ] }, "modes": { @@ -34,12 +42,42 @@ "heading": "The six-option matrix", "intro": "The choice determines both which backend runs and what path selection strategy is applied. Cross-reference the destination-specific pages for the configuration details of each cell.", "rows": [ - { "combo": "1", "destination": "PBS", "profile": "Default", "action": "Uploads the default profile plus persistent extras to a configured PBS repository." }, - { "combo": "2", "destination": "Borg", "profile": "Default", "action": "Creates an archive with the default profile plus persistent extras in the selected Borg repository." }, - { "combo": "3", "destination": "Local", "profile": "Default", "action": "Writes a .tar.zst archive with the default profile plus persistent extras to the configured local target." }, - { "combo": "4", "destination": "PBS", "profile": "Custom", "action": "Opens the path picker before the PBS upload; the user ticks paths and can add new ones." }, - { "combo": "5", "destination": "Borg", "profile": "Custom", "action": "Opens the path picker before the Borg archive create." }, - { "combo": "6", "destination": "Local", "profile": "Custom", "action": "Opens the path picker before writing the local .tar.zst." } + { + "combo": "1", + "destination": "PBS", + "profile": "Default", + "action": "Uploads the default profile plus persistent extras to a configured PBS repository." + }, + { + "combo": "2", + "destination": "Borg", + "profile": "Default", + "action": "Creates an archive with the default profile plus persistent extras in the selected Borg repository." + }, + { + "combo": "3", + "destination": "Local", + "profile": "Default", + "action": "Writes a .tar.zst archive with the default profile plus persistent extras to the configured local target." + }, + { + "combo": "4", + "destination": "PBS", + "profile": "Custom", + "action": "Opens the path picker before the PBS upload; the user ticks paths and can add new ones." + }, + { + "combo": "5", + "destination": "Borg", + "profile": "Custom", + "action": "Opens the path picker before the Borg archive create." + }, + { + "combo": "6", + "destination": "Local", + "profile": "Custom", + "action": "Opens the path picker before writing the local .tar.zst." + } ] }, "profiles": { @@ -57,11 +95,31 @@ "heading": "What runs regardless of destination", "intro": "After the profile is resolved, every backend runs the same staging pipeline before diverging into its own upload path. hb_prepare_staging assembles the archive tree in /tmp/proxmenux-DESTINATION-stage.XXXXXX and populates each of the three payloads.", "steps": [ - { "step": "1", "name": "rootfs assembly", "detail": "Runs rsync -a for each selected path into staging_root/rootfs/. The pmxcfs database at /var/lib/pve-cluster/config.db is captured separately via sqlite3 .backup to produce a consistent snapshot without stopping the cluster, and the .db-wal / .db-shm sidecars are excluded from the rsync; when sqlite3 is not available a config.db.raw-fallback is dropped instead, and the restore promotes it on import. Volatile subpaths (bash history, caches, trash) are excluded from /root/. Paths absent from the source are recorded in metadata/missing_paths.txt without stopping the backup." }, - { "step": "2", "name": "Manifest generation", "detail": "build_manifest.sh orchestrates the six collectors and writes manifest.json at the top of staging. On collector failure, the affected section falls back to a documented empty default; the manifest is still valid." }, - { "step": "3", "name": "Package inventory", "detail": "apt-mark showmanual is captured verbatim into metadata/packages.manual.list. Component state is already inside the restored rootfs (components_status.json) because /usr/local/share/proxmenux/ is part of the default profile." }, - { "step": "4", "name": "Run info", "detail": "metadata/run_info.env records the backup run identity — hostname, timestamp, kernel version — used by the restore's compatibility check to determine the cross-kernel direction." }, - { "step": "5", "name": "Notification (start)", "detail": "hb_notify_lifecycle \"start\" fires. If notifications are configured in the Monitor, an user-facing Host backup started event is emitted. Silent if no channels are configured." } + { + "step": "1", + "name": "rootfs assembly", + "detail": "Runs rsync -a for each selected path into staging_root/rootfs/. The pmxcfs database at /var/lib/pve-cluster/config.db is captured separately via sqlite3 .backup to produce a consistent snapshot without stopping the cluster, and the .db-wal / .db-shm sidecars are excluded from the rsync; when sqlite3 is not available a config.db.raw-fallback is dropped instead, and the restore promotes it on import. Volatile subpaths (bash history, caches, trash) are excluded from /root/. Paths absent from the source are recorded in metadata/missing_paths.txt without stopping the backup." + }, + { + "step": "2", + "name": "Manifest generation", + "detail": "build_manifest.sh orchestrates the six collectors and writes manifest.json at the top of staging. On collector failure, the affected section falls back to a documented empty default; the manifest is still valid." + }, + { + "step": "3", + "name": "Package inventory", + "detail": "apt-mark showmanual is captured verbatim into metadata/packages.manual.list. Component state is already inside the restored rootfs (components_status.json) because /usr/local/share/proxmenux/ is part of the default profile." + }, + { + "step": "4", + "name": "Run info", + "detail": "metadata/run_info.env records the backup run identity — hostname, timestamp, kernel version — used by the restore's compatibility check to determine the cross-kernel direction." + }, + { + "step": "5", + "name": "Notification (start)", + "detail": "hb_notify_lifecycle \"start\" fires. If notifications are configured in the Monitor, a user-facing Host backup started event is emitted. Silent if no channels are configured." + } ] }, "included": { @@ -117,9 +175,18 @@ "heading": "Writing to the destination", "intro": "Once the user confirms, each backend runs its own write step. The mechanics are covered in the destination pages; the shared surface is the log, the sidecar and the completion notification.", "rows": [ - { "topic": "Log file", "detail": "Every backend writes its full output to /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log and, on failure, offers to open it in a scrollable dialog. The log path is printed in the completion summary only when the file has content." }, - { "topic": "Sidecar (local only)", "detail": "hb_write_archive_sidecar drops a *.proxmenux.json next to the local archive so the Monitor identifies it as a ProxMenux host backup even after moves or renames." }, - { "topic": "Notification (complete/fail)", "detail": "hb_notify_lifecycle \"complete\" or \"fail\" fires with duration, archive size and — for failures — the last error-looking line from the log." } + { + "topic": "Log file", + "detail": "Every backend writes its full output to /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log and, on failure, offers to open it in a scrollable dialog. The log path is printed in the completion summary only when the file has content." + }, + { + "topic": "Sidecar (local only)", + "detail": "hb_write_archive_sidecar drops a *.proxmenux.json next to the local archive so the Monitor identifies it as a ProxMenux host backup even after moves or renames." + }, + { + "topic": "Notification (complete/fail)", + "detail": "hb_notify_lifecycle \"complete\" or \"fail\" fires with duration, archive size and — for failures — the last error-looking line from the log." + } ] }, "finishedScreens": { @@ -133,9 +200,21 @@ "whereNext": { "heading": "Where to go next", "items": [ - { "label": "Destinations", "href": "/docs/backup-restore/destinations", "tail": " — configuration details for Local, PBS and Borg." }, - { "label": "Scheduled jobs", "href": "/docs/backup-restore/scheduled-jobs", "tail": " — running the same backup unattended on a schedule instead of interactively." }, - { "label": "Restoring", "href": "/docs/backup-restore/restoring", "tail": " — the flow that consumes what this page produces." } + { + "label": "Destinations", + "href": "/docs/backup-restore/destinations", + "tail": " — configuration details for Local, PBS and Borg." + }, + { + "label": "Scheduled jobs", + "href": "/docs/backup-restore/scheduled-jobs", + "tail": " — running the same backup unattended on a schedule instead of interactively." + }, + { + "label": "Restoring", + "href": "/docs/backup-restore/restoring", + "tail": " — the flow that consumes what this page produces." + } ] } } diff --git a/web/messages/en/docs/backup-restore/destinations/borg.json b/web/messages/en/docs/backup-restore/destinations/borg.json index bebe8813..a5c3afa6 100644 --- a/web/messages/en/docs/backup-restore/destinations/borg.json +++ b/web/messages/en/docs/backup-restore/destinations/borg.json @@ -63,7 +63,7 @@ { "type": "local", "url": "/backup/borgbackup (any absolute path)", - "detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against operator error but not against disk failure." + "detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against user error but not against disk failure." } ] }, @@ -91,7 +91,7 @@ }, { "requirement": "A writable repository directory", - "detail": "The path the operator gives ProxMenux (for example /backup/borgbackup) must exist on the server and be owned by the borg user." + "detail": "The path the user gives ProxMenux (for example /backup/borgbackup) must exist on the server and be owned by the borg user." }, { "requirement": "SSH daemon accepting the borg user", @@ -117,7 +117,7 @@ { "mode": "generate-manual", "label": "No admin password on this host", - "detail": "ProxMenux generates the keypair as above but displays the full authorized_keys line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for." + "detail": "ProxMenux generates the keypair as above but displays the full authorized_keys line for the user to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for." }, { "mode": "generate-pct", @@ -127,7 +127,7 @@ { "mode": "existing", "label": "Use an existing key", - "detail": "ProxMenux scans /root/.ssh/ and $HOME/.ssh/ for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path." + "detail": "ProxMenux scans /root/.ssh/ and $HOME/.ssh/ for parseable ed25519/RSA private keys and lists them. The user picks one or browses manually to a non-standard path." }, { "mode": "none", @@ -150,7 +150,7 @@ }, { "file": "borg-pass-NAME.txt", - "content": "Passphrase for the target NAMEd above (chmod 600). Only present when the operator chose repokey encryption." + "content": "Passphrase for the target NAMEd above (chmod 600). Only present when the user chose repokey encryption." } ], "outro": "Saving the target is optional. Declining the save prompt omits the named target configuration, but does not remove a generated SSH key. If repokey encryption is enabled without a saved target, ProxMenux still saves the passphrase in the legacy borg-pass.txt file." diff --git a/web/messages/en/docs/backup-restore/destinations/index.json b/web/messages/en/docs/backup-restore/destinations/index.json index 5f0f8ff2..55277f14 100644 --- a/web/messages/en/docs/backup-restore/destinations/index.json +++ b/web/messages/en/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "The archive layout does not change with the destination", - "body": "Inside any of the three destinations, the same rootfs/ + metadata/ + manifest.json layout described in How it works is present. A .tar.zst extracted from a local archive, a .pxar restored from PBS, and a Borg archive extracted with borg extract all yield an identical directory tree. The restore code path (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) reads the same three payloads without knowing which destination they came from." + "body": "Wherever the backup is stored, it always holds the same three blocks described in How it works: the filesystem (rootfs/), the metadata (metadata/) and the manifest (manifest.json). Extracting a local .tar.zst archive, restoring a .pxar from PBS or extracting a Borg archive all yield an identical directory tree. The restore therefore always reads the same files, whichever destination the backup comes from." }, "extractStandalone": { "heading": "Extracting a backup outside of ProxMenux", diff --git a/web/messages/en/docs/backup-restore/destinations/local.json b/web/messages/en/docs/backup-restore/destinations/local.json index b9c88bad..be7c0fb8 100644 --- a/web/messages/en/docs/backup-restore/destinations/local.json +++ b/web/messages/en/docs/backup-restore/destinations/local.json @@ -18,7 +18,7 @@ }, "targetConfig": { "heading": "Configuring the target directory", - "intro": "The local destination is a single persisted target directory — not a list. ProxMenux stores the operator's choice at /usr/local/share/proxmenux/local-target.conf and reads it on every backup. When no target has been configured, the default HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump is used (the same directory Proxmox uses for its own vzdump outputs). The target is configured from Configure backup destinations → Local destinations:", + "intro": "The local destination is a single persisted target directory — not a list. ProxMenux stores the user's choice at /usr/local/share/proxmenux/local-target.conf and reads it on every backup. When no target has been configured, the default HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump is used (the same directory Proxmox uses for its own vzdump outputs). The target is configured from Configure backup destinations → Local destinations:", "options": [ "Use default (/var/lib/vz/dump). The Proxmox local storage. Present on every Proxmox install; the archive sits next to vzdump outputs and is picked up by the Monitor's Backups tab automatically.", "Enter a custom path. Any absolute filesystem path can be used: an NFS mount, an SMB share mounted via fstab, a dedicated ZFS dataset, a second internal disk. ProxMenux validates that the path exists and is a directory before persisting it.", @@ -30,11 +30,23 @@ "intro": "The USB submenu lists partitions on removable devices reported by lsblk. Each partition is presented with its size, filesystem label and current state. The state determines the action ProxMenux offers.", "statesTitle": "The three device states", "stateRows": [ - { "state": "mounted", "shown": "Size · label · [fstype] · → /mount/point", "action": "The partition is already mounted somewhere. Selecting it persists the current mount point as the local target. No mounting is performed." }, - { "state": "unmounted", "shown": "Size · label · [fstype] · (not mounted — will be mounted)", "action": "A filesystem is present but not mounted. On confirmation, ProxMenux runs hb_mount_usb_partition: creates /mnt/backup-LABEL (or a UUID-based path if there is no label), mounts the partition and persists the mount point as the local target." }, - { "state": "empty", "shown": "Size · raw USB disk — no filesystem (will be FORMATTED)", "action": "The device has no filesystem. A destructive path — protected by two confirmations. First a Yes/No dialog explains that the operation will erase the disk. Second, an inputbox requires the operator to type the exact device path (e.g. /dev/sdb) before ProxMenux creates a fresh GPT + ext4 partition and mounts it." } + { + "state": "mounted", + "shown": "Size · label · [fstype] · → /mount/point", + "action": "The partition is already mounted somewhere. Selecting it persists the current mount point as the local target. No mounting is performed." + }, + { + "state": "unmounted", + "shown": "Size · label · [fstype] · (not mounted — will be mounted)", + "action": "A filesystem is present but not mounted. On confirmation, ProxMenux runs hb_mount_usb_partition: creates /mnt/backup-LABEL (or a UUID-based path if there is no label), mounts the partition and persists the mount point as the local target." + }, + { + "state": "empty", + "shown": "Size · raw USB disk — no filesystem (will be FORMATTED)", + "action": "The device has no filesystem. A destructive path — protected by two confirmations. First a Yes/No dialog explains that the operation will erase the disk. Second, an inputbox requires the user to type the exact device path (e.g. /dev/sdb) before ProxMenux creates a fresh GPT + ext4 partition and mounts it." + } ], - "notMountedFallback": "When no USB device is detected, the submenu falls back to a plain inputbox. The operator can enter an arbitrary mount point path; if the path is not a registered mount point, a confirmation dialog warns before proceeding." + "notMountedFallback": "When no USB device is detected, the submenu falls back to a plain inputbox. The user can enter an arbitrary mount point path; if the path is not a registered mount point, a confirmation dialog warns before proceeding." }, "safetyCheck": { "heading": "Safety check — destination inside a backup path", @@ -45,7 +57,7 @@ "intro": "The output filename embeds the source hostname and the backup timestamp so that a directory holding several archives sorts chronologically and each file is self-identifying.", "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst", "compressionTitle": "Compression", - "compressionBody": "The primary path uses tar --zstd -cf — a single-command pipeline that compresses at zstd's default level. When zstd is not present on the source (rare on Proxmox but possible on minimal installs), ProxMenux falls back to gzip. In the fallback path, if pv is available, a progress bar is added to the pipeline so the operator sees the archive size grow in real time; without pv, plain tar -czf is used silently.", + "compressionBody": "The primary path uses tar --zstd -cf — a single-command pipeline that compresses at zstd's default level. When zstd is not present on the source (rare on Proxmox but possible on minimal installs), ProxMenux falls back to gzip. In the fallback path, if pv is available, a progress bar is added to the pipeline so the user sees the archive size grow in real time; without pv, plain tar -czf is used silently.", "sourceTitle": "What goes into the archive", "sourceBody": "The tar command is invoked with -C \"$staging_root\" ., which archives the full staging root: rootfs/, metadata/ and manifest.json. All three payloads land side by side at the top of the tarball. Extracting the archive produces the exact same tree that the restore code consumes." }, diff --git a/web/messages/en/docs/backup-restore/destinations/pbs.json b/web/messages/en/docs/backup-restore/destinations/pbs.json index e5aac4e6..462436b3 100644 --- a/web/messages/en/docs/backup-restore/destinations/pbs.json +++ b/web/messages/en/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Repository selection", - "intro": "ProxMenux discovers PBS repositories from two sources on every backup. The operator picks one from a unified menu; the choice determines HB_PBS_REPOSITORY, HB_PBS_SECRET and HB_PBS_FINGERPRINT for the run.", + "intro": "ProxMenux discovers PBS repositories from two sources on every backup. The user picks one from a unified menu; for that run, the choice determines which server and datastore the backup is sent to, the password it authenticates with and the fingerprint that validates the certificate.", "sourceRows": [ { "source": "Proxmox storage.cfg (auto-discovered)", @@ -37,43 +37,43 @@ } ], "menuTitle": "Selection menu", - "menuBody": "Both sources are shown in a single menu, each row tagged with its origin ([proxmox] or [manual]). Entries whose password could not be resolved are tagged with a ⚠ no password warning — selecting one triggers a password re-entry before the backup starts. The fingerprint is passed to proxmox-backup-client via the PBS_FINGERPRINT environment variable; when absent, the client asks the operator to accept the server certificate interactively on the first backup." + "menuBody": "Both sources are shown in a single menu, each row tagged with its origin ([proxmox] or [manual]). Entries whose password could not be resolved are tagged with a ⚠ no password warning — selecting one triggers a password re-entry before the backup starts. The fingerprint is passed to proxmox-backup-client via the PBS_FINGERPRINT environment variable; when absent, the client asks the user to accept the server certificate interactively on the first backup." }, "backupCommand": { "heading": "The backup command", "intro": "The upload is a single invocation of proxmox-backup-client backup. ProxMenux uses env to pass the password, encryption password and fingerprint to the client as environment variables.", "cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]", "backupIdTitle": "Backup ID naming", - "backupIdBody": "The default backup ID is hostcfg-HOSTNAME. The operator is asked to confirm or edit it before the upload; any characters outside [A-Za-z0-9_-] are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a group, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.", + "backupIdBody": "The default backup ID is hostcfg-HOSTNAME. The user is asked to confirm or edit it before the upload; any characters outside [A-Za-z0-9_-] are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a group, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.", "pxarTitle": "Why the source is the full staging root", - "pxarBody": "The .pxar source is the entire staging_root — rootfs/, metadata/ and manifest.json together. Earlier versions passed $staging_root/rootfs as the source; that left metadata/ out of the archive and the restore's compatibility check had nothing to read, degrading to cross-host warnings even on same-host restores. Old backups created with the rootfs-only source still restore correctly via _rs_check_layout's case-3 branch, which wraps a flat etc/var/root/usr tree back into a rootfs/ hierarchy." + "pxarBody": "The .pxar archive packs the whole working directory: the host filesystem (rootfs/), the metadata (metadata/) and the manifest (manifest.json). On restore, ProxMenux compares the manifest with the target host to tell whether they are equivalent, whether the hardware changed or whether it is a different machine, and adjusts the process accordingly. Older backups, made by earlier ProxMenux versions that packed only the filesystem, still restore correctly: the restore detects that legacy format and rearranges it automatically." }, "encryption": { "heading": "Client-side encryption", "glossaryHint": "This section uses the terms keyfile, passphrase and recovery envelope. The glossary summarises the differences in one sentence per term.", - "intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. In ProxMenux encryption is optional; when enabled, whether to also upload a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is an explicit yes/no choice the operator makes at setup time (and can revisit later from the Monitor). The keyfile itself always lives at one canonical path on the host — /usr/local/share/proxmenux/pbs-key.conf — and is reused silently by every subsequent encrypted backup.", + "intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. In ProxMenux encryption is optional; when enabled, whether to also upload a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is an explicit yes/no choice the user makes at setup time (and can revisit later from the Monitor). The keyfile itself always lives at one canonical path on the host — /usr/local/share/proxmenux/pbs-key.conf — and is reused silently by every subsequent encrypted backup.", "keyfileTitle": "Setting up the keyfile", - "keyfileBody": "The encryption prompt runs at the first encrypted backup on the host. Step one asks whether to encrypt the backup: No continues without encryption; Yes moves to step two. Step two depends on whether a keyfile is already installed at /usr/local/share/proxmenux/pbs-key.conf. If it is, the installed keyfile is reused silently and the backup proceeds — subsequent backups never re-ask. If it is not, a two-option menu asks how to set one up. Generate a new keyfile runs proxmox-backup-client key create --kdf none. Use an existing keyfile auto-detects a PVE-managed keyfile: when the selected PBS repository is registered in Proxmox with an encryption key at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the ProxMenux canonical path silently and the flow continues. When no PVE-managed keyfile matches the repository, an input prompts for the absolute path where the operator has already placed the keyfile on this host. Either way, the file lands at the canonical path with chmod 600.", + "keyfileBody": "The encryption prompt runs at the first encrypted backup on the host. Step one asks whether to encrypt the backup: No continues without encryption; Yes moves to step two. Step two depends on whether a keyfile is already installed at /usr/local/share/proxmenux/pbs-key.conf. If it is, the installed keyfile is reused silently and the backup proceeds — subsequent backups never re-ask. If it is not, a two-option menu asks how to set one up. Generate a new keyfile runs proxmox-backup-client key create --kdf none. Use an existing keyfile auto-detects a PVE-managed keyfile: when the selected PBS repository is registered in Proxmox with an encryption key at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the ProxMenux canonical path silently and the flow continues. When no PVE-managed keyfile matches the repository, an input prompts for the absolute path where the user has already placed the keyfile on this host. Either way, the file lands at the canonical path with chmod 600.", "modesTitle": "Per-host or shared keyfile", - "modesIntro": "Both operating models are supported and neither is enforced — the choice belongs to the operator based on how their fleet is organised.", + "modesIntro": "Both operating models are supported and neither is enforced — the choice belongs to the user based on how their fleet is organised.", "modesPerHostTitle": "Per-host keyfile (default)", "modesPerHostBody": "Each host generates its own keyfile the first time it enables PBS encryption. Isolation is maximum: compromising the keyfile of one host does not expose the backups of any other. Recommended for production fleets and for environments where hosts have different owners or compliance boundaries.", "modesSharedTitle": "Shared keyfile (import on every host)", "modesSharedBody": "One master keyfile generated once and installed on every host via the Use an existing keyfile option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.", - "recoveryTitle": "Upload key to PBS — the operator decides", + "recoveryTitle": "Upload key to PBS — the user decides", "recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — Upload key to PBS? — with two answers. No recovery artifact is uploaded to PBS until the operator answers Yes. The default is No, keep local only: the keyfile stays at the canonical local path, ProxMenux uploads no recovery artifact to PBS, and the operator handles the offsite copy themselves (the Monitor’s Download keyfile button in the PBS destination row provides one on demand). Choosing Yes, upload prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce pbs-key.recovery.enc. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile is sent to PBS during these uploads. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).", "blobUploadTitle": "Paired backup group on PBS", - "blobUploadBody1": "When the escrow mode is Yes, upload, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in -keyrecovery. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. The envelope never leaves the host in plaintext: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS receives only the already-encrypted envelope.", + "blobUploadBody1": "When the answer is Yes, upload, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in -keyrecovery. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. The envelope never leaves the host in plaintext: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS receives only the already-encrypted envelope.", "envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?", - "envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the operator holds both.", + "envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the user holds both.", "blobUploadConstraintTitle": "Why two groups instead of a single encrypted one", "blobUploadConstraintBody": "A single proxmox-backup-client backup invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by the PBS client with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.", "blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.", "blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.", "recoverTitle": "Recovery on a fresh host", - "recoverBody": "When the local keyfile is missing at the canonical path — on a freshly reinstalled host, or after an explicit removal — the restore flow tries three sources in order and stops at the first one that produces a usable keyfile. First, when the selected PBS repository has a matching PVE-managed keyfile at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the canonical path silently. Second, when a -keyrecovery group is available on PBS, the newest snapshot is downloaded and the operator is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the operator declines them, an input prompts for the absolute path where the keyfile lives on this host and copies it to the canonical path. The Monitor exposes the same import flow inline in the backup detail modal — an amber panel appears at the top of the modal when Restore, Download or View contents would need a keyfile that is not installed. When a keyfile is installed but does not match the one that encrypted the backup, PBS returns a wrong key — manifest's key XX does not match provided key YY error; the same three actions display a structured amber panel with the required manifest fingerprint prominently rendered, so the operator can identify which keyfile to import to open that specific backup.", + "recoverBody": "When the local keyfile is missing at the canonical path — on a freshly reinstalled host, or after an explicit removal — the restore flow tries three sources in order and stops at the first one that produces a usable keyfile. First, when the selected PBS repository has a matching PVE-managed keyfile at /etc/pve/priv/storage/<NAME>.enc, that file is copied to the canonical path silently. Second, when a -keyrecovery group is available on PBS, the newest snapshot is downloaded and the user is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the user declines them, an input prompts for the absolute path where the keyfile lives on this host and copies it to the canonical path. The Monitor exposes the same import flow inline in the backup detail modal — an amber panel appears at the top of the modal when Restore, Download or View contents would need a keyfile that is not installed. When a keyfile is installed but does not match the one that encrypted the backup, PBS returns a wrong key — manifest's key XX does not match provided key YY error; the same three actions display a structured amber panel with the required manifest fingerprint prominently rendered, so the user can identify which keyfile to import to open that specific backup.", "monitorManagementTitle": "Managing the keyfile from the Monitor", - "monitorManagementBody": "The Monitor exposes the keyfile controls inline in each PBS destination row of the backup configuration page. The row shows three actions: Download exports the current keyfile to the operator's browser, Upload replaces the installed keyfile with one supplied by the operator (the previous file is overwritten only after the new one lands successfully at the canonical path), and Delete removes the keyfile from the host. The recovery-escrow toggle is a single inline control next to those actions: a Yes/No radio for Upload key to PBS?, a passphrase field when Yes is selected, and a contextual Apply button that reads Start uploading, Stop uploading or Update passphrase depending on the current state. Every action goes through the same Flask endpoints that the shell TUI uses, so the on-disk effect and the state on PBS are identical whichever surface the operator picks." + "monitorManagementBody": "The Monitor shows the keyfile controls in each PBS destination row of the backup configuration page. The row has three actions: Download exports the current keyfile to the user's browser, Upload replaces the installed keyfile with one supplied by the user (the previous file is overwritten only after the new one has arrived correctly at its path), and Delete removes the keyfile from the host. Right next to them is the switch of the recovery envelope: a Yes/No for Upload key to PBS?, a passphrase field that appears when Yes is selected, and a button that follows the current state: Start uploading, Stop uploading or Update passphrase. The Monitor controls and the shell dialog do the same underneath, so the result on disk and on PBS is identical whichever one is used." }, "restoreAccess": { "heading": "Retrieval on the restore side", diff --git a/web/messages/en/docs/backup-restore/how-it-works.json b/web/messages/en/docs/backup-restore/how-it-works.json index 5651f7ef..450a8e11 100644 --- a/web/messages/en/docs/backup-restore/how-it-works.json +++ b/web/messages/en/docs/backup-restore/how-it-works.json @@ -107,7 +107,7 @@ { "collector": "collect_kernel.sh", "produces": "kernel_params", - "content": "Operator-authored tokens from /proc/cmdline (stripped of boilerplate like BOOT_IMAGE=, root=, ro/rw, quiet, splash), modules loaded at boot from /etc/modules, and paths of /etc/modprobe.d/*.conf files with actual directives (options, blacklist, install, alias, softdep)." + "content": "User-authored tokens from /proc/cmdline (stripped of boilerplate like BOOT_IMAGE=, root=, ro/rw, quiet, splash), modules loaded at boot from /etc/modules, and paths of /etc/modprobe.d/*.conf files with actual directives (options, blacklist, install, alias, softdep)." }, { "collector": "collect_proxmenux_state.sh", @@ -121,7 +121,7 @@ } ], "schemaTitle": "Schema validation", - "schemaBody": "The manifest validates against scripts/backup_restore/schema/manifest.schema.json. Running build_manifest.sh --validate triggers a Python-side JSON Schema validation (requires python3 + jsonschema). If the module is not present, the check is skipped silently — validation is primarily a developer aid, not a runtime dependency." + "schemaBody": "ProxMenux ships a template that describes which fields the manifest must contain and the shape of each one. When a backup is generated, the manifest can be checked against that template automatically, so a collector that produced malformed JSON or a misspelled field is caught at once. The check is meant for the development of ProxMenux itself: on a system that does not have it installed, the backup works as usual and the manifest is generated all the same." }, "applications": { "heading": "The application inventory", diff --git a/web/messages/en/docs/backup-restore/scheduled-jobs.json b/web/messages/en/docs/backup-restore/scheduled-jobs.json index b5a3acf2..309941ec 100644 --- a/web/messages/en/docs/backup-restore/scheduled-jobs.json +++ b/web/messages/en/docs/backup-restore/scheduled-jobs.json @@ -127,7 +127,7 @@ }, "notifications": { "heading": "Notifications", - "body": "Every scheduled run fires the same hb_notify_lifecycle events as the interactive flow (start, complete, fail). If notification channels are configured in the Monitor, unattended jobs surface their results the same way manual backups do — an user does not need to check the log to know whether a job succeeded." + "body": "Every scheduled run fires the same hb_notify_lifecycle events as the interactive flow (start, complete, fail). If notification channels are configured in the Monitor, unattended jobs surface their results the same way manual backups do — a user does not need to check the log to know whether a job succeeded." }, "whereNext": { "heading": "Where to go next", diff --git a/web/messages/en/docs/monitor/access-auth.json b/web/messages/en/docs/monitor/access-auth.json index 62606548..1787f106 100644 --- a/web/messages/en/docs/monitor/access-auth.json +++ b/web/messages/en/docs/monitor/access-auth.json @@ -124,7 +124,7 @@ "/api/system-info is a public lightweight system-information endpoint, including health.status. It is not decorated with the token requirement. /api/auth/status is another public endpoint suitable for a reachability check." ], "cryptoTitle": "Cryptography and storage", - "cryptoIntro": "ProxMenux Monitor is open source — none of this is secret. Documenting the stack here explicitly is a deliberate choice: operators who store credentials on their host deserve to know how those credentials are protected before they decide to trust them. The algorithms below are the same ones the code in scripts/auth_manager.py uses; this section is a contract, not a marketing promise.", + "cryptoIntro": "ProxMenux Monitor is open source — none of this is secret. Documenting the stack here explicitly is a deliberate choice: users who store credentials on their host deserve to know how those credentials are protected before they decide to trust them. The algorithms below are the same ones the code in scripts/auth_manager.py uses; this section is a contract, not a marketing promise.", "headerAsset": "Asset", "headerAlgo": "Algorithm", "headerWhere": "Where it lives", @@ -158,9 +158,9 @@ "authJsonTitle": "auth.json — what it contains and how it's protected", "authJsonBody": "Everything ProxMenux Monitor needs to authenticate you lives in a single file: /root/.config/proxmenux-monitor/auth.json, mode 0600, owner root. The file holds hashes (PBKDF2) and signing material (jwt_secret, totp_secret) — never a plaintext password. Treat it like any other root-only secret: if you back up or replicate the host, encrypt the destination, and never commit it to version control.", "rotateTitle": "Rotating jwt_secret invalidates all existing JWTs", - "rotateBody": "If auth.json is regenerated (manual delete, reinstall, restore from a backup with a different secret) the jwt_secret changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI flags affected API tokens with an Invalid — regenerate badge so the operator knows to revoke and re-mint them; Home Assistant / scripts / any external client needs a fresh token after that.", + "rotateBody": "If auth.json is regenerated (manual delete, reinstall, restore from a backup with a different secret) the jwt_secret changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI flags affected API tokens with an Invalid — regenerate badge so the user knows to revoke and re-mint them; Home Assistant / scripts / any external client needs a fresh token after that.", "recoverTitle": "Recovering a lost password", - "recoverIntro": "There is no online \"forgot password\" flow — by design, since the dashboard runs on the operator's own host and the recovery path is shell access to that host. ProxMenux ships a guided reset inside the configuration menu so you don't have to hand-edit auth.json:", + "recoverIntro": "There is no online \"forgot password\" flow — by design, since the dashboard runs on the user's own host and the recovery path is shell access to that host. ProxMenux ships a guided reset inside the configuration menu so you don't have to hand-edit auth.json:", "survivesTitle": "What survives the reset", "survivesBody": "Only the interactive login is wiped. The jwt_secret and the registered api_tokens are preserved — so Home Assistant and any other script using a long-lived API token continue to work without reconfiguration. If you want a fully clean slate (also rotate the JWT secret), delete auth.json manually and restart the service. The next launch generates a fresh secret and all old tokens become invalid.", "physicalTitle": "Physical-access prerequisite", diff --git a/web/messages/en/docs/monitor/ai-assistant.json b/web/messages/en/docs/monitor/ai-assistant.json index 93b8368b..fab18565 100644 --- a/web/messages/en/docs/monitor/ai-assistant.json +++ b/web/messages/en/docs/monitor/ai-assistant.json @@ -215,7 +215,7 @@ "shareTitle": "Sharing prompts with the community", "shareIntro": "The Export button writes your current custom prompt to a file (.txt / .md) you can keep as a backup or hand to someone else. Import pulls one back in. The third button next to them links to a public community gallery on GitHub:", "shareLinkLabel": "github.com/MacRimi/ProxMenux/discussions — Share custom prompts for AI notifications", - "shareOutro": "Browse the discussion to see what other operators have built — terse pager-style alerts, verbose technical reports, language-specific variants. If you tweak yours and like the result, post it there: even a one-paragraph description of what your prompt optimises for helps people pick a good starting point. Feedback on what works and what doesn't is equally welcome." + "shareOutro": "Browse the discussion to see what other users have built — terse pager-style alerts, verbose technical reports, language-specific variants. If you tweak yours and like the result, post it there: even a one-paragraph description of what your prompt optimises for helps people pick a good starting point. Feedback on what works and what doesn't is equally welcome." }, "suggestions": { "heading": "AI Suggestions (BETA)", diff --git a/web/messages/en/docs/monitor/dashboard/settings.json b/web/messages/en/docs/monitor/dashboard/settings.json index 66abb836..d7d5107e 100644 --- a/web/messages/en/docs/monitor/dashboard/settings.json +++ b/web/messages/en/docs/monitor/dashboard/settings.json @@ -22,7 +22,7 @@ "If a translated key is missing, only that text falls back to English instead of rendering a broken placeholder." ], "scopeTitle": "Browser-local preference", - "scopeBody": "The selection is stored in localStorage under proxmenux-ui-language. It is therefore specific to this browser profile and device, not a node-wide setting. Each operator can choose a different Monitor language." + "scopeBody": "The selection is stored in localStorage under proxmenux-ui-language. It is therefore specific to this browser profile and device, not a node-wide setting. Each user can choose a different Monitor language." }, "navigationOrder": { "heading": "Navigation order", diff --git a/web/messages/en/docs/monitor/dashboard/storage.json b/web/messages/en/docs/monitor/dashboard/storage.json index 146d165d..4675b60a 100644 --- a/web/messages/en/docs/monitor/dashboard/storage.json +++ b/web/messages/en/docs/monitor/dashboard/storage.json @@ -184,7 +184,7 @@ ], "obsDedupTitle": "How dedup and re-notification work", "obsDedupBody1": "Observations are deduplicated by their signature — a stable fingerprint of the error type, device and key fields of the kernel line. The same event repeating bumps the occurrence_count on the existing row rather than creating a new one. A different signature on the same disk creates a new observation and is treated as a new event for notification purposes.", - "obsDedupBody2": "Notifications follow an anti-cascade rule: the first occurrence of a given (disk, signature, severity) combination pages the operator, and ProxMenux then waits 24 hours before pinging again about the same combination — even if the count keeps climbing. Escalating severity (WARNING → CRITICAL) breaks the cooldown so the operator is told when things get worse, not just when they happen.", + "obsDedupBody2": "Notifications follow an anti-cascade rule: the first occurrence of a given (disk, signature, severity) combination pages the user, and ProxMenux then waits 24 hours before pinging again about the same combination — even if the count keeps climbing. Escalating severity (WARNING → CRITICAL) breaks the cooldown so the user is told when things get worse, not just when they happen.", "obsDismissTitle": "Permanent history vs active errors", "obsDismissBody1": "An observation cannot be dismissed, hidden or removed. Each different observation of a disk is one card; the same one seen again adds to its occurrence count and moves its last date instead of creating a new card. The history belongs to the disk, identified by its serial number: a disk plugged where another one was starts with none, and a disk the kernel renames keeps its own.", "obsDismissBody2": "Resolving or dismissing on the active-error side (Health Monitor) is independent of the observations — the observation persists past the active error's auto-resolve. That's the whole point: it survives, so a transient warning from last week is still visible on the disk card today. See Health Monitor for the active-error side of the same picture." diff --git a/web/messages/en/docs/monitor/dashboard/vms-lxcs.json b/web/messages/en/docs/monitor/dashboard/vms-lxcs.json index 7c4b14b3..b258a399 100644 --- a/web/messages/en/docs/monitor/dashboard/vms-lxcs.json +++ b/web/messages/en/docs/monitor/dashboard/vms-lxcs.json @@ -88,7 +88,7 @@ "updatesLinkLabel": "dedicated Updates page", "updatesLinkTail": "for integrated and custom updaters, Docker recreation, bulk selection, safety options and scheduling.", "mountsTitle": "Tab 4 — Mounts (LXC only, when present)", - "mountsImageAlt": "LXC drill-in modal — Mounts tab listing every mount point the container is using: PVE volumes, host binds, binds from PVE storage and ad-hoc NFS/CIFS mounts the operator mounted from inside the CT. Each card carries a type badge, capacity bar, used/total bytes, mount options, and a colour-coded state dot (green healthy, amber readonly/divergent, red stale)", + "mountsImageAlt": "LXC drill-in modal — Mounts tab listing every mount point the container is using: PVE volumes, host binds, binds from PVE storage and ad-hoc NFS/CIFS mounts the user mounted from inside the CT. Each card carries a type badge, capacity bar, used/total bytes, mount options, and a colour-coded state dot (green healthy, amber readonly/divergent, red stale)", "mountsImageCaption": "Mounts tab — only renders for LXC containers, and only when at least one mount point or ad-hoc remote mount is present. A CT without mounts gets no tab.", "mountsIntro": "Proxmox's own UI shows the mount-point entries defined in the container config (mpX) but stops there — anything you mount from inside the CT later (mount.cifs, NFS via autofs, …) is invisible. This tab merges both views: the configured mounts and the runtime mounts ProxMenux probes from inside the container, with a per-mount health status and a capacity bar wherever the backend can resolve one.", "mountTypesTitle": "Types of mount detected", diff --git a/web/messages/en/docs/oci-manager/hardware.json b/web/messages/en/docs/oci-manager/hardware.json index 11c61c96..96dca463 100644 --- a/web/messages/en/docs/oci-manager/hardware.json +++ b/web/messages/en/docs/oci-manager/hardware.json @@ -19,9 +19,18 @@ { "flow": { "nodes": [ - { "label": "Host inventory", "detail": "/dev/dri/renderD128\nGID 993 · Intel" }, - { "label": "ProxMenux", "detail": "vendor and\npermissions checked" }, - { "label": "LXC", "detail": "same device\neffective GID" } + { + "label": "Host inventory", + "detail": "/dev/dri/renderD128\nGID 993 · Intel" + }, + { + "label": "ProxMenux", + "detail": "vendor and\npermissions checked" + }, + { + "label": "LXC", + "detail": "same device\neffective GID" + } ] } } @@ -33,12 +42,32 @@ "blocks": [ { "table": { - "headers": ["Source", "What is read", "What the installer does"], + "headers": [ + "Source", + "What is read", + "What the installer does" + ], "rows": [ - ["Docker Compose", "devices, group_add, deploy.resources and NVIDIA requests", "Each requirement becomes a device request shown for review"], - ["Catalog profile", "The GPU, Coral, OpenCL, USB or FUSE support the application actually has", "Only the options validated for that image are offered"], - ["Image metadata and documentation", "VA-API, Selkies, LinuxServer mods or the NVIDIA runtime", "The documented variables and preparation are added"], - ["User selection", "CPU only, Intel/AMD, OpenCL, NVIDIA or an optional device", "The selection is stored in the instance contract"] + [ + "Docker Compose", + "devices, group_add, deploy.resources and NVIDIA requests", + "Each requirement becomes a device request shown for review" + ], + [ + "Catalog profile", + "The GPU, Coral, OpenCL, USB or FUSE support the application actually has", + "Only the options validated for that image are offered" + ], + [ + "Image metadata and documentation", + "VA-API, Selkies, LinuxServer mods or the NVIDIA runtime", + "The documented variables and preparation are added" + ], + [ + "User selection", + "CPU only, Intel/AMD, OpenCL, NVIDIA or an optional device", + "The selection is stored in the instance contract" + ] ] } }, @@ -57,16 +86,52 @@ "blocks": [ { "table": { - "headers": ["Type", "Identity", "Validation"], + "headers": [ + "Type", + "Identity", + "Validation" + ], "rows": [ - ["Intel/AMD DRM", "/dev/dri/renderD* and /sys/class/drm/NODE/device/vendor", "A character device with vendor 0x8086 (Intel) or 0x1002 (AMD)"], - ["AMD OpenCL", "The render node, plus /dev/kfd when the profile needs it", "Existence, type, vendor, permissions and declared compatibility"], - ["AMD ROCm", "The render node, /dev/kfd and the generation the compute driver reports in /sys/class/kfd/kfd/topology/nodes/*/properties", "A generation the ROCm image of the application carries kernels for, the RDNA2 GPUs it names and newer ones, is offered as it is. The other GPUs of those families, such as the Radeon 680M and 780M, are offered as experimental and are never the proposed option: ROCm does not support them officially, the application presents them as the generation of their family (HSA_OVERRIDE_GFX_VERSION) and the installer asks for confirmation before the larger image is downloaded. An older GPU, such as the integrated graphics of a Ryzen 5000U, is not offered and Immich keeps recognition on the CPU"], - ["NVIDIA", "nvidia-smi and nvidia-container-cli", "GPU, UUID, PCI bus, driver version, Toolkit, /dev/nvidia* nodes, binaries and libraries"], - ["Coral PCIe/M.2", "/dev/apex_N and its link in /sys/dev/char/MAJOR:MINOR", "Character node, major/minor, owner, GID and permissions"], - ["USB and serial", "/dev/ttyUSB*, /dev/ttyACM* or /dev/bus/usb/BBB/DDD", "Character node; for USB also vendor, product and serial when sysfs publishes them"], - ["KVM, TUN, FUSE, video and generic SCSI", "/dev/kvm, /dev/net/tun, /dev/fuse, /dev/videoN or /dev/sgN", "Supported path, node type and effective permissions"], - ["Optical drive", "/dev/srN", "A block device"] + [ + "Intel/AMD DRM", + "/dev/dri/renderD* and /sys/class/drm/NODE/device/vendor", + "A character device with vendor 0x8086 (Intel) or 0x1002 (AMD)" + ], + [ + "AMD OpenCL", + "The render node, plus /dev/kfd when the profile needs it", + "Existence, type, vendor, permissions and declared compatibility" + ], + [ + "AMD ROCm", + "The render node, /dev/kfd and the generation the compute driver reports in /sys/class/kfd/kfd/topology/nodes/*/properties", + "A GPU of a generation the application's ROCm image supports (the RDNA2 GPUs it names, and newer ones) is offered as it is. Other GPUs of those families, such as the Radeon 680M and 780M, are offered as experimental and are never the proposed option. ROCm does not support them officially: the application presents them as the generation of their family (HSA_OVERRIDE_GFX_VERSION), and the installer asks for confirmation before downloading the larger image. An older GPU, such as the integrated graphics of a Ryzen 5000U, is not offered, and Immich keeps recognition on the CPU" + ], + [ + "NVIDIA", + "nvidia-smi and nvidia-container-cli", + "GPU, UUID, PCI bus, driver version, Toolkit, /dev/nvidia* nodes, binaries and libraries" + ], + [ + "Coral PCIe/M.2", + "/dev/apex_N and its link in /sys/dev/char/MAJOR:MINOR", + "Character node, major/minor, owner, GID and permissions" + ], + [ + "USB and serial", + "/dev/ttyUSB*, /dev/ttyACM* or /dev/bus/usb/BBB/DDD", + "Character node; for USB also vendor, product and serial when sysfs publishes them" + ], + [ + "KVM, TUN, FUSE, video and generic SCSI", + "/dev/kvm, /dev/net/tun, /dev/fuse, /dev/videoN or /dev/sgN", + "Supported path, node type and effective permissions" + ], + [ + "Optical drive", + "/dev/srN", + "A block device" + ] ] } } @@ -79,12 +144,30 @@ { "steps": { "items": [ - { "title": "The template offers its profiles", "body": "For example CPU only, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL or NVIDIA. The options belong to the image, not to a common menu." }, - { "title": "A profile is chosen", "body": "It defines the device nodes, environment, mods or runtime the application needs." }, - { "title": "A path is proposed", "body": "For DRM, /dev/dri/renderD128, which can be changed on a host with several render nodes. For USB or serial, the concrete node is selected." }, - { "title": "Validation", "body": "Existence, type, allowed vendor, permissions and GID are checked. A mismatch stops the operation." }, - { "title": "The contract is written", "body": "Path, mode, GID, write access and profile are recorded for updates and recreations." }, - { "title": "Attach and test", "body": "pct set adds the devN entry and access is then checked inside the LXC. LinuxServer images are also checked as user abc." } + { + "title": "The template offers its profiles", + "body": "For example CPU only, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL or NVIDIA. The options belong to the image, not to a common menu." + }, + { + "title": "A profile is chosen", + "body": "It defines the device nodes, environment, mods or runtime the application needs." + }, + { + "title": "A path is proposed", + "body": "For DRM, /dev/dri/renderD128, which can be changed on a host with several render nodes. For USB or serial, the concrete node is selected." + }, + { + "title": "Validation", + "body": "Existence, type, allowed vendor, permissions and GID are checked. A mismatch stops the operation." + }, + { + "title": "The contract is written", + "body": "Path, mode, GID, write access and profile are recorded for updates and recreations." + }, + { + "title": "Attach and test", + "body": "pct set adds the devN entry and access is then checked inside the LXC. LinuxServer images are also checked as user abc." + } ] } } @@ -98,10 +181,22 @@ { "codeGrid": { "items": [ - { "title": "Intel/AMD VA-API", "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0" }, - { "title": "Coral PCIe/M.2", "code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0" }, - { "title": "A specific USB device", "code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0" }, - { "title": "AMD OpenCL", "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0" } + { + "title": "Intel/AMD VA-API", + "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0" + }, + { + "title": "Coral PCIe/M.2", + "code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0" + }, + { + "title": "A specific USB device", + "code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0" + }, + { + "title": "AMD OpenCL", + "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0" + } ] } }, @@ -116,13 +211,37 @@ "blocks": [ { "table": { - "headers": ["Profile", "Translation", "Offered when"], + "headers": [ + "Profile", + "Translation", + "Offered when" + ], "rows": [ - ["Intel/AMD VA-API", "/dev/dri render node", "The application supports video acceleration"], - ["OpenCL", "Render node, /dev/kfd when needed and the official mod", "The image or profile documents it"], - ["NVIDIA", "Driver devices and libraries of the host", "The host has a working driver and the NVIDIA Container Toolkit"], - ["Coral", "/dev/apex_0 or the USB bus", "The profile declares Coral support (Frigate)"], - ["USB, serial, FUSE", "A single device, a validated tree or an LXC feature", "The contract asks for it"] + [ + "Intel/AMD VA-API", + "/dev/dri render node", + "The application supports video acceleration" + ], + [ + "OpenCL", + "Render node, /dev/kfd when needed and the official mod", + "The image or profile documents it" + ], + [ + "NVIDIA", + "Driver devices and libraries of the host", + "The host has a working driver and the NVIDIA Container Toolkit" + ], + [ + "Coral", + "/dev/apex_0 or the USB bus", + "The profile declares Coral support (Frigate)" + ], + [ + "USB, serial, FUSE", + "A single device, a validated tree or an LXC feature", + "The contract asks for it" + ] ] } } @@ -145,7 +264,9 @@ "p": "These two commands on the host show whether the driver and the Toolkit are available:" }, { - "shell": { "code": "nvidia-smi -L\nnvidia-container-cli --version" } + "shell": { + "code": "nvidia-smi -L\nnvidia-container-cli --version" + } }, { "p": "On a host where the driver was installed by other means, the Toolkit is installed from the official stable repository:" @@ -159,7 +280,9 @@ "p": "The inventory OCI manager Apps uses is the output of:" }, { - "shell": { "code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs" } + "shell": { + "code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs" + } }, { "calloutInfo": { @@ -170,10 +293,26 @@ { "cards": { "items": [ - { "icon": "cpu", "title": "Inventory from the driver", "body": "nvidia-container-cli lists the device nodes, binaries, firmware and libraries of the installed driver." }, - { "icon": "refresh", "title": "No fixed version", "body": "The template does not name library files. The profile is generated from the current host." }, - { "icon": "shield", "title": "Read-only mounts", "body": "The host libraries are mounted read-only instead of being copied into the container." }, - { "icon": "hardDrive", "title": "Driver changes", "body": "After a driver change the inventory is generated again before the affected LXCs start." } + { + "icon": "cpu", + "title": "Inventory from the driver", + "body": "nvidia-container-cli lists the device nodes, binaries, firmware and libraries of the installed driver." + }, + { + "icon": "refresh", + "title": "No fixed version", + "body": "The template does not name library files. The profile is generated from the current host." + }, + { + "icon": "shield", + "title": "Read-only mounts", + "body": "The host libraries are mounted read-only instead of being copied into the container." + }, + { + "icon": "hardDrive", + "title": "Driver changes", + "body": "After a driver change the inventory is generated again before the affected LXCs start." + } ] } }, @@ -209,12 +348,32 @@ "blocks": [ { "table": { - "headers": ["Request", "Translation", "Scope"], + "headers": [ + "Request", + "Translation", + "Scope" + ], "rows": [ - ["/dev/dvb, /dev/snd or /dev/bus/usb", "Each character node of the tree gets its own devN entry with the host mode and GID", "Only the requested tree, not the rest of /dev"], - ["/dev/fuse", "The node and, when the profile needs it, the fuse=1 feature", "FUSE alone does not publish mounts to other LXCs"], - ["/dev/net/tun", "A devN entry at the same path inside the LXC", "The VPN or network configuration stays in the application"], - ["/dev/kvm", "A validated devN entry", "Offered only when the contract asks for it"] + [ + "/dev/dvb, /dev/snd or /dev/bus/usb", + "Each character node of the tree gets its own devN entry with the host mode and GID", + "Only the requested tree, not the rest of /dev" + ], + [ + "/dev/fuse", + "The node and, when the profile needs it, the fuse=1 feature", + "FUSE alone does not publish mounts to other LXCs" + ], + [ + "/dev/net/tun", + "A devN entry at the same path inside the LXC", + "The VPN or network configuration stays in the application" + ], + [ + "/dev/kvm", + "A validated devN entry", + "Offered only when the contract asks for it" + ] ] } } diff --git a/web/messages/en/docs/oci-manager/lifecycle.json b/web/messages/en/docs/oci-manager/lifecycle.json index cdb3f103..b2889dcf 100644 --- a/web/messages/en/docs/oci-manager/lifecycle.json +++ b/web/messages/en/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "The new image is verified layer by layer before the CT stops. A download that arrives damaged is fetched a second time; an image already cached that fails the check is downloaded again.", "Settings changed in Proxmox VE after the installation (memory, swap, cores, CPU limit, CPU priority, start with the node) are kept and carried into the new contract.", "The LAN interface that the Arr suite and multi-container applications add (net1) and the start order (startup) are given back to the new container as they are.", + "A host directory is recognised by its path and by the filesystem it is on, not by the device name the host gives its disk, so a USB or network disk that comes back under another name is still the same directory. When its disk is not connected, the update stops before the CT is stopped and names the directory that is missing.", "Any other difference between the CT and its contract stops the update before the CT is stopped." ] } diff --git a/web/messages/en/docs/oci-manager/storage-network.json b/web/messages/en/docs/oci-manager/storage-network.json index 4665d890..1ad30c17 100644 --- a/web/messages/en/docs/oci-manager/storage-network.json +++ b/web/messages/en/docs/oci-manager/storage-network.json @@ -28,12 +28,30 @@ { "steps": { "items": [ - { "title": "Required paths", "body": "/config, /data, libraries, downloads and every volume the application declares are listed." }, - { "title": "Location", "body": "Each path is placed on a disk of the container or on an existing host directory." }, - { "title": "Storage and size", "body": "A container disk is created on a Proxmox VE storage with the size given. The default installation uses local-lvm; the advanced installation asks the storage of each path right before its size and proposes the one of the rootfs. It appears as vm-VMID-disk-N and is attached as mpN." }, - { "title": "Host directory", "body": "A host directory is given by its path. A directory that does not exist is created, owned by the user the container maps." }, - { "title": "Additional paths", "body": "More pairs of host path or volume and container path can be added before installing." }, - { "title": "Summary", "body": "The complete mapping is shown before the CT is created and is stored in its instance contract." } + { + "title": "Required paths", + "body": "/config, /data, libraries, downloads and every volume the application declares are listed." + }, + { + "title": "Location", + "body": "Each path is placed on a disk of the container or on an existing host directory." + }, + { + "title": "Storage and size", + "body": "A container disk is created on a Proxmox VE storage with the size given. The default installation asks once for the storage of the container and its data when the node has more than one; the advanced installation asks the storage of each path right before its size and proposes the one of the rootfs. It appears as vm-VMID-disk-N and is attached as mpN." + }, + { + "title": "Host directory", + "body": "A host directory is given by its path. A directory that does not exist is created, owned by the user the container maps." + }, + { + "title": "Additional paths", + "body": "More pairs of host path or volume and container path can be added before installing." + }, + { + "title": "Summary", + "body": "The complete mapping is shown before the CT is created and is stored in its instance contract." + } ] } } @@ -45,20 +63,55 @@ "blocks": [ { "table": { - "headers": ["Property", "Container disk", "Host directory"], + "headers": [ + "Property", + "Container disk", + "Host directory" + ], "rows": [ - ["In the configuration", "mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G", "mpN: /mnt/oci-shared/media,mp=/data/media"], - ["Container backup (vzdump)", "Included, with backup=1", "Not included"], - ["Size", "Fixed; grown with a resize of the mount point", "The free space of the host filesystem or dataset"], - ["Other containers", "Mounted only by its own container", "The same directory can be mounted in several containers"], - ["Snapshots and restore", "Managed by Proxmox VE together with the CT", "Managed on the host storage"], - ["Removing the application", "Deleted with the container", "Kept, with its content"], - ["Moving the CT to another node", "Moves with the CT", "The same path has to exist on the other node"] + [ + "In the configuration", + "mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G", + "mpN: /mnt/oci-shared/media,mp=/data/media" + ], + [ + "Container backup (vzdump)", + "Included, with backup=1", + "Not included" + ], + [ + "Size", + "Fixed; grown with a resize of the mount point", + "The free space of the host filesystem or dataset" + ], + [ + "Other containers", + "Mounted only by its own container", + "The same directory can be mounted in several containers" + ], + [ + "Snapshots and restore", + "Managed by Proxmox VE together with the CT", + "Managed on the host storage" + ], + [ + "Removing the application", + "Deleted with the container", + "Kept, with its content" + ], + [ + "Moving the CT to another node", + "Moves with the CT", + "The same path has to exist on the other node" + ] ] } }, { "p": "The rootfs is reserved for the binaries and the content of the image. An update or a recreation replaces it without touching either kind of mount point." + }, + { + "p": "A host directory is mounted with everything the host has mounted inside it. A directory such as /mnt/pve shows its network shares, disks and datasets in the container, and what the host mounts or unmounts there later appears or disappears without restarting the container. A directory added as read-only is read-only together with what is mounted inside it when the container starts. A filesystem the host mounts afterwards arrives with the permissions the host mounts it with, and becomes read-only as well when the container is restarted." } ] }, @@ -78,9 +131,18 @@ { "flow": { "nodes": [ - { "label": "Contract", "detail": "/config" }, - { "label": "Location", "detail": "container disk\nor host directory" }, - { "label": "LXC", "detail": "always /config\nfor the application" } + { + "label": "Contract", + "detail": "/config" + }, + { + "label": "Location", + "detail": "container disk\nor host directory" + }, + { + "label": "LXC", + "detail": "always /config\nfor the application" + } ], "caption": "The application sees the path the image publishes; only where it is stored changes." } @@ -94,7 +156,10 @@ { "mermaid": { "chartCode": "flowchart TB\n H[\"{{host}}
/mnt/oci-shared/media\"]\n H --> Q[\"qBittorrent
/data\"]\n H --> J[\"Jellyfin
/data\"]\n H --> R[\"Radarr / Sonarr
/data\"]\n Q -. \"{{config}}\" .-> QV[(\"/config mpN\")]\n J -. \"{{config}}\" .-> JV[(\"/config mpN\")]\n R -. \"{{config}}\" .-> RV[(\"/config mpN\")]", - "labels": { "host": "Host directory", "config": "own configuration" } + "labels": { + "host": "Host directory", + "config": "own configuration" + } } }, { @@ -110,10 +175,22 @@ { "steps": { "items": [ - { "title": "Container and remote", "body": "The VMID of the Rclone container, the exact name of the remote and, optionally, a path inside it." }, - { "title": "Mount name and cache", "body": "The name of the mount and the VFS cache mode: off, minimal, writes or full (default)." }, - { "title": "Published views", "body": "A common root, /mnt/oci-shared by default, holds a read/write view in /mnt/oci-shared/remotes/NAME and a read-only view in /mnt/oci-shared/remotes-ro/NAME." }, - { "title": "Activation", "body": "After a confirmation, the CT is stopped, its start command and a Proxmox VE hookscript are set, and it is started again. The operation waits until both views are mounted on the host." } + { + "title": "Container and remote", + "body": "The VMID of the Rclone container, the exact name of the remote and, optionally, a path inside it." + }, + { + "title": "Mount name and cache", + "body": "The name of the mount and the VFS cache mode: off, minimal, writes or full (default)." + }, + { + "title": "Published views", + "body": "A common root, /mnt/oci-shared by default, holds a read/write view in /mnt/oci-shared/remotes/NAME and a read-only view in /mnt/oci-shared/remotes-ro/NAME." + }, + { + "title": "Activation", + "body": "After a confirmation, the CT is stopped, its start command and a Proxmox VE hookscript are set, and it is started again. The operation waits until both views are mounted on the host." + } ] } }, @@ -133,17 +210,34 @@ { "cards": { "items": [ - { "icon": "network", "title": "Single application", "body": "Bridge and DHCP or a fixed CIDR address are chosen. The LXC has an address of its own and the summary shows the complete URLs of the services." }, - { "icon": "waypoints", "title": "Multi-container application", "body": "A free subnet is found, a persistent private bridge is created and each member (application, database, cache) gets a fixed address on it." } + { + "icon": "network", + "title": "Single application", + "body": "Bridge and DHCP or a fixed CIDR address are chosen. The LXC has an address of its own and the summary shows the complete URLs of the services." + }, + { + "icon": "waypoints", + "title": "Multi-container application", + "body": "A free subnet is found, a persistent private bridge is created and each member (application, database, cache) gets a fixed address on it." + } ] } }, { "flow": { "nodes": [ - { "label": "LAN", "detail": "reachable address\nmain service only" }, - { "label": "Main LXC", "detail": "web / API\nLAN + private network" }, - { "label": "Private network", "detail": "PostgreSQL · Valkey · ML\nfixed addresses" } + { + "label": "LAN", + "detail": "reachable address\nmain service only" + }, + { + "label": "Main LXC", + "detail": "web / API\nLAN + private network" + }, + { + "label": "Private network", + "detail": "PostgreSQL · Valkey · ML\nfixed addresses" + } ], "caption": "Dependencies talk over the private network and have no address on the LAN." } @@ -174,13 +268,37 @@ "blocks": [ { "table": { - "headers": ["Element", "In the CT vzdump", "Where it is kept"], + "headers": [ + "Element", + "In the CT vzdump", + "Where it is kept" + ], "rows": [ - ["OCI rootfs", "Yes", "The CT backup; it can also be rebuilt from the image and the contract"], - ["Container disk with backup=1", "Yes", "The CT backup"], - ["Host directory", "No", "The backup of the host storage"], - ["Instance contract", "Yes, the copy carried inside the CT", "/.proxmenux/oci-record.json inside the CT; additional host and cluster copies are kept separately"], - ["Multi-container application", "Each member in its own backup", "The backups of every member, plus the stack contract and its bridge on the host"] + [ + "OCI rootfs", + "Yes", + "The CT backup; it can also be rebuilt from the image and the contract" + ], + [ + "Container disk with backup=1", + "Yes", + "The CT backup" + ], + [ + "Host directory", + "No", + "The backup of the host storage" + ], + [ + "Instance contract", + "Yes, the copy carried inside the CT", + "/.proxmenux/oci-record.json inside the CT; additional host and cluster copies are kept separately" + ], + [ + "Multi-container application", + "Each member in its own backup", + "The backups of every member, plus the stack contract and its bridge on the host" + ] ] } } diff --git a/web/messages/en/docs/post-install/storage.json b/web/messages/en/docs/post-install/storage.json index 2998ba58..be7aced9 100644 --- a/web/messages/en/docs/post-install/storage.json +++ b/web/messages/en/docs/post-install/storage.json @@ -117,7 +117,7 @@ "manualIntro": "The full sequence the script runs against each pool is replicable by hand. This is what you would type if you wanted to do the same thing on a single pool without ProxMenux:", "verifyTitle": "Verification and manual rollback", "oneShotTitle": "Need a one-shot trim instead of continuous?", - "oneShotBody": "Some operators prefer a manual trim during off-peak hours rather than continuous trim activity. Disable autotrim and schedule a cron job that runs zpool trim <pool> — same end goal, different cadence." + "oneShotBody": "Some users prefer a manual trim during off-peak hours rather than continuous trim activity. Disable autotrim and schedule a cron job that runs zpool trim <pool> — same end goal, different cadence." }, "vzdump": { "heading": "Increase vzdump backup speed", diff --git a/web/messages/en/docs/post-install/updates.json b/web/messages/en/docs/post-install/updates.json index 482c4072..fa9fb3ea 100644 --- a/web/messages/en/docs/post-install/updates.json +++ b/web/messages/en/docs/post-install/updates.json @@ -14,7 +14,7 @@ }, "why": { "heading": "Why this exists", - "body": "Post-install optimizations occasionally get improvements — a better sysctl tuning, a stricter Logrotate limit, a new Log2RAM size heuristic, a fix for an edge case reported by a tester. Without an update path the operator had only two options: manually re-run the post-install script (which re-applies every optimization) or skip the improvement entirely. Apply Available Updates is the middle ground: a per-optimization, opt-in re-run that lifts only the versions that actually moved." + "body": "Post-install optimizations occasionally get improvements — a better sysctl tuning, a stricter Logrotate limit, a new Log2RAM size heuristic, a fix for an edge case reported by a tester. Without an update path the user had only two options: manually re-run the post-install script (which re-applies every optimization) or skip the improvement entirely. Apply Available Updates is the middle ground: a per-optimization, opt-in re-run that lifts only the versions that actually moved." }, "detection": { "heading": "How updates are detected", @@ -25,7 +25,7 @@ }, { "title": "Versioned registry on the host", - "body": "When the operator applied each optimization, the corresponding register_tool call wrote the active version into /usr/local/share/proxmenux/installed_tools.json. That file is the source of truth for \"what is active on this host right now\"." + "body": "When the user applied each optimization, the corresponding register_tool call wrote the active version into /usr/local/share/proxmenux/installed_tools.json. That file is the source of truth for \"what is active on this host right now\"." }, { "title": "Monitor compares both sides", diff --git a/web/messages/en/docs/settings/beta-program.json b/web/messages/en/docs/settings/beta-program.json index 8157582a..a926b253 100644 --- a/web/messages/en/docs/settings/beta-program.json +++ b/web/messages/en/docs/settings/beta-program.json @@ -18,7 +18,7 @@ "heading": "Why this option exists", "intro": "ProxMenux ships from two git branches:", "items": [ - "Stable — the main branch. What the README points at, what most operators want, with a slower release cadence and only changes that have already been through beta validation.", + "Stable — the main branch. What the README points at, what most users want, with a slower release cadence and only changes that have already been through beta validation.", "Beta — the develop branch. Newer features and Monitor builds; carries the tag the next stable release will inherit. Some things may not work perfectly — that's the deal you sign up for and the way new features get tested before they ship." ], "outro": "Hopping between channels used to require remembering the right installer URL, copying it in from the README, and editing config.json by hand if something got out of sync. The unified option does the whole flow as a single guided action." @@ -75,7 +75,7 @@ }, "unifiedCallout": { "title": "Why both directions are now one option", - "body": "The previous “Deactivate Beta Program” only existed if the host had ever joined the beta. Operators wanting to join had to find the beta installer URL elsewhere; operators wanting to leave sometimes had to manually clean up beta_* metadata to be sure. The unified Change Release Channel option always shows up, makes the current channel explicit, and treats both directions as the same kind of operation — runnable, repeatable, idempotent." + "body": "The previous “Deactivate Beta Program” only existed if the host had ever joined the beta. Users wanting to join had to find the beta installer URL elsewhere; users wanting to leave sometimes had to manually clean up beta_* metadata to be sure. The unified Change Release Channel option always shows up, makes the current channel explicit, and treats both directions as the same kind of operation — runnable, repeatable, idempotent." }, "troubleshoot": { "heading": "Troubleshooting", diff --git a/web/messages/en/docs/settings/proxmenux-monitor.json b/web/messages/en/docs/settings/proxmenux-monitor.json index 5444e906..f5284f6f 100644 --- a/web/messages/en/docs/settings/proxmenux-monitor.json +++ b/web/messages/en/docs/settings/proxmenux-monitor.json @@ -71,7 +71,7 @@ }, "reset": { "heading": "Reset ProxMenux Monitor Password", - "intro": "Recovery path for the operator who lost the dashboard password (or 2FA device). The option only appears when the Monitor is installed on the host. Selecting it:", + "intro": "Recovery path for the user who lost the dashboard password (or 2FA device). The option only appears when the Monitor is installed on the host. Selecting it:", "items": [ "Asks for confirmation with a yes/no dialog — the action is destructive for the login credentials.", "Backs up the existing /root/.config/proxmenux-monitor/auth.json to auth.json.bak-<UTC timestamp> (mode 0600) so the previous state can be restored manually if the reset was a mistake.", diff --git a/web/messages/en/guides/nvidia-manual.json b/web/messages/en/guides/nvidia-manual.json index 513a1f99..395db3b8 100644 --- a/web/messages/en/guides/nvidia-manual.json +++ b/web/messages/en/guides/nvidia-manual.json @@ -12,7 +12,7 @@ }, "intro": { "calloutTitle": "Note", - "calloutBody": "This is the manual procedure preserved as a reference. For most users the recommended path is the automated ProxMenux flow: Install NVIDIA Drivers (Host) in the GPUs and Coral-TPU menu, and Add GPU to LXC (or Add GPU to VM) for the per-guest wiring. The automated flow handles the same steps documented here (with extra safety checks: kernel-headers compatibility, IOMMU validation, VFIO conflict resolution). This page is for operators who want to understand each command, or who need to deviate from the standard flow.", + "calloutBody": "This is the manual procedure preserved as a reference. For most users the recommended path is the automated ProxMenux flow: Install NVIDIA Drivers (Host) in the GPUs and Coral-TPU menu, and Add GPU to LXC (or Add GPU to VM) for the per-guest wiring. The automated flow handles the same steps documented here (with extra safety checks: kernel-headers compatibility, IOMMU validation, VFIO conflict resolution). This page is for users who want to understand each command, or who need to deviate from the standard flow.", "targetNote": "Targeted at Proxmox VE 9 (Debian Trixie). PVE 7 (Bullseye) and PVE 8 (Bookworm) are no longer covered.", "stepsTitle": "What you'll do", "steps": [ diff --git a/web/messages/es/docs/backup-restore/creating-backups.json b/web/messages/es/docs/backup-restore/creating-backups.json index b3805757..21b9f6a2 100644 --- a/web/messages/es/docs/backup-restore/creating-backups.json +++ b/web/messages/es/docs/backup-restore/creating-backups.json @@ -118,7 +118,7 @@ { "step": "5", "name": "Notificación (start)", - "detail": "Se dispara hb_notify_lifecycle \"start\". Si las notificaciones están configuradas en el Monitor, se emite un evento usuario-facing Host backup started. Silencioso si no hay canales configurados." + "detail": "Se dispara hb_notify_lifecycle \"start\". Si las notificaciones están configuradas en el Monitor, se emite el evento Host backup started, visible para el usuario. Si no hay canales configurados, no se envía nada." } ] }, diff --git a/web/messages/es/docs/backup-restore/destinations/index.json b/web/messages/es/docs/backup-restore/destinations/index.json index 1f6eca83..41584e5f 100644 --- a/web/messages/es/docs/backup-restore/destinations/index.json +++ b/web/messages/es/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "El contenido interno del backup es el mismo en cualquier destino", - "body": "Los tres destinos contienen la misma estructura rootfs/ + metadata/ + manifest.json descrita en Cómo funciona. Extraer un .tar.zst de un archivo local, restaurar un .pxar desde PBS o extraer un archivo de Borg con borg extract produce el mismo árbol de directorios. El proceso de restauración (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lee los mismos tres componentes sin necesitar saber de qué destino proceden." + "body": "Con independencia de dónde se guarde el backup, dentro siempre están los mismos tres bloques descritos en Cómo funciona: el sistema de ficheros (rootfs/), los metadatos (metadata/) y el manifiesto (manifest.json). Al extraer un archivo local .tar.zst, restaurar un .pxar desde PBS o extraer un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Por eso la restauración lee siempre los mismos ficheros, venga el backup del destino que venga." }, "extractStandalone": { "heading": "Extraer un backup fuera de ProxMenux", diff --git a/web/messages/es/docs/backup-restore/destinations/pbs.json b/web/messages/es/docs/backup-restore/destinations/pbs.json index d92ff2ef..5a209e6b 100644 --- a/web/messages/es/docs/backup-restore/destinations/pbs.json +++ b/web/messages/es/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Selección del repositorio", - "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; esa elección determina los valores de HB_PBS_REPOSITORY, HB_PBS_SECRET y HB_PBS_FINGERPRINT para esa ejecución.", + "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; en esa ejecución, la elección determina a qué servidor y datastore se envía el backup, la contraseña con la que se autentica y la fingerprint que valida el certificado.", "sourceRows": [ { "source": "storage.cfg de Proxmox (auto-descubierto)", @@ -46,7 +46,7 @@ "backupIdTitle": "Nombrado del backup ID", "backupIdBody": "El backup ID por defecto es hostcfg-HOSTNAME. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de [A-Za-z0-9_-] se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un grupo, y cada backup posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.", "pxarTitle": "Qué se incluye dentro del archivo .pxar", - "pxarBody": "El origen del .pxar es todo el directorio staging_root, con rootfs/, metadata/ y manifest.json juntos. Las versiones anteriores utilizaban $staging_root/rootfs como origen; esto dejaba metadata/ fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Los backups antiguos creados solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de _rs_check_layout, que vuelve a colocar el árbol plano etc/var/root/usr dentro de una estructura rootfs/." + "pxarBody": "El archivo .pxar empaqueta todo el directorio de trabajo: el sistema de ficheros del host (rootfs/), los metadatos (metadata/) y el manifiesto (manifest.json). Al restaurar, ProxMenux compara el manifiesto con el host de destino para saber si son equivalentes, si ha cambiado el hardware o si es otra máquina, y adapta el proceso. Los backups antiguos, hechos por versiones anteriores de ProxMenux que solo empaquetaban el sistema de ficheros, se siguen restaurando bien: la restauración detecta ese formato antiguo y lo reorganiza automáticamente." }, "encryption": { "heading": "Cifrado del lado del cliente", diff --git a/web/messages/es/docs/backup-restore/how-it-works.json b/web/messages/es/docs/backup-restore/how-it-works.json index 9240775f..7cfe2eaa 100644 --- a/web/messages/es/docs/backup-restore/how-it-works.json +++ b/web/messages/es/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Validación por esquema", - "schemaBody": "El manifiesto se valida con scripts/backup_restore/schema/manifest.schema.json. Ejecutar build_manifest.sh --validate activa una validación JSON Schema en Python (requiere python3 y jsonschema). Si el módulo no está instalado, se omite la comprobación sin mostrar ningún aviso: esta validación es principalmente una ayuda para el desarrollo, no una dependencia necesaria durante la ejecución." + "schemaBody": "ProxMenux incluye una plantilla que describe qué campos debe contener el manifiesto y qué forma tiene cada uno. Cuando se genera un backup se puede comprobar automáticamente que el manifiesto respeta esa plantilla, de modo que si un colector produjera un JSON malformado o con un campo mal escrito se detectaría en el momento. Es una comprobación destinada al desarrollo del propio ProxMenux: si el sistema no la tiene instalada, el backup sigue funcionando con normalidad y el manifiesto se genera igual." }, "applications": { "heading": "El inventario de aplicaciones", diff --git a/web/messages/es/docs/oci-manager/hardware.json b/web/messages/es/docs/oci-manager/hardware.json index 72239db9..8671c092 100644 --- a/web/messages/es/docs/oci-manager/hardware.json +++ b/web/messages/es/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "El nodo de render, /dev/kfd y la generación que declara el driver de cómputo en /sys/class/kfd/kfd/topology/nodes/*/properties", - "Una generación para la que la imagen ROCm de la aplicación trae kernels, las GPU RDNA2 que incluye y las posteriores, se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta: ROCm no las soporta oficialmente, la aplicación las presenta como la generación de su familia (HSA_OVERRIDE_GFX_VERSION) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece e Immich deja el reconocimiento en la CPU" + "Una GPU de una generación que la imagen ROCm de la aplicación soporta (las RDNA2 que nombra y las posteriores) se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta. ROCm no las soporta oficialmente: la aplicación las presenta como la generación de su familia (HSA_OVERRIDE_GFX_VERSION) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece, e Immich deja el reconocimiento en la CPU" ], [ "NVIDIA", diff --git a/web/messages/es/docs/oci-manager/lifecycle.json b/web/messages/es/docs/oci-manager/lifecycle.json index 0649c11e..94f8da98 100644 --- a/web/messages/es/docs/oci-manager/lifecycle.json +++ b/web/messages/es/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "La imagen nueva se verifica capa a capa antes de detener el CT. Una descarga que llega dañada se repite una vez; una imagen ya almacenada que no supera la comprobación se descarga de nuevo.", "Los ajustes cambiados en Proxmox VE después de la instalación (memoria, swap, núcleos, límite de CPU, prioridad de CPU, arranque con el nodo) se conservan y pasan al contrato nuevo.", "La interfaz de la LAN que añaden la suite Arr y las aplicaciones multicontenedor (net1) y el orden de arranque (startup) se devuelven tal cual al contenedor nuevo.", + "Un directorio del host se reconoce por su ruta y por el sistema de ficheros en el que está, no por el nombre de dispositivo que el host da a su disco, así que un disco USB o de red que vuelve con otro nombre sigue siendo el mismo directorio. Si su disco no está conectado, la actualización se detiene antes de parar el CT e indica qué directorio falta.", "Cualquier otra diferencia entre el CT y su contrato detiene la actualización antes de detener el CT." ] } diff --git a/web/messages/es/docs/oci-manager/storage-network.json b/web/messages/es/docs/oci-manager/storage-network.json index 5884786e..3c5062d6 100644 --- a/web/messages/es/docs/oci-manager/storage-network.json +++ b/web/messages/es/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Almacenamiento y tamaño", - "body": "Se crea un disco del contenedor en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación predeterminada usa local-lvm; la avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. El disco aparece como vm-VMID-disk-N y se conecta como mpN." + "body": "Un disco del contenedor se crea en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación por defecto pregunta una sola vez el almacenamiento del contenedor y sus datos cuando el nodo tiene más de uno; la instalación avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. Aparece como vm-VMID-disk-N y se conecta como mpN." }, { "title": "Directorio del host", @@ -109,6 +109,9 @@ }, { "p": "El rootfs se reserva para los binarios y el contenido de la imagen. Una actualización o recreación lo sustituye sin tocar ninguno de los dos tipos de punto de montaje." + }, + { + "p": "Un directorio del host se monta con todo lo que el host tiene montado dentro de él. Un directorio como /mnt/pve muestra en el contenedor sus recursos de red, discos y datasets, y lo que el host monta o desmonta allí después aparece o desaparece sin reiniciar el contenedor. Un directorio añadido como solo lectura lo es junto con lo que tiene montado dentro al iniciar el contenedor. Un sistema de archivos que el host monta después llega con los permisos con los que el host lo monta, y pasa también a solo lectura al reiniciar el contenedor." } ] }, diff --git a/web/messages/fr/docs/backup-restore/destinations/index.json b/web/messages/fr/docs/backup-restore/destinations/index.json index ff0d8970..8e840e8d 100644 --- a/web/messages/fr/docs/backup-restore/destinations/index.json +++ b/web/messages/fr/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "La disposition des archives ne change pas avec la destination", - "body": "A l'intérieur de l'une des trois destinations, la même disposition rootfs/ + metadata/ + manifest.json décrite dans Comment ça marche est présente. Un .tar.zst extrait d'une archive locale, un .pxar restauré de PBS et une archive Borg extraite de borg extract donnent tous un arbre de répertoire identique. Le chemin du code de restauration (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent." + "body": "Quel que soit l’endroit où la sauvegarde est stockée, elle contient toujours les trois mêmes blocs décrits dans Comment ça marche : le système de fichiers (rootfs/), les métadonnées (metadata/) et le manifeste (manifest.json). L’extraction d’une archive locale .tar.zst, la restauration d’un .pxar depuis PBS ou l’extraction d’une archive Borg produisent toutes une arborescence identique. La restauration lit donc toujours les mêmes fichiers, quelle que soit la destination d’où provient la sauvegarde." }, "extractStandalone": { "heading": "Extraire une sauvegarde à l'extérieur de ProxMenux", diff --git a/web/messages/fr/docs/backup-restore/destinations/pbs.json b/web/messages/fr/docs/backup-restore/destinations/pbs.json index ef0daf61..dc0139b8 100644 --- a/web/messages/fr/docs/backup-restore/destinations/pbs.json +++ b/web/messages/fr/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Sélection du dépôt", - "intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine HB_PBS_REPOSITORY, HB_PBS_SECRET et HB_PBS_FINGERPRINT pour l'exécution.", + "intro": "ProxMenux découvre les dépôts PBS à partir de deux sources à chaque sauvegarde. L’utilisateur en choisit un dans un menu unifié ; pour cette exécution, ce choix détermine le serveur et le datastore vers lesquels la sauvegarde est envoyée, le mot de passe avec lequel elle s’authentifie et l’empreinte qui valide le certificat.", "sourceRows": [ { "source": "storage.cfg de Proxmox (détection automatique)", @@ -46,7 +46,7 @@ "backupIdTitle": "Nom de l'ID de sauvegarde", "backupIdBody": "L’identifiant de sauvegarde par défaut est hostcfg-HOSTNAME. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de [A-Za-z0-9_-] et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un groupe. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.", "pxarTitle": "Pourquoi la source est la racine de mise en scène complète", - "pxarBody": "La source .pxar est la totalité du staging_root — rootfs/, metadata/ et manifest.json ensemble. Les versions antérieures ont passé le $staging_root/rootfs comme source; cela a laissé le metadata/ hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-_rs_check_layout de 3, qui enveloppe un arbre plat etc/var/root/usr dans une hiérarchie rootfs/." + "pxarBody": "L’archive .pxar regroupe l’ensemble du répertoire de travail : le système de fichiers de l’hôte (rootfs/), les métadonnées (metadata/) et le manifeste (manifest.json). Lors de la restauration, ProxMenux compare le manifeste avec l’hôte cible pour déterminer s’ils sont équivalents, si le matériel a changé ou s’il s’agit d’une autre machine, et adapte le processus en conséquence. Les sauvegardes plus anciennes, réalisées par des versions antérieures de ProxMenux qui n’empaquetaient que le système de fichiers, se restaurent toujours correctement : la restauration détecte cet ancien format et le réorganise automatiquement." }, "encryption": { "heading": "Chiffrement côté client", @@ -63,7 +63,7 @@ "recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide", "recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, Déposer la clé sur PBS ?, avec deux réponses. Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui. Le choix par défaut est Non, conserver uniquement en local : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton Télécharger le fichier clé du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir Oui, envoyer demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant pbs-key.recovery.enc. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.", "blobUploadTitle": "Groupe de sauvegarde associé sur PBS", - "blobUploadBody1": "Lorsque le mode de dépôt est Oui, envoyer, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe -keyrecovery. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. L’enveloppe ne quitte jamais l’hôte en clair : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS ne reçoit que l’enveloppe déjà chiffrée.", + "blobUploadBody1": "Lorsque la réponse est Oui, envoyer, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe de sauvegarde associé. Son nom reprend celui du groupe de l’hôte avec le suffixe -keyrecovery. Les deux groupes se trouvent côte à côte dans la liste du datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. L’enveloppe ne quitte jamais l’hôte en clair : le chiffrement se fait sur l’hôte lui-même avec AES-256-CBC et PBKDF2 avant toute transmission (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS ne reçoit que l’enveloppe déjà chiffrée.", "envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?", "envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.", "blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté", @@ -73,7 +73,7 @@ "recoverTitle": "Récupération sur un hôte frais", "recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans /etc/pve/priv/storage/<NAME>.enc, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe -keyrecovery existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie wrong key — manifest's key XX does not match provided key YY. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.", "monitorManagementTitle": "Gestion du fichier clé depuis le moniteur", - "monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : Télécharger exporte le fichier actuel vers le navigateur ; Envoyer remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; Supprimer retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour Déposer la clé sur PBS ?, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces." + "monitorManagementBody": "Monitor affiche les commandes du fichier clé dans chaque ligne de destination PBS de la page de configuration des sauvegardes. La ligne propose trois actions : Télécharger exporte le fichier clé actuel vers le navigateur de l’utilisateur, Envoyer remplace le fichier clé installé par celui fourni par l’utilisateur (l’ancien fichier n’est écrasé qu’une fois le nouveau arrivé correctement à son chemin) et Supprimer retire le fichier clé de l’hôte. Juste à côté se trouve l’interrupteur de l’enveloppe de récupération : un choix Oui/Non pour Déposer la clé sur PBS ?, un champ de phrase secrète qui apparaît lorsque Oui est sélectionné et un bouton qui suit l’état actuel : Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète. Les commandes de Monitor et la boîte de dialogue du shell font la même chose en arrière-plan : le résultat sur le disque et sur PBS est donc identique, quelle que soit l’interface utilisée." }, "restoreAccess": { "heading": "Récupération du côté restauration", diff --git a/web/messages/fr/docs/backup-restore/how-it-works.json b/web/messages/fr/docs/backup-restore/how-it-works.json index aba3a5f8..4bec322e 100644 --- a/web/messages/fr/docs/backup-restore/how-it-works.json +++ b/web/messages/fr/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Validation du schéma", - "schemaBody": "Le manifeste valide contre scripts/backup_restore/schema/manifest.schema.json. L'exécution du build_manifest.sh --validate déclenche une validation de schéma côté Python JSON (exige python3 + jsonschema). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution." + "schemaBody": "ProxMenux fournit un modèle qui décrit les champs que le manifeste doit contenir et la forme de chacun. Lors de la génération d’une sauvegarde, le manifeste peut être vérifié automatiquement par rapport à ce modèle, de sorte qu’un collecteur ayant produit un JSON mal formé ou un champ mal orthographié est détecté immédiatement. Cette vérification est destinée au développement de ProxMenux lui-même : sur un système où elle n’est pas installée, la sauvegarde fonctionne normalement et le manifeste est généré de la même façon." }, "applications": { "heading": "L'inventaire des applications", diff --git a/web/messages/fr/docs/backup-restore/scheduled-jobs.json b/web/messages/fr/docs/backup-restore/scheduled-jobs.json index 8f8ac95c..384fbe2c 100644 --- a/web/messages/fr/docs/backup-restore/scheduled-jobs.json +++ b/web/messages/fr/docs/backup-restore/scheduled-jobs.json @@ -127,7 +127,7 @@ }, "notifications": { "heading": "Notifications", - "body": "Chaque exécution programmée déclenche les mêmes événements hb_notify_lifecycle que le flux interactif (start, complete, fail). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi." + "body": "Chaque exécution programmée déclenche les mêmes événements hb_notify_lifecycle que le flux interactif (start, complete, fail). Si des canaux de notification sont configurés dans Monitor, les tâches sans surveillance présentent leurs résultats de la même manière que les sauvegardes manuelles : un utilisateur n’a pas besoin de consulter le journal pour savoir si une tâche a réussi." }, "whereNext": { "heading": "Où aller ensuite?", diff --git a/web/messages/fr/docs/oci-manager/hardware.json b/web/messages/fr/docs/oci-manager/hardware.json index e1bf73c0..f9efbc28 100644 --- a/web/messages/fr/docs/oci-manager/hardware.json +++ b/web/messages/fr/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "Le nœud de rendu, /dev/kfd et la génération indiquée par le pilote de calcul dans /sys/class/kfd/kfd/topology/nodes/*/properties", - "Une génération pour laquelle l’image ROCm de l’application contient des noyaux de calcul — les GPU RDNA2 cités et les plus récents — est proposée telle quelle. Les autres GPU de ces familles, comme les Radeon 680M et 780M, sont proposés à titre expérimental et jamais présélectionnés : ROCm ne les prend pas officiellement en charge, l’application les présente comme la génération de leur famille (HSA_OVERRIDE_GFX_VERSION) et l’installateur demande confirmation avant de télécharger l’image plus volumineuse. Une GPU plus ancienne, telle que la partie graphique intégrée d’un Ryzen 5000U, n’est pas proposée et Immich conserve la reconnaissance sur le CPU." + "Un GPU d’une génération prise en charge par l’image ROCm de l’application (les GPU RDNA2 qu’elle cite et les plus récents) est proposé tel quel. Les autres GPU de ces familles, comme les Radeon 680M et 780M, sont proposés à titre expérimental et ne sont jamais l’option proposée par défaut. ROCm ne les prend pas officiellement en charge : l’application les présente comme la génération de leur famille (HSA_OVERRIDE_GFX_VERSION) et l’installateur demande confirmation avant de télécharger l’image plus volumineuse. Un GPU plus ancien, tel que la partie graphique intégrée d’un Ryzen 5000U, n’est pas proposé et Immich conserve la reconnaissance sur le CPU" ], [ "NVIDIA", diff --git a/web/messages/fr/docs/oci-manager/lifecycle.json b/web/messages/fr/docs/oci-manager/lifecycle.json index 5030ebcc..63da18c6 100644 --- a/web/messages/fr/docs/oci-manager/lifecycle.json +++ b/web/messages/fr/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "La nouvelle image est vérifiée couche par couche avant l'arrêt du CT. Un téléchargement qui arrive endommagé est récupéré une deuxième fois ; une image déjà mise en cache qui échoue la vérification est à nouveau téléchargée.", "Les paramètres modifiés dans Proxmox VE après l'installation (mémoire, swap, cœurs, limite et priorité du CPU, démarrage avec le nœud) sont conservés et intégrés au nouveau contrat.", "L'interface LAN ajoutée par la suite Arr et les applications à plusieurs conteneurs (net1), ainsi que l'ordre de démarrage (startup), sont réappliqués tels quels au nouveau conteneur.", + "Un répertoire de l’hôte est reconnu par son chemin et par le système de fichiers sur lequel il se trouve, et non par le nom de périphérique que l’hôte donne à son disque : un disque USB ou réseau qui revient sous un autre nom reste donc le même répertoire. Lorsque son disque n’est pas connecté, la mise à jour s’arrête avant que le CT ne soit arrêté et indique le répertoire manquant.", "Toute autre différence entre le CT et son contrat arrête la mise à jour avant que le CT ne soit arrêté." ] } diff --git a/web/messages/fr/docs/oci-manager/storage-network.json b/web/messages/fr/docs/oci-manager/storage-network.json index 8f7f3649..4fd6489b 100644 --- a/web/messages/fr/docs/oci-manager/storage-network.json +++ b/web/messages/fr/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Stockage et taille", - "body": "Un disque du conteneur est créé sur un stockage Proxmox VE avec la taille indiquée. L’installation par défaut utilise local-lvm. L’installation avancée demande le stockage de chaque chemin juste avant sa taille et propose celui du rootfs. Le disque apparaît sous le nom vm-VMID-disk-N et est rattaché comme mpN." + "body": "Un disque du conteneur est créé sur un stockage Proxmox VE avec la taille indiquée. L’installation par défaut demande une seule fois le stockage du conteneur et de ses données lorsque le nœud en possède plusieurs ; l’installation avancée demande le stockage de chaque chemin juste avant sa taille et propose celui du rootfs. Le disque apparaît sous le nom vm-VMID-disk-N et est rattaché comme mpN." }, { "title": "Répertoire de l’hôte", @@ -109,6 +109,9 @@ }, { "p": "Le rootfs est réservé aux binaires et au contenu de l’image. Une mise à jour ou une recréation le remplace sans toucher à l’un ou l’autre type de point de montage." + }, + { + "p": "Un répertoire de l’hôte est monté avec tout ce que l’hôte a monté à l’intérieur. Un répertoire tel que /mnt/pve affiche ses partages réseau, disques et datasets dans le conteneur, et ce que l’hôte y monte ou démonte par la suite apparaît ou disparaît sans redémarrer le conteneur. Un répertoire ajouté en lecture seule est en lecture seule avec ce qui y est monté au démarrage du conteneur. Un système de fichiers que l’hôte monte ensuite arrive avec les permissions avec lesquelles l’hôte le monte, et passe lui aussi en lecture seule au redémarrage du conteneur." } ] }, diff --git a/web/messages/fr/docs/post-install/index.json b/web/messages/fr/docs/post-install/index.json index 937e0797..32cb8324 100644 --- a/web/messages/fr/docs/post-install/index.json +++ b/web/messages/fr/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Scripts communautaires", "body": "Le menu propose aussi deux scripts tiers du projet community-scripts : Proxmox VE Post Install et Proxmox VE Microcode. Ces enveloppes téléchargent et exécutent les scripts originaux via wget | bash. ProxMenux ne les maintient pas. Consultez Dépôts externes pour les détails et les questions de confiance avant de les lancer." }, + "pbs": { + "heading": "Sur Proxmox Backup Server", + "body": "Sur un hôte Proxmox Backup Server, le même menu s'ouvre depuis Paramètres post-installation de Proxmox dans le menu PBS. Automatisé, Personnalisable, Appliquer les mises à jour disponibles et Désinstaller les optimisations fonctionnent comme sur Proxmox VE, avec ces différences :", + "items": [ + "Dépôts et mise à niveau : lorsque le serveur n'a pas d'abonnement et que seul le dépôt Enterprise de PBS est actif, ProxMenux demande avant de passer au dépôt sans abonnement de PBS. Le changement passe par l'API des dépôts du serveur lui-même, celle utilisée par Administration > Repositories. Avec un abonnement actif, ou un dépôt sans abonnement ou de test déjà configuré, les sources restent telles quelles.", + "Liste personnalisable : les options qui ne concernent que Proxmox VE ne sont pas proposées : agent invité, VFIO IOMMU, Open vSwitch, vitesse des sauvegardes vzdump, pigz, Appliance Manager, Ceph, haute disponibilité et OVH Real Time Monitoring.", + "Bannière d'abonnement : le correctif s'applique à l'interface web de Proxmox Backup Server, et Désinstaller les optimisations la restaure.", + "Figurine : s'installe sans les alias de Proxmox VE.", + "Scripts communautaires : la section propose Proxmox Backup Server Post Install et Proxmox Backup Server Microcode à la place des scripts de Proxmox VE." + ] + }, "related": { "heading": "Voir aussi", "items": [ diff --git a/web/messages/it/docs/backup-restore/creating-backups.json b/web/messages/it/docs/backup-restore/creating-backups.json index a7fd47c4..c3446fd6 100644 --- a/web/messages/it/docs/backup-restore/creating-backups.json +++ b/web/messages/it/docs/backup-restore/creating-backups.json @@ -118,7 +118,7 @@ { "step": "5", "name": "Notifica (start)", - "detail": "Viene eseguito hb_notify_lifecycle \"start\". Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento Backup dell’host avviato. Non viene inviato nulla se non sono configurati canali." + "detail": "Viene eseguito hb_notify_lifecycle \"start\". Se le notifiche sono configurate nel Monitor, viene inviato all’utente l’evento Backup dell’host avviato. Non viene inviato nulla se non sono configurati canali." } ] }, diff --git a/web/messages/it/docs/backup-restore/destinations/index.json b/web/messages/it/docs/backup-restore/destinations/index.json index 3e80c055..254e5661 100644 --- a/web/messages/it/docs/backup-restore/destinations/index.json +++ b/web/messages/it/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "Il layout dell'archivio non cambia con la destinazione", - "body": "All'interno di una delle tre destinazioni, lo stesso layout rootfs/ + metadata/ + manifest.json descritto in Come funziona è presente. Un .tar.zst estratto da un archivio locale, un .pxar restaurato da PBS, e un archivio Borg estratto con borg extract producono tutti un albero di directory identico. Il percorso del codice di ripristino (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano." + "body": "Ovunque sia archiviato il backup, contiene sempre gli stessi tre blocchi descritti in Come funziona: il filesystem (rootfs/), i metadati (metadata/) e il manifesto (manifest.json). L’estrazione di un archivio locale .tar.zst, il ripristino di un .pxar da PBS o l’estrazione di un archivio Borg producono tutti un albero di directory identico. Il ripristino legge quindi sempre gli stessi file, qualunque sia la destinazione da cui proviene il backup." }, "extractStandalone": { "heading": "Estrazione di un backup al di fuori di ProxMenux", diff --git a/web/messages/it/docs/backup-restore/destinations/pbs.json b/web/messages/it/docs/backup-restore/destinations/pbs.json index 6cc1e51e..d6c90a2a 100644 --- a/web/messages/it/docs/backup-restore/destinations/pbs.json +++ b/web/messages/it/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Selezione dei repository", - "intro": "ProxMenux scopre i repository PBS da due fonti su ogni backup. L'operatore sceglie uno da un menu unificato; la scelta determina HB_PBS_REPOSITORY, HB_PBS_SECRET e HB_PBS_FINGERPRINT per l'esecuzione.", + "intro": "ProxMenux individua i repository PBS da due fonti a ogni backup. L’utente ne sceglie uno da un menu unificato; per quell’esecuzione, la scelta determina il server e il datastore a cui viene inviato il backup, la password con cui si autentica e l’impronta digitale che convalida il certificato.", "sourceRows": [ { "source": "storage.cfg di Proxmox (rilevamento automatico)", @@ -46,7 +46,7 @@ "backupIdTitle": "Nome ID di backup", "backupIdBody": "L’ID di backup predefinito è hostcfg-HOSTNAME. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in [A-Za-z0-9_-] e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un gruppo e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.", "pxarTitle": "Perché la fonte è la radice di staging completa", - "pxarBody": "La sorgente .pxar è l'intero staging_root — rootfs/, metadata/ e manifest.json insieme. Le versioni precedenti hanno superato $staging_root/rootfs come fonte; che ha lasciato metadata/ fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-_rs_check_layout di 3, che avvolge un albero etc/var/root/usr piatto di nuovo in una gerarchia rootfs/." + "pxarBody": "L’archivio .pxar racchiude l’intera directory di lavoro: il filesystem dell’host (rootfs/), i metadati (metadata/) e il manifesto (manifest.json). Durante il ripristino, ProxMenux confronta il manifesto con l’host di destinazione per stabilire se sono equivalenti, se l’hardware è cambiato o se si tratta di una macchina diversa, e adatta il processo di conseguenza. I backup più vecchi, creati da versioni precedenti di ProxMenux che includevano solo il filesystem, si ripristinano ancora correttamente: il ripristino rileva quel formato precedente e lo riorganizza automaticamente." }, "encryption": { "heading": "Crittografia lato cliente", @@ -63,7 +63,7 @@ "recoveryTitle": "Caricare la chiave su PBS: decide l’operatore", "recoveryBody": "Subito dopo la scelta del file di chiave, ProxMenux pone la domanda esplicita Caricare la chiave su PBS?, con due risposte. Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì. L’opzione predefinita è No, conserva solo in locale: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante Scarica il file di chiave del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo Sì, carica, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo pbs-key.recovery.enc. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.", "blobUploadTitle": "Gruppo di backup abbinato su PBS", - "blobUploadBody1": "Quando la modalità escrow è Sì, carica, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in -keyrecovery. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. La busta non lascia mai l'host in plaintext: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS riceve solo la busta già crittografata.", + "blobUploadBody1": "Quando la risposta è Sì, carica, ProxMenux carica la busta di recupero su PBS dopo ogni backup crittografato, come secondo gruppo di backup abbinato con lo stesso nome del gruppo dell’host ma che termina in -keyrecovery. I due gruppi compaiono uno accanto all’altro nell’elenco del datastore: uno per i backup dell’host, uno per le buste di recupero. La busta non lascia mai l’host in chiaro: la crittografia avviene sull’host stesso con AES-256-CBC e PBKDF2 prima che qualsiasi byte venga trasmesso (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS riceve solo la busta già crittografata.", "envelopeSecurityTitle": "Caricare il file keyrecovery a PBS è un rischio di sicurezza?", "envelopeSecurityBody": "Il file keyrecovery è crittografato in transito e a riposo. Il passphrase di recupero non lascia mai l'host: la crittografia avviene localmente prima del caricamento, e PBS vede solo il risultato già crittografato. Un amministratore PBS — o chiunque abbia accesso al datastore — può scaricare il file di keyrecovery, ma senza la passphrase di recupero non può leggere il keyfile all'interno: è un codice opaco. Ricostruire il keyfile richiede entrambi i pezzi contemporaneamente, il file keyrecovery e la passphrase, e solo l'operatore tiene entrambi.", "blobUploadConstraintTitle": "Perché servono due gruppi anziché un unico gruppo crittografato", @@ -73,7 +73,7 @@ "recoverTitle": "Recupero su un host fresco", "recoverBody": "Quando il file di chiave manca nel percorso canonico, dopo una reinstallazione o una rimozione esplicita, il ripristino prova tre fonti in ordine e si ferma alla prima che fornisce una chiave utilizzabile. Prima, se il repository PBS selezionato ha una chiave corrispondente gestita da PVE in /etc/pve/priv/storage/<NAME>.enc, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo -keyrecovery, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce wrong key — manifest's key XX does not match provided key YY. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.", "monitorManagementTitle": "Gestione del keyfile dal Monitor", - "monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: Scarica esporta il file attuale nel browser; Carica sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; Elimina rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per Caricare la chiave su PBS?, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con Avvia caricamento, Interrompi caricamento o Aggiorna passphrase. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce." + "monitorManagementBody": "Il Monitor mostra i controlli del file di chiave in ogni riga di destinazione PBS della pagina di configurazione dei backup. La riga offre tre azioni: Scarica esporta il file di chiave attuale nel browser dell’utente, Carica sostituisce il file di chiave installato con uno fornito dall’utente (il file precedente viene sovrascritto solo dopo che il nuovo è arrivato correttamente nel suo percorso) ed Elimina rimuove il file di chiave dall’host. Subito accanto si trova l’interruttore della busta di recupero: una scelta Sì/No per Caricare la chiave su PBS?, un campo passphrase che compare quando si seleziona Sì e un pulsante che segue lo stato attuale: Avvia caricamento, Interrompi caricamento o Aggiorna passphrase. I controlli del Monitor e la finestra di dialogo della shell eseguono internamente le stesse operazioni, quindi il risultato su disco e su PBS è identico qualunque dei due si utilizzi." }, "restoreAccess": { "heading": "Recuperare sul lato del ripristino", diff --git a/web/messages/it/docs/backup-restore/how-it-works.json b/web/messages/it/docs/backup-restore/how-it-works.json index 78a4d54c..cc0aa5a8 100644 --- a/web/messages/it/docs/backup-restore/how-it-works.json +++ b/web/messages/it/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Validazione schema", - "schemaBody": "Il manifesto convalida contro scripts/backup_restore/schema/manifest.schema.json. L'esecuzione di build_manifest.sh --validate attiva una validazione dello schema JSON (richiede python3 + jsonschema). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime." + "schemaBody": "ProxMenux include un modello che descrive quali campi deve contenere il manifesto e la forma di ciascuno. Quando viene generato un backup, il manifesto può essere verificato automaticamente rispetto a quel modello, così un collettore che ha prodotto un JSON malformato o un campo scritto in modo errato viene individuato subito. La verifica è pensata per lo sviluppo di ProxMenux stesso: su un sistema in cui non è installata, il backup funziona come di consueto e il manifesto viene generato comunque." }, "applications": { "heading": "inventario delle applicazioni", diff --git a/web/messages/it/docs/oci-manager/hardware.json b/web/messages/it/docs/oci-manager/hardware.json index 8a60aa10..bc16b51d 100644 --- a/web/messages/it/docs/oci-manager/hardware.json +++ b/web/messages/it/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "Il nodo di rendering, /dev/kfd e la generazione indicata dal driver di calcolo in /sys/class/kfd/kfd/topology/nodes/*/properties", - "Una generazione per cui l’immagine ROCm dell’applicazione include kernel di calcolo — le GPU RDNA2 indicate e quelle più recenti — viene proposta così com’è. Le altre GPU di queste famiglie, come Radeon 680M e 780M, sono proposte come sperimentali e non sono mai preselezionate: ROCm non le supporta ufficialmente, l’applicazione le presenta come la generazione della rispettiva famiglia (HSA_OVERRIDE_GFX_VERSION) e l’installatore chiede conferma prima di scaricare l’immagine più grande. Una GPU precedente, come la grafica integrata di un Ryzen 5000U, non viene proposta e Immich mantiene il riconoscimento sulla CPU." + "Una GPU di una generazione supportata dall’immagine ROCm dell’applicazione (le GPU RDNA2 che indica e quelle più recenti) viene proposta così com’è. Le altre GPU di queste famiglie, come Radeon 680M e 780M, sono proposte come sperimentali e non sono mai l’opzione suggerita. ROCm non le supporta ufficialmente: l’applicazione le presenta come la generazione della rispettiva famiglia (HSA_OVERRIDE_GFX_VERSION) e l’installatore chiede conferma prima di scaricare l’immagine più grande. Una GPU precedente, come la grafica integrata di un Ryzen 5000U, non viene proposta e Immich mantiene il riconoscimento sulla CPU" ], [ "NVIDIA", diff --git a/web/messages/it/docs/oci-manager/lifecycle.json b/web/messages/it/docs/oci-manager/lifecycle.json index a0271b28..81cd3a41 100644 --- a/web/messages/it/docs/oci-manager/lifecycle.json +++ b/web/messages/it/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "La nuova immagine viene verificata livello per livello prima di arrestare il CT. Un download danneggiato viene ripetuto una seconda volta; un’immagine già nella cache che non supera la verifica viene scaricata di nuovo.", "Le impostazioni modificate in Proxmox VE dopo l’installazione (memoria, swap, core, limite e priorità della CPU, avvio con il nodo) vengono conservate e incluse nel nuovo contratto.", "L'interfaccia LAN che la suite Arr e le applicazioni multi-container aggiungono (net1) e l'ordine di avvio (startup) sono restituiti al nuovo contenitore come sono.", + "Una directory dell’host viene riconosciuta dal suo percorso e dal filesystem su cui si trova, non dal nome di dispositivo che l’host assegna al suo disco, quindi un disco USB o di rete che ricompare con un altro nome resta la stessa directory. Quando il suo disco non è collegato, l’aggiornamento si interrompe prima che il CT venga arrestato e indica la directory mancante.", "Qualsiasi altra differenza tra il CT e il suo contratto interrompe l’aggiornamento prima che il CT venga arrestato." ] } diff --git a/web/messages/it/docs/oci-manager/storage-network.json b/web/messages/it/docs/oci-manager/storage-network.json index 60b32b16..e069c1ef 100644 --- a/web/messages/it/docs/oci-manager/storage-network.json +++ b/web/messages/it/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Storage e dimensione", - "body": "Viene creato un disco del container su uno storage Proxmox VE con la dimensione indicata. L’installazione predefinita usa local-lvm; quella avanzata chiede lo storage di ogni percorso subito prima della dimensione e propone quello del rootfs. Il disco appare come vm-VMID-disk-N e viene collegato come mpN." + "body": "Viene creato un disco del container su uno storage Proxmox VE con la dimensione indicata. L’installazione predefinita chiede una sola volta lo storage del container e dei suoi dati quando il nodo ne ha più di uno; quella avanzata chiede lo storage di ogni percorso subito prima della dimensione e propone quello del rootfs. Il disco appare come vm-VMID-disk-N e viene collegato come mpN." }, { "title": "Directory dell’host", @@ -109,6 +109,9 @@ }, { "p": "Il rootfs è riservato ai binari e al contenuto dell’immagine. Un aggiornamento o una ricreazione lo sostituisce senza toccare nessuno dei due tipi di punto di mount." + }, + { + "p": "Una directory dell’host viene montata con tutto ciò che l’host vi ha montato all’interno. Una directory come /mnt/pve mostra nel container le sue condivisioni di rete, i dischi e i dataset, e ciò che l’host vi monta o smonta in seguito compare o scompare senza riavviare il container. Una directory aggiunta in sola lettura è in sola lettura insieme a ciò che vi è montato all’avvio del container. Un filesystem che l’host monta successivamente arriva con i permessi con cui l’host lo monta e diventa anch’esso di sola lettura al riavvio del container." } ] }, diff --git a/web/messages/it/docs/post-install/index.json b/web/messages/it/docs/post-install/index.json index cdb0054b..3ea7f689 100644 --- a/web/messages/it/docs/post-install/index.json +++ b/web/messages/it/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Script della community", "body": "Il menu offre anche due script di terze parti del progetto community-scripts: Proxmox VE Post Install e Proxmox VE Microcode. Sono wrapper che scaricano ed eseguono gli script originali tramite wget | bash. ProxMenux non li mantiene. Vedi Repository esterni per dettagli e valutazioni sull’affidabilità prima di eseguirli." }, + "pbs": { + "heading": "Su Proxmox Backup Server", + "body": "Su un host Proxmox Backup Server, lo stesso menu si apre da Impostazioni post-installazione Proxmox nel menu PBS. Automatizzato, Personalizzabile, Applica aggiornamenti disponibili e Disinstalla ottimizzazioni funzionano come su Proxmox VE, con queste differenze:", + "items": [ + "Repository e aggiornamento: quando il server non ha un abbonamento ed è attivo solo il repository Enterprise di PBS, ProxMenux chiede conferma prima di passare al repository no-subscription di PBS. Il cambio passa per l'API dei repository del server stesso, la stessa usata da Administration > Repositories. Con un abbonamento attivo, o con un repository no-subscription o di test già configurato, le sorgenti restano invariate.", + "Elenco personalizzabile: le opzioni valide solo per Proxmox VE non vengono mostrate: guest agent, VFIO IOMMU, Open vSwitch, velocità dei backup vzdump, pigz, Appliance Manager, Ceph, alta disponibilità e OVH Real Time Monitoring.", + "Banner dell'abbonamento: la patch si applica all'interfaccia web di Proxmox Backup Server e Disinstalla ottimizzazioni la ripristina.", + "Figurine: si installa senza gli alias di Proxmox VE.", + "Script della community: la sezione offre Proxmox Backup Server Post Install e Proxmox Backup Server Microcode al posto degli script di Proxmox VE." + ] + }, "related": { "heading": "Correlati", "items": [ diff --git a/web/messages/pt/docs/backup-restore/creating-backups.json b/web/messages/pt/docs/backup-restore/creating-backups.json index 99ed48c1..6386b9ab 100644 --- a/web/messages/pt/docs/backup-restore/creating-backups.json +++ b/web/messages/pt/docs/backup-restore/creating-backups.json @@ -118,7 +118,7 @@ { "step": "5", "name": "Notificação (início)", - "detail": "hb_notify_lifecycle \"start\" é acionado. Se as notificações estiverem configuradas no Monitor, um evento Backup do host iniciado é enviado ao usuário. Nada é enviado se não houver canais configurados." + "detail": "hb_notify_lifecycle \"start\" é acionado. Se as notificações estiverem configuradas no Monitor, é enviado ao utilizador um evento Backup do host iniciado. Nada é enviado se não houver canais configurados." } ] }, diff --git a/web/messages/pt/docs/backup-restore/destinations/index.json b/web/messages/pt/docs/backup-restore/destinations/index.json index 0f92be36..70c484dd 100644 --- a/web/messages/pt/docs/backup-restore/destinations/index.json +++ b/web/messages/pt/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "A disposição do arquivo não muda com o destino", - "body": "Dentro de qualquer um dos três destinos, o mesmo rootfs/ + metadata/ + manifest.json layout descrito em Como funciona está presente. Um .tar.zst extraído de um arquivo local, um .pxar restaurado de PBS, e um arquivo Borg extraído com borg extract todos produzem uma árvore de diretórios idêntica. O caminho do código de restauração (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lê as mesmas três cargas úteis sem saber de que destino vieram." + "body": "Onde quer que o backup esteja guardado, contém sempre os mesmos três blocos descritos em Como funciona: o sistema de ficheiros (rootfs/), os metadados (metadata/) e o manifesto (manifest.json). Extrair um arquivo local .tar.zst, restaurar um .pxar a partir do PBS ou extrair um arquivo Borg produzem sempre uma árvore de diretórios idêntica. Por isso, o restauro lê sempre os mesmos ficheiros, seja qual for o destino de onde vem o backup." }, "extractStandalone": { "heading": "Extraindo um backup fora de ProxMenux", diff --git a/web/messages/pt/docs/backup-restore/destinations/pbs.json b/web/messages/pt/docs/backup-restore/destinations/pbs.json index 1164a2ae..2a36cac8 100644 --- a/web/messages/pt/docs/backup-restore/destinations/pbs.json +++ b/web/messages/pt/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Selecção do repositório", - "intro": "ProxMenux descobre repositórios PBS de duas fontes em cada backup. O operador escolhe um de um menu unificado; a escolha determina HB_PBS_REPOSITORY, HB_PBS_SECRET e HB_PBS_FINGERPRINT para a execução.", + "intro": "O ProxMenux descobre repositórios PBS a partir de duas fontes em cada backup. O utilizador escolhe um num menu unificado; para essa execução, a escolha determina o servidor e o datastore para onde o backup é enviado, a palavra-passe com que se autentica e a impressão digital que valida o certificado.", "sourceRows": [ { "source": "storage.cfg do Proxmox (deteção automática)", @@ -46,7 +46,7 @@ "backupIdTitle": "Nome do ID de backup", "backupIdBody": "O ID de backup padrão é hostcfg-HOSTNAME. Pede-se ao operador que o confirme ou edite antes do envio; quaisquer caracteres fora do [A-Za-z0-9_-] são despojados e os traços são aparados. Reutilizar o mesmo ID entre as execuções é intencional — o PBS trata o ID como um group, e cada backup subsequente aparece como um novo backup dentro desse grupo, compartilhando dedup com execuções anteriores.", "pxarTitle": "Por que a fonte é a raiz de estadiamento completa", - "pxarBody": "A origem do arquivo .pxar é todo o staging_root: rootfs/, metadata/ e manifest.json em conjunto. Versões anteriores usavam $staging_root/rootfs como origem, deixando metadata/ fora do arquivo. Sem esses dados, a verificação de compatibilidade emitia avisos de mudança de host mesmo ao restaurar no mesmo host. As cópias antigas continuam a ser restauradas pelo caso 3 de _rs_check_layout, que volta a colocar a árvore simples etc/var/root/usr dentro de uma hierarquia rootfs/." + "pxarBody": "O arquivo .pxar empacota todo o diretório de trabalho: o sistema de ficheiros do host (rootfs/), os metadados (metadata/) e o manifesto (manifest.json). No restauro, o ProxMenux compara o manifesto com o host de destino para determinar se são equivalentes, se o hardware mudou ou se se trata de uma máquina diferente, e ajusta o processo em conformidade. Os backups mais antigos, criados por versões anteriores do ProxMenux que empacotavam apenas o sistema de ficheiros, continuam a ser restaurados corretamente: o restauro deteta esse formato antigo e reorganiza-o automaticamente." }, "encryption": { "heading": "Criptografia do lado do cliente", @@ -63,7 +63,7 @@ "recoveryTitle": "Chave de envio para PBS — o operador decide", "recoveryBody": "Logo após escolher o arquivo de chave, o ProxMenux pergunta explicitamente Enviar a chave para o PBS?, com duas respostas. Nenhum artefato de recuperação é enviado ao PBS até o operador responder Sim. O padrão é Não, manter apenas localmente: a chave fica no caminho canônico local, o ProxMenux não envia artefatos de recuperação ao PBS e o operador cuida da cópia externa. O botão Baixar arquivo de chave do Monitor, na linha do destino PBS, fornece essa cópia quando necessário. Ao escolher Sim, enviar, é solicitada duas vezes uma frase secreta de recuperação, verificando se as duas entradas coincidem. O ProxMenux protege o arquivo com AES-256-CBC e PBKDF2 (600.000 iterações, salt aleatório), produzindo pbs-key.recovery.enc. Cada backup criptografado posterior envia esse envelope ao PBS como um grupo de backup associado. Esses envios não transmitem ao PBS a frase secreta nem o arquivo de chave em texto claro. A escolha pode ser alterada a qualquer momento no Monitor: o controle na linha PBS permite Sim ou Não e aplica imediatamente Iniciar envio, Parar envio ou Atualizar frase secreta, conforme o estado atual.", "blobUploadTitle": "Grupo de backup emparelhado no PBS", - "blobUploadBody1": "Quando o modo de garantia é Sim, fazer upload, ProxMenux carrega o envelope de recuperação para PBS após cada backup criptografado como um segundo grupo de backup emparelhado com o mesmo nome do grupo host, mas terminando em -keyrecovery. Os dois grupos ficam próximos um do outro na listagem do armazenamento de dados – um para backups de host e outro para envelopes de recuperação. O envelope nunca sai do host em texto simples: a criptografia acontece no próprio host com AES-256-CBC e PBKDF2 antes que qualquer byte seja transmitido (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS recebe apenas o envelope já criptografado.", + "blobUploadBody1": "Quando a resposta é Sim, fazer upload, o ProxMenux carrega o envelope de recuperação para o PBS após cada backup encriptado, como um segundo grupo de backup emparelhado, com o mesmo nome do grupo do host mas terminado em -keyrecovery. Os dois grupos ficam lado a lado na listagem do datastore: um para os backups do host e outro para os envelopes de recuperação. O envelope nunca sai do host em texto simples: a encriptação é feita no próprio host com AES-256-CBC e PBKDF2 antes de qualquer byte ser transmitido (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). O PBS recebe apenas o envelope já encriptado.", "envelopeSecurityTitle": "Carregar o arquivo de recuperação de chaves para PBS é um risco de segurança?", "envelopeSecurityBody": "O arquivo de recuperação de chaves está criptografado em trânsito e em repouso. A senha de recuperação nunca deixa o host: criptografia acontece localmente antes do upload, e PBS só vê o resultado já criptografado. Um administrador PBS — ou qualquer pessoa com acesso ao datastore — pode baixar o arquivo keyrecovery, mas sem a frase-passe de recuperação eles não podem ler o arquivo de chave dentro: é cifrar opaco. Reconstruir o arquivo de chaves requer ambas as peças ao mesmo tempo, o arquivo de recuperação de chaves e a frase-passe, e apenas o operador detém ambas.", "blobUploadConstraintTitle": "Por que dois grupos em vez de um único criptografado", @@ -73,7 +73,7 @@ "recoverTitle": "Recuperação num novo hospedeiro", "recoverBody": "Quando o arquivo de chave falta no caminho canônico, após reinstalar o host ou removê-lo explicitamente, a restauração tenta três fontes em ordem e para na primeira que fornece uma chave utilizável. Primeiro, se houver uma chave gerenciada pelo PVE correspondente ao repositório PBS selecionado em /etc/pve/priv/storage/<NAME>.enc, ela será copiada sem perguntas para o caminho canônico. Segundo, se houver um grupo -keyrecovery no PBS, será baixado o instantâneo mais recente e solicitada a frase secreta de recuperação para descriptografá-lo. Terceiro, se as opções anteriores falharem ou forem recusadas, o diálogo pedirá o caminho absoluto do arquivo de chave neste host e o copiará para o caminho canônico. O Monitor oferece o mesmo fluxo de importação na janela de detalhes do backup. Um painel âmbar aparece no topo quando Restaurar, Baixar ou Ver conteúdo exige uma chave ausente. Se a chave instalada não corresponde à usada no backup, o PBS retorna wrong key — manifest's key XX does not match provided key YY. As mesmas três ações exibem então um painel estruturado com a impressão digital exigida pelo manifesto em destaque, permitindo identificar qual chave importar para abrir o backup.", "monitorManagementTitle": "Gerenciando o arquivo de chaves do Monitor", - "monitorManagementBody": "O Monitor mostra os controles do arquivo de chave diretamente em cada linha de destino PBS na configuração dos backups. Há três ações: Baixar exporta o arquivo atual para o navegador; Enviar substitui o arquivo instalado pelo fornecido pelo operador, sobrescrevendo o anterior somente após a instalação bem-sucedida do novo no caminho canônico; Excluir remove o arquivo do host. Ao lado fica o controle da cópia de recuperação: uma opção Sim/Não para Enviar a chave para o PBS?, um campo de frase secreta quando Sim é escolhido e um botão contextual para aplicar Iniciar envio, Parar envio ou Atualizar frase secreta. Todas as ações usam os mesmos endpoints Flask da interface de terminal; portanto, o efeito em disco e o estado no PBS são idênticos nas duas interfaces." + "monitorManagementBody": "O Monitor mostra os controlos do ficheiro de chave em cada linha de destino PBS da página de configuração dos backups. A linha tem três ações: Baixar exporta o ficheiro de chave atual para o navegador do utilizador, Enviar substitui o ficheiro de chave instalado por um fornecido pelo utilizador (o ficheiro anterior só é sobrescrito depois de o novo ter chegado corretamente ao seu caminho) e Excluir remove o ficheiro de chave do host. Mesmo ao lado fica o interruptor do envelope de recuperação: uma opção Sim/Não para Enviar a chave para o PBS?, um campo de frase secreta que aparece quando Sim é selecionado e um botão que acompanha o estado atual: Iniciar envio, Parar envio ou Atualizar frase secreta. Os controlos do Monitor e o diálogo da shell fazem o mesmo internamente, pelo que o resultado no disco e no PBS é idêntico, seja qual for o utilizado." }, "restoreAccess": { "heading": "Obtenção no lado da restauração", diff --git a/web/messages/pt/docs/backup-restore/how-it-works.json b/web/messages/pt/docs/backup-restore/how-it-works.json index 8f8f7845..681902e0 100644 --- a/web/messages/pt/docs/backup-restore/how-it-works.json +++ b/web/messages/pt/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Validação do esquema", - "schemaBody": "O manifesto valida contra scripts/backup_restore/schema/manifest.schema.json. Executar o build_manifest.sh --validate desencadeia uma validação do esquema JSON do lado Python (exige o python3 + jsonschema). Se o módulo não estiver presente, a verificação é ignorada silenciosamente — a validação é principalmente um auxílio ao desenvolvedor, não uma dependência de execução." + "schemaBody": "O ProxMenux inclui um modelo que descreve os campos que o manifesto deve conter e o formato de cada um. Quando é gerado um backup, o manifesto pode ser verificado automaticamente face a esse modelo, pelo que um coletor que tenha produzido JSON malformado ou um campo mal escrito é detetado de imediato. A verificação destina-se ao desenvolvimento do próprio ProxMenux: num sistema que não a tenha instalada, o backup funciona normalmente e o manifesto é gerado na mesma." }, "applications": { "heading": "O inventário de aplicativos", diff --git a/web/messages/pt/docs/backup-restore/scheduled-jobs.json b/web/messages/pt/docs/backup-restore/scheduled-jobs.json index 44f8fe5a..44c417e0 100644 --- a/web/messages/pt/docs/backup-restore/scheduled-jobs.json +++ b/web/messages/pt/docs/backup-restore/scheduled-jobs.json @@ -127,7 +127,7 @@ }, "notifications": { "heading": "Notificações", - "body": "Cada execução programada dispara os mesmos eventos hb_notify_lifecycle que o fluxo interativo (start, complete, fail). Se os canais de notificação estiverem configurados no Monitor, os trabalhos não vigiados mostram seus resultados da mesma forma que backups manuais – um usuário não precisa verificar o log para saber se um trabalho foi bem sucedido." + "body": "Cada execução agendada dispara os mesmos eventos hb_notify_lifecycle que o fluxo interativo (start, complete, fail). Se houver canais de notificação configurados no Monitor, as tarefas não vigiadas comunicam os seus resultados da mesma forma que os backups manuais: um utilizador não precisa de consultar o registo para saber se uma tarefa foi bem-sucedida." }, "whereNext": { "heading": "Para onde ir a seguir", diff --git a/web/messages/pt/docs/oci-manager/hardware.json b/web/messages/pt/docs/oci-manager/hardware.json index 7f98c0e9..284859b0 100644 --- a/web/messages/pt/docs/oci-manager/hardware.json +++ b/web/messages/pt/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "O nó de renderização, /dev/kfd e a geração que o controlador de computação relata em /sys/class/kfd/kfd/topology/nodes/*/properties", - "Uma geração para a qual a imagem ROCm do aplicativo inclui kernels de computação — as GPUs RDNA2 citadas e as mais recentes — é oferecida sem adaptação. As outras GPUs dessas famílias, como Radeon 680M e 780M, são oferecidas como experimentais e nunca são a opção sugerida: o ROCm não as suporta oficialmente, o aplicativo as apresenta como a geração de sua família (HSA_OVERRIDE_GFX_VERSION) e o instalador pede confirmação antes de baixar a imagem maior. Uma GPU mais antiga, como a integrada de um Ryzen 5000U, não é oferecida e o Immich mantém o reconhecimento na CPU." + "Uma GPU de uma geração suportada pela imagem ROCm da aplicação (as GPUs RDNA2 que indica e as mais recentes) é oferecida sem alterações. As outras GPUs dessas famílias, como as Radeon 680M e 780M, são oferecidas como experimentais e nunca são a opção proposta. O ROCm não as suporta oficialmente: a aplicação apresenta-as como a geração da sua família (HSA_OVERRIDE_GFX_VERSION) e o instalador pede confirmação antes de transferir a imagem maior. Uma GPU mais antiga, como a gráfica integrada de um Ryzen 5000U, não é oferecida e o Immich mantém o reconhecimento na CPU" ], [ "NVIDIA", diff --git a/web/messages/pt/docs/oci-manager/lifecycle.json b/web/messages/pt/docs/oci-manager/lifecycle.json index ece467a3..79ff9cdb 100644 --- a/web/messages/pt/docs/oci-manager/lifecycle.json +++ b/web/messages/pt/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "A nova imagem é verificada camada a camada antes de parar o CT. Uma transferência que chega danificada é repetida uma segunda vez; uma imagem já em cache que não passa na verificação é transferida novamente.", "As definições alteradas no Proxmox VE após a instalação (memória, swap, núcleos, limite e prioridade da CPU, arranque com o nó) são mantidas e incluídas no novo contrato.", "A interface LAN adicionada pela suite Arr e pelas aplicações com vários contentores (net1) e a ordem de arranque (startup) são repostas sem alterações no novo contentor.", + "Um diretório do host é reconhecido pelo seu caminho e pelo sistema de ficheiros em que se encontra, e não pelo nome de dispositivo que o host atribui ao seu disco, pelo que um disco USB ou de rede que volte com outro nome continua a ser o mesmo diretório. Quando o seu disco não está ligado, a atualização é interrompida antes de parar o CT e indica o diretório em falta.", "Qualquer outra diferença entre o CT e o seu contrato interrompe a atualização antes de parar o CT." ] } diff --git a/web/messages/pt/docs/oci-manager/storage-network.json b/web/messages/pt/docs/oci-manager/storage-network.json index 3fb8a7ee..e8325c6e 100644 --- a/web/messages/pt/docs/oci-manager/storage-network.json +++ b/web/messages/pt/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Armazenamento e tamanho", - "body": "É criado um disco do contentor num armazenamento do Proxmox VE com o tamanho indicado. A instalação predefinida utiliza local-lvm; a avançada pergunta o armazenamento de cada caminho imediatamente antes do tamanho e propõe o do rootfs. O disco aparece como vm-VMID-disk-N e é associado como mpN." + "body": "É criado um disco do contentor num armazenamento do Proxmox VE com o tamanho indicado. A instalação predefinida pergunta uma única vez o armazenamento do contentor e dos seus dados quando o nó tem mais do que um; a avançada pergunta o armazenamento de cada caminho imediatamente antes do tamanho e propõe o do rootfs. O disco aparece como vm-VMID-disk-N e é associado como mpN." }, { "title": "Diretório do host", @@ -109,6 +109,9 @@ }, { "p": "O rootfs fica reservado para os binários e o conteúdo da imagem. Uma atualização ou recriação substitui-o sem tocar em nenhum dos dois tipos de ponto de montagem." + }, + { + "p": "Um diretório do host é montado com tudo o que o host montou dentro dele. Um diretório como /mnt/pve mostra no contentor as suas partilhas de rede, discos e datasets, e o que o host lá montar ou desmontar mais tarde aparece ou desaparece sem reiniciar o contentor. Um diretório adicionado só de leitura fica só de leitura juntamente com o que estiver montado dentro dele quando o contentor arranca. Um sistema de ficheiros que o host monte depois chega com as permissões com que o host o monta e passa também a só de leitura quando o contentor é reiniciado." } ] }, diff --git a/web/messages/pt/docs/post-install/index.json b/web/messages/pt/docs/post-install/index.json index 40f74230..3f0cf9fc 100644 --- a/web/messages/pt/docs/post-install/index.json +++ b/web/messages/pt/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Scripts da comunidade", "body": "O menu também oferece dois scripts de terceiros do projeto community-scripts: Proxmox VE Post Install e Proxmox VE Microcode. São invólucros que transferem e executam os scripts originais através de wget | bash. Não são mantidos pelo ProxMenux. Consulte Repositórios externos para detalhes e questões de confiança antes de os executar." }, + "pbs": { + "heading": "No Proxmox Backup Server", + "body": "Num host Proxmox Backup Server, o mesmo menu abre-se a partir de Configurações pós-instalação do Proxmox no menu do PBS. Automatizado, Personalizável, Aplicar atualizações disponíveis e Desinstalar otimizações funcionam como no Proxmox VE, com estas diferenças:", + "items": [ + "Repositórios e atualização: quando o servidor não tem subscrição e apenas o repositório Enterprise do PBS está ativo, o ProxMenux pergunta antes de mudar para o repositório sem subscrição do PBS. A mudança é feita através da API de repositórios do próprio servidor, a mesma usada em Administration > Repositories. Com uma subscrição ativa, ou com um repositório sem subscrição ou de teste já configurado, as fontes mantêm-se como estão.", + "Lista personalizável: as opções que só se aplicam ao Proxmox VE não são mostradas: agente convidado, VFIO IOMMU, Open vSwitch, velocidade dos backups vzdump, pigz, Appliance Manager, Ceph, alta disponibilidade e OVH Real Time Monitoring.", + "Banner de subscrição: o patch aplica-se à interface web do Proxmox Backup Server, e Desinstalar otimizações repõe-na.", + "Figurine: é instalado sem os aliases do Proxmox VE.", + "Scripts da comunidade: a secção oferece Proxmox Backup Server Post Install e Proxmox Backup Server Microcode em vez dos scripts do Proxmox VE." + ] + }, "related": { "heading": "Relacionado", "items": [ diff --git a/web/messages/sk/docs/backup-restore/destinations/index.json b/web/messages/sk/docs/backup-restore/destinations/index.json index 6a89082e..abb84ab4 100644 --- a/web/messages/sk/docs/backup-restore/destinations/index.json +++ b/web/messages/sk/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "Rozloženie archívu sa nemení s destináciou", - "body": "V každom z troch cieľov sa nachádza rovnaká štruktúra rootfs/ + metadata/ + manifest.json opísaná v časti Ako to funguje. Rozbalenie lokálneho archívu .tar.zst, obnova .pxar z PBS aj rozbalenie archívu Borg cez borg extract vytvoria rovnaký adresárový strom. Vetva kódu obnovy (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) číta rovnaké tri bloky údajov bez potreby vedieť, z ktorého cieľa pochádzajú." + "body": "Bez ohľadu na to, kde je záloha uložená, vždy obsahuje rovnaké tri bloky opísané v časti Ako to funguje: súborový systém (rootfs/), metadáta (metadata/) a manifest (manifest.json). Rozbalenie lokálneho archívu .tar.zst, obnova .pxar z PBS aj rozbalenie archívu Borg vytvoria rovnaký adresárový strom. Obnova preto vždy číta rovnaké súbory bez ohľadu na to, z ktorého cieľa záloha pochádza." }, "extractStandalone": { "heading": "Rozbalenie zálohy mimo ProxMenux", diff --git a/web/messages/sk/docs/backup-restore/destinations/pbs.json b/web/messages/sk/docs/backup-restore/destinations/pbs.json index 8df7ad4d..01ab2c8f 100644 --- a/web/messages/sk/docs/backup-restore/destinations/pbs.json +++ b/web/messages/sk/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Výber úložiska", - "intro": "ProxMenux objavuje archív PBS z dvoch zdrojov na každej zálohe. Operátor vyberie jeden z jednotného menu; voľba určuje HB_PBS_REPOSITORY, HB_PBS_SECRET a HB_PBS_FINGERPRINT pre spustenie.", + "intro": "ProxMenux pri každej zálohe vyhľadá repozitáre PBS z dvoch zdrojov. Používateľ jeden z nich vyberie z jednotného menu; pre dané spustenie voľba určuje, na ktorý server a do ktorého dátového skladu sa záloha odošle, akým heslom sa overí a ktorý odtlačok overí certifikát.", "sourceRows": [ { "source": "Proxmox storage.cfg (automaticky zistené)", @@ -46,7 +46,7 @@ "backupIdTitle": "Identifikačné meno zálohy", "backupIdBody": "Predvolený identifikátor zálohy je hostcfg-HOSTNAME. Pred odoslaním ho operátor potvrdí alebo upraví. Znaky mimo [A-Za-z0-9_-] aj pomlčky na konci sa odstránia. Opakované použitie rovnakého ID je zámerné: PBS ho chápe ako skupinu a každá ďalšia záloha pribudne do tejto skupiny ako nová položka so spoločnou deduplikáciou s predchádzajúcimi zálohami.", "pxarTitle": "Prečo je zdrojom celý prípravný adresár", - "pxarBody": "Zdrojom archívu .pxar je celý staging_root: spolu rootfs/, metadata/ aj manifest.json. Staršie verzie používali ako zdroj $staging_root/rootfs, takže v archíve chýbal adresár metadata/. Kontrola kompatibility pri obnove nemala čo čítať a zobrazovala upozornenia na iného hostiteľa aj pri obnove na pôvodnom hostiteľovi. Staré zálohy obsahujúce iba rootfs sa stále obnovujú správne pomocou tretej vetvy _rs_check_layout, ktorá plochý strom etc/var/root/usr zabalí do hierarchie rootfs/." + "pxarBody": "Archív .pxar obsahuje celý pracovný adresár: súborový systém hostiteľa (rootfs/), metadáta (metadata/) a manifest (manifest.json). Pri obnove ProxMenux porovná manifest s cieľovým hostiteľom, aby zistil, či sú rovnocenné, či sa zmenil hardvér alebo či ide o iný počítač, a podľa toho upraví postup. Staršie zálohy vytvorené staršími verziami ProxMenux, ktoré balili iba súborový systém, sa stále obnovujú správne: obnova tento starší formát rozpozná a automaticky ho preusporiada." }, "encryption": { "heading": "Šifrovanie na strane klienta", @@ -63,7 +63,7 @@ "recoveryTitle": "Odoslanie kľúča na PBS — rozhoduje operátor", "recoveryBody": "Hneď po výbere súboru kľúča položí ProxMenux výslovnú otázku Odoslať kľúč na PBS? s dvoma odpoveďami. Kým operátor nezvolí Áno, na PBS sa neodošle žiadny obnovovací artefakt. Predvolená voľba je Nie, ponechať iba lokálne: kľúč zostane na kanonickej miestnej ceste, ProxMenux neodosiela na PBS žiadne obnovovacie artefakty a externú kópiu zabezpečí operátor. Tlačidlo Stiahnuť súbor kľúča v riadku cieľa PBS v Monitore ju poskytne na požiadanie. Voľba Áno, odoslať vyžiada dvakrát prístupovú frázu na obnovu a overí zhodu. ProxMenux ňou zašifruje súbor kľúča pomocou AES-256-CBC a PBKDF2 (600 000 iterácií, náhodná soľ) a vytvorí pbs-key.recovery.enc. Každá ďalšia šifrovaná záloha odošle túto obálku na PBS ako priradenú skupinu záloh. Pri týchto odoslaniach sa na PBS neposiela prístupová fráza ani súbor kľúča v otvorenom tvare. Voľbu možno kedykoľvek zmeniť v Monitore: ovládací prvok v riadku PBS prepína Áno/Nie a okamžite použije Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu podľa aktuálneho stavu.", "blobUploadTitle": "Párovaná záložná skupina na PBS", - "blobUploadBody1": "Keď je režim úschovy Áno, nahrať, ProxMenux odošle obálku na obnovenie do PBS po každej zašifrovanej zálohe ako druhá, spárovaná skupina záloh s rovnakým názvom ako hostiteľská skupina, ale končiaca na -keyrecovery. Tieto dve skupiny sedia vedľa seba v zozname dátového skladu – jedna pre zálohy hostiteľa, druhá pre obálky na obnovenie. Obálka nikdy neopustí hostiteľa v obyčajnom texte: šifrovanie prebieha na samotnom hostiteľovi pomocou AES-256-CBC a PBKDF2 predtým, ako prejdú akékoľvek bajty na drôt (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS prijíma iba už zašifrovanú obálku.", + "blobUploadBody1": "Keď je odpoveď Áno, nahrať, ProxMenux po každej zašifrovanej zálohe odošle obálku na obnovenie do PBS ako druhú, spárovanú skupinu záloh s rovnakým názvom ako skupina hostiteľa, ktorá však končí na -keyrecovery. Obe skupiny sú v zozname dátového skladu vedľa seba: jedna pre zálohy hostiteľa, druhá pre obálky na obnovenie. Obálka nikdy neopustí hostiteľa v otvorenom texte: šifrovanie prebieha priamo na hostiteľovi pomocou AES-256-CBC a PBKDF2 ešte pred odoslaním akýchkoľvek bajtov po sieti (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS prijme iba už zašifrovanú obálku.", "envelopeSecurityTitle": "Predstavuje odoslanie obnovovacieho súboru na PBS bezpečnostné riziko?", "envelopeSecurityBody": "Obnovovací súbor je šifrovaný pri prenose aj pri uložení. Prístupová fráza na obnovu neopúšťa hostiteľa: šifrovanie prebehne lokálne pred odoslaním a PBS dostane iba zašifrovaný výsledok. Správca PBS alebo ktokoľvek s prístupom k dátovému úložisku môže obnovovací súbor stiahnuť, ale bez prístupovej frázy nedokáže prečítať súbor kľúča vnútri; ide o nečitateľný šifrovaný text. Na získanie súboru kľúča treba obe časti súčasne: obnovovací súbor aj prístupovú frázu. Obe má iba operátor.", "blobUploadConstraintTitle": "Prečo dve skupiny namiesto jedného zašifrovaného", @@ -73,7 +73,7 @@ "recoverTitle": "Obnovenie nového hostiteľa", "recoverBody": "Ak miestny súbor kľúča chýba na kanonickej ceste, napríklad po preinštalovaní hostiteľa alebo úmyselnom odstránení, obnova vyskúša tri zdroje v poradí a skončí pri prvom použiteľnom kľúči. Najprv sa bez otázok skopíruje zodpovedajúci kľúč spravovaný PVE z /etc/pve/priv/storage/<NAME>.enc na kanonickú cestu, ak existuje pre vybrané úložisko PBS. Ak je na PBS dostupná skupina -keyrecovery, druhý krok stiahne jej najnovšiu snímku a vyžiada prístupovú frázu na dešifrovanie. Ak ani jedna možnosť nefunguje alebo ich operátor odmietne, tretí krok vyžiada absolútnu cestu k súboru kľúča na tomto hostiteľovi a skopíruje ho na kanonickú cestu. Monitor poskytuje rovnaký import v okne podrobností zálohy. Ak Obnoviť, Stiahnuť alebo Zobraziť obsah potrebuje chýbajúci kľúč, hore sa zobrazí jantárový panel. Ak je kľúč nainštalovaný, ale nezodpovedá šifrovaniu zálohy, PBS vráti chybu wrong key — manifest's key XX does not match provided key YY. Rovnaké tri akcie potom zobrazia štruktúrovaný panel so zvýrazneným odtlačkom kľúča požadovaným manifestom, aby operátor vedel, ktorý kľúč má pre túto zálohu importovať.", "monitorManagementTitle": "Správa súboru kľúčov z monitora", - "monitorManagementBody": "Monitor zobrazuje ovládanie súboru kľúča priamo v každom riadku cieľa PBS na stránke konfigurácie záloh. Sú tam tri akcie: Stiahnuť exportuje aktuálny súbor do prehliadača operátora; Nahrať nahradí nainštalovaný súbor dodaným súborom, pričom pôvodný prepíše až po úspešnom uložení nového na kanonickú cestu; Odstrániť zmaže súbor z hostiteľa. Vedľa je ovládanie obnovovacej kópie: výber Áno/Nie pre Odoslať kľúč na PBS?, pole prístupovej frázy pri voľbe Áno a kontextové tlačidlo na použitie voľby Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu. Všetky akcie používajú rovnaké koncové body Flask ako terminálové rozhranie, takže účinok na disku a stav na PBS sú z oboch rozhraní rovnaké." + "monitorManagementBody": "Monitor zobrazuje ovládanie súboru kľúča v každom riadku cieľa PBS na stránke konfigurácie záloh. Riadok ponúka tri akcie: Stiahnuť exportuje aktuálny súbor kľúča do prehliadača používateľa, Nahrať nahradí nainštalovaný súbor kľúča súborom, ktorý dodá používateľ (pôvodný súbor sa prepíše až potom, ako nový správne dorazí na svoju cestu), a Odstrániť odstráni súbor kľúča z hostiteľa. Hneď vedľa je prepínač obálky na obnovenie: výber Áno/Nie pre Odoslať kľúč na PBS?, pole prístupovej frázy, ktoré sa zobrazí pri voľbe Áno, a tlačidlo, ktoré sa riadi aktuálnym stavom: Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu. Ovládacie prvky v Monitore a dialóg v shelli vykonávajú v pozadí to isté, takže výsledok na disku aj na PBS je rovnaký bez ohľadu na to, ktorý z nich sa použije." }, "restoreAccess": { "heading": "Získavanie na strane obnovy", diff --git a/web/messages/sk/docs/backup-restore/how-it-works.json b/web/messages/sk/docs/backup-restore/how-it-works.json index 76f3c680..a3e816b8 100644 --- a/web/messages/sk/docs/backup-restore/how-it-works.json +++ b/web/messages/sk/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Potvrdenie schémy", - "schemaBody": "Manifest sa overuje podľa scripts/backup_restore/schema/manifest.schema.json. Príkaz build_manifest.sh --validate spustí validáciu JSON Schema v Pythone, ktorá vyžaduje python3 a jsonschema. Ak modul chýba, kontrola sa bez upozornenia preskočí. Validácia slúži najmä vývojárom, nie je závislosťou potrebnou pri bežnom behu." + "schemaBody": "ProxMenux obsahuje šablónu, ktorá opisuje, ktoré polia musí manifest obsahovať a aký tvar má každé z nich. Pri vytváraní zálohy možno manifest automaticky overiť podľa tejto šablóny, takže zberač, ktorý vytvoril chybný JSON alebo pole s preklepom, sa odhalí okamžite. Kontrola je určená na vývoj samotného ProxMenux: v systéme, kde nie je nainštalovaná, záloha funguje ako zvyčajne a manifest sa vytvorí rovnako." }, "applications": { "heading": "Inventár aplikácií", diff --git a/web/messages/sk/docs/oci-manager/hardware.json b/web/messages/sk/docs/oci-manager/hardware.json index f6a5bf36..0c2cfe52 100644 --- a/web/messages/sk/docs/oci-manager/hardware.json +++ b/web/messages/sk/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "Renderovací uzol, /dev/kfd a generácia, ktorú výpočtový ovládač hlási v /sys/class/kfd/kfd/topology/nodes/*/properties", - "Generácia, pre ktorú obraz ROCm aplikácie obsahuje výpočtové jadrá — uvedené GPU RDNA2 a novšie — sa ponúkne bez úprav. Ostatné GPU týchto rodín, napríklad Radeon 680M a 780M, sa ponúkajú ako experimentálne a nikdy nie sú navrhnutou voľbou: ROCm ich oficiálne nepodporuje, aplikácia ich prezentuje ako generáciu danej rodiny (HSA_OVERRIDE_GFX_VERSION) a inštalátor pred stiahnutím väčšieho obrazu vyžiada potvrdenie. Staršia GPU, napríklad integrovaná grafika Ryzen 5000U, sa neponúkne a Immich ponechá rozpoznávanie na CPU." + "GPU generácie, ktorú obraz ROCm aplikácie podporuje (uvedené GPU RDNA2 a novšie), sa ponúkne bez úprav. Ostatné GPU týchto rodín, napríklad Radeon 680M a 780M, sa ponúkajú ako experimentálne a nikdy nie sú navrhnutou voľbou. ROCm ich oficiálne nepodporuje: aplikácia ich prezentuje ako generáciu danej rodiny (HSA_OVERRIDE_GFX_VERSION) a inštalátor pred stiahnutím väčšieho obrazu vyžiada potvrdenie. Staršia GPU, napríklad integrovaná grafika Ryzen 5000U, sa neponúkne a Immich ponechá rozpoznávanie na CPU" ], [ "NVIDIA", diff --git a/web/messages/sk/docs/oci-manager/lifecycle.json b/web/messages/sk/docs/oci-manager/lifecycle.json index 5f345b34..fe648caf 100644 --- a/web/messages/sk/docs/oci-manager/lifecycle.json +++ b/web/messages/sk/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "Nový obraz sa overí vrstvu po vrstve ešte pred zastavením CT. Poškodené stiahnutie sa zopakuje druhýkrát; obraz už uložený vo vyrovnávacej pamäti, ktorý neprejde kontrolou, sa stiahne znova.", "Nastavenia zmenené v Proxmox VE po inštalácii (pamäť, swap, jadrá, limit CPU, priorita CPU, spustenie spolu s uzlom) sa zachovajú a prenesú do nového kontraktu.", "Rozhranie LAN, ktoré pridáva súprava Arr a aplikácie s viacerými kontajnermi (net1), aj poradie spúšťania (startup) sa bez zmeny prenesú do nového kontajnera.", + "Adresár hostiteľa sa rozpoznáva podľa svojej cesty a súborového systému, na ktorom sa nachádza, nie podľa názvu zariadenia, ktorý hostiteľ dáva jeho disku, takže disk USB alebo sieťový disk, ktorý sa vráti pod iným názvom, je stále ten istý adresár. Keď jeho disk nie je pripojený, aktualizácia sa zastaví pred zastavením CT a uvedie chýbajúci adresár.", "Akýkoľvek iný rozdiel medzi CT a jeho zmluvou zastaví aktualizáciu pred zastavením CT." ] } diff --git a/web/messages/sk/docs/oci-manager/storage-network.json b/web/messages/sk/docs/oci-manager/storage-network.json index f0ff007e..163def74 100644 --- a/web/messages/sk/docs/oci-manager/storage-network.json +++ b/web/messages/sk/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Úložisko a veľkosť", - "body": "Na úložisku Proxmox VE sa vytvorí disk kontajnera so zadanou veľkosťou. Predvolená inštalácia používa local-lvm. Rozšírená inštalácia sa pri každej ceste pýta najprv na úložisko a potom na veľkosť; navrhuje úložisko rootfs. Disk sa zobrazuje ako vm-VMID-disk-N a pripája sa ako mpN." + "body": "Na úložisku Proxmox VE sa vytvorí disk kontajnera so zadanou veľkosťou. Predvolená inštalácia sa raz opýta na úložisko kontajnera a jeho údajov, ak má uzol viac ako jedno; rozšírená inštalácia sa pri každej ceste pýta na úložisko tesne pred veľkosťou a navrhuje úložisko rootfs. Disk sa zobrazuje ako vm-VMID-disk-N a pripája sa ako mpN." }, { "title": "Adresár hostiteľa", @@ -109,6 +109,9 @@ }, { "p": "Rootfs je vyhradený pre binárne súbory a obsah obrazu. Aktualizácia alebo opätovné vytvorenie ho nahradí bez zásahu do ktoréhokoľvek z dvoch typov prípojných bodov." + }, + { + "p": "Adresár hostiteľa sa pripojí so všetkým, čo v ňom má hostiteľ pripojené. Adresár ako /mnt/pve zobrazí v kontajneri svoje sieťové zdieľania, disky a datasety a to, čo tam hostiteľ neskôr pripojí alebo odpojí, sa zobrazí alebo zmizne bez reštartu kontajnera. Adresár pridaný iba na čítanie je iba na čítanie spolu s tým, čo je v ňom pripojené pri spustení kontajnera. Súborový systém, ktorý hostiteľ pripojí neskôr, prichádza s oprávneniami, s ktorými ho hostiteľ pripojí, a pri reštarte kontajnera bude tiež iba na čítanie." } ] }, diff --git a/web/messages/sk/docs/post-install/index.json b/web/messages/sk/docs/post-install/index.json index af8baf78..bc4e6e8c 100644 --- a/web/messages/sk/docs/post-install/index.json +++ b/web/messages/sk/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Komunitné skripty", "body": "Menu ponúka aj dva skripty tretích strán z projektu community-scripts: Proxmox VE Post Install a Proxmox VE Microcode. Ide o obaly, ktoré stiahnu a spustia pôvodné autorské skripty cez wget | bash. ProxMenux ich neudržiava. Pred spustením si pozrite podrobnosti a otázky dôvery v časti Externé repozitáre." }, + "pbs": { + "heading": "Na Proxmox Backup Server", + "body": "Na hostiteľovi Proxmox Backup Server sa rovnaká ponuka otvára cez Nastavenie Proxmoxu po inštalácii v ponuke PBS. Automatický, Prispôsobiteľný, Nainštalovať dostupné aktualizácie a Odinštalovať optimalizácie fungujú ako na Proxmox VE, s týmito rozdielmi:", + "items": [ + "Repozitáre a aktualizácia: keď server nemá predplatné a aktívny je iba repozitár Enterprise pre PBS, ProxMenux sa pred prepnutím na repozitár PBS bez predplatného opýta. Prepnutie prebieha cez API repozitárov samotného servera, rovnaké, aké používa Administration > Repositories. Pri aktívnom predplatnom alebo pri už nastavenom repozitári bez predplatného či testovacom repozitári zostanú zdroje bez zmeny.", + "Prispôsobiteľný zoznam: možnosti, ktoré platia iba pre Proxmox VE, sa nezobrazujú: hosťovský agent, VFIO IOMMU, Open vSwitch, rýchlosť záloh vzdump, pigz, Appliance Manager, Ceph, vysoká dostupnosť a OVH Real Time Monitoring.", + "Banner predplatného: záplata sa vzťahuje na webové rozhranie Proxmox Backup Server a Odinštalovať optimalizácie ho obnoví.", + "Figurine: inštaluje sa bez aliasov Proxmox VE.", + "Komunitné skripty: sekcia ponúka Proxmox Backup Server Post Install a Proxmox Backup Server Microcode namiesto skriptov pre Proxmox VE." + ] + }, "related": { "heading": "Súvisiace", "items": [ diff --git a/web/messages/sv/docs/backup-restore/destinations/index.json b/web/messages/sv/docs/backup-restore/destinations/index.json index 793321f9..99eca320 100644 --- a/web/messages/sv/docs/backup-restore/destinations/index.json +++ b/web/messages/sv/docs/backup-restore/destinations/index.json @@ -76,7 +76,7 @@ }, "sameArchive": { "heading": "Arkivlayouten ändras inte med destinationen", - "body": "Alla tre destinationerna innehåller samma struktur med rootfs/ + metadata/ + manifest.json som beskrivs i Så fungerar det. Ett uppackat lokalt .tar.zst-arkiv, ett .pxar-arkiv återställt från PBS och ett Borg-arkiv uppackat med borg extract ger samma katalogträd. Återställningskoden (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) läser samma tre datablock utan att behöva veta vilken destination de kommer från." + "body": "Var säkerhetskopian än lagras innehåller den alltid samma tre block som beskrivs i Så fungerar det: filsystemet (rootfs/), metadata (metadata/) och manifestet (manifest.json). Att packa upp ett lokalt .tar.zst-arkiv, återställa ett .pxar-arkiv från PBS eller packa upp ett Borg-arkiv ger alltid samma katalogträd. Återställningen läser därför alltid samma filer, oavsett vilken destination säkerhetskopian kommer från." }, "extractStandalone": { "heading": "Extrahera en backup utanför ProxMenux", diff --git a/web/messages/sv/docs/backup-restore/destinations/pbs.json b/web/messages/sv/docs/backup-restore/destinations/pbs.json index 2fe4d02b..70e5c074 100644 --- a/web/messages/sv/docs/backup-restore/destinations/pbs.json +++ b/web/messages/sv/docs/backup-restore/destinations/pbs.json @@ -23,7 +23,7 @@ }, "repoSelection": { "heading": "Repository urval", - "intro": "ProxMenux upptäcker PBS repositorier från två källor på varje backup. Operatören väljer en från en enhetlig meny; valet bestämmer HB_PBS_REPOSITORY, HB_PBS_SECRET och HB_PBS_FINGERPRINT för körningen.", + "intro": "ProxMenux hittar PBS-repositorier från två källor vid varje säkerhetskopiering. Användaren väljer ett från en enhetlig meny; för den körningen avgör valet vilken server och vilket datalager säkerhetskopian skickas till, vilket lösenord den autentiserar sig med och vilket fingeravtryck som validerar certifikatet.", "sourceRows": [ { "source": "Proxmox storage.cfg (identifierad automatiskt)", @@ -46,7 +46,7 @@ "backupIdTitle": "Namnge säkerhetskopierings-ID", "backupIdBody": "Standard-ID är hostcfg-HOSTNAME. Operatören bekräftar eller redigerar det före uppladdning; tecken utanför [A-Za-z0-9_-] och avslutande bindestreck tas bort. Att återanvända samma ID är avsiktligt: PBS behandlar ID:t som en grupp, och varje senare säkerhetskopia blir en ny post i gruppen med gemensam deduplicering med tidigare körningar.", "pxarTitle": "Varför källan är hela staging roten", - "pxarBody": ".pxar-källan är hela staging_root - rootfs/, metadata/ och manifest.json tillsammans. Tidigare versioner passerade $staging_root/rootfs som källa; som lämnade metadata/ ur arkivet och återställningens kompatibilitetskontroll hade ingenting att läsa, försämrade att korsa värd varningar även på samma värd återställningar. Gamla säkerhetskopior som skapats med rootfs-bara källan återställs fortfarande korrekt via _rs_check_layout: s fall-3 gren, som lindrar en platt etc/var/root/usr träd tillbaka till en rootfs/ hierarki." + "pxarBody": ".pxar-arkivet packar hela arbetskatalogen: värdens filsystem (rootfs/), metadata (metadata/) och manifestet (manifest.json). Vid återställning jämför ProxMenux manifestet med målvärden för att avgöra om de är likvärdiga, om hårdvaran har ändrats eller om det är en annan maskin, och anpassar processen därefter. Äldre säkerhetskopior, gjorda av tidigare ProxMenux-versioner som bara packade filsystemet, återställs fortfarande korrekt: återställningen upptäcker det äldre formatet och ordnar om det automatiskt." }, "encryption": { "heading": "Klient-side kryptering", @@ -63,7 +63,7 @@ "recoveryTitle": "Ladda upp nyckeln till PBS – operatören bestämmer", "recoveryBody": "Direkt efter valet av nyckelfil ställer ProxMenux den uttryckliga frågan Ladda upp nyckeln till PBS? med två svar. Ingen återställningsfil laddas upp till PBS förrän operatören svarar Ja. Standardvalet är Nej, behåll endast lokalt: nyckelfilen ligger kvar på den kanoniska lokala sökvägen, ProxMenux laddar inte upp någon återställningsfil till PBS och operatören ansvarar själv för kopian utanför värden. Knappen Ladda ner nyckelfil på PBS-målets rad i Monitor ger en kopia vid behov. Valet Ja, ladda upp efterfrågar en återställningslösenfras två gånger och kontrollerar att svaren matchar. ProxMenux skyddar nyckelfilen med AES-256-CBC och PBKDF2 (600 000 iterationer, slumpmässigt salt) och skapar pbs-key.recovery.enc. Varje senare krypterad säkerhetskopia laddar upp detta kuvert till PBS som en tillhörande säkerhetskopieringsgrupp. Dessa uppladdningar skickar varken lösenfrasen eller nyckelfilen i klartext till PBS. Valet kan ändras när som helst i Monitor: kontrollen på PBS-målets rad växlar Ja/Nej och tillämpar omedelbart Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras beroende på aktuellt tillstånd.", "blobUploadTitle": "Tillhörande säkerhetskopieringsgrupp på PBS", - "blobUploadBody1": "När läget är Ja, ladda upp laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra tillhörande grupp. Den har samma namn som värdens grupp med suffixet -keyrecovery. Grupperna visas bredvid varandra i datalagrets lista: en för värdsäkerhetskopior och en för återställningskuvert. Kuvertet lämnar aldrig värden i klartext: krypteringen sker på värden med AES-256-CBC och PBKDF2 innan några data överförs (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS tar endast emot det redan krypterade kuvertet.", + "blobUploadBody1": "När svaret är Ja, ladda upp laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra, tillhörande säkerhetskopieringsgrupp. Den har samma namn som värdens grupp men slutar på -keyrecovery. Grupperna visas bredvid varandra i datalagrets lista: en för värdsäkerhetskopior och en för återställningskuvert. Kuvertet lämnar aldrig värden i klartext: krypteringen sker på värden själv med AES-256-CBC och PBKDF2 innan några byte överförs (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS tar endast emot det redan krypterade kuvertet.", "envelopeSecurityTitle": "Överför nyckelåterhämtningsfilen till PBS en säkerhetsrisk?", "envelopeSecurityBody": "Keyrecovery-filen krypteras i transit och i vila. Återhämtningspassfrasen lämnar aldrig värden: kryptering sker lokalt före uppladdningen, och PBS ser bara det redan krypterade resultatet. En PBS-administratör - eller någon med tillgång till databutiken - kan ladda ner nyckelrecovery-filen, men utan återställningspassfrasen kan de inte läsa nyckelfilen inuti: det är ogenomskinlig chiffertext. Rekonstruera nyckelfilen kräver båda bitarna samtidigt, nyckelrecovery-filen och passfrasen, och endast operatören håller båda.", "blobUploadConstraintTitle": "Varför två grupper istället för en enda krypterad", @@ -73,7 +73,7 @@ "recoverTitle": "Återhämtning på en ny värd", "recoverBody": "Om nyckelfilen saknas på den kanoniska sökvägen, efter en ominstallation eller uttrycklig borttagning, provar återställningen tre källor i ordning och stannar vid den första användbara nyckeln. Först kopieras en matchande PVE-hanterad nyckel från /etc/pve/priv/storage/<NAME>.enc utan frågor till den kanoniska sökvägen, om den finns för det valda PBS-förvaret. Om det finns en -keyrecovery-grupp på PBS laddas sedan den senaste ögonblicksbilden ner och operatören anger återställningslösenfrasen för att dekryptera den. Om båda alternativen misslyckas eller avböjs efterfrågas till sist den absoluta sökvägen till nyckelfilen på värden, och filen kopieras till den kanoniska sökvägen. Monitor visar samma importflöde i säkerhetskopians detaljdialog. En gul panel visas överst när Återställ, Ladda ner eller Visa innehåll behöver en nyckel som saknas. Om en installerad nyckel inte matchar säkerhetskopian returnerar PBS wrong key — manifest's key XX does not match provided key YY. Samma tre åtgärder visar då en strukturerad panel med manifestets nödvändiga nyckelfingeravtryck tydligt utmärkt, så att operatören kan identifiera rätt nyckelfil att importera för säkerhetskopian.", "monitorManagementTitle": "Hantera nyckelfilen från Monitor", - "monitorManagementBody": "Monitor visar nyckelfilens kontroller direkt på varje PBS-målrad i säkerhetskopieringskonfigurationen. Tre åtgärder finns: Ladda ner exporterar den aktuella filen till webbläsaren; Ladda upp ersätter den installerade filen med operatörens fil, och den gamla skrivs över först när den nya har installerats på den kanoniska sökvägen; Ta bort tar bort filen från värden. Bredvid finns kontrollen för återställningskopian: ett Ja/Nej-val för Ladda upp nyckeln till PBS?, ett lösenfrasfält när Ja väljs och en knapp som beroende på tillstånd tillämpar Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras. Alla åtgärder använder samma Flask-slutpunkter som terminalgränssnittet, så effekten på disk och tillståndet på PBS blir identiska från båda gränssnitten." + "monitorManagementBody": "Monitor visar nyckelfilens kontroller på varje PBS-målrad på sidan för säkerhetskopieringskonfiguration. Raden har tre åtgärder: Ladda ner exporterar den aktuella nyckelfilen till användarens webbläsare, Ladda upp ersätter den installerade nyckelfilen med en som användaren tillhandahåller (den tidigare filen skrivs över först när den nya har kommit fram korrekt till sin sökväg) och Ta bort tar bort nyckelfilen från värden. Direkt bredvid finns reglaget för återställningskuvertet: ett Ja/Nej-val för Ladda upp nyckeln till PBS?, ett lösenfrasfält som visas när Ja väljs och en knapp som följer det aktuella tillståndet: Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras. Kontrollerna i Monitor och dialogrutan i skalet gör samma sak i grunden, så resultatet på disken och på PBS blir identiskt oavsett vilket som används." }, "restoreAccess": { "heading": "Hämta vid återställning", diff --git a/web/messages/sv/docs/backup-restore/how-it-works.json b/web/messages/sv/docs/backup-restore/how-it-works.json index b50bb742..42415ca0 100644 --- a/web/messages/sv/docs/backup-restore/how-it-works.json +++ b/web/messages/sv/docs/backup-restore/how-it-works.json @@ -121,7 +121,7 @@ } ], "schemaTitle": "Schema validering", - "schemaBody": "manifestet validerar mot scripts/backup_restore/schema/manifest.schema.json. Kör build_manifest.sh --validate utlöser en Python-side JSON Schema validering (kräver python3 + jsonschema). Om modulen inte är närvarande, är kontrollen hoppad tyst - validering är i första hand ett utvecklarhjälp, inte ett drifttidsberoende." + "schemaBody": "ProxMenux levereras med en mall som beskriver vilka fält manifestet måste innehålla och hur vart och ett ska se ut. När en säkerhetskopia skapas kan manifestet kontrolleras automatiskt mot mallen, så att en insamlare som har gett felformaterad JSON eller ett felstavat fält upptäcks direkt. Kontrollen är avsedd för utvecklingen av ProxMenux självt: på ett system där den inte är installerad fungerar säkerhetskopieringen som vanligt och manifestet skapas ändå." }, "applications": { "heading": "Applikationsinventeringen", diff --git a/web/messages/sv/docs/backup-restore/scheduled-jobs.json b/web/messages/sv/docs/backup-restore/scheduled-jobs.json index ae00c752..cd4cd3b5 100644 --- a/web/messages/sv/docs/backup-restore/scheduled-jobs.json +++ b/web/messages/sv/docs/backup-restore/scheduled-jobs.json @@ -127,7 +127,7 @@ }, "notifications": { "heading": "Aviseringar", - "body": "Varje schemalagd körning utlöser samma hb_notify_lifecycle händelser som det interaktiva flödet (start, complete, fail). Om meddelandekanaler är konfigurerade i Monitor, obevakade jobb visar sina resultat på samma sätt manuella säkerhetskopior gör - en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades." + "body": "Varje schemalagd körning utlöser samma hb_notify_lifecycle-händelser som det interaktiva flödet (start, complete, fail). Om aviseringskanaler är konfigurerade i Monitor visar obevakade jobb sina resultat på samma sätt som manuella säkerhetskopior – en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades." }, "whereNext": { "heading": "Nästa steg", diff --git a/web/messages/sv/docs/oci-manager/hardware.json b/web/messages/sv/docs/oci-manager/hardware.json index e828a5d7..747b3991 100644 --- a/web/messages/sv/docs/oci-manager/hardware.json +++ b/web/messages/sv/docs/oci-manager/hardware.json @@ -105,7 +105,7 @@ [ "AMD ROCm", "Rendernoden, /dev/kfd och generationen som beräkningsdrivrutinen rapporterar i /sys/class/kfd/kfd/topology/nodes/*/properties", - "En generation som programmets ROCm-avbildning innehåller beräkningskärnor för — de namngivna RDNA2-GPU:erna och nyare — erbjuds utan anpassning. Andra GPU:er i dessa familjer, till exempel Radeon 680M och 780M, erbjuds som experimentella och väljs aldrig som föreslaget alternativ: ROCm stöder dem inte officiellt, programmet presenterar dem som familjens generation (HSA_OVERRIDE_GFX_VERSION) och installeraren begär bekräftelse innan den större avbildningen hämtas. Äldre GPU:er, till exempel den integrerade grafiken i Ryzen 5000U, erbjuds inte och Immich fortsätter köra igenkänningen på CPU:n." + "En GPU av en generation som programmets ROCm-avbildning stöder (de RDNA2-GPU:er den nämner och nyare) erbjuds som den är. Andra GPU:er i dessa familjer, till exempel Radeon 680M och 780M, erbjuds som experimentella och är aldrig det föreslagna alternativet. ROCm stöder dem inte officiellt: programmet presenterar dem som familjens generation (HSA_OVERRIDE_GFX_VERSION) och installeraren begär bekräftelse innan den större avbildningen hämtas. En äldre GPU, till exempel den integrerade grafiken i en Ryzen 5000U, erbjuds inte och Immich fortsätter köra igenkänningen på CPU:n" ], [ "NVIDIA", diff --git a/web/messages/sv/docs/oci-manager/lifecycle.json b/web/messages/sv/docs/oci-manager/lifecycle.json index b4a5ad6e..11486303 100644 --- a/web/messages/sv/docs/oci-manager/lifecycle.json +++ b/web/messages/sv/docs/oci-manager/lifecycle.json @@ -104,6 +104,7 @@ "Den nya avbildningen verifieras lager för lager innan CT:n stoppas. En skadad nedladdning hämtas en andra gång; en redan cachad avbildning som inte klarar kontrollen laddas ned igen.", "Inställningar som ändrats i Proxmox VE efter installationen (minne, swap, kärnor, CPU-gräns, CPU-prioritet och start med noden) bevaras och förs över till det nya kontraktet.", "LAN-gränssnittet som Arr-sviten och multi-container-applikationerna lägger till (net1) och startordern (startup) ges tillbaka till den nya containern som de är.", + "En katalog på värden känns igen på sin sökväg och på filsystemet den ligger på, inte på det enhetsnamn som värden ger dess disk, så en USB- eller nätverksdisk som kommer tillbaka under ett annat namn är fortfarande samma katalog. När dess disk inte är ansluten stoppar uppdateringen innan CT stoppas och anger vilken katalog som saknas.", "Alla andra skillnader mellan CT och dess kontrakt stoppar uppdateringen innan CT stoppas." ] } diff --git a/web/messages/sv/docs/oci-manager/storage-network.json b/web/messages/sv/docs/oci-manager/storage-network.json index db121e93..3d2df763 100644 --- a/web/messages/sv/docs/oci-manager/storage-network.json +++ b/web/messages/sv/docs/oci-manager/storage-network.json @@ -38,7 +38,7 @@ }, { "title": "Lagring och storlek", - "body": "En containerdisk skapas på en Proxmox VE-lagring med den angivna storleken. Standardinstallationen använder local-lvm. Den avancerade installationen frågar efter lagring för varje sökväg strax före storleken och föreslår lagringen för rootfs. Disken visas som vm-VMID-disk-N och ansluts som mpN." + "body": "En containerdisk skapas på en Proxmox VE-lagring med den angivna storleken. Standardinstallationen frågar en gång efter lagringen för containern och dess data när noden har mer än en; den avancerade installationen frågar efter lagring för varje sökväg strax före storleken och föreslår lagringen för rootfs. Disken visas som vm-VMID-disk-N och ansluts som mpN." }, { "title": "Katalog på värden", @@ -109,6 +109,9 @@ }, { "p": "Rootfs är reserverat för binärfilerna och avbildningens innehåll. En uppdatering eller ett återskapande ersätter det utan att röra någon av de två typerna av monteringspunkt." + }, + { + "p": "En katalog på värden monteras med allt som värden har monterat i den. En katalog som /mnt/pve visar sina nätverksresurser, diskar och dataset i containern, och det som värden senare monterar eller avmonterar där dyker upp eller försvinner utan att containern startas om. En katalog som lagts till som skrivskyddad är skrivskyddad tillsammans med det som är monterat i den när containern startar. Ett filsystem som värden monterar efteråt kommer med de behörigheter som värden monterar det med, och blir också skrivskyddat när containern startas om." } ] }, diff --git a/web/messages/sv/docs/post-install/index.json b/web/messages/sv/docs/post-install/index.json index e9e49444..fbd1baef 100644 --- a/web/messages/sv/docs/post-install/index.json +++ b/web/messages/sv/docs/post-install/index.json @@ -78,6 +78,17 @@ "heading": "Gemenskapens skript", "body": "Menyn erbjuder också två tredjepartsskript från projektet community-scripts: Proxmox VE Post Install och Proxmox VE Microcode. Startskripten laddar ned och kör originalförfattarnas skript via wget | bash. De underhålls inte av ProxMenux. Se Externa paketförråd för detaljer och frågor om tillit innan du kör dem." }, + "pbs": { + "heading": "På Proxmox Backup Server", + "body": "På en Proxmox Backup Server-värd öppnas samma meny från Inställningar efter installation av Proxmox i PBS-menyn. Automatiserat, Anpassningsbart, Tillämpa tillgängliga uppdateringar och Avinstallera optimeringar fungerar som på Proxmox VE, med dessa skillnader:", + "items": [ + "Paketkällor och uppgradering: när servern saknar prenumeration och bara Enterprise-källan för PBS är aktiv frågar ProxMenux innan den byter till PBS-källan utan prenumeration. Bytet görs via serverns egen API för paketkällor, samma som används i Administration > Repositories. Med en aktiv prenumeration, eller med en källa utan prenumeration eller en testkälla redan konfigurerad, lämnas källorna som de är.", + "Anpassningsbar lista: alternativ som bara gäller Proxmox VE visas inte: gästagent, VFIO IOMMU, Open vSwitch, hastighet för vzdump-backuper, pigz, Appliance Manager, Ceph, hög tillgänglighet och OVH Real Time Monitoring.", + "Prenumerationsbanner: patchen gäller webbgränssnittet för Proxmox Backup Server, och Avinstallera optimeringar återställer det.", + "Figurine: installeras utan Proxmox VE-aliasen.", + "Communityskript: avsnittet erbjuder Proxmox Backup Server Post Install och Proxmox Backup Server Microcode i stället för Proxmox VE-skripten." + ] + }, "related": { "heading": "Relaterat", "items": [