mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +00:00
docs: review backup and restore documentation in all seven translations
This commit is contained in:
Jonatan
@@ -0,0 +1,234 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Borg-Ziel — Repository-Typen, SSH-Authentifizierung, Verschlüsselung | ProxMenux",
|
||||
"description": "Das Borg-Ziel speichert ProxMenux-Host-Backups in einem Borg-Repository: lokal, auf einem eingehängten externen Datenträger oder auf einem per SSH erreichbaren Server. Beschrieben werden die Suche nach der ausführbaren borg-Datei, die vier anfänglichen SSH-Schlüsseloptionen, repokey-Verschlüsselung, gespeicherte Ziele und Aufbewahrungsregeln je geplantem Auftrag.",
|
||||
"ogTitle": "ProxMenux Backup — Zielort Borg",
|
||||
"ogDescription": "So speichert ProxMenux Host-Backups in Borg-Repositories mit SSH-Authentifizierung und repokey-Verschlüsselung.",
|
||||
"twitterTitle": "Borg Backup Ziel | ProxMenux",
|
||||
"twitterDescription": "Lokale, USB- und SSH-gestützte Borg-Repositories für Host-Backups."
|
||||
},
|
||||
"header": {
|
||||
"title": "Borg",
|
||||
"description": "Das Borg-Ziel schreibt Host-Backups in ein Borg-Repository. Es werden drei Repository-Typen unterstützt: lokaler Dateisystempfad, eingehängte externe Festplatte oder Remote-Server über SSH. Chunk-Level-Deduplizierung über alle Archive im Repository und optionale Repokey-Verschlüsselung.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"aboutBorg": {
|
||||
"heading": "Was Borg ist",
|
||||
"body": "Borg (auch BorgBackup geschrieben) ist ein Open-Source-Deduplizierungs-Backup-Tool, das von der Borg Backup-Community verwaltet wird. Es speichert jedes Archiv als eine Reihe von Blöcken variabler Länge in einem Repository; Blöcke werden über Archive hinweg geteilt, so dass das erneute Sichern unveränderter Daten nahezu Null Speicherkosten verursacht. Borg ist nicht an Proxmox gebunden - es ist ein universelles Backup-Tool, das in vielen Umgebungen verwendet wird. ProxMenux verwendet es als eines der drei Ziele für Host-Backups; jeder auf dieser Seite beschriebene Borg-spezifische Mechanismus (Repository-Typen, borg-serve über SSH, Repokey-Verschlüsselung, prune) ist Standard-Borg-Verhalten."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Chunk-basierte Deduplizierung mit lokalen oder SSH-servierten Repositorys",
|
||||
"body": "Ein Borg-Repository speichert Brocken, die in jedem enthaltenen Archiv geteilt werden, so dass das erneute Sichern einer unveränderten Datei nichts Neues überträgt und speichert. ProxMenux ruft <code>borg create</code> zum Backup-Zeitpunkt und <code>borg extract</code> zum Wiederherstellungszeitpunkt gegen ein Repository auf. Das Repository kann auf demselben Dateisystem wie die Quelle, auf einer montierten externen Festplatte oder auf einem Remote-Host, auf den über SSH zugegriffen wird, leben."
|
||||
},
|
||||
"binarySourcing": {
|
||||
"heading": "Die ausführbare borg-Datei",
|
||||
"intro": "Borg ist keine Basisabhängigkeit des ProxMenux-Installationsprogramms. Wenn ein Backup ausgeführt wird, löst <code>hb_ensure_borg</code> die Binärdatei in der Reihenfolge aus vier Quellen auf und gibt die erste zurück, die funktioniert:",
|
||||
"rows": [
|
||||
{
|
||||
"priority": "1",
|
||||
"source": "Systemweites <code>borg</code>",
|
||||
"detail": "Wenn der Host bereits <code>borg</code> über APT installiert hat (<code>which borg</code> löst auf), wird diese Binärdatei verwendet."
|
||||
},
|
||||
{
|
||||
"priority": "2",
|
||||
"source": "State-Dir-Cache",
|
||||
"detail": "<code>/usr/local/share/proxmenux/borg</code> — aus einem früheren GitHub-Download auf diesem Host aufbewahrt."
|
||||
},
|
||||
{
|
||||
"priority": "3",
|
||||
"source": "AppImage-Paket des Monitors",
|
||||
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — der AppImage bündelt einen signierten borg-linux64. Dies ist der offline-sichere Pfad: Ein Host ohne Internet hat immer noch einen funktionierenden <code>borg</code>."
|
||||
},
|
||||
{
|
||||
"priority": "4",
|
||||
"source": "GitHub Download",
|
||||
"detail": "<code>wget</code> gegen die angepinnte <code>borg-linux64</code>-URL unter <code>github.com/borgbackup/borg/releases/</code>, verifiziert gegen eine Konstante SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Bei Checksummenfehlanpassung wird die Binärdatei verworfen und das Backup abgebrochen. Die heruntergeladene Datei wird im State Dir zwischengespeichert, so dass nachfolgende Backups den Pfad 2 verwenden."
|
||||
}
|
||||
]
|
||||
},
|
||||
"repoTypes": {
|
||||
"heading": "Repository-Typen",
|
||||
"intro": "Der Repository-Typ wird ausgewählt, wenn ein Ziel hinzugefügt wird. Jeder Typ löst sich in einer anderen Repository-URL auf, die Borg versteht.",
|
||||
"rows": [
|
||||
{
|
||||
"type": "remote",
|
||||
"url": "ssh://USER@HOST/RPATH",
|
||||
"detail": "Repository lebt auf einem Remote-Server, auf dem <code>borg serve</code> ausgeführt wird. Erfordert eine SSH-Verbindung zu diesem Server."
|
||||
},
|
||||
{
|
||||
"type": "usb",
|
||||
"url": "/mnt/MOUNTPOINT/borgbackup",
|
||||
"detail": "Repository lebt auf einer montierten externen Festplatte (normalerweise USB). Die Mount wird über <code>hb_prompt_mounted_path</code> aufgelöst, das USB-Partitionen nach Bedarf erkennt, einhängt oder formatiert."
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "Repository lebt in einem lokalen Verzeichnis. Bedeutsam nur, wenn sich das Zielverzeichnis auf einer separaten physischen Festplatte befindet – ein Repository auf derselben Festplatte wie die Quelle schützt vor Operatorfehlern, aber nicht vor Festplattenausfällen."
|
||||
}
|
||||
]
|
||||
},
|
||||
"serverSetup": {
|
||||
"heading": "Vorbereitung des Borg-Servers (Serverseite)",
|
||||
"intro": "Der Repository-Typ <code>remote</code> setzt einen funktionierenden, per SSH erreichbaren Borg-Server voraus. ProxMenux richtet den Server nicht selbst ein; es autorisiert nur einen Schlüssel für ein vorhandenes Konto. Dieser Abschnitt beschreibt, was der Server vor der Verbindung benötigt.",
|
||||
"hostChoicesTitle": "Wo der Server leben kann",
|
||||
"hostChoicesBody": "Jeder Linux-Host mit SSH-Zugang ist qualifiziert. Gemeinsame Setups:",
|
||||
"hostChoicesItems": [
|
||||
"Eine dedizierte NAS- oder Backup-Box (Debian, Ubuntu, TrueNAS SCALE mit einer Shell).",
|
||||
"Ein LXC Container in einem Proxmox Knoten. Kleiner Footprint, isoliert vom Host, der die Backups ausführt.",
|
||||
"Ein anderer Proxmox-Host im selben LAN oder ein VM, der über SSH erreichbar ist."
|
||||
],
|
||||
"lxcWarningTitle": "LXC als Borg-Server",
|
||||
"lxcWarningBody": "Läuft der Borg-Server in einem LXC, benötigt generate-auto zur Schlüsselinstallation ein Konto, das SSH-Passwortanmeldung erlaubt. Ist diese nicht verfügbar, verwenden Sie die manuelle Installation oder generate-pct über den PVE-Host.",
|
||||
"requirementsTitle": "Anforderungen an den Server",
|
||||
"requirementsRows": [
|
||||
{
|
||||
"requirement": "Ausführbare borg-Datei unter <code>/usr/bin/borg</code>",
|
||||
"detail": "Die Zeile <code>command=\"/usr/bin/borg serve ...\"</code>, die ProxMenux in <code>authorized_keys</code> einträgt, verwendet diesen festen Pfad. APT (<code>apt install borgbackup</code>) installiert das Programm dort. Für eine separat installierte Binärdatei ist ein symbolischer Link unter <code>/usr/bin/borg</code> nötig."
|
||||
},
|
||||
{
|
||||
"requirement": "Ein dediziertes Benutzerkonto (normalerweise <code>borg</code>)",
|
||||
"detail": "Besitzt das Repository-Verzeichnis und empfängt eingehende SSH-Verbindungen. Benötigt keinen sudo- oder shell-zugriff - die authorized_keys-linie deaktiviert interaktive shells sowieso."
|
||||
},
|
||||
{
|
||||
"requirement": "Ein beschreibbares Repository Verzeichnis",
|
||||
"detail": "Der vom Betreiber angegebene Pfad ProxMenux (z. B. <code>/backup/borgbackup</code>) muss auf dem Server vorhanden sein und im Besitz des borg-Benutzers sein."
|
||||
},
|
||||
{
|
||||
"requirement": "SSH Daemon akzeptiert den Borg-Benutzer",
|
||||
"detail": "<code>PubkeyAuthentication yes</code> (Standard). Die Passwort-Authentifizierung wird nur für den One-Shot <em>generate-auto</em>-Flow benötigt – nachdem der Schlüssel installiert wurde, kann der Server das Passwort auth vollständig deaktivieren."
|
||||
}
|
||||
],
|
||||
"minimalSetupTitle": "Minimale Server-Einrichtung",
|
||||
"minimalSetupBody": "Auf einem Debian- oder Ubuntu-Borg-Server besteht eine Arbeitsbasislinie aus vier Befehlen als root:",
|
||||
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
|
||||
"minimalSetupNote": "Sind Server und SSH-Passwortanmeldung vorbereitet, installiert <code>generate-auto</code> den Schlüssel über ein Konto mit Schreibzugriff auf die authorized_keys-Datei des borg-Benutzers. Spätere Backups verwenden diesen auf <code>borg serve</code> am konfigurierten Pfad beschränkten Schlüssel. Ohne Passwortanmeldung wird er manuell oder über den PVE-Host installiert."
|
||||
},
|
||||
"sshAuth": {
|
||||
"heading": "SSH-Authentifizierung (Clientseite)",
|
||||
"intro": "Remote-Borg-Repositories sind über SSH zugänglich. Die Verbindung läuft vom ProxMenux-Host zu einem Benutzerkonto auf dem Borg-Server, auf dem <code>borg serve</code> ausgeführt wird. Dieser Benutzer heißt normalerweise <code>borg</code>, NICHT der Admin / Root-Benutzer des Servers - die Befehlszeile borg-serve sperrt die Verbindung zu diesem spezifischen Repository-Pfad (siehe die wichtigsten Strategien unten).",
|
||||
"strategiesTitle": "SSH-Schlüsselstrategien",
|
||||
"strategiesIntro": "Beim Hinzufügen eines entfernten Ziels fragt ProxMenux nach SSH-Benutzer, Host und entferntem Pfad und bietet vier Anmeldeoptionen. Wird die Passwortanmeldung abgewiesen, steht zusätzlich generate-pct zur Wahl. Die Modi sind unten beschrieben:",
|
||||
"strategyRows": [
|
||||
{
|
||||
"mode": "generate-auto",
|
||||
"label": "Empfohlen",
|
||||
"detail": "ProxMenux erzeugt oder verwendet ein ed25519-Schlüsselpaar unter <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>. Mit <code>sshpass</code> prüft es die Anmeldung und installiert den öffentlichen Schlüssel in <code>~borg/.ssh/authorized_keys</code>. Das Passwort gehört zu einem Konto mit Schreibzugriff auf diese Datei, meist root oder borg. Es wird nur bei der Einrichtung verwendet und nicht gespeichert."
|
||||
},
|
||||
{
|
||||
"mode": "generate-manual",
|
||||
"label": "Kein Admin-Passwort auf diesem Host",
|
||||
"detail": "ProxMenux generiert das Keypair wie oben, zeigt aber die vollständige <code>authorized_keys</code>-Zeile an, die der Betreiber manuell in den Server einfügen kann. Das Admin-Passwort verlässt niemals den ProxMenux-Host, weil es nie angefordert wird."
|
||||
},
|
||||
{
|
||||
"mode": "generate-pct",
|
||||
"label": "Borg Server ist ein PVE LXC",
|
||||
"detail": "Der Borg-Server läuft innerhalb eines LXC auf einem PVE-Knoten. ProxMenux autorisiert den Schlüssel über <code>pct exec</code> vom PVE-Host - root auf dem PVE-Host schreibt in den <code>~borg/.ssh/authorized_keys</code> des LXC, ohne dass SSH selbst in den LXC benötigt wird."
|
||||
},
|
||||
{
|
||||
"mode": "existing",
|
||||
"label": "Verwenden Sie einen vorhandenen Schlüssel",
|
||||
"detail": "ProxMenux scannt <code>/root/.ssh/</code> und <code>$HOME/.ssh/</code> nach Parseable ed25519/RSA Private Keys und listet diese auf. Der Bediener wählt einen oder durchsucht manuell einen nicht standardmäßigen Pfad."
|
||||
},
|
||||
{
|
||||
"mode": "none",
|
||||
"label": "Standard SSH-Konfiguration",
|
||||
"detail": "Kein benutzerdefinierter Schlüssel - Borg stützt sich auf die standardmäßige SSH-Konfiguration des Hosts (normalerweise <code>~/.ssh/id_rsa</code> oder ein SSH-Agent)."
|
||||
}
|
||||
],
|
||||
"restrictTitle": "Die authorized_keys Linie",
|
||||
"restrictBody": "Für jeden erzeugten Schlüssel beschränkt die von ProxMenux auf dem Server eingetragene <code>authorized_keys</code>-Zeile den Zugriff auf den folgenden borg-serve-Aufruf für den konfigurierten Repository-Pfad:",
|
||||
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
|
||||
"restrictNote": "Der <code>command=</code> zwingt jede SSH-Sitzung mit diesem Schlüssel, nur den Befehl borg-serve auszuführen; <code>restrict</code> deaktiviert die Portweiterleitung, die Agentenweiterleitung, die X11-Weiterleitung und die PTY-Zuweisung. Der Schlüssel kann nicht verwendet werden, um eine interaktive Shell auf dem Server zu öffnen oder auf einen anderen Repository-Pfad zuzugreifen, selbst wenn das Konto über breitere Privilegien verfügt."
|
||||
},
|
||||
"savedTargets": {
|
||||
"heading": "Gespeicherte Ziele",
|
||||
"intro": "Ein gespeichertes Ziel hält die Repository-Konfiguration unter einem verständlichen Namen fest, damit die Angaben nicht erneut eingegeben werden müssen. Dateien im ProxMenux-Zustandsverzeichnis:",
|
||||
"rows": [
|
||||
{
|
||||
"file": "borg-targets.txt",
|
||||
"content": "Eine Zeile je Ziel: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> liest sie ein, um das Zielauswahlmenü zu füllen."
|
||||
},
|
||||
{
|
||||
"file": "borg-pass-NAME.txt",
|
||||
"content": "Passphrase des oben mit NAME benannten Ziels (<code>chmod 600</code>). Nur bei gewählter repokey-Verschlüsselung vorhanden."
|
||||
}
|
||||
],
|
||||
"outro": "Das Speichern des Ziels ist optional. Bei Ablehnung wird keine benannte Zielkonfiguration gespeichert; ein erzeugter SSH-Schlüssel wird jedoch nicht entfernt. Bei repokey-Verschlüsselung ohne gespeichertes Ziel legt ProxMenux die Passphrase weiterhin in der älteren Datei borg-pass.txt ab."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Verschlüsselung",
|
||||
"body": "Repositories werden mit einem Verschlüsselungsmodus über <code>hb_borg_init_if_needed</code> initialisiert: das moderne <code>borg repo-create -e MODE</code>, wenn verfügbar, oder das alte <code>borg init --encryption=MODE</code>. ProxMenux zeigt zwei Modi: <code>repokey</code> (Standard) und <code>none</code>. Im <code>repokey</code>-Modus speichert Borg den Verschlüsselungsschlüssel im Repository selbst; der Zugriff erfordert eine Passphrase, die ProxMenux zweimal mit Übereinstimmungsvalidierung anfordert und für gespeicherte Ziele unter <code>borg-pass-NAME.txt</code> speichert, sonst in der oben beschriebenen älteren Datei. Ein obligatorischer Bestätigungsdialog wird angezeigt, nachdem die Passphrase gespeichert wurde: Die Passphrase ist die einzige Möglichkeit, auf die verschlüsselten Archive zuzugreifen, und wenn sie verloren geht, ist jedes Archiv im Repository nicht wiederherstellbar."
|
||||
},
|
||||
"runtimeEnv": {
|
||||
"heading": "Laufzeitumgebung",
|
||||
"intro": "ProxMenux exportiert die folgenden Umgebungsvariablen, bevor <code>borg</code> aufgerufen wird. Sie konfigurieren die Verbindung und entsperren das Repository, ohne Geheimnisse in die Kommandozeile einzubetten.",
|
||||
"rows": [
|
||||
{
|
||||
"var": "BORG_RSH",
|
||||
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
|
||||
"purpose": "Remote-Shell-Befehl für Borg-Repositories über SSH. Ein gewählter Schlüssel ergänzt die Identitätsoptionen, ein abweichender Port ergänzt -p PORT. Ohne eigenen Schlüssel und mit Standardport bleibt die Variable ungesetzt; Borg nutzt dann die SSH-Vorgaben des Hosts."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
"value": "(Passphrase von borg-pass-NAME.txt)",
|
||||
"purpose": "Entsperrt den Repokey. Setzen Sie nur, wenn das Ziel <code>repokey</code>-Verschlüsselung verwendet. Erscheint nie in der Prozessargumentenliste."
|
||||
},
|
||||
{
|
||||
"var": "BORG_ENCRYPT_MODE",
|
||||
"value": "repokey | none",
|
||||
"purpose": "Wird von <code>hb_borg_init_if_needed</code> bei der Initialisierung eines noch nicht vorhandenen Repositorys verwendet. Ignoriert von <code>borg create</code> auf bestehenden Repositories."
|
||||
},
|
||||
{
|
||||
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Unterdrückt die interaktive Eingabeaufforderung, die Borg aufruft, wenn die Repository-URL von der URL abweicht, von der sie ursprünglich erreicht wurde (üblich nach einem Rename für einen Mount-Point oder SSH-Host, der über eine neue Adresse erreichbar ist)."
|
||||
},
|
||||
{
|
||||
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Unterdrückt die interaktive Eingabeaufforderung, die Borg beim ersten Zugriff auf ein unverschlüsseltes Repository von einem neuen Client aus erstellt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Bezeichnung und Aufbewahrung des Archivs",
|
||||
"intro": "Jedes Backup erstellt ein neues Archiv im Repository.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
|
||||
"retentionBody": "Für geplante Aufträge führt <code>run_scheduled_backup.sh</code> <code>borg prune</code> nach jedem erfolgreichen Backup mit den für den Auftrag konfigurierten Retentionswerten (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>) gegen das Repository aus. Interaktive Backups beschneiden nicht."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Abruf auf der Wiederherstellungsseite",
|
||||
"body": "Die Wiederherstellung listet Archive mit <code>borg list REPO</code> auf und entpackt das gewählte Archiv mit <code>borg extract REPO::ARCHIVE-NAME</code> in ein Vorbereitungsverzeichnis. <code>_rs_check_layout</code> übergibt dieses an den normalen Wiederherstellungsablauf. Dieselben Befehle funktionieren auch manuell außerhalb von ProxMenux. Der entpackte Verzeichnisbaum entspricht der in <em>So funktioniert es</em> beschriebenen Struktur aus drei Datenblöcken."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenzen",
|
||||
"intro": "Offizielle Borg-Dokumentation zu den Komponenten, auf die ProxMenux aufbaut.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Borg-Dokumentation",
|
||||
"href": "https://borgbackup.readthedocs.io/",
|
||||
"tail": "— Haupteinstiegspunkt für Konzepte, Bereitstellung, Schnellstart und jeden Befehl."
|
||||
},
|
||||
{
|
||||
"label": "borg create",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
|
||||
"tail": " — der Befehl, den ProxMenux für jedes Backup aufruft, mit allen unterstützten Optionen."
|
||||
},
|
||||
{
|
||||
"label": "Datenspeicherverschlüsselung",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
|
||||
"tail": "- die Verschlüsselungsmodi, die Borg unterstützt, einschließlich Repokey, den ProxMenux standardmäßig verwendet."
|
||||
},
|
||||
{
|
||||
"label": "borg serve und Bereitstellung über SSH",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
|
||||
"tail": " - wie man einen zentralen Borg-Server einrichtet, auf den über SSH zugegriffen wird, einschließlich des borg-serve-Befehls und des restrict-to-path-Flags ProxMenux schreibt in authorized_keys."
|
||||
},
|
||||
{
|
||||
"label": "borg prune",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
|
||||
"tail": "— das Retentionsmodell hinter --keep-last / --keep-daily / --keep-weekly, das ProxMenux pro geplantem Auftrag anwendet."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Backup-Ziele — Lokal, Proxmox Backup Server, Borg | ProxMenux",
|
||||
"description": "Drei Storage-Backends erhalten die gleiche ProxMenux Backup-Nutzlast: ein lokales .tar.zst-Archiv auf jedem beschreibbaren Dateisystem, ein PBS-Backup in einem Proxmox Backup Server-Datenspeicher oder ein Borg-Archiv in einem lokalen oder entfernten Borg-Repository. Jedes Backend hat seine eigenen Kompressions-, Deduplizierungs-, Verschlüsselungs- und Netzwerkeigenschaften.",
|
||||
"ogTitle": "ProxMenux Backup-Ziele",
|
||||
"ogDescription": "Local, Proxmox Backup Server und Borg – drei Storage-Backends für die gleiche Host-Backup-Nutzlast.",
|
||||
"twitterTitle": "ProxMenux Backup Ziele | ProxMenux",
|
||||
"twitterDescription": "Lokales Archiv, Proxmox Backup Server und Borg Backends für Host-Backups."
|
||||
},
|
||||
"header": {
|
||||
"title": "Ziele",
|
||||
"description": "Drei Storage Backends, die von ProxMenux Backup unterstützt werden: lokales Archiv, Proxmox Backup Server (empfohlen) und Borg. Jeder erhält das gleiche Drei-Nutzlast-Archiv; sie unterscheiden sich in Speicherformat, Deduplizierung, Verschlüsselungsmodell und Netzwerkanforderungen.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Gleiche Nutzlast, drei Backends",
|
||||
"body": "Jedes Backup erzeugt die gleichen drei Nutzlasten (Rootfs, Manifest, Anwendungen). Was sich zwischen Zielen ändert, ist, wie diese Nutzlasten gespeichert werden und wie der Betreiber sie für eine Wiederherstellung abruft. Jedes Backend wird als separate Funktion in <code>backup_host.sh</code> - <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> - implementiert, aber alle drei haben den gleichen Staging-Schritt (<code>hb_prepare_staging</code>) und den gleichen Wiederherstellungscodepfad. Die Wahl des Ziels betrifft nur das Schreiben und den Abruf; es ändert nicht, was eine Wiederherstellung tut oder wie sie das Archiv verbraucht."
|
||||
},
|
||||
"comparison": {
|
||||
"heading": "Merkmalsvergleich",
|
||||
"intro": "Die folgende Tabelle listet die konkreten Unterschiede zwischen den drei Backends auf, wie sie sich heute in ProxMenux verhalten. Alle Werte beschreiben das beobachtete Verhalten des Backends selbst, nicht redaktionelle Empfehlungen.",
|
||||
"rows": [
|
||||
{
|
||||
"feature": "Speicherformat",
|
||||
"local": "Einzelne <code>.tar.zst</code>-Datei (oder <code>.tar.gz</code>, wenn <code>zstd</code> fehlt).",
|
||||
"pbs": "PBS Backup (<code>.pxar</code> Chunks im Datenspeicher).",
|
||||
"borg": "Borg-Archiv in einem Borg-Repository (Segmentdateien)."
|
||||
},
|
||||
{
|
||||
"feature": "Kompression",
|
||||
"local": "zstd (Standardstufe) über <code>tar --zstd</code>. gzip Fallback.",
|
||||
"pbs": "Von proxmox-backup-client verwaltet. ProxMenux überschreibt die Kompressionseinstellungen nicht.",
|
||||
"borg": "In Borg integrierte Kompression. ProxMenux ruft borg create auf, ohne die Kompressionseinstellungen zu überschreiben."
|
||||
},
|
||||
{
|
||||
"feature": "Deduplizierung",
|
||||
"local": "Keine. Jedes Backup ist ein vollständiges unabhängiges Archiv.",
|
||||
"pbs": "Vollständige Chunk-Level-Deduplizierung über alle Backups im Datenspeicher.",
|
||||
"borg": "Vollständige Chunk-Level-Deduplizierung über alle Archive im Repository."
|
||||
},
|
||||
{
|
||||
"feature": "Verschlüsselung im Ruhezustand",
|
||||
"local": "Keine (Verlässt sich auf den Schutz auf Dateisystemebene).",
|
||||
"pbs": "Optionale clientseitige Keyfile-Verschlüsselung. Recovery-Blob als separate Backup-Gruppe hochgeladen, wenn aktiviert.",
|
||||
"borg": "Optionale Repokey-Verschlüsselung (Schlüssel im Repo gespeichert, durch eine Passphrase freigeschaltet)."
|
||||
},
|
||||
{
|
||||
"feature": "Aufbewahrung / Bereinigung",
|
||||
"local": "Wird pro geplantem Auftrag über <code>KEEP_LAST</code> angewendet. Alte Archive werden zusammen mit ihren Begleitdateien und Ausführungsprotokollen gelöscht. Interaktive Backups führen keine Bereinigung aus.",
|
||||
"pbs": "Angewendet pro geplanten Auftrag über <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktive Backups führen keine Bereinigung aus.",
|
||||
"borg": "Angewendet pro geplanten Auftrag über <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktive Backups führen keine Bereinigung aus."
|
||||
},
|
||||
{
|
||||
"feature": "Netzwerk",
|
||||
"local": "Keine. Schreibt auf einen lokalen Einhängepunkt (normalerweise eine interne Festplatte oder ein USB-Laufwerk).",
|
||||
"pbs": "TCP auf den PBS-Server (Standardport 8007). Erfordert PBS Anmeldeinformationen + Fingerabdruck.",
|
||||
"borg": "Lokaler Dateisystempfad oder SSH Tunnel zu einem entfernten Borg-Host."
|
||||
},
|
||||
{
|
||||
"feature": "Abhängigkeiten",
|
||||
"local": "<code>tar</code>, <code>zstd</code> (standardmäßig auf Proxmox vorhanden).",
|
||||
"pbs": "<code>proxmox-backup-client</code> Paket (gebündelt mit Proxmox VE 8+).",
|
||||
"borg": "<code>borg</code> binär. Automatische Bereitstellung durch ProxMenux aus dem Monitor AppImage-Bundle, wenn es fehlt."
|
||||
},
|
||||
{
|
||||
"feature": "Zugriff für die Wiederherstellung",
|
||||
"local": "Jeder Host mit tar+zstd kann das Archiv extrahieren. Keine PBS/Borg erforderlich.",
|
||||
"pbs": "Erfordert <code>proxmox-backup-client</code> + PBS Anmeldeinformationen + die Schlüsseldatei (falls verschlüsselt).",
|
||||
"borg": "Erfordert <code>borg</code> + den Repository-Pfad + die Passphrase (falls verschlüsselt)."
|
||||
}
|
||||
],
|
||||
"captionCode": "feature",
|
||||
"captionLocal": "Lokal",
|
||||
"captionPbs": "Proxmox Backup Server (empfohlen)",
|
||||
"captionBorg": "Borg"
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extrahieren eines Backups außerhalb von ProxMenux",
|
||||
"intro": "Jedes der drei Archivformate kann mit Standardtools gelesen werden, ohne dass ProxMenux auf dem Lesehost installiert ist. Die folgenden Befehle erzeugen den gleichen Verzeichnisbaum, den eine Wiederherstellung intern verbraucht.",
|
||||
"localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
|
||||
"pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n --repository USER@REALM@HOST:DATASTORE \\\n host/hostcfg-HOST/BACKUP-TIME \\\n hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
|
||||
"borgCmd": "# Aus einem Borg-Archiv (benötigt borg und bei verschlüsselten Repositories die Passphrase):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Bei einem über SSH erreichbaren entfernten Repository:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
|
||||
"note": "Der extrahierte Baum kann dann manuell inspiziert oder einer manuellen Wiederherstellung zugeführt werden. Sehen Sie sich die einzelnen Zielseiten für den genauen Abruffluss an, den ProxMenux unter der Haube verwendet."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Details je Ziel",
|
||||
"intro": "Jedes Ziel hat eine eigene Seite, die den Konfigurationsfluss, das On-Disk-Format und den von der Wiederherstellung verwendeten Abrufbefehl abdeckt.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Lokales Archiv",
|
||||
"href": "/docs/backup-restore/destinations/local",
|
||||
"tail": " — Vorkonfiguration eines lokalen Ziels, Einhängen von USB-Laufwerken, Schutz vor dem Einschließen des Archivs in sich selbst und die JSON-Begleitdatei zur Erkennung im Monitor."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox Backup Server (empfohlen)",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "Datenspeicherauswahl, Anmeldeinformationen und Fingerabdruck, Verschlüsselungs-Keyfile-Lebenszyklus, Recovery-Passphrase, Hochladen des Recovery-Blobs zu PBS für die Wiederherstellung mit frischer Installation."
|
||||
},
|
||||
{
|
||||
"label": "Borg",
|
||||
"href": "/docs/backup-restore/destinations/borg",
|
||||
"tail": " — lokale und über SSH erreichbare Repositories, Bezugsquellen der Borg-Binärdatei (System / Cache / Monitor-AppImage-Bundle / GitHub-Download), Repository-Initialisierung, Umgang mit Passphrasen und SSH-Schlüssel für entfernte Repositories."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,75 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Lokales Archivziel — tar.zst auf einem Dateisystem oder USB-Laufwerk | ProxMenux",
|
||||
"description": "Das lokale Sicherungsziel schreibt ein einzelnes .tar.zst-Archiv in ein beliebiges beschreibbares Verzeichnis: auf eine interne Festplatte, einen Proxmox-Mountpoint, eine NFS-Freigabe oder ein USB-Laufwerk. Diese Seite beschreibt die Einrichtung, das Erkennen und Einbinden von USB-Laufwerken, den Schutz vor dem Speichern des Archivs in einem selbst gesicherten Pfad und die zugehörige JSON-Datei zur Identifizierung der Sicherung.",
|
||||
"ogTitle": "ProxMenux Backup — Ziel des lokalen Archivs",
|
||||
"ogDescription": "Wie ProxMenux lokale Backups als .tar.zst-Archive schreibt und wie man das Zielverzeichnis oder das USB-Laufwerk konfiguriert.",
|
||||
"twitterTitle": "Lokales Backup-Ziel | ProxMenux",
|
||||
"twitterDescription": "Wie ProxMenux lokale Backups als .tar.zst-Archive auf ein Dateisystem oder USB-Laufwerk schreibt."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lokales Archiv",
|
||||
"description": "Das lokale Sicherungsziel schreibt ein einzelnes komprimiertes tar-Archiv in ein beliebiges beschreibbares Verzeichnis auf dem Host: auf eine interne Festplatte, einen NFS- oder SMB-Mount oder ein USB-Laufwerk.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Eine Datei, in sich geschlossen",
|
||||
"body": "Ein lokales Backup erzeugt eine einzelne <code>hostcfg-HOST-TIMESTAMP.tar.zst</code>-Datei (oder <code>.tar.gz</code>, wenn <code>zstd</code> fehlt). Die Datei enthält den gesamten Archivbaum <code>manifest.json</code>, <code>metadata/</code> und <code>rootfs/</code> und kann auf jedem Proxmox-Host mit dem ProxMenux-Wiederherstellungsfluss wiederhergestellt oder manuell mit <code>tar --zstd -xf</code> auf jedem Linux-System extrahiert werden. Kein Server, kein Repository init, keine externe Abhängigkeit. Dies ist das Ziel mit dem kürzesten Wiederherstellungspfad, wenn weder PBS noch Borg verfügbar sind."
|
||||
},
|
||||
"targetConfig": {
|
||||
"heading": "Konfiguration des Zielverzeichnisses",
|
||||
"intro": "Das lokale Ziel ist ein <strong>einziges dauerhaft gespeichertes Zielverzeichnis</strong> – keine Liste. ProxMenux speichert die Auswahl des Betreibers bei <code>/usr/local/share/proxmenux/local-target.conf</code> und liest sie bei jedem Backup. Wenn kein Ziel konfiguriert wurde, wird der Standard-<code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> verwendet (das gleiche Verzeichnis, das Proxmox für seine eigenen <code>vzdump</code>-Ausgänge verwendet). Das Ziel wird unter <em>Backup-Ziele konfigurieren → Lokale Ziele</em> konfiguriert:",
|
||||
"options": [
|
||||
"<strong>Standard verwenden (<code>/var/lib/vz/dump</code>).</strong> Der lokale Proxmox-Speicher. Bei jeder Proxmox-Installation vorhanden; das Archiv befindet sich neben den vzdump-Ausgaben und wird automatisch von der Registerkarte Backups des Monitors aufgenommen.",
|
||||
"<strong>Benutzerdefinierten Pfad eingeben.</strong> Jeder absolute Dateisystempfad kann verwendet werden: ein NFS-Mount, eine über <code>fstab</code> eingebundene SMB-Freigabe, ein eigenes ZFS-Dataset oder eine zweite interne Festplatte. ProxMenux prüft vor dem Speichern, ob der Pfad existiert und ein Verzeichnis ist.",
|
||||
"<strong>Wählen Sie ein USB-Laufwerk.</strong> Öffnet das USB-Untermenü (unten), das Wechselgeräte erkennt und ein Gerät montieren oder formatieren kann."
|
||||
]
|
||||
},
|
||||
"usbFlow": {
|
||||
"heading": "USB-Laufwerkerkennung und -montage",
|
||||
"intro": "Das USB-Untermenü listet Partitionen auf Wechselgeräten auf, die von <code>lsblk</code> gemeldet werden. Jede Partition wird mit ihrer Größe, Dateisystem-Beschriftung und aktuellem Zustand dargestellt. Der Zustand bestimmt die Aktion, die ProxMenux anbietet.",
|
||||
"statesTitle": "Die drei Gerätezustände",
|
||||
"stateRows": [
|
||||
{
|
||||
"state": "eingehängt",
|
||||
"shown": "Größe · Etikett · [fstype] · → /mount/point",
|
||||
"action": "Die Partition ist bereits irgendwo montiert. Bei der Auswahl wird der aktuelle Einhängepunkt als lokales Ziel gespeichert. Es wird kein neuer Mount ausgeführt."
|
||||
},
|
||||
{
|
||||
"state": "nicht montiert",
|
||||
"shown": "Größe · Etikett · [fstype] · (nicht montiert — wird montiert)",
|
||||
"action": "Ein Dateisystem ist vorhanden, aber nicht montiert. Bei Bestätigung führt ProxMenux <code>hb_mount_usb_partition</code> aus: erstellt <code>/mnt/backup-LABEL</code> (oder einen UUID-basierten Pfad, wenn kein Label vorhanden ist), mountet die Partition und speichert den Einhängepunkt als lokales Ziel."
|
||||
},
|
||||
{
|
||||
"state": "leer",
|
||||
"shown": "Größe · unformatierter USB-Datenträger — kein Dateisystem (wird FORMATIERT)",
|
||||
"action": "Das Gerät hat kein Dateisystem. Dieser destruktive Vorgang ist durch zwei Bestätigungen geschützt. Zuerst erklärt ein Ja/Nein-Dialog, dass der Datenträger gelöscht wird. Anschließend muss der Benutzer in einem Eingabefeld <strong>den exakten Gerätepfad eingeben</strong> (z. B. <code>/dev/sdb</code>), bevor ProxMenux eine neue GPT mit ext4-Partition erstellt und diese einhängt."
|
||||
}
|
||||
],
|
||||
"notMountedFallback": "Wenn kein USB-Gerät erkannt wird, fällt das Untermenü auf eine einfache Eingabebox zurück. Der Bediener kann einen beliebigen Einhängepunktpfad eingeben; wenn der Pfad kein registrierter Einhängepunkt ist, warnt ein Bestätigungsdialog, bevor er fortfährt."
|
||||
},
|
||||
"safetyCheck": {
|
||||
"heading": "Sicherheitsprüfung — Ziel innerhalb eines gesicherten Pfads",
|
||||
"body": "Vor dem Schreiben des Archivs überprüft <code>_bk_local</code>, dass das Zielverzeichnis <strong>nicht</strong> ein Unterpfad eines zu sichernden Verzeichnisses ist. Ein häufiger Fehler wäre das Hinzufügen von <code>/root</code> zum Profil und die Auswahl von <code>/root/backups</code> als Ziel – das Archiv würde sich dann selbst einschließen und entweder ein beschädigtes Archiv erzeugen oder unbegrenzt wachsen, bis die Festplatte voll ist. Die Prüfung löst beide Pfade mit <code>readlink -m</code> auf, vergleicht sie und bricht bei einem Konflikt die Sicherung mit einem Dialogfeld ab, das den in Konflikt stehenden Pfad benennt und drei Möglichkeiten zur Lösung auflistet: Wählen Sie ein Ziel außerhalb des in Konflikt stehenden Pfads, entfernen Sie den benutzerdefinierten Eintrag, der das Ziel enthält, oder deaktivieren Sie den in Konflikt stehenden Pfad für diesen Lauf im benutzerdefinierten Modus."
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Archivformat und Komprimierung",
|
||||
"intro": "Der Ausgabedateiname bettet den Quellhostnamen und den Backup-Zeitstempel ein, so dass ein Verzeichnis mit mehreren Archiven chronologisch sortiert und jede Datei sich selbst identifiziert.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
|
||||
"compressionTitle": "Kompression",
|
||||
"compressionBody": "Der primäre Pfad verwendet <code>tar --zstd -cf</code> - eine Single-Command-Pipeline, die auf dem Standardniveau von zstd komprimiert wird. Wenn <code>zstd</code> nicht in der Quelle vorhanden ist (selten bei Proxmox, aber bei minimalen Installationen möglich), fällt ProxMenux auf <code>gzip</code> zurück. Im Fallback-Pfad wird, wenn <code>pv</code> verfügbar ist, ein Fortschrittsbalken zur Pipeline hinzugefügt, so dass der Betreiber die Archivgröße in Echtzeit wachsen sieht; ohne <code>pv</code> wird <code>tar -czf</code> still verwendet.",
|
||||
"sourceTitle": "Was geht ins Archiv",
|
||||
"sourceBody": "Der tar-Befehl wird mit <code>-C \"$staging_root\" .</code> aufgerufen und archiviert dadurch das <strong>gesamte Staging-Hauptverzeichnis</strong>: <code>rootfs/</code>, <code>metadata/</code> und <code>manifest.json</code>. Alle drei Datenblöcke liegen nebeneinander auf der obersten Ebene des tar-Archivs. Beim Entpacken entsteht genau der Baum, den der Wiederherstellungscode verwendet."
|
||||
},
|
||||
"sidecar": {
|
||||
"heading": "Die JSON-Begleitdatei",
|
||||
"intro": "Jedes erfolgreiche lokale Backup erzeugt eine Begleitdatei: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, geschrieben neben dem Archiv von <code>hb_write_archive_sidecar</code>. Diese kleine JSON-Datei ermöglicht es dem ProxMenux Monitor, das Archiv als ProxMenux-Host-Backup zu identifizieren, auch wenn es später an anderer Stelle verschoben, umbenannt oder archiviert wird.",
|
||||
"contentTitle": "Inhalt der Begleitdatei",
|
||||
"contentBody": "Das Sidecar speichert die Schemaversion, ob das Backup von einem interaktiven Lauf oder einem geplanten Job (<code>kind</code>) stammt, die Job-ID für geplante Läufe, den verwendeten Profilmodus (<code>default</code> oder <code>custom</code>), den Quellhostnamen, den ursprünglichen Archivbasisnamen, einen ISO-8601-Erstellungszeitstempel und die Archivgröße in Bytes.",
|
||||
"whyBody": "Die Registerkarte Backups des Monitors scannt konfigurierte lokale Verzeichnisse für <code>*.proxmenux.json</code>-Begleitdateien - nicht für <code>*.tar.zst</code>-Dateien -, da ein <code>.tar.zst</code> ohne Sidecar möglicherweise überhaupt kein ProxMenux-Backup ist. Der Scan ist schnell (JSON-Dateien sind winzig) und die Paarung ist stabil bei Umbenennungen des Archivs, solange das Sidecar entsprechend umbenannt wird."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Wiederherstellen aus einem lokalen Archiv",
|
||||
"body": "Der ProxMenux-Wiederherstellungsfluss entdeckt lokale Archive, indem er das konfigurierte lokale Ziel nach Begleitdateien durchsucht und in der Archivliste anzeigt. Die Auswahl eines Archivs löst <code>_rs_check_layout</code> aus, der den Tarball in ein Staging-Verzeichnis extrahiert und das Layout mit drei Nutzlasten bestätigt, bevor er fortfährt. Für die manuelle Extraktion außerhalb von ProxMenux liefert <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> den gleichen Baum, den der Wiederherstellungscode verbraucht."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Backup Server Zielort — Repository, Verschlüsselung, Wiederherstellung | ProxMenux",
|
||||
"description": "Das PBS-Ziel speichert ProxMenux-Host-Backups als PBS-Backups. Beschrieben werden die Repository-Erkennung aus /etc/pve/storage.cfg, die manuelle PBS-Konfiguration, der .pxar-Upload, die clientseitige Verschlüsselung mit einer Schlüsseldatei samt optionaler passphrasengeschützter Sicherungskopie sowie die Schlüsselwiederherstellung aus mehreren Quellen auf einem neu installierten Host.",
|
||||
"ogTitle": "ProxMenux Backup — Bestimmungsort Proxmox Backup Server",
|
||||
"ogDescription": "So speichert ProxMenux Host-Backups auf Proxmox Backup Server mit clientseitiger Schlüsseldateiverschlüsselung und einer hinterlegten Wiederherstellungskopie.",
|
||||
"twitterTitle": "PBS Backup Ziel | ProxMenux",
|
||||
"twitterDescription": "Proxmox Backup Server als Ziel mit Schlüsseldateiverschlüsselung und passphrasengeschützter Wiederherstellungskopie."
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "Das PBS-Ziel lädt das gesamte Vorbereitungsverzeichnis als ein einzelnes .pxar-Backup in einen Proxmox-Backup-Server-Datenspeicher hoch. Optional wird es clientseitig mit einer Schlüsseldatei verschlüsselt; zusätzlich kann neben jedem Backup eine passphrasengeschützte Wiederherstellungskopie der Schlüsseldatei hinterlegt werden.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"recommendedBadge": "Empfohlenes Ziel",
|
||||
"aboutPbs": {
|
||||
"heading": "Was Proxmox Backup Server ist",
|
||||
"body": "Proxmox Backup Server (PBS) ist das eigene Backup-Server-Produkt von Proxmox, das von dem gleichen Team entwickelt und gewartet wird, das auch Proxmox VE entwickelt hat. Es ist ein dedizierter Backup-Server, der entwickelt wurde, um Backups von Proxmox VE-Hosts (VMs, LXCs und - über <code>proxmox-backup-client</code> - beliebige Host-Verzeichnisse) mit chunkbasierter Deduplizierung, clientseitiger Verschlüsselung und serverseitig angewendeten Aufbewahrungsrichtlinien zu erhalten. ProxMenux verwendet PBS als eines der drei Ziele für Host-Backups; jeder auf dieser Seite beschriebene PBS-spezifische Mechanismus (Backup-Gruppen, <code>.pxar</code>-Archive, <code>--backup-id</code>, Keyfile-Verschlüsselung) ist Standard-PBS-Verhalten."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ein Backup pro Lauf, Chunk-Level-Dedup",
|
||||
"body": "Ein PBS-Backup erzeugt einen einzelnen Backup-Eintrag im Datenspeicher, der unter der Backup-ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code> gruppiert ist. Die Nutzlast ist ein <code>.pxar</code>-Archiv, das das gleiche dreiblockige Layout enthält, das in <em>How it works</em> beschrieben ist. PBS dedupliziert auf der Chunk-Ebene über alle Backups im Datenspeicher, so dass nachfolgende Backups desselben Hosts nur die geänderten Chunks übertragen und speichern. Die Retention wird von ProxMenux selbst für geplante Aufträge angewendet — <code>run_scheduled_backup.sh</code> führt <code>proxmox-backup-client prune</code> mit <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> nach jedem erfolgreichen Lauf mit den für den Auftrag konfigurierten Werten aus."
|
||||
},
|
||||
"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.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "Proxmox storage.cfg (automatisch erkannt)",
|
||||
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
|
||||
"content": "Jede <code>pbs:</code> Strophe in der eigenen Speicherkonfiguration von Proxmox wird automatisch abgeholt. Server, Datenspeicher, Benutzername und Fingerabdruck stammen aus der Strophe. Das Passwort wird aus dem eigenen Anmeldeverzeichnis von Proxmox gelesen. Auf der ProxMenux-Seite ist kein erneuter Eintrag erforderlich – das Repository ist verfügbar, sobald es in Proxmox konfiguriert ist."
|
||||
},
|
||||
{
|
||||
"source": "ProxMenux manuelle Konfiguration",
|
||||
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
|
||||
"content": "Zusätzlich von <em> Backup-Ziele konfigurieren → PBS Ziele → PBS</em> hinzufügen. Prompts für einen Namen, Benutzernamen (<code>root@pam</code> oder <code>user@pbs!token</code>), Host oder IP, Datenspeicher und Passwort. Das Passwort wird bei leeren Eingaben erneut angezeigt - ein leeres Speichern würde ansonsten still bleiben und jedes nachfolgende Backup würde mit einem undurchsichtigen Authentifizierungsfehler fehlschlagen. Dieser Pfad wird verwendet, wenn das Ziel PBS nicht als Proxmox-Speicher registriert ist."
|
||||
}
|
||||
],
|
||||
"menuTitle": "Auswahlmenü",
|
||||
"menuBody": "Beide Quellen werden in einem einzigen Menü angezeigt, wobei jede Zeile mit ihrem Ursprung markiert ist (<code>[proxmox]</code> oder <code>[manual]</code>). Einträge, deren Passwort nicht aufgelöst werden konnte, werden mit einer <code>⚠ no password</code>-Warnung versehen – die Auswahl einer löst einen erneuten Passworteintrag aus, bevor das Backup startet. Der Fingerabdruck wird über die <code>PBS_FINGERPRINT</code>-Umgebungsvariable an <code>proxmox-backup-client</code> übergeben; bei Abwesenheit fordert der Client den Betreiber auf, das Serverzertifikat beim ersten Backup interaktiv zu akzeptieren."
|
||||
},
|
||||
"backupCommand": {
|
||||
"heading": "Der Backup-Befehl",
|
||||
"intro": "Der Upload erfolgt mit einem einzigen Aufruf von <code>proxmox-backup-client backup</code>. ProxMenux übergibt Passwort, Verschlüsselungspasswort und Fingerabdruck mit <code>env</code> als Umgebungsvariablen an den Client.",
|
||||
"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-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."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Clientseitige Verschlüsselung",
|
||||
"glossaryHint": "Dieser Abschnitt verwendet die Begriffe <em>Schlüsseldatei</em>, <em>Passphrase</em> und <em>Wiederherstellungshülle</em>. Das <glosarioLink>Glossar</glosarioLink> erklärt die Unterschiede mit einem Satz pro Begriff.",
|
||||
"intro": "Die clientseitige PBS-Verschlüsselung mit einer Schlüsseldatei verschlüsselt die Blöcke vor dem Upload auf dem Quellhost. In ProxMenux ist die Verschlüsselung optional. Wird sie aktiviert, entscheidet der Betreiber bei der Einrichtung ausdrücklich mit Ja oder Nein, ob zusätzlich eine passphrasengeschützte Wiederherstellungskopie der Schlüsseldatei auf PBS hinterlegt wird; diese Wahl lässt sich später im Monitor ändern. Die Schlüsseldatei selbst liegt immer unter dem kanonischen Pfad <code>/usr/local/share/proxmenux/pbs-key.conf</code> und wird für alle weiteren verschlüsselten Backups ohne erneute Nachfrage verwendet.",
|
||||
"keyfileTitle": "Einrichten der Keyfile",
|
||||
"keyfileBody": "Der Verschlüsselungsdialog erscheint beim ersten verschlüsselten Backup des Hosts. Zunächst wird gefragt, ob das Backup verschlüsselt werden soll: <em>Nein</em> fährt ohne Verschlüsselung fort, <em>Ja</em> führt zum zweiten Schritt. Dieser hängt davon ab, ob bereits eine Schlüsseldatei unter <code>/usr/local/share/proxmenux/pbs-key.conf</code> installiert ist. Falls ja, wird sie ohne Nachfrage wiederverwendet und das Backup fortgesetzt; auch spätere Backups fragen nicht erneut. Andernfalls bietet ein Menü zwei Möglichkeiten. <em>Neue Schlüsseldatei erzeugen</em> führt <code>proxmox-backup-client key create --kdf none</code> aus. <em>Vorhandene Schlüsseldatei verwenden</em> erkennt eine von PVE verwaltete Datei automatisch: Ist das gewählte PBS-Repository in Proxmox mit einem Verschlüsselungsschlüssel unter <code>/etc/pve/priv/storage/<NAME>.enc</code> registriert, wird diese Datei ohne Nachfrage an den kanonischen ProxMenux-Pfad kopiert. Gibt es keine passende PVE-Datei, wird nach dem absoluten Pfad gefragt, unter dem der Betreiber die Schlüsseldatei bereits auf diesem Host abgelegt hat. In beiden Fällen liegt sie danach am kanonischen Pfad mit <code>chmod 600</code>.",
|
||||
"modesTitle": "Schlüsseldatei je Host oder gemeinsam nutzen",
|
||||
"modesIntro": "Beide Betriebsmodelle werden unterstützt und keines wird durchgesetzt - die Wahl liegt beim Betreiber, je nachdem, wie seine Flotte organisiert ist.",
|
||||
"modesPerHostTitle": "Eigene Schlüsseldatei je Host (Standard)",
|
||||
"modesPerHostBody": "Jeder Host generiert seine eigene Schlüsseldatei, wenn er zum ersten Mal die PBS-Verschlüsselung aktiviert. Die Isolation ist maximal: Durch die Kompromittierung der Schlüsseldatei eines Hosts werden die Backups anderer Hosts nicht offengelegt. Empfohlen für Produktionsflotten und für Umgebungen, in denen Hosts unterschiedliche Eigentümer oder Compliance-Grenzen haben.",
|
||||
"modesSharedTitle": "Gemeinsame Keyfile (Import auf jedem Host)",
|
||||
"modesSharedBody": "Eine Hauptschlüsseldatei wird einmal generiert und auf jedem Host über die Option <em>Vorhandene Schlüsseldatei verwenden</em> installiert. Die Verwaltung ist einfacher: Ein einziges Geheimnis muss geschützt werden, und jeder Host kann die Archive jedes anderen entschlüsseln (nützlich für Konsolidierung, hostübergreifende Wiederherstellungsübungen oder zentralisierte Backup-Verifizierung). Der Nachteil besteht darin, dass ein Leck der gemeinsam genutzten Schlüsseldatei jeden Host auf einmal offenlegt. Empfohlen für Homelabs und Flotten, bei denen alle Hosts denselben Eigentümer und dieselbe Vertrauensgrenze haben.",
|
||||
"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.",
|
||||
"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",
|
||||
"blobUploadConstraintBody": "Ein einzelner Aufruf von <code>proxmox-backup-client backup</code> verschlüsselt entweder alle enthaltenen Archive mit derselben Schlüsseldatei oder keines davon. Das Host-Backup muss mit der Host-Schlüsseldatei verschlüsselt werden. Die Wiederherstellungshülle darf aber nicht im selben Upload liegen, sonst würde sie mit genau der Schlüsseldatei verschlüsselt, die sie enthält. Auf einem neu installierten Host ließe sie sich nicht öffnen: Zum Entschlüsseln der Schlüsseldatei wäre diese selbst nötig. Deshalb werden die beiden Artefakte unabhängig hochgeladen und erscheinen als zwei Gruppen. Der PBS-Client verschlüsselt das Host-Backup mit der Schlüsseldatei; ProxMenux verschlüsselt die Wiederherstellungshülle vor dem Upload mit der Passphrase. Zwei verschiedene Verschlüsselungsschichten schützen zwei unterschiedliche Inhalte.",
|
||||
"blobUploadImageAlt": "PBS Benutzeroberfläche zeigt die Backup-Gruppen hostcfg-HOSTNAME und hostcfg-HOSTNAME-keyrecovery angrenzend im Datenspeicher.",
|
||||
"blobUploadImageCaption": "PBS UI — die gepaarten Backup-Gruppen. Die Hauptgruppe hält die Host-Backups; die -keyrecovery-Gruppe hält die passphrase-verpackte Schlüsseldatei.",
|
||||
"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."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Abruf auf der Wiederherstellungsseite",
|
||||
"body": "Der Wiederherstellungsfluss erkennt ProxMenux Host-Backups auf PBS, indem er Backup-Gruppen unter dem konfigurierten Repository auflistet und nach Backup-ID-Muster filtert. Die Registerkarte Backups des Monitors stellt dieselbe Liste dar. Durch das Auswählen eines Backups wird <code>proxmox-backup-client restore</code> mit demselben Repository + Passwort + Fingerabdruck (und <code>--keyfile</code>, als das Backup verschlüsselt wurde) ausgelöst, wodurch das <code>.pxar</code> in ein Staging-Verzeichnis extrahiert wird, das <code>_rs_check_layout</code> dann der Standardwiederherstellungspipeline zuführt. Für das manuelle Abrufen außerhalb von ProxMenux extrahiert derselbe Befehl das Archiv auf einen beliebigen Pfad - der resultierende Baum kann inspiziert oder einer handgesteuerten Wiederherstellung zugeführt werden."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenzen",
|
||||
"intro": "Offizielle Dokumentation von Proxmox Backup Server zu den Komponenten, auf die ProxMenux aufbaut.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Proxmox Backup Server Dokumentation",
|
||||
"href": "https://pbs.proxmox.com/docs/",
|
||||
"tail": "— Haupteinstiegspunkt für Installation, Verwaltung, Speicherung, Benutzer und Rollen."
|
||||
},
|
||||
{
|
||||
"label": "proxmox-backup-client",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html",
|
||||
"tail": " — das Befehlszeilenwerkzeug, das ProxMenux für jedes Backup und jede Wiederherstellung aufruft. Beschreibt Backup-IDs, Backup-Typen, Archive, Repository-Syntax und Umgebungsvariablen."
|
||||
},
|
||||
{
|
||||
"label": "Clientseitige Verschlüsselung",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
|
||||
"tail": " — Erzeugung der Schlüsseldatei, --kdf-Modi und das Verschlüsselungsmodell, das ProxMenux um eine passphrasengeschützte Wiederherstellungskopie erweitert."
|
||||
},
|
||||
{
|
||||
"label": "Datenspeicherverwaltung",
|
||||
"href": "https://pbs.proxmox.com/docs/storage.html",
|
||||
"tail": "Erstellen und Verwalten der Datenspeicher, die Host-Backups erhalten, einschließlich Chunk-Store-Layout und Berechtigungen."
|
||||
},
|
||||
{
|
||||
"label": "Aufbewahrungsregeln und Garbage Collection",
|
||||
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
|
||||
"tail": " — das Aufbewahrungsmodell hinter --keep-last / --keep-daily / --keep-weekly, das ProxMenux je geplantem Auftrag anwendet, sowie die Freigabe ungenutzter Blöcke durch PBS nach der Bereinigung."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user