mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
docs: review backup and restore documentation in all seven translations
This commit is contained in:
Jonatan
@@ -0,0 +1,220 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Backups erstellen – interaktiver Backup-Flow | ProxMenux",
|
||||
"description": "Der interaktive Backup-Ablauf in ProxMenux: zwei Einstiegspunkte (das TUI-Menü von Scripts und die Weboberfläche von Monitor), drei Ziele, zwei Profilmodi, ein gemeinsamer Vorbereitungsschritt und ein Bestätigungsdialog. Beschrieben werden die Matrix mit sechs Optionen, das Standardprofil und das benutzerdefinierte Profil sowie die Schritte von der Auswahl eines Backups bis zum Speichern des Archivs am Ziel.",
|
||||
"ogTitle": "ProxMenux Backup — Erstellen von Backups",
|
||||
"ogDescription": "Der interaktive Backup-Flow mit drei Destinationen, zwei Profilen und einem gemeinsamen Staging-Schritt.",
|
||||
"twitterTitle": "Backups erstellen | ProxMenux",
|
||||
"twitterDescription": "Interaktiver Backup-Flow mit drei Zielen und zwei Profilmodi."
|
||||
},
|
||||
"header": {
|
||||
"title": "Backups erstellen",
|
||||
"description": "Der interaktive Backup-Ablauf: Wählen Sie ein Ziel und ein Profil, prüfen Sie die Zusammenfassung und verfolgen Sie, wie das Archiv gespeichert wird. Beide Einstiegspunkte verwenden dasselbe Backend und erzeugen identische Archive.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Zwei Einstiegspunkte, identische Funktionalität",
|
||||
"body": "Die TUI von Scripts und die Weboberfläche von Monitor bieten <strong>genau dieselben Funktionen</strong>. Jedes Backup — manuell oder geplant — durchläuft dieselbe Auswahlmatrix (drei Ziele × zwei Profile) und ruft pro Zelle dieselbe Backend-Funktion auf (<code>_bk_pbs</code>, <code>_bk_borg</code> oder <code>_bk_local</code>). Die über beide Einstiegspunkte erzeugten Archive sind nicht zu unterscheiden. Die Wahl ist Geschmackssache: Die TUI eignet sich für SSH und Skripte; Monitor bietet Mausbedienung sowie Ansichten für Benachrichtigungen und laufende Protokollausgaben."
|
||||
},
|
||||
"entryPoints": {
|
||||
"heading": "Die beiden Eingangspunkte",
|
||||
"rows": [
|
||||
{
|
||||
"entry": "ProxMenux Scripts (TUI)",
|
||||
"path": "menu → Utilities → Host Config Backup",
|
||||
"detail": "Dialogbasierter Flow, SSH-freundlich. Das Hauptmenü präsentiert die sechs Optionen direkt. Verwendet <code>backup_menu</code> in <code>backup_host.sh</code>."
|
||||
},
|
||||
{
|
||||
"entry": "ProxMenux Monitor (Weboberfläche)",
|
||||
"path": "Backups tab → Create backup",
|
||||
"detail": "Assistentengestützter Ablauf. Dieselben sechs Optionen erscheinen als zweistufiges Formular (Ziel → Profil). Über die Flask-API werden dieselben Backend-Funktionen aufgerufen."
|
||||
}
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Manuelle vs. geplante Backups",
|
||||
"body": "Backups können in zwei Modi erstellt werden: <strong>manuell</strong> (der interaktive Fluss, den diese Seite dokumentiert - der Benutzer wählt ein Ziel und ein Profil aus einem Menü aus und verfolgt das Speichern des Archivs) oder <strong>geplant</strong> (ein unbeaufsichtigter Job, der auf einem Cron-Timer läuft und die für den Job konfigurierte Aufbewahrung anwendet). Beide Modi unterstützen die gleichen drei Ziele und die gleichen zwei Profile, und beide sind von beiden Einstiegspunkten verfügbar - dem Scripts TUI-Menü und der Registerkarte Monitor-Backups. Geplante Jobs verwenden die gleichen Backend-Funktionen wie der manuelle Ablauf durch <code>run_scheduled_backup.sh</code>; die produzierten Archive sind nicht zu unterscheiden.",
|
||||
"seeAlso": "Die Seite mit geplanten Aufträgen deckt den gesamten Ablauf ab, einschließlich der Art und Weise, wie Sie einen Auftrag erstellen, ihn an einen vorhandenen PVE vzdump-Timer anhängen und die Retentionswerte konfigurieren.",
|
||||
"monitorAlt": "ProxMenux Monitor Backups Registerkarte zeigt den Neuen geplanten Backup-Dialog mit Ziel, Profil, Zeitplan und Aufbewahrungsfelder.",
|
||||
"monitorCaption": "Geplantes Backup — ProxMenux Monitor. Derselbe Wizard-Dialog, der ein manuelles Backup erstellt, trägt die Zeitplan- und Aufbewahrungsfelder unten für den unbeaufsichtigten Pfad."
|
||||
},
|
||||
"matrix": {
|
||||
"heading": "Die Matrix mit sechs Optionen",
|
||||
"intro": "Die Auswahl bestimmt sowohl das ausgeführte Backend als auch die Strategie zur Pfadauswahl. Die zielspezifischen Seiten erläutern die Konfiguration jeder Zelle.",
|
||||
"rows": [
|
||||
{
|
||||
"combo": "1",
|
||||
"destination": "PBS",
|
||||
"profile": "Standard",
|
||||
"action": "Lädt das Standardprofil plus persistente Extras in ein konfiguriertes PBS-Repository hoch."
|
||||
},
|
||||
{
|
||||
"combo": "2",
|
||||
"destination": "Borg",
|
||||
"profile": "Standard",
|
||||
"action": "Erstellt ein Archiv mit dem Standardprofil plus persistenten Extras im ausgewählten Borg-Repository."
|
||||
},
|
||||
{
|
||||
"combo": "3",
|
||||
"destination": "Lokal",
|
||||
"profile": "Standard",
|
||||
"action": "Schreibt ein <code>.tar.zst</code>-Archiv mit dem Standardprofil plus persistenten Extras an das konfigurierte lokale Ziel."
|
||||
},
|
||||
{
|
||||
"combo": "4",
|
||||
"destination": "PBS",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet vor dem PBS-Upload die Pfadauswahl; der Benutzer markiert die gewünschten Pfade und kann neue hinzufügen."
|
||||
},
|
||||
{
|
||||
"combo": "5",
|
||||
"destination": "Borg",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet den Pfadwähler, bevor das Borg-Archiv erstellt wird."
|
||||
},
|
||||
{
|
||||
"combo": "6",
|
||||
"destination": "Lokal",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet den Pfadwähler vor dem Schreiben des lokalen <code>.tar.zst</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"profiles": {
|
||||
"heading": "Standardprofil und benutzerdefiniertes Profil",
|
||||
"defaultTitle": "Standardprofil",
|
||||
"defaultBody": "Das Standardprofil ist die kuratierte Liste aus <code>hb_default_profile_paths</code> (dokumentiert in <em>Funktionsweise</em> unter <em>Pfadkategorien</em>) sowie jeder Eintrag in der persistenten Extras-Datei <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. Der Benutzer bestätigt die Ziel- und Verschlüsselungsoptionen und das Backup verläuft ohne weitere Pfadauswahl.",
|
||||
"customTitle": "Benutzerdefiniertes Profil",
|
||||
"customBody": "Das benutzerdefinierte Profil öffnet eine Checkliste mit allen Pfaden des Standardprofils (nicht markiert) und allen persistenten Extras (vormarkiert, mit dem Präfix <code>[+]</code>). Der Benutzer markiert die Pfade für diesen Durchlauf und kann über <em>Benutzerdefinierten Pfad hinzufügen</em> einen neuen absoluten Pfad ergänzen. Jeder dabei hinzugefügte Pfad wird in <code>backup-extra-paths.txt</code> gespeichert, damit künftige Backups ihn automatisch berücksichtigen. Das Abwählen eines persistenten Extras gilt nur für diesen Durchlauf und löscht es nicht aus der Datei — dafür gibt es außerhalb des Backup-Ablaufs die separate Aktion <em>Benutzerdefinierte Pfade verwalten</em>.",
|
||||
"customPickerAlt": "Benutzerdefinierte Profil-Checkliste mit den Standard-Profilpfaden (nicht markiert) und persistenten Extras (vormarkiert mit einem [+]-Präfix) sowie Schaltflächen, um einen neuen Pfad hinzuzufügen oder die Auswahl zu bestätigen.",
|
||||
"customPickerCaption": "Benutzerdefiniertes Profil — die Pfadauswahl. Die Pfade des Standardprofils sind nicht markiert; persistente Extras sind mit dem Präfix [+] vormarkiert. Der Benutzer markiert die Pfade für diesen Durchlauf.",
|
||||
"manageCustomAlt": "Menü zur Verwaltung benutzerdefinierter Pfade mit der Liste persistenter Extras und Optionen zum Hinzufügen, Entfernen und Bearbeiten.",
|
||||
"manageCustomCaption": "Benutzerdefinierte Pfade verwalten - der Einstiegspunkt, an dem persistente Extras hinzugefügt oder entfernt werden. Jeder hier aufgeführte Pfad wird automatisch in Backups im Standardmodus aufgenommen, ohne dass die benutzerdefinierte Pfadauswahl geöffnet werden muss."
|
||||
},
|
||||
"commonPipeline": {
|
||||
"heading": "Was läuft unabhängig vom Ziel",
|
||||
"intro": "Nachdem das Profil aufgelöst wurde, führt jedes Backend die gleiche Staging-Pipeline aus, bevor es in seinen eigenen Upload-Pfad divergiert. <code>hb_prepare_staging</code> stellt den Archivbaum in <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> zusammen und füllt jede der drei Nutzlasten aus.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"name": "rootfs zusammenstellen",
|
||||
"detail": "Führt <code>rsync -a</code> für jeden ausgewählten Pfad in <code>staging_root/rootfs/</code> aus. Die pmxcfs-Datenbank bei <code>/var/lib/pve-cluster/config.db</code> wird separat über <code>sqlite3 .backup</code> erfasst, um einen konsistenten Snapshot zu erstellen, ohne den Cluster zu stoppen, und die <code>.db-wal</code> / <code>.db-shm</code> Sidecars sind vom rsync ausgeschlossen; Wenn <code>sqlite3</code> nicht verfügbar ist, wird stattdessen eine Datei <code>config.db.raw-fallback</code> abgelegt, die bei der Wiederherstellung während des Imports als Datenbank übernommen wird. Flüchtige Subpfade (Bash-Historie, Caches, Trash) sind von <code>/root/</code> ausgeschlossen. Pfade, die in der Quelle fehlen, werden in <code>metadata/missing_paths.txt</code> aufgezeichnet, ohne das Backup zu stoppen."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"name": "Manifest erstellen",
|
||||
"detail": "<code>build_manifest.sh</code> steuert die sechs Datensammler und schreibt <code>manifest.json</code> in das Hauptverzeichnis des Staging-Bereichs. Fällt ein Datensammler aus, erhält der betroffene Abschnitt einen dokumentierten leeren Standardwert; das Manifest bleibt gültig."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"name": "Paketbestand",
|
||||
"detail": "<code>apt-mark showmanual</code> wird wortwörtlich in <code>metadata/packages.manual.list</code> erfasst. Der Komponentenzustand befindet sich bereits innerhalb der wiederhergestellten Rootfs (<code>components_status.json</code>), da <code>/usr/local/share/proxmenux/</code> Teil des Standardprofils ist."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"name": "Informationen zum Durchlauf",
|
||||
"detail": "<code>metadata/run_info.env</code> zeichnet die Backup-Laufidentität (Hostname, Zeitstempel, Kernelversion) auf, die von der Kompatibilitätsprüfung der Wiederherstellung zur Bestimmung der kernübergreifenden Richtung verwendet wird."
|
||||
},
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Mitteilung (Beginn)",
|
||||
"detail": "<code>hb_notify_lifecycle \"start\"</code> wird ausgelöst. Sind im Monitor Benachrichtigungen konfiguriert, wird das Ereignis <em>Host-Backup gestartet</em> für den Benutzer ausgegeben. Ohne konfigurierte Kanäle erfolgt keine Benachrichtigung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"included": {
|
||||
"heading": "Was reingeht und was draußen bleibt",
|
||||
"intro": "Jeder Pfad im aufgelösten Profil (Standard + persistente Extras + Custom-Mode-Auswahl) wird mit <code>rsync -aAXH --numeric-ids</code> kopiert. Eine gemeinsame Ausschlussliste gilt für jeden Pfad, und zwei Verzeichnisse tragen zusätzliche pfadspezifische Ausschlüsse.",
|
||||
"globalTitle": "Globale Ausschlüsse (auf jeden Pfad angewendet)",
|
||||
"globalItems": [
|
||||
"<code>images/</code> — Image Dumps.",
|
||||
"<code>dump/</code> — Ausgaben von vzdump.",
|
||||
"<code>tmp/</code> — temporäre Dateien.",
|
||||
"<code>*.log</code> — Protokolldateien."
|
||||
],
|
||||
"rootTitle": "<code>/root/</code> Ausschlüsse",
|
||||
"rootBody": "<code>/root/</code> ist Teil des Standardprofils, sodass Benutzerskripte und Konfigurationen im Archiv landen. Flüchtige Subpfade werden fallen gelassen:",
|
||||
"rootItems": [
|
||||
"<code>.bash_history</code>",
|
||||
"<code>.cache/</code>",
|
||||
"<code>tmp/</code>",
|
||||
"<code>.local/share/Trash/</code>"
|
||||
],
|
||||
"proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code> Ausschlüsse",
|
||||
"proxmenuxBody": "Dieses Verzeichnis liefert nur Benutzerstatus - <code>components_status.json</code>, Einstellungen, Cache nach der Installation. Code, den das Ziel bereits von seiner eigenen ProxMenux-Installation haben wird, ist ausgeschlossen, so dass eine Wiederherstellung die aktuellen Binärdateien des Ziels nicht mit älteren überschreibt:",
|
||||
"proxmenuxItems": [
|
||||
"<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
|
||||
"<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
|
||||
"<code>images/</code>, <code>json/</code>",
|
||||
"<code>utils.sh</code>, <code>helpers_cache.json</code>",
|
||||
"<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
|
||||
],
|
||||
"notInProfileTitle": "Pfade außerhalb des Profils",
|
||||
"notInProfileBody": "Alles, was nicht in <code>hb_default_profile_paths</code> aufgeführt ist und nicht als benutzerdefiniertes oder persistentes Extra hinzugefügt wurde, ist nicht Teil des Backups. Bemerkenswerte Beispiele:",
|
||||
"notInProfileItems": [
|
||||
"<strong>VM und LXC Festplatten</strong> — werden von <code>vzdump</code> behandelt, nicht von dieser Funktion. Gastkonfigurationsdateien unter <code>/etc/pve/nodes/*/qemu-server/*.conf</code> und <code>lxc/*.conf</code> werden erfasst (sie leben unter <code>/etc/pve</code>), so dass die Wiederherstellung das Inventar reproduziert; die Festplatten selbst werden von einem vorhandenen vzdump / PBS-Backup neu angehängt.",
|
||||
"<strong><code>/boot</code> und <code>/boot/efi</code></strong> — Kernel-Binärdateien, Initramfs und die UEFI-ESP-Partition werden nach der Wiederherstellung durch die eigenen <code>update-initramfs</code>, <code>update-grub</code> oder <code>proxmox-boot-tool refresh</code> des Ziels regeneriert. Der Bootloader wird niemals wörtlich kopiert.",
|
||||
"<strong>Kernel und Systemlaufzeit-Dateisysteme</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> und <code>/run</code> sind Pseudo-Dateisysteme, die vom Kernel und von udev erzeugt werden; sie werden nirgendwo persistent.",
|
||||
"<strong>Paket-Binärdateien unter <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — vom APT des Ziels aus <code>packages.manual.list</code> neu installiert.",
|
||||
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — Laufzeitzustand pro Host, nicht wiederhergestellt.",
|
||||
"<strong><code>/home/USER</code></strong> — nicht im Standardprofil. Fügen Sie es als benutzerdefinierten Pfad hinzu, wenn ein System Heimverzeichnisse des Benutzers trägt, die eine Wiederherstellung überleben müssen."
|
||||
],
|
||||
"customPathsTitle": "Wie benutzerdefinierte Pfade gehandhabt werden",
|
||||
"customPathsBody": "Ein benutzerdefinierter Pfad, der im benutzerdefinierten Modus hinzugefügt wurde oder in <code>backup-extra-paths.txt</code> persistiert wurde, durchläuft dieselbe <code>rsync</code>-Pipeline wie Standardprofilpfade. Globale Ausschlüsse gelten. Wenn der benutzerdefinierte Pfad unter <code>/root/</code> oder <code>/usr/local/share/proxmenux/</code> liegt, gelten die oben genannten pfadspezifischen Ausschlüsse weiterhin. Jeder archivierte Pfad – standardmäßig oder benutzerdefiniert – wird in <code>metadata/paths_archived.txt</code> aufgezeichnet. Pfade, die in der Quelle nicht vorhanden sind, werden in <code>metadata/missing_paths.txt</code> aufgezeichnet, ohne das Backup zu stoppen."
|
||||
},
|
||||
"archiveStructure": {
|
||||
"heading": "Archivstruktur",
|
||||
"intro": "Das von jedem Backend erstellte Staging-Verzeichnis folgt unabhängig vom Ziel dem gleichen Layout. Das Tarball-, PBS <code>.pxar</code> oder Borg-Archiv speichert diesen Baum wortwörtlich.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│ ├── packages.manual.list # output of apt-mark showmanual\n│ ├── run_info.env # hostname, timestamp, kernel version, pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n ├── root/ # /root without volatile subpaths\n ├── usr/local/ # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
|
||||
},
|
||||
"confirmation": {
|
||||
"heading": "Bestätigungszusammenfassung",
|
||||
"body": "Bevor das Backend etwas an das Ziel schreibt, zeigt ProxMenux einen zusammenfassenden Dialog mit dem Ziel, der Backup-ID oder dem Archivnamen, dem Verschlüsselungsstatus und der Liste der zu kopierenden Pfade an. Das Abbrechen hier bricht das Backup sauber ab - das Staging-Verzeichnis wird durch den <code>trap</code>-Hook entfernt, der auf der Backend-Funktion eingestellt ist, und keine Teildaten erreichen das Ziel."
|
||||
},
|
||||
"writing": {
|
||||
"heading": "Schreiben an den Bestimmungsort",
|
||||
"intro": "Sobald der Benutzer bestätigt, führt jedes Backend seinen eigenen Schreibschritt aus. Die Mechanik wird auf den Zielseiten behandelt; die gemeinsame Oberfläche ist das Protokoll, das Sidecar und die Abschlussbenachrichtigung.",
|
||||
"rows": [
|
||||
{
|
||||
"topic": "Protokolldatei",
|
||||
"detail": "Jedes Backend schreibt seine vollständige Ausgabe in <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> und bietet bei Ausfall an, sie in einem scrollbaren Dialog zu öffnen. Der Protokollpfad wird in der Abschlusszusammenfassung nur dann gedruckt, wenn die Datei Inhalt hat."
|
||||
},
|
||||
{
|
||||
"topic": "Begleitdatei (nur lokal)",
|
||||
"detail": "<code>hb_write_archive_sidecar</code> legt einen <code>*.proxmenux.json</code> neben das lokale Archiv, so dass der Monitor ihn als ProxMenux-Host-Backup auch nach Umzügen oder Umbenennungen identifiziert."
|
||||
},
|
||||
{
|
||||
"topic": "Benachrichtigung (Abschluss/Fehler)",
|
||||
"detail": "<code>hb_notify_lifecycle \"complete\"</code> oder <code>\"fail\"</code> wird mit Dauer, Archivgröße und — bei Fehlern — der letzten nach einem Fehler aussehenden Protokollzeile ausgelöst."
|
||||
}
|
||||
]
|
||||
},
|
||||
"finishedScreens": {
|
||||
"heading": "Wie ein fertiges Backup aussieht",
|
||||
"intro": "Das gleiche Abschlussereignis wird an beiden Einstiegspunkten angezeigt. Die TUI schreibt einen Zusammenfassungsblock in das Terminal; die Registerkarte Backups des Monitors zeigt den Ablauf in der Archivliste mit Größe, Dauer und Statusabzeichen an.",
|
||||
"scriptsAlt": "ProxMenux Scripts TUI zeigt ein fertiges Host-Backup an - Ziel, Backup-ID, Snapshot-Pfad, Datengröße, Dauer und Verschlüsselungszustand.",
|
||||
"scriptsCaption": "Abgeschlossenes Backup — ProxMenux Scripts (TUI). Der Vervollständigungsblock druckt das Ziel, die Backup-ID, den resultierenden Snapshot- oder Archivnamen, die Datengröße, die Dauer und den Verschlüsselungszustand.",
|
||||
"monitorAlt": "Die Registerkarte ProxMenux Monitor Backups zeigt einen fertigen Host-Backup-Eintrag mit Größe, Dauer, Methodenabzeichen und Verschlüsselungsindikator.",
|
||||
"monitorCaption": "Abgeschlossenes Backup — ProxMenux Monitor Backups Registerkarte. Das neue Backup erscheint in der Archivliste mit dem Zielmethode-Badge, der Größe, der Dauer und gegebenenfalls dem Verschlüsselungssperrindikator."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— Konfigurationsdetails für Local, PBS und Borg."
|
||||
},
|
||||
{
|
||||
"label": "Geplante Aufträge",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "- das gleiche Backup unbeaufsichtigt nach einem Zeitplan anstatt interaktiv auszuführen."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— der Fluss, der verbraucht, was diese Seite produziert."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Wiederherstellung zwischen Kernel-Versionen — Richtungserkennung, Sicherheitsfilter und Ergänzung | ProxMenux",
|
||||
"description": "Wie ProxMenux ein Host-Backup auf einem Ziel mit einer anderen Hauptkernelversion wiederherstellt. Dokumentiert, wie die Richtung der Fehlanpassung erkannt wird, den Safe-Subset-Filter, der bootkritische Pfade überspringt, wenn das Ziel einen neueren Kernel als das Backup ausführt, und die vierphasige Kernel-agnostische Hydratation, die Benutzertuning wie IOMMU, VFIO IDs und benutzerdefinierte Cmdline-Token erneut anwendet, ohne Kernel-gebundene Dateien wörtlich zu kopieren.",
|
||||
"ogTitle": "ProxMenux Backup — kernübergreifende Wiederherstellung und Hydratation",
|
||||
"ogDescription": "Wiederherstellung zwischen Kernel-Versionen mit Richtungserkennung, sicherer Pfadauswahl und kernelunabhängiger Ergänzung.",
|
||||
"twitterTitle": "Cross-Kernel-Wiederherstellung | ProxMenux",
|
||||
"twitterDescription": "Wie ProxMenux eine Wiederherstellung durchführt, wenn sich der Zielkernel vom Backup unterscheidet."
|
||||
},
|
||||
"header": {
|
||||
"title": "Kernübergreifende Wiederherstellung",
|
||||
"description": "Wie ProxMenux eine Wiederherstellung durchführt, wenn der Zielhost einen anderen Kernel als den im Backup aufgezeichneten ausführt - insbesondere wenn das Ziel einen neueren Kernel ausführt. Dokumentiert, wie der Unterschied erkannt wird, wie bootkritische Pfade, die das Ziel unterbrechen könnten, gefiltert werden und wie die eigene Konfiguration des Benutzers erneut angewendet wird, ohne Kernel-gebundene Dateien wörtlich zu kopieren.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Jeder Kernelsprung wird anders gehandhabt",
|
||||
"body": "Der Kernel eines Proxmox-Hosts wird durch eine Versionszeichenfolge wie <code>6.17.13-2-pve</code> identifiziert. Die ersten beiden Zahlen (<strong>6.17</strong> in diesem Beispiel) definieren die Hauptversion: Wenn sie sich ändern, sind einige Konfigurationsdateien, die für den vorherigen Kernel geschrieben wurden, möglicherweise nicht für den neuen gültig. Wenn die Wiederherstellung erkennt, dass das Backup und das Ziel unterschiedliche Hauptkernelversionen haben, verzweigt sich der Fluss basierend auf der Richtung des Sprungs - ob das Backup älter oder neuer als das Ziel ist - weil die beiden Fälle entgegengesetzte Fehlermodi haben. Backups, die neuer sind als das Ziel, stellen sauber wieder her, wie sie sind (bench-verifiziert über mehrere Kernelsprünge). Backups, die älter als das Ziel sind, benötigen einen Filter, um zu vermeiden, dass der Boot des Ziels mit einer Konfiguration unterbrochen wird, die für einen Kernel geschrieben wurde, der sich seitdem geändert hat."
|
||||
},
|
||||
"directionCheck": {
|
||||
"heading": "Die Richtungskontrolle",
|
||||
"intro": "Während der Kompatibilitätsprüfung vergleicht <code>hb_compat_check</code> den im Backup-Manifest aufgezeichneten Kernel mit dem aktuellen Kernel des Ziels (<code>uname -r</code>) und klassifiziert die Wiederherstellung in einen von drei Fällen, die in der internen Variable <code>HB_COMPAT_KERNEL_DIRECTION</code> gespeichert sind:",
|
||||
"rows": [
|
||||
{
|
||||
"direction": "same",
|
||||
"condition": "Die Hauptkernelversion stimmt zwischen Backup und Target überein.",
|
||||
"behavior": "Der vollständige Restaurationsfluss läuft unverändert. Kein extra Filter, keine Hydratation, kein besonderer Hinweis in der UI."
|
||||
},
|
||||
{
|
||||
"direction": "bk_newer",
|
||||
"condition": "Der Backup-Kernel ist NEUER als der des Ziels (zum Beispiel: Das Backup wurde auf dem Kernel 7.0 erstellt und das Ziel führt den Kernel 6.17 aus).",
|
||||
"behavior": "Der vollständige Wiederherstellungsfluss läuft unverändert, genau wie <code>same</code>. Es wird kein Filter angewendet. Empirisch verifiziert: Treiber werden automatisch gegen den Zielkernel neu installiert, IOMMU config wird sauber angewendet, VMs mit GPU-Durchgang kommen ohne Probleme auf."
|
||||
},
|
||||
{
|
||||
"direction": "bk_older",
|
||||
"condition": "Der Backup-Kernel ist älter als der des Ziels (zum Beispiel: Das Backup wurde auf dem Kernel 6.17 erstellt und das Ziel führt den Kernel 7.0 aus).",
|
||||
"behavior": "Der Safe-Subset-Filter und die folgende vierphasige Hydratation werden aktiviert. Die Wiederherstellung geht weiter - das Ziel reproduziert die Quelle, aber bootkritische Dateien werden nicht wörtlich kopiert."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyBkNewerIsSafe": {
|
||||
"heading": "Warum ein Backup mit einem neueren Kernel als das Ziel unverändert wiederherstellt",
|
||||
"body": "Wenn die Wiederherstellung gegen ein Ziel mit einem <em>älteren</em>-Kernel als dem im Backup aufgezeichneten läuft, ist jeder Mechanismus, von dem die Wiederherstellung abhängt, unabhängig von der Kernelversion. GPU-Treiberinstallateure und andere PCI-Geräteinstallateure erkennen den laufenden Kernel mit <code>uname -r</code> und kompilieren DKMS mit dem, was das Ziel hat. Die APT-Paketinstallation zieht Binärdateien, die für die Verteilung des Ziels erstellt wurden. IOMMU-Cmdline-Token wie <code>intel_iommu=on</code> sind in den wichtigsten Kernelversionen stabil. Das Backup trägt Pfade, die unter einem neueren Kernel geschrieben wurden, aber diese Pfade (Module Blacklists, GRUB Defaults, Initramfs Config) sind immer noch gültige Syntax auf dem älteren - Kernel ignorieren Token, die sie nicht erkennen, anstatt zu scheitern. Dieser Fall entspricht in der Praxis einer Wiederherstellung des gleichen Kerns, und ProxMenux behandelt ihn als solchen."
|
||||
},
|
||||
"safeSubsetFilter": {
|
||||
"heading": "Der Safe-Subset-Filter (nur wenn der Zielkernel neuer ist)",
|
||||
"intro": "Wenn der Zielkernel neuer ist als das Backup, fügt die Kompatibilitätsprüfung 16 bootkritische Pfade von <code>hb_unsafe_paths_cross_version</code> zu <code>RS_SKIP_PATHS</code> hinzu. Diese Pfade sind von der Wiederherstellung ausgeschlossen, da das Schreiben einer Version von ihnen aus einem älteren Kernel über ein Ziel mit einem neueren Kernelpanik in Bench-Tests verursacht hat. Die Pfade umfassen fünf Kategorien:",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Bootloader",
|
||||
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
|
||||
"reason": "GRUB-Standards, die an die vorherige Kernel-Order gebunden sind, und proxmox-boot-tool-Status (cmdline, ESP-UUIDs, Hooks), der auf Pfade und Identifikatoren aus der älteren Installation verweist."
|
||||
},
|
||||
{
|
||||
"category": "Kernelmodule und Bootartefakte",
|
||||
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
|
||||
"reason": "Autoload-Listen, die möglicherweise auf Module verweisen, die zwischen Kernel-Majors umbenannt wurden, Moduloptionen, die möglicherweise nicht gelten, Initramfs-Hooks, die für den älteren Kernel geschrieben wurden."
|
||||
},
|
||||
{
|
||||
"category": "Storage Stack und Filesystem Identität",
|
||||
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
|
||||
"reason": "UUIDs, die in dieser Installation möglicherweise nicht vorhanden sind, Multipath-Treiber, die zwischen Kerneln wechseln, iSCSI-Parameter, die sich entwickeln, udev-Regeln, die an nicht vorhandene Subsysteme binden können, ZFS-Zustand (<code>zpool.cache</code> + <code>hostid</code>), der den Pool als fremd sperren kann."
|
||||
},
|
||||
{
|
||||
"category": "APT-Quellen",
|
||||
"paths": "<code>/etc/apt</code>",
|
||||
"reason": "APT-Source-Suiten können beim nächsten Upgrade ein Downgrade kritischer Pakete auslösen."
|
||||
},
|
||||
{
|
||||
"category": "systemd",
|
||||
"paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
|
||||
"reason": "Unit overrides und .wants, die an den älteren systemd Major gebunden sind; Konfigurationsschlüssel, die möglicherweise nicht auf einem neueren systemd analysiert werden."
|
||||
}
|
||||
],
|
||||
"outroBody": "Der Filter läuft VOR dem Bestätigungsdialog, so dass der Benutzer die genaue Liste der Pfade sieht, die nach dem Grund kategorisiert übersprungen werden. Die Wiederherstellung geht weiter - alles andere (VM-/LXC-Konfiguration, Netzwerk, /etc/pve, Benutzer, cron, ProxMenux-Zustand, Pakete, Treiber, /root) wird normal wiederhergestellt."
|
||||
},
|
||||
"hydration": {
|
||||
"heading": "Kern-agnostische Hydratation",
|
||||
"intro": "Der Filter überspringt bootkritische Dateien; die Ergänzung übernimmt ausgewählte Benutzereinstellungen wie IOMMU-Parameter, VFIO-IDs, eigenes <code>GRUB_TIMEOUT</code> und nvidia-Sperrlisten. Sie läuft bei neuerem Zielkernel. Cmdline-Schlüssel des Ziels bleiben erhalten und fehlende Module werden ergänzt. Freigegebene GRUB-Werte und Benutzerdateien können abweichende Zielinhalte ersetzen. Gleiche Eingaben sind bei Wiederholung idempotent.",
|
||||
"phaseRows": [
|
||||
{
|
||||
"phase": "1a — GRUB-Trasse",
|
||||
"detail": "Für Hosts mit GRUB (ext4/lvm-Installationen). <code>_rs_hyd_grub</code> führt jedes Token aus dem <code>manifest.kernel_params.cmdline_extra</code> des Backups in das <code>GRUB_CMDLINE_LINUX_DEFAULT</code> des Ziels ein und überspringt Token, deren Schlüssel das Ziel bereits trägt. Dann werden die <code>GRUB_*</code>-Schlüssel auf der weißen Liste (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) aus dem <code>/etc/default/grub</code> des Backups zusammengeführt, wenn sie sich von denen des Ziels unterscheiden."
|
||||
},
|
||||
{
|
||||
"phase": "1b — systemd-boot / ZFS",
|
||||
"detail": "Für Hosts mit systemd-Boot (normalerweise ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> verschmilzt Benutzer-Token von <code>cmdline_extra</code> in <code>/etc/kernel/cmdline</code> des Ziels, wobei die eigene <code>root=</code>, <code>boot=</code> und <code>rootflags=</code> Boilerplate des Ziels intakt bleibt."
|
||||
},
|
||||
{
|
||||
"phase": "2 — /etc/modules-Merge",
|
||||
"detail": "<code>_rs_hyd_modules</code> fügt Module aus <code>manifest.kernel_params.modules_loaded_at_boot</code> hinzu, die sich in der Whitelist befinden (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) UND nicht bereits im <code>/etc/modules</code> des Ziels vorhanden sind."
|
||||
},
|
||||
{
|
||||
"phase": "3 — Kopie von Dateien auf der weißen Liste",
|
||||
"detail": "<code>_rs_hyd_files</code> kopiert vom Benutzer verfasste Dateien von den Staging-Rootfs zum Live-Ziel, wenn sich der Inhalt unterscheidet. Whitelist umfasst VFIO/nvidia / Blacklist-Dateien unter <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code> und die ProxMenux VFIO Binderegel + nvidia udev Regeln unter <code>/etc/udev/rules.d</code>. Distro-eigene Dateien (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) werden absichtlich ausgeschlossen - ihre Inhalte entwickeln sich zwischen den Releases."
|
||||
},
|
||||
{
|
||||
"phase": "4 — Neubildung nach dem Booten erzwingen",
|
||||
"detail": "Die vier Phasen schreiben direkt an das Live-Ziel außerhalb der normalen Wiederherstellungspipeline. Damit die zusammengeführten Token/Module/Dateien beim nächsten Booten wirksam werden, breitet sich <code>HB_HYDRATION_APPLIED=1</code> durch <code>plan.env</code> bis <code>apply_pending_restore.sh</code> aus, was <code>NEEDS_INITRAMFS=1</code> und <code>NEEDS_GRUB=1</code> unabhängig davon erzwingt, was in der Anwendungsliste war. Der Post-Boot-Dispatcher regeneriert dann Initramfs und aktualisiert den Bootloader."
|
||||
}
|
||||
]
|
||||
},
|
||||
"planCommit": {
|
||||
"heading": "Plan vs Commit - der Benutzer sieht zuerst eine Vorschau",
|
||||
"body": "Die Hydratation läuft in zwei Modi. Vor dem Bestätigungsdialog führt ProxMenux <code>_rs_apply_bk_older_hydration</code> im <code>plan</code>-Modus aus: Es berechnet genau, was zusammengeführt werden würde, füllt <code>RS_HYDRATION_SUMMARY</code> mit einem grünen Block, der jede Aktion auflistet, und gibt ohne zu schreiben zurück. Der Bestätigungsdialog zeigt den grünen Block neben der gelben Liste der durch den Sicherheitsfilter übersprungenen Pfade an, sodass der Benutzer VORAB sieht, was automatisch erneut angewendet wird. Nachdem der Benutzer bestätigt hat, führt ProxMenux den gleichen Helfer im <code>commit</code>-Modus erneut aus - gleiche Phasen, gleiche Logik, aber dieses Mal schreibt jede Phase an das Live-Ziel. Das Abbrechen des Bestätigungsdialogs lässt das Ziel unberührt."
|
||||
},
|
||||
"flowDiagram": {
|
||||
"heading": "Der Flow, wenn der Zielkernel neuer ist als das Backup",
|
||||
"intro": "Die Schritte, die hinzugefügt werden, wenn der Zielkernel neuer ist, befinden sich innerhalb des normalen Wiederherstellungsflusses. Alles andere - heißes Aufbringen, ausstehende Vorbereitung, Paketinstallation, Post-Boot-Dispatcher - läuft identisch mit einer Wiederherstellung mit dem gleichen Kern.",
|
||||
"diagram": " ┌────────────────────────────────────────────────────────────┐\n │ hb_compat_check │\n │ HB_COMPAT_KERNEL_DIRECTION = bk_older │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Add 16 boot-critical paths to RS_SKIP_PATHS │\n │ /etc/default/grub, /etc/kernel, /etc/modules-load.d, ... │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"plan\" │\n │ Compute what would be merged │\n │ Populate RS_HYDRATION_SUMMARY (green block) │\n │ No writes │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Confirmation dialog │\n │ Amber: paths skipped by safe-subset filter │\n │ Green: tokens/files reapplied by hydration │\n │ User accepts or cancels │\n └───────────────────────────┬────────────────────────────────┘\n │ (accepted)\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"commit\" │\n │ Phase 1a/1b: merge cmdline tokens + GRUB keys │\n │ Phase 2: append modules to /etc/modules │\n │ Phase 3: copy whitelisted vfio/nvidia files │\n │ Set HB_HYDRATION_APPLIED=1 │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Rest of the restore runs normally │\n │ _rs_apply hot (skips RS_SKIP_PATHS) │\n │ _rs_prepare_pending_restore (writes plan.env with │\n │ HB_HYDRATION_APPLIED=1) │\n │ packages.manual.list install │\n │ Reboot │\n │ apply_pending_restore.sh (forces NEEDS_INITRAMFS=1, │\n │ NEEDS_GRUB=1 because of the hydration flag) │\n │ apply_cluster_postboot.sh │\n │ update-initramfs -u -k all │\n │ update-grub / proxmox-boot-tool refresh │\n │ component --auto-reinstall │\n └────────────────────────────────────────────────────────────┘"
|
||||
},
|
||||
"concreteExamples": {
|
||||
"heading": "Konkrete Beispiele",
|
||||
"intro": "Der Hydratationspass ist nicht abstrakt - er erzeugt beobachtbare, korrekte Ergebnisse für gängige Szenarien. Zwei Beispiele, die Hydratation automatisch handhaben:",
|
||||
"rows": [
|
||||
{
|
||||
"scenario": "GPU-Durchgang (VFIO)",
|
||||
"detail": "Quelle hatte <code>intel_iommu=on iommu=pt</code> in der cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, ein <code>/etc/modprobe.d/vfio.conf</code> mit <code>options vfio-pci ids=10de:2216</code> und ein <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration führt die Cmdline-Token in die GRUB- oder Kernel-Cmdline des Ziels ein, fügt die vfio-Module an <code>/etc/modules</code> an und kopiert die beiden vom Benutzer verfassten Modprobe-Dateien. Beim nächsten Booten ist IOMMU aktiv, VFIO-Module laden, der GPU ist an vfio-pci gebunden und der VM hat Passthrough-Funktionen."
|
||||
},
|
||||
{
|
||||
"scenario": "Custom GRUB-Standards",
|
||||
"detail": "Quelle hatte <code>GRUB_TIMEOUT=1</code> und <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration liest beide Schlüssel aus dem <code>/etc/default/grub</code> des Backups und sieht, dass sie sich von den Standardeinstellungen der Neuinstallation unterscheiden, und schreibt diese beiden Zeilen in der Zieldatei um (alles andere, einschließlich <code>GRUB_DISTRIBUTOR</code>, bleibt unberührt)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"warningTitle": "Was bei neuerem Zielkernel nicht erneut angewendet wird",
|
||||
"warningBody": "Hydration wendet nur die Konfiguration ProxMenux an, von der bekannt ist, dass sie in Kernelversionen sicher ist: IOMMU-Token, VFIO-IDs, GRUB-Schlüssel auf der weißen Liste und Module aus einer festen Liste (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Alles außerhalb dieses Sets - benutzerdefinierte Initramfs-Hooks unter <code>/etc/initramfs-tools/hooks/</code>, nicht auf der weißen Liste stehende Dateien unter <code>/etc/modprobe.d/</code>, vom Benutzer verfasste systemd-Unit-Overrides - bleibt ausgeschlossen. Der Grund dafür ist konkret: Diese Dateien können Kernel-interne Schnittstellen (Modul-APIs, <code>/sys</code>-Layout, <code>udev</code>-Hooks) aufrufen, die zwischen den Hauptversionen wechseln, und ihre wörtliche Anwendung auf den neueren Kernel kann das Booten des Ziels verhindern. Wenn eine exakte Reproduktion der Bootkette erforderlich ist, muss die Wiederherstellung auf einem Host mit der gleichen Hauptkernelversion wie das Backup ausgeführt werden."
|
||||
},
|
||||
"codeReference": {
|
||||
"heading": "Wo die Mechanismen leben",
|
||||
"intro": "Für Entwickler, die das Cross-Kernel-Verhalten verfolgen oder erweitern möchten:",
|
||||
"rows": [
|
||||
{
|
||||
"component": "Richtungserkennung",
|
||||
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Setzt <code>HB_COMPAT_KERNEL_DIRECTION</code>."
|
||||
},
|
||||
{
|
||||
"component": "Liste sicherer Teilstrecken",
|
||||
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Sendet <code>path\\treason</code>-Linien aus, die sowohl vom CLI-Filter als auch vom Web-Endpunkt <code>/api/host-backups/restore/prepare</code> verwendet werden."
|
||||
},
|
||||
{
|
||||
"component": "Hydratationsphasen",
|
||||
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> in <code>backup_host.sh</code>. Orchestriert von <code>_rs_apply_bk_older_hydration</code>."
|
||||
},
|
||||
{
|
||||
"component": "Neubildung nach dem Booten erzwingen",
|
||||
"location": "<code>apply_pending_restore.sh</code> liest <code>HB_HYDRATION_APPLIED</code> von <code>plan.env</code> und zwingt <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
|
||||
},
|
||||
{
|
||||
"component": "Web Preview",
|
||||
"location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Lädt die Hilfsbibliothek, führt <code>_rs_apply_bk_older_hydration</code> im Planmodus aus und gibt die Aktionen an den Webmodal zurück."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— die vollständige Wiederherstellungspipeline der Mechanismen dieser Seite."
|
||||
},
|
||||
{
|
||||
"label": "Wie es funktioniert",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — Manifest und Erfassungsroutinen, die den von der Ergänzung gelesenen Block <code>kernel_params</code> erzeugen."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -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."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Glossar - Backup & Restore | ProxMenux",
|
||||
"description": "Begriffe des ProxMenux-Sicherungs- und Wiederherstellungssystems: Verschlüsselung, Schlüsseldatei, Passphrase, Wiederherstellungsumschlag, PBS, Chunks, rootfs, Manifest, Ausführungsprozess und Ergänzung zwischen Kernel-Versionen.",
|
||||
"ogTitle": "Backup & Restore Glossar | ProxMenux",
|
||||
"ogDescription": "Klare Definitionen für das Vokabular, das in der ProxMenux-Backup- und Wiederherstellungsdokumentation verwendet wird.",
|
||||
"twitterTitle": "Backup & Restore Glossar | ProxMenux",
|
||||
"twitterDescription": "Passphrase, Keyfile, Recovery-Umschlag, Rootfs, Manifest, PBS, Brocken — alle an einer Stelle definiert."
|
||||
},
|
||||
"header": {
|
||||
"title": "Glossar",
|
||||
"description": "Begriffe, die in der Backup- und Wiederherstellungsdokumentation mit ihrer Definition verwendet werden.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"body": "Begriffe werden nach Themen gruppiert. Jeder Eintrag gibt den Begriff und eine kurze Definition."
|
||||
},
|
||||
"groups": [
|
||||
{
|
||||
"title": "Verschlüsselung und Key Recovery",
|
||||
"intro": "Vokabular für den PBS-Verschlüsselungsblock. Es beinhaltet zwei verschiedene Geheimnisse: eine binäre Schlüsseldatei und eine geschriebene Passphrase.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "passphrase-recuperacion",
|
||||
"term": "Wiederherstellungspassphrase",
|
||||
"def": "Textkennwort, das der Benutzer auswählt, um den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag </a> zu schützen. Es wird zweimal mit einer Übereinstimmungsprüfung aufgefordert und wird nur verwendet, um den Umschlag zu verschlüsseln und zu entschlüsseln, wenn die Schlüsseldatei jemals wiederhergestellt werden muss. <strong>Es ist nicht die Passphrase, die die Schlüsseldatei selbst entsperrt</strong> und wird niemals an PBS gesendet. Während eines normalen Backups verlässt es niemals den Host."
|
||||
},
|
||||
{
|
||||
"id": "clave-cifrado",
|
||||
"term": "Keyfile (Verschlüsselungsschlüssel)",
|
||||
"def": "Schlüsseldatei, mit der proxmox-backup-client die <a href=\"#chunk\">Chunks</a> vor dem Hochladen zu PBS verschlüsselt. Ohne passenden Schlüssel sind verschlüsselte Daten nicht lesbar. ProxMenux speichert sie unter <code>/usr/local/share/proxmenux/pbs-key.conf</code> mit Modus <code>600</code>. Schützen Sie sie; der <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a> dient ihrer Wiederherstellung bei Verlust."
|
||||
},
|
||||
{
|
||||
"id": "contrasena-keyfile",
|
||||
"term": "Keyfile Passphrase (KDF Passphrase)",
|
||||
"def": "Optionale Passphrase, die die Keyfile selbst tragen kann, im Unterschied zur <a href=\"#passphrase-recuperacion\">Recovery Passphrase</a>. Es existiert nur, wenn die Keyfile mit <code>--kdf scrypt</code> erstellt wurde (normalerweise eine importierte Keyfile). Ohne sie kann die Keyfile nicht für die Verwendung entsperrt werden. ProxMenux behält es in verschlüsselter Form auf dem Host, so dass geplante Backups ohne interaktive Eingabeaufforderung ausgeführt werden können."
|
||||
},
|
||||
{
|
||||
"id": "sobre-recuperacion",
|
||||
"term": "Wiederherstellungsumschlag",
|
||||
"def": "Das <a href=\"#clave-cifrado\">keyfile</a> ist in eine zusätzliche Schicht eingewickelt: Es ist mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> unter Verwendung von <a href=\"#aes-256-cbc\">AES-256-CBC</a> und <a href=\"#pbkdf2\">PBKDF2</a> verschlüsselt, bevor es den Host verlässt. Es wird auf PBS als <code>-keyrecovery</code>-Gruppe hochgeladen. Ohne die Passphrase ist der Umschlag undurchsichtig: Wenn Sie ihn von PBS herunterladen, wird die Schlüsseldatei nicht angezeigt."
|
||||
},
|
||||
{
|
||||
"id": "cifrado-cliente",
|
||||
"term": "Clientseitige Verschlüsselung",
|
||||
"def": "Verschlüsselungsmodell, bei dem Daten auf dem Quellhost verschlüsselt werden, bevor sie hochgeladen werden. PBS empfängt und speichert immer nur Geheimtext; nicht einmal ein PBS-Administrator mit Datenspeicherzugriff kann ihn ohne die Schlüsseldatei lesen. ProxMenux baut auf diesem Modell auf und fügt den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a> hinzu."
|
||||
},
|
||||
{
|
||||
"id": "kdf-none",
|
||||
"term": "--kdf none",
|
||||
"def": "Option auf <code>proxmox-backup-client key create</code>, die eine Schlüsseldatei ohne angehängte Passphrase erzeugt. Die Keyfile kann direkt ohne Aufforderung verwendet werden, was für geplante Aufträge, die unbeaufsichtigt ausgeführt werden, unerlässlich ist. Dies ist, was ProxMenux standardmäßig verwendet, wenn eine neue Keyfile erzeugt wird."
|
||||
},
|
||||
{
|
||||
"id": "kdf-scrypt",
|
||||
"term": "--kdf scrypt",
|
||||
"def": "Option auf <code>proxmox-backup-client key create</code>, die eine Schlüsseldatei erzeugt, die durch eine <a href=\"#contrasena-keyfile\">keyfile-Passphrase</a> geschützt ist. Jede Verwendung der Keyfile erfordert das Entsperren mit dieser Passphrase. ProxMenux akzeptiert diese Art von Keyfile beim Import und speichert die Passphrase verschlüsselt, so dass geplante Backups immer noch unbeaufsichtigt ausgeführt werden können."
|
||||
},
|
||||
{
|
||||
"id": "aes-256-cbc",
|
||||
"term": "AES-256-CBC",
|
||||
"def": "Standardsymmetrische Chiffre. ProxMenux verwendet es (über <code>openssl enc -aes-256-cbc</code>), um die <a href=\"#clave-cifrado\">Schlüsseldatei</a> mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> zu wickeln und die <a href=\"#sobre-recuperacion\">Umschlag</a> zu produzieren."
|
||||
},
|
||||
{
|
||||
"id": "pbkdf2",
|
||||
"term": "PBKDF2",
|
||||
"def": "Kryptografische Funktion, die eine vom Menschen typisierte Passphrase in einen für die Verschlüsselung geeigneten binären Schlüssel verwandelt. Es verlangsamt Brute-Force-Versuche, indem es viele Iterationen anwendet. ProxMenux verwendet es mit 600 000 Iterationen und einem Zufallssalz bei der Verschlüsselung des Recovery-Umschlags."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Backup-Struktur",
|
||||
"intro": "Begriffe, die beschreiben, was sich in einem Backup befindet, unabhängig vom Zielort.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "rootfs",
|
||||
"term": "rootfs / Root-Dateisystem",
|
||||
"def": "Dateibasierte Kopie des Dateisystems des Quellhosts, erstellt mit <code>rsync</code> nach dem <a href=\"#perfil-defecto\">Standardprofil</a> und zusätzlichen <a href=\"#rutas-personalizadas\">eigenen Pfaden</a>. Kein vollständiges Datenträgerabbild: Kopiert werden nur Pfade mit Konfiguration oder Zustand, die Proxmox nicht selbst wiederherstellen kann."
|
||||
},
|
||||
{
|
||||
"id": "manifiesto",
|
||||
"term": "Manifest (manifest.json)",
|
||||
"def": "Strukturiertes JSON-Dokument zur Beschreibung des Quell-Hosts zum Backup-Zeitpunkt: Hardware, Storage, Kernel, ProxMenux-installierte Komponenten und Inventar von VMs und LXCs. Es wird von sechs unabhängigen Erfassungsroutinen produziert. Der Wiederherstellungsfluss verwendet ihn, um Quelle und Ziel zu vergleichen."
|
||||
},
|
||||
{
|
||||
"id": "staging",
|
||||
"term": "Stagingverzeichnis",
|
||||
"def": "Temporäres Verzeichnis, in dem ProxMenux die drei Blöcke (rootfs, Metadaten und Manifest) zusammenstellt, bevor sie verpackt und zum Zielort hochgeladen werden. Es wird automatisch entfernt, wenn das Backup beendet ist, auch bei Abbruch."
|
||||
},
|
||||
{
|
||||
"id": "perfil-defecto",
|
||||
"term": "Standardprofil",
|
||||
"def": "Kuratierte Reihe von Pfaden, die ProxMenux standardmäßig in jedem Backup kopiert. Umfasst PVE-Konfiguration, Netzwerk, SSH, Kernel, apt, ProxMenux Tools und mehr. Es ist im Code definiert und auf der Seite <em>Wie es funktioniert</em> dokumentiert."
|
||||
},
|
||||
{
|
||||
"id": "rutas-personalizadas",
|
||||
"term": "Benutzerdefinierte Pfade",
|
||||
"def": "Zusätzliche Pfade, die der Benutzer zusätzlich zum <a href=\"#perfil-defecto\">default-Profil</a> hinzufügt. Entweder persistent (gespeichert in <code>backup-extra-paths.txt</code>) oder per Run (im Custom-Modus ausgewählt)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Ziele und Speicher",
|
||||
"intro": "Begriffe, die an den Ort gebunden sind, an dem das Backup landet - PBS-Server, lokales Archiv oder Borg-Repository - und wie PBS die Daten organisiert.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "repositorio-pbs",
|
||||
"term": "PBS-Repository",
|
||||
"def": "Kombination von Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + Benutzer, der das Backup erhält. Identifiziert durch den String <code>user@realm@host:datastore</code>. Ein einzelner PBS-Server kann mehrere Repositories hosten."
|
||||
},
|
||||
{
|
||||
"id": "datastore",
|
||||
"term": "Datenspeicher",
|
||||
"def": "Konkreter Datenspeicher auf einem PBS-Server für Sicherungen und ihre Chunks. Er liegt auf einem Dateisystem des PBS-Servers und besitzt eigene Berechtigungen und Richtlinien."
|
||||
},
|
||||
{
|
||||
"id": "chunk",
|
||||
"term": "Chunk/Chunk-Deduplizierung",
|
||||
"def": "PBS teilt jedes Backup in Blöcke variabler Größe auf, identifiziert jedes Stück durch seinen Hash und speichert jedes Stück nur einmal, auch wenn es in vielen verschiedenen Backups erscheint. Dies bedeutet, dass aufeinanderfolgende Backups desselben Hosts - oder über ähnliche Hosts - sehr wenig zusätzlichen Speicherplatz benötigen."
|
||||
},
|
||||
{
|
||||
"id": "fingerprint",
|
||||
"term": "Fingerabdruck",
|
||||
"def": "Kryptografischer Fingerabdruck des PBS-Servers TLS Zertifikat. Der Client kann überprüfen, ob er mit dem vorgesehenen Server spricht, ohne sich auf eine öffentliche Zertifizierungsstelle zu verlassen. ProxMenux leitet sie über die Umgebungsvariable <code>PBS_FINGERPRINT</code> an <code>proxmox-backup-client</code> weiter."
|
||||
},
|
||||
{
|
||||
"id": "grupo-copia",
|
||||
"term": "Backup-Gruppe",
|
||||
"def": "Logischer Container innerhalb von PBS, unter dem sich aufeinanderfolgende Backups desselben Assets ansammeln. Jedes neue Backup teilt die Deduplizierung mit früheren in derselben Gruppe. ProxMenux verwendet zwei Gruppen pro Host, wenn die Verschlüsselung aktiviert ist: eine für das Host-Backup und eine mit einem <code>-keyrecovery</code>-Suffix für den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a>."
|
||||
},
|
||||
{
|
||||
"id": "backup-id",
|
||||
"term": "Backup-ID",
|
||||
"def": "Name der <a href=\"#grupo-copia\">backup-Gruppe</a>. ProxMenux ist standardmäßig <code>hostcfg-HOSTNAME</code> und lässt den Benutzer es vor dem Hochladen bearbeiten; nicht unterstützte Zeichen werden automatisch entfernt."
|
||||
},
|
||||
{
|
||||
"id": "pxar",
|
||||
"term": ".pxar",
|
||||
"def": "PBS-natives Archivformat für Verzeichnisse. Es verhält sich wie ein für die Chunk-Deduplizierung optimierter tar-Archiv: Anstatt eine undurchsichtige Datei zu speichern, zerlegt PBS seinen Inhalt in wiederverwendbare Chunks."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Ausführung und Terminplanung",
|
||||
"intro": "Begriffe, die vom ProxMenux-Planed-Jobs-System verwendet werden.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "runner",
|
||||
"term": "Ausführungsprozess",
|
||||
"def": "Das <code>run_scheduled_backup.sh</code>-Script, das ein geplantes Backup ausführt. Es liest die Job-Konfiguration, startet das passende Backend (Local, PBS oder Borg), wendet nach Erfolg die Aufbewahrungsregeln an und sendet die konfigurierten Benachrichtigungen."
|
||||
},
|
||||
{
|
||||
"id": "trabajo-programado",
|
||||
"term": "Geplanter Auftrag",
|
||||
"def": "Beharrliche Konfiguration eines wiederkehrenden Backups. Behält Ziel, Anmeldeinformationen, Verschlüsselung, Zeitplan und Aufbewahrung. Lebt bei <code>/var/lib/proxmenux/backup-jobs/<id>.env</code>."
|
||||
},
|
||||
{
|
||||
"id": "modo-adjunto",
|
||||
"term": "Anhängemodus",
|
||||
"def": "Auftrag ohne eigenen Timer. Ein job-end-Hook von PVE-<code>vzdump</code> startet ihn nach Gastsicherungen bei passendem Zielspeicher. Der gewählte Elternauftrag liefert Speicher und anfängliche Aufbewahrung; der Hook vergleicht aber Speicher statt Auftrags-ID. Auch andere Aufgaben desselben Speichers können ihn auslösen. Nur Local und PBS."
|
||||
},
|
||||
{
|
||||
"id": "timer-systemd",
|
||||
"term": "Systemd Timer",
|
||||
"def": "Standard-systemd-Mechanismus, der einen Befehl in einem Kalender auslöst. ProxMenux erstellt einen Timer pro <em>unabhängigem</em> geplanten Job; <a href=\"#modo-adjunto\">attach-mode</a> Jobs verwenden keinen Timer, sie laufen über den PVE-Skript-Hook."
|
||||
},
|
||||
{
|
||||
"id": "retencion",
|
||||
"term": "Aufbewahrung (keep-last, keep-daily…)",
|
||||
"def": "Richtlinie, die entscheidet, welche älteren Backups aufbewahrt und welche beschnitten werden sollen. Definiert pro Auftrag mit Parametern wie <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Wird vom Ausführungsprozess nach jedem erfolgreichen Backup angewendet."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Wiederherstellen",
|
||||
"intro": "Terme aus dem Wiederherstellungsfluss.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "restauracion-universal",
|
||||
"term": "Universale Wiederherstellung",
|
||||
"def": "Der ProxMenux-Wiederherstellungsfluss extrahiert nicht nur das Dateisystem: Er liest das Manifest, um Unterschiede zwischen Quelle und Ziel zu erkennen, reproduziert die Systemkonfiguration und führt die Installateure für die ProxMenux-verwalteten Komponenten erneut aus. Ziel ist es, den Quellhost zu reproduzieren, nicht nur das Archiv."
|
||||
},
|
||||
{
|
||||
"id": "hidratacion",
|
||||
"term": "Ergänzung zwischen Kernel-Versionen (Hydration)",
|
||||
"def": "Wiederherstellungsschritt, der die eigene Quellkonfiguration (IOMMU-Parameter, VFIO-Geräte-IDs, eigene Anpassungen und GRUB-Schlüssel) in die frische Boot-Konfiguration des Ziels übernimmt, ohne kernelgebundene Quelldateien unverändert zu kopieren. Läuft, wenn der Zielkernel neuer als der der Sicherung ist."
|
||||
},
|
||||
{
|
||||
"id": "cross-kernel",
|
||||
"term": "Kernübergreifende Wiederherstellung",
|
||||
"def": "Wiederherstellung, bei der der Zielkernel vom Quellkernel abweicht und meist neuer ist. Der <a href=\"#hidratacion\">Ergänzungsschritt</a> verhindert die Übernahme von Dateien, die mit dem Zielkernel inkompatibel sind."
|
||||
},
|
||||
{
|
||||
"id": "instalador-postboot",
|
||||
"term": "Installateur nach dem Booten",
|
||||
"def": "Komponenten, die nach dem ersten Booten des wiederhergestellten Hosts neu installiert wurden (NVIDIA-Treiber, Coral TPU-Treiber, AMD GPU-Tools, Intel GPU-Tools). Jeder Installer läuft gegen den Kernel des Ziels, so dass der wiederhergestellte Host nicht davon abhängt, ob der Kernel der Quelle vorhanden ist."
|
||||
},
|
||||
{
|
||||
"id": "compatibility-check",
|
||||
"term": "Kompatibilitätsprüfung",
|
||||
"def": "Vergleich zwischen dem Quellenmanifest und dem Zustand des Ziels, den ProxMenux zu Beginn der Wiederherstellung durchführt. Es entscheidet, welche Teile wortwörtlich kopiert werden, welche Hydratation benötigen und welche von einem Installateur neu erstellt werden."
|
||||
},
|
||||
{
|
||||
"id": "equipo-recien-instalado",
|
||||
"term": "Frische Installation",
|
||||
"def": "Host nur von Grund auf neu installiert, ohne lokale <a href=\"#clave-cifrado\">Schlüsseldatei</a>. Um ein verschlüsseltes Backup wiederherzustellen, muss zunächst die Schlüsseldatei aus der <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a>, die auf PBS gespeichert ist, mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> wiederhergestellt werden."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"whereNext": {
|
||||
"heading": "Wo als nächstes",
|
||||
"items": [
|
||||
{
|
||||
"label": "Wie es funktioniert",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "- wo das Rootfs-, Manifest- und Anwendungsinventar in ein Backup passt."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox-Backup-Server-Ziel",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "- wobei clientseitige Verschlüsselung, Keyfile, Recovery-Passphrase und Envelope ausführlich dokumentiert sind."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — Wiederherstellungsablauf und Verwendung des Manifests."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,205 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Wie ProxMenux Backup intern funktioniert – Rootfs, Manifest, Anwendungen",
|
||||
"description": "Detaillierte Aufschlüsselung dessen, was ein ProxMenux-Backup enthält: die Rootfs, die von rsync des Standardpfadprofils erzeugt werden, das strukturierte Manifest, das von sechs unabhängigen Sammlern erstellt wird, und das Anwendungsinventar, das die automatische Neuinstallation von Paketen und Komponenten nach einer Wiederherstellung steuert.",
|
||||
"ogTitle": "Wie ProxMenux Backup intern funktioniert",
|
||||
"ogDescription": "Die drei Nutzlasten eines ProxMenux-Backups wurden erklärt: Rootfs, Manifest und Anwendungen.",
|
||||
"twitterTitle": "Wie ProxMenux Backup funktioniert | ProxMenux",
|
||||
"twitterDescription": "Die drei Nutzlasten eines ProxMenux-Backups und wie die Wiederherstellung den Quellhost von ihnen reproduziert."
|
||||
},
|
||||
"header": {
|
||||
"title": "Wie es funktioniert",
|
||||
"description": "Die interne Aufschlüsselung eines ProxMenux-Backups - Dateisystem, Manifest und Anwendungsinventar - und wie die Wiederherstellung alle drei verbraucht, um den Quellhost auf einem Ziel zu reproduzieren, das möglicherweise nicht den gleichen Kernel teilt.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ein Archiv, drei Nutzlasten",
|
||||
"body": "Jedes Backup erzeugt drei klar getrennte Datenblöcke unter einem gemeinsamen Vorbereitungsverzeichnis. Das hochgeladene Archiv (lokales <code>.tar.zst</code>, PBS-Backup oder Borg-Archiv) enthält genau diese Struktur. Die Wiederherstellung nutzt alle drei: <strong>Das Manifest</strong> wird vor Änderungen ausgewertet, um Abweichungen zu erkennen und Ausschlüsse festzulegen; <strong>rootfs</strong> liefert die Konfigurationsdateien, die direkt oder nach einem Neustart angewendet werden; <strong>das Anwendungsinventar</strong> steuert die Paketinstallation und die Neuinstallation der Komponenten nach dem Start. Jeder Block lässt sich unabhängig untersuchen oder entpacken."
|
||||
},
|
||||
"layout": {
|
||||
"heading": "Archivlayout",
|
||||
"intro": "Jedes Archiv folgt dem gleichen Baumlayout, unabhängig vom Zielort. Das <code>metadata/</code>-Unterverzeichnis enthält die strukturierten Nutzlasten; das <code>rootfs/</code>-Unterverzeichnis enthält die Dateisystemkopie.",
|
||||
"treeCaption": "Das beim Backup angelegte Vorbereitungsverzeichnis. Alle Ziele erhalten denselben Verzeichnisbaum in ihrem nativen Format: tar bei lokalen Zielen, PBS-Blöcke bei PBS und Borg-Segmente bei Borg.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state\n├── metadata/\n│ ├── packages.manual.list # apt-mark showmanual\n│ ├── run_info.env # backup run identity + kernel version + pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n ├── root/ # /root (with volatile subdirs excluded)\n ├── usr/local/ # /usr/local/bin, /usr/local/share/proxmenux, …\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
|
||||
},
|
||||
"rootfs": {
|
||||
"heading": "Die Rootfs Nutzlast",
|
||||
"intro": "Der Verzeichnisbaum <code>rootfs/</code> ist eine <strong>einfache Dateisystemkopie</strong>, die <code>rsync</code> vom Quellhost erstellt. Er enthält ein ausgewähltes <strong>Standardprofil</strong> der für eine Proxmox-Wiederherstellung wichtigen Pfade sowie <strong>eigene Pfade</strong>, die der Benutzer zum Backup-Auftrag oder zur interaktiven Sitzung hinzufügt. Die Auswahl ist bewusst eng: nur Pfade, die <em>Konfiguration enthalten</em> oder <em>Zustand speichern, den Proxmox nicht selbst wiederherstellen kann</em>.",
|
||||
"defaultProfileTitle": "Das Standardprofil",
|
||||
"defaultProfileBody": "Das Standardprofil wird durch <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code> definiert. Es umfasst acht feste Kategorien und bei Bedarf den ZFS-Zustand, die zusammen einen funktionierenden Proxmox-Host beschreiben:",
|
||||
"categoriesTitle": "Pfadkategorien",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "PVE-Kern",
|
||||
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
|
||||
"why": "Cluster-Dateisysteminhalte und vzdump-Standards. Die pmxcfs-Datenbank (<code>config.db</code>) wird als konsistenter Snapshot über <code>sqlite3 .backup</code> erfasst, ohne den Cluster zu stoppen, und die <code>.db-wal</code> / <code>.db-shm</code> Sidecars sind vom rsync ausgeschlossen. Wenn <code>sqlite3</code> nicht verfügbar ist, wird stattdessen <code>config.db.raw-fallback</code> erstellt und bei der Wiederherstellung automatisch als Datenbank übernommen."
|
||||
},
|
||||
{
|
||||
"category": "Host-Identität und Netzwerk",
|
||||
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
|
||||
"why": "Alles, was der Host für den Netzwerkstart mit derselben Identität benötigt. Die <code>.link</code>-Dateien unter <code>/etc/systemd/network</code> ordnen Netzwerkkartennamen ihren MAC-Adressen zu, damit Neuinstallationen und Hardwareänderungen die Schnittstellen nicht umbenennen."
|
||||
},
|
||||
{
|
||||
"category": "Zugriff und Authentifizierung",
|
||||
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
|
||||
"why": "SSH Schlüssel, Sudo Regeln und PAM Konfiguration. Wenn Sie diese verlieren, wird der Benutzer aus dem wiederhergestellten Host ausgeschlossen."
|
||||
},
|
||||
{
|
||||
"category": "Kernel und Boot",
|
||||
"paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
|
||||
"why": "IOMMU-Token, Modul-Blacklists, VFIO-Geräte-IDs, Mount-Tabelle, Storage-Stack-Konfiguration."
|
||||
},
|
||||
{
|
||||
"category": "Shell und Gebietsschema",
|
||||
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
|
||||
"why": "Systemweite Shell-Einrichtung, Umgebungsvariablen und Konfiguration der Gebietsschema-Erzeugung."
|
||||
},
|
||||
{
|
||||
"category": "Paketverwaltung und cron",
|
||||
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
|
||||
"why": "APT-Quellen für konsistente Paketauflösung, geplante Aufgaben, die vom Benutzer definiert werden."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux Zustand & Werkzeuge",
|
||||
"paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
|
||||
"why": "Optionale, aber übliche Proxmox-Werkzeuge. Fehlende Pfade werden in <code>metadata/missing_paths.txt</code> vermerkt, ohne das Backup zu stoppen."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux Binärdateien und root",
|
||||
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (ausgenommen flüchtige Subdir)",
|
||||
"why": "ProxMenux-installierte Binärdateien und Konfiguration pro Benutzer unter <code>/root</code>. Flüchtige Pfade (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sind von der Kopie ausgeschlossen. <code>/var/lib/proxmenux</code> hält die geplanten Backup-Jobs und den Host-Status, der von ProxMenux beibehalten wird; das Wiederherstellungsstaging, die Rollback-Kopien und die Post-Restore-Marker sind ausgeschlossen, da sie zu dem Host gehören, der eine Wiederherstellung ausführt."
|
||||
},
|
||||
{
|
||||
"category": "ZFS-Zustand (bedingter Zustand)",
|
||||
"paths": "/etc/zfs",
|
||||
"why": "Nur enthalten, wenn der Quellhost ZFS ausführt. Enthält <code>zpool.cache</code> und <code>hostid</code>."
|
||||
}
|
||||
],
|
||||
"customTitle": "Erweiterung des Profils mit benutzerdefinierten Pfaden",
|
||||
"customBody": "Neben dem Standardprofil bietet ProxMenux zwei Möglichkeiten, zusätzliche Pfade in ein Backup aufzunehmen. Sie komponieren ohne Konflikte und gelten beide für interaktive Backups und geplante Jobs.",
|
||||
"customExtrasTitle": "1. Persistente Extras (Pro-Host-Datei)",
|
||||
"customExtrasBody": "Eine Textdatei bei <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> enthält eine Liste absoluter Pfade, die der Benutzer auf diesem Host als \"immer einschließen\" markiert hat. Wenn ein Backup im <strong>Default</strong>-Modus ausgeführt wird, fügt ProxMenux diese Pfade automatisch an das Standardprofil an, ohne zu fragen. Die Datei wird von der Benutzeroberfläche aus bearbeitet - keine manuelle Bearbeitung erforderlich - und bleibt bei Neustarts und Updates bestehen. Ein absoluter Pfad pro Zeile; <code>#</code>-Kommentare sind zulässig.",
|
||||
"customModeTitle": "2. Benutzerdefinierter Modus (per Lauf)",
|
||||
"customModeBody": "Das Starten eines Backups im <strong>Custom</strong>-Modus ersetzt die automatische Anwendung des Standardprofils durch eine Checkliste, die jeden Pfad anzeigt: die Standardprofileinträge und die persistenten Extras (vorangestellt mit <code>[+]</code> und bereits ausgewählt). Der Benutzer aktiviert oder deaktiviert Einträge für diesen bestimmten Lauf und kann auch <em>Eigenen Pfad hinzufügen</em> drücken, um einen neuen Pfad einzugeben - der dann für zukünftige Backups auf der Extras-Datei verbleibt.",
|
||||
"customMissingTitle": "Aus der Quelle fehlende Pfade",
|
||||
"customMissingBody": "Jeder Pfad aus dem Profil (Standard oder hinzugefügt), der auf dem Quellhost nicht vorhanden ist, wird in <code>metadata/missing_paths.txt</code> im Archiv aufgezeichnet. Das Backup schlägt nicht fehl und stoppt nicht – der Benutzer sieht am Ende eine Zusammenfassung der archivierten Pfade und fehlenden Pfade. In der Praxis geschieht dies bei optionalen Werkzeugpfaden wie <code>/etc/wireguard</code> oder <code>/etc/prometheus</code>, wenn diese Werkzeuge nicht installiert sind."
|
||||
},
|
||||
"manifest": {
|
||||
"heading": "Der Manifest-Datenblock",
|
||||
"intro": "<code>manifest.json</code> ist ein strukturiertes JSON-Dokument, das den Quellhost zum Zeitpunkt des Backups beschreibt. Es wird von <strong>sechs unabhängigen Erfassungsskripten</strong> orchestriert von <code>build_manifest.sh</code> produziert. Jeder Kollektor ist schreibgeschützt, erzeugt ein gut definiertes JSON-Fragment und fällt bei einem Ausfall auf einen sicheren leeren Standard zurück - das Manifest ist immer noch verwendbar, wenn ein Abschnitt unvollständig ist.",
|
||||
"orchestratorCaption": "Die sechs Sammler verfassen das Manifest. Jeder Kollektor läuft in seinem eigenen Subprozess; ein Fehler in einem fällt auf einen dokumentierten sicheren Standard zurück und warnt, bricht aber das Backup nicht ab.",
|
||||
"collectorRows": [
|
||||
{
|
||||
"collector": "collect_source_host.sh",
|
||||
"produces": "source_host",
|
||||
"content": "Hostname, PVE-Version (<code>pveversion</code>), PBS-Version, wenn der Host die Backup-Server-Rolle ausführt, Kernel (<code>uname -r</code>), Boot-Modus (efi/bios), Root-Dateisystemtyp, CPU-Modell + Architektur, Speicher in KB."
|
||||
},
|
||||
{
|
||||
"collector": "collect_hardware.sh",
|
||||
"produces": "hardware_inventory",
|
||||
"content": "GPUs (mit Hersteller- und ProxMenux-Installationsprogramm), TPUs (Coral USB + M.2 mit <code>lsusb</code>/<code>lspci</code>-Erkennung), NICs (mit MAC-, PCI-Slot- und Bridge-Mitgliedschaft), drahtlose Geräte. GPU-Einträge tragen eine <code>passthrough_eligible</code>-Heuristik."
|
||||
},
|
||||
{
|
||||
"collector": "collect_storage.sh",
|
||||
"produces": "storage_inventory",
|
||||
"content": "ZFS-Pools (mit Pooltyp + Mitglieds-Festplatten, die nach <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> oder rohen <code>/dev/sdX</code>-Pfaden aufgelöst wurden, je nachdem, wie jeder Pool ursprünglich erstellt wurde), LVM-Volumengruppen + dünne Pools, physische Festplatten mit SMART-Fähigkeit, PVE <code>storage.cfg</code>-Einträge, externe Mounts."
|
||||
},
|
||||
{
|
||||
"collector": "collect_kernel.sh",
|
||||
"produces": "kernel_params",
|
||||
"content": "Vom Betreiber hinzugefügte Parameter aus <code>/proc/cmdline</code>, ohne übliche Standardwerte wie <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> und <code>splash</code>; beim Start geladene Module aus <code>/etc/modules</code>; sowie Pfade der Dateien <code>/etc/modprobe.d/*.conf</code> mit tatsächlichen Direktiven (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
|
||||
},
|
||||
{
|
||||
"collector": "collect_proxmenux_state.sh",
|
||||
"produces": "proxmenux_installed_components",
|
||||
"content": "Lesen Sie <code>/usr/local/share/proxmenux/managed_installs.json</code> (Registrierung von allem, was ProxMenux installiert hat) und <code>installed_tools.json</code>. Jeder Eintrag behält den Installationspfad (<code>menu_script</code>) bei, so dass die Wiederherstellung genau den gleichen Installationsfluss auslösen kann."
|
||||
},
|
||||
{
|
||||
"collector": "collect_guests.sh",
|
||||
"produces": "vms_lxcs_at_backup",
|
||||
"content": "Zählt VMs (<code>qm list</code>) und LXCs (<code>pct list</code>) auf, die zum Backup-Zeitpunkt vorhanden sind — VMID, Name, aktueller Status. Nur das Inventar: Die eigentlichen Gästedaten liegen in der Verantwortung von <code>vzdump</code> / PBS."
|
||||
}
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "Das Anwendungsinventar",
|
||||
"intro": "Zwei Inventare erfassen die zusätzlich zu den Proxmox-VE-Basispaketen installierte Software: die Paketliste unter <code>metadata/</code> und das Komponentenverzeichnis im rootfs, beide unten beschrieben. Die Wiederherstellung installiert die Benutzersoftware je nach ursprünglichem Installationsweg mit APT oder den ProxMenux-Installationsskripten neu.",
|
||||
"packagesTitle": "packages.manual.list",
|
||||
"packagesBody": "Eine alphabetisch sortierte Textliste aus <code>apt-mark showmanual</code> mit allen auf dem Quellhost <em>ausdrücklich installierten</em> APT-Paketen. Als Abhängigkeiten des Proxmox-VE-Basissystems installierte Pakete fehlen darin; APT auf dem Ziel zieht sie selbst nach. Bei der Wiederherstellung liest <code>_rs_run_complete_extras</code> die Liste und wendet einen dreistufigen <em>Filter gegen Kaskadenentfernung</em> an: <code>dpkg -s</code> erkennt bereits installierte Pakete, für Bibliotheken werden vorhandene andere Hauptversionen erkannt und <code>apt-get install --simulate</code> prüft das Risiko von Folgeentfernungen. Danach folgt <code>apt-get install -y</code>.",
|
||||
"componentsTitle": "components_status.json (Teil des rootfs)",
|
||||
"componentsBody": "Ein JSON-Verzeichnis unter <code>/usr/local/share/proxmenux/</code> erfasst jede von ProxMenux installierte Komponente mit ihrem genauen Zustand: Version und ProxMenux-spezifische Merkmale (bei NVIDIA der boolesche Wert <code>patched</code>, bei Coral die DKMS-Version). Die Datei liegt im rootfs und nicht unter <code>metadata/</code>, weil sie <em>erst gelesen wird, nachdem</em> das rootfs auf das Ziel kopiert wurde. Der nach dem Start ausgeführte Dispatcher (<code>apply_cluster_postboot.sh</code>) geht alle Einträge durch und ruft den <code>--auto-reinstall</code>-Hook der jeweiligen Komponente auf. Dieser liest den gespeicherten Zustand und stellt die Installation für den aktuellen Kernel des Zielsystems wieder her.",
|
||||
"componentInstallersTitle": "Installationsskripte für Komponenten",
|
||||
"componentInstallersBody": "Vier ProxMenux-Installateure stellen derzeit einen <code>--auto-reinstall</code>-Einstiegspunkt frei:",
|
||||
"installerRows": [
|
||||
{
|
||||
"component": "nvidia_driver",
|
||||
"installer": "gpu_tpu/nvidia_installer.sh",
|
||||
"action": "Lesen Sie <code>version</code> + <code>patched</code>. Downloads der exakt gleichen NVIDIA-Runfile, baut DKMS-Module gegen den Kernel des Ziels und wendet den ProxMenux-Patch erneut an, wenn die Quelle ihn hatte."
|
||||
},
|
||||
{
|
||||
"component": "coral_driver",
|
||||
"installer": "gpu_tpu/install_coral.sh",
|
||||
"action": "Lesen Sie die Coral Driver Version. Kompiliert das DKMS-Modul gegen den Kernel des Ziels."
|
||||
},
|
||||
{
|
||||
"component": "amdgpu_top",
|
||||
"installer": "gpu_tpu/amd_gpu_tools.sh",
|
||||
"action": "Lesen Sie die aufgezeichnete Version. Laden Sie die genaue <code>.deb</code> aus dem GitHub-Release erneut herunter."
|
||||
},
|
||||
{
|
||||
"component": "intel_gpu_tools",
|
||||
"installer": "gpu_tpu/intel_gpu_tools.sh",
|
||||
"action": "APT installiert das Paket. Idempotent, wenn bereits vorhanden von <code>packages.manual.list</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"restoreFlow": {
|
||||
"heading": "Wie die Wiederherstellung die drei Nutzlasten verbraucht",
|
||||
"intro": "Die Wiederherstellung ist eine sechsstufige Pipeline. Jede Stufe liest eine bestimmte Untergruppe des Archivs und aktualisiert den Zielhost. Keine Stufe erfordert, dass der Quellhost erreichbar ist - das Archiv ist vollständig in sich geschlossen.",
|
||||
"stagesCaption": "Stufe 1 wertet das Manifest aus und legt fest, was geändert werden darf. Stufe 2 kopiert rootfs-Pfade, die auf dem laufenden System angewendet werden können. Stufe 3 bereitet riskante Pfade für den nächsten Start vor. Stufe 3b importiert ZFS-Datenpools ohne Root-Dateisystem, deren Datenträger vollständig vorhanden sind. Stufe 4 installiert Pakete. Stufe 5 installiert nach dem Neustart Komponenten für den Kernel des Ziels neu.",
|
||||
"stageRows": [
|
||||
{
|
||||
"stage": "1",
|
||||
"name": "Kompatibilitätsprüfung",
|
||||
"reads": "manifest.json",
|
||||
"action": "Läuft <code>hb_compat_check</code> aus. Vergleicht Quelle und Zielhardware (NICs, Storage IDs), PVE-Version und Hauptkernel-Version. Setzt <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> oder <code>bk_older</code>) ein und füllt <code>RS_SKIP_PATHS</code> mit Hardware-Drift- und Cross-Kernel-Ausschlüssen."
|
||||
},
|
||||
{
|
||||
"stage": "2",
|
||||
"name": "Anwenden im laufenden Betrieb",
|
||||
"reads": "rootfs/ (nur sichere Pfade)",
|
||||
"action": "<code>_rs_apply … hot</code> kopiert <code>hb_classify_path</code>=<code>hot</code>-Einträge direkt auf das Live-Ziel. Alles, was unter <code>/etc/pve</code>, <code>/etc/network</code> oder als <em>reboot</em>/<em>dangerous</em> klassifiziert ist, wird verschoben."
|
||||
},
|
||||
{
|
||||
"stage": "3",
|
||||
"name": "Ausstehende Vorbereitung",
|
||||
"reads": "rootfs/ (Reboot + gefährliche Pfade)",
|
||||
"action": "<code>_rs_prepare_pending_restore</code> bereitet riskante Pfade unter <code>/var/lib/proxmenux/pending-restore/</code> vor, schreibt <code>plan.env</code>, <code>apply-on-boot.list</code> und <code>rs-skip-paths.txt</code> und aktiviert <code>proxmenux-restore-onboot.service</code> für den nächsten Start."
|
||||
},
|
||||
{
|
||||
"stage": "3b",
|
||||
"name": "Import von Datenpools",
|
||||
"reads": "manifest.storage_inventory + ZFS-Zustand des Ziels",
|
||||
"action": "<code>_rs_import_data_pools</code> importiert jeden Nicht-Root-ZFS-Pool, dessen vollständiger Satz von Festplatten auf dem Ziel vorhanden ist. Pools mit einem fremden Hostid werden mit <code>zpool import -f</code> getestet. Pools, denen eine Festplatte fehlt, werden mit einer Warnung übersprungen. Das Ergebnis pro Pool wird in <code>/var/log/proxmenux/restore-datapools-<timestamp>.log</code> aufgezeichnet."
|
||||
},
|
||||
{
|
||||
"stage": "4",
|
||||
"name": "Paketinstallation",
|
||||
"reads": "metadata/packages.manual.list",
|
||||
"action": "<code>_rs_run_complete_extras</code> führt den kaskadensicheren Filter aus und ruft <code>apt-get install -y</code> mit der Paketliste auf. Die volle Ausgabe geht an <code>/var/log/proxmenux/restore-apt-*.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "5",
|
||||
"name": "Postboot",
|
||||
"reads": "rootfs (bereits angewendet) + components_status.json",
|
||||
"action": "Nach dem Neustart spielt <code>apply_pending_restore.sh</code> die zurückgestellten Pfade ab und <code>apply_cluster_postboot.sh</code> läuft <code>update-initramfs</code>, <code>update-grub</code> (oder <code>proxmox-boot-tool refresh</code>) und iteriert über <code>components_status.json</code> und feuert den <code>--auto-reinstall</code>-Hook jeder Komponente."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyItWorks": {
|
||||
"heading": "Warum der Drei-Payload-Split verwendet wird",
|
||||
"body": "Die Aufteilung richtet sich nach dem <strong>Lebenszyklus</strong> der Daten. Dateisysteminhalte werden mit <code>rsync</code> übertragen: schnell, nachvollziehbar und atomar je Datei. Der vor Änderungen auszuwertende Konfigurationszustand liegt als <strong>strukturiertes JSON</strong> vor: unabhängig lesbar, per Schema versionierbar und maschinell mit dem Zielzustand vergleichbar. Neu zu installierende Software wird als <strong>Inventar</strong> mit Namen und Versionen erfasst. Der Paketmanager des Ziels und die ProxMenux-Installationsskripte wählen die passenden Binärdateien. Jeder Datenblock erfüllt seine eigene Aufgabe. Zusammen ermöglichen sie eine auf konsistente Wiederherstellung ausgerichtete, fehlertolerante Verarbeitung: Bei beschädigtem Manifest bleibt rootfs wiederherstellbar; ein fehlendes Paket verhindert die Komponenteninstallation nicht; scheitert ein Komponenteninstallationsskript an einem Eintrag, wird der nächste trotzdem bearbeitet."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Sichern und Wiederherstellen – Übersicht | Vollständige Hostsicherung und -wiederherstellung für Proxmox VE",
|
||||
"description": "ProxMenux Backup & Restore erfasst den vollständigen Zustand eines Proxmox-Hosts – Dateisystem, strukturiertes Konfigurationsmanifest und installierte Pakete/Komponenten – und reproduziert ihn auf demselben oder einem anderen Host. Das Backup und die Wiederherstellung sind in sich geschlossen: keine externen Abhängigkeiten und Kernel-übergreifende Wiederherstellungen werden durch einen richtungsbewussten Safe-Subset-Filter und eine Kernel-agnostische Hydratation unterstützt.",
|
||||
"ogTitle": "ProxMenux Sicherung und Wiederherstellung – Übersicht",
|
||||
"ogDescription": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE mit strukturiertem Manifest, Paketliste und Neuinstallationsprogrammen für Komponenten.",
|
||||
"twitterTitle": "ProxMenux Sichern und Wiederherstellen | ProxMenux",
|
||||
"twitterDescription": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE mit strukturiertem Manifest, Paketliste und Komponenten-Neuinstallationsprogrammen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sichern und Wiederherstellen",
|
||||
"description": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE. Erfasst Dateisystem, Konfiguration und installierte Komponenten in einem einzigen Archiv und reproduziert den Host auf derselben oder einer anderen Proxmox-Installation ohne externe Abhängigkeiten.",
|
||||
"section": "Sichern und Wiederherstellen"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was es ist, in einem Absatz",
|
||||
"body": "Eine ProxMenux-Sicherung erfasst den vollständigen Zustand eines Proxmox-Hosts: <strong>das Dateisystem</strong> mit den relevanten Verzeichnissen unter <code>/etc</code>, <code>/root</code> und <code>/var/lib/pve-cluster</code> sowie optionalen eigenen Pfaden; <strong>ein strukturiertes Manifest</strong> im JSON-Format mit erkannter Hardware, Kernel-Parametern, Netzwerkkonfiguration, ZFS-Zustand, Benutzern und Cron-Einträgen; und <strong>ein Anwendungsinventar</strong> mit allen von APT als manuell installiert markierten Paketen und den von ProxMenux installierten Komponenten samt exakten Versionen. Alle drei unterstützten Ziele – lokales Archiv, Proxmox Backup Server (empfohlen) und Borg – erhalten denselben eigenständigen Datenbestand. Mit jedem davon lässt sich der Zielhost wiederherstellen, ohne dass der Quellhost während der Wiederherstellung erreichbar sein muss."
|
||||
},
|
||||
"video": {
|
||||
"heading": "Videoanleitung",
|
||||
"intro": "Beobachten Sie Backup & Restore lieber in Aktion, bevor Sie es konfigurieren? Diese exemplarische Vorgehensweise umfasst eine vollständige End-to-End-Demo der Funktion in ProxMenux.",
|
||||
"title": "ProxMenux – Anleitung zum Sichern und Wiederherstellen",
|
||||
"caption": "Externes Video auf YouTube. Spielt im erweiterten Datenschutzmodus (keine Cookies, bis Sie auf „Play“ drücken)."
|
||||
},
|
||||
"whatItIsNot": {
|
||||
"heading": "Was es nicht ist",
|
||||
"intro": "Dieser Abschnitt beschreibt Sicherung und Wiederherstellung <strong>auf Host-Ebene</strong>: die Proxmox-Installation selbst, nicht die darauf ausgeführten Anwendungen und Gastsysteme.",
|
||||
"items": [
|
||||
"<strong>Dies ist kein Sicherungswerkzeug für VMs oder CTs.</strong> Gastfestplatten und RAM-Zustand werden nicht erfasst; dafür ist <code>vzdump</code> zuständig. Die <strong>Konfigurationsdateien</strong> der Gäste (<code>/etc/pve/nodes/<node>/qemu-server/*.conf</code> und <code>lxc/*.conf</code>) werden <strong>jedoch</strong> gesichert. Nach der Wiederherstellung erscheint das Gastinventar erneut, und die Festplatten können aus einer vorhandenen PBS- oder lokalen Sicherung wiederhergestellt und zugeordnet werden.",
|
||||
"<strong>Dies ist kein clusterweiter Vorgang.</strong> Jeder Knoten sichert sich selbst. Die Clusterzugehörigkeit wird mit <code>/etc/pve</code> erfasst, sodass ein wiederhergestellter Knoten erneut aufgenommen werden kann. Die Wiederherstellung eines ganzen Clusters erfordert jedoch die Abstimmung zwischen den einzelnen Knoten.",
|
||||
"<strong>Dies ist kein vollständiges Festplattenabbild.</strong> Kernel-Binärdateien, initramfs und Boot-Partition werden nicht gesichert. Bei der Wiederherstellung nutzt ProxMenux die Boot-Dateien des Zielhosts, die mit <code>update-initramfs</code> und dem Bootloader-Werkzeug automatisch neu erzeugt werden, und installiert passende Treiber für den dort laufenden Kernel."
|
||||
]
|
||||
},
|
||||
"threePillars": {
|
||||
"heading": "Die drei Säulen eines Backups",
|
||||
"intro": "Ein ProxMenux-Archiv ist um drei in sich geschlossene Nutzdaten herum strukturiert. Bei der Wiederherstellung werden alle drei zusammen verwendet, um den Quellhost auf einem Ziel zu reproduzieren, auf dem möglicherweise nicht einmal derselbe Kernel installiert ist.",
|
||||
"diagramCaption": "Jedes Backup versendet unabhängig vom Ziel dieselben drei Payloads. Die Wiederherstellung verbraucht alle drei: rootfs zum Ablegen von Dateien, Manifest zum Erkennen von Abweichungen und Kernel-übergreifenden Unterschieden und Anwendungsinventar zum Neuinstallieren von Paketen und Komponenten im eigenen Kernel des Ziels.",
|
||||
"pillar1Label": "Dateisystem",
|
||||
"pillar1Detail": "rootfs/\n(rsync von /etc,\n/etc/systemd/network,\n/root sowie ein\nsqlite3-Snapshot\nvon /var/lib/pve-cluster,\n+ optionale Pfade)",
|
||||
"pillar2Label": "Manifest",
|
||||
"pillar2Detail": "manifest.json\n(Hardware, Kernel-\nParameter, Netzwerk,\nZFS, Benutzer, Cron,\nZFS-Pools, Speicher)",
|
||||
"pillar3Label": "Anwendungen",
|
||||
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(manuelle APT-Pakete + ProxMenux-\nInstaller mit Versionen)"
|
||||
},
|
||||
"restoreIsUniversal": {
|
||||
"heading": "Die Wiederherstellung reproduziert den Quellhost, nicht das Archiv",
|
||||
"body": "Beim Wiederherstellen eines ProxMenux-Backups wird nicht nur das Dateisystem extrahiert. Der Wiederherstellungsfluss liest das Manifest, um Abweichungen zwischen der Quelle und dem Ziel zu erkennen (Hardwareunterschiede, NIC-Umbenennungen, Kernelversion, ZFS-Pool-Identität), spielt das Dateisystem erneut ab und löst dann das richtige Komponenteninstallationsprogramm für jeden Dienst aus, der auf der Quelle installiert wurde (NVIDIA-Treiber, Coral TPU, AMD GPU-Tools, Intel-GPU-Tools). Jedes Installationsprogramm wird für den aktuellen Kernel des <strong>Ziels</strong> ausgeführt, sodass der wiederhergestellte Host nicht davon abhängt, dass der Kernel der Quelle vorhanden ist. Wenn der Kernel des Ziels neuer ist als der des Backups, führt ein Kernel-unabhängiger <strong>Hydration</strong>-Durchgang die eigene Optimierung des Benutzers (IOMMU-Tokens, VFIO-Geräte-IDs, benutzerdefinierte Sonderanpassungen, GRUB-Schlüssel) in die neue Startkonfiguration des Ziels ein, ohne Kernel-gebundene Dateien wörtlich zu kopieren."
|
||||
},
|
||||
"twoInterfaces": {
|
||||
"heading": "Zwei Schnittstellen, ein Backend",
|
||||
"intro": "Alle Schritte der Sicherung und Wiederherstellung sind über zwei Oberflächen erreichbar. Beide rufen dieselbe Shell-Bibliothek auf, erstellen identische Archive und verwenden dasselbe Auftragsverzeichnis.",
|
||||
"cliLabel": "ProxMenux Scripts (TUI)",
|
||||
"cliDetail": "Menü → Dienstprogramme →\nHost-Sicherung/Wiederherstellung\n\nDialogbasierter Ablauf,\nSSH-freundlich, skriptfähig\nzur unbeaufsichtigten Nutzung.",
|
||||
"webLabel": "ProxMenux Monitor (Web UI)",
|
||||
"webDetail": "Registerkarte Backups in der\nWeboberfläche von Monitor.\n\nWiederherstellung mit einem Klick,\nlaufende Protokollanzeige, integriert\nmit Benachrichtigungen und der\nAnzeige von Rollback-Differenzen."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin geht es von hier aus?",
|
||||
"intro": "Jeder Unterabschnitt unten behandelt einen Aspekt des Arbeitsablaufs ausführlich. Beginnen Sie mit <em>Wie es funktioniert</em>, wenn das Ziel darin besteht, zu verstehen, was das Archiv enthält und warum. Wechseln Sie zu <em>Ziele</em>, um das Ziel für die Kopie zu konfigurieren. Lesen Sie <em>Wiederherstellung</em> und <em>Cross-Kernel-Wiederherstellung</em> für die Wiederherstellungsseite.",
|
||||
"items": [
|
||||
{
|
||||
"label": "So funktioniert es",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "– die drei Payloads (rootfs, Manifest, Anwendungen) im Detail, mit den Collectors, die sie erzeugen, und dem Format jeder Datei."
|
||||
},
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "– Vergleich von lokal, Proxmox Backup Server (empfohlen) und Borg und wie man sie jeweils konfiguriert."
|
||||
},
|
||||
{
|
||||
"label": "Backups erstellen",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "– einmalige Sicherungen, das Standardpfadprofil, Hinzufügen benutzerdefinierter Pfade, Verschlüsselung für PBS."
|
||||
},
|
||||
{
|
||||
"label": "Geplante Jobs",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "– neue Jobs im Vergleich zum Anhängen an einen vorhandenen PVE-vzdump-Job, Planungsformate, das Jobdetail-Modal."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellen",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "– die drei Aktionen für ein Archiv (Anzeigen, Herunterladen, Wiederherstellen), vollständige vs. benutzerdefinierte Wiederherstellung, der Post-Boot-Dispatcher und warum die letzten zehn Minuten wichtig sind."
|
||||
},
|
||||
{
|
||||
"label": "Kernelübergreifende Wiederherstellung",
|
||||
"href": "/docs/backup-restore/cross-kernel",
|
||||
"tail": " — vom Versionswechsel abhängiges Verhalten bei unterschiedlichen Quell- und Zielkerneln, der Filter für eine sichere Teilmenge und die vier Hydratationsphasen."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Geplante Aufträge — Timer, Attachment-Modus, Retention | ProxMenux",
|
||||
"description": "Geplante ProxMenux Host-Backup-Jobs. Zwei Erstellungsmodi (eigener systemd-Timer oder Attachment zu einem vorhandenen PVE vzdump-Job), Retentionswerte, die pro Job über proxmox-backup-client/borg/local prune angewendet werden, Storage-Layout unter /var/lib/proxmenux/backup-jobs und das Runner-Script, das Archive erzeugt, die mit dem interaktiven Fluss identisch sind.",
|
||||
"ogTitle": "ProxMenux Backup — geplante Aufträge",
|
||||
"ogDescription": "Unbeaufsichtigte geplante Host-Backups mit Attachment-Modus, Retention und den gleichen drei Zielen wie der interaktive Fluss.",
|
||||
"twitterTitle": "Geplante Jobs | ProxMenux",
|
||||
"twitterDescription": "Unbeaufsichtigte geplante Host-Backup-Jobs mit Attach-Modus und Retention."
|
||||
},
|
||||
"header": {
|
||||
"title": "Geplante Aufträge",
|
||||
"description": "Unbeaufsichtigte Host-Backup-Jobs. Zwei Erstellungsmodelle: ein neuer unabhängiger Job mit einem eigenen Zeitplan oder ein Job, der an eine bestehende PVE vzdump-Aufgabe angehängt ist, die den Zeitplan und die Aufbewahrung dieser Aufgabe erbt. Beide produzieren Archive, die mit dem interaktiven Fluss identisch sind.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Die beiden planmäßigen Job-Modelle",
|
||||
"body": "Ein geplanter Job kann nach einem von zwei Modellen erstellt werden:",
|
||||
"modelsList": [
|
||||
"<strong>Neuer unabhängiger job</strong> — ProxMenux definiert den Jobplan selbst mit einem eigenen systemd-Timer, unabhängig von anderen Aufgaben auf dem Host. Kompatibel mit allen drei Destinationen: Local, PBS und Borg.",
|
||||
"<strong>An eine bestehende PVE vzdump-Task anhängen</strong> – der Job hat keinen eigenen Zeitplan; er wird automatisch ausgeführt, wenn die übergeordnete PVE vzdump-Task, die bereits die VMs und LXCs auf diesem Host sichert, ausgelöst wird. Erbt den Zeitplan und die Beibehaltung von der übergeordneten Aufgabe. Kompatibel mit Local und PBS (Borg wird nicht unterstützt, da PVE keinen nativen Scheduler für Borg hat)."
|
||||
]
|
||||
},
|
||||
"attachBadge": {
|
||||
"title": "Attach-Modus — empfohlen, wenn bereits eine PVE vzdump-Task existiert",
|
||||
"body": "Wenn bereits ein PVE-vzdump-Auftrag für die VMs und LXCs dieses Knotens eingerichtet ist, wird das angehängte Host-Backup nach dem Gast-Backup im <strong>selben Sicherungszyklus</strong> ausgeführt. Bei der Wiederherstellung stammen die Gastkonfigurationen aus dem Host-Backup (unter <code>/etc/pve</code>) und die Gastfestplatten aus den vzdump-Backups dieses Zyklus. Dies erleichtert eine koordinierte Wiederherstellung des gesamten Knotens, ist aber kein atomarer Snapshot: Änderungen während des Zyklus können Unterschiede zwischen Hostkonfiguration und Gastfestplattenzustand hinterlassen."
|
||||
},
|
||||
"frequencyBadge": {
|
||||
"title": "Empfohlene Häufigkeit",
|
||||
"body": "Um die Kompatibilität zwischen einem Host-Backup und seiner zukünftigen Wiederherstellung zu maximieren, führen Sie häufig Host-Backups aus. Je näher das Backup dem aktuellen Zustand des Hosts ist, desto weniger Konfigurations-, Paket- und Komponentendrift muss die Wiederherstellung in Einklang bringen."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Die beiden Modi",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Neuer geplanter Auftrag",
|
||||
"backends": "Lokal, PBS, Borg",
|
||||
"schedule": "Eigener <code>OnCalendar</code>-Ausdruck (systemd-Kalendersyntax, z. B. <code>daily</code> oder <code>Mon..Fri 03:00</code>).",
|
||||
"retention": "Separat abgefragt: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Wird vom Ausführungsskript nach jedem erfolgreichen Backup angewendet."
|
||||
},
|
||||
{
|
||||
"mode": "Anhängen an einen PVE vzdump Job",
|
||||
"backends": "Lokal, PBS (Borg hat keinen PVE-seitigen Scheduler)",
|
||||
"schedule": "Vererbt vom Eltern-PVE-Job. Auf der ProxMenux-Seite ist kein systemd-Timer installiert.",
|
||||
"retention": "Aus der <code>prune-backups</code>-Konfiguration des übergeordneten Auftrags übernommen (über <code>hb_pve_prune_to_keep_env</code> eins zu eins den <code>KEEP_*</code>-Variablen des Ausführungsskripts zugeordnet)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"attachDetail": {
|
||||
"heading": "Wie Attach Mode funktioniert",
|
||||
"intro": "PVE speichert <code>vzdump</code>-Aufträge in <code>/etc/pve/jobs.cfg</code> — einen Abschnitt pro Auftrag mit dem Speicherziel für VM- und LXC-Backups. Der Attach-Modus erfordert ein von ProxMenux unterstütztes Backend (Lokal oder PBS). Das Host-Backup wird nach Abschluss des Gast-Backups über den job-end-Hook ausgeführt.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"detail": "Während der Auftragserstellung listet ProxMenux kompatible übergeordnete PVE-Aufgaben über <code>hb_pve_list_vzdump_jobs_for_backend</code> auf. Der Benutzer wählt einen aus."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"detail": "Der <code>.env</code> des Jobs wird mit <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> und den geerbten <code>KEEP_*</code>-Werten geschrieben; es wird kein systemd-Timer erstellt."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"detail": "<code>hb_install_vzdump_hook</code> registriert einen Skript-Hook in <code>/etc/vzdump.conf</code>. In der job-end-Phase jedes vzdump-Auftrags vergleicht er den übergebenen <code>$STOREID</code> mit <code>PVE_STORAGE</code> aller aktivierten angehängten Aufträge und startet das Ausführungsskript bei Übereinstimmung. Der Abgleich erfolgt nach Speicher, nicht nach der ID des gewählten übergeordneten Auftrags."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"detail": "Das Archiv landet im selben Speicher, den die vzdump-Dumps gerade geschrieben haben: <code>path/dump/</code> für Local oder das PBS-Repository, das auf dem PVE-Speichereintrag konfiguriert ist."
|
||||
}
|
||||
],
|
||||
"outroBody": "Der Attach-Modus hat keinen eigenen Timer. Das Deaktivieren oder Löschen des gewählten übergeordneten PVE-Auftrags stoppt dessen Auslösung; andere vzdump-Aufträge mit demselben Speicher können das Host-Backup weiterhin auslösen. Deaktivieren oder löschen Sie den ProxMenux-Auftrag selbst, um dies zu verhindern. Beim Deaktivieren bleibt der Eintrag auf der Festplatte und kann später erneut aktiviert oder angehängt werden."
|
||||
},
|
||||
"storageLayout": {
|
||||
"heading": "Dateien, die einen Job ausmachen",
|
||||
"intro": "Jeder geplante Job wird vollständig durch drei oder vier Dateien auf der Festplatte beschrieben. Das Lesen gibt die vollständige Konfiguration des Jobs, ohne sich auf die Benutzeroberfläche zu verlassen.",
|
||||
"rows": [
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
|
||||
"content": "Backend, Backup-ID oder Ziel, Zeitplan (Neuer Auftrag) oder übergeordneter PVE-Auftrag (Attach-Modus), Aktivierungsstatus, Aufbewahrungswerte <code>KEEP_*</code> und Verweise auf Zugangsdaten."
|
||||
},
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
|
||||
"content": "Ein absoluter Pfad pro Zeile - die eingefrorene Auswahl wurde zum Zeitpunkt der Joberstellung aus dem Profil aufgelöst. Das Bearbeiten der Datei führt den Job mit der neuen Auswahl beim nächsten Auslösen des Timers erneut aus."
|
||||
},
|
||||
{
|
||||
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
|
||||
"content": "Nur neuer Modus. Der Dienst ruft <code>run_scheduled_backup.sh JOB_ID</code> auf. Der Timer plant es mit <code>Persistent=true</code> (verpasste Ausführungen werden beim nächsten Boot nachgeholt) und einem kleinen <code>RandomizedDelaySec=120</code>, um die Last zu verteilen, wenn mehrere Jobs den gleichen OnCalendar-Ausdruck teilen."
|
||||
},
|
||||
{
|
||||
"path": "/etc/vzdump.conf script-hook",
|
||||
"content": "Nur Attach-Modus. Einmal durch <code>hb_install_vzdump_hook</code> installiert; vergleicht <code>PVE_STORAGE</code> jedes angehängten Auftrags mit <code>$STOREID</code>, das PVE dem Hook-Skript übergibt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"runner": {
|
||||
"heading": "Was beim Start eines Auftrags geschieht",
|
||||
"intro": "Jeder Job - ob New-Model oder Attachment - führt die gleiche dreistufige Sequenz aus:",
|
||||
"steps": [
|
||||
"<strong>Backup vorbereiten.</strong> Liest die Job-Konfiguration (Ziel, Profil, Pfade) und stellt den Archivbaum genau so zusammen, wie es der interaktive Fluss tut. Das Ergebnis ist das gleiche Archiv, das ein manuelles Backup mit diesen Einstellungen erzeugen würde.",
|
||||
"<strong>An das Ziel schreiben.</strong> Überträgt oder schreibt das Archiv in das konfigurierte Ziel – eine lokale <code>.tar.zst</code>-Datei, ein PBS-Backup oder ein Borg-Archiv – mit genau den gleichen Tools und Anmeldeinformationen, die ein manuelles Backup für dasselbe Ziel verwenden würde.",
|
||||
"<strong>Aufbewahrungsregeln anwenden.</strong> Entfernt alte Backups vom Zielort, wobei die Anzahl der <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> für den Auftrag konfiguriert bleibt. Das Beschneiden wird vom Zielort selbst durchgeführt: PBS wendet seine eigene Aufbewahrung an, Borg führt <code>borg prune</code> aus und bei Lokal löscht ProxMenux die Dateien, die außerhalb des <code>keep-last</code>-Fensters liegen."
|
||||
]
|
||||
},
|
||||
"management": {
|
||||
"heading": "Aufträge verwalten",
|
||||
"intro": "Das Scheduler-Menü (Scripts TUI) und die Registerkarte Monitor Backups zeigen die gleichen Aktionen bei jedem Job.",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Jetzt ausführen",
|
||||
"detail": "Ruft das Ausführungsskript sofort auf und umgeht Timer bzw. vzdump-Hook. Damit lässt sich die Auftragskonfiguration prüfen, ohne auf die nächste geplante Ausführung zu warten."
|
||||
},
|
||||
{
|
||||
"action": "Aktivieren/Deaktivieren",
|
||||
"detail": "Neuer Modus: <code>systemctl enable/disable --now</code> der Timer. Attach-Modus: Dreht das <code>ENABLED</code>-Flag im Job Env um — das Hook-Skript berücksichtigt es beim nächsten PVE-Aufruf."
|
||||
},
|
||||
{
|
||||
"action": "Bearbeiten",
|
||||
"detail": "Öffnet Ziel, Zeitplan, Profil und Aufbewahrungsaufforderungen neu und schreibt die Jobdateien neu. Bewahrt die Job ID auf."
|
||||
},
|
||||
{
|
||||
"action": "Löschen",
|
||||
"detail": "Entfernt die Job env, Pfaddatei, systemd Timer + Service (Neuer Modus) und deaktiviert die Hakenbindung (Attach-Modus). Berührt keine Archive bereits am Zielort."
|
||||
},
|
||||
{
|
||||
"action": "Protokoll anzeigen",
|
||||
"detail": "Zeigt laufend an: <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> – eine Protokolldatei pro Lauf. Der Runner gibt außerdem eine kompakte Statuszeile an journald unter dem Dienst systemd aus."
|
||||
}
|
||||
]
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Backups erstellen",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "- der interaktive Fluss, der das Backend mit dem Scheduler teilt."
|
||||
},
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "Per-Backend-Konfiguration, die sowohl vom interaktiven Flow als auch vom Scheduler verwendet wird."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — der Ablauf zur Wiederherstellung der von den Aufträgen erzeugten Backups."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user