mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +00:00
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
This commit is contained in:
MacRimi
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "Das Archivlayout ändert sich nicht mit dem Ziel",
|
||||
"body": "Innerhalb eines der drei Ziele ist das gleiche <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> Layout vorhanden, das in <em>Funktionsweise</em> beschrieben wird. Ein aus einem lokalen Archiv extrahierter <code>.tar.zst</code>, ein aus PBS wiederhergestellter <code>.pxar</code> und ein mit <code>borg extract</code> extrahiertes Borg-Archiv ergeben alle einen identischen Verzeichnisbaum. Der Wiederherstellungscodepfad (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) liest die gleichen drei Nutzlasten, ohne zu wissen, von welchem Ziel sie kamen."
|
||||
"body": "Unabhängig davon, wo das Backup gespeichert ist, enthält es immer dieselben drei Blöcke, die in <em>Funktionsweise</em> beschrieben sind: das Dateisystem (<code>rootfs/</code>), die Metadaten (<code>metadata/</code>) und das Manifest (<code>manifest.json</code>). Das Entpacken eines lokalen <code>.tar.zst</code>-Archivs, das Wiederherstellen eines <code>.pxar</code> aus PBS oder das Entpacken eines Borg-Archivs ergeben alle einen identischen Verzeichnisbaum. Die Wiederherstellung liest daher immer dieselben Dateien, unabhängig davon, von welchem Ziel das Backup stammt."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extrahieren eines Backups außerhalb von ProxMenux",
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Repository-Auswahl",
|
||||
"intro": "ProxMenux entdeckt PBS-Repositories aus zwei Quellen in jedem Backup. Der Bediener wählt einen aus einem einheitlichen Menü aus; die Auswahl bestimmt <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> und <code>HB_PBS_FINGERPRINT</code> für den Lauf.",
|
||||
"intro": "ProxMenux ermittelt bei jedem Backup PBS-Repositories aus zwei Quellen. Der Benutzer wählt eines aus einem einheitlichen Menü aus; für diesen Lauf bestimmt die Auswahl, an welchen Server und welchen Datenspeicher das Backup gesendet wird, mit welchem Passwort es sich authentifiziert und welcher <em>Fingerabdruck</em> das Zertifikat validiert.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "Proxmox storage.cfg (automatisch erkannt)",
|
||||
@@ -46,7 +46,7 @@
|
||||
"backupIdTitle": "Backup-ID-Bezeichnung",
|
||||
"backupIdBody": "Die Standard-Backup-ID ist <code>hostcfg-HOSTNAME</code>. Vor dem Upload wird sie bestätigt oder bearbeitet. Zeichen außerhalb von <code>[A-Za-z0-9_-]</code> sowie abschließende Bindestriche werden entfernt. Die Wiederverwendung derselben ID bei weiteren Läufen ist beabsichtigt: PBS behandelt die ID als <em>Gruppe</em>. Jedes weitere Backup erscheint als neuer Eintrag in dieser Gruppe und nutzt die Deduplizierung mit früheren Backups.",
|
||||
"pxarTitle": "Warum die Quelle die vollständige Staging-Wurzel ist",
|
||||
"pxarBody": "Die <code>.pxar</code>-Quelle ist die gesamte <code>staging_root</code> - <code>rootfs/</code>, <code>metadata/</code> und <code>manifest.json</code> zusammen. Frühere Versionen bestanden <code>$staging_root/rootfs</code> als Quelle; Das ließ <code>metadata/</code> aus dem Archiv und die Kompatibilitätsprüfung der Wiederherstellung hatte nichts zu lesen, was selbst bei Wiederherstellungen des gleichen Hosts zu Cross-Host-Warnungen führte. Alte Backups, die mit der Rootfs-only-Quelle erstellt wurden, werden immer noch korrekt über den <code>_rs_check_layout</code>-Fall-3-Zweig wiederhergestellt, der einen flachen <code>etc/var/root/usr</code>-Baum zurück in eine <code>rootfs/</code>-Hierarchie wickelt."
|
||||
"pxarBody": "Das <code>.pxar</code>-Archiv packt das gesamte Arbeitsverzeichnis: das Dateisystem des Hosts (<code>rootfs/</code>), die Metadaten (<code>metadata/</code>) und das Manifest (<code>manifest.json</code>). Bei der Wiederherstellung vergleicht ProxMenux das Manifest mit dem Zielhost, um festzustellen, ob beide gleichwertig sind, ob sich die Hardware geändert hat oder ob es sich um eine andere Maschine handelt, und passt den Ablauf entsprechend an. Ältere Backups, die von früheren ProxMenux-Versionen erstellt wurden und nur das Dateisystem packten, werden weiterhin korrekt wiederhergestellt: Die Wiederherstellung erkennt dieses alte Format und ordnet es automatisch neu an."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Clientseitige Verschlüsselung",
|
||||
@@ -63,7 +63,7 @@
|
||||
"recoveryTitle": "Schlüssel auf PBS hinterlegen — der Betreiber entscheidet",
|
||||
"recoveryBody": "Direkt nach Auswahl der Schlüsseldatei fragt ProxMenux ausdrücklich <em>Schlüssel auf PBS hochladen?</em> und bietet zwei Antworten. <strong>Erst wenn der Betreiber Ja wählt, wird ein Wiederherstellungsartefakt auf PBS hochgeladen.</strong> Vorgabe ist <em>Nein, nur lokal behalten</em>: Die Schlüsseldatei bleibt am kanonischen lokalen Pfad, ProxMenux lädt kein Wiederherstellungsartefakt auf PBS hoch und der Betreiber sorgt selbst für eine externe Kopie. Die Schaltfläche <em>Schlüsseldatei herunterladen</em> in der PBS-Zielzeile des Monitors stellt sie bei Bedarf bereit. Bei <em>Ja, hochladen</em> wird zweimal eine Wiederherstellungspassphrase abgefragt und auf Übereinstimmung geprüft. ProxMenux schützt die Schlüsseldatei damit mittels AES-256-CBC und PBKDF2 (600.000 Iterationen, zufälliges Salt) und erzeugt <code>pbs-key.recovery.enc</code>. Jedes weitere verschlüsselte Backup lädt diese Hülle als zugehörige Backup-Gruppe auf PBS hoch. Dabei werden weder die Passphrase noch die Schlüsseldatei im Klartext an PBS gesendet. Die Entscheidung lässt sich jederzeit im Monitor ändern: Der Schalter in der PBS-Zielzeile wählt Ja oder Nein und übernimmt je nach Zustand sofort Upload starten, Upload stoppen oder Passphrase aktualisieren.",
|
||||
"blobUploadTitle": "Gepaarte Backup-Gruppe auf PBS",
|
||||
"blobUploadBody1": "Ist die Hinterlegung auf <em>Ja, hochladen</em> gesetzt, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie heißt wie die Host-Gruppe, ergänzt um <code>-keyrecovery</code>. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. <strong>Die Hülle verlässt den Host niemals im Klartext</strong>: Noch vor der Übertragung verschlüsselt der Host sie mit AES-256-CBC und PBKDF2 (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
|
||||
"blobUploadBody1": "Lautet die Antwort <em>Ja, hochladen</em>, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie trägt denselben Namen wie die Host-Gruppe, endet aber auf <code>-keyrecovery</code>. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. <strong>Die Hülle verlässt den Host niemals im Klartext</strong>: Noch bevor ein Byte übertragen wird, verschlüsselt der Host sie selbst mit AES-256-CBC und PBKDF2 (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
|
||||
"envelopeSecurityTitle": "Ist das Hochladen der keyrecovery-Datei in PBS ein Sicherheitsrisiko?",
|
||||
"envelopeSecurityBody": "Die keyrecovery-datei ist verschlüsselt in transit und in ruhe. Die Wiederherstellungspassphrase verlässt den Host nie: Verschlüsselung geschieht lokal vor dem Upload, und PBS sieht immer nur das bereits verschlüsselte Ergebnis. Ein PBS-Administrator - oder jeder, der Zugriff auf den Datenspeicher hat - kann die KeyRecovery-Datei herunterladen, aber ohne die Wiederherstellungspassphrase können sie die Keyfile nicht lesen: Es ist undurchsichtiger Geheimtext. Das Rekonstruieren der Keyfile erfordert beide Teile gleichzeitig, die KeyRecovery-Datei und die Passphrase, und nur der Operator hält beide.",
|
||||
"blobUploadConstraintTitle": "Warum zwei Gruppen statt einer einzigen verschlüsselten",
|
||||
@@ -73,7 +73,7 @@
|
||||
"recoverTitle": "Wiederherstellung auf einem neu installierten Host",
|
||||
"recoverBody": "Fehlt die lokale Schlüsseldatei am kanonischen Pfad, etwa nach einer Neuinstallation oder ausdrücklichem Löschen, versucht die Wiederherstellung drei Quellen der Reihe nach und stoppt bei der ersten brauchbaren Schlüsseldatei. Erstens wird eine zum gewählten PBS-Repository passende, von PVE verwaltete Datei unter <code>/etc/pve/priv/storage/<NAME>.enc</code> ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe <code>-keyrecovery</code> vorhanden ist, deren neuester Snapshot heruntergeladen und die Wiederherstellungspassphrase zum Entschlüsseln abgefragt. Funktioniert beides nicht oder lehnt der Betreiber die Optionen ab, fragt der dritte Schritt nach dem absoluten Pfad der Schlüsseldatei auf diesem Host und kopiert sie an den kanonischen Pfad. Der Monitor bietet denselben Importablauf im Backup-Detaildialog. Oben erscheint ein gelbes Feld, wenn Wiederherstellen, Herunterladen oder Inhalt anzeigen eine nicht installierte Schlüsseldatei benötigen. Ist eine Datei installiert, passt aber nicht zum Backup, meldet PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Dieselben drei Aktionen zeigen dann ein strukturiertes gelbes Feld mit dem erforderlichen Manifest-Fingerabdruck an, damit der Betreiber die passende Schlüsseldatei für dieses Backup erkennen und importieren kann.",
|
||||
"monitorManagementTitle": "Schlüsseldatei im Monitor verwalten",
|
||||
"monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung direkt in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Es gibt drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Datei in den Browser des Betreibers; <em>Hochladen</em> ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; <em>Löschen</em> entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Jede Aktion nutzt dieselben Flask-Endpunkte wie die Terminaloberfläche. Die Wirkung auf Dateien und den PBS-Zustand ist deshalb bei beiden Oberflächen identisch."
|
||||
"monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Die Zeile bietet drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Schlüsseldatei in den Browser des Benutzers, <em>Hochladen</em> ersetzt die installierte Schlüsseldatei durch eine vom Benutzer bereitgestellte (die bisherige Datei wird erst überschrieben, nachdem die neue korrekt an ihrem Pfad angekommen ist), und <em>Löschen</em> entfernt die Schlüsseldatei vom Host. Direkt daneben befindet sich der Schalter für die Wiederherstellungshülle: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, ein Passphrase-Feld, das bei Auswahl von Ja erscheint, und eine Schaltfläche, die dem aktuellen Zustand folgt: <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Die Steuerelemente im Monitor und der Dialog in der Shell führen im Hintergrund dasselbe aus, sodass das Ergebnis auf dem Datenträger und auf PBS identisch ist, unabhängig davon, welches von beiden verwendet wird."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Abruf auf der Wiederherstellungsseite",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validierung des Schemas",
|
||||
"schemaBody": "Das Manifest bestätigt gegen <code>scripts/backup_restore/schema/manifest.schema.json</code>. Das Ausführen von <code>build_manifest.sh --validate</code> löst eine Python-seitige JSON-Schemavalidierung aus (erfordert <code>python3</code> + <code>jsonschema</code>). Wenn das Modul nicht vorhanden ist, wird die Überprüfung still übersprungen - die Validierung ist in erster Linie eine Entwicklerhilfe, keine Laufzeitabhängigkeit."
|
||||
"schemaBody": "ProxMenux liefert eine Vorlage mit, die beschreibt, welche Felder das Manifest enthalten muss und welche Form jedes Feld hat. Beim Erstellen eines Backups kann das Manifest automatisch mit dieser Vorlage abgeglichen werden, sodass ein Collector, der fehlerhaftes JSON oder ein falsch geschriebenes Feld erzeugt hat, sofort erkannt wird. Die Prüfung ist für die Entwicklung von ProxMenux selbst gedacht: Auf einem System, auf dem sie nicht installiert ist, funktioniert das Backup wie gewohnt, und das Manifest wird trotzdem erzeugt."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "Das Anwendungsinventar",
|
||||
|
||||
@@ -127,7 +127,7 @@
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Benachrichtigungen",
|
||||
"body": "Jeder geplante Lauf feuert die gleichen <code>hb_notify_lifecycle</code>-Ereignisse ab wie der interaktive Fluss (<code>start</code>, <code>complete</code>, <code>fail</code>). Wenn Benachrichtigungskanäle im Monitor konfiguriert sind, tauchen unbeaufsichtigte Jobs auf die gleiche Weise wie manuelle Backups auf - ein Benutzer muss das Protokoll nicht überprüfen, um zu wissen, ob ein Job erfolgreich war."
|
||||
"body": "Jeder geplante Lauf löst dieselben <code>hb_notify_lifecycle</code>-Ereignisse aus wie der interaktive Ablauf (<code>start</code>, <code>complete</code>, <code>fail</code>). Sind im Monitor Benachrichtigungskanäle konfiguriert, melden unbeaufsichtigte Jobs ihre Ergebnisse auf die gleiche Weise wie manuelle Backups – ein Benutzer muss das Protokoll nicht prüfen, um zu wissen, ob ein Job erfolgreich war."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
|
||||
@@ -105,7 +105,7 @@
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Der Renderknoten, <code>/dev/kfd</code> und die Generation, die der Compute-Treiber in <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code> 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 (<code>HSA_OVERRIDE_GFX_VERSION</code>), 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 (<code>HSA_OVERRIDE_GFX_VERSION</code>), 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",
|
||||
|
||||
@@ -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 (<code>net1</code>) und die Startreihenfolge (<code>startup</code>) 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."
|
||||
]
|
||||
}
|
||||
|
||||
@@ -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 <code>local-lvm</code>. 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 <code>vm-VMID-disk-N</code> und wird als <code>mpN</code> 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 <code>vm-VMID-disk-N</code> und wird als <code>mpN</code> 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 <code>/mnt/pve</code> 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."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Gemeinschaftsskripte",
|
||||
"body": "Das Menü bietet zwei Drittanbieterskripte aus dem Projekt <a>community-scripts</a>: <em>Proxmox VE Post Install</em> und <em>Proxmox VE Microcode</em>. Die Wrapper laden die Originalskripte mit <code>wget | bash</code> herunter und führen sie aus. ProxMenux pflegt sie nicht. Lesen Sie vor der Ausführung <link>Externe Repositories</link> 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 <strong>Einstellungen nach der Installation von Proxmox</strong> im PBS-Menü. Automatisiert, Anpassbar, Verfügbare Updates anwenden und Optimierungen deinstallieren funktionieren wie unter Proxmox VE, mit diesen Unterschieden:",
|
||||
"items": [
|
||||
"<strong>Repositories und Upgrade:</strong> 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 <em>Administration > Repositories</em>. Mit aktivem Abonnement oder bereits eingerichtetem No-Subscription- oder Test-Repository bleiben die Quellen unverändert.",
|
||||
"<strong>Anpassbare Liste:</strong> 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.",
|
||||
"<strong>Abonnement-Hinweis:</strong> Der Patch gilt für die Weboberfläche von Proxmox Backup Server, und Optimierungen deinstallieren stellt sie wieder her.",
|
||||
"<strong>Figurine:</strong> wird ohne die Proxmox-VE-Aliase installiert.",
|
||||
"<strong>Community-Skripte:</strong> Der Abschnitt bietet <em>Proxmox Backup Server Post Install</em> und <em>Proxmox Backup Server Microcode</em> anstelle der Proxmox-VE-Skripte an."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
|
||||
Reference in New Issue
Block a user