Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-11-01 10:22:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: review backup and restore documentation in all seven translations

Browse Source
This commit is contained in:
Jonatan
2026-10-17 15:08:53 +02:00
parent ce1a3de719
commit ea6f6dbf6e
86 changed files with 11849 additions and 244 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/test-i18n.yml
+10
View File
@@ -9,15 +9,20 @@ on:
- 'AppImage/messages/**'
- 'AppImage/lib/i18n/**'
- 'AppImage/components/terminal-panel.tsx'
- 'web/**'
- 'CONTRIBUTING.md'
# Scheduler consumers and the offline extractor's .sh/.func inputs.
- 'scripts/**/*.sh'
- 'scripts/**/*.func'
- 'scripts/**/*.py'
- 'lang/*.json'
- 'menu'
- 'install_proxmenux.sh'
- 'install_proxmenux_beta.sh'
- 'oci/src/**/*.py'
- 'oci/catalog/**/*.json'
- 'oci/remote/**/*.sh'
- 'oci/remote/**/*.py'
push:
branches: [main, develop]
paths:
@@ -27,15 +32,20 @@ on:
- 'AppImage/messages/**'
- 'AppImage/lib/i18n/**'
- 'AppImage/components/terminal-panel.tsx'
- 'web/**'
- 'CONTRIBUTING.md'
# Scheduler consumers and the offline extractor's .sh/.func inputs.
- 'scripts/**/*.sh'
- 'scripts/**/*.func'
- 'scripts/**/*.py'
- 'lang/*.json'
- 'menu'
- 'install_proxmenux.sh'
- 'install_proxmenux_beta.sh'
- 'oci/src/**/*.py'
- 'oci/catalog/**/*.json'
- 'oci/remote/**/*.sh'
- 'oci/remote/**/*.py'
workflow_dispatch:
permissions:
web/messages/de/docs/backup-restore/creating-backups.json
+220
View File
@@ -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."
}
]
}
}
web/messages/de/docs/backup-restore/cross-kernel.json
+170
View File
@@ -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."
}
]
}
}
web/messages/de/docs/backup-restore/destinations/borg.json
+234
View File
@@ -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."
}
]
}
}
web/messages/de/docs/backup-restore/destinations/index.json
+110
View File
@@ -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."
}
]
}
}
web/messages/de/docs/backup-restore/destinations/local.json
+75
View File
@@ -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."
}
}
web/messages/de/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -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/&lt;NAME&gt;.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/&lt;NAME&gt;.enc</code> ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe <code>-keyrecovery</code> vorhanden ist, deren neuester Snapshot heruntergeladen und die Wiederherstellungspassphrase zum Entschlüsseln abgefragt. Funktioniert beides nicht oder lehnt der Betreiber die Optionen ab, fragt der dritte Schritt nach dem absoluten Pfad der Schlüsseldatei auf diesem Host und kopiert sie an den kanonischen Pfad. Der Monitor bietet denselben Importablauf im Backup-Detaildialog. Oben erscheint ein gelbes Feld, wenn Wiederherstellen, Herunterladen oder Inhalt anzeigen eine nicht installierte Schlüsseldatei benötigen. Ist eine Datei installiert, passt aber nicht zum Backup, meldet PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Dieselben drei Aktionen zeigen dann ein strukturiertes gelbes Feld mit dem erforderlichen Manifest-Fingerabdruck an, damit der Betreiber die passende Schlüsseldatei für dieses Backup erkennen und importieren kann.",
"monitorManagementTitle": "Schlüsseldatei im Monitor verwalten",
"monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung direkt in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Es gibt drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Datei in den Browser des Betreibers; <em>Hochladen</em> ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; <em>Löschen</em> entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Jede Aktion nutzt dieselben Flask-Endpunkte wie die Terminaloberfläche. Die Wirkung auf Dateien und den PBS-Zustand ist deshalb bei beiden Oberflächen identisch."
},
"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."
}
]
}
}
web/messages/de/docs/backup-restore/glossary.json
+230
View File
@@ -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/&lt;id&gt;.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."
}
]
}
}
web/messages/de/docs/backup-restore/how-it-works.json
+205
View File
@@ -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-&lt;timestamp&gt;.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."
}
}
web/messages/de/docs/backup-restore/index.json
+93
View File
@@ -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/&lt;node&gt;/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."
}
]
}
}
web/messages/de/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/de/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -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."
}
]
}
}
web/messages/en/docs/backup-restore/cross-kernel.json
+101 -25
View File
@@ -20,9 +20,21 @@
"heading": "The direction check",
"intro": "During the compatibility check, <code>hb_compat_check</code> compares the kernel recorded in the backup's manifest against the target's current kernel (<code>uname -r</code>) and classifies the restore into one of three cases, stored in the internal variable <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{ "direction": "same", "condition": "The major kernel version matches between backup and target.", "behavior": "The full restore flow runs unchanged. No extra filter, no hydration, no special notice in the UI." },
{ "direction": "bk_newer", "condition": "Backup kernel is NEWER than the target's (for example: the backup was made on kernel 7.0 and the target runs kernel 6.17).", "behavior": "The full restore flow runs unchanged, exactly like <code>same</code>. No filter is applied. Verified empirically: drivers auto-reinstall against the target's kernel, IOMMU config applies cleanly, VMs with GPU passthrough come up without issue." },
{ "direction": "bk_older", "condition": "Backup kernel is OLDER than the target's (for example: the backup was made on kernel 6.17 and the target runs kernel 7.0).", "behavior": "The safe-subset filter and the four-phase hydration below are activated. The restore proceeds — the target reproduces the source, but boot-critical files are not copied verbatim." }
{
"direction": "same",
"condition": "The major kernel version matches between backup and target.",
"behavior": "The full restore flow runs unchanged. No extra filter, no hydration, no special notice in the UI."
},
{
"direction": "bk_newer",
"condition": "Backup kernel is NEWER than the target's (for example: the backup was made on kernel 7.0 and the target runs kernel 6.17).",
"behavior": "The full restore flow runs unchanged, exactly like <code>same</code>. No filter is applied. Verified empirically: drivers auto-reinstall against the target's kernel, IOMMU config applies cleanly, VMs with GPU passthrough come up without issue."
},
{
"direction": "bk_older",
"condition": "Backup kernel is OLDER than the target's (for example: the backup was made on kernel 6.17 and the target runs kernel 7.0).",
"behavior": "The safe-subset filter and the four-phase hydration below are activated. The restore proceeds — the target reproduces the source, but boot-critical files are not copied verbatim."
}
]
},
"whyBkNewerIsSafe": {
@@ -31,25 +43,60 @@
},
"safeSubsetFilter": {
"heading": "The safe-subset filter (only when the target kernel is newer)",
"intro": "When the target kernel is newer than the backup's, the compatibility check adds 16 boot-critical paths from <code>hb_unsafe_paths_cross_version</code> to <code>RS_SKIP_PATHS</code>. These paths are excluded from the restore because writing a version of them from an older kernel over a target running a newer one has caused kernel panics in bench tests. The paths cover four categories:",
"intro": "When the target kernel is newer than the backup's, the compatibility check adds 16 boot-critical paths from <code>hb_unsafe_paths_cross_version</code> to <code>RS_SKIP_PATHS</code>. These paths are excluded from the restore because writing a version of them from an older kernel over a target running a newer one has caused kernel panics in bench tests. The paths cover five categories:",
"categoryRows": [
{ "category": "Bootloader", "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>", "reason": "GRUB defaults tied to the prior kernel order, and proxmox-boot-tool state (cmdline, ESP UUIDs, hooks) that references paths and identifiers from the older install." },
{ "category": "Kernel modules and boot artifacts", "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>", "reason": "Autoload lists that may reference modules renamed between kernel majors, module options that may not apply, initramfs hooks written for the older kernel." },
{ "category": "Storage stack and filesystem identity", "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 that may not exist on this install, multipath drivers that change between kernels, iSCSI parameters that evolve, udev rules that may bind to nonexistent subsystems, ZFS state (<code>zpool.cache</code> + <code>hostid</code>) that can lock the pool as foreign." },
{ "category": "APT sources", "paths": "<code>/etc/apt</code>", "reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade." },
{ "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 and .wants tied to the older systemd major; configuration keys that may not parse on a newer systemd." }
{
"category": "Bootloader",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB defaults tied to the prior kernel order, and proxmox-boot-tool state (cmdline, ESP UUIDs, hooks) that references paths and identifiers from the older install."
},
{
"category": "Kernel modules and boot artifacts",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Autoload lists that may reference modules renamed between kernel majors, module options that may not apply, initramfs hooks written for the older kernel."
},
{
"category": "Storage stack and filesystem identity",
"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 that may not exist on this install, multipath drivers that change between kernels, iSCSI parameters that evolve, udev rules that may bind to nonexistent subsystems, ZFS state (<code>zpool.cache</code> + <code>hostid</code>) that can lock the pool as foreign."
},
{
"category": "APT sources",
"paths": "<code>/etc/apt</code>",
"reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade."
},
{
"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 and .wants tied to the older systemd major; configuration keys that may not parse on a newer systemd."
}
],
"outroBody": "The filter runs BEFORE the confirmation dialog so the user sees the exact list of paths that will be skipped, categorised by reason. The restore still proceeds — everything else (VMs, LXCs, network, /etc/pve, users, cron, ProxMenux state, packages, drivers, /root) is restored normally."
"outroBody": "The filter runs BEFORE the confirmation dialog so the user sees the exact list of paths that will be skipped, categorised by reason. The restore still proceeds — everything else (VM/LXC configuration, network, /etc/pve, users, cron, ProxMenux state, packages, drivers, /root) is restored normally."
},
"hydration": {
"heading": "Kernel-agnostic hydration",
"intro": "The safe-subset filter alone would leave the target without the tuning the user had inside those boot-critical files: IOMMU cmdline for GPU passthrough, VFIO device IDs, custom <code>GRUB_TIMEOUT</code>, nvidia blacklists. The hydration pass re-applies those bits kernel-agnostically. Four phases run when the target kernel is newer than the backup's, each additive (never overwrites a value the target already carries) and idempotent (running twice is a no-op).",
"intro": "The filter omits boot-critical files, so hydration reapplies selected user tuning: IOMMU cmdline, VFIO IDs, custom <code>GRUB_TIMEOUT</code> and nvidia blacklists. It runs when the target kernel is newer. Cmdline merges preserve existing target keys and module merges append missing entries. Whitelisted GRUB values and user files may replace differing target content. Repeating the same input is idempotent.",
"phaseRows": [
{ "phase": "1a — GRUB path", "detail": "For hosts using GRUB (ext4/lvm installs). <code>_rs_hyd_grub</code> merges every token from the backup's <code>manifest.kernel_params.cmdline_extra</code> into the target's live <code>GRUB_CMDLINE_LINUX_DEFAULT</code>, skipping tokens whose key the target already carries. Then merges whitelisted <code>GRUB_*</code> keys (<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>) from the backup's <code>/etc/default/grub</code> if they differ from the target's." },
{ "phase": "1b — systemd-boot / ZFS path", "detail": "For hosts using systemd-boot (typically ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> merges user tokens from <code>cmdline_extra</code> into the target's <code>/etc/kernel/cmdline</code>, keeping the target's own <code>root=</code>, <code>boot=</code> and <code>rootflags=</code> boilerplate intact." },
{ "phase": "2 — /etc/modules merge", "detail": "<code>_rs_hyd_modules</code> appends modules from <code>manifest.kernel_params.modules_loaded_at_boot</code> that are in the whitelist (<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>) AND not already present in the target's <code>/etc/modules</code>." },
{ "phase": "3 — Whitelisted files copy", "detail": "<code>_rs_hyd_files</code> copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, and the ProxMenux VFIO bind rule + nvidia udev rules under <code>/etc/udev/rules.d</code>. Distro-owned files (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) are intentionally excluded — their contents evolve between releases." },
{ "phase": "4 — Force post-boot reflows", "detail": "The four phases write directly to the live target OUTSIDE the normal restore pipeline. To make the merged tokens/modules/files take effect on the next boot, <code>HB_HYDRATION_APPLIED=1</code> propagates through <code>plan.env</code> to <code>apply_pending_restore.sh</code>, which forces <code>NEEDS_INITRAMFS=1</code> and <code>NEEDS_GRUB=1</code> regardless of what was in the apply list. The post-boot dispatcher then regenerates initramfs and refreshes the bootloader." }
{
"phase": "1a — GRUB path",
"detail": "For hosts using GRUB (ext4/lvm installs). <code>_rs_hyd_grub</code> merges every token from the backup's <code>manifest.kernel_params.cmdline_extra</code> into the target's live <code>GRUB_CMDLINE_LINUX_DEFAULT</code>, skipping tokens whose key the target already carries. Then merges whitelisted <code>GRUB_*</code> keys (<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>) from the backup's <code>/etc/default/grub</code> if they differ from the target's."
},
{
"phase": "1b — systemd-boot / ZFS path",
"detail": "For hosts using systemd-boot (typically ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> merges user tokens from <code>cmdline_extra</code> into the target's <code>/etc/kernel/cmdline</code>, keeping the target's own <code>root=</code>, <code>boot=</code> and <code>rootflags=</code> boilerplate intact."
},
{
"phase": "2 — /etc/modules merge",
"detail": "<code>_rs_hyd_modules</code> appends modules from <code>manifest.kernel_params.modules_loaded_at_boot</code> that are in the whitelist (<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>) AND not already present in the target's <code>/etc/modules</code>."
},
{
"phase": "3 — Whitelisted files copy",
"detail": "<code>_rs_hyd_files</code> copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, and the ProxMenux VFIO bind rule + nvidia udev rules under <code>/etc/udev/rules.d</code>. Distro-owned files (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) are intentionally excluded — their contents evolve between releases."
},
{
"phase": "4 — Force post-boot reflows",
"detail": "The four phases write directly to the live target OUTSIDE the normal restore pipeline. To make the merged tokens/modules/files take effect on the next boot, <code>HB_HYDRATION_APPLIED=1</code> propagates through <code>plan.env</code> to <code>apply_pending_restore.sh</code>, which forces <code>NEEDS_INITRAMFS=1</code> and <code>NEEDS_GRUB=1</code> regardless of what was in the apply list. The post-boot dispatcher then regenerates initramfs and refreshes the bootloader."
}
]
},
"planCommit": {
@@ -65,8 +112,14 @@
"heading": "Concrete examples",
"intro": "The hydration pass is not abstract — it produces observable, correct outcomes for common scenarios. Two examples that hydration handles automatically:",
"rows": [
{ "scenario": "GPU passthrough (VFIO)", "detail": "Source had <code>intel_iommu=on iommu=pt</code> in the cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, an <code>/etc/modprobe.d/vfio.conf</code> with <code>options vfio-pci ids=10de:2216</code>, and a <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to <code>/etc/modules</code>, and copies the two user-authored modprobe files. On the next boot, IOMMU is active, VFIO modules load, the GPU is bound to vfio-pci and the VM comes up with passthrough working." },
{ "scenario": "Custom GRUB defaults", "detail": "Source had <code>GRUB_TIMEOUT=1</code> and <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration reads both keys from the backup's <code>/etc/default/grub</code>, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including <code>GRUB_DISTRIBUTOR</code>, untouched)." }
{
"scenario": "GPU passthrough (VFIO)",
"detail": "Source had <code>intel_iommu=on iommu=pt</code> in the cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, an <code>/etc/modprobe.d/vfio.conf</code> with <code>options vfio-pci ids=10de:2216</code>, and a <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to <code>/etc/modules</code>, and copies the two user-authored modprobe files. On the next boot, IOMMU is active, VFIO modules load, the GPU is bound to vfio-pci and the VM comes up with passthrough working."
},
{
"scenario": "Custom GRUB defaults",
"detail": "Source had <code>GRUB_TIMEOUT=1</code> and <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration reads both keys from the backup's <code>/etc/default/grub</code>, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including <code>GRUB_DISTRIBUTOR</code>, untouched)."
}
]
},
"callout": {
@@ -77,18 +130,41 @@
"heading": "Where the mechanisms live",
"intro": "For developers looking to trace or extend the cross-kernel behaviour:",
"rows": [
{ "component": "Direction detection", "location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Sets <code>HB_COMPAT_KERNEL_DIRECTION</code>." },
{ "component": "Safe-subset path list", "location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emits <code>path\\treason</code> lines used by both the CLI filter and the Web endpoint <code>/api/host-backups/restore/prepare</code>." },
{ "component": "Hydration phases", "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>. Orchestrated by <code>_rs_apply_bk_older_hydration</code>." },
{ "component": "Post-boot reflow forcing", "location": "<code>apply_pending_restore.sh</code> reads <code>HB_HYDRATION_APPLIED</code> from <code>plan.env</code> and forces <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>. Sources the helper library, runs <code>_rs_apply_bk_older_hydration</code> in plan mode, returns the actions to the Web modal." }
{
"component": "Direction detection",
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Sets <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Safe-subset path list",
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emits <code>path\\treason</code> lines used by both the CLI filter and the Web endpoint <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Hydration phases",
"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>. Orchestrated by <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Post-boot reflow forcing",
"location": "<code>apply_pending_restore.sh</code> reads <code>HB_HYDRATION_APPLIED</code> from <code>plan.env</code> and forces <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>. Sources the helper library, runs <code>_rs_apply_bk_older_hydration</code> in plan mode, returns the actions to the Web modal."
}
]
},
"whereNext": {
"heading": "Where to go next",
"items": [
{ "label": "Restoring", "href": "/docs/backup-restore/restoring", "tail": " — the full restore pipeline this page's mechanisms plug into." },
{ "label": "How it works", "href": "/docs/backup-restore/how-it-works", "tail": " — the manifest and collectors that produce the <code>kernel_params</code> block hydration reads from." }
{
"label": "Restoring",
"href": "/docs/backup-restore/restoring",
"tail": " — the full restore pipeline this page's mechanisms plug into."
},
{
"label": "How it works",
"href": "/docs/backup-restore/how-it-works",
"tail": " — the manifest and collectors that produce the <code>kernel_params</code> block hydration reads from."
}
]
}
}
web/messages/en/docs/backup-restore/destinations/borg.json
+115 -29
View File
@@ -24,19 +24,47 @@
"heading": "The borg binary",
"intro": "Borg is not a base dependency of the ProxMenux installer. When a backup runs, <code>hb_ensure_borg</code> resolves the binary from four sources in order and returns the first that works:",
"rows": [
{ "priority": "1", "source": "System <code>borg</code>", "detail": "If the host already has <code>borg</code> installed via APT (<code>which borg</code> resolves), that binary is used." },
{ "priority": "2", "source": "State-dir cache", "detail": "<code>/usr/local/share/proxmenux/borg</code> — kept from a prior GitHub download on this host." },
{ "priority": "3", "source": "Monitor AppImage bundle", "detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working <code>borg</code>." },
{ "priority": "4", "source": "GitHub download", "detail": "<code>wget</code> against the pinned <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verified against a constant SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). On checksum mismatch the binary is discarded and the backup aborts. The downloaded file is cached in the state dir so subsequent backups use path 2." }
{
"priority": "1",
"source": "System <code>borg</code>",
"detail": "If the host already has <code>borg</code> installed via APT (<code>which borg</code> resolves), that binary is used."
},
{
"priority": "2",
"source": "State-dir cache",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — kept from a prior GitHub download on this host."
},
{
"priority": "3",
"source": "Monitor AppImage bundle",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working <code>borg</code>."
},
{
"priority": "4",
"source": "GitHub download",
"detail": "<code>wget</code> against the pinned <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verified against a constant SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). On checksum mismatch the binary is discarded and the backup aborts. The downloaded file is cached in the state dir so subsequent backups use path 2."
}
]
},
"repoTypes": {
"heading": "Repository types",
"intro": "The repository type is chosen when a target is added. Each type resolves to a different repository URL that Borg understands.",
"rows": [
{ "type": "remote", "url": "ssh://USER@HOST/RPATH", "detail": "Repository lives on a remote server that runs <code>borg serve</code>. Requires an SSH connection to that server." },
{ "type": "usb", "url": "/mnt/MOUNTPOINT/borgbackup", "detail": "Repository lives on a mounted external disk (typically USB). The mount is resolved via <code>hb_prompt_mounted_path</code>, which detects, mounts or formats USB partitions as needed." },
{ "type": "local", "url": "/backup/borgbackup (any absolute path)", "detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against operator error but not against disk failure." }
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "Repository lives on a remote server that runs <code>borg serve</code>. Requires an SSH connection to that server."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "Repository lives on a mounted external disk (typically USB). The mount is resolved via <code>hb_prompt_mounted_path</code>, which detects, mounts or formats USB partitions as needed."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against operator error but not against disk failure."
}
]
},
"serverSetup": {
@@ -50,30 +78,62 @@
"Another Proxmox host on the same LAN, or a VM anywhere reachable over SSH."
],
"lxcWarningTitle": "LXC as Borg server",
"lxcWarningBody": "If the Borg server runs inside an LXC, the container must have a user account with a password.",
"lxcWarningBody": "If the Borg server runs inside an LXC, generate-auto requires an account that accepts SSH password authentication during key installation. If password login is unavailable, use manual key installation or the generate-pct alternative through the PVE host.",
"requirementsTitle": "Requirements on the server",
"requirementsRows": [
{ "requirement": "borg binary at <code>/usr/bin/borg</code>", "detail": "The <code>command=\"/usr/bin/borg serve ...\"</code> line ProxMenux writes into <code>authorized_keys</code> hard-codes that path. Installing via APT (<code>apt install borgbackup</code>) puts it there. A standalone binary must be symlinked to <code>/usr/bin/borg</code>." },
{ "requirement": "A dedicated user account (typically <code>borg</code>)", "detail": "Owns the repository directory and receives incoming SSH connections. Does not need sudo or shell access — the authorized_keys line disables interactive shells anyway." },
{ "requirement": "A writable repository directory", "detail": "The path the operator gives ProxMenux (for example <code>/backup/borgbackup</code>) must exist on the server and be owned by the borg user." },
{ "requirement": "SSH daemon accepting the borg user", "detail": "<code>PubkeyAuthentication yes</code> (default). Password authentication is only needed for the one-shot <em>generate-auto</em> flow — after the key is installed, the server can disable password auth entirely." }
{
"requirement": "borg binary at <code>/usr/bin/borg</code>",
"detail": "The <code>command=\"/usr/bin/borg serve ...\"</code> line ProxMenux writes into <code>authorized_keys</code> hard-codes that path. Installing via APT (<code>apt install borgbackup</code>) puts it there. A standalone binary must be symlinked to <code>/usr/bin/borg</code>."
},
{
"requirement": "A dedicated user account (typically <code>borg</code>)",
"detail": "Owns the repository directory and receives incoming SSH connections. Does not need sudo or shell access — the authorized_keys line disables interactive shells anyway."
},
{
"requirement": "A writable repository directory",
"detail": "The path the operator gives ProxMenux (for example <code>/backup/borgbackup</code>) must exist on the server and be owned by the borg user."
},
{
"requirement": "SSH daemon accepting the borg user",
"detail": "<code>PubkeyAuthentication yes</code> (default). Password authentication is only needed for the one-shot <em>generate-auto</em> flow — after the key is installed, the server can disable password auth entirely."
}
],
"minimalSetupTitle": "Minimal server setup",
"minimalSetupBody": "On a Debian or Ubuntu Borg server, a working baseline is four commands as root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "After this, ProxMenux's <code>generate-auto</code> mode can connect using the borg user's password once, install its own SSH key, and every subsequent backup uses that key. No further server-side configuration is needed — the key restricts itself to <code>borg serve</code> on that path."
"minimalSetupNote": "With the server prepared and SSH password authentication available, ProxMenux’s <code>generate-auto</code> mode can install its SSH key using an account permitted to write the borg user’s authorized_keys file. Subsequent backups use that key, restricted to <code>borg serve</code> on the configured path. Without password login, install the key manually or use the PVE-host alternative."
},
"sshAuth": {
"heading": "SSH authentication (client side)",
"intro": "Remote Borg repositories are accessed over SSH. The connection runs from the ProxMenux host to a user account on the Borg server that runs <code>borg serve</code>. This user is typically named <code>borg</code>, NOT the admin/root user of the server — the borg-serve command line locks the connection to that specific repository path (see the key strategies below).",
"strategiesTitle": "The four key strategies",
"strategiesIntro": "When a remote target is added, ProxMenux prompts for the SSH user, host and remote path, then asks how to authenticate. Four modes:",
"strategiesTitle": "SSH key strategies",
"strategiesIntro": "When a remote target is added, ProxMenux asks for the SSH user, host and remote path, then offers four authentication choices. The additional generate-pct path is offered when password authentication is refused. The modes are described below:",
"strategyRows": [
{ "mode": "generate-auto", "label": "Recommended", "detail": "ProxMenux generates a new ed25519 keypair at <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, then uses <code>sshpass</code> to log in ONCE to the server with the admin password and append the public key to <code>~borg/.ssh/authorized_keys</code>. The admin password is only used for this one call — it is never stored." },
{ "mode": "generate-manual", "label": "No admin password on this host", "detail": "ProxMenux generates the keypair as above but displays the full <code>authorized_keys</code> line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for." },
{ "mode": "generate-pct", "label": "Borg server is a PVE LXC", "detail": "The Borg server runs inside an LXC on a PVE node. ProxMenux authorises the key via <code>pct exec</code> from the PVE host — root on the PVE host writes into the LXC's <code>~borg/.ssh/authorized_keys</code> without needing SSH into the LXC itself." },
{ "mode": "existing", "label": "Use an existing key", "detail": "ProxMenux scans <code>/root/.ssh/</code> and <code>$HOME/.ssh/</code> for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path." },
{ "mode": "none", "label": "Default SSH config", "detail": "No custom key — Borg relies on the host's default SSH configuration (typically <code>~/.ssh/id_rsa</code> or an SSH agent)." }
{
"mode": "generate-auto",
"label": "Recommended",
"detail": "ProxMenux generates or reuses an ed25519 keypair at <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, then uses <code>sshpass</code> for a login probe and installation of the public key in <code>~borg/.ssh/authorized_keys</code>. The password belongs to an account allowed to write that file, usually root or the borg user. It is used during setup and is not saved."
},
{
"mode": "generate-manual",
"label": "No admin password on this host",
"detail": "ProxMenux generates the keypair as above but displays the full <code>authorized_keys</code> line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for."
},
{
"mode": "generate-pct",
"label": "Borg server is a PVE LXC",
"detail": "The Borg server runs inside an LXC on a PVE node. ProxMenux authorises the key via <code>pct exec</code> from the PVE host — root on the PVE host writes into the LXC's <code>~borg/.ssh/authorized_keys</code> without needing SSH into the LXC itself."
},
{
"mode": "existing",
"label": "Use an existing key",
"detail": "ProxMenux scans <code>/root/.ssh/</code> and <code>$HOME/.ssh/</code> for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path."
},
{
"mode": "none",
"label": "Default SSH config",
"detail": "No custom key — Borg relies on the host's default SSH configuration (typically <code>~/.ssh/id_rsa</code> or an SSH agent)."
}
],
"restrictTitle": "The authorized_keys line",
"restrictBody": "For every generated key, the <code>authorized_keys</code> line ProxMenux writes on the server locks the key to a single borg-serve invocation against the configured repository path:",
@@ -84,24 +144,50 @@
"heading": "Saved targets",
"intro": "A saved target persists the repository configuration under a friendly name so the details do not have to be re-entered. Storage layout in the ProxMenux state directory:",
"rows": [
{ "file": "borg-targets.txt", "content": "One line per target: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Read by <code>hb_collect_borg_configs</code> to populate the target-selection menu." },
{ "file": "borg-pass-NAME.txt", "content": "Passphrase for the target NAMEd above (<code>chmod 600</code>). Only present when the operator chose repokey encryption." }
{
"file": "borg-targets.txt",
"content": "One line per target: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Read by <code>hb_collect_borg_configs</code> to populate the target-selection menu."
},
{
"file": "borg-pass-NAME.txt",
"content": "Passphrase for the target NAMEd above (<code>chmod 600</code>). Only present when the operator chose repokey encryption."
}
],
"outro": "Saving is optional — the operator can decline the save prompt for a one-shot backup that leaves no credentials on the host."
"outro": "Saving the target is optional. Declining the save prompt omits the named target configuration, but does not remove a generated SSH key. If repokey encryption is enabled without a saved target, ProxMenux still saves the passphrase in the legacy borg-pass.txt file."
},
"encryption": {
"heading": "Encryption",
"body": "Repositories are initialised with an encryption mode via <code>hb_borg_init_if_needed</code>: the modern <code>borg repo-create -e MODE</code> when available, or the legacy <code>borg init --encryption=MODE</code>. ProxMenux exposes two modes: <code>repokey</code> (default) and <code>none</code>. In <code>repokey</code> mode Borg stores the encryption key inside the repository itself; access requires a passphrase, which ProxMenux prompts for twice with match validation and stores at <code>borg-pass-NAME.txt</code>. A mandatory acknowledgement dialog is shown after the passphrase is saved: the passphrase is the only way to access the encrypted archives, and losing it makes every archive in the repository unrecoverable."
"body": "Repositories are initialised with an encryption mode via <code>hb_borg_init_if_needed</code>: the modern <code>borg repo-create -e MODE</code> when available, or the legacy <code>borg init --encryption=MODE</code>. ProxMenux exposes two modes: <code>repokey</code> (default) and <code>none</code>. In <code>repokey</code> mode Borg stores the encryption key inside the repository itself; access requires a passphrase, which ProxMenux prompts for twice with match validation and stores at <code>borg-pass-NAME.txt</code> for saved targets (or in the legacy file described above). A mandatory acknowledgement dialog is shown after the passphrase is saved: the passphrase is the only way to access the encrypted archives, and losing it makes every archive in the repository unrecoverable."
},
"runtimeEnv": {
"heading": "Runtime environment",
"intro": "ProxMenux exports the following environment variables before invoking <code>borg</code>. They configure the connection and unlock the repository without embedding secrets in the command line.",
"rows": [
{ "var": "BORG_RSH", "value": "ssh -i SSH_KEY_PATH -o StrictHostKeyChecking=accept-new", "purpose": "The remote-shell command Borg uses for SSH-served repositories. Set only when a custom key was selected; otherwise unset so Borg uses the default SSH configuration." },
{ "var": "BORG_PASSPHRASE", "value": "(passphrase from borg-pass-NAME.txt)", "purpose": "Unlocks the repokey. Set only when the target uses <code>repokey</code> encryption. Never appears in the process argument list." },
{ "var": "BORG_ENCRYPT_MODE", "value": "repokey | none", "purpose": "Used by <code>hb_borg_init_if_needed</code> when initialising a repository that does not yet exist. Ignored by <code>borg create</code> on existing repositories." },
{ "var": "BORG_RELOCATED_REPO_ACCESS_IS_OK", "value": "yes", "purpose": "Suppresses the interactive prompt Borg raises when the repository URL differs from the URL it was originally reached from (common after a mount-point rename or SSH-host reachable via new address)." },
{ "var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK", "value": "yes", "purpose": "Suppresses the interactive prompt Borg raises the first time an unencrypted repository is accessed from a new client." }
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "The remote-shell command Borg uses for SSH repositories. A selected key adds the identity options; a non-default port adds -p PORT. With no custom key and the default port, the variable is unset so Borg uses the host’s default SSH configuration."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passphrase from borg-pass-NAME.txt)",
"purpose": "Unlocks the repokey. Set only when the target uses <code>repokey</code> encryption. Never appears in the process argument list."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Used by <code>hb_borg_init_if_needed</code> when initialising a repository that does not yet exist. Ignored by <code>borg create</code> on existing repositories."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suppresses the interactive prompt Borg raises when the repository URL differs from the URL it was originally reached from (common after a mount-point rename or SSH-host reachable via new address)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suppresses the interactive prompt Borg raises the first time an unencrypted repository is accessed from a new client."
}
]
},
"archiveFormat": {
web/messages/en/docs/backup-restore/destinations/index.json
+3 -3
View File
@@ -14,7 +14,7 @@
},
"intro": {
"title": "Same payload, three backends",
"body": "Every backup produces the same three payloads (rootfs, manifest, applications). What changes between destinations is how those payloads are stored and how the operator retrieves them for a restore. Each backend is implemented as a separate function in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — but all four share the same staging step (<code>hb_prepare_staging</code>) and the same restore code path. The choice of destination only affects the write and the retrieval; it does not change what a restore does or how it consumes the archive."
"body": "Every backup produces the same three payloads (rootfs, manifest, applications). What changes between destinations is how those payloads are stored and how the operator retrieves them for a restore. Each backend is implemented as a separate function in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — but all three share the same staging step (<code>hb_prepare_staging</code>) and the same restore code path. The choice of destination only affects the write and the retrieval; it does not change what a restore does or how it consumes the archive."
},
"comparison": {
"heading": "Feature comparison",
@@ -29,8 +29,8 @@
{
"feature": "Compression",
"local": "zstd (default level) via <code>tar --zstd</code>. gzip fallback.",
"pbs": "PBS-managed. The client streams uncompressed; the server chunks + compresses.",
"borg": "Borg's built-in (lz4 default). Configurable at repo init."
"pbs": "Managed by proxmox-backup-client. ProxMenux does not override compression settings.",
"borg": "Borg’s built-in compression. ProxMenux invokes borg create without overriding compression settings."
},
{
"feature": "Deduplication",
web/messages/en/docs/backup-restore/destinations/pbs.json
+3 -3
View File
@@ -41,7 +41,7 @@
},
"backupCommand": {
"heading": "The backup command",
"intro": "The upload is a single invocation of <code>proxmox-backup-client backup</code>. ProxMenux runs it inside an <code>env</code> wrapper so credentials never appear in the process argument list.",
"intro": "The upload is a single invocation of <code>proxmox-backup-client backup</code>. ProxMenux uses <code>env</code> to pass the password, encryption password and fingerprint to the client as environment variables.",
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
"backupIdTitle": "Backup ID naming",
"backupIdBody": "The default backup ID is <code>hostcfg-HOSTNAME</code>. The operator is asked to confirm or edit it before the upload; any characters outside <code>[A-Za-z0-9_-]</code> are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a <em>group</em>, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.",
@@ -61,13 +61,13 @@
"modesSharedTitle": "Shared keyfile (import on every host)",
"modesSharedBody": "One master keyfile generated once and installed on every host via the <em>Use an existing keyfile</em> option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.",
"recoveryTitle": "Upload key to PBS — the operator decides",
"recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>Nothing gets uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays only at the canonical local path, ProxMenux never touches PBS with any recovery artefact, and the operator handles the offsite copy themselves (the Monitor's <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce <code>pbs-key.recovery.enc</code>. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile ever leaves the host. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
"recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>No recovery artifact is uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays at the canonical local path, ProxMenux uploads no recovery artifact to PBS, and the operator handles the offsite copy themselves (the Monitor’s <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce <code>pbs-key.recovery.enc</code>. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile is sent to PBS during these uploads. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
"blobUploadTitle": "Paired backup group on PBS",
"blobUploadBody1": "When the escrow mode is <em>Yes, upload</em>, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in <code>-keyrecovery</code>. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. <strong>The envelope never leaves the host in plaintext</strong>: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS receives only the already-encrypted envelope.",
"envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?",
"envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the operator holds both.",
"blobUploadConstraintTitle": "Why two groups instead of a single encrypted one",
"blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by PBS with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
"blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by the PBS client with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
"blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.",
"blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.",
"recoverTitle": "Recovery on a fresh host",
web/messages/en/docs/backup-restore/glossary.json
+2 -2
View File
@@ -28,7 +28,7 @@
{
"id": "clave-cifrado",
"term": "Keyfile (encryption key)",
"def": "Binary file that Proxmox Backup Server uses to encrypt the <a href=\"#chunk\">chunks</a> of each backup before uploading them. Without this file, no encrypted backup can be read. ProxMenux stores it at <code>/usr/local/share/proxmenux/pbs-key.conf</code> with mode <code>600</code>. This is the asset that has to be protected; the <a href=\"#sobre-recuperacion\">recovery envelope</a> exists precisely so that this file can be rescued if it is lost."
"def": "Key file used by proxmox-backup-client to encrypt the <a href=\"#chunk\">chunks</a> before uploading them to PBS. Without the matching key, encrypted backup data cannot be read. ProxMenux stores the file at <code>/usr/local/share/proxmenux/pbs-key.conf</code> with mode <code>600</code>. Protect it: the <a href=\"#sobre-recuperacion\">recovery envelope</a> is designed to recover this file if it is lost."
},
{
"id": "contrasena-keyfile",
@@ -156,7 +156,7 @@
{
"id": "modo-adjunto",
"term": "Attach mode",
"def": "Scheduled job with no schedule of its own; it fires automatically whenever an existing PVE <code>vzdump</code> task runs. It inherits the schedule and retention from that parent task. Supported for Local and PBS destinations only."
"def": "Job without its own timer. A PVE <code>vzdump</code> job-end hook triggers it after guest backups when the destination storage matches. The selected parent supplies storage and initial retention, but the hook matches storage rather than parent job ID; another task using that storage may also trigger it. Supported for Local and PBS only."
},
{
"id": "timer-systemd",
web/messages/en/docs/backup-restore/how-it-works.json
+3 -3
View File
@@ -14,7 +14,7 @@
},
"intro": {
"title": "One archive, three payloads",
"body": "Every backup produces a directory layout with three well-defined payloads under a single staging root. The archive uploaded to the destination (local <code>.tar.zst</code>, PBS backup or Borg archive) contains this exact layout. The restore reads the three payloads independently, in a specific order that guarantees correctness: <strong>rootfs</strong> is copied first to lay down configuration, <strong>the manifest</strong> is consulted to detect drift and decide what to skip, and <strong>the application inventory</strong> drives the post-boot reinstall pass. No cross-payload dependencies — each one can be inspected or extracted independently."
"body": "Every backup produces a directory layout with three well-defined payloads under a single staging root. The archive uploaded to the destination (local <code>.tar.zst</code>, PBS backup or Borg archive) contains this exact layout. The restore uses all three: <strong>the manifest</strong> is consulted before applying changes to detect drift and decide what to skip; <strong>rootfs</strong> supplies the configuration files, applied live or deferred until reboot; and <strong>the application inventory</strong> drives package installation and the post-boot component reinstall. Each payload can be inspected or extracted independently."
},
"layout": {
"heading": "Archive layout",
@@ -26,7 +26,7 @@
"heading": "The rootfs payload",
"intro": "The <code>rootfs/</code> tree is a <strong>plain filesystem copy</strong> produced by <code>rsync</code> from the source host. It contains a curated <strong>default profile</strong> of paths that matter for a Proxmox restore, plus any <strong>custom paths</strong> added by the user to the backup job or interactive session. The set is deliberately narrow: only paths that either <em>hold configuration</em> or <em>hold state that Proxmox cannot regenerate on its own</em>.",
"defaultProfileTitle": "The default profile",
"defaultProfileBody": "The default profile is defined by <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. It covers eight categories that together describe a working Proxmox host:",
"defaultProfileBody": "The default profile is defined by <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. It covers eight fixed categories, plus conditional ZFS state, that together describe a working Proxmox host:",
"categoriesTitle": "Path categories",
"categoryRows": [
{
@@ -125,7 +125,7 @@
},
"applications": {
"heading": "The application inventory",
"intro": "Two files under <code>metadata/</code> catalogue everything installed on the source that is not part of the base Proxmox VE package set. The restore uses them to reproduce the exact set of user-installed software on the target, using either APT or ProxMenux's own installers depending on how the software was originally installed.",
"intro": "Two inventories catalogue the software installed on the source beyond the base Proxmox VE package set: the package list under <code>metadata/</code> and the component registry inside rootfs, detailed below. The restore uses them to reproduce user-installed software with APT or ProxMenux’s own installers, depending on how it was originally installed.",
"packagesTitle": "packages.manual.list",
"packagesBody": "A plain-text list produced by <code>apt-mark showmanual</code>: every APT package that was <em>explicitly installed</em> on the source host, sorted alphabetically. This excludes packages installed as dependencies of the base Proxmox VE ISO (they are re-pulled automatically by the target's own APT). Read by <code>_rs_run_complete_extras</code> during restore, filtered through a three-pass <em>cascade-safe</em> filter (<code>dpkg -s</code> for already-installed, sibling-major detection for library packages, <code>apt-get install --simulate</code> for cascade-remove risk), then installed with <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (part of the rootfs)",
web/messages/en/docs/backup-restore/restoring.json
+10 -10
View File
@@ -14,7 +14,7 @@
},
"intro": {
"title": "The restore reproduces the source, not just the files",
"body": "Restoring a ProxMenux backup is not an extraction. Files are only the first step: after the filesystem is in place, the restore reads the manifest to detect differences between source and target, filters paths that would break the target's boot, hydrates user-authored tuning that cannot be copied verbatim, and — after the mandatory reboot — reinstalls every component the source had (NVIDIA driver, Coral TPU, GPU tools) against the target's own kernel. What the user picks from the menu is a single archive; what actually happens involves the compatibility check, the path classification, the on-boot dispatcher and the post-boot pass working together to produce a host that behaves like the source."
"body": "Restoring a ProxMenux backup involves more than extracting files. Before applying changes, the restore reads the manifest to detect differences between source and target, filters paths that could break the target’s boot and adapts user-authored tuning that cannot be copied verbatim. After the required reboot, it attempts to reinstall the recorded supported components (NVIDIA driver, Coral TPU, GPU tools) for the target’s running kernel. A single selected archive drives the compatibility check, path classification, on-boot dispatcher and post-boot work. Review the per-component results and logs to confirm the outcome."
},
"threeActions": {
"heading": "Three actions on a backup",
@@ -52,7 +52,7 @@
},
{
"output": "Rollback plan",
"detail": "Computed by <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but not in the backup. The user opts in during the confirmation dialog to have these removed as part of the restore, so the target ends up matching the backup exactly."
"detail": "Computed by <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but absent from the backup. The confirmation dialog offers optional removal of the extra guests before reboot. Component removal remains manual, and guest deletion can fail, so this does not guarantee an exact match with the backup."
}
],
"reportBody": "The check also emits a structured report (<code>HB_COMPAT_RESULTS</code>) categorised as PASS / INFO / WARN / FAIL. WARN and FAIL entries surface in the pre-restore panel; the restore refuses to proceed only when a FAIL is present that the user cannot resolve by clicking Continue."
@@ -81,11 +81,11 @@
},
{
"class": "reboot",
"detail": "Paths applied <strong>immediately</strong> as well, but whose actual effect only kicks in on the <strong>next boot</strong>: the kernel only reads <code>/etc/default/grub</code> when the bootloader starts, <code>/etc/fstab</code> when filesystems are mounted at boot, <code>/etc/modules</code> when modules are loaded, etc. The file is in place the moment it is applied but the system has to reboot to consume it. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
"detail": "Paths deferred to the <strong>next boot</strong>, rather than applied <strong>immediately</strong> by this restore flow. They affect boot-time configuration: bootloader generation reads <code>/etc/default/grub</code>, filesystem mounting uses <code>/etc/fstab</code>, and module loading uses <code>/etc/modules</code>. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
},
{
"class": "dangerous",
"detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount; writing directly to it bypasses it), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
"detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount holding active cluster configuration), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
}
]
},
@@ -131,7 +131,7 @@
},
{
"task": "Component auto-reinstall",
"detail": "Reads the restored <code>components_status.json</code> and iterates over the registered installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each installer runs in <code>--auto-reinstall</code> mode, reads its previously-recorded version from the state file, and rebuilds against the target's current kernel. The interactive flow does not do this — reinstalling drivers against a kernel that has not yet booted is meaningless."
"detail": "Reads the restored <code>components_status.json</code> and iterates over the registered supported installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each selected installer runs in <code>--auto-reinstall</code> mode, reads its recorded state and reinstalls for the target’s environment, rebuilding kernel modules when applicable. This is deferred until after reboot so the installers use the kernel then running on the target. Individual failures are recorded and do not stop the next component."
},
{
"task": "Boot sanity check",
@@ -145,7 +145,7 @@
},
"liveProgress": {
"heading": "Live progress in the Monitor's Backups tab",
"body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>apply_cluster_postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
"body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>proxmenux-apply-cluster-postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
"fields": [
{
"name": "Status badge",
@@ -184,9 +184,9 @@
},
"postbootExample": {
"heading": "What the post-boot looks like on the console",
"body": "On the host's physical console, a successful dispatcher run ends with a <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code> line. When that line appears — usually alongside the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code> — the restore is completely finished: components reinstalled, boot artifacts regenerated, cluster reconciled.",
"body": "On the host’s physical console, a dispatcher run that exits successfully ends with <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>, often near the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code>. This marks the end of the dispatcher process. Individual component failures or boot warnings can still have been recorded; check the Monitor’s component states and logs before treating the host as fully restored.",
"imageAlt": "Proxmox physical console showing '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).' followed by the OK for multi-user.target and graphical.target, with the host login prompt above.",
"imageCaption": "Physical console after a successful post-boot. The 'Finished proxmenux-apply-cluster-postboot.service' line is the signal that the restore flow is fully complete — the same event the 'Host restore finished' notification surfaces in the Monitor."
"imageCaption": "Physical console after the dispatcher process finishes. 'Finished proxmenux-apply-cluster-postboot.service' marks process completion, also reported by 'Host restore finished' in the Monitor. Component results and warnings still need review."
},
"tenMinutes": {
"heading": "Why the last ten minutes matter",
@@ -228,11 +228,11 @@
"detail": "Cheap. The user learns the run completed the moment the notification fires."
}
],
"outroBody": "The window matters because the user can log in during this time and see missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected). This is expected — the reinstall is still running in the background. The completion notification signals when everything is ready."
"outroBody": "During this window a login may show missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected) because reinstall work is still running in the background. The completion notification marks the end of that work; check component results, warnings and logs to distinguish success from individual failures."
},
"destructiveRollback": {
"heading": "The optional destructive rollback",
"body": "A restore is additive by default: if the target has VMs, LXCs or components that are not in the backup, they survive. This preserves work but can leave stale hostpci entries, orphan components or VMs the user no longer wants. When drift is detected between target and backup, the confirmation dialog offers a second yes/no: <em>Execute destructive rollback?</em>. Accepting it triggers <code>_rs_execute_rollback</code>, which deletes the VMs, LXCs and components that exist on the target but not in the backup. The rollback runs BEFORE the reboot so that the pending restore machinery sees a clean state. This is opt-in — the default is No, and the user sees exactly what would be removed listed by name (VMID and CTID) before deciding."
"body": "A restore is additive by default: extra VMs, LXCs and components on the target remain. When differences are detected, the confirmation dialog offers <em>Execute destructive rollback?</em>, defaulting to No. Accepting calls <code>_rs_execute_rollback</code> before reboot to attempt deletion of listed extra VMs and LXCs. Components are flagged for manual uninstall because automatic uninstall is not implemented. Guest deletion failures are reported and processing continues, so an exact match with the backup is not guaranteed. Review the listed names and VMIDs/CTIDs before choosing this destructive option."
},
"logs": {
"heading": "Where the logs live",
web/messages/en/docs/backup-restore/scheduled-jobs.json
+82 -21
View File
@@ -22,7 +22,7 @@
},
"attachBadge": {
"title": "Attach mode — recommended when a PVE vzdump task already exists",
"body": "When a PVE vzdump backup task is already configured for the VMs and LXCs on this node, attaching the host backup to that task guarantees the host configuration is captured in the <strong>same window</strong> as the guests. On restore, the guest configs come from the host backup (they live under <code>/etc/pve</code>), and the guest disks come from the vzdump backup taken alongside — both sets are consistent with each other, so a full-node recovery can reproduce the host and re-attach every guest without version drift."
"body": "When a PVE vzdump backup task is already configured for the VMs and LXCs on this node, attaching the host backup runs it after the guest backup job, in the <strong>same backup cycle</strong>. On restore, guest configurations come from the host backup (under <code>/etc/pve</code>) and guest disks come from the vzdump backups taken in that cycle. This helps coordinate a full-node recovery, but is not an atomic snapshot: changes made during the backup cycle can leave differences between host configuration and guest disk state."
},
"frequencyBadge": {
"title": "Recommended frequency",
@@ -31,29 +31,63 @@
"modes": {
"heading": "The two modes",
"rows": [
{ "mode": "New scheduled job", "backends": "Local, PBS, Borg", "schedule": "Own <code>OnCalendar</code> expression (systemd calendar syntax — e.g. <code>daily</code>, <code>Mon..Fri 03:00</code>).", "retention": "Prompted separately: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applied by the runner after each successful backup." },
{ "mode": "Attach to a PVE vzdump job", "backends": "Local, PBS (Borg has no PVE-side scheduler)", "schedule": "Inherited from the parent PVE job. No systemd timer is installed on the ProxMenux side.", "retention": "Inherited from the parent's <code>prune-backups</code> configuration (mapped one-to-one to the runner's <code>KEEP_*</code> variables via <code>hb_pve_prune_to_keep_env</code>)." }
{
"mode": "New scheduled job",
"backends": "Local, PBS, Borg",
"schedule": "Own <code>OnCalendar</code> expression (systemd calendar syntax — e.g. <code>daily</code>, <code>Mon..Fri 03:00</code>).",
"retention": "Prompted separately: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applied by the runner after each successful backup."
},
{
"mode": "Attach to a PVE vzdump job",
"backends": "Local, PBS (Borg has no PVE-side scheduler)",
"schedule": "Inherited from the parent PVE job. No systemd timer is installed on the ProxMenux side.",
"retention": "Inherited from the parent's <code>prune-backups</code> configuration (mapped one-to-one to the runner's <code>KEEP_*</code> variables via <code>hb_pve_prune_to_keep_env</code>)."
}
]
},
"attachDetail": {
"heading": "How attach mode works",
"intro": "PVE writes <code>vzdump</code> tasks to <code>/etc/pve/jobs.cfg</code> — one stanza per task, each pointing at a storage where the VM and LXC dumps land. Attach mode requires that storage to be a backend ProxMenux understands (Local or PBS); when the task fires, ProxMenux runs alongside it.",
"intro": "PVE writes <code>vzdump</code> tasks to <code>/etc/pve/jobs.cfg</code> — one stanza per task, each pointing at a storage where the VM and LXC dumps land. Attach mode requires a backend ProxMenux understands (Local or PBS). The host backup runs from the job-end hook after the guest backup job finishes.",
"steps": [
{ "step": "1", "detail": "During job creation, ProxMenux lists compatible parent PVE tasks via <code>hb_pve_list_vzdump_jobs_for_backend</code>. The user picks one." },
{ "step": "2", "detail": "The job's <code>.env</code> is written with <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> and the inherited <code>KEEP_*</code> values; no systemd timer is created." },
{ "step": "3", "detail": "<code>hb_install_vzdump_hook</code> registers a script-hook in <code>/etc/vzdump.conf</code>. When PVE runs any vzdump task, the hook script fires; if the <code>$STOREID</code> passed to it matches an attached job's <code>PVE_STORAGE</code>, the runner is invoked for that job." },
{ "step": "4", "detail": "The archive lands in the same storage the vzdump dumps just wrote to: <code>path/dump/</code> for Local, or the PBS repository configured on the PVE storage entry." }
{
"step": "1",
"detail": "During job creation, ProxMenux lists compatible parent PVE tasks via <code>hb_pve_list_vzdump_jobs_for_backend</code>. The user picks one."
},
{
"step": "2",
"detail": "The job's <code>.env</code> is written with <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> and the inherited <code>KEEP_*</code> values; no systemd timer is created."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> registers a script-hook in <code>/etc/vzdump.conf</code>. In the job-end phase of any vzdump task, it compares the supplied <code>$STOREID</code> with each enabled attached job’s <code>PVE_STORAGE</code> and invokes the runner for matching jobs. The match is by storage, not by the selected parent job ID."
},
{
"step": "4",
"detail": "The archive lands in the same storage the vzdump dumps just wrote to: <code>path/dump/</code> for Local, or the PBS repository configured on the PVE storage entry."
}
],
"outroBody": "Attach mode has one operational implication: disabling or deleting the parent PVE task also disables the host backup — there is no timer of its own to fall back on. The job entry stays on disk so it can be re-attached later."
"outroBody": "Attach mode has no timer of its own. Disabling or deleting the selected parent PVE task stops that task’s trigger, but another vzdump task using the same storage can still trigger the attached host backup. Disable or delete the ProxMenux job itself to prevent that. The job entry remains on disk when disabled and can be re-enabled or re-attached later."
},
"storageLayout": {
"heading": "Files that make up a job",
"intro": "Every scheduled job is fully described by three or four files on disk. Reading them gives the full configuration of the job without relying on the interface.",
"rows": [
{ "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env", "content": "Backend, backup ID or destination, schedule (New mode) or PVE parent (Attach mode), enabled flag, retention <code>KEEP_*</code> values, credentials pointers." },
{ "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths", "content": "One absolute path per line — the frozen selection resolved from the profile at job-creation time. Editing the file re-runs the job with the new selection on the next timer fire." },
{ "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service", "content": "New mode only. The service invokes <code>run_scheduled_backup.sh JOB_ID</code>. The timer schedules it with <code>Persistent=true</code> (missed fires run at next boot) and a small <code>RandomizedDelaySec=120</code> to spread load when multiple jobs share the same OnCalendar expression." },
{ "path": "/etc/vzdump.conf script-hook", "content": "Attach mode only. Installed once by <code>hb_install_vzdump_hook</code>; matches every attached job's <code>PVE_STORAGE</code> against the <code>$STOREID</code> PVE passes to the hook script." }
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Backend, backup ID or destination, schedule (New mode) or PVE parent (Attach mode), enabled flag, retention <code>KEEP_*</code> values, credentials pointers."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "One absolute path per line — the frozen selection resolved from the profile at job-creation time. Editing the file re-runs the job with the new selection on the next timer fire."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "New mode only. The service invokes <code>run_scheduled_backup.sh JOB_ID</code>. The timer schedules it with <code>Persistent=true</code> (missed fires run at next boot) and a small <code>RandomizedDelaySec=120</code> to spread load when multiple jobs share the same OnCalendar expression."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Attach mode only. Installed once by <code>hb_install_vzdump_hook</code>; matches every attached job's <code>PVE_STORAGE</code> against the <code>$STOREID</code> PVE passes to the hook script."
}
]
},
"runner": {
@@ -69,11 +103,26 @@
"heading": "Managing jobs",
"intro": "The scheduler menu (Scripts TUI) and the Monitor Backups tab expose the same actions on any job.",
"rows": [
{ "action": "Run now", "detail": "Invokes the runner immediately, bypassing the timer / vzdump hook. Useful to verify a job configuration without waiting for the next scheduled fire." },
{ "action": "Enable / Disable", "detail": "New mode: <code>systemctl enable/disable --now</code> the timer. Attach mode: flips the <code>ENABLED</code> flag in the job env — the hook script honours it on the next PVE fire." },
{ "action": "Edit", "detail": "Reopens the destination, schedule, profile and retention prompts and rewrites the job files. Preserves the job ID." },
{ "action": "Delete", "detail": "Removes the job env, paths file, systemd timer + service (New mode), and disables the hook binding (Attach mode). Does not touch archives already on the destination." },
{ "action": "View log", "detail": "Streams <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — one log file per run. The runner also emits a compact status line to journald under the systemd service." }
{
"action": "Run now",
"detail": "Invokes the runner immediately, bypassing the timer / vzdump hook. Useful to verify a job configuration without waiting for the next scheduled fire."
},
{
"action": "Enable / Disable",
"detail": "New mode: <code>systemctl enable/disable --now</code> the timer. Attach mode: flips the <code>ENABLED</code> flag in the job env — the hook script honours it on the next PVE fire."
},
{
"action": "Edit",
"detail": "Reopens the destination, schedule, profile and retention prompts and rewrites the job files. Preserves the job ID."
},
{
"action": "Delete",
"detail": "Removes the job env, paths file, systemd timer + service (New mode), and disables the hook binding (Attach mode). Does not touch archives already on the destination."
},
{
"action": "View log",
"detail": "Streams <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — one log file per run. The runner also emits a compact status line to journald under the systemd service."
}
]
},
"notifications": {
@@ -83,9 +132,21 @@
"whereNext": {
"heading": "Where to go next",
"items": [
{ "label": "Creating backups", "href": "/docs/backup-restore/creating-backups", "tail": " — the interactive flow that shares the backend with the scheduler." },
{ "label": "Destinations", "href": "/docs/backup-restore/destinations", "tail": " — per-backend configuration used by both the interactive flow and the scheduler." },
{ "label": "Restoring", "href": "/docs/backup-restore/restoring", "tail": " — the flow that consumes what jobs produce." }
{
"label": "Creating backups",
"href": "/docs/backup-restore/creating-backups",
"tail": " — the interactive flow that shares the backend with the scheduler."
},
{
"label": "Destinations",
"href": "/docs/backup-restore/destinations",
"tail": " — per-backend configuration used by both the interactive flow and the scheduler."
},
{
"label": "Restoring",
"href": "/docs/backup-restore/restoring",
"tail": " — the flow that consumes what jobs produce."
}
]
}
}
web/messages/es/docs/backup-restore/creating-backups.json
+22 -22
View File
@@ -1,7 +1,7 @@
{
"meta": {
"title": "Crear copias — flujo interactivo de copia | ProxMenux",
"description": "El flujo interactivo de copia en ProxMenux. Dos puntos de entrada (menú TUI de Scripts y UI Web del Monitor), tres destinos, dos modos de perfil, un paso común de staging y un diálogo de confirmación. Documenta la matriz de seis opciones, los perfiles Default y Custom, y qué ve el usuario entre seleccionar una copia y ver el archivo aterrizando en el destino.",
"description": "El flujo interactivo de copia de seguridad en ProxMenux. Dos puntos de entrada (el menú TUI de Scripts y la interfaz web de Monitor), tres destinos, dos modos de perfil, un paso de preparación temporal y un diálogo de confirmación. Documenta la matriz de seis opciones, los perfiles predeterminado y personalizado, y lo que ve el usuario desde que selecciona una copia hasta que el archivo se guarda en el destino.",
"ogTitle": "ProxMenux Backup — crear copias",
"ogDescription": "El flujo interactivo de copia con tres destinos, dos perfiles y un paso común de staging.",
"twitterTitle": "Crear copias | ProxMenux",
@@ -9,12 +9,12 @@
},
"header": {
"title": "Crear copias",
"description": "El flujo interactivo de copia: elegir un destino y un perfil, revisar el resumen de confirmación, y ver el archivo aterrizando. Dos puntos de entrada comparten el mismo backend y producen archivos idénticos.",
"section": "Backup & Restore"
"description": "El flujo interactivo de copia de seguridad: elige un destino y un perfil, revisa el resumen de confirmación y observa cómo se guarda el archivo. Los dos puntos de entrada comparten el mismo backend y producen archivos idénticos.",
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Dos puntos de entrada, funcionalidad idéntica",
"body": "El TUI de Scripts y la UI Web del Monitor exponen <strong>exactamente la misma funcionalidad</strong>. Cada copia — manual o programada — pasa por la misma matriz de elección (tres destinos × dos perfiles) e invoca la misma función backend por celda (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Los archivos producidos desde uno u otro punto de entrada son indistinguibles. Cuál usar es una cuestión de preferencia: el TUI es amigable por SSH y admite scripting; el Monitor ofrece click-y-elegir y convive con las vistas de notificaciones y de tail del log."
"body": "El TUI de Scripts y la interfaz web de Monitor ofrecen <strong>exactamente las mismas funciones</strong>. Cada copia —manual o programada— pasa por la misma matriz de opciones (tres destinos × dos perfiles) y llama a la misma función del backend en cada celda (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Los archivos generados desde cualquiera de los dos puntos de entrada son indistinguibles. La elección depende de tus preferencias: el TUI se puede usar por SSH y mediante scripts; Monitor permite trabajar con clics y reúne las vistas de notificaciones y seguimiento del registro."
},
"entryPoints": {
"heading": "Los dos puntos de entrada",
@@ -26,14 +26,14 @@
},
{
"entry": "ProxMenux Monitor (UI Web)",
"path": "Pestaña Backups → Create backup",
"path": "Backups tab → Create backup",
"detail": "Flujo en estilo asistente. Las mismas seis opciones presentadas como formulario de dos pasos (destino → perfil). Se invocan las mismas funciones backend por la API Flask."
}
]
},
"modes": {
"heading": "Copias manuales vs programadas",
"body": "Las copias se pueden producir en dos modos: <strong>manuales</strong> (el flujo interactivo que documenta esta página — el usuario elige un destino y un perfil desde un menú y ve el archivo aterrizando) o <strong>programadas</strong> (un trabajo desatendido que se ejecuta en un timer estilo cron y aplica la retención configurada en el trabajo). Ambos modos soportan los mismos tres destinos y los mismos dos perfiles, y ambos están disponibles desde los dos puntos de entrada — el menú TUI de Scripts y la pestaña Backups del Monitor. Los trabajos programados usan las mismas funciones backend que el flujo manual a través de <code>run_scheduled_backup.sh</code>; los archivos producidos son indistinguibles.",
"body": "Las copias se pueden producir en dos modos: <strong>manuales</strong> (el flujo interactivo que documenta esta página — el usuario elige un destino y un perfil desde un menú y ve cómo se guarda el archivo) o <strong>programadas</strong> (un trabajo desatendido que se ejecuta en un timer estilo cron y aplica la retención configurada en el trabajo). Ambos modos soportan los mismos tres destinos y los mismos dos perfiles, y ambos están disponibles desde los dos puntos de entrada — el menú TUI de Scripts y la pestaña Backups del Monitor. Los trabajos programados usan las mismas funciones backend que el flujo manual a través de <code>run_scheduled_backup.sh</code>; los archivos producidos son indistinguibles.",
"seeAlso": "La página de trabajos programados cubre el flujo completo, incluyendo cómo crear un trabajo, adjuntarlo a un timer vzdump de PVE existente, y configurar los valores de retención.",
"monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando el diálogo New scheduled backup con los campos de destino, perfil, horario y retención.",
"monitorCaption": "Copia programada — Monitor de ProxMenux. El mismo diálogo estilo asistente que crea una copia manual lleva los campos de horario y retención al final para la ruta desatendida."
@@ -45,46 +45,46 @@
{
"combo": "1",
"destination": "PBS",
"profile": "Default",
"profile": "Por defecto",
"action": "Sube el perfil por defecto más los extras persistentes a un repositorio PBS configurado."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Default",
"profile": "Por defecto",
"action": "Crea un archivo con el perfil por defecto más los extras persistentes en el repositorio Borg seleccionado."
},
{
"combo": "3",
"destination": "Local",
"profile": "Default",
"profile": "Por defecto",
"action": "Escribe un archivo <code>.tar.zst</code> con el perfil por defecto más los extras persistentes en el destino local configurado."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Custom",
"action": "Abre el path picker antes de la subida a PBS; el usuario marca rutas y puede añadir nuevas."
"profile": "Personalizado",
"action": "Abre el selector de rutas antes de la subida a PBS; el usuario marca las rutas y puede añadir otras nuevas."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Custom",
"action": "Abre el path picker antes de crear el archivo Borg."
"profile": "Personalizado",
"action": "Abre el selector de rutas antes de crear el archivo Borg."
},
{
"combo": "6",
"destination": "Local",
"profile": "Custom",
"action": "Abre el path picker antes de escribir el <code>.tar.zst</code> local."
"profile": "Personalizado",
"action": "Abre el selector de rutas antes de escribir el <code>.tar.zst</code> local."
}
]
},
"profiles": {
"heading": "Perfil Default vs Custom",
"defaultTitle": "Perfil Default",
"heading": "Perfil predeterminado y personalizado",
"defaultTitle": "Perfil predeterminado",
"defaultBody": "El perfil por defecto es la lista curada de <code>hb_default_profile_paths</code> (documentada en <em>Cómo funciona</em> bajo <em>Categorías de rutas</em>) más cada entrada del fichero de extras persistentes <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. El usuario confirma el destino y las opciones de cifrado y la copia continúa sin más selección de rutas.",
"customTitle": "Perfil Custom",
"customTitle": "Perfil personalizado",
"customBody": "El perfil Custom abre un checklist mostrando cada ruta del perfil por defecto (sin marcar) y cada extra persistente (premarcado, prefijado con <code>[+]</code>). El usuario marca el conjunto para esa ejecución y puede pulsar <em>Add custom path</em> para añadir una nueva ruta absoluta. Cualquier ruta añadida en línea se persiste en <code>backup-extra-paths.txt</code> para que futuras copias la recojan automáticamente sin volver a añadirla. Quitar la marca a un extra persistente lo desmarca para esa ejecución pero no lo elimina del fichero — la eliminación es una acción <em>Manage custom paths</em> separada, fuera del flujo de copia.",
"customPickerAlt": "Checklist del perfil Custom mostrando las rutas del perfil por defecto (sin marcar) y los extras persistentes (premarcados con prefijo [+]), más botones para añadir una ruta nueva o confirmar la selección.",
"customPickerCaption": "Perfil Custom — el path picker. Las rutas del perfil por defecto aparecen sin marcar; los extras persistentes aparecen premarcados con prefijo [+]. El usuario marca el conjunto para esa ejecución.",
@@ -118,7 +118,7 @@
{
"step": "5",
"name": "Notificación (start)",
"detail": "Se dispara <code>hb_notify_lifecycle \"start\"</code>. Si las notificaciones están configuradas en el Monitor, se emite un evento usuario-facing <em>Host backup started</em>. Silencioso si no hay canales configurados."
"detail": "Se ejecuta <code>hb_notify_lifecycle \"start\"</code>. Si las notificaciones están configuradas en Monitor, se emite un evento <em>Copia de seguridad del host iniciada</em> para el usuario. No se envía nada si no hay canales configurados."
}
]
},
@@ -157,7 +157,7 @@
"<strong>Filesystems runtime del kernel y sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> y <code>/run</code> son pseudo-filesystems que produce el kernel y udev; no se persisten en ningún sitio.",
"<strong>Binarios de paquetes bajo <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — los reinstala el APT del destino a partir de <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — estado runtime por host, no se restaura.",
"<strong><code>/home/USUARIO</code></strong> — no está en el perfil por defecto. Añadirlo como ruta custom cuando un sistema tenga directorios home de usuario que deban sobrevivir a una restauración."
"<strong><code>/home/USER</code></strong> — no está en el perfil por defecto. Añadirlo como ruta custom cuando un sistema tenga directorios home de usuario que deban sobrevivir a una restauración."
],
"customPathsTitle": "Cómo se tratan las rutas custom",
"customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en <code>backup-extra-paths.txt</code> pasa por el mismo pipeline de <code>rsync</code> que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en <code>metadata/paths_archived.txt</code>. Las rutas que no existen en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
@@ -165,7 +165,7 @@
"archiveStructure": {
"heading": "Estructura del archivo",
"intro": "El directorio de staging que produce cada backend sigue el mismo layout con independencia del destino. El tarball, el <code>.pxar</code> de PBS o el archivo Borg almacenan este árbol verbatim.",
"tree": "backup-[timestamp]/\n├── manifest.json # estado estructurado del host (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│ ├── packages.manual.list # salida de apt-mark showmanual\n│ ├── run_info.env # hostname, timestamp, versión del kernel, método pmxcfs\n│ ├── paths_archived.txt # lista exacta de rutas que llegaron a rootfs/\n│ └── missing_paths.txt # rutas del perfil ausentes en el origen\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n ├── root/ # /root sin subpaths volátiles\n ├── usr/local/ # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (sólo estado)\n └── var/ # /var/lib/pve-cluster (config.db vía sqlite3 .backup), /var/spool/cron/crontabs"
"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": "Resumen de confirmación",
@@ -184,7 +184,7 @@
"detail": "<code>hb_write_archive_sidecar</code> deposita un <code>*.proxmenux.json</code> junto al archivo local para que el Monitor lo identifique como copia de host de ProxMenux incluso tras movimientos o renombrados."
},
{
"topic": "Notificación (complete/fail)",
"topic": "Notificación (éxito o fallo)",
"detail": "Se dispara <code>hb_notify_lifecycle \"complete\"</code> o <code>\"fail\"</code> con duración, tamaño del archivo y — en fallos — la última línea del log que parezca un error."
}
]
web/messages/es/docs/backup-restore/cross-kernel.json
+104 -28
View File
@@ -10,19 +10,31 @@
"header": {
"title": "Restauración cross-kernel",
"description": "Cómo maneja ProxMenux una restauración cuando el kernel del host de destino es distinto al kernel que había en el momento de la copia — especialmente cuando el destino ejecuta un kernel más reciente. Documenta cómo se detecta la diferencia, cómo se filtran las rutas críticas del arranque que podrían romper el destino, y cómo se reaplica la configuración propia del usuario sin copiar verbatim los ficheros ligados al kernel.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Cada salto de kernel se maneja de forma distinta",
"body": "Cuando la restauración detecta que la copia y el destino tienen versiones mayores distintas de kernel, el flujo se ramifica en función de la dirección del salto — si la copia es más antigua o más reciente que el destino — porque los dos casos tienen modos de fallo opuestos. Las copias más recientes que el destino se restauran limpiamente tal cual (verificado empíricamente en múltiples pruebas de banco). Las copias más antiguas que el destino necesitan un filtro para evitar romper el arranque del destino con configuración escrita para un kernel que desde entonces ha cambiado."
"body": "El kernel de un host Proxmox se identifica mediante una versión como <code>6.17.13-2-pve</code>. Los dos primeros números (<strong>6.17</strong> en este ejemplo) definen la versión principal: cuando cambian, algunos archivos de configuración del kernel anterior podrían no ser válidos para el nuevo. Si la restauración detecta versiones principales distintas en la copia y en el destino, el proceso toma un camino u otro según la dirección del salto: si el kernel de la copia es anterior o posterior al del destino. Los dos casos presentan riesgos opuestos. Las copias con un kernel más reciente que el del destino se restauran tal cual, sin problemas según las pruebas realizadas con varios saltos de kernel. Las copias con un kernel anterior al del destino necesitan un filtro para evitar que una configuración del kernel antiguo impida arrancar el sistema de destino."
},
"directionCheck": {
"heading": "La comprobación de dirección",
"intro": "Durante la comprobación de compatibilidad, <code>hb_compat_check</code> compara el kernel registrado en el manifiesto de la copia contra el kernel actual del destino (<code>uname -r</code>) y clasifica la restauración en uno de tres casos, guardado en la variable interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{ "direction": "same", "condition": "La versión mayor del kernel coincide entre la copia y el destino.", "behavior": "El flujo de restauración completo corre sin cambios. Sin filtro adicional, sin hidratación, sin aviso especial en la interfaz." },
{ "direction": "bk_newer", "condition": "El kernel de la copia es más RECIENTE que el del destino (por ejemplo: la copia se hizo con kernel 7.0 y el destino corre kernel 6.17).", "behavior": "El flujo de restauración completo corre sin cambios, exactamente igual que en <code>same</code>. No se aplica ningún filtro. Verificado empíricamente: los controladores se reinstalan contra el kernel del destino, la configuración IOMMU se aplica limpia, las VMs con passthrough GPU arrancan sin problemas." },
{ "direction": "bk_older", "condition": "El kernel de la copia es más ANTIGUO que el del destino (por ejemplo: la copia se hizo con kernel 6.17 y el destino corre kernel 7.0).", "behavior": "Se activan el filtro de subconjunto seguro y la hidratación de cuatro fases descritos más abajo. La restauración procede — el destino reproduce el origen, pero los ficheros críticos del arranque no se copian verbatim." }
{
"direction": "same",
"condition": "La versión mayor del kernel coincide entre la copia y el destino.",
"behavior": "El flujo de restauración completo corre sin cambios. Sin filtro adicional, sin hidratación, sin aviso especial en la interfaz."
},
{
"direction": "bk_newer",
"condition": "El kernel de la copia es más RECIENTE que el del destino (por ejemplo: la copia se hizo con kernel 7.0 y el destino corre kernel 6.17).",
"behavior": "El flujo de restauración completo corre sin cambios, exactamente igual que en <code>same</code>. No se aplica ningún filtro. Verificado empíricamente: los controladores se reinstalan contra el kernel del destino, la configuración IOMMU se aplica limpia, las VMs con passthrough GPU arrancan sin problemas."
},
{
"direction": "bk_older",
"condition": "El kernel de la copia es más ANTIGUO que el del destino (por ejemplo: la copia se hizo con kernel 6.17 y el destino corre kernel 7.0).",
"behavior": "Se activan el filtro de subconjunto seguro y la hidratación de cuatro fases descritos más abajo. La restauración procede — el destino reproduce el origen, pero los ficheros críticos del arranque no se copian verbatim."
}
]
},
"whyBkNewerIsSafe": {
@@ -31,25 +43,60 @@
},
"safeSubsetFilter": {
"heading": "El filtro de subconjunto seguro (sólo cuando el kernel del destino es más reciente)",
"intro": "Cuando el kernel del destino es más reciente que el de la copia, la comprobación de compatibilidad añade 16 rutas críticas del arranque de <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Estas rutas se excluyen de la restauración porque escribir una versión suya de un kernel más antiguo sobre un destino que corre uno más reciente ha causado kernel panics en pruebas de banco. Las rutas cubren cuatro categorías:",
"intro": "Cuando el kernel del destino es más reciente que el de la copia, la comprobación de compatibilidad añade 16 rutas críticas del arranque de <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Estas rutas se excluyen de la restauración porque escribir una versión suya de un kernel más antiguo sobre un destino que corre uno más reciente ha causado kernel panics en pruebas de banco. Las rutas cubren cinco categorías:",
"categoryRows": [
{ "category": "Bootloader", "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>", "reason": "Defaults de GRUB atados al orden previo de kernels, y estado de proxmox-boot-tool (cmdline, UUIDs de ESP, hooks) que referencia rutas e identificadores de la instalación más antigua." },
{ "category": "Módulos del kernel y artefactos de arranque", "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>", "reason": "Listas de autocarga que pueden referenciar módulos renombrados entre majors del kernel, opciones de módulo que pueden no aplicar, hooks de initramfs escritos para el kernel más antiguo." },
{ "category": "Stack de almacenamiento e identidad de filesystem", "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 que pueden no existir en esta instalación, drivers de multipath que cambian entre kernels, parámetros iSCSI que evolucionan, reglas udev que pueden atarse a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que puede bloquear el pool como si no perteneciera al host." },
{ "category": "Fuentes APT", "paths": "<code>/etc/apt</code>", "reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización." },
{ "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": "Overrides de unit y .wants ligados al major de systemd más antiguo; claves de configuración que pueden no parsearse en un systemd más reciente." }
{
"category": "Cargador de arranque",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "Defaults de GRUB atados al orden previo de kernels, y estado de proxmox-boot-tool (cmdline, UUIDs de ESP, hooks) que referencia rutas e identificadores de la instalación más antigua."
},
{
"category": "Módulos del kernel y artefactos de arranque",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Listas de autocarga que pueden referenciar módulos renombrados entre majors del kernel, opciones de módulo que pueden no aplicar, hooks de initramfs escritos para el kernel más antiguo."
},
{
"category": "Stack de almacenamiento e identidad de filesystem",
"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 que pueden no existir en esta instalación, drivers de multipath que cambian entre kernels, parámetros iSCSI que evolucionan, reglas udev que pueden atarse a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que puede bloquear el pool como si no perteneciera al host."
},
{
"category": "Fuentes APT",
"paths": "<code>/etc/apt</code>",
"reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización."
},
{
"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": "Overrides de unit y .wants ligados al major de systemd más antiguo; claves de configuración que pueden no parsearse en un systemd más reciente."
}
],
"outroBody": "El filtro corre ANTES del diálogo de confirmación para que el usuario vea la lista exacta de rutas que se saltarán, categorizadas por motivo. La restauración procede igualmente — todo lo demás (VMs, LXCs, red, /etc/pve, usuarios, cron, estado de ProxMenux, paquetes, drivers, /root) se restaura con normalidad."
"outroBody": "El filtro corre ANTES del diálogo de confirmación para que el usuario vea la lista exacta de rutas que se saltarán, categorizadas por motivo. La restauración procede igualmente — todo lo demás (configuración de VM/LXC, red, /etc/pve, usuarios, cron, estado de ProxMenux, paquetes, drivers, /root) se restaura con normalidad."
},
"hydration": {
"heading": "Hidratación independiente del kernel",
"intro": "El filtro de subconjunto seguro por sí solo dejaría al destino sin la configuración que el usuario había puesto dentro de esos ficheros críticos del arranque: cmdline IOMMU para passthrough GPU, IDs de dispositivo VFIO, <code>GRUB_TIMEOUT</code> custom, blacklists de nvidia. La pasada de hidratación reaplica esas piezas de forma independiente de la versión del kernel. Corren cuatro fases cuando el kernel del destino es más reciente que el de la copia, cada una aditiva (nunca sobrescribe un valor que el destino ya lleva) e idempotente (correr dos veces es un no-op).",
"intro": "El filtro omite archivos críticos del arranque; la hidratación reaplica ajustes seleccionados: cmdline IOMMU, IDs VFIO, <code>GRUB_TIMEOUT</code> personalizado y listas de bloqueo nvidia. Se ejecuta con un kernel destino más reciente. La fusión de cmdline conserva las claves del destino y añade módulos que faltan. Los valores GRUB y archivos permitidos pueden reemplazar contenido distinto del destino. Repetir la misma entrada es idempotente.",
"phaseRows": [
{ "phase": "1a — Ruta GRUB", "detail": "Para hosts que usan GRUB (instalaciones ext4/lvm). <code>_rs_hyd_grub</code> mergea cada token de <code>manifest.kernel_params.cmdline_extra</code> de la copia en el <code>GRUB_CMDLINE_LINUX_DEFAULT</code> vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted <code>GRUB_*</code> (<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>) del <code>/etc/default/grub</code> de la copia si difieren de las del destino." },
{ "phase": "1b — Ruta systemd-boot / ZFS", "detail": "Para hosts que usan systemd-boot (típicamente ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> mergea los tokens del usuario de <code>cmdline_extra</code> en el <code>/etc/kernel/cmdline</code> del destino, manteniendo intacto el boilerplate propio del destino: <code>root=</code>, <code>boot=</code> y <code>rootflags=</code>." },
{ "phase": "2 — Merge en /etc/modules", "detail": "<code>_rs_hyd_modules</code> añade los módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estén en la whitelist (<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>) Y que aún no estén presentes en <code>/etc/modules</code> del destino." },
{ "phase": "3 — Copia de ficheros whitelisted", "detail": "<code>_rs_hyd_files</code> copia ficheros escritos por el usuario del staging rootfs al destino en vivo cuando el contenido difiere. La whitelist cubre ficheros VFIO/nvidia/blacklist bajo <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo <code>/etc/udev/rules.d</code>. Los ficheros propiedad de la distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) se excluyen intencionadamente — sus contenidos evolucionan entre releases." },
{ "phase": "4 — Forzar reflows post-arranque", "detail": "Las cuatro fases escriben directamente en el destino vivo FUERA del pipeline normal de restauración. Para que los tokens/módulos/ficheros mergeados tengan efecto en el siguiente arranque, <code>HB_HYDRATION_APPLIED=1</code> se propaga a través de <code>plan.env</code> a <code>apply_pending_restore.sh</code>, que fuerza <code>NEEDS_INITRAMFS=1</code> y <code>NEEDS_GRUB=1</code> con independencia de lo que hubiera en la lista de apply. El dispatcher post-arranque después regenera el initramfs y refresca el bootloader." }
{
"phase": "1a — Ruta GRUB",
"detail": "Para hosts que usan GRUB (instalaciones ext4/lvm). <code>_rs_hyd_grub</code> mergea cada token de <code>manifest.kernel_params.cmdline_extra</code> de la copia en el <code>GRUB_CMDLINE_LINUX_DEFAULT</code> vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted <code>GRUB_*</code> (<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>) del <code>/etc/default/grub</code> de la copia si difieren de las del destino."
},
{
"phase": "1b — Ruta systemd-boot / ZFS",
"detail": "Para hosts que usan systemd-boot (típicamente ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> mergea los tokens del usuario de <code>cmdline_extra</code> en el <code>/etc/kernel/cmdline</code> del destino, manteniendo intacto el boilerplate propio del destino: <code>root=</code>, <code>boot=</code> y <code>rootflags=</code>."
},
{
"phase": "2 — Merge en /etc/modules",
"detail": "<code>_rs_hyd_modules</code> añade los módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estén en la whitelist (<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>) Y que aún no estén presentes en <code>/etc/modules</code> del destino."
},
{
"phase": "3 — Copia de ficheros whitelisted",
"detail": "<code>_rs_hyd_files</code> copia ficheros escritos por el usuario del staging rootfs al destino en vivo cuando el contenido difiere. La whitelist cubre ficheros VFIO/nvidia/blacklist bajo <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo <code>/etc/udev/rules.d</code>. Los ficheros propiedad de la distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) se excluyen intencionadamente — sus contenidos evolucionan entre releases."
},
{
"phase": "4 — Forzar reflows post-arranque",
"detail": "Las cuatro fases escriben directamente en el destino vivo FUERA del pipeline normal de restauración. Para que los tokens/módulos/ficheros mergeados tengan efecto en el siguiente arranque, <code>HB_HYDRATION_APPLIED=1</code> se propaga a través de <code>plan.env</code> a <code>apply_pending_restore.sh</code>, que fuerza <code>NEEDS_INITRAMFS=1</code> y <code>NEEDS_GRUB=1</code> con independencia de lo que hubiera en la lista de apply. El dispatcher post-arranque después regenera el initramfs y refresca el bootloader."
}
]
},
"planCommit": {
@@ -59,14 +106,20 @@
"flowDiagram": {
"heading": "El flujo cuando el kernel del destino es más reciente que el de la copia",
"intro": "Los pasos específicos que se añaden cuando el kernel del destino es más reciente se insertan dentro del flujo normal de restauración. Todo lo demás — hot apply, prepare pending, instalación de paquetes, dispatcher post-arranque — corre idéntico a una restauración con el mismo kernel.",
"diagram": " ┌────────────────────────────────────────────────────────────┐\n │ hb_compat_check │\n │ HB_COMPAT_KERNEL_DIRECTION = bk_older │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Añade 16 rutas críticas del arranque a 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 │ Calcula qué se mergearía │\n │ Rellena RS_HYDRATION_SUMMARY (bloque verde) │\n │ Sin escrituras │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Diálogo de confirmación │\n │ Ámbar: rutas saltadas por el filtro de subconjunto seguro │\n │ Verde: tokens/ficheros reaplicados por la hidratación │\n │ El usuario acepta o cancela │\n └───────────────────────────┬────────────────────────────────┘\n │ (aceptado)\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"commit\" │\n │ Fase 1a/1b: mergea tokens del cmdline + claves GRUB │\n │ Fase 2: añade módulos a /etc/modules │\n │ Fase 3: copia ficheros whitelisted vfio/nvidia │\n │ Fija HB_HYDRATION_APPLIED=1 │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ El resto de la restauración corre normalmente │\n │ _rs_apply hot (salta RS_SKIP_PATHS) │\n │ _rs_prepare_pending_restore (escribe plan.env con │\n │ HB_HYDRATION_APPLIED=1) │\n │ packages.manual.list install │\n │ Reinicio │\n │ apply_pending_restore.sh (fuerza NEEDS_INITRAMFS=1, │\n │ NEEDS_GRUB=1 por el flag de hidratación) │\n │ apply_cluster_postboot.sh │\n │ update-initramfs -u -k all │\n │ update-grub / proxmox-boot-tool refresh │\n │ component --auto-reinstall │\n └────────────────────────────────────────────────────────────┘"
"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": "Ejemplos concretos",
"intro": "La pasada de hidratación no es abstracta — produce resultados observables y correctos en escenarios habituales. Dos ejemplos que la hidratación resuelve automáticamente:",
"rows": [
{ "scenario": "GPU passthrough (VFIO)", "detail": "El origen tenía <code>intel_iommu=on iommu=pt</code> en el cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> en <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, y un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a <code>/etc/modules</code>, y copia los dos ficheros modprobe escritos por el usuario. En el siguiente arranque, IOMMU está activo, los módulos VFIO cargan, la GPU queda ligada a vfio-pci y la VM arranca con el passthrough funcionando." },
{ "scenario": "Defaults custom de GRUB", "detail": "El origen tenía <code>GRUB_TIMEOUT=1</code> y <code>GRUB_DISABLE_OS_PROBER=true</code>. La hidratación lee ambas claves del <code>/etc/default/grub</code> de la copia, ve que difieren de los defaults de la instalación fresca, y reescribe esas dos líneas en el fichero del destino (dejando todo lo demás, incluido <code>GRUB_DISTRIBUTOR</code>, intacto)." }
{
"scenario": "Paso GPU (VFIO)",
"detail": "El origen tenía <code>intel_iommu=on iommu=pt</code> en el cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> en <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, y un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a <code>/etc/modules</code>, y copia los dos ficheros modprobe escritos por el usuario. En el siguiente arranque, IOMMU está activo, los módulos VFIO cargan, la GPU queda ligada a vfio-pci y la VM arranca con el passthrough funcionando."
},
{
"scenario": "Defaults custom de GRUB",
"detail": "El origen tenía <code>GRUB_TIMEOUT=1</code> y <code>GRUB_DISABLE_OS_PROBER=true</code>. La hidratación lee ambas claves del <code>/etc/default/grub</code> de la copia, ve que difieren de los defaults de la instalación fresca, y reescribe esas dos líneas en el fichero del destino (dejando todo lo demás, incluido <code>GRUB_DISTRIBUTOR</code>, intacto)."
}
]
},
"callout": {
@@ -77,18 +130,41 @@
"heading": "Dónde viven los mecanismos",
"intro": "Para desarrolladores que quieran trazar o extender el comportamiento cross-kernel:",
"rows": [
{ "component": "Detección de dirección", "location": "<code>hb_compat_check</code> en <code>lib_host_backup_common.sh</code>. Fija <code>HB_COMPAT_KERNEL_DIRECTION</code>." },
{ "component": "Lista de rutas del subconjunto seguro", "location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\tmotivo</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>." },
{ "component": "Fases de hidratación", "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> en <code>backup_host.sh</code>. Orquestados por <code>_rs_apply_bk_older_hydration</code>." },
{ "component": "Forzado de reflow post-arranque", "location": "<code>apply_pending_restore.sh</code> lee <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> y fuerza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>." },
{ "component": "Preview Web", "location": "<code>/api/host-backups/restore/prepare</code> en <code>flask_server.py</code>. Fuentea la librería helper, ejecuta <code>_rs_apply_bk_older_hydration</code> en modo plan, devuelve las acciones al modal Web." }
{
"component": "Detección de dirección",
"location": "<code>hb_compat_check</code> en <code>lib_host_backup_common.sh</code>. Fija <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Lista de rutas del subconjunto seguro",
"location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\treason</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Fases de hidratación",
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> en <code>backup_host.sh</code>. Orquestados por <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Forzado de reflow post-arranque",
"location": "<code>apply_pending_restore.sh</code> lee <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> y fuerza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Preview Web",
"location": "<code>/api/host-backups/restore/prepare</code> en <code>flask_server.py</code>. Fuentea la librería helper, ejecuta <code>_rs_apply_bk_older_hydration</code> en modo plan, devuelve las acciones al modal Web."
}
]
},
"whereNext": {
"heading": "A dónde seguir",
"items": [
{ "label": "Restaurar", "href": "/docs/backup-restore/restoring", "tail": " — el pipeline completo de restauración en el que se enchufan los mecanismos de esta página." },
{ "label": "Cómo funciona", "href": "/docs/backup-restore/how-it-works", "tail": " — el manifiesto y los colectores que producen el bloque <code>kernel_params</code> del que lee la hidratación." }
{
"label": "Restaurar",
"href": "/docs/backup-restore/restoring",
"tail": " — el pipeline completo de restauración en el que se enchufan los mecanismos de esta página."
},
{
"label": "Cómo funciona",
"href": "/docs/backup-restore/how-it-works",
"tail": " — el manifiesto y los colectores que producen el bloque <code>kernel_params</code> del que lee la hidratación."
}
]
}
}
web/messages/es/docs/backup-restore/destinations/borg.json
+11 -11
View File
@@ -10,7 +10,7 @@
"header": {
"title": "Borg",
"description": "El destino Borg escribe las copias del host en un repositorio Borg. Se soportan tres tipos de repositorio: ruta local de sistema de ficheros, disco externo montado o servidor remoto vía SSH. Deduplicación a nivel de chunk entre todos los archivos del repositorio y cifrado opcional repokey.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"aboutBorg": {
"heading": "Qué es Borg",
@@ -62,7 +62,7 @@
},
{
"type": "local",
"url": "/backup/borgbackup (cualquier ruta absoluta)",
"url": "/backup/borgbackup (any absolute path)",
"detail": "El repositorio vive en un directorio local. Sólo tiene sentido cuando el directorio está en un disco físico distinto — un repositorio en el mismo disco que el origen protege contra error humano pero no contra fallo de disco."
}
]
@@ -78,7 +78,7 @@
"Otro host Proxmox en la misma LAN, o una VM en cualquier lugar alcanzable por SSH."
],
"lxcWarningTitle": "LXC como servidor Borg",
"lxcWarningBody": "Si el servidor Borg se ejecuta dentro de un LXC, el contenedor debe tener una cuenta de usuario con contraseña.",
"lxcWarningBody": "Si el servidor Borg está en un LXC, generate-auto necesita una cuenta que acepte autenticación SSH por contraseña durante la instalación de la clave. Si no está disponible, utiliza la instalación manual de la clave o la alternativa generate-pct a través del host PVE.",
"requirementsTitle": "Requisitos en el servidor",
"requirementsRows": [
{
@@ -101,18 +101,18 @@
"minimalSetupTitle": "Setup mínimo del servidor",
"minimalSetupBody": "En un servidor Borg Debian o Ubuntu, un baseline funcional son cuatro comandos como root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Tras esto, el modo <code>generate-auto</code> de ProxMenux puede conectarse usando la contraseña del usuario borg una vez, instalar su propia clave SSH, y cada copia posterior usa esa clave. No hace falta más configuración en el servidor — la clave se restringe a sí misma a <code>borg serve</code> sobre esa ruta."
"minimalSetupNote": "Con el servidor preparado y la autenticación SSH por contraseña disponible, <code>generate-auto</code> instala la clave mediante una cuenta que pueda escribir en authorized_keys del usuario borg. Las copias posteriores usan esa clave, restringida a <code>borg serve</code> en la ruta configurada. Si no hay acceso por contraseña, instala la clave manualmente o usa la alternativa a través del host PVE."
},
"sshAuth": {
"heading": "Autenticación SSH (lado cliente)",
"intro": "Los repositorios Borg remotos se acceden vía SSH. La conexión va desde el host ProxMenux a una cuenta de usuario en el servidor Borg que ejecuta <code>borg serve</code>. Ese usuario se llama típicamente <code>borg</code>, NO el usuario admin/root del servidor — la línea de comando de borg-serve bloquea la conexión a esa ruta concreta del repositorio (ver las estrategias de clave más abajo).",
"strategiesTitle": "Las cuatro estrategias de clave",
"strategiesIntro": "Al añadir un destino remoto, ProxMenux pregunta por el usuario SSH, host y ruta remota, y a continuación pregunta cómo autenticar. Cuatro modos:",
"strategiesTitle": "Estrategias de clave SSH",
"strategiesIntro": "Al añadir un destino remoto, ProxMenux pide el usuario SSH, el host y la ruta remota, y ofrece cuatro opciones de autenticación. Si se rechaza la autenticación por contraseña, también ofrece generate-pct. Los modos se describen a continuación:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Recomendado",
"detail": "ProxMenux genera una nueva keypair ed25519 en <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, y a continuación usa <code>sshpass</code> para hacer login UNA VEZ en el servidor con la contraseña de admin y añadir la clave pública a <code>~borg/.ssh/authorized_keys</code>. La contraseña de admin se usa sólo para esa única llamada — nunca se almacena."
"detail": "ProxMenux genera o reutiliza un par de claves ed25519 en <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> y usa <code>sshpass</code> para probar el acceso e instalar la clave pública en <code>~borg/.ssh/authorized_keys</code>. La contraseña es de una cuenta que pueda escribir ese archivo, normalmente root o el usuario borg. Se utiliza durante la configuración y no se guarda."
},
{
"mode": "generate-manual",
@@ -153,11 +153,11 @@
"content": "Passphrase del destino con el NAME dado arriba (<code>chmod 600</code>). Sólo está presente si el usuario eligió cifrado repokey."
}
],
"outro": "Guardar es opcional — el usuario puede rechazar el prompt de guardado para una copia puntual que no deje credenciales en el host."
"outro": "Guardar el destino es opcional. Si se rechaza, no se guarda la configuración del destino con nombre, pero no se elimina una clave SSH generada. Si se activa repokey sin guardar el destino, ProxMenux guarda igualmente la frase de contraseña en el archivo heredado borg-pass.txt."
},
"encryption": {
"heading": "Cifrado",
"body": "Los repositorios se inicializan con un modo de cifrado vía <code>hb_borg_init_if_needed</code>: <code>borg repo-create -e MODE</code> en versiones modernas, o el legacy <code>borg init --encryption=MODE</code>. ProxMenux expone dos modos: <code>repokey</code> (por defecto) y <code>none</code>. En modo <code>repokey</code>, Borg almacena la clave de cifrado dentro del propio repositorio; el acceso requiere una passphrase, que ProxMenux pregunta dos veces con validación de coincidencia y guarda en <code>borg-pass-NAME.txt</code>. Un diálogo de reconocimiento obligatorio se muestra tras guardar la passphrase: la passphrase es la única manera de acceder a los archivos cifrados, y perderla hace irrecuperable todo archivo del repositorio."
"body": "Los repositorios se inicializan con un modo de cifrado vía <code>hb_borg_init_if_needed</code>: <code>borg repo-create -e MODE</code> en versiones modernas, o el legacy <code>borg init --encryption=MODE</code>. ProxMenux expone dos modos: <code>repokey</code> (por defecto) y <code>none</code>. En modo <code>repokey</code>, Borg almacena la clave de cifrado dentro del propio repositorio; el acceso requiere una passphrase, que ProxMenux pregunta dos veces con validación de coincidencia y guarda en <code>borg-pass-NAME.txt</code> para destinos guardados, o en el archivo heredado descrito antes. Un diálogo de reconocimiento obligatorio se muestra tras guardar la passphrase: la passphrase es la única manera de acceder a los archivos cifrados, y perderla hace irrecuperable todo archivo del repositorio."
},
"runtimeEnv": {
"heading": "Entorno de ejecución",
@@ -165,8 +165,8 @@
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o StrictHostKeyChecking=accept-new",
"purpose": "El comando de shell remoto que Borg usa para repositorios servidos por SSH. Se fija sólo cuando se seleccionó una clave personalizada; en caso contrario queda sin definir para que Borg use la configuración SSH por defecto."
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Comando de shell remoto que Borg utiliza para repositorios SSH. Elegir una clave añade las opciones de identidad; un puerto distinto del predeterminado añade -p PORT. Sin clave personalizada y con el puerto predeterminado, la variable queda sin definir y Borg usa la configuración SSH del host."
},
{
"var": "BORG_PASSPHRASE",
web/messages/es/docs/backup-restore/destinations/index.json
+7 -7
View File
@@ -10,7 +10,7 @@
"header": {
"title": "Destinos",
"description": "Los tres backends de almacenamiento soportados por ProxMenux Backup: archivo local, Proxmox Backup Server (recomendado) y Borg. Cada uno recibe el mismo archivo de tres bloques; se diferencian en formato de almacenamiento, deduplicación, modelo de cifrado y requisitos de red.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "El mismo contenido, tres backends",
@@ -29,8 +29,8 @@
{
"feature": "Compresión",
"local": "zstd (nivel por defecto) mediante <code>tar --zstd</code>. Fallback a gzip.",
"pbs": "Gestionada por PBS. El cliente envía sin comprimir; el servidor chunkiza + comprime.",
"borg": "La integrada de Borg (lz4 por defecto). Configurable al inicializar el repo."
"pbs": "La gestiona proxmox-backup-client. ProxMenux no modifica las opciones de compresión.",
"borg": "La compresión integrada de Borg. ProxMenux ejecuta borg create sin modificar las opciones de compresión."
},
{
"feature": "Deduplicación",
@@ -69,20 +69,20 @@
"borg": "Requiere <code>borg</code> + la ruta del repositorio + la passphrase (si está cifrado)."
}
],
"captionCode": "Característica",
"captionCode": "feature",
"captionLocal": "Local",
"captionPbs": "Proxmox Backup Server (recomendado)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "El contenido interno de la copia es el mismo en cualquier destino",
"body": "Con independencia de dónde se guarde la copia, dentro siempre están los mismos tres bloques descritos en <em>Cómo funciona</em>: el sistema de ficheros (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al extraer una copia local <code>.tar.zst</code>, restaurar un archivo <code>.pxar</code> desde PBS o descomprimir un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Esto significa que el proceso de restauración lee siempre los mismos ficheros y no le importa desde qué destino provenga la copia."
"body": "Los tres destinos contienen la misma estructura <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descrita en <em>Cómo funciona</em>. Extraer un <code>.tar.zst</code> de un archivo local, restaurar un <code>.pxar</code> desde PBS o extraer un archivo de Borg con <code>borg extract</code> produce el mismo árbol de directorios. El proceso de restauración (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lee los mismos tres componentes sin necesitar saber de qué destino proceden."
},
"extractStandalone": {
"heading": "Extraer una copia fuera de ProxMenux",
"intro": "Cualquiera de los tres formatos de archivo se puede leer con herramientas estándar sin tener ProxMenux instalado en el host de lectura. Los comandos siguientes producen el mismo árbol de directorios que consume internamente una restauración.",
"localCmd": "# Desde un archivo local .tar.zst:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# Desde el fallback .tar.gz:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
"pbsCmd": "# Desde un backup PBS (requiere 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# Añadir --keyfile KEY-PATH cuando el backup está cifrado.",
"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": "# Desde un archivo Borg (requiere el binario borg + passphrase si hay cifrado):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Sobre un repo servido por SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "El árbol extraído puede inspeccionarse manualmente o alimentar una restauración manual. Consulta las páginas de cada destino para conocer el flujo exacto de recuperación que ProxMenux utiliza por dentro."
},
web/messages/es/docs/backup-restore/destinations/local.json
+6 -6
View File
@@ -10,7 +10,7 @@
"header": {
"title": "Archivo local",
"description": "El destino local escribe un único archivo tar comprimido en cualquier directorio escribible del host: un disco interno, un montaje NFS o SMB, o una unidad USB.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Un solo fichero, autocontenido",
@@ -31,17 +31,17 @@
"statesTitle": "Los tres estados del dispositivo",
"stateRows": [
{
"state": "mounted",
"shown": "Tamaño · label · [fstype] · → /punto/de/montaje",
"state": "montado",
"shown": "Tamaño · etiqueta · [fstype] · → /mount/point",
"action": "La partición ya está montada en algún sitio. Seleccionarla persiste ese punto de montaje como destino local. No se realiza ningún montaje."
},
{
"state": "unmounted",
"state": "sin montar",
"shown": "Tamaño · label · [fstype] · (no montada — se montará)",
"action": "Hay un filesystem pero no está montado. Al confirmar, ProxMenux ejecuta <code>hb_mount_usb_partition</code>: crea <code>/mnt/backup-LABEL</code> (o una ruta basada en UUID si no hay label), monta la partición y persiste el punto de montaje como destino local."
},
{
"state": "empty",
"state": "vacía",
"shown": "Tamaño · disco USB en crudo — sin filesystem (se FORMATEARÁ)",
"action": "El dispositivo no tiene filesystem. Camino destructivo — protegido por dos confirmaciones. Primero un diálogo Yes/No explica que la operación borrará el disco. Después una caja de entrada obliga al usuario a <strong>escribir la ruta exacta del dispositivo</strong> (por ejemplo <code>/dev/sdb</code>) antes de que ProxMenux cree una partición GPT + ext4 fresca y la monte."
}
@@ -50,7 +50,7 @@
},
"safetyCheck": {
"heading": "Chequeo de seguridad — destino dentro de una ruta copiada",
"body": "Antes de escribir el archivo, <code>_bk_local</code> verifica que el directorio de destino <strong>no</strong> sea un subcamino de ninguno de los directorios que se están copiando. Un footgun habitual sería añadir <code>/root</code> al perfil y elegir <code>/root/backups</code> como destino — el archivo se incluiría a sí mismo, produciendo o bien un archivo corrupto o bien crecimiento sin límite hasta llenar el disco. El chequeo resuelve ambos caminos con <code>readlink -m</code>, los compara y, si hay conflicto, aborta la copia con un diálogo que nombra la ruta en conflicto y lista tres formas de resolverlo: elegir un destino fuera de la ruta en conflicto, eliminar la entrada personalizada que contiene el destino, o usar modo Custom para desmarcar la ruta en conflicto en esa ejecución."
"body": "Antes de escribir el archivo, <code>_bk_local</code> verifica que el directorio de destino <strong>no</strong> sea un subcamino de ninguno de los directorios que se están copiando. Un error habitual sería añadir <code>/root</code> al perfil y elegir <code>/root/backups</code> como destino — el archivo se incluiría a sí mismo, produciendo o bien un archivo corrupto o bien crecimiento sin límite hasta llenar el disco. El chequeo resuelve ambos caminos con <code>readlink -m</code>, los compara y, si hay conflicto, aborta la copia con un diálogo que nombra la ruta en conflicto y lista tres formas de resolverlo: elegir un destino fuera de la ruta en conflicto, eliminar la entrada personalizada que contiene el destino, o usar modo Custom para desmarcar la ruta en conflicto en esa ejecución."
},
"archiveFormat": {
"heading": "Formato de archivo y compresión",
web/messages/es/docs/backup-restore/destinations/pbs.json
+11 -11
View File
@@ -1,7 +1,7 @@
{
"meta": {
"title": "Destino Proxmox Backup Server — repositorio, cifrado, recuperación | ProxMenux",
"description": "El destino PBS escribe las copias de host de ProxMenux como backups PBS. Documenta la auto-detección del repositorio desde /etc/pve/storage.cfg, la configuración manual de PBS, el comando de subida .pxar, el modelo de cifrado por keyfile del lado del cliente, el blob de escrow con passphrase de recuperación, y la recuperación del keyfile desde PBS en instalaciones frescas.",
"description": "El destino PBS guarda las copias del host de ProxMenux como copias PBS. Explica la detección de repositorios desde /etc/pve/storage.cfg, la configuración manual, la subida de .pxar, el cifrado con archivo de clave en el cliente y su custodia opcional protegida por una frase de contraseña, y la recuperación de la clave desde varias fuentes en un host recién instalado.",
"ogTitle": "ProxMenux Backup — destino Proxmox Backup Server",
"ogDescription": "Cómo escribe ProxMenux las copias de host en Proxmox Backup Server con cifrado por keyfile del lado del cliente y escrow de recuperación.",
"twitterTitle": "Destino PBS de copia | ProxMenux",
@@ -9,8 +9,8 @@
},
"header": {
"title": "Proxmox Backup Server",
"description": "El destino PBS sube la raíz de staging como un único backup .pxar a un datastore de Proxmox Backup Server, con cifrado opcional por keyfile del lado del cliente y escrow automático de una passphrase de recuperación para recuperación tras reinstalación.",
"section": "Backup & Restore"
"description": "El destino PBS sube todo el directorio de preparación como una única copia .pxar a un datastore de Proxmox Backup Server. Permite cifrarla en el cliente con un archivo de clave y, de forma opcional, subir junto a cada copia una copia de la clave protegida por una frase de contraseña para recuperarla después.",
"section": "Copias de seguridad y restauración"
},
"recommendedBadge": "Destino recomendado",
"aboutPbs": {
@@ -23,7 +23,7 @@
},
"repoSelection": {
"heading": "Selección del repositorio",
"intro": "ProxMenux descubre repositorios PBS desde dos fuentes en cada copia. El usuario elige uno desde un menú unificado; esa elección determina, para esa ejecución concreta, contra qué servidor y datastore se envía la copia, con qué contraseña se autentica y con qué huella (<em>fingerprint</em>) valida el certificado.",
"intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada copia de seguridad. El usuario elige uno en un menú unificado; esa elección determina los valores de <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
"sourceRows": [
{
"source": "storage.cfg de Proxmox (auto-descubierto)",
@@ -41,12 +41,12 @@
},
"backupCommand": {
"heading": "El comando de copia",
"intro": "La subida es una única invocación de <code>proxmox-backup-client backup</code>. ProxMenux la ejecuta dentro de un envoltorio <code>env</code> para que las credenciales nunca aparezcan en la lista de argumentos del proceso.",
"intro": "La subida se realiza con una única invocación de <code>proxmox-backup-client backup</code>. ProxMenux utiliza <code>env</code> para pasar al cliente la contraseña, la contraseña de cifrado y el fingerprint como variables de entorno.",
"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": "Nombrado del backup ID",
"backupIdBody": "El backup ID por defecto es <code>hostcfg-HOSTNAME</code>. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de <code>[A-Za-z0-9_-]</code> se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un <em>grupo</em>, y cada copia posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
"pxarTitle": "Qué se incluye dentro del archivo .pxar",
"pxarBody": "Al construir el archivo <code>.pxar</code> se empaqueta el directorio de trabajo completo: el sistema de ficheros del host (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al restaurar, ProxMenux compara la información del manifiesto con la del host destino para detectar si son equivalentes, si cambia el hardware o si se trata de un equipo distinto, y ajustar el proceso en consecuencia. Las copias antiguas —hechas con versiones anteriores de ProxMenux que empaquetaban solo el sistema de ficheros— siguen restaurándose sin problema: el flujo de restauración detecta ese formato heredado y lo reorganiza automáticamente."
"pxarBody": "El origen del <code>.pxar</code> es todo el directorio <code>staging_root</code>, con <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Las versiones anteriores utilizaban <code>$staging_root/rootfs</code> como origen; esto dejaba <code>metadata/</code> fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Las copias antiguas creadas solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de <code>_rs_check_layout</code>, que vuelve a colocar el árbol plano <code>etc/var/root/usr</code> dentro de una estructura <code>rootfs/</code>."
},
"encryption": {
"heading": "Cifrado del lado del cliente",
@@ -61,19 +61,19 @@
"modesSharedTitle": "Clave compartida (importar la misma en cada host)",
"modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
"recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
"recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta si se quiere subir una copia de esa clave a PBS como red de seguridad, con dos opciones. <strong>No</strong> (por defecto) mantiene la clave solo en el host; ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, la acción <em>Descargar</em> en la fila del destino PBS la exporta en el acto). <strong>Sí</strong> pide una passphrase de recuperación —dos veces, para comprobar que coincidan—; con esa passphrase, la clave se envuelve localmente con AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) en un fichero <code>pbs-key.recovery.enc</code>. A partir de ese momento, cada copia cifrada sube también ese fichero envuelto a PBS. Ni la passphrase ni la clave en claro salen del host. La respuesta se puede cambiar después desde el Monitor en cualquier momento; el interruptor está inline en la fila del destino PBS y el botón que aparece se adapta al estado (empezar a subir, dejar de subir, o cambiar la passphrase).",
"recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta <em>¿Subir la clave a PBS?</em>, con dos respuestas. <strong>No se sube ningún artefacto de recuperación a PBS hasta que el usuario responde Sí.</strong> Por defecto se elige <em>No, mantener solo en local</em>: la clave queda en su ruta canónica, ProxMenux no sube artefactos de recuperación a PBS y el usuario se encarga de guardarla fuera del host. El botón <em>Descargar archivo de clave</em> del Monitor, en la fila del destino PBS, permite obtenerla cuando se necesite. Al elegir <em>Sí, subir</em>, se pide dos veces una frase de contraseña de recuperación y se comprueba que coincidan. ProxMenux protege la clave con AES-256-CBC y PBKDF2 (600.000 iteraciones y sal aleatoria) para generar <code>pbs-key.recovery.enc</code>. Cada copia cifrada posterior sube esa envoltura a PBS como un grupo de copias asociado. En estas subidas no se envían a PBS ni la frase de contraseña ni la clave en texto claro. La elección puede cambiarse en cualquier momento desde el Monitor: el control de custodia de la fila del destino permite elegir Sí o No y aplicar inmediatamente Iniciar subida, Detener subida o Actualizar frase de contraseña, según el estado.",
"blobUploadTitle": "Grupo emparejado en PBS",
"blobUploadBody1": "Cuando el usuario ha respondido Sí, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore: uno con las copias del host, otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: se cifra en el host con AES-256-CBC y PBKDF2 antes de enviar un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el sobre ya cifrado.",
"blobUploadBody1": "Cuando la custodia está configurada como <em>Sí, subir</em>, ProxMenux sube el archivo de recuperación protegido a PBS después de cada copia cifrada. Lo guarda en un segundo grupo de copia asociado, con el mismo nombre que el grupo del host y el sufijo <code>-keyrecovery</code>. Los dos grupos aparecen juntos en la lista del almacén de datos: uno para las copias del host y otro para los archivos de recuperación. <strong>El archivo de recuperación nunca sale del host en texto plano</strong>: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar ningún dato (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el archivo ya cifrado.",
"envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
"envelopeSecurityBody": "El sobre viaja y se guarda cifrado en todo momento. La passphrase de recuperación no sale nunca del host: el cifrado ocurre en local antes de la subida y PBS solo recibe el resultado ya cifrado. Un administrador de PBS —o cualquiera con acceso al datastore— puede descargar el sobre, pero sin la passphrase no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas a la vez, el sobre y la passphrase, y solo el usuario tiene ambas.",
"blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
"blobUploadConstraintBody": "Cada subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave —o ninguno—. No hay opción intermedia. La copia del host tiene que ir cifrada con la clave. El sobre de recuperación no puede viajar en esa misma subida: quedaría cifrado con la clave que precisamente contiene, y en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso salen dos subidas independientes y aparecen dos grupos separados: la copia del host la cifra PBS con la clave, y el sobre lo cifra ProxMenux con la passphrase antes de subirlo. Dos capas de cifrado distintas para dos cosas distintas.",
"blobUploadConstraintBody": "Una invocación de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave o no cifra ninguno; no permite mezclar ambos casos. La copia del host se cifra con su archivo de clave, pero la envoltura de recuperación no puede acompañarla en la misma subida porque acabaría cifrada con la propia clave que contiene. En un host recién reinstalado sería imposible abrirla: haría falta la clave para descifrar esa misma clave. Por eso los dos artefactos se suben por separado y aparecen en dos grupos: el cliente PBS cifra la copia del host con el archivo de clave y ProxMenux cifra la envoltura con la frase de contraseña antes de subirla. Dos capas de cifrado distintas protegen dos elementos diferentes.",
"blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.",
"blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
"recoverTitle": "Recuperación en un equipo recién instalado",
"recoverBody": "Cuando la clave no está en su sitio —tras reinstalar el host desde cero o después de eliminarla a propósito— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS elegido tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo <code>-keyrecovery</code>, se descarga la copia más reciente y se pide la passphrase de recuperación para abrirla. Tercero, si ninguna de las dos anteriores funciona o el usuario las descarta, el diálogo pide la ruta absoluta donde ha dejado la clave en este host, y se copia a la ruta canónica. El Monitor expone el mismo flujo dentro del modal de la copia. Si al Restaurar, Descargar o Ver contenido falta la clave, aparece un panel ámbar arriba del modal con las mismas tres vías de importación. Si la clave está instalada pero no es la correcta para esa copia, PBS devuelve un error de tipo <code>wrong key — manifest's key XX does not match provided key YY</code> y el modal muestra un panel estructurado con el fingerprint que PBS espera (el que quedó grabado en el manifest de la copia), para que el usuario sepa qué clave concreta necesita importar.",
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
"monitorManagementBody": "En la página de configuración de copias, la fila de cada destino PBS incluye los controles de la clave. Tres acciones directas: <em>Descargar</em> exporta la clave actual al navegador. <em>Subir</em> reemplaza la clave instalada por otra que aporta el usuario (la anterior solo se sobrescribe cuando la nueva ha llegado correctamente a su sitio). <em>Eliminar</em> retira la clave del host. Justo al lado está el interruptor del sobre de recuperación: un Sí/No para subir o no la clave a PBS, un campo de passphrase que aparece al elegir Sí, y un botón que se adapta al estado actual (empezar a subir, dejar de subir, o cambiar la passphrase). Los controles del Monitor y el diálogo del shell hacen lo mismo por dentro, así que el resultado en disco y en PBS es idéntico se use la que se use."
"monitorManagementBody": "El Monitor muestra los controles del archivo de clave en cada fila de destino PBS de la página de configuración de copias. Hay tres acciones: <em>Descargar</em> envía el archivo de clave actual al navegador del usuario; <em>Subir</em> sustituye el archivo de clave instalado por uno proporcionado por el usuario (el anterior solo se sobrescribe cuando el nuevo se ha guardado correctamente en la ruta canónica); y <em>Eliminar</em> borra el archivo de clave del host. Junto a estas acciones hay un único control de custodia para la recuperación: las opciones Sí y No de <em>¿Subir la clave a PBS?</em>, un campo para la frase de contraseña al elegir Sí y un botón contextual para aplicar el cambio, con el texto <em>Iniciar subida</em>, <em>Detener subida</em> o <em>Actualizar frase de contraseña</em> según el estado actual. Todas las acciones utilizan los mismos endpoints de Flask que el menú de terminal, por lo que el resultado en disco y el estado en PBS son idénticos desde ambas interfaces."
},
"restoreAccess": {
"heading": "Recuperación del lado de la restauración",
@@ -96,7 +96,7 @@
{
"label": "Cifrado del lado del cliente",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — creación del keyfile, modos --kdf, el modelo de cifrado que ProxMenux extiende con un escrow de passphrase."
"tail": " — creación del archivo de clave, modos --kdf y modelo de cifrado que ProxMenux amplía con una copia de recuperación protegida por frase de contraseña."
},
{
"label": "Gestión de datastores",
web/messages/es/docs/backup-restore/glossary.json
+9 -17
View File
@@ -10,7 +10,7 @@
"header": {
"title": "Glosario",
"description": "Términos que aparecen a lo largo de la documentación de copia y restauración, con su definición.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"body": "Los términos están agrupados por temas. Cada entrada incluye una definición breve."
@@ -23,43 +23,36 @@
{
"id": "passphrase-recuperacion",
"term": "Passphrase de recuperación",
"also": "recovery passphrase",
"def": "Contraseña de texto que elige el usuario para proteger el <a href=\"#sobre-recuperacion\">sobre de recuperación</a>. Se pide dos veces con validación de coincidencia y solo se usa para cifrar el sobre y para descifrarlo si algún día hay que recuperar la clave. <strong>No sirve para desbloquear la clave del keyfile</strong> ni se envía nunca a PBS. Nunca sale del host durante una copia normal."
},
{
"id": "clave-cifrado",
"term": "Clave de cifrado (keyfile)",
"also": "keyfile, PBS encryption key",
"def": "Fichero binario que Proxmox Backup Server utiliza para cifrar los <a href=\"#chunk\">chunks</a> de la copia antes de subirlos. Sin ese fichero, ninguna copia cifrada puede leerse. ProxMenux lo guarda en <code>/usr/local/share/proxmenux/pbs-key.conf</code> con permisos <code>600</code>. Es el activo que hay que proteger; el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> existe precisamente para poder rescatar este fichero si se pierde."
"def": "Archivo de clave que proxmox-backup-client usa para cifrar los <a href=\"#chunk\">chunks</a> antes de subirlos a PBS. Sin la clave correspondiente no se leen los datos cifrados. ProxMenux lo guarda en <code>/usr/local/share/proxmenux/pbs-key.conf</code> con modo <code>600</code>. Protégelo: el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> permite recuperarlo si se pierde."
},
{
"id": "contrasena-keyfile",
"term": "Contraseña de la clave (KDF passphrase)",
"also": "keyfile passphrase, scrypt passphrase",
"def": "Contraseña opcional que puede llevar la propia clave, distinta de la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>. Solo aparece si la clave se creó con <code>--kdf scrypt</code> (una clave importada de otro sitio, por ejemplo). Sin ella, la clave no se puede desbloquear en cada uso. ProxMenux la persiste cifrada en el host para que las copias programadas puedan ejecutarse sin diálogo interactivo."
},
{
"id": "sobre-recuperacion",
"term": "Sobre de recuperación",
"also": "recovery envelope, escrow blob, pbs-key.recovery.enc",
"def": "La propia <a href=\"#clave-cifrado\">clave de cifrado</a> envuelta en una capa adicional: se cifra con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a> mediante <a href=\"#aes-256-cbc\">AES-256-CBC</a> y <a href=\"#pbkdf2\">PBKDF2</a> antes de salir del host. Es lo que se sube a PBS en el grupo <code>-keyrecovery</code>. Sin la passphrase, el sobre es opaco: descargarlo desde PBS no revela la clave."
},
{
"id": "cifrado-cliente",
"term": "Cifrado del lado del cliente",
"also": "client-side encryption",
"def": "Modelo en el que los datos se cifran en el host de origen antes de subirse. PBS solo recibe y almacena datos cifrados; ni siquiera un administrador de PBS con acceso al datastore puede leerlos sin la clave. ProxMenux se apoya en este modelo y añade el <a href=\"#sobre-recuperacion\">sobre de recuperación</a> encima."
},
{
"id": "kdf-none",
"term": "--kdf none",
"also": "clave sin contraseña",
"def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave sin contraseña asociada. La clave se puede usar directamente sin ningún diálogo, lo que es imprescindible para que los trabajos programados corran de forma desatendida. Es lo que ProxMenux usa por defecto al generar una clave nueva."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"also": "clave con contraseña",
"def": "Opción de <code>proxmox-backup-client key create</code> que genera una clave protegida con una <a href=\"#contrasena-keyfile\">contraseña de la clave</a>. Cada vez que se usa la clave hay que desbloquearla con esa contraseña. ProxMenux acepta este tipo de claves al importarlas y guarda la contraseña cifrada para que las copias programadas puedan correr sin intervención."
},
{
@@ -112,11 +105,11 @@
{
"id": "repositorio-pbs",
"term": "Repositorio PBS",
"def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>usuario@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
"def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>user@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
},
{
"id": "datastore",
"term": "Datastore",
"term": "almacén de datos",
"def": "Almacén concreto dentro de un servidor PBS donde se guardan las copias y sus chunks. Cada datastore vive sobre un sistema de ficheros del servidor PBS y tiene sus propios permisos y políticas."
},
{
@@ -136,7 +129,7 @@
},
{
"id": "backup-id",
"term": "Backup ID",
"term": "ID del backup",
"def": "Nombre del <a href=\"#grupo-copia\">grupo de copia</a>. ProxMenux propone por defecto <code>hostcfg-HOSTNAME</code> y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
},
{
@@ -152,8 +145,8 @@
"entries": [
{
"id": "runner",
"term": "Runner",
"def": "Script <code>run_scheduled_backup.sh</code> que ejecuta una copia programada. Lee la configuración del trabajo, lanza el backend correspondiente (Local, PBS o Borg), aplica la retención al terminar y envía las notificaciones configuradas."
"term": "Ejecutor",
"def": "Script <code>run_scheduled_backup.sh</code> que ejecuta una copia programada. Lee la configuración del trabajo, lanza el backend correspondiente (Local, PBS o Borg), aplica la retención tras completarse con éxito y envía las notificaciones configuradas."
},
{
"id": "trabajo-programado",
@@ -163,7 +156,7 @@
{
"id": "modo-adjunto",
"term": "Modo adjunto (attach mode)",
"def": "Trabajo programado que no lleva horario propio; se dispara automáticamente cada vez que una tarea <code>vzdump</code> de PVE existente se ejecuta. Hereda el horario y la retención de esa tarea padre. Solo compatible con destinos Local y PBS."
"def": "Trabajo sin timer propio. Un hook job-end de <code>vzdump</code> lo ejecuta después de las copias de invitados cuando coincide el almacenamiento. El padre seleccionado aporta destino y retención inicial, pero el hook compara almacenamiento, no ID de tarea padre; otra tarea con el mismo destino también puede activarlo. Solo para Local y PBS."
},
{
"id": "timer-systemd",
@@ -203,13 +196,12 @@
},
{
"id": "compatibility-check",
"term": "Compatibility check",
"term": "Verificación de compatibilidad",
"def": "Comparación entre el manifiesto del origen y el estado del destino que ProxMenux realiza al principio de la restauración. Decide qué partes se copian verbatim, cuáles necesitan hidratación y cuáles se recrean desde el instalador."
},
{
"id": "equipo-recien-instalado",
"term": "Equipo recién instalado",
"also": "fresh install",
"def": "Host acabado de reinstalar desde cero, sin la <a href=\"#clave-cifrado\">clave de cifrado</a> local. Para restaurar copias cifradas hace falta primero recuperar la clave desde el <a href=\"#sobre-recuperacion\">sobre</a> almacenado en PBS, con la <a href=\"#passphrase-recuperacion\">passphrase de recuperación</a>."
}
]
web/messages/es/docs/backup-restore/how-it-works.json
+6 -6
View File
@@ -10,23 +10,23 @@
"header": {
"title": "Cómo funciona",
"description": "Desglose interno de una copia de seguridad creada con ProxMenux — sistema de ficheros, manifiesto e inventario de aplicaciones — y cómo la restauración consume los tres para reproducir el host de origen sobre un destino que puede no compartir el mismo kernel.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Un archivo, tres bloques",
"body": "Cada copia produce un layout de directorio con tres bloques bien definidos bajo una única raíz de staging. El archivo que se sube al destino (archivo local <code>.tar.zst</code>, backup PBS o archivo Borg) contiene ese layout exacto. La restauración lee los tres bloques de forma independiente, en un orden concreto que garantiza la corrección: primero se copia el <strong>rootfs</strong> —el sistema de archivos raíz del host— para colocar la configuración, después se consulta <strong>el manifiesto</strong> para detectar drift y decidir qué omitir, y finalmente <strong>el inventario de aplicaciones</strong> dirige la pasada de reinstalación post-arranque. No hay dependencias entre bloques — cada uno puede inspeccionarse o extraerse de forma independiente."
"body": "Cada copia produce una estructura con tres bloques definidos bajo un único directorio de preparación. El archivo subido al destino (<code>.tar.zst</code> local, copia PBS o archivo Borg) contiene esa misma estructura. La restauración utiliza los tres: consulta <strong>el manifiesto</strong> antes de aplicar cambios para detectar diferencias y decidir qué omitir; <strong>rootfs</strong> aporta los archivos de configuración, que se aplican en vivo o tras el reinicio; y <strong>el inventario de aplicaciones</strong> dirige la instalación de paquetes y la reinstalación de componentes después del arranque. Cada bloque puede inspeccionarse o extraerse de forma independiente."
},
"layout": {
"heading": "Layout del archivo",
"intro": "Cada archivo respeta el mismo layout con independencia del destino. El subdirectorio <code>metadata/</code> contiene los bloques estructurados; el subdirectorio <code>rootfs/</code> contiene la copia del sistema de ficheros.",
"treeCaption": "El directorio de staging generado durante una copia. Todos los destinos reciben el mismo árbol (adaptado a su formato nativo: tar para local, chunks PBS para PBS, segmentos borg para Borg).",
"tree": "backup-[timestamp]/\n├── manifest.json # estado estructurado del host\n├── metadata/\n│ ├── packages.manual.list # apt-mark showmanual\n│ ├── run_info.env # identidad de la ejecución + versión del kernel + método pmxcfs\n│ ├── paths_archived.txt # lista exacta de rutas que llegaron a rootfs/\n│ └── missing_paths.txt # rutas del perfil ausentes en el origen\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n ├── root/ # /root (con subdirs volátiles excluidos)\n ├── usr/local/ # /usr/local/bin, /usr/local/share/proxmenux, …\n └── var/ # /var/lib/pve-cluster (config.db vía sqlite3 .backup), /var/spool/cron/…"
"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": "El bloque rootfs",
"intro": "El árbol <code>rootfs/</code> es una <strong>copia plana del sistema de ficheros</strong> producida por <code>rsync</code> desde el host de origen. Contiene un <strong>perfil por defecto</strong> curado de rutas que importan para una restauración de Proxmox, más cualquier <strong>ruta personalizada</strong> añadida por el usuario al trabajo de copia o a la sesión interactiva. El conjunto es intencionadamente estrecho: solamente rutas que <em>contienen configuración</em> o <em>contienen estado que Proxmox no puede regenerar por sí solo</em>.",
"defaultProfileTitle": "El perfil por defecto",
"defaultProfileBody": "El perfil por defecto está definido por <code>hb_default_profile_paths</code> en <code>lib_host_backup_common.sh</code>. Cubre ocho categorías que en conjunto describen un host Proxmox operativo:",
"defaultProfileBody": "El perfil por defecto se define en <code>hb_default_profile_paths</code> de <code>lib_host_backup_common.sh</code>. Incluye ocho categorías fijas y, si corresponde, el estado ZFS, que juntas describen un host Proxmox operativo:",
"categoriesTitle": "Categorías de rutas",
"categoryRows": [
{
@@ -121,11 +121,11 @@
}
],
"schemaTitle": "Validación por esquema",
"schemaBody": "ProxMenux incluye una plantilla que describe qué campos debe contener el manifiesto y qué forma tiene cada uno. Cuando se genera una copia se puede comprobar automáticamente que el manifiesto respeta esa plantilla, de modo que si un colector produjera un JSON malformado o con un campo mal escrito se detectaría en el momento. Es una comprobación destinada al desarrollo del propio ProxMenux: si el sistema no la tiene instalada, la copia sigue funcionando con normalidad y el manifiesto se genera igual."
"schemaBody": "El manifiesto se valida con <code>scripts/backup_restore/schema/manifest.schema.json</code>. Ejecutar <code>build_manifest.sh --validate</code> activa una validación JSON Schema en Python (requiere <code>python3</code> y <code>jsonschema</code>). Si el módulo no está instalado, se omite la comprobación sin mostrar ningún aviso: esta validación es principalmente una ayuda para el desarrollo, no una dependencia necesaria durante la ejecución."
},
"applications": {
"heading": "El inventario de aplicaciones",
"intro": "Dos ficheros bajo <code>metadata/</code> catalogan todo lo instalado en el origen que no forma parte del conjunto de paquetes base de Proxmox VE. La restauración los utiliza para reproducir el conjunto exacto de software instalado por el usuario en el destino, usando APT o los instaladores propios de ProxMenux según cómo se instalara originalmente el software.",
"intro": "Dos inventarios registran el software añadido al conjunto base de Proxmox VE: la lista de paquetes en <code>metadata/</code> y el registro de componentes dentro de rootfs, detallados a continuación. La restauración los usa para reproducir el software del usuario con APT o los instaladores de ProxMenux, según cómo se instalara originalmente.",
"packagesTitle": "packages.manual.list",
"packagesBody": "Una lista de texto plano producida por <code>apt-mark showmanual</code>: todos los paquetes APT que fueron <em>instalados explícitamente</em> en el host de origen, ordenados alfabéticamente. Esto excluye los paquetes instalados como dependencias del ISO base de Proxmox VE (que APT del destino vuelve a traer automáticamente). Es leída por <code>_rs_run_complete_extras</code> durante la restauración, filtrada por un filtro <em>cascade-safe</em> de tres pases (<code>dpkg -s</code> para lo ya instalado, detección de sibling-major para librerías, <code>apt-get install --simulate</code> para riesgo de cascade-remove) y después instalada con <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (parte del rootfs)",
web/messages/es/docs/backup-restore/index.json
+12 -12
View File
@@ -4,17 +4,17 @@
"description": "ProxMenux Backup & Restore captura el estado completo de un host Proxmox — sistema de ficheros, manifiesto estructurado de configuración y paquetes/componentes instalados — y lo reproduce en el mismo host o en uno distinto. La copia y la restauración son autocontenidas: sin dependencias externas, y con soporte para restauraciones cross-kernel mediante un filtro direccional de subconjunto seguro y una hidratación kernel-agnóstica.",
"ogTitle": "ProxMenux Backup & Restore — Descripción general",
"ogDescription": "Copia y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes.",
"twitterTitle": "ProxMenux Backup & Restore | ProxMenux",
"twitterTitle": "Copia de seguridad y restauración de ProxMenux | ProxMenux",
"twitterDescription": "Copia y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes."
},
"header": {
"title": "Backup & Restore",
"title": "Copias de seguridad y restauración",
"description": "Copia y restauración a nivel de host para Proxmox VE. Captura el sistema de ficheros, la configuración y los componentes instalados en un único archivo y reproduce el host sobre la misma instalación de Proxmox o sobre una distinta, sin dependencias externas.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Qué es, en un párrafo",
"body": "Una copia de ProxMenux captura el estado completo de un host Proxmox: <strong>el sistema de ficheros</strong> (directorios relevantes bajo <code>/etc</code>, <code>/root</code>, <code>/var/lib/pve-cluster</code>, más rutas personalizadas opcionales), <strong>un manifiesto estructurado</strong> (JSON con el hardware detectado, los parámetros del kernel, la topología de red, el estado de ZFS, los usuarios y las entradas de cron) y <strong>un inventario de aplicaciones</strong> (todos los paquetes marcados como instalados manualmente por APT, más la lista de componentes instalados por ProxMenux con sus versiones exactas). Cualquiera de los tres destinos soportados — archivo local, Proxmox Backup Server (recomendado) o Borg — recibe el mismo contenido autocontenido, y cualquiera de ellos puede hidratar el host de destino sin depender de que el origen esté accesible en el momento de la restauración."
"body": "Una copia de ProxMenux recoge el estado completo de un host Proxmox: <strong>el sistema de archivos</strong> (los directorios pertinentes de <code>/etc</code>, <code>/root</code> y <code>/var/lib/pve-cluster</code>, además de las rutas personalizadas opcionales), <strong>un manifiesto estructurado</strong> (JSON con el hardware detectado, los parámetros del kernel, la configuración de red, el estado de ZFS, los usuarios y las entradas de cron) y <strong>un inventario de aplicaciones</strong> (los paquetes que APT marca como instalados manualmente y los componentes instalados por ProxMenux, con sus versiones exactas). Los tres destinos admitidos —archivo local, Proxmox Backup Server (recomendado) y Borg— reciben el mismo contenido autónomo. Cualquiera de ellos permite reconstruir el host de destino sin que el host de origen tenga que estar accesible durante la restauración."
},
"video": {
"heading": "Vídeo demostración",
@@ -24,23 +24,23 @@
},
"whatItIsNot": {
"heading": "Qué no es",
"intro": "La sección cubre copia y restauración <strong>a nivel de host</strong>: la instalación de Proxmox en sí, no las cargas de trabajo que se ejecutan sobre ella.",
"intro": "Esta sección trata de la copia y restauración <strong>del host</strong>: la instalación de Proxmox, no las aplicaciones y máquinas que se ejecutan sobre ella.",
"items": [
"<strong>No es una herramienta de copia de VMs/CTs.</strong> Los discos de los invitados y su estado de RAM no se capturan en esta función; para eso está <code>vzdump</code>. Los <strong>ficheros de configuración</strong> de los invitados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> y <code>lxc/*.conf</code>) <strong>sí</strong> se capturan, de modo que tras la restauración el inventario de invitados reaparece y sus discos pueden re-adjuntarse desde una copia existente de PBS o local.",
"<strong>No es una operación a nivel de clúster.</strong> Cada nodo se copia a sí mismo. La pertenencia al clúster se captura como parte de <code>/etc/pve</code> para que un nodo restaurado pueda re-incorporarse al clúster, pero restaurar un clúster completo requiere coordinación por nodo.",
"<strong>No es una imagen completa del disco.</strong> Los binarios del kernel, el initramfs y la partición de arranque no se capturan. En la restauración, ProxMenux utiliza los artefactos de arranque propios del host de destino (regenerados automáticamente por <code>update-initramfs</code> y la herramienta de bootloader) e instala los controladores adecuados contra el kernel que el destino tenga en ejecución."
"<strong>No es una herramienta de copia de VM/CT.</strong> Esta función no guarda los discos ni el estado de la RAM de los invitados; para eso está <code>vzdump</code>. Los <strong>archivos de configuración</strong> de los invitados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> y <code>lxc/*.conf</code>) <strong>sí</strong> se guardan. Tras restaurar, reaparece su inventario y los discos se pueden recuperar o volver a asociar a partir de una copia existente en PBS o en almacenamiento local.",
"<strong>No es una operación sobre todo el clúster.</strong> Cada nodo guarda su propia copia. La pertenencia al clúster se incluye en <code>/etc/pve</code> para poder volver a incorporar un nodo restaurado, pero recuperar todo el clúster requiere coordinar la restauración de sus nodos.",
"<strong>No es una imagen completa del disco.</strong> No se guardan los binarios del kernel, el initramfs ni la partición de arranque. Al restaurar, ProxMenux utiliza los archivos de arranque del host de destino, regenerados automáticamente con <code>update-initramfs</code> y la herramienta del gestor de arranque, e instala los controladores compatibles con el kernel que está ejecutando el destino."
]
},
"threePillars": {
"heading": "Los tres pilares de una copia",
"intro": "Un archivo de ProxMenux se estructura en torno a tres cargas útiles autocontenidas. La restauración utiliza las tres en conjunto para reproducir el host de origen sobre un destino que puede no tener siquiera el mismo kernel instalado.",
"diagramCaption": "Cada copia contiene los mismos tres bloques con independencia del destino. La restauración los consume todos: rootfs para colocar los ficheros, manifiesto para detectar drift y diferencias cross-kernel, e inventario de aplicaciones para reinstalar paquetes y componentes contra el kernel del propio destino.",
"pillar1Label": "Sistema de ficheros",
"pillar1Label": "Sistema de archivos",
"pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, más snapshot\nsqlite3 de\n/var/lib/pve-cluster,\n+ rutas opcionales)",
"pillar2Label": "Manifiesto",
"pillar2Detail": "manifest.json\n(hardware, params\ndel kernel, red,\nZFS, usuarios, cron,\npools ZFS, storage)",
"pillar2Detail": "manifest.json\n(hardware, parámetros\ndel kernel, red,\nZFS, usuarios, cron,\npools ZFS, almacenamiento)",
"pillar3Label": "Aplicaciones",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(APT manual + instaladores\nProxMenux con versiones)"
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(paquetes APT manuales + instaladores\nProxMenux con versiones)"
},
"restoreIsUniversal": {
"heading": "La restauración reproduce el host de origen, no el archivo",
@@ -51,7 +51,7 @@
"intro": "Cada paso del flujo de copia y restauración está disponible desde dos puntos de entrada. Ambos invocan la misma librería de shell, producen archivos idénticos y leen el mismo registro de trabajos.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "menu → Utilities →\nHost Backup / Restore\n\nFlujo basado en diálogos,\namigable por SSH, admite\nejecución desatendida\ndesde scripts.",
"webLabel": "ProxMenux Monitor (Web UI)",
"webLabel": "ProxMenux Monitor (UI Web)",
"webDetail": "Pestaña Backups en la\ninterfaz Web del Monitor.\n\nRestauración con un clic,\nlog en vivo, integrado con\nlas notificaciones y con\nel visor de rollback."
},
"whereNext": {
web/messages/es/docs/backup-restore/restoring.json
+17 -17
View File
File diff suppressed because one or more lines are too long
web/messages/es/docs/backup-restore/scheduled-jobs.json
+11 -11
View File
@@ -10,7 +10,7 @@
"header": {
"title": "Trabajos programados",
"description": "Trabajos de copia de host desatendidos. Dos modelos de creación: un trabajo nuevo e independiente con su propio horario, o un trabajo adjuntado a una tarea vzdump de PVE existente que hereda el horario y la retención de esa tarea. Ambos producen archivos idénticos al flujo interactivo.",
"section": "Backup & Restore"
"section": "Copias de seguridad y restauración"
},
"intro": {
"title": "Los dos modelos de trabajo programado",
@@ -22,7 +22,7 @@
},
"attachBadge": {
"title": "Modo adjunto — recomendado cuando ya existe una tarea vzdump de PVE",
"body": "Cuando ya hay una tarea de copia vzdump de PVE configurada para las VMs y los LXCs de este nodo, adjuntar la copia de host a esa tarea garantiza que la configuración del host se captura en la <strong>misma ventana</strong> que los invitados. En la restauración, las configuraciones de los invitados vienen de la copia de host (viven bajo <code>/etc/pve</code>), y los discos de los invitados vienen de la copia vzdump tomada al mismo tiempo — ambos conjuntos son consistentes entre sí, por lo que una recuperación completa del nodo puede reproducir el host y re-adjuntar cada invitado sin drift de versiones."
"body": "Si ya existe una tarea vzdump de PVE para las VM y los LXC de este nodo, adjuntar la copia del host hace que se ejecute después de la copia de los invitados, en el <strong>mismo ciclo de copia</strong>. Al restaurar, las configuraciones de los invitados proceden de la copia del host (bajo <code>/etc/pve</code>) y sus discos de las copias vzdump de ese ciclo. Esto facilita coordinar la recuperación de todo el nodo, pero no es una instantánea atómica: los cambios durante el ciclo pueden dejar diferencias entre la configuración del host y el estado de los discos de los invitados."
},
"frequencyBadge": {
"title": "Frecuencia recomendada",
@@ -47,7 +47,7 @@
},
"attachDetail": {
"heading": "Cómo funciona el modo adjunto",
"intro": "PVE escribe las tareas <code>vzdump</code> en <code>/etc/pve/jobs.cfg</code> — una entrada por tarea, cada una apuntando a un storage donde caen los dumps de VMs y LXCs. El modo adjunto requiere que ese storage sea un backend que ProxMenux entienda (Local o PBS); cuando la tarea dispara, ProxMenux se ejecuta al mismo tiempo.",
"intro": "PVE guarda las tareas <code>vzdump</code> en <code>/etc/pve/jobs.cfg</code>: una sección por tarea, con el almacenamiento de las copias de VM y LXC. El modo adjunto requiere un backend compatible con ProxMenux (Local o PBS). La copia del host se ejecuta desde el hook job-end cuando termina la tarea de copia de los invitados.",
"steps": [
{
"step": "1",
@@ -59,14 +59,14 @@
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> registra un script-hook en <code>/etc/vzdump.conf</code>. Cuando PVE ejecuta cualquier tarea vzdump, el script-hook dispara; si el <code>$STOREID</code> que se le pasa coincide con el <code>PVE_STORAGE</code> de un trabajo adjuntado, el runner se invoca para ese trabajo."
"detail": "<code>hb_install_vzdump_hook</code> registra un hook en <code>/etc/vzdump.conf</code>. En la fase job-end de cualquier tarea vzdump, compara el <code>$STOREID</code> recibido con el <code>PVE_STORAGE</code> de cada trabajo adjunto habilitado y ejecuta el script correspondiente si coincide. La asociación se basa en el almacenamiento, no en el ID de la tarea padre seleccionada."
},
{
"step": "4",
"detail": "El archivo aterriza en el mismo storage donde los dumps de vzdump acaban de escribirse: <code>path/dump/</code> para Local, o el repositorio PBS configurado en la entrada de storage de PVE."
}
],
"outroBody": "El modo adjunto tiene una implicación operativa: desactivar o eliminar la tarea padre de PVE también desactiva la copia de host — no hay timer propio al que recurrir. La entrada del trabajo permanece en disco para poder re-adjuntarla más tarde."
"outroBody": "El modo adjunto no tiene temporizador propio. Desactivar o eliminar la tarea padre seleccionada detiene ese disparador, pero otra tarea vzdump con el mismo almacenamiento aún puede activar la copia del host. Para impedirlo, desactiva o elimina el propio trabajo de ProxMenux. Al desactivarlo, su entrada sigue en disco para poder reactivarla o volver a adjuntarla."
},
"storageLayout": {
"heading": "Ficheros que componen un trabajo",
@@ -85,7 +85,7 @@
"content": "Sólo modo Nuevo. El service invoca <code>run_scheduled_backup.sh JOB_ID</code>. El timer lo programa con <code>Persistent=true</code> (los disparos perdidos se ejecutan al siguiente arranque) y un pequeño <code>RandomizedDelaySec=120</code> para repartir carga cuando varios trabajos comparten la misma expresión OnCalendar."
},
{
"path": "script-hook de /etc/vzdump.conf",
"path": "/etc/vzdump.conf script-hook",
"content": "Sólo modo adjunto. Lo instala una vez <code>hb_install_vzdump_hook</code>; casa el <code>PVE_STORAGE</code> de cada trabajo adjuntado contra el <code>$STOREID</code> que PVE pasa al script-hook."
}
]
@@ -104,23 +104,23 @@
"intro": "El menú del scheduler (TUI de Scripts) y la pestaña Backups del Monitor exponen las mismas acciones sobre cualquier trabajo.",
"rows": [
{
"action": "Run now",
"action": "Ejecutar ahora",
"detail": "Invoca el runner de inmediato, saltándose el timer / hook de vzdump. Útil para verificar una configuración de trabajo sin esperar al siguiente disparo programado."
},
{
"action": "Enable / Disable",
"action": "Activar / Desactivar",
"detail": "Modo Nuevo: <code>systemctl enable/disable --now</code> sobre el timer. Modo adjunto: cambia el flag <code>ENABLED</code> en el env del trabajo — el script-hook lo respeta en el siguiente disparo de PVE."
},
{
"action": "Edit",
"action": "Editar",
"detail": "Reabre los prompts de destino, horario, perfil y retención y reescribe los ficheros del trabajo. Preserva el ID del trabajo."
},
{
"action": "Delete",
"action": "Eliminar",
"detail": "Elimina el env del trabajo, el fichero de rutas, el timer + service systemd (modo Nuevo) y desactiva el binding del hook (modo adjunto). No toca los archivos ya presentes en el destino."
},
{
"action": "View log",
"action": "Ver log",
"detail": "Muestra en streaming <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — un fichero de log por ejecución. El runner también emite una línea de estado compacta a journald bajo el service systemd."
}
]
web/messages/fr/docs/backup-restore/creating-backups.json
+220
View File
@@ -0,0 +1,220 @@
{
"meta": {
"title": "Création de sauvegardes — flux de sauvegarde interactif ProxMenux",
"description": "Le processus de sauvegarde interactif de ProxMenux : deux points d’entrée (le menu TUI de Scripts et l’interface web de Monitor), trois destinations, deux modes de profil, une étape de préparation temporaire et une boîte de dialogue de confirmation. Cette page décrit la matrice de six options, les profils par défaut et personnalisé, et ce que voit l’utilisateur entre le choix d’une sauvegarde et l’enregistrement de l’archive à destination.",
"ogTitle": "Sauvegarde ProxMenux — création de sauvegardes",
"ogDescription": "Le processus de sauvegarde interactif avec trois destinations, deux profils et une étape commune de préparation temporaire.",
"twitterTitle": "Création de sauvegardes ProxMenux",
"twitterDescription": "Flux de sauvegarde interactif avec trois destinations et deux modes de profil."
},
"header": {
"title": "Création de sauvegardes",
"description": "Le processus de sauvegarde interactif : choisissez une destination et un profil, vérifiez le récapitulatif de confirmation et suivez l’enregistrement de l’archive. Les deux points d’entrée partagent le même backend et produisent des archives identiques.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Deux points d'entrée, fonctionnalité identique",
"body": "La TUI de Scripts et l’interface web de Monitor offrent <strong>exactement les mêmes fonctions</strong>. Chaque sauvegarde — manuelle ou programmée — utilise la même matrice de choix (trois destinations × deux profils) et appelle la même fonction backend par cellule (<code>_bk_pbs</code>, <code>_bk_borg</code> ou <code>_bk_local</code>). Les archives produites depuis les deux points d’entrée sont identiques. Le choix dépend des préférences : la TUI se prête à SSH et aux scripts ; Monitor permet une utilisation à la souris et regroupe les vues des notifications et du suivi des journaux."
},
"entryPoints": {
"heading": "Les deux points d'entrée",
"rows": [
{
"entry": "ProxMenux Scripts (TUI)",
"path": "menu → Utilities → Host Config Backup",
"detail": "Processus fondé sur des boîtes de dialogue, adapté à SSH. Le menu principal présente directement les six options. Utilise <code>backup_menu</code> dans <code>backup_host.sh</code>."
},
{
"entry": "ProxMenux Monitor (interface utilisateur Web)",
"path": "Backups tab → Create backup",
"detail": "Processus guidé par un assistant. Les six mêmes options sont présentées dans un formulaire en deux étapes (destination → profil). Les mêmes fonctions backend sont appelées via l’API Flask."
}
]
},
"modes": {
"heading": "Sauvegardes manuelles ou programmées",
"body": "Les sauvegardes peuvent être produites en deux modes : <strong>manuel</strong> (le processus interactif décrit sur cette page — l'utilisateur choisit une destination et un profil à partir d'un menu et suit l’enregistrement de l’archive) ou <strong>programmé</strong> (un travail sans surveillance qui fonctionne sur un minuteur de style cron et applique la rétention configurée sur le travail). Les deux modes supportent les mêmes trois destinations et les mêmes deux profils, et les deux sont disponibles à partir des deux points d'entrée — le menu Scripts TUI et l'onglet Sauvegardes Monitor. Les tâches programmées utilisent les mêmes fonctions de backend que le flux manuel à travers <code>run_scheduled_backup.sh</code> ; les archives produites sont indistinguables.",
"seeAlso": "La page des tâches programmées décrit tout le processus, notamment la création d’une tâche, son association à un minuteur vzdump PVE existant et la configuration des valeurs de rétention.",
"monitorAlt": "L'onglet Sauvegardes ProxMenux Monitor affiche la boîte de dialogue Nouvelle sauvegarde programmée avec les champs destination, profil, calendrier et conservation.",
"monitorCaption": "Sauvegarde programmée — ProxMenux Monitor. La même boîte de dialogue de style assistant qui crée une sauvegarde manuelle porte les champs de planning et de rétention en bas pour le chemin sans surveillance."
},
"matrix": {
"heading": "La matrice de six options",
"intro": "Le choix détermine le backend exécuté et la stratégie de sélection des chemins. Consultez les pages de chaque destination pour connaître les détails de configuration de chaque cellule.",
"rows": [
{
"combo": "1",
"destination": "PBS",
"profile": "Par défaut",
"action": "Envoie le profil par défaut et les ajouts persistants vers un dépôt PBS configuré."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Par défaut",
"action": "Crée une archive avec le profil par défaut plus des extras persistants dans le dépôt Borg sélectionné."
},
{
"combo": "3",
"destination": "Locale",
"profile": "Par défaut",
"action": "Écrit une archive <code>.tar.zst</code> avec le profil par défaut et des suppléments persistants à la cible locale configurée."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Personnalisé",
"action": "Ouvre le sélecteur de chemins avant l’envoi vers PBS ; l’utilisateur coche les chemins et peut en ajouter."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Personnalisé",
"action": "Ouvre le sélecteur de chemin avant la création de l'archive Borg."
},
{
"combo": "6",
"destination": "Locale",
"profile": "Personnalisé",
"action": "Ouvre le sélecteur de chemin avant d'écrire le <code>.tar.zst</code> local."
}
]
},
"profiles": {
"heading": "Profil par défaut vs personnalisé",
"defaultTitle": "Profil par défaut",
"defaultBody": "Le profil par défaut est la liste prédéfinie de <code>hb_default_profile_paths</code> (documentée dans <em>Comment ça marche</em> sous <em>Catégories de chemins</em>) plus chaque entrée dans le fichier supplémentaire persistant <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. L'utilisateur confirme les options de destination et de chiffrement et la sauvegarde se déroule sans autre sélection de chemin.",
"customTitle": "Profil personnalisé",
"customBody": "Le profil personnalisé ouvre une liste à cocher avec tous les chemins du profil par défaut (décochés) et tous les ajouts persistants (précochés, avec le préfixe <code>[+]</code>). L’utilisateur coche les chemins pour cette exécution et peut cliquer sur <em>Ajouter un chemin personnalisé</em> pour ajouter un chemin absolu. Tout chemin ainsi ajouté est enregistré dans <code>backup-extra-paths.txt</code> afin que les sauvegardes suivantes l’incluent automatiquement. Décocher un ajout persistant l’exclut de cette exécution sans le supprimer du fichier — la suppression se fait séparément par <em>Gérer les chemins personnalisés</em>, en dehors du processus de sauvegarde.",
"customPickerAlt": "Liste de contrôle de profil personnalisé montrant les chemins de profil par défaut (non coché) et les extras persistants (pré coché avec un préfixe [+]), ainsi que des boutons pour ajouter un nouveau chemin ou confirmer la sélection.",
"customPickerCaption": "Profil personnalisé — le sélecteur de chemins. Les chemins du profil par défaut sont décochés ; les ajouts persistants sont précochés avec le préfixe [+]. L’utilisateur coche les chemins pour cette exécution.",
"manageCustomAlt": "Menu de gestion des chemins personnalisés montrant les ajouts persistants et les options pour les ajouter, les supprimer ou les modifier.",
"manageCustomCaption": "Gérer les chemins personnalisés — le point d'entrée où des extras persistants sont ajoutés ou supprimés. Chaque chemin listé ici est automatiquement inclus dans les sauvegardes en mode Défaut sans avoir à ouvrir le sélecteur personnalisé."
},
"commonPipeline": {
"heading": "Ce qui s’exécute quelle que soit la destination",
"intro": "Une fois le profil défini, chaque backend suit le même processus de préparation temporaire avant de passer à sa propre méthode d’envoi. <code>hb_prepare_staging</code> assemble l’arborescence de l’archive dans <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> et remplit chacun des trois blocs de données.",
"steps": [
{
"step": "1",
"name": "Assemblage du rootfs",
"detail": "Exécute <code>rsync -a</code> pour chaque chemin sélectionné dans <code>staging_root/rootfs/</code>. La base de données pmxcfs de <code>/var/lib/pve-cluster/config.db</code> est capturée séparément via <code>sqlite3 .backup</code> pour produire un instantané cohérent sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync; lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé comme base de données lors de l’importation. Les sous-chemins volatils (historique bash, caches, poubelles) sont exclus du <code>/root/</code>. Les chemins absents de la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
},
{
"step": "2",
"name": "Génération de manifestes",
"detail": "<code>build_manifest.sh</code> coordonne les six collecteurs et écrit <code>manifest.json</code> à la racine du répertoire temporaire. Si un collecteur échoue, la section concernée reçoit une valeur vide par défaut documentée ; le manifeste reste valide."
},
{
"step": "3",
"name": "Inventaire des paquets",
"detail": "<code>apt-mark showmanual</code> est capté mot à mot dans <code>metadata/packages.manual.list</code>. L'état des composants est déjà à l'intérieur des rootfs restauré (<code>components_status.json</code>) car <code>/usr/local/share/proxmenux/</code> fait partie du profil par défaut."
},
{
"step": "4",
"name": "Informations sur l’exécution",
"detail": "<code>metadata/run_info.env</code> enregistre l'identité d'exécution de sauvegarde — nom d'hôte, horodatage, version du noyau — utilisée par la vérification de compatibilité de la restauration pour déterminer la direction du cross-kernel."
},
{
"step": "5",
"name": "Notification (démarrage)",
"detail": "<code>hb_notify_lifecycle \"start\"</code> est déclenché. Si les notifications sont configurées dans Monitor, un événement <em>Sauvegarde de l’hôte démarrée</em> est envoyé à l’utilisateur. Aucun envoi si aucun canal n’est configuré."
}
]
},
"included": {
"heading": "Ce qui entre et ce qui reste en dehors",
"intro": "Chaque chemin dans le profil résolu (par défaut + suppléments persistants + sélection en mode personnalisé) est copié avec <code>rsync -aAXH --numeric-ids</code>. Une liste d'exclusion partagée s'applique à chaque chemin, et deux répertoires comportent d'autres exclusions spécifiques au chemin.",
"globalTitle": "Les exclusions globales (appliquées à chaque voie)",
"globalItems": [
"<code>images/</code> — images de disque exportées.",
"<code>dump/</code> — sorties vzdump.",
"<code>tmp/</code> — fichiers temporaires.",
"<code>*.log</code> — fichiers journaux."
],
"rootTitle": "Exclusions de <code>/root/</code>",
"rootBody": "<code>/root/</code> fait partie du profil par défaut, de sorte que les scripts utilisateur et la configuration se trouvent dans l'archive. Les sous-chemins volatils sont abandonnés:",
"rootItems": [
"<code>.bash_history</code>",
"<code>.cache/</code>",
"<code>tmp/</code>",
"<code>.local/share/Trash/</code>"
],
"proxmenuxTitle": "Exclusions de <code>/usr/local/share/proxmenux/</code>",
"proxmenuxBody": "Ce répertoire ne livre que l'état utilisateur — <code>components_status.json</code>, préférences, cache post-installation. Code que la destination aura déjà de sa propre installation ProxMenux est exclu de sorte qu'une restauration n'écrase pas les binaires actuels de la cible avec les plus anciens:",
"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": "Chemins en dehors du profil",
"notInProfileBody": "Tout ce qui n'est pas listé dans <code>hb_default_profile_paths</code> et qui n'est pas ajouté en tant qu'extra personnalisé ou persistant ne fait pas partie de la sauvegarde. Exemples notables:",
"notInProfileItems": [
"<strong>Disques des VM et des LXC</strong> — manipulés par <code>vzdump</code>, pas par cette fonctionnalité. Les fichiers de configuration invités sous <code>/etc/pve/nodes/*/qemu-server/*.conf</code> et <code>lxc/*.conf</code> sont capturés (ils vivent sous <code>/etc/pve</code>) de sorte que la restauration reproduit l'inventaire; les disques eux-mêmes sont ré-attachés à partir d'une sauvegarde existante vzdump/PBS.",
"<strong><code>/boot</code> et <code>/boot/efi</code></strong> — les binaires du noyau, les initramfs et la partition ESP UEFI sont régénérés par les propres <code>update-initramfs</code>, <code>update-grub</code> ou <code>proxmox-boot-tool refresh</code> après la restauration. Le chargeur de démarrage n’est jamais recopié à l’identique.",
"<strong>Les systèmes de fichiers de noyau et d'exécution du système</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> et <code>/run</code> sont des pseudo-systèmes de fichiers produits par le noyau et l'udev; ils ne persistent nulle part.",
"<strong>Binaires des paquets sous <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — réinstallés par APT sur la cible à partir de <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — état d'exécution par hôte, non restauré.",
"<strong><code>/home/USER</code></strong> — pas dans le profil par défaut. Ajoutez-le comme un chemin personnalisé lorsqu'un système transporte des répertoires d'utilisateur qui doivent survivre à une restauration."
],
"customPathsTitle": "Comment les chemins personnalisés sont gérés",
"customPathsBody": "Un chemin personnalisé ajouté en ligne en mode personnalisé ou maintenu dans <code>backup-extra-paths.txt</code> passe par le même pipeline <code>rsync</code> que les chemins de profil par défaut. Les exclusions globales s'appliquent. Si le chemin personnalisé se trouve sous <code>/root/</code> ou <code>/usr/local/share/proxmenux/</code>, les exclusions spécifiques au chemin ci-dessus s'appliquent toujours. Chaque chemin archivé — par défaut ou personnalisé — est enregistré dans <code>metadata/paths_archived.txt</code>. Les chemins qui n'existent pas sur la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
},
"archiveStructure": {
"heading": "Structure des archives",
"intro": "Le répertoire de préparation temporaire produit par chaque moteur suit la même disposition quelle que soit la destination. L'archive tarball, PBS <code>.pxar</code> ou Borg stocke cet arbre dans son intégralité.",
"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": "Résumé de la confirmation",
"body": "Avant que le moteur n'écrive quoi que ce soit à la destination, ProxMenux affiche une boîte de dialogue de résumé avec la destination, l’identifiant de sauvegarde ou le nom de l’archive, l'état de chiffrement et la liste des chemins copiés. Annuler ici avorte la sauvegarde proprement — le répertoire temporaire est supprimé par le gestionnaire <code>trap</code> défini dans la fonction backend et aucune donnée partielle n'arrive à destination."
},
"writing": {
"heading": "Écrire à la destination",
"intro": "Après confirmation, chaque backend exécute sa propre étape d’écriture. Les pages des destinations en décrivent le fonctionnement ; les éléments communs sont le journal, le fichier annexe et la notification de fin.",
"rows": [
{
"topic": "Fichier journal",
"detail": "Chaque moteur écrit sa sortie complète sur <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> et, en cas d'échec, propose de l'ouvrir dans une boîte de dialogue défilante. Le chemin du journal n'est imprimé dans le résumé d'achèvement que lorsque le fichier contient du contenu."
},
{
"topic": "Sidecar (local seulement)",
"detail": "<code>hb_write_archive_sidecar</code> dépose un <code>*.proxmenux.json</code> à côté de l'archive locale afin que le moniteur l'identifie comme une sauvegarde d'hôte ProxMenux même après des déplacements ou des renoms."
},
{
"topic": "Notification (réussite/échec)",
"detail": "<code>hb_notify_lifecycle \"complete\"</code> ou <code>\"fail\"</code> est déclenché avec la durée, la taille de l’archive et — en cas d’échec — la dernière ligne du journal qui ressemble à une erreur."
}
]
},
"finishedScreens": {
"heading": "A quoi ressemble une sauvegarde terminée",
"intro": "Le même événement d'achèvement est présenté par les deux points d'entrée. Le TUI écrit un bloc de résumé au terminal; l'onglet Sauvegardes de Monitor affiche l'exécution dans la liste des archives avec la taille, la durée et les badges d'état.",
"scriptsAlt": "ProxMenux Scripts TUI montrant une sauvegarde d'hôte terminée — destination, ID de sauvegarde, chemin instantané, taille des données, durée et état de chiffrement.",
"scriptsCaption": "Sauvegarde terminée — ProxMenux Scripts (TUI). Le bloc d'achèvement imprime la destination, l'ID de sauvegarde, le nom d'instantané ou d'archive, la taille des données, la durée et l'état de chiffrement.",
"monitorAlt": "Onglet de sauvegarde ProxMenux Monitor montrant une entrée de sauvegarde d'hôte terminée avec taille, durée, badge de méthode et indicateur de chiffrement.",
"monitorCaption": "Sauvegarde terminée — onglet Sauvegardes ProxMenux Monitor. La nouvelle sauvegarde apparaît dans la liste des archives avec le badge de la méthode de destination, la taille, la durée et, le cas échéant, l'indicateur de verrouillage de chiffrement."
},
"whereNext": {
"heading": "Où aller ensuite?",
"items": [
{
"label": "Destinations",
"href": "/docs/backup-restore/destinations",
"tail": "— détails de configuration pour Local, PBS et Borg."
},
{
"label": "Tâches programmées",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": " — exécuter la même sauvegarde sans intervention selon un calendrier, plutôt que de façon interactive."
},
{
"label": "Restauration",
"href": "/docs/backup-restore/restoring",
"tail": "— le flux qui consomme ce que cette page produit."
}
]
}
}
web/messages/fr/docs/backup-restore/cross-kernel.json
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Restauration entre noyaux différents — détection, filtrage et adaptation | ProxMenux",
"description": "Comment ProxMenux restaure une sauvegarde d’hôte sur une version principale différente du noyau. Détection du sens de l’écart, filtre des chemins critiques si la cible utilise un noyau plus récent et adaptation en quatre phases pour réappliquer IOMMU, ID VFIO et paramètres de ligne de commande sans recopier tels quels les fichiers liés au noyau.",
"ogTitle": "ProxMenux Backup — restauration entre versions du noyau et adaptation",
"ogDescription": "Restauration entre versions du noyau tenant compte du sens du changement, avec filtrage sûr et adaptation indépendante du noyau.",
"twitterTitle": "Restauration entre noyaux différents | ProxMenux",
"twitterDescription": "Comment ProxMenux gère une restauration lorsque le noyau cible diffère de celui de la sauvegarde."
},
"header": {
"title": "Restauration entre versions du noyau",
"description": "Comment ProxMenux gère une restauration lorsque l'hôte cible exécute un noyau différent de celui enregistré dans la sauvegarde, surtout lorsque la cible exécute un noyau plus récent. Explique comment la différence est détectée, comment les chemins critiques de démarrage qui pourraient briser la cible sont filtrés, et comment la configuration propre de l'utilisateur est réappliquée sans copier les fichiers liés au noyau mot pour mot.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Chaque saut du noyau est géré différemment",
"body": "Le noyau d'un hôte Proxmox est identifié par une chaîne de version comme <code>6.17.13-2-pve</code>. Les deux premiers nombres (<strong>6.17</strong> dans cet exemple) définissent la version principale : lorsqu'ils changent, certains fichiers de configuration écrits pour le noyau précédent peuvent ne pas être valides sur le nouveau. Lorsque la restauration détecte que la sauvegarde et la cible ont différentes versions majeures du noyau, les branches de flux basées sur la direction du saut — que la sauvegarde soit plus ancienne ou plus récente que la cible — parce que les deux cas ont des modes de défaillance opposés. Les sauvegardes plus récentes que la cible restaurent proprement comme-est (vérifiées sur plusieurs sauts du noyau). Les sauvegardes plus anciennes que la cible ont besoin d'un filtre pour éviter de casser le démarrage de la cible avec une configuration écrite pour un noyau qui a depuis changé."
},
"directionCheck": {
"heading": "Le contrôle de direction",
"intro": "Lors de la vérification de compatibilité, <code>hb_compat_check</code> compare le noyau enregistré dans le manifeste de sauvegarde au noyau courant de la cible (<code>uname -r</code>) et classifie la restauration dans l'un des trois cas, stockés dans la variable interne <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{
"direction": "same",
"condition": "La version principale du noyau correspond entre la sauvegarde et la cible.",
"behavior": "Le flux complet de restauration est inchangé. Pas de filtre supplémentaire, pas d'hydratation, pas de notice spéciale dans l'interface utilisateur."
},
{
"direction": "bk_newer",
"condition": "Le noyau de la sauvegarde est PLUS RÉCENT que celui de la cible (exemple : sauvegarde sous 7.0, cible sous 6.17).",
"behavior": "Le processus complet reste inchangé, comme pour <code>same</code>, sans filtre. Les essais rapportés ont montré la réinstallation des pilotes pour le noyau cible, l’application de la configuration IOMMU et le démarrage des VM avec passthrough GPU."
},
{
"direction": "bk_older",
"condition": "Le noyau de la sauvegarde est PLUS ANCIEN que celui de la cible (exemple : sauvegarde sous 6.17, cible sous 7.0).",
"behavior": "Le filtre sous-ensemble et l'hydratation en quatre phases ci-dessous sont activés. Le processus de restauration — la cible reproduit la source, mais les fichiers critiques de démarrage ne sont pas copiés mot à mot."
}
]
},
"whyBkNewerIsSafe": {
"heading": "Pourquoi une sauvegarde avec un noyau plus récent que la cible restaure inchangé",
"body": "Lorsque la restauration s'exécute contre une cible avec un noyau <em>plus ancien</em> que celui enregistré dans la sauvegarde, chaque mécanisme dont dépend la restauration est indépendant de la version du noyau. Les installateurs de pilotes GPU et d'autres installateurs PCI détectent le noyau en cours d'exécution avec <code>uname -r</code> et compilent DKMS contre tout ce que la cible a. Le paquet APT installe tire des binaires construits pour la distribution de la cible. Les jetons IOMMU cmdline comme <code>intel_iommu=on</code> sont stables dans les principales versions du noyau. La sauvegarde porte des chemins écrits sous un noyau plus récent, mais ces chemins (module blacklists, GRUB par défaut, initramfs config) sont toujours valides sur l'ancien — les noyaux ignorent les jetons qu'ils ne reconnaissent pas au lieu d'échouer. Ce cas est équivalent en pratique à une restauration du même noyau, et ProxMenux le traite comme tel."
},
"safeSubsetFilter": {
"heading": "Le filtre de sous-ensemble de sécurité (uniquement lorsque le noyau cible est plus récent)",
"intro": "Lorsque le noyau cible est plus récent que celui de la sauvegarde, la vérification de compatibilité ajoute des chemins critiques de démarrage 16 de <code>hb_unsafe_paths_cross_version</code> à <code>RS_SKIP_PATHS</code>. Ces chemins sont exclus de la restauration parce que l'écriture d'une version d'un noyau plus ancien sur une cible en cours d'exécution d'un nouveau a causé des paniques du noyau dans les tests de banc. Les chemins couvrent cinq catégories:",
"categoryRows": [
{
"category": "Chargeur d'amorçage",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB est lié à l'ordre du noyau précédent, et à l'état proxmox-boot-tool (cmdline, ESP UUIDs, crochets) qui fait référence aux chemins et aux identifiants de l'ancienne installation."
},
{
"category": "Modules de noyau et artefacts de démarrage",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Autoload listes qui peuvent renvoyer des modules rebaptisés entre les majors du noyau, options de module qui peuvent ne pas s'appliquer, initramfs crochets écrits pour l'ancien noyau."
},
{
"category": "Empilement de stockage et identité du système de fichiers",
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
"reason": "UUID qui peuvent ne pas exister sur cette installation, pilotes multipath qui changent entre les noyaux, paramètres iSCSI qui évoluent, règles udev qui peuvent se lier à des sous-systèmes inexistants, état ZFS (<code>zpool.cache</code> + <code>hostid</code>) qui peuvent verrouiller le pool comme étranger."
},
{
"category": "Sources APT",
"paths": "<code>/etc/apt</code>",
"reason": "Les suites sources APT peuvent déclencher une dégradation des paquets critiques lors de la prochaine mise à jour."
},
{
"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": "Surcharges d’unités et liens .wants liés à une ancienne version majeure de systemd ; clés de configuration pouvant être invalides pour une version plus récente."
}
],
"outroBody": "Le filtre fonctionne AVANT la boîte de dialogue de confirmation afin que l'utilisateur voit la liste exacte des chemins qui seront ignorés, catégorisé par la raison. La restauration continue — tout le reste (configuration VM/LXC, réseau, /etc/pve, utilisateurs, cron, état ProxMenux, paquets, pilotes, /root) est restauré normalement."
},
"hydration": {
"heading": "Hydratation du noyau-agnostique",
"intro": "Le filtre omet les fichiers critiques ; l’adaptation réapplique certains réglages : paramètres IOMMU, ID VFIO, <code>GRUB_TIMEOUT</code> personnalisé et listes de blocage nvidia. Elle s’exécute si le noyau cible est plus récent. La fusion cmdline conserve les clés de la cible et ajoute les modules manquants. Les valeurs GRUB et fichiers autorisés peuvent remplacer un contenu cible différent. Répéter les mêmes entrées est idempotent.",
"phaseRows": [
{
"phase": "1a — Voie GRUB",
"detail": "Pour les hôtes GRUB (installations ext4/lvm). <code>_rs_hyd_grub</code> fusionne les paramètres de <code>manifest.kernel_params.cmdline_extra</code> de la sauvegarde dans <code>GRUB_CMDLINE_LINUX_DEFAULT</code> de la cible, en ignorant les clés déjà présentes. Il reprend ensuite les clés autorisées <code>GRUB_*</code> (<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>) depuis <code>/etc/default/grub</code> de la sauvegarde si leurs valeurs diffèrent de la cible."
},
{
"phase": "1b — systemd-boot / ZFS",
"detail": "Pour systemd-boot (souvent ZFS à la racine). <code>_rs_hyd_kernel_cmdline</code> fusionne les paramètres utilisateur de <code>cmdline_extra</code> dans <code>/etc/kernel/cmdline</code> de la cible tout en préservant ses paramètres de démarrage <code>root=</code>, <code>boot=</code> et <code>rootflags=</code>."
},
{
"phase": "2 — Fusion /etc/modules",
"detail": "<code>_rs_hyd_modules</code> ajoute des modules de <code>manifest.kernel_params.modules_loaded_at_boot</code> qui sont dans la liste blanche (<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>) ET n'est pas déjà présent dans la cible <code>/etc/modules</code>."
},
{
"phase": "3 — Copie des fichiers figurant sur la liste blanche",
"detail": "<code>_rs_hyd_files</code> copie les fichiers rédigés par l’utilisateur depuis les rootfs jusqu'à la cible en direct lorsque le contenu diffère. La liste blanche couvre les fichiers VFIO/nvidia/blacklist sous <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, et la règle de liaison ProxMenux VFIO + règles nvidia udev sous <code>/etc/udev/rules.d</code>. Les fichiers appartenant à des Distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sont délibérément exclus — leur contenu évolue entre les versions."
},
{
"phase": "4 — Forcer la régénération après démarrage",
"detail": "Les quatre phases écrivent directement à la cible en direct EN DEHORS DE le pipeline normal de restauration. Pour que les paramètres/modules/fichiers fusionnés prennent effet sur le prochain boot, <code>HB_HYDRATION_APPLIED=1</code> se propage via <code>plan.env</code> vers <code>apply_pending_restore.sh</code>, ce qui force <code>NEEDS_INITRAMFS=1</code> et <code>NEEDS_GRUB=1</code> indépendamment de ce qui était dans la liste d'application. Le répartiteur post-démarrage régénère ensuite les initramfs et rafraîchit le chargeur."
}
]
},
"planCommit": {
"heading": "Plan vs commit — l'utilisateur voit d'abord un aperçu",
"body": "L'hydratation fonctionne en deux modes. Avant la boîte de dialogue de confirmation, ProxMenux exécute <code>_rs_apply_bk_older_hydration</code> en mode <code>plan</code> : il calcule exactement ce qui serait fusionné, peuple <code>RS_HYDRATION_SUMMARY</code> avec un bloc vert listant chaque action, et retourne sans écrire. La boîte de dialogue de confirmation montre que le bloc vert à côté de la liste orange des chemins exclus, de sorte que l'utilisateur voit À L’AVANCE ce qui sera ré-appliqué automatiquement. Après que l'utilisateur ait confirmé, ProxMenux réexécute le même helper en mode <code>commit</code> — mêmes phases, même logique, mais cette fois chaque phase écrit à la cible en direct. L'annulation de la boîte de dialogue de confirmation laisse la cible intacte."
},
"flowDiagram": {
"heading": "Le flux lorsque le noyau cible est plus récent que celui de la sauvegarde",
"intro": "Les étapes ajoutées lorsque le noyau cible est plus récent s'assoient à l'intérieur du flux normal de restauration. Tout le reste — application chaude, préparation en attente, installation de paquets, répartiteur post-démarrage — fonctionne identiquement à une restauration du même noyau.",
"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": "Exemples concrets",
"intro": "Le passe d'hydratation n'est pas abstrait — il produit des résultats observables et corrects pour des scénarios communs. Deux exemples que l'hydratation gère automatiquement :",
"rows": [
{
"scenario": "Passage de GPU (VFIO)",
"detail": "La source avait le <code>intel_iommu=on iommu=pt</code> dans la ligne cmd, le <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> dans le <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> avec le <code>options vfio-pci ids=10de:2216</code> et un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. L'hydratation fusionne les jetons cmdline dans le GRUB de la cible ou le noyau cmdline, ajoute les modules vfio au <code>/etc/modules</code>, et copie les deux fichiers modprobe rédigés par l’utilisateur. Sur le prochain démarrage, IOMMU est actif, les modules VFIO chargent, le GPU est lié à vfio-pci et le VM est livré avec le travail de passage."
},
{
"scenario": "Par défaut du GRUB personnalisé",
"detail": "Source : <code>GRUB_TIMEOUT=1</code> et <code>GRUB_DISABLE_OS_PROBER=true</code>. L'hydratation lit les deux clés de la sauvegarde <code>/etc/default/grub</code>, voit qu'elles diffèrent des valeurs par défaut de la nouvelle installation, et réécrit ces deux lignes dans le fichier de la cible (en laissant tout le reste, y compris <code>GRUB_DISTRIBUTOR</code>, intact)."
}
]
},
"callout": {
"warningTitle": "Ce que l'hydratation ne réapplique pas lorsque le noyau cible est plus récent",
"warningBody": "L'hydratation ne réapplique que la configuration ProxMenux sait être sûre dans toutes les versions du noyau : jetons IOMMU, ID VFIO, clés GRUB sur liste blanche et modules d'une liste fixe (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Tout ce qui se trouve à l'extérieur de cet ensemble — les crochets initramfs personnalisés sous <code>/etc/initramfs-tools/hooks/</code>, les fichiers non inscrits sur la liste blanche sous <code>/etc/modprobe.d/</code>, les surcharges d’unités systemd rédigées par l’utilisateur — reste exclu. La raison en est concrète : ces fichiers peuvent appeler des interfaces internes au noyau (API modulaires, mise en page <code>/sys</code>, crochets <code>udev</code>) qui changent entre les versions principales, et les appliquer mot à mot sur le nouveau noyau peut empêcher la cible de démarrer. Lorsque la reproduction exacte de la chaîne de démarrage est requise, la restauration doit être exécutée sur un hôte avec la même version principale du noyau que la sauvegarde."
},
"codeReference": {
"heading": "Où vivent les mécanismes",
"intro": "Pour les développeurs qui cherchent à tracer ou à étendre le comportement du cross-kernel:",
"rows": [
{
"component": "Détection de la direction",
"location": "<code>hb_compat_check</code> dans <code>lib_host_backup_common.sh</code>. Définit <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Liste des chemins de sous-ensembles sécurisés",
"location": "<code>hb_unsafe_paths_cross_version</code> dans <code>lib_host_backup_common.sh</code>. Émet <code>path\\treason</code> lignes utilisées à la fois par le filtre CLI et le point de terminaison Web <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Phases d'hydratation",
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> dans <code>backup_host.sh</code>. Ordonné par <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Régénération forcée après démarrage",
"location": "<code>apply_pending_restore.sh</code> lit <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> et force <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Aperçu du Web",
"location": "<code>/api/host-backups/restore/prepare</code> dans <code>flask_server.py</code>. Charge la bibliothèque d'aide, exécute <code>_rs_apply_bk_older_hydration</code> en mode plan, renvoie les actions au mode Web."
}
]
},
"whereNext": {
"heading": "Où aller ensuite?",
"items": [
{
"label": "Restauration",
"href": "/docs/backup-restore/restoring",
"tail": " — le processus complet de restauration qui intègre les mécanismes de cette page."
},
{
"label": "Comment ça marche",
"href": "/docs/backup-restore/how-it-works",
"tail": " — le manifeste et les collecteurs qui produisent le bloc <code>kernel_params</code> lu par l’adaptation."
}
]
}
}
web/messages/fr/docs/backup-restore/destinations/borg.json
+234
View File
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Destination Borg — types de dépôts, authentification SSH, chiffrement | ProxMenux",
"description": "La destination Borg enregistre les sauvegardes d’hôte ProxMenux dans un dépôt local, sur un disque externe monté ou sur un serveur distant via SSH. Cette page décrit la recherche de l’exécutable borg, les quatre options initiales de clé SSH, le chiffrement repokey, la configuration des destinations enregistrées et la rétention par tâche planifiée.",
"ogTitle": "Sauvegarde ProxMenux — Destination borg",
"ogDescription": "Comment ProxMenux enregistre les sauvegardes d’hôte dans des dépôts Borg avec authentification SSH et chiffrement repokey.",
"twitterTitle": "Destination de sauvegarde Borg: ProxMenux",
"twitterDescription": "Dépôts Borg locaux, USB et SSH pour les sauvegardes hôtes."
},
"header": {
"title": "Borg",
"description": "La destination Borg écrit des sauvegardes d'hôte dans un dépôt Borg. Trois types de dépôt sont pris en charge : chemin du système de fichiers local, disque externe monté ou serveur distant via SSH. Déduplication au niveau du chunk dans toutes les archives du dépôt et cryptage facultatif des repokey.",
"section": "Sauvegarde et restauration"
},
"aboutBorg": {
"heading": "Ce que Borg est",
"body": "Borg, aussi appelé BorgBackup, est un outil de sauvegarde libre avec déduplication, maintenu par la communauté Borg Backup. Il stocke chaque archive sous forme de blocs de longueur variable dans un dépôt. Les blocs sont partagés entre archives : sauvegarder à nouveau des données inchangées ne consomme presque aucun espace supplémentaire. Borg est indépendant de Proxmox et sert dans de nombreux environnements. ProxMenux l’utilise comme l’une des trois destinations de sauvegarde d’hôte ; les mécanismes décrits ici (types de dépôts, borg-serve via SSH, chiffrement repokey, prune) sont ceux de Borg."
},
"intro": {
"title": "Déduplication par blocs avec dépôts locaux ou accessibles via SSH",
"body": "Un dépôt Borg stocke des blocs partagés entre toutes ses archives. Sauvegarder à nouveau un fichier inchangé ne transfère ni ne stocke de nouvelles données. ProxMenux utilise <code>borg create</code> pour sauvegarder et <code>borg extract</code> pour restaurer. Le dépôt peut se trouver sur le même système de fichiers que la source, sur un disque externe monté ou sur un hôte distant accessible via SSH."
},
"binarySourcing": {
"heading": "Le binaire borg",
"intro": "Borg n'est pas une dépendance de base de l'installateur ProxMenux. Lorsqu'une sauvegarde s'exécute, <code>hb_ensure_borg</code> résout le binaire à partir de quatre sources dans l'ordre et retourne le premier qui fonctionne :",
"rows": [
{
"priority": "1",
"source": "Système <code>borg</code>",
"detail": "Si l'hôte a déjà <code>borg</code> installé via APT (<code>which borg</code> résout), ce binaire est utilisé."
},
{
"priority": "2",
"source": "Cache du répertoire d’état",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — conservé d'un téléchargement préalable de GitHub sur cet hôte."
},
{
"priority": "3",
"source": "Paquet AppImage du moniteur",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — le AppImage regroupe un borg-linux64 signé. C'est le chemin hors ligne sécurisé : un hôte sans internet a toujours un <code>borg</code> fonctionnant."
},
{
"priority": "4",
"source": "Téléchargement GitHub",
"detail": "<code>wget</code> contre l'URL <code>borg-linux64</code> épinglée sous <code>github.com/borgbackup/borg/releases/</code>, vérifiée contre une constante SHA-256 dans <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). En cas de somme de contrôle incorrecte, le binaire est rejeté et la sauvegarde avorte. Le fichier téléchargé est mis en cache dans l'état dir afin que les sauvegardes suivantes utilisent le chemin 2."
}
]
},
"repoTypes": {
"heading": "Types de dépôts",
"intro": "Le type de dépôt est choisi lorsqu'une cible est ajoutée. Chaque type résout une URL de dépôt différente que Borg comprend.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "Le dépôt vit sur un serveur distant qui exécute <code>borg serve</code>. Nécessite une connexion SSH à ce serveur."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "Le dépôt vit sur un disque externe monté (habituellement USB). Le montage est résolu via <code>hb_prompt_mounted_path</code>, qui détecte, monte ou formate les partitions USB au besoin."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "Le dépôt vit dans un répertoire local. Signifiant seulement lorsque le répertoire cible est sur un disque physique séparé — un dépôt sur le même disque que la source protège contre l'erreur de l'opérateur mais pas contre la défaillance du disque."
}
]
},
"serverSetup": {
"heading": "Préparation du serveur Borg (côté serveur)",
"intro": "Le type de dépôt <code>remote</code> nécessite un serveur Borg fonctionnel accessible via SSH. ProxMenux ne configure pas le serveur lui-même : il autorise seulement une clé sur un compte existant. Cette section décrit les prérequis du serveur.",
"hostChoicesTitle": "Où le serveur peut vivre",
"hostChoicesBody": "Tout hôte Linux avec accès SSH se qualifie. Configurations communes :",
"hostChoicesItems": [
"Un NAS dédié ou une boîte de sauvegarde (Debian, Ubuntu, TrueNAS SCALE avec un shell).",
"Un conteneur LXC à l'intérieur d'un nœud Proxmox. Petite empreinte, isolée de l'hôte exécutant les sauvegardes.",
"Un autre hôte Proxmox sur le même LAN, ou un VM n'importe où accessible sur SSH."
],
"lxcWarningTitle": "LXC comme serveur Borg",
"lxcWarningBody": "Si le serveur Borg est dans un LXC, generate-auto nécessite un compte acceptant l’authentification SSH par mot de passe pour installer la clé. Sinon, utilisez l’installation manuelle ou l’alternative generate-pct via l’hôte PVE.",
"requirementsTitle": "Exigences sur le serveur",
"requirementsRows": [
{
"requirement": "Exécutable borg dans <code>/usr/bin/borg</code>",
"detail": "La ligne <code>command=\"/usr/bin/borg serve ...\"</code> écrite par ProxMenux dans <code>authorized_keys</code> utilise ce chemin fixe. L’installation APT (<code>apt install borgbackup</code>) y place l’exécutable. Pour un binaire autonome, créez un lien symbolique à <code>/usr/bin/borg</code>."
},
{
"requirement": "Un compte utilisateur dédié (généralement <code>borg</code>)",
"detail": "Possède le répertoire du dépôt et reçoit les connexions SSH entrantes. N'a pas besoin d'accès sudo ou shell — la ligne authorized_keys désactive de toute façon les shells interactifs."
},
{
"requirement": "Un répertoire de dépôt en écriture",
"detail": "Le chemin que l'opérateur donne à ProxMenux (par exemple <code>/backup/borgbackup</code>) doit exister sur le serveur et être la propriété de l'utilisateur borg."
},
{
"requirement": "SSH démon acceptant l'utilisateur borg",
"detail": "<code>PubkeyAuthentication yes</code> (par défaut). L'authentification par mot de passe n'est nécessaire que pour le flux <em>generate-auto</em>, une fois la clé installée, le serveur peut désactiver complètement le mot de passe auth."
}
],
"minimalSetupTitle": "Configuration minimale du serveur",
"minimalSetupBody": "Sur un serveur Debian ou Ubuntu Borg, une référence de travail est quatre commandes comme root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Une fois le serveur préparé et l’authentification SSH par mot de passe disponible, <code>generate-auto</code> installe la clé via un compte pouvant écrire dans authorized_keys de l’utilisateur borg. Les sauvegardes suivantes utilisent cette clé, limitée à <code>borg serve</code> au chemin configuré. Sans connexion par mot de passe, installez-la manuellement ou via l’hôte PVE."
},
"sshAuth": {
"heading": "authentification SSH (côté client)",
"intro": "Les dépôts distants Borg sont accessibles sur SSH. La connexion passe de l'hôte ProxMenux à un compte utilisateur sur le serveur Borg qui exécute <code>borg serve</code>. Cet utilisateur s'appelle généralement <code>borg</code>, PAS l'utilisateur admin/root du serveur — la ligne de commande borg-serve verrouille la connexion à ce chemin de dépôt spécifique (voir les stratégies clés ci-dessous).",
"strategiesTitle": "Stratégies de clé SSH",
"strategiesIntro": "Lors de l’ajout d’une destination distante, ProxMenux demande l’utilisateur SSH, l’hôte et le chemin distant, puis propose quatre choix d’authentification. L’alternative generate-pct est proposée si l’authentification par mot de passe est refusée. Voici les modes :",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Recommandé",
"detail": "ProxMenux crée ou réutilise une paire de clés ed25519 dans <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, puis utilise <code>sshpass</code> pour tester la connexion et installer la clé publique dans <code>~borg/.ssh/authorized_keys</code>. Le mot de passe est celui d’un compte autorisé à écrire ce fichier, généralement root ou borg. Il sert pendant la configuration et n’est pas enregistré."
},
{
"mode": "generate-manual",
"label": "Pas de mot de passe admin sur cet hôte",
"detail": "ProxMenux génère la paire de clés comme ci-dessus, mais affiche la ligne complète <code>authorized_keys</code> pour que l'opérateur colle manuellement dans le serveur. Le mot de passe administrateur ne quitte jamais l'hôte ProxMenux car il n'est jamais demandé."
},
{
"mode": "generate-pct",
"label": "Le serveur Borg est un PVE LXC",
"detail": "Le serveur Borg fonctionne à l'intérieur d'un LXC sur un nœud PVE. ProxMenux autorise la clé via <code>pct exec</code> de l'hôte PVE — root sur l'hôte PVE écrit dans le LXC de <code>~borg/.ssh/authorized_keys</code> sans avoir besoin de SSH dans le LXC lui-même."
},
{
"mode": "existing",
"label": "Utiliser une clé existante",
"detail": "ProxMenux recherche dans <code>/root/.ssh/</code> et <code>$HOME/.ssh/</code> les clés privées ed25519/RSA qu’il peut lire, puis les liste. L’opérateur en choisit une ou indique manuellement un chemin non standard."
},
{
"mode": "none",
"label": "Config par défaut SSH",
"detail": "Aucune clé personnalisée — Borg s'appuie sur la configuration par défaut de l'hôte SSH (généralement <code>~/.ssh/id_rsa</code> ou un agent SSH)."
}
],
"restrictTitle": "La ligne authorized_keys",
"restrictBody": "Pour chaque clé générée, la ligne <code>authorized_keys</code> écrite par ProxMenux sur le serveur limite la clé à cet appel borg-serve sur le chemin configuré du dépôt :",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "Le <code>command=</code> force chaque session SSH en utilisant cette clé pour exécuter seulement la commande borg-serve; <code>restrict</code> désactive le renvoi de port, le renvoi d'agent, le renvoi de X11 et l'allocation de PTY. La clé ne peut pas être utilisée pour ouvrir un shell interactif sur le serveur ou pour accéder à tout autre chemin de dépôt, même si le compte a des privilèges plus larges."
},
"savedTargets": {
"heading": "Objectifs enregistrés",
"intro": "Une destination enregistrée conserve la configuration du dépôt sous un nom lisible pour éviter de ressaisir les détails. Fichiers dans le répertoire d’état ProxMenux :",
"rows": [
{
"file": "borg-targets.txt",
"content": "Une ligne par destination : <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> la lit pour remplir le menu de sélection des destinations."
},
{
"file": "borg-pass-NAME.txt",
"content": "Phrase secrète de la destination nommée NAME ci-dessus (<code>chmod 600</code>). Présente uniquement si le chiffrement repokey a été choisi."
}
],
"outro": "Enregistrer la destination est facultatif. Refuser omet la configuration nommée, mais ne supprime pas une clé SSH générée. Si le chiffrement repokey est activé sans destination enregistrée, ProxMenux conserve tout de même la phrase secrète dans l’ancien fichier borg-pass.txt."
},
"encryption": {
"heading": "Cryptage",
"body": "Les dépôts sont initialisés avec un mode de chiffrement via <code>hb_borg_init_if_needed</code>: le <code>borg repo-create -e MODE</code> moderne quand disponible, ou le <code>borg init --encryption=MODE</code> hérité. ProxMenux expose deux modes : <code>repokey</code> (par défaut) et <code>none</code>. En mode <code>repokey</code> Borg stocke la clé de cryptage à l'intérieur du dépôt lui-même ; l'accès nécessite une phrase de passe, que ProxMenux invite pour deux fois avec vérification de concordance et enregistre dans <code>borg-pass-NAME.txt</code> pour une destination enregistrée, sinon dans l’ancien fichier décrit plus haut. Une boîte de dialogue de reconnaissance obligatoire s'affiche après l'enregistrement de la phrase de passe : la phrase de passe est la seule façon d'accéder aux archives chiffrées, et la perdre rend chaque archive du dépôt inrécupérable."
},
"runtimeEnv": {
"heading": "Environnement d'exécution",
"intro": "ProxMenux exporte les variables d'environnement suivantes avant d'invoquer <code>borg</code>. Ils configurent la connexion et déverrouillent le dépôt sans intégrer de secrets dans la ligne de commande.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Commande distante utilisée par Borg pour les dépôts SSH. Une clé sélectionnée ajoute les options d’identité ; un port non standard ajoute -p PORT. Sans clé personnalisée et avec le port par défaut, la variable reste non définie et Borg utilise la configuration SSH de l’hôte."
},
{
"var": "BORG_PASSPHRASE",
"value": "(Passphrase de borg-pass-NAME.txt)",
"purpose": "Débloque le repokey. Définir uniquement lorsque la cible utilise le chiffrement <code>repokey</code>. N'apparaît jamais dans la liste des arguments du processus."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Utilisé par <code>hb_borg_init_if_needed</code> lors de l'initialisation d'un dépôt qui n'existe pas encore. Ignoré par <code>borg create</code> sur les dépôts existants."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Supprime la confirmation interactive demandée par Borg lorsque l’URL du dépôt diffère de celle utilisée initialement, par exemple après avoir renommé un point de montage ou changé l’adresse du serveur SSH."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Supprime l'invite interactive Borg soulève la première fois qu'un dépôt non chiffré est accessible depuis un nouveau client."
}
]
},
"archiveFormat": {
"heading": "Nom et conservation des archives",
"intro": "Chaque sauvegarde crée une nouvelle archive dans le dépôt.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "Pour les tâches programmées, <code>run_scheduled_backup.sh</code> exécute <code>borg prune</code> contre le dépôt après chaque sauvegarde réussie avec les valeurs de conservation configurées sur le travail (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Les sauvegardes interactives ne se prunent pas."
},
"restoreAccess": {
"heading": "Récupération du côté restauration",
"body": "Le flux de restauration liste les archives avec <code>borg list REPO</code> et extrait celui sélectionné avec <code>borg extract REPO::ARCHIVE-NAME</code> dans un répertoire de mise en scène que <code>_rs_check_layout</code> alimente dans le pipeline de restauration standard. Pour la récupération manuelle à l'extérieur de ProxMenux les mêmes commandes fonctionnent; l'arborescence extraite est la mise en page standard à trois payload décrite dans <em>Comment ça marche</em>."
},
"references": {
"heading": "Références",
"intro": "Documentation officielle de Borg pour les composants utilisés par ProxMenux.",
"items": [
{
"label": "Documentation borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": "— point d'entrée principal couvrant les concepts, le déploiement, le démarrage rapide et chaque commande."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " — la commande utilisée par ProxMenux pour chaque sauvegarde, avec toutes les options prises en charge."
},
{
"label": "Chiffrement des dépôts",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": "— les modes de cryptage pris en charge par Borg, y compris la repokey que ProxMenux utilise par défaut."
},
{
"label": "borg serve et déploiement via SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — configuration d’un serveur Borg central accessible via SSH, avec la commande borg-serve et l’option restrict-to-path inscrites par ProxMenux dans authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly appliqué par ProxMenux à chaque tâche planifiée."
}
]
}
}
web/messages/fr/docs/backup-restore/destinations/index.json
+110
View File
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Destinations des sauvegardes — archive locale, Proxmox Backup Server et Borg | ProxMenux",
"description": "Trois moteurs de stockage reçoivent la même charge utile de sauvegarde ProxMenux : une archive locale .tar.zst sur tout système de fichiers accessible en écriture, une sauvegarde PBS dans un datastore Proxmox Backup Server ou une archive Borg dans un dépôt Borg local ou distant. Chaque moteur a ses propres caractéristiques de compression, de déduplication, de chiffrement et de réseau.",
"ogTitle": "Destinations de sauvegarde ProxMenux",
"ogDescription": "Local, Proxmox Backup Server et Borg — trois moteurs de stockage pour la même charge utile de sauvegarde d'hôte.",
"twitterTitle": "Destinations de sauvegarde ProxMenux | ProxMenux",
"twitterDescription": "Archives locales, moteurs Proxmox Backup Server et Borg pour les sauvegardes d'hôte."
},
"header": {
"title": "Destinations",
"description": "Trois backends de stockage pris en charge par ProxMenux Backup: archive locale, Proxmox Backup Server (recommandé) et Borg. Chacun reçoit la même archive à trois charges; ils diffèrent en format de stockage, déduplication, modèle de chiffrement et exigences du réseau.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Même charge utile, trois moteurs",
"body": "Chaque sauvegarde produit les mêmes trois charges utiles (rootfs, manifeste, applications). Ce qui change entre les destinations, c'est comment ces charges sont stockées et comment l'opérateur les récupère pour une restauration. Chaque moteur est implémenté comme une fonction séparée dans <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — mais les trois partagent la même étape de préparation temporaire (<code>hb_prepare_staging</code>) et le même chemin de code de restauration. Le choix de la destination n'affecte que l'écriture et la récupération ; il ne change pas ce qu'une restauration fait ou comment elle consomme l'archive."
},
"comparison": {
"heading": "Comparaison des caractéristiques",
"intro": "Le tableau suivant répertorie les différences concrètes entre les trois backends tels qu'ils se comportent dans ProxMenux aujourd'hui. Toutes les valeurs décrivent le comportement observé du backend lui-même, et non des recommandations éditoriales.",
"rows": [
{
"feature": "Format de stockage",
"local": "Un seul fichier <code>.tar.zst</code> (ou <code>.tar.gz</code> si <code>zstd</code> est absent).",
"pbs": "Sauvegarde PBS (blocs <code>.pxar</code> dans le datastore).",
"borg": "Archive Borg à l'intérieur d'un dépôt Borg (fichiers de segments)."
},
{
"feature": "Compression",
"local": "zstd (niveau par défaut) via <code>tar --zstd</code>. Repli sur gzip.",
"pbs": "Gérée par proxmox-backup-client. ProxMenux ne modifie pas les paramètres de compression.",
"borg": "Compression intégrée à Borg. ProxMenux appelle borg create sans modifier les paramètres de compression."
},
{
"feature": "Déduplication",
"local": "Aucune. Chaque sauvegarde est une archive indépendante complète.",
"pbs": "Déduplication complète de niveau chunk sur toutes les sauvegardes dans le datastore.",
"borg": "Déduplication complète au niveau des blocs entre toutes les archives du dépôt."
},
{
"feature": "Chiffrement au repos",
"local": "Aucun (dépend de la protection au niveau du système de fichiers).",
"pbs": "Chiffrement facultatif côté client avec un fichier de clé. Si activé, le blob de récupération est envoyé dans un groupe de sauvegarde distinct.",
"borg": "Chiffrement facultatif des repokey (clé stockée dans la repo, déverrouillée par une phrase de passe)."
},
{
"feature": "Rétention / purge",
"local": "Appliquée par tâche programmée via <code>KEEP_LAST</code>. Les anciennes archives sont supprimées avec leurs fichiers annexes et journaux d’exécution. Les sauvegardes interactives ne font pas de purge.",
"pbs": "Appliquée par tâche programmée via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge.",
"borg": "Appliquée par tâche programmée via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge."
},
{
"feature": "Réseau",
"local": "Aucune. Écrit à un point de montage local (généralement un disque interne ou un lecteur USB).",
"pbs": "TCP vers le serveur PBS (port par défaut 8007). Nécessite des identifiants PBS + empreinte du certificat.",
"borg": "Chemin du système de fichiers local ou tunnel SSH vers un hôte Borg distant."
},
{
"feature": "Dépendances",
"local": "<code>tar</code>, <code>zstd</code> (présent sur Proxmox par défaut).",
"pbs": "Paquet <code>proxmox-backup-client</code> (fourni avec Proxmox VE 8+).",
"borg": "<code>borg</code> binaire. Auto-provisionné par ProxMenux à partir du paquet Moniteur AppImage quand il manque."
},
{
"feature": "Accès pour restaurer",
"local": "Tout hôte avec tar+zstd peut extraire l'archive. Pas de PBS/Borg nécessaire.",
"pbs": "Nécessite <code>proxmox-backup-client</code>, les identifiants PBS et le fichier de clé (si la sauvegarde est chiffrée).",
"borg": "Nécessite <code>borg</code> + le chemin du dépôt + la phrase de passe (si chiffrée)."
}
],
"captionCode": "feature",
"captionLocal": "Locale",
"captionPbs": "Proxmox Backup Server (recommandé)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "La disposition des archives ne change pas avec la destination",
"body": "A l'intérieur de l'une des trois destinations, la même disposition <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> décrite dans <em>Comment ça marche</em> est présente. Un <code>.tar.zst</code> extrait d'une archive locale, un <code>.pxar</code> restauré de PBS et une archive Borg extraite de <code>borg extract</code> donnent tous un arbre de répertoire identique. Le chemin du code de restauration (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
},
"extractStandalone": {
"heading": "Extraire une sauvegarde à l'extérieur de ProxMenux",
"intro": "N'importe lequel des trois formats d'archive peut être lu avec des outils standard sans ProxMenux installé sur l'hôte de lecture. Les commandes ci-dessous produisent le même arbre de répertoire qu'une restauration consomme en interne.",
"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": "# Depuis une archive Borg (nécessite borg et la phrase de passe des dépôts chiffrés) :\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Sur un dépôt distant accessible par SSH :\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "L'arbre extrait peut ensuite être inspecté manuellement ou alimenté à une restauration manuelle. Consultez les pages de destination individuelles pour connaître le processus de récupération exact que ProxMenux utilise sous le capot."
},
"whereNext": {
"heading": "Détails par destination",
"intro": "Chaque destination a sa propre page couvrant le flux de configuration, le format sur disque et la commande de récupération utilisée par la restauration.",
"items": [
{
"label": "Archives locales",
"href": "/docs/backup-restore/destinations/local",
"tail": "— pré-configuration d'une cible locale, montage d'un lecteur USB, vérification de sécurité contre l'écriture de l'archive en soi, le sidecar JSON qui permet au moniteur d'identifier le fichier."
},
{
"label": "Proxmox Backup Server (recommandé)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — choix du datastore, identifiants et empreinte du certificat, cycle de vie du fichier de clé, phrase de passe de récupération et envoi du blob de récupération à PBS pour restaurer après une nouvelle installation."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — dépôts locaux ou accessibles par SSH, provenance du binaire Borg (système / cache / paquet AppImage de Monitor / téléchargement GitHub), initialisation du dépôt, gestion des phrases de passe et configuration des clés SSH pour les dépôts distants."
}
]
}
}
web/messages/fr/docs/backup-restore/destinations/local.json
+75
View File
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Destination d'archive locale — tar.zst sur un système de fichiers ou un lecteur USB ProxMenux",
"description": "La destination de sauvegarde locale écrit une seule archive .tar.zst dans n'importe quel répertoire accessible en écriture : un disque interne, un point de montage Proxmox, un partage NFS ou un lecteur USB. Cette page décrit le processus de configuration, la détection USB et la logique de montage, le contrôle de sécurité contre l'écriture de l'archive dans un chemin en cours de sauvegarde, et le sidecar JSON qui identifie le fichier.",
"ogTitle": "Sauvegarde ProxMenux — Destination des archives locales",
"ogDescription": "Comment ProxMenux écrit des sauvegardes locales comme archives .tar.zst et comment configurer le répertoire de destination ou le lecteur USB.",
"twitterTitle": "Destination de sauvegarde locale ProxMenux",
"twitterDescription": "Comment ProxMenux écrit des sauvegardes locales comme des archives .tar.zst sur un système de fichiers ou un lecteur USB."
},
"header": {
"title": "Archives locales",
"description": "La destination locale écrit une seule archive tar compressée dans n'importe quel répertoire accessible en écriture sur l'hôte : un disque interne, un montage NFS ou SMB ou un lecteur USB.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Un fichier autonome",
"body": "Une sauvegarde locale produit un seul fichier <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (ou <code>.tar.gz</code> lorsque <code>zstd</code> est absent). Le fichier contient l'arborescence entière de l'archive — <code>manifest.json</code>, <code>metadata/</code> et <code>rootfs/</code> — et peut être restauré sur n'importe quel hôte Proxmox avec le flux de restauration ProxMenux ou extrait manuellement avec <code>tar --zstd -xf</code> sur n'importe quel système Linux. Pas de serveur, pas d’initialisation de dépôt, pas de dépendance externe. C'est la destination avec le chemin de récupération le plus court lorsque ni PBS ni Borg n'est disponible."
},
"targetConfig": {
"heading": "Configuration du répertoire cible",
"intro": "La destination locale est un <strong>unique répertoire cible enregistré durablement</strong> — pas une liste. ProxMenux stocke le choix de l'opérateur chez <code>/usr/local/share/proxmenux/local-target.conf</code> et le lit sur chaque sauvegarde. Lorsqu'aucune cible n'a été configurée, le <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> par défaut est utilisé (le même répertoire que Proxmox utilise pour ses propres sorties <code>vzdump</code>). La cible est configurée à partir de <em>Configurer les destinations de sauvegarde → Destinations locales</em>:",
"options": [
"<strong>Utilisez par défaut (<code>/var/lib/vz/dump</code>).</strong> Le stockage local Proxmox. Présent sur chaque install Proxmox ; l'archive se trouve à côté des sorties vzdump et est captée automatiquement par l'onglet Sauvegardes du moniteur.",
"<strong>Entrez un chemin personnalisé.</strong> Tout chemin absolu du système de fichiers peut être utilisé : un montage NFS, un partage SMB monté via <code>fstab</code>, un jeu de données ZFS dédié, un deuxième disque interne. ProxMenux valide que le chemin existe et est un répertoire avant de l’enregistrer.",
"<strong>Choisissez un lecteur USB.</strong> Ouvre le sous-menu USB (ci-dessous), qui détecte les appareils amovibles et propose de monter ou de formater un périphérique."
]
},
"usbFlow": {
"heading": "Détection et montage du lecteur USB",
"intro": "Le sous-menu USB énumère les partitions sur les périphériques amovibles signalées par <code>lsblk</code>. Chaque partition est présentée avec sa taille, l'étiquette du système de fichiers et l'état actuel. L'état détermine l'action ProxMenux offre.",
"statesTitle": "Les trois états de l'appareil",
"stateRows": [
{
"state": "monté",
"shown": "Taille · étiquette · [fstype] · → /mount/point",
"action": "La partition est déjà montée quelque part. La sélection enregistre le point de montage actuel en tant que cible locale. Aucun montage n'est effectué."
},
{
"state": "non monté",
"shown": "Taille · étiquette · [fstype] · (non monté — sera monté)",
"action": "Un système de fichiers est présent mais n'est pas monté. Lors de la confirmation, ProxMenux exécute <code>hb_mount_usb_partition</code> : crée <code>/mnt/backup-LABEL</code> (ou un chemin basé sur UUID s'il n'y a pas d'étiquette), monte la partition et persiste le point de montage comme cible locale."
},
{
"state": "vide",
"shown": "Taille · disque USB brut — aucun système de fichiers (sera FORMATÉ)",
"action": "Le périphérique n’a pas de système de fichiers. Cette opération destructive est protégée par deux confirmations. Une boîte de dialogue Oui/Non avertit d’abord que le disque sera effacé. Ensuite, un champ exige de <strong>saisir le chemin exact du périphérique</strong> (par exemple <code>/dev/sdb</code>) avant que ProxMenux crée une nouvelle table GPT avec une partition ext4 et la monte."
}
],
"notMountedFallback": "Lorsqu'aucun périphérique USB n'est détecté, le sous-menu revient à une boîte d'entrée simple. L'opérateur peut entrer un chemin de point de montage arbitraire ; si le chemin n'est pas un point de montage enregistré, une boîte de dialogue de confirmation avertit avant de procéder."
},
"safetyCheck": {
"heading": "Contrôle de sécurité — destination dans un chemin de sauvegarde",
"body": "Avant d'écrire l'archive, <code>_bk_local</code> vérifie que le répertoire de destination n'est <strong>pas</strong> un sous-chemin d'un répertoire en cours de sauvegarde. Une erreur courante consisterait à ajouter <code>/root</code> au profil et à choisir <code>/root/backups</code> comme destination — l'archive s'inclurait alors elle-même, produisant soit une archive corrompue, soit s'agrandissant sans limite jusqu'à ce que le disque se remplisse. La vérification résout les deux chemins avec <code>readlink -m</code>, les compare et, en cas de conflit, abandonne la sauvegarde avec une boîte de dialogue qui nomme le chemin en conflit et répertorie trois façons de le résoudre : choisissez une destination en dehors du chemin en conflit, supprimez l'entrée personnalisée qui contient la destination ou utilisez le mode personnalisé pour décocher le chemin en conflit pour cette exécution."
},
"archiveFormat": {
"heading": "Format d'archives et compression",
"intro": "Le nom du fichier contient le nom d’hôte source et l’horodatage de la sauvegarde, afin de permettre un tri chronologique dans un répertoire contenant plusieurs archives et d’identifier chaque fichier.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Compression",
"compressionBody": "Le chemin primaire utilise <code>tar --zstd -cf</code> — un pipeline à commande unique qui compresse au niveau par défaut de zstd. Lorsque <code>zstd</code> n'est pas présent sur la source (rare sur Proxmox mais possible sur des installations minimales), ProxMenux revient à <code>gzip</code>. Dans le chemin de repli, si <code>pv</code> est disponible, une barre de progression est ajoutée au pipeline afin que l'opérateur voit la taille des archives croître en temps réel; sans <code>pv</code>, <code>tar -czf</code> est utilisé en silence.",
"sourceTitle": "Ce qui va dans l'archive",
"sourceBody": "La commande tar est appelée avec <code>-C \"$staging_root\" .</code>, ce qui archive <strong>toute la racine du répertoire temporaire</strong> : <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code>. Les trois blocs de données se trouvent côte à côte à la racine de l’archive tar. L’extraction produit exactement l’arborescence utilisée par le code de restauration."
},
"sidecar": {
"heading": "Le sidecar JSON",
"intro": "Chaque sauvegarde locale réussie produit un fichier compagnon : <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, écrit à côté de l'archive par <code>hb_write_archive_sidecar</code>. Ce petit fichier JSON permet au ProxMenux Monitor d'identifier l'archive comme une sauvegarde d'hôte ProxMenux même s'il est déplacé, rebaptisé ou archivé ailleurs.",
"contentTitle": "Contenu du sidecar",
"contentBody": "Le sidecar stocke la version du schéma, que la sauvegarde soit issue d'une opération interactive ou d'un travail programmé (<code>kind</code>), l'ID de travail pour les opérations programmées, le mode de profil utilisé (<code>default</code> ou <code>custom</code>), le nom d'hôte source, le nom de base d'archive original, un horodatage de création ISO-8601 et la taille des archives en octets.",
"whyBody": "L'onglet Sauvegardes du moniteur scanne les répertoires locaux configurés pour les sidecars <code>*.proxmenux.json</code> — pas pour les fichiers <code>*.tar.zst</code> — parce qu'un <code>.tar.zst</code> sans sidecar pourrait ne pas être une sauvegarde ProxMenux du tout. Le scan est rapide (les fichiers JSON sont minuscules) et l'appariement est stable à travers les renoms de l'archive aussi longtemps que le sidecar est renommé pour correspondre."
},
"restoreAccess": {
"heading": "Restauration à partir d'une archive locale",
"body": "Le flux de restauration ProxMenux découvre les archives locales en scannant la cible locale configurée pour les sidecars et en les affichant dans la liste des archives. La sélection d’une archive déclenche <code>_rs_check_layout</code>, qui extrait le tarball dans un répertoire de préparation temporaire et confirme la mise en page à trois payload avant de procéder. Pour l'extraction manuelle à l'extérieur de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> donne le même arbre que le code de restauration consommé."
}
}
web/messages/fr/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -0,0 +1,113 @@
{
"meta": {
"title": "Proxmox Backup Server destination — dépôt, chiffrement, récupération ProxMenux",
"description": "La destination PBS enregistre les sauvegardes d’hôte ProxMenux au format PBS. Cette page décrit la détection des dépôts dans /etc/pve/storage.cfg, la configuration manuelle, l’envoi des archives .pxar, le chiffrement côté client avec un fichier clé et sa copie de secours facultative protégée par une phrase secrète, ainsi que sa récupération depuis plusieurs sources sur un hôte réinstallé.",
"ogTitle": "ProxMenux Sauvegarde — Proxmox Backup Server destination",
"ogDescription": "Comment ProxMenux écrit des sauvegardes d'hôte à Proxmox Backup Server avec le cryptage de fichier clé côté client et la récupération séquestre.",
"twitterTitle": "PBS destination de sauvegarde ProxMenux",
"twitterDescription": "Destination Proxmox Backup Server avec chiffrement par fichier clé et copie de récupération protégée par une phrase secrète."
},
"header": {
"title": "Proxmox Backup Server",
"description": "La destination PBS envoie tout le répertoire de préparation sous forme d’une seule sauvegarde .pxar vers un datastore Proxmox Backup Server. Le chiffrement côté client avec un fichier clé est facultatif, tout comme l’envoi, à côté de chaque sauvegarde, d’une copie de récupération de la clé protégée par une phrase secrète.",
"section": "Sauvegarde et restauration"
},
"recommendedBadge": "Destination recommandée",
"aboutPbs": {
"heading": "Qu'est-ce que Proxmox Backup Server",
"body": "Proxmox Backup Server (PBS) est le propre produit serveur de sauvegarde de Proxmox, développé et entretenu par la même équipe que les auteurs Proxmox VE. Il s'agit d'un serveur de sauvegarde dédié conçu pour recevoir des sauvegardes des hôtes Proxmox VE (VMs, LXCs et — via <code>proxmox-backup-client</code> — répertoires d'hôtes arbitraires) avec déduplication basée sur le chunk, chiffrement côté client et politiques de rétention appliquées côté serveur. ProxMenux utilise le PBS comme l'une des trois destinations pour les sauvegardes d'hôtes; chaque mécanisme spécifique au PBS décrit sur cette page (groupes de sauvegarde, archives <code>.pxar</code>, <code>--backup-id</code>, cryptage de fichiers clés) est le comportement standard du PBS."
},
"intro": {
"title": "Une sauvegarde par exécution, déduplication par blocs",
"body": "Une sauvegarde PBS crée une seule entrée dans le datastore, sous l’identifiant <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Les données sont une archive <code>.pxar</code> contenant la même structure en trois blocs que celle décrite dans <em>Fonctionnement</em>. PBS déduplique les blocs entre toutes les sauvegardes du datastore : les suivantes ne transfèrent et ne stockent que les blocs modifiés de cet hôte. Pour les tâches planifiées, ProxMenux applique lui-même la rétention : après chaque exécution réussie, <code>run_scheduled_backup.sh</code> lance <code>proxmox-backup-client prune</code> avec <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> et les valeurs configurées pour la tâche."
},
"repoSelection": {
"heading": "Sélection du dépôt",
"intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> et <code>HB_PBS_FINGERPRINT</code> pour l'exécution.",
"sourceRows": [
{
"source": "storage.cfg de Proxmox (détection automatique)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Toute stanza <code>pbs:</code> dans la configuration de stockage propre de Proxmox est captée automatiquement. Serveur, datastore, nom d'utilisateur et empreinte digitale viennent de la stanza. Le mot de passe est lu dans le propre répertoire d'identification de Proxmox. Aucune réentrée nécessaire du côté ProxMenux — le dépôt est disponible dès qu'il est configuré dans Proxmox."
},
{
"source": "Configuration manuelle ProxMenux",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Ajouté de <em>Configurer les destinations de sauvegarde → PBS destinations → Ajouter PBS</em>. Prompts pour un nom, nom d'utilisateur (<code>root@pam</code> ou <code>user@pbs!token</code>), hôte ou IP, datastore et mot de passe. Le mot de passe reprend sur l'entrée vide — une sauvegarde vide persisterait silencieusement et chaque sauvegarde ultérieure échouerait avec une erreur d'authentification opaque. Ce chemin est utilisé lorsque la cible PBS n'est pas enregistrée comme stockage Proxmox."
}
],
"menuTitle": "Menu de sélection",
"menuBody": "Les deux sources sont affichées dans un menu unique, chaque ligne marquée avec son origine (<code>[proxmox]</code> ou <code>[manual]</code>). Les entrées dont le mot de passe n'a pas pu être résolu sont marquées d'un avertissement <code>⚠ no password</code> – la sélection d'une entrée déclenche une réentrée de mot de passe avant le début de la sauvegarde. L'empreinte digitale est transmise à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>; en cas d'absence, le client demande à l'opérateur d'accepter le certificat serveur de manière interactive lors de la première sauvegarde."
},
"backupCommand": {
"heading": "La commande de sauvegarde",
"intro": "L’envoi se fait en un seul appel à <code>proxmox-backup-client backup</code>. ProxMenux utilise <code>env</code> pour transmettre au client le mot de passe, le mot de passe de chiffrement et l’empreinte sous forme de variables d’environnement.",
"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": "Nom de l'ID de sauvegarde",
"backupIdBody": "L’identifiant de sauvegarde par défaut est <code>hostcfg-HOSTNAME</code>. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de <code>[A-Za-z0-9_-]</code> et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un <em>groupe</em>. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
"pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
"pxarBody": "La source <code>.pxar</code> est la totalité du <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code> ensemble. Les versions antérieures ont passé le <code>$staging_root/rootfs</code> comme source; cela a laissé le <code>metadata/</code> hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-<code>_rs_check_layout</code> de 3, qui enveloppe un arbre plat <code>etc/var/root/usr</code> dans une hiérarchie <code>rootfs/</code>."
},
"encryption": {
"heading": "Chiffrement côté client",
"glossaryHint": "Cette section emploie les termes <em>fichier clé</em>, <em>phrase secrète</em> et <em>enveloppe de récupération</em>. Le <glosarioLink>glossaire</glosarioLink> résume leurs différences en une phrase par terme.",
"intro": "Le chiffrement PBS côté client avec un fichier clé chiffre les blocs sur l’hôte source avant leur envoi. Dans ProxMenux, il est facultatif. Une fois activé, l’opérateur choisit explicitement, par oui ou non lors de la configuration, s’il faut aussi déposer sur PBS une copie de récupération du fichier clé protégée par une phrase secrète ; ce choix reste modifiable dans le moniteur. Le fichier clé se trouve toujours au chemin canonique <code>/usr/local/share/proxmenux/pbs-key.conf</code> et est réutilisé sans nouvelle demande pour chaque sauvegarde chiffrée suivante.",
"keyfileTitle": "Configuration du fichier de clés",
"keyfileBody": "Le dialogue de chiffrement apparaît lors de la première sauvegarde chiffrée de l’hôte. Il demande d’abord s’il faut chiffrer la sauvegarde : <em>Non</em> poursuit sans chiffrement, <em>Oui</em> passe à la deuxième étape. Celle-ci dépend de la présence d’un fichier clé dans <code>/usr/local/share/proxmenux/pbs-key.conf</code>. S’il existe, il est réutilisé sans nouvelle demande et la sauvegarde continue ; les suivantes ne reposent pas la question. Sinon, un menu propose deux options. <em>Générer un nouveau fichier clé</em> exécute <code>proxmox-backup-client key create --kdf none</code>. <em>Utiliser un fichier clé existant</em> détecte automatiquement une clé gérée par PVE : si le dépôt PBS choisi est enregistré dans Proxmox avec une clé de chiffrement dans <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ce fichier est copié sans demande au chemin canonique ProxMenux. Si aucune clé PVE ne correspond au dépôt, le dialogue demande le chemin absolu où l’opérateur a déjà placé le fichier clé sur cet hôte. Dans les deux cas, le fichier est installé au chemin canonique avec <code>chmod 600</code>.",
"modesTitle": "Fichier clé par hôte ou partagé",
"modesIntro": "Les deux modes sont pris en charge, sans en imposer un : l’opérateur choisit selon l’organisation de son parc.",
"modesPerHostTitle": "Fichier de clés par hôte (par défaut)",
"modesPerHostBody": "Chaque hôte génère son propre fichier de clé la première fois qu'il permet le cryptage PBS. L'isolement est maximal : compromettre le fichier clé d'un hôte n'expose les sauvegardes d'aucun autre. Recommandé pour les flottes de production et pour les environnements où les hôtes ont différents propriétaires ou limites de conformité.",
"modesSharedTitle": "Fichier de clés partagé (import sur chaque hôte)",
"modesSharedBody": "Un fichier clé principal généré une fois et installé sur chaque hôte via l’option <em>Utiliser un fichier clé existant</em>. La gestion est plus simple: un seul secret à sauvegarder, et tout hôte peut déchiffrer les archives de n'importe quel autre (utile pour la consolidation, les exercices de restauration cross-host ou la vérification centralisée de sauvegarde). Le compromis est qu'une fuite du fichier de clés partagé expose chaque hôte à la fois. Recommandé pour les labos et les flottes où tous les hôtes ont le même propriétaire et la même limite de confiance.",
"recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide",
"recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, <em>Déposer la clé sur PBS ?</em>, avec deux réponses. <strong>Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui.</strong> Le choix par défaut est <em>Non, conserver uniquement en local</em> : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton <em>Télécharger le fichier clé</em> du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir <em>Oui, envoyer</em> demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant <code>pbs-key.recovery.enc</code>. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
"blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
"blobUploadBody1": "Lorsque le mode de dépôt est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
"envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?",
"envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.",
"blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté",
"blobUploadConstraintBody": "Un seul appel à <code>proxmox-backup-client backup</code> chiffre toutes ses archives avec le même fichier clé, ou aucune : il ne permet pas de mélanger les deux. La sauvegarde de l’hôte doit être chiffrée avec sa clé, mais l’enveloppe de récupération ne peut pas être envoyée dans le même appel : elle serait alors chiffrée avec le fichier clé qu’elle contient. Sur un hôte réinstallé, il serait impossible de l’ouvrir, puisqu’il faudrait la clé pour déchiffrer cette même clé. Les deux éléments sont donc envoyés indépendamment et apparaissent dans deux groupes. Le client PBS chiffre la sauvegarde de l’hôte avec le fichier clé ; ProxMenux chiffre l’enveloppe avec la phrase secrète avant son envoi. Deux couches de chiffrement distinctes protègent deux éléments différents.",
"blobUploadImageAlt": "PBS UI montrant les groupes de sauvegarde hostcfg-HOSTNAME et hostcfg-HOSTNAME-keyrecovery adjacents à la liste datastore.",
"blobUploadImageCaption": "PBS UI — les groupes de sauvegarde appariés. Le groupe principal détient les sauvegardes de l'hôte; le groupe -keyrecovery détient le fichier de clés enveloppé de la phrase de passe.",
"recoverTitle": "Récupération sur un hôte frais",
"recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe <code>-keyrecovery</code> existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie <code>wrong key — manifest's key XX does not match provided key YY</code>. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
"monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
"monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : <em>Télécharger</em> exporte le fichier actuel vers le navigateur ; <em>Envoyer</em> remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; <em>Supprimer</em> retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
},
"restoreAccess": {
"heading": "Récupération du côté restauration",
"body": "La restauration repère les sauvegardes d’hôte ProxMenux sur PBS en listant les groupes du dépôt configuré puis en filtrant leur identifiant. L’onglet Sauvegardes du moniteur affiche la même liste. Choisir une sauvegarde lance <code>proxmox-backup-client restore</code> avec le même dépôt, mot de passe et empreinte, ainsi que <code>--keyfile</code> si elle est chiffrée. L’archive <code>.pxar</code> est extraite dans un répertoire de préparation que <code>_rs_check_layout</code> transmet au processus de restauration standard. Hors de ProxMenux, la même commande extrait l’archive à l’emplacement souhaité pour examiner l’arborescence ou effectuer une restauration manuelle."
},
"references": {
"heading": "Références",
"intro": "Documentation officielle de Proxmox Backup Server pour les composants utilisés par ProxMenux.",
"items": [
{
"label": "Documentation Proxmox Backup Server",
"href": "https://pbs.proxmox.com/docs/",
"tail": "— point d'entrée principal couvrant l'installation, l'administration, le stockage, les utilisateurs et les rôles."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — l’outil en ligne de commande appelé par ProxMenux pour chaque sauvegarde et restauration. Décrit les identifiants et types de sauvegarde, les archives, la syntaxe des dépôts et les variables d’environnement."
},
{
"label": "Chiffrement côté client",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — création du fichier clé, modes --kdf et modèle de chiffrement que ProxMenux complète par une copie de récupération protégée par une phrase secrète."
},
{
"label": "Gestion des Datastore",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": " — création et gestion des datastores qui reçoivent les sauvegardes d’hôte, avec la structure du stockage des blocs et les permissions."
},
{
"label": "Élagage des sauvegardes et récupération d’espace",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly que ProxMenux applique par tâche planifiée, et la récupération des blocs inutilisés par PBS après l’élagage."
}
]
}
}
web/messages/fr/docs/backup-restore/glossary.json
+230
View File
@@ -0,0 +1,230 @@
{
"meta": {
"title": "Glossaire — Sauvegarde et restauration ProxMenux",
"description": "Glossaire des termes et définitions de la pile de sauvegarde et de restauration ProxMenux: chiffrement, fichier de clés, mots de passe, enveloppe de récupération, PBS, morceaux, rootfs, manifeste, hydratation coureur et cross-kernel.",
"ogTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
"ogDescription": "Définitions claires des termes utilisés dans la documentation de sauvegarde et de restauration ProxMenux.",
"twitterTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
"twitterDescription": "Phrase de passe, fichier clé, enveloppe de récupération, rootfs, manifeste, PBS, morceaux — tous définis en un seul endroit."
},
"header": {
"title": "Glossaire",
"description": "Termes utilisés dans la documentation de sauvegarde et de restauration, avec leur définition.",
"section": "Sauvegarde et restauration"
},
"intro": {
"body": "Les termes sont regroupés par thème. Chaque entrée donne le terme et une courte définition."
},
"groups": [
{
"title": "Chiffrement et récupération des clés",
"intro": "Vocabulaire pour le bloc de chiffrement PBS. Il implique deux secrets distincts: un fichier de clés binaires et une phrase de passe écrite.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Phrase secrète de récupération",
"def": "Mot de passe texte choisi par l'utilisateur pour protéger l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>. Il est demandé deux fois avec une vérification de correspondance, et n'est utilisé que pour chiffrer l'enveloppe et la déchiffrer si le fichier clé a besoin d'être récupéré. <strong>Ce n'est pas la phrase de passe qui déverrouille le fichier clé lui-même</strong>, et il n'est jamais envoyé à PBS. Pendant une sauvegarde normale, il ne quitte jamais l'hôte."
},
{
"id": "clave-cifrado",
"term": "Fichier-clé (clé de chiffrement)",
"def": "Fichier de clé utilisé par proxmox-backup-client pour chiffrer les <a href=\"#chunk\">blocs</a> avant leur envoi à PBS. Sans la clé correspondante, les données chiffrées sont illisibles. ProxMenux le stocke dans <code>/usr/local/share/proxmenux/pbs-key.conf</code> avec le mode <code>600</code>. Protégez-le : l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> permet de le récupérer en cas de perte."
},
{
"id": "contrasena-keyfile",
"term": "Phrase de passe du fichier clé (phrase de passe KDF)",
"def": "Phrase de passe optionnelle que le fichier clé lui-même peut porter, distincte de la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a>. Il n'existe que lorsque le fichier clé a été créé avec <code>--kdf scrypt</code> (généralement un fichier clé importé). Sans cela, le fichier clé ne peut pas être déverrouillé pour utilisation. ProxMenux le maintient sous forme chiffrée sur l'hôte afin que les sauvegardes programmées puissent fonctionner sans une demande interactive."
},
{
"id": "sobre-recuperacion",
"term": "Enveloppe de récupération",
"def": "Le fichier <a href=\"#clave-cifrado\">keyfile</a> enveloppé dans une couche supplémentaire: il est crypté avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> utilisant <a href=\"#aes-256-cbc\">AES-256-CBC</a> et <a href=\"#pbkdf2\">PBKDF2</a> avant de quitter l'hôte. C'est ce qui est téléchargé sur PBS en tant que groupe <code>-keyrecovery</code>. Sans la phrase de passe, l'enveloppe est opaque : le téléchargement de PBS ne révèle pas le fichier de clés."
},
{
"id": "cifrado-cliente",
"term": "Chiffrement côté client",
"def": "Modèle de chiffrement dans lequel les données sont chiffrées sur l'hôte source avant d'être téléchargées. PBS ne reçoit et stocke que du texte codé; même un administrateur PBS avec accès datastore ne peut pas le lire sans le fichier clé. ProxMenux s'appuie sur ce modèle et ajoute l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> sur le dessus."
},
{
"id": "kdf-none",
"term": "--kdf none",
"def": "Option de <code>proxmox-backup-client key create</code> qui produit un fichier de clés sans phrase de passe jointe. Le fichier de clés peut être utilisé directement sans une prompte, ce qui est essentiel pour les travaux programmés qui ne sont pas surveillés. C'est ce que ProxMenux utilise par défaut lors de la génération d'un nouveau fichier clé."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"def": "Option pour <code>proxmox-backup-client key create</code> qui produit un fichier clé protégé par une <a href=\"#contrasena-keyfile\">phrase de passe du fichier de clé</a>. Chaque utilisation du fichier clé nécessite de le déverrouiller avec cette phrase de passe. ProxMenux accepte ce style de keyfile sur l'importation et stocke la phrase de passe cryptée afin que les sauvegardes programmées puissent toujours fonctionner sans surveillance."
},
{
"id": "aes-256-cbc",
"term": "AES-256-CBC",
"def": "Chiffrement symétrique standard. ProxMenux l’utilise via <code>openssl enc -aes-256-cbc</code> pour protéger le <a href=\"#clave-cifrado\">fichier de clé</a> avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> et produire l’<a href=\"#sobre-recuperacion\">enveloppe</a>."
},
{
"id": "pbkdf2",
"term": "PBKDF2",
"def": "Fonction cryptographique qui transforme une phrase de passe de type humain en une clé binaire adaptée au chiffrement. Il ralentit les tentatives de force brute en appliquant de nombreuses itérations. ProxMenux l'utilise avec des itérations 600 000 et un sel aléatoire lors du chiffrement de l'enveloppe de récupération."
}
]
},
{
"title": "Structure de sauvegarde",
"intro": "Termes décrivant ce qui vit dans une sauvegarde, quelle que soit la destination.",
"entries": [
{
"id": "rootfs",
"term": "rootfs / système de fichiers racine",
"def": "Copie des fichiers de l’hôte source réalisée par <code>rsync</code> selon le <a href=\"#perfil-defecto\">profil par défaut</a> et les <a href=\"#rutas-personalizadas\">chemins personnalisés</a>. Ce n’est pas une image de disque complet : seuls sont copiés les chemins contenant la configuration ou l’état que Proxmox ne peut pas recréer seul."
},
{
"id": "manifiesto",
"term": "Manifeste (manifest.json)",
"def": "Document structuré JSON décrivant l'hôte source au moment de la sauvegarde : matériel, stockage, noyau, composants installés par ProxMenux et inventaire des VM et des LXC. Il est produit par six collecteurs indépendants. Le flux de restauration l'utilise pour comparer la source et la cible."
},
{
"id": "staging",
"term": "Répertoire de préparation",
"def": "Répertoire temporaire où ProxMenux assemble les trois blocs (rootfs, métadonnées et manifeste) avant de les emballer et de les télécharger vers la destination. Il est supprimé automatiquement lorsque la sauvegarde se termine, même sur avorter."
},
{
"id": "perfil-defecto",
"term": "Profil par défaut",
"def": "Ensemble sélectionné de chemins copiés par défaut dans chaque sauvegarde : configuration PVE, réseau, SSH, noyau, apt, outils ProxMenux et plus encore. Défini dans le code et documenté sur la page <em>Comment ça marche</em>."
},
{
"id": "rutas-personalizadas",
"term": "Chemins personnalisés",
"def": "Les chemins supplémentaires que l'utilisateur ajoute au dessus du <a href=\"#perfil-defecto\">profil par défaut</a>. Soit persistante (conservée en <code>backup-extra-paths.txt</code>) soit per-run (en mode personnalisé)."
}
]
},
{
"title": "Destinations et stockage",
"intro": "Termes liés à l'emplacement de la sauvegarde — serveur PBS, archive locale ou dépôt Borg — et comment PBS organise les données.",
"entries": [
{
"id": "repositorio-pbs",
"term": "Dépôt PBS",
"def": "Combinaison de Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + utilisateur qui reçoit la sauvegarde. Identifié par la chaîne <code>user@realm@host:datastore</code>. Un seul serveur PBS peut héberger plusieurs dépôts."
},
{
"id": "datastore",
"term": "Banque de données",
"def": "Espace de stockage précis dans un serveur PBS contenant les sauvegardes et leurs blocs. Chaque datastore repose sur un système de fichiers du serveur PBS avec ses propres permissions et politiques."
},
{
"id": "chunk",
"term": "Bloc (chunk) / déduplication par blocs",
"def": "PBS divise chaque sauvegarde en morceaux de taille variable, identifie chaque morceau par son hachage et ne stocke chaque morceau qu'une seule fois, même s'il apparaît dans de nombreuses sauvegardes différentes. Cela signifie que les sauvegardes successives d'un même hôte — ou d'un hôte similaire — prennent très peu d'espace supplémentaire."
},
{
"id": "fingerprint",
"term": "Empreinte",
"def": "Empreinte cryptographique du certificat du serveur PBS TLS Il permet au client de vérifier qu'il parle au serveur prévu sans compter sur une autorité de certification publique. ProxMenux le transmet à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>."
},
{
"id": "grupo-copia",
"term": "Groupe de sauvegarde",
"def": "Conteneur logique à l'intérieur de PBS sous lequel les sauvegardes successives du même actif s'accumulent. Chaque nouvelle sauvegarde partage la déduplication avec les précédentes dans le même groupe. ProxMenux utilise deux groupes par hôte lorsque le chiffrement est activé : un pour la sauvegarde de l'hôte et un avec un suffixe <code>-keyrecovery</code> pour l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>."
},
{
"id": "backup-id",
"term": "ID de sauvegarde",
"def": "Nom du groupe <a href=\"#grupo-copia\">backup</a>. ProxMenux par défaut sur <code>hostcfg-HOSTNAME</code> et permet à l'utilisateur de l'éditer avant le téléchargement; les caractères non pris en charge sont supprimés automatiquement."
},
{
"id": "pxar",
"term": ".pxar",
"def": "Format d'archive native PBS pour les répertoires. Il se comporte comme un tar optimisé pour la déduplication des morceaux : au lieu de stocker un fichier opaque, PBS brise son contenu en morceaux réutilisables."
}
]
},
{
"title": "Exécution et calendrier",
"intro": "Termes utilisés par le système ProxMenux emploi programmé.",
"entries": [
{
"id": "runner",
"term": "Processus d'exécution",
"def": "Le script <code>run_scheduled_backup.sh</code> qui exécute une sauvegarde programmée. Il lit la configuration du travail, lance le moteur correspondant (Local, PBS ou Borg), applique la conservation sur le succès et envoie les notifications configurées."
},
{
"id": "trabajo-programado",
"term": "Tâche planifiée",
"def": "Configuration permanente d'une sauvegarde récurrente. Tient destination, identifiants, chiffrement, calendrier et conservation. Vit à <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
},
{
"id": "modo-adjunto",
"term": "Mode rattaché",
"def": "Tâche sans timer propre. Un hook job-end de PVE <code>vzdump</code> la déclenche après les sauvegardes des invités si le stockage correspond. La tâche parent fournit destination et conservation initiale, mais le hook compare le stockage, pas l’ID parent. Une autre tâche sur ce stockage peut aussi la déclencher. Uniquement Local et PBS."
},
{
"id": "timer-systemd",
"term": "Systemd minuterie",
"def": "Mécanisme standard systemd qui déclenche une commande sur un calendrier. ProxMenux crée une minuterie par <em>indépendant</em> emploi programmé; <a href=\"#modo-adjunto\"> mode rattaché</a> emplois n'utilisent pas de minuterie, ils fonctionnent via le script PVE-hook."
},
{
"id": "retencion",
"term": "Conservation (keep-last, keep-daily…)",
"def": "Politique qui décide quelles sauvegardes plus anciennes à conserver et à pruner. Défini par travail avec des paramètres comme <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Appliquée par le processus d’exécution après chaque sauvegarde réussie."
}
]
},
{
"title": "Restaurer",
"intro": "Termes du flux de restauration.",
"entries": [
{
"id": "restauracion-universal",
"term": "Restauration universelle",
"def": "Le flux de restauration ProxMenux n'extrait pas seulement le système de fichiers : il lit le manifeste pour repérer les différences entre la source et la cible, reproduit la configuration du système et réexécute les installateurs des composants gérés par ProxMenux. Le but est de reproduire l'hôte source, pas seulement l'archive."
},
{
"id": "hidratacion",
"term": "Hydratation entre versions du noyau",
"def": "Étape de restauration qui fusionne les réglages de l’utilisateur depuis la source (paramètres IOMMU, ID VFIO, particularités et clés GRUB) avec la configuration de démarrage neuve de la cible, sans recopier tels quels les fichiers liés au noyau source. S’exécute si le noyau cible est plus récent que celui de la sauvegarde."
},
{
"id": "cross-kernel",
"term": "Restaurer le cross-kernel",
"def": "Restaurer où le noyau de la cible diffère de (habituellement est plus récent que) celui de la source. Nécessite le passage <a href=\"#hidratacion\">hydration</a> pour éviter de traîner le long de fichiers incompatibles avec le noyau de la cible."
},
{
"id": "instalador-postboot",
"term": "Installation après démarrage",
"def": "Composants réinstallés après le premier démarrage de l'hôte restauré (drivers NVIDIA, drivers Coral TPU, outils AMD GPU, outils Intel GPU). Chaque installateur fonctionne contre le noyau de la cible, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source."
},
{
"id": "compatibility-check",
"term": "Vérification de compatibilité",
"def": "Comparaison entre le manifeste source et l'état de la cible que ProxMenux effectue au début de la restauration. Il décide quelles parties sont copiées mot à mot, qui ont besoin d'hydratation et qui sont recréées par un installateur."
},
{
"id": "equipo-recien-instalado",
"term": "Installation fraîche",
"def": "Hôte juste réinstallé à partir de zéro, sans fichier local <a href=\"#clave-cifrado\">key</a>. La restauration d'une sauvegarde chiffrée nécessite d'abord la récupération du fichier clé à partir de l’<a href=\"#sobre-recuperacion\">enveloppe</a> stockée sur PBS, en utilisant la phrase de passe <a href=\"#passphrase-recuperacion\">de récupération</a>."
}
]
}
],
"whereNext": {
"heading": "Où après",
"items": [
{
"label": "Comment ça marche",
"href": "/docs/backup-restore/how-it-works",
"tail": " — où se placent rootfs, le manifeste et l’inventaire des applications dans une sauvegarde."
},
{
"label": "Destination Proxmox Backup Server",
"href": "/docs/backup-restore/destinations/pbs",
"tail": "— où le cryptage côté client, le fichier clé, la phrase de récupération et l'enveloppe sont documentés en profondeur."
},
{
"label": "Restauration",
"href": "/docs/backup-restore/restoring",
"tail": " — procédure de restauration et utilisation du manifeste."
}
]
}
}
web/messages/fr/docs/backup-restore/how-it-works.json
+205
View File
@@ -0,0 +1,205 @@
{
"meta": {
"title": "Comment ProxMenux Sauvegarde fonctionne en interne — rootfs, manifeste, applications",
"description": "Description détaillée de ce qu'une sauvegarde ProxMenux contient : les rootfs produits par rsync du profil de chemin par défaut, le manifeste structuré construit par six collecteurs indépendants, et l'inventaire d'applications qui entraîne la réinstallation automatique des paquets et des composants après une restauration.",
"ogTitle": "Comment la sauvegarde ProxMenux fonctionne en interne",
"ogDescription": "Les trois parties d’une sauvegarde ProxMenux : rootfs, manifeste et applications.",
"twitterTitle": "Fonctionnement des sauvegardes ProxMenux | ProxMenux",
"twitterDescription": "Les trois charges utiles d'une sauvegarde ProxMenux et comment la restauration reproduit l'hôte source à partir d'eux."
},
"header": {
"title": "Comment ça marche",
"description": "La structure interne d’une sauvegarde ProxMenux — système de fichiers, manifeste et inventaire des applications — et leur utilisation pour recréer l’hôte source sur une destination dont le noyau peut être différent.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Une archive, trois charges utiles",
"body": "Chaque sauvegarde crée trois parties bien définies dans un même répertoire de préparation. L’archive envoyée à la destination (<code>.tar.zst</code> local, sauvegarde PBS ou archive Borg) conserve cette structure. La restauration utilise les trois : <strong>le manifeste</strong> est consulté avant toute modification pour détecter les différences et déterminer les exclusions ; <strong>rootfs</strong> fournit les fichiers de configuration, appliqués à chaud ou après redémarrage ; <strong>l’inventaire des applications</strong> guide l’installation des paquets et la réinstallation des composants après démarrage. Chaque partie peut être examinée ou extraite indépendamment."
},
"layout": {
"heading": "Mise en page des archives",
"intro": "Chaque archive suit la même disposition de l'arbre, quelle que soit la destination. Le sous-répertoire <code>metadata/</code> détient les charges utiles structurées; le sous-répertoire <code>rootfs/</code> détient la copie du système de fichiers.",
"treeCaption": "Le répertoire de mise en scène a été établi lors d'une sauvegarde. Chaque destination reçoit le même arbre (adapté à son format natif: tar pour local, PBS morceaux pour PBS, segments borg pour 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": "La partie rootfs",
"intro": "L’arborescence <code>rootfs/</code> est une <strong>simple copie du système de fichiers</strong>, créée par <code>rsync</code> depuis l’hôte source. Elle contient un <strong>profil par défaut</strong> sélectionnant les chemins nécessaires à une restauration Proxmox, ainsi que les <strong>chemins personnalisés</strong> ajoutés à la tâche ou à la session interactive. La sélection est volontairement limitée aux chemins qui <em>contiennent de la configuration</em> ou <em>conservent un état que Proxmox ne peut pas recréer seul</em>.",
"defaultProfileTitle": "Le profil par défaut",
"defaultProfileBody": "Le profil par défaut est défini par <code>hb_default_profile_paths</code> dans <code>lib_host_backup_common.sh</code>. Il couvre huit catégories fixes, plus l’état ZFS si nécessaire, qui décrivent ensemble un hôte Proxmox fonctionnel :",
"categoriesTitle": "Catégories de chemins",
"categoryRows": [
{
"category": "Noyau PVE",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
"why": "Contenus du système de fichiers cluster et vzdump par défaut. La base de données pmxcfs (<code>config.db</code>) est capturée comme un instantané cohérent via <code>sqlite3 .backup</code> sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync. Lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé automatiquement comme base lors de la restauration."
},
{
"category": "Identité de l'hôte & réseau",
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
"why": "Les éléments nécessaires pour retrouver le réseau avec la même identité. Les fichiers <code>.link</code> dans <code>/etc/systemd/network</code> associent le nom des interfaces à leur adresse MAC, afin de conserver les noms lors des réinstallations et des changements matériels."
},
{
"category": "Accès et authentification",
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
"why": "Clés SSH, règles sudo et configuration PAM. Les perdre peut empêcher l’utilisateur d’accéder à l’hôte restauré."
},
{
"category": "Noyau et démarrage",
"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 jetons, listes noires de module, ID de périphérique VFIO, table de montage, configuration de la pile de stockage."
},
{
"category": "Shell et paramètres régionaux",
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
"why": "Configuration shell à l'échelle du système, variables d'environnement, configuration de génération locale."
},
{
"category": "Gestion des paquets et cron",
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
"why": "Sources APT pour une résolution de paquets cohérente, tâches programmées définies par l'utilisateur."
},
{
"category": "État et outils ProxMenux",
"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": "Outillage facultatif mais courant Proxmox. Les chemins manquants sont notés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
},
{
"category": "Exécutables ProxMenux et compte root",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (sous-dirs volatils exclus)",
"why": "Les binaires installés par ProxMenux et la configuration par utilisateur sous <code>/root</code>. Les chemins volatils (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sont exclus de la copie. <code>/var/lib/proxmenux</code> détient les tâches de sauvegarde programmées et l'état de l'hôte conservé par ProxMenux; la mise en scène de restauration, les copies de retour et les marqueurs post-restauration sont exclus, parce qu'ils appartiennent à l'hôte qui exécute une restauration."
},
{
"category": "État ZFS (conditionnel)",
"paths": "/etc/zfs",
"why": "Seulement inclus lorsque l'hôte source exécute ZFS. Contient <code>zpool.cache</code> et <code>hostid</code>."
}
],
"customTitle": "Extension du profil avec des chemins personnalisés",
"customBody": "Au-delà du profil par défaut, ProxMenux offre deux façons d'inclure des chemins supplémentaires dans une sauvegarde. Ils composent sans conflit et s'appliquent à la fois aux sauvegardes interactives et aux emplois programmés.",
"customExtrasTitle": "1. Extras persistants (fichier par hôte)",
"customExtrasBody": "Un fichier texte à <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contient une liste de chemins absolus que l'utilisateur a marqués comme « toujours inclure » sur cet hôte. Lorsqu'une sauvegarde fonctionne en mode <strong>Default</strong>, ProxMenux ajoute ces chemins au profil par défaut automatiquement sans demander. Le fichier est édité à partir de l'interface — pas d'édition manuelle nécessaire — et persiste à travers les reboots et les mises à jour. Un chemin absolu par ligne ; les commentaires <code>#</code> sont autorisés.",
"customModeTitle": "2. Mode personnalisé (par exécution)",
"customModeBody": "Lancer une sauvegarde en mode <strong>Custom</strong> remplace l'application automatique du profil par défaut par une liste de contrôle montrant chaque chemin : les entrées par défaut du profil et les extras persistants (préfixés avec <code>[+]</code> et pré-cochés). L'utilisateur coche ou désactive les entrées pour cette exécution spécifique, et peut également appuyer sur <em>Ajouter un chemin personnalisé</em> pour entrer un nouveau chemin — qui est ensuite maintenu dans le fichier extras pour les futures sauvegardes.",
"customMissingTitle": "Voies absentes de la source",
"customMissingBody": "Tout chemin du profil (par défaut ou ajouté) qui n'existe pas sur l'hôte source est enregistré dans <code>metadata/missing_paths.txt</code> à l'intérieur de l'archive. La sauvegarde n’échoue ni ne s'arrête — l'utilisateur voit un résumé des chemins archivés et des chemins manquants à la fin. En pratique, cela se produit pour les chemins optionnels d'outillage comme <code>/etc/wireguard</code> ou <code>/etc/prometheus</code> lorsque ces outils ne sont pas installés."
},
"manifest": {
"heading": "La partie manifeste",
"intro": "<code>manifest.json</code> est un document structuré JSON qui décrit l'hôte source au moment de la sauvegarde. Il est produit par <strong>six modules de collecte indépendants</strong> orchestrés par <code>build_manifest.sh</code>. Chaque collecteur est en lecture seule, produit un fragment JSON bien défini, et revient à une valeur par défaut vide s'il échoue – le manifeste est toujours utilisable si une section est incomplète.",
"orchestratorCaption": "Les six modules de collecte composent le manifeste. Chaque collecteur fonctionne dans son propre sous-processus; une défaillance d'un seul tombe à un défaut de sécurité documenté et avertit mais n'interrompt pas la sauvegarde.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
"produces": "source_host",
"content": "Nom d'hôte, version PVE (<code>pveversion</code>), version PBS si l'hôte exécute le rôle de serveur de sauvegarde, noyau (<code>uname -r</code>), mode de démarrage (efi/bios), type de système de fichiers racine, modèle CPU + architecture, mémoire en KB."
},
{
"collector": "collect_hardware.sh",
"produces": "hardware_inventory",
"content": "GPU avec fabricant et correspondance avec l’installateur ProxMenux ; TPU Coral USB et M.2 détectés par <code>lsusb</code>/<code>lspci</code> ; interfaces réseau avec MAC, emplacement PCI et appartenance à un pont ; périphériques sans fil. Les entrées GPU comprennent l’heuristique <code>passthrough_eligible</code>."
},
{
"collector": "collect_storage.sh",
"produces": "storage_inventory",
"content": "ZFS pools (avec pool type + disques membres résolus à <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> ou crus <code>/dev/sdX</code> chemins en fonction de la façon dont chaque pool a été créé à l'origine), LVM Groupes de volume + mince pools, disques physiques avec SMART capacité, PVE <code>storage.cfg</code> entrées, montages externes."
},
{
"collector": "collect_kernel.sh",
"produces": "kernel_params",
"content": "Paramètres ajoutés par l’opérateur dans <code>/proc/cmdline</code>, sans les éléments standard comme <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> et <code>splash</code> ; modules chargés au démarrage depuis <code>/etc/modules</code> ; chemins des fichiers <code>/etc/modprobe.d/*.conf</code> contenant des directives effectives (<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": "Lire <code>/usr/local/share/proxmenux/managed_installs.json</code> (enregistrement de tout ce que ProxMenux a installé) et <code>installed_tools.json</code>. Chaque entrée conserve le chemin d'installation (<code>menu_script</code>) afin que la restauration puisse déclencher le même flux d'installation."
},
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
"content": "Énumère les VM (<code>qm list</code>) et les LXC (<code>pct list</code>) présents au moment de la sauvegarde — VMID, nom, état actuel. Seul l'inventaire : les données des invités sont sous la responsabilité de <code>vzdump</code> / PBS."
}
],
"schemaTitle": "Validation du schéma",
"schemaBody": "Le manifeste valide contre <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'exécution du <code>build_manifest.sh --validate</code> déclenche une validation de schéma côté Python JSON (exige <code>python3</code> + <code>jsonschema</code>). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
},
"applications": {
"heading": "L'inventaire des applications",
"intro": "Deux inventaires recensent les logiciels ajoutés aux paquets de base Proxmox VE : la liste des paquets dans <code>metadata/</code> et le registre des composants dans rootfs, détaillés ci-dessous. La restauration les utilise pour réinstaller les logiciels de l’utilisateur avec APT ou les installateurs ProxMenux selon leur mode d’installation initial.",
"packagesTitle": "packages.manual.list",
"packagesBody": "Une liste alphabétique en texte brut produite par <code>apt-mark showmanual</code>, avec les paquets APT <em>explicitement installés</em> sur l’hôte source. Les dépendances du système Proxmox VE de base sont exclues ; APT les réinstalle automatiquement sur la destination. Lors de la restauration, <code>_rs_run_complete_extras</code> lit la liste et applique un <em>filtre contre les suppressions en cascade</em> en trois passes : <code>dpkg -s</code> repère les paquets déjà installés, la détection des autres versions majeures vise les bibliothèques, et <code>apt-get install --simulate</code> vérifie le risque de suppression en cascade. Les paquets retenus sont installés avec <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (dans rootfs)",
"componentsBody": "Un registre JSON sous <code>/usr/local/share/proxmenux/</code> qui enregistre chaque composant ProxMenux a installé avec son état exact : version, drapeaux spécifiques ProxMenux (pour NVIDIA : <code>patched</code> booléen ; pour Coral : DKMS version). Ce fichier vit à l'intérieur des rootfs — pas dans <code>metadata/</code> — parce que c'est <em>lu après</em> la copie de rootfs vers la cible. Le répartiteur post-démarrage (<code>apply_cluster_postboot.sh</code>) itère ses entrées et exécute le crochet <code>--auto-reinstall</code> de chaque composant, qui lit l'état enregistré et reproduit l'installation contre le noyau courant de la cible.",
"componentInstallersTitle": "Installateurs de composants",
"componentInstallersBody": "Quatre installateurs ProxMenux exposent actuellement un point d'entrée <code>--auto-reinstall</code> :",
"installerRows": [
{
"component": "nvidia_driver",
"installer": "gpu_tpu/nvidia_installer.sh",
"action": "Lire <code>version</code> + <code>patched</code>. Télécharge exactement le même fichier d'exécution NVIDIA, construit des modules DKMS contre le noyau de la cible, réapplique le patch ProxMenux si la source l'avait."
},
{
"component": "coral_driver",
"installer": "gpu_tpu/install_coral.sh",
"action": "Lire la version du pilote Coral. Compile le module DKMS contre le noyau de la cible."
},
{
"component": "amdgpu_top",
"installer": "gpu_tpu/amd_gpu_tools.sh",
"action": "Lis la version enregistrée. Re-télécharge le <code>.deb</code> exact de la version GitHub."
},
{
"component": "intel_gpu_tools",
"installer": "gpu_tpu/intel_gpu_tools.sh",
"action": "APT-installe le paquet. Idépotent si déjà présent à partir de <code>packages.manual.list</code>."
}
]
},
"restoreFlow": {
"heading": "Comment la restauration consomme les trois charges utiles",
"intro": "La restauration est un pipeline en six étapes. Chaque étape lit un sous-ensemble spécifique de l'archive et met à jour l'hôte cible. Aucune étape n'exige que l'hôte source soit accessible — l'archive est entièrement autonome.",
"stagesCaption": "L’étape 1 consulte le manifeste pour déterminer les modifications possibles. L’étape 2 copie les chemins rootfs applicables à chaud. L’étape 3 prépare les chemins à risque pour le prochain démarrage. L’étape 3b importe les pools ZFS de données ne contenant pas la racine et dont tous les disques sont présents. L’étape 4 installe les paquets. L’étape 5 réinstalle les composants après redémarrage pour le noyau de la destination.",
"stageRows": [
{
"stage": "1",
"name": "Vérification de compatibilité",
"reads": "manifest.json",
"action": "Exécute <code>hb_compat_check</code>. Comparer le matériel source par rapport au matériel cible (NIC, ID de stockage), la version PVE et la version principale du noyau. Ensembles <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> ou <code>bk_older</code>) et peuple <code>RS_SKIP_PATHS</code> avec des exclusions à la dérive matérielle et aux différences de noyau."
},
{
"stage": "2",
"name": "Appliquer à chaud",
"reads": "rootfs/ (chemins sûrs seulement)",
"action": "<code>_rs_apply … hot</code> copie les entrées de <code>hb_classify_path</code>=<code>hot</code> directement à la cible en direct. Tout ce qui est sous <code>/etc/pve</code>, <code>/etc/network</code> ou des chemins classés comme <em>reboot</em>/<em>dangerous</em> est reporté."
},
{
"stage": "3",
"name": "En attente de préparation",
"reads": "rootfs/ (redémarrage + chemins dangereux)",
"action": "<code>_rs_prepare_pending_restore</code> prépare les chemins à risque dans <code>/var/lib/proxmenux/pending-restore/</code>, écrit <code>plan.env</code>, <code>apply-on-boot.list</code> et <code>rs-skip-paths.txt</code>, puis active <code>proxmenux-restore-onboot.service</code> pour le prochain démarrage."
},
{
"stage": "3b",
"name": "Importation des pools de données",
"reads": "manifest.storage_inventory + état ZFS de la destination",
"action": "<code>_rs_import_data_pools</code> tente d’importer chaque pool ZFS ne contenant pas la racine et dont tous les disques sont présents sur la destination. Avec un hostid étranger, l’importation est retentée avec <code>zpool import -f</code>. Si un disque manque, le pool est ignoré avec un avertissement. Le résultat par pool est enregistré dans <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
},
{
"stage": "4",
"name": "Installation du paquet",
"reads": "metadata/packages.manual.list",
"action": "<code>_rs_run_complete_extras</code> exécute le filtre sans risque de cascade et appelle <code>apt-get install -y</code> avec la liste des paquets survivants. La sortie complète va à <code>/var/log/proxmenux/restore-apt-*.log</code>."
},
{
"stage": "5",
"name": "Après le démarrage",
"reads": "rootfs (déjà appliqué) + components_status.json",
"action": "Après le redémarrage, <code>apply_pending_restore.sh</code> rejoue les chemins différés et <code>apply_cluster_postboot.sh</code> exécute <code>update-initramfs</code>, <code>update-grub</code> (ou <code>proxmox-boot-tool refresh</code>) et itère sur <code>components_status.json</code> en tirant le crochet <code>--auto-reinstall</code> de chaque composant."
}
]
},
"whyItWorks": {
"heading": "Pourquoi séparer la sauvegarde en trois parties",
"body": "La séparation suit le <strong>cycle de vie</strong> des données. Le système de fichiers est transféré avec <code>rsync</code> : rapidement, de façon transparente et atomique par fichier. L’état de configuration à interpréter avant toute modification est du <strong>JSON structuré</strong>, lisible indépendamment, versionnable par schéma et comparable automatiquement à l’état de la destination. Les logiciels à réinstaller sont décrits dans un <strong>inventaire</strong> de noms et versions ; le gestionnaire de paquets et les installateurs ProxMenux choisissent les binaires adaptés. Chaque partie répond à son besoin. Leur combinaison vise une restauration cohérente tout en tolérant les échecs : un manifeste corrompu laisse rootfs récupérable, un paquet manquant n’empêche pas l’installation des composants et l’échec d’un installateur sur une entrée n’arrête pas la suivante."
}
}
web/messages/fr/docs/backup-restore/index.json
+93
View File
@@ -0,0 +1,93 @@
{
"meta": {
"title": "ProxMenux Sauvegarde et restauration — Présentation | Sauvegarde et restauration complètes de l'hôte pour Proxmox VE",
"description": "La fonction de sauvegarde et de restauration de ProxMenux capture l'état complet d'un hôte Proxmox (système de fichiers, manifeste de configuration structuré et paquets/composants installés) et le reproduisent sur le même hôte ou sur un hôte différent. La sauvegarde et la restauration sont autonomes : aucune dépendance externe et les restaurations inter-noyaux sont prises en charge via un filtre de sous-ensemble sécurisé sensible à la direction et une hydratation indépendante du noyau.",
"ogTitle": "ProxMenux Sauvegarde et restauration – Présentation",
"ogDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants.",
"twitterTitle": "ProxMenux Sauvegarde et restauration | ProxMenux",
"twitterDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants."
},
"header": {
"title": "Sauvegarde et restauration",
"description": "Sauvegarde et restauration de l'hôte complet pour Proxmox VE. Capture le système de fichiers, la configuration et les composants installés dans une seule archive, et reproduit l'hôte sur la même installation Proxmox ou sur une autre installation Proxmox sans dépendances externes.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Qu'est-ce que c'est, en un seul paragraphe",
"body": "Une sauvegarde ProxMenux capture l’état complet d’un hôte Proxmox : <strong>le système de fichiers</strong>, avec les répertoires pertinents sous <code>/etc</code>, <code>/root</code> et <code>/var/lib/pve-cluster</code>, ainsi que les chemins personnalisés facultatifs ; <strong>un manifeste structuré</strong> en JSON décrivant le matériel détecté, les paramètres du noyau, la configuration réseau, l’état de ZFS, les utilisateurs et les entrées cron ; et <strong>un inventaire des applications</strong>, avec les paquets marqués comme installés manuellement par APT et les composants installés par ProxMenux, accompagnés de leurs versions exactes. Les trois destinations prises en charge — archive locale, Proxmox Backup Server (recommandé) et Borg — reçoivent le même contenu autonome. Chacune permet de reconstruire l’hôte cible sans que l’hôte source soit accessible pendant la restauration."
},
"video": {
"heading": "Présentation vidéo",
"intro": "Vous préférez regarder la sauvegarde et la restauration en action avant de la configurer ? Cette procédure pas à pas couvre une démonstration complète de bout en bout de la fonctionnalité dans ProxMenux.",
"title": "ProxMenux — Procédure pas à pas de sauvegarde et de restauration",
"caption": "Vidéo externe sur YouTube. Lecture en mode de confidentialité amélioré (pas de cookies jusqu'à ce que vous appuyiez sur play)."
},
"whatItIsNot": {
"heading": "Ce que ce n'est pas",
"intro": "Cette section couvre la sauvegarde et la restauration <strong>de l’hôte</strong> : l’installation Proxmox elle-même, et non les applications ou systèmes invités qui y fonctionnent.",
"items": [
"<strong>Ce n’est pas un outil de sauvegarde des VM/CT.</strong> Cette fonction ne capture ni les disques ni l’état de la RAM des invités ; c’est le rôle de <code>vzdump</code>. Les <strong>fichiers de configuration</strong> des invités (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> et <code>lxc/*.conf</code>) sont <strong>bien</strong> sauvegardés. Après restauration, l’inventaire réapparaît et les disques peuvent être restaurés ou rattachés à partir d’une sauvegarde existante sur PBS ou en local.",
"<strong>Ce n’est pas une opération à l’échelle du cluster.</strong> Chaque nœud se sauvegarde lui-même. L’appartenance au cluster est enregistrée dans <code>/etc/pve</code> afin de pouvoir réintégrer un nœud restauré, mais la restauration de tout le cluster nécessite de coordonner les différents nœuds.",
"<strong>Ce n’est pas une image complète du disque.</strong> Les binaires du noyau, l’initramfs et la partition de démarrage ne sont pas sauvegardés. Lors de la restauration, ProxMenux utilise les fichiers de démarrage de l’hôte cible, régénérés automatiquement par <code>update-initramfs</code> et l’outil du chargeur d’amorçage, puis installe les pilotes adaptés au noyau en cours d’exécution sur la cible."
]
},
"threePillars": {
"heading": "Les trois piliers d'une sauvegarde",
"intro": "Une archive ProxMenux est structurée autour de trois charges utiles autonomes. La restauration utilise les trois ensemble pour reproduire l'hôte source sur une cible sur laquelle le même noyau n'est peut-être même pas installé.",
"diagramCaption": "Chaque sauvegarde expédie les trois mêmes charges utiles, quelle que soit la destination. La restauration consomme les trois : rootfs pour déposer les fichiers, le manifeste pour détecter les dérives et les différences entre les noyaux, et l'inventaire des applications pour réinstaller les packages et les composants sur le propre noyau de la cible.",
"pillar1Label": "Système de fichiers",
"pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, plus un\ninstantané sqlite3\nde /var/lib/pve-cluster,\n+ chemins facultatifs)",
"pillar2Label": "Manifeste",
"pillar2Detail": "manifest.json\n(matériel, paramètres\ndu noyau, réseau,\nZFS, utilisateurs, cron,\npools ZFS, stockage)",
"pillar3Label": "Applications",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(paquets APT manuels + installateurs\nProxMenux avec versions)"
},
"restoreIsUniversal": {
"heading": "La restauration reproduit l'hôte source, pas l'archive",
"body": "La restauration d'une sauvegarde ProxMenux ne se contente pas d'extraire le système de fichiers. Le flux de restauration lit le manifeste pour détecter la dérive entre la source et la cible (différences matérielles, renommages des cartes réseau, version du noyau, identité du pool ZFS), restaure le système de fichiers, puis déclenche le programme d'installation de composant correct pour chaque service installé sur la source (pilote NVIDIA, Coral TPU, outils GPU AMD, outils Intel GPU). Chaque programme d'installation s'exécute sur le <strong>noyau actuel de la cible</strong>, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source. Lorsque le noyau de la cible est plus récent que celui de la sauvegarde, une passe d'<strong>hydratation</strong> indépendante du noyau fusionne les propres réglages de l'utilisateur (jetons IOMMU, ID de périphérique VFIO, adaptations particulières, clés GRUB) dans la nouvelle configuration de démarrage de la cible sans copier textuellement les fichiers liés au noyau."
},
"twoInterfaces": {
"heading": "Deux interfaces, un backend",
"intro": "Chaque étape du workflow de sauvegarde et de restauration est disponible à partir de deux points d'entrée. Les deux appellent la même bibliothèque shell, produisent des archives identiques et lisent le même registre de tâches.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "menu → Utilitaires →\nSauvegarde / Restauration de l'hôte\n\nFlux basé sur le dialogue,\nCompatible avec SSH, scriptable\npour une utilisation sans surveillance.",
"webLabel": "ProxMenux Monitor (Web UI)",
"webDetail": "Onglet Sauvegardes dans\nl’interface web de Monitor.\n\nRestauration en un clic, suivi\ndes journaux en direct, intégré\naux notifications et à la vue\ndes différences de retour arrière."
},
"whereNext": {
"heading": "Où aller à partir d'ici",
"intro": "Chaque sous-section ci-dessous couvre en profondeur un aspect du flux de travail. Commencez par <em>Comment ça marche</em> si l'objectif est de comprendre ce que contient l'archive et pourquoi. Accédez à <em>Destinations</em> pour configurer la cible de la copie. Lisez <em>Restauration</em> et <em>Restauration inter-noyaux</em> pour le côté récupération.",
"items": [
{
"label": "Comment ça marche",
"href": "/docs/backup-restore/how-it-works",
"tail": "— les trois charges utiles (rootfs, manifeste, applications) en détail, avec les collecteurs qui les produisent et le format de chaque fichier."
},
{
"label": "Destinations",
"href": "/docs/backup-restore/destinations",
"tail": "— comparaison de local, Proxmox Backup Server (recommandé) et Borg, et comment configurer chacun d'eux."
},
{
"label": "Création de sauvegardes",
"href": "/docs/backup-restore/creating-backups",
"tail": "— sauvegardes ponctuelles, profil de chemin par défaut, ajout de chemins personnalisés, chiffrement pour PBS."
},
{
"label": "Tâches planifiées",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": "— nouvelles tâches ou attachement à une tâche vzdump PVE existante, formats de planification, modal de détail de la tâche."
},
{
"label": "Restauration",
"href": "/docs/backup-restore/restoring",
"tail": "— les trois actions sur une archive (afficher, télécharger, restaurer), la restauration complète ou personnalisée, le répartiteur post-démarrage et pourquoi les dix dernières minutes sont importantes."
},
{
"label": "Restauration inter-noyaux",
"href": "/docs/backup-restore/cross-kernel",
"tail": " — comportement tenant compte du sens du changement de version lorsque le noyau cible diffère de celui de la sauvegarde, filtre de sous-ensemble sûr et quatre phases d’hydratation."
}
]
}
}
web/messages/fr/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/fr/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Tâches planifiées — temporisateurs, mode attach et rétention | ProxMenux",
"description": "Tâches de sauvegarde d’hôte ProxMenux programmées. Deux modes de création (minuteur systemd propre ou association à une tâche vzdump PVE existante), règles de rétention appliquées par tâche avec proxmox-backup-client, Borg ou le nettoyage local, fichiers sous /var/lib/proxmenux/backup-jobs et script d’exécution produisant les mêmes archives que le processus interactif.",
"ogTitle": "Sauvegarde ProxMenux — tâches programmées",
"ogDescription": "Sauvegardes d'hôte programmées non surveillées avec mode de fixation, conservation, et les mêmes trois destinations que le flux interactif.",
"twitterTitle": "Tâches planifiées | ProxMenux",
"twitterDescription": "Tâches programmées de sauvegarde d’hôte sans intervention, avec mode d’association et rétention."
},
"header": {
"title": "Tâches programmées",
"description": "Tâches de sauvegarde d’hôte sans intervention. Deux modèles de création : une nouvelle tâche indépendante avec son propre calendrier, ou une tâche associée à une tâche vzdump PVE existante, dont elle reprend le calendrier et la rétention. Les deux produisent les mêmes archives que le processus interactif.",
"section": "Sauvegarde et restauration"
},
"intro": {
"title": "Les deux modèles de tâches programmées",
"body": "Une tâche programmée peut être créé selon l'un des deux modèles suivants :",
"modelsList": [
"<strong>Nouveau travail indépendant</strong> — ProxMenux définit lui-même l'horaire de travail avec sa propre minuterie systemd, indépendamment de toute autre tâche sur l'hôte. Compatible avec les trois destinations : Local, PBS et Borg.",
"<strong>Associer à une tâche vzdump PVE existante</strong> — la tâche n’a pas de calendrier propre ; elle s’exécute automatiquement quand la tâche vzdump parente sauvegarde les VM et LXC de cet hôte. Elle reprend son calendrier et sa rétention. Compatible avec les destinations locale et PBS (Borg n’est pas pris en charge, car PVE n’a pas de planificateur natif pour Borg)."
]
},
"attachBadge": {
"title": "Mode d’association — recommandé si une tâche vzdump PVE existe déjà",
"body": "Lorsqu’une tâche de sauvegarde vzdump PVE est déjà configurée pour les VM et LXC du nœud, l’association de la sauvegarde hôte la fait exécuter après celle des invités, dans le <strong>même cycle de sauvegarde</strong>. À la restauration, les configurations des invités viennent de la sauvegarde hôte (sous <code>/etc/pve</code>) et leurs disques des sauvegardes vzdump du même cycle. Cela facilite la récupération coordonnée du nœud, sans constituer un instantané atomique : des modifications pendant le cycle peuvent créer des écarts entre la configuration hôte et l’état des disques des invités."
},
"frequencyBadge": {
"title": "Fréquence recommandée",
"body": "Pour maximiser la compatibilité entre une sauvegarde hôte et sa future restauration, sauvegardez fréquemment l’hôte. Plus la copie est proche de son état actuel, moins la restauration doit réconcilier d’écarts de configuration, de paquets et de composants."
},
"modes": {
"heading": "Les deux modes",
"rows": [
{
"mode": "Nouveau travail planifié",
"backends": "Local, PBS, Borg",
"schedule": "Propre expression <code>OnCalendar</code> (syntaxe du calendrier systemd — par exemple <code>daily</code>, <code>Mon..Fri 03:00</code>).",
"retention": "Demandée séparément: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Appliquée par le script d’exécution après chaque sauvegarde réussie."
},
{
"mode": "Associer à une tâche vzdump PVE",
"backends": "Local, PBS (Borg n'a pas de planificateur côté PVE)",
"schedule": "Hérité de la tâche PVE parente. Aucun minuteur systemd n’est installé côté ProxMenux.",
"retention": "Héritée de la configuration <code>prune-backups</code> de la tâche parente (associée une à une aux variables <code>KEEP_*</code> du script d’exécution via <code>hb_pve_prune_to_keep_env</code>)."
}
]
},
"attachDetail": {
"heading": "Comment fonctionne le mode de fixation",
"intro": "PVE écrit les tâches <code>vzdump</code> dans <code>/etc/pve/jobs.cfg</code>, avec une section par tâche indiquant le stockage des sauvegardes VM et LXC. Le mode d’association exige un backend compris par ProxMenux (local ou PBS). La sauvegarde hôte s’exécute via le hook job-end après la fin de la tâche de sauvegarde des invités.",
"steps": [
{
"step": "1",
"detail": "Lors de la création de tâches, ProxMenux liste les tâches parent PVE compatibles via <code>hb_pve_list_vzdump_jobs_for_backend</code>. L'utilisateur en choisit un."
},
{
"step": "2",
"detail": "Le <code>.env</code> de l'emploi est écrit avec <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> et les valeurs de <code>KEEP_*</code> héritées; aucun minuteur systemd n'est créé."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> enregistre un hook dans <code>/etc/vzdump.conf</code>. À la phase job-end de toute tâche vzdump, il compare le <code>$STOREID</code> reçu au <code>PVE_STORAGE</code> de chaque tâche associée activée et appelle le script d’exécution en cas de correspondance. L’association se fait par stockage, et non par identifiant de la tâche parente choisie."
},
{
"step": "4",
"detail": "L’archive est enregistrée dans le même stockage que les sauvegardes vzdump : <code>path/dump/</code> pour la destination locale ou le dépôt PBS configuré dans l’entrée de stockage PVE."
}
],
"outroBody": "Le mode d’association n’a pas de minuteur propre. Désactiver ou supprimer la tâche PVE parente choisie arrête son déclenchement, mais une autre tâche vzdump utilisant le même stockage peut encore lancer la sauvegarde hôte. Désactivez ou supprimez la tâche ProxMenux elle-même pour l’empêcher. Lors d’une désactivation, son entrée reste sur disque pour permettre une réactivation ou une nouvelle association."
},
"storageLayout": {
"heading": "Fichiers qui constituent un travail",
"intro": "Chaque travail programmé est entièrement décrit par trois ou quatre fichiers sur disque. Les lire donne la configuration complète du travail sans compter sur l'interface.",
"rows": [
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Backend, identifiant de sauvegarde ou destination, calendrier (nouvelle tâche) ou tâche PVE parente (association), indicateur d’activation, valeurs de rétention <code>KEEP_*</code> et références aux identifiants."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "Un chemin absolu par ligne : la sélection figée à partir du profil lors de la création de la tâche. Modifier le fichier utilise la nouvelle sélection à la prochaine exécution du minuteur."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "Nouveau mode seulement. Le service invoque <code>run_scheduled_backup.sh JOB_ID</code>. Le minuteur le planifie avec <code>Persistent=true</code> (exécutions manquées rattrapées au prochain démarrage) et un petit <code>RandomizedDelaySec=120</code> pour répartir la charge lorsque plusieurs tâches partagent la même expression OnCalendar."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Mode d’association uniquement. Installé une fois par <code>hb_install_vzdump_hook</code> ; compare le <code>PVE_STORAGE</code> de chaque tâche associée au <code>$STOREID</code> transmis par PVE au hook."
}
]
},
"runner": {
"heading": "Ce que fait une tâche à son déclenchement",
"intro": "Chaque travail — qu’il s’agisse d’une nouvelle tâche indépendante ou d’une tâche associée — comporte la même séquence en trois étapes:",
"steps": [
"<strong>Prépare la sauvegarde.</strong> Lit la configuration de travail (destination, profil, chemins) et assemble l'arborescence des archives exactement comme le flux interactif. Le résultat est la même archive qu'une sauvegarde manuelle avec ces paramètres produirait.",
"<strong>Écrire à la destination.</strong> Charge ou écrit l'archive vers la destination configurée — un fichier local <code>.tar.zst</code>, une sauvegarde PBS ou une archive Borg — en utilisant exactement les mêmes outils et identifiants qu’une sauvegarde manuelle vers la même destination.",
"<strong>Appliquer la rétention.</strong> Supprime les anciennes sauvegardes de la destination, en maintenant les nombres <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurés sur le travail. La purge est effectuée par la destination elle-même: PBS applique sa propre conservation, Borg exécute <code>borg prune</code>, et pour Local ProxMenux supprime les fichiers qui tombent en dehors de la fenêtre <code>keep-last</code>."
]
},
"management": {
"heading": "Gestion des tâches",
"intro": "Le menu planificateur (Scripts TUI) et l'onglet Sauvegardes Monitor exposent les mêmes actions sur n'importe quel travail.",
"rows": [
{
"action": "Exécuter maintenant",
"detail": "Appelle immédiatement le script d’exécution, sans attendre le minuteur ou le hook vzdump. Utile pour vérifier la configuration sans attendre le prochain déclenchement."
},
{
"action": "Activer / Désactiver",
"detail": "Nouveau mode : <code>systemctl enable/disable --now</code> la minuterie. Attache le mode : retourne le drapeau <code>ENABLED</code> dans le travail env — le script hook l'honore au prochain déclenchement PVE."
},
{
"action": "Modifier",
"detail": "Rouvre les champs de destination, calendrier, profil et rétention et réécrit les fichiers de la tâche. Conserve son identifiant."
},
{
"action": "Supprimer",
"detail": "Supprime le fichier env, la liste des chemins et le minuteur et service systemd (nouvelle tâche), et désactive l’association au hook (mode d’association). Les archives déjà présentes à destination restent intactes."
},
{
"action": "Voir le journal",
"detail": "Affiche en continu <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> : un fichier journal par exécution. Le programme d'exécution émet également une ligne d'état compacte à journald sous le service systemd."
}
]
},
"notifications": {
"heading": "Notifications",
"body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
},
"whereNext": {
"heading": "Où aller ensuite?",
"items": [
{
"label": "Création de sauvegardes",
"href": "/docs/backup-restore/creating-backups",
"tail": "— le flux interactif qui partage le moteur avec le planificateur."
},
{
"label": "Destinations",
"href": "/docs/backup-restore/destinations",
"tail": "— configuration par moteur utilisée à la fois par le flux interactif et le planificateur."
},
{
"label": "Restauration",
"href": "/docs/backup-restore/restoring",
"tail": " — le processus qui utilise les sauvegardes produites par les tâches."
}
]
}
}
web/messages/it/docs/backup-restore/creating-backups.json
+220
View File
@@ -0,0 +1,220 @@
{
"meta": {
"title": "Creazione di backup — flusso di backup interattivo | ProxMenux",
"description": "Il flusso di backup interattivo di ProxMenux: due punti di accesso (il menu TUI di Scripts e l’interfaccia web di Monitor), tre destinazioni, due modalità di profilo, una fase di preparazione temporanea e una finestra di conferma. La pagina descrive la matrice con sei opzioni, i profili predefinito e personalizzato e ciò che vede l’utente dalla scelta del backup fino al salvataggio dell’archivio a destinazione.",
"ogTitle": "ProxMenux Backup — creazione di backup",
"ogDescription": "Il flusso di backup interattivo con tre destinazioni, due profili e una fase di staging comune.",
"twitterTitle": "Creazione di backup | ProxMenux",
"twitterDescription": "Flusso di backup interattivo con tre destinazioni e due modalità di profilo."
},
"header": {
"title": "Creazione di backup",
"description": "Il flusso di backup interattivo: scegli una destinazione e un profilo, controlla il riepilogo di conferma e segui il salvataggio dell’archivio. I due punti di accesso condividono lo stesso backend e producono archivi identici.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Due punti di ingresso, funzionalità identiche",
"body": "La TUI di Scripts e l’interfaccia web di Monitor offrono <strong>esattamente le stesse funzionalità</strong>. Ogni backup — manuale o pianificato — usa la stessa matrice di scelta (tre destinazioni × due profili) e richiama la stessa funzione backend per ogni cella (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Gli archivi prodotti dai due punti di accesso sono indistinguibili. La scelta dipende dalle preferenze: la TUI è adatta a SSH e agli script; Monitor offre il controllo con il mouse insieme alle viste delle notifiche e del monitoraggio dei log."
},
"entryPoints": {
"heading": "I due punti di ingresso",
"rows": [
{
"entry": "ProxMenux Scripts (TUI)",
"path": "menu → Utilities → Host Config Backup",
"detail": "Flusso basato sul dialogo, SSH-friendly. Il menu principale presenta le sei opzioni direttamente. Utilizza <code>backup_menu</code> in <code>backup_host.sh</code>."
},
{
"entry": "ProxMenux Monitor (interfaccia web)",
"path": "Backups tab → Create backup",
"detail": "Flusso guidato da una procedura assistita. Le stesse sei opzioni sono presentate in un modulo in due passaggi (destinazione → profilo). Le stesse funzioni backend vengono richiamate tramite l’API Flask."
}
]
},
"modes": {
"heading": "Backup manuali e pianificati",
"body": "I backup possono essere prodotti in due modi: <strong>manuale</strong> (il flusso interattivo descritto in questa pagina - l'utente sceglie una destinazione e un profilo da un menu e segue il salvataggio dell’archivio) o <strong>pianificato</strong> (un lavoro non assistito che funziona su un timer in stile cron e applica la ritenzione configurata sul lavoro). Entrambe le modalità supportano le stesse tre destinazioni e gli stessi due profili, ed entrambe sono disponibili da entrambi i punti di ingresso — il menu Script TUI e la scheda Monitor Backups. I lavori programmati utilizzano le stesse funzioni backend del flusso manuale attraverso <code>run_scheduled_backup.sh</code>; gli archivi prodotti sono indistinguibili.",
"seeAlso": "La pagina dei lavori programmati copre il flusso completo, incluso come creare un lavoro, collegarlo a un timer PVE vzdump esistente e configurare i valori di ritenzione.",
"monitorAlt": "Scheda di backup ProxMenux Monitor che mostra la Nuova finestra di dialogo di backup programmata con i campi di destinazione, profilo, pianificazione e ritenzione.",
"monitorCaption": "Backup pianificato — ProxMenux Monitor. La stessa finestra guidata che crea un backup manuale contiene in basso i campi di pianificazione e conservazione per l’esecuzione senza intervento."
},
"matrix": {
"heading": "La matrice con sei opzioni",
"intro": "La scelta determina sia il backend eseguito sia la strategia di selezione dei percorsi. Consulta le pagine delle singole destinazioni per i dettagli di configurazione di ogni cella.",
"rows": [
{
"combo": "1",
"destination": "PBS",
"profile": "Predefinito",
"action": "Carica il profilo predefinito e gli extra persistenti su un repository PBS configurato."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Predefinito",
"action": "Crea un archivio con il profilo predefinito più extra persistenti nel repository Borg selezionato."
},
{
"combo": "3",
"destination": "Locale",
"profile": "Predefinito",
"action": "Scrive un archivio <code>.tar.zst</code> con il profilo predefinito più extra persistenti al target locale configurato."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Personalizzato",
"action": "Apre il selettore dei percorsi prima del caricamento su PBS; l’utente seleziona i percorsi e può aggiungerne di nuovi."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Personalizzato",
"action": "Apre il selettore dei percorsi prima di creare l’archivio Borg."
},
{
"combo": "6",
"destination": "Locale",
"profile": "Personalizzato",
"action": "Apre il selettore dei percorsi prima di scrivere il file <code>.tar.zst</code> locale."
}
]
},
"profiles": {
"heading": "Profilo predefinito e personalizzato",
"defaultTitle": "Profilo predefinito",
"defaultBody": "Il profilo predefinito è l'elenco curato da <code>hb_default_profile_paths</code> (documentato in <em>Come funziona</em> sotto <em>Categorie di percorsi</em>) più ogni voce nel file extra persistente <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. L'utente conferma le opzioni di destinazione e crittografia e il backup procede senza ulteriori selezioni dei percorsi.",
"customTitle": "Profilo personalizzato",
"customBody": "Il profilo personalizzato apre un elenco con tutti i percorsi del profilo predefinito (non selezionati) e tutti gli extra persistenti (già selezionati, con il prefisso <code>[+]</code>). L’utente seleziona i percorsi per questa esecuzione e può premere <em>Aggiungi percorso personalizzato</em> per aggiungere un nuovo percorso assoluto. I percorsi aggiunti vengono salvati in <code>backup-extra-paths.txt</code>, così i backup futuri li includono automaticamente senza doverli aggiungere di nuovo. Deselezionare un extra persistente lo esclude da questa esecuzione ma non lo elimina dal file — l’eliminazione avviene con l’azione separata <em>Gestisci percorsi personalizzati</em>, al di fuori del flusso di backup.",
"customPickerAlt": "Elenco di controllo del profilo personalizzato che mostra i percorsi di predefinito (non selezionati) e gli extra persistenti (già selezionati con un prefisso [+]), più pulsanti per aggiungere un nuovo percorso o confermare la selezione.",
"customPickerCaption": "Profilo personalizzato — il selettore dei percorsi. I percorsi del profilo predefinito non sono selezionati; gli extra persistenti sono già selezionati con il prefisso [+]. L’utente seleziona i percorsi per questa esecuzione.",
"manageCustomAlt": "Menu di gestione dei percorsi personalizzati con l’elenco degli extra persistenti e le opzioni per aggiungerli, rimuoverli o modificarli.",
"manageCustomCaption": "Gestisci percorsi personalizzati — il punto di ingresso dove vengono aggiunti o rimossi gli extra persistenti. Ogni percorso elencato qui è incluso automaticamente nei backup in modalità predefinita senza dover aprire il selettore personalizzato."
},
"commonPipeline": {
"heading": "Cosa funziona indipendentemente dalla destinazione",
"intro": "Una volta definito il profilo, ogni backend esegue la stessa procedura di preparazione temporanea prima di passare al proprio metodo di caricamento. <code>hb_prepare_staging</code> assembla l’albero dell’archivio in <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> e compila ciascuno dei tre blocchi di dati.",
"steps": [
{
"step": "1",
"name": "Assemblaggio del rootfs",
"detail": "Esegue <code>rsync -a</code> per ogni percorso selezionato verso <code>staging_root/rootfs/</code>. Il database pmxcfs in <code>/var/lib/pve-cluster/config.db</code> viene acquisito separatamente tramite <code>sqlite3 .backup</code> per ottenere un’istantanea coerente senza arrestare il cluster; i file ausiliari <code>.db-wal</code> / <code>.db-shm</code> sono esclusi da rsync. Se <code>sqlite3</code> non è disponibile, viene invece salvato un file <code>config.db.raw-fallback</code>, che il ripristino adotta come database durante l’importazione. Da <code>/root/</code> sono esclusi i sottopercorsi volatili (cronologia bash, cache, cestino). I percorsi assenti nell’origine vengono registrati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
},
{
"step": "2",
"name": "Generazione manifesto",
"detail": "<code>build_manifest.sh</code> coordina i sei moduli di raccolta e scrive <code>manifest.json</code> nella radice della directory temporanea. Se un modulo non riesce, la sezione interessata assume un valore predefinito vuoto documentato; il manifest resta valido."
},
{
"step": "3",
"name": "Inventario dei pacchetti",
"detail": "<code>apt-mark showmanual</code> viene catturato verbatim in <code>metadata/packages.manual.list</code>. Lo stato dei componenti è già all'interno del rootfs ripristinato (<code>components_status.json</code>) perché <code>/usr/local/share/proxmenux/</code> fa parte del profilo predefinito."
},
{
"step": "4",
"name": "Informazioni sull’esecuzione",
"detail": "<code>metadata/run_info.env</code> registra l'identità di esecuzione di backup — hostname, timestamp, versione del kernel — utilizzata dal controllo di compatibilità del ripristino per determinare la direzione del cross-kernel."
},
{
"step": "5",
"name": "Notifica (start)",
"detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
}
]
},
"included": {
"heading": "Cosa entra e cosa rimane fuori",
"intro": "Ogni percorso nel profilo risolto (predefinito + extra persistenti + selezione personalizzata) viene copiato con <code>rsync -aAXH --numeric-ids</code>. Un elenco di esclusione condiviso si applica a ogni percorso, e due directory portano ulteriori esclusioni specifiche del percorso.",
"globalTitle": "Esclusioni globali (applicate ad ogni percorso)",
"globalItems": [
"<code>images/</code> — dump immagine.",
"<code>dump/</code> — output di vzdump.",
"<code>tmp/</code> — file temporanei.",
"<code>*.log</code> — file di registro."
],
"rootTitle": "<code>/root/</code> esclusioni",
"rootBody": "<code>/root/</code> fa parte del profilo predefinito per includere nell’archivio gli script e la configurazione dell’utente. Sono esclusi i sottopercorsi volatili:",
"rootItems": [
"<code>.bash_history</code>",
"<code>.cache/</code>",
"<code>tmp/</code>",
"<code>.local/share/Trash/</code>"
],
"proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code> esclusioni",
"proxmenuxBody": "Questa directory spedisce solo stato utente — <code>components_status.json</code>, preferenze, cache post-installazione. Codice che la destinazione avrà già dalla propria installazione ProxMenux è escluso quindi un ripristino non sovrascrive i binari attuali dell'obiettivo con quelli più vecchi:",
"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": "Percorsi fuori dal profilo",
"notInProfileBody": "Qualsiasi cosa non elencata in <code>hb_default_profile_paths</code> e non aggiunta come un extra personalizzato o persistente non fa parte del backup. Esempi notevoli:",
"notInProfileItems": [
"<strong>VM e dischi LXC</strong> — gestiti da <code>vzdump</code>, non da questa funzione. I file di configurazione degli ospiti sotto <code>/etc/pve/nodes/*/qemu-server/*.conf</code> e <code>lxc/*.conf</code> vengono catturati (vivono sotto <code>/etc/pve</code>) in modo che il ripristino riproduca l'inventario; i dischi stessi vengono riattaccati da un backup vzdump/PBS esistente.",
"<strong><code>/boot</code> e <code>/boot/efi</code></strong> — binari del kernel, initramfs e la partizione UEFI ESP sono rigenerati dal proprio <code>update-initramfs</code>, <code>update-grub</code> o <code>proxmox-boot-tool refresh</code> dopo il ripristino. Il bootloader non è mai copiato verbatim.",
"<strong>Filesystem del kernel e dello stato di esecuzione del sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> e <code>/run</code> sono pseudo-filesystem generati dal kernel e da udev; non vengono salvati in modo persistente.",
"<strong>Binari dei pacchetti in <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — reinstallati da APT sul sistema di destinazione a partire da <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — stato runtime per host, non restaurato.",
"<strong><code>/home/USER</code></strong> — non nel profilo predefinito. Aggiungilo come un percorso personalizzato quando un sistema porta directory home degli utenti che devono sopravvivere a un ripristino."
],
"customPathsTitle": "Come vengono gestiti i percorsi personalizzati",
"customPathsBody": "Un percorso personalizzato aggiunto in linea in modalità personalizzata o persistito in <code>backup-extra-paths.txt</code> passa attraverso la stessa pipeline <code>rsync</code> come percorsi di default-profile. Si applicano esclusioni globali. Se il percorso personalizzato avviene sotto <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, si applicano ancora le esclusioni specifiche del percorso. Ogni percorso archiviato — predefinito o personalizzato — viene registrato in <code>metadata/paths_archived.txt</code>. I percorsi che non esistono sulla sorgente sono registrati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
},
"archiveStructure": {
"heading": "Struttura dell'archivio",
"intro": "La directory di staging prodotta da ogni backend segue lo stesso layout indipendentemente dalla destinazione. Il tarball, PBS <code>.pxar</code> o Borg archivio memorizza questo albero verbatim.",
"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": "Riepilogo conferma",
"body": "Prima che il backend scriva qualcosa alla destinazione, ProxMenux mostra una finestra di dialogo sommaria con la destinazione, l'ID di backup o il nome dell'archivio, lo stato di crittografia e l'elenco dei percorsi da copiare. Cancellando qui interrompe il backup in modo pulito — la directory di staging viene rimossa dal gancio <code>trap</code> impostato sulla funzione backend e nessun dato parziale raggiunge la destinazione."
},
"writing": {
"heading": "Scrivere alla destinazione",
"intro": "Dopo la conferma, ogni backend esegue la propria fase di scrittura. Le pagine delle destinazioni ne descrivono il funzionamento; gli elementi comuni sono il log, il file ausiliario e la notifica di completamento.",
"rows": [
{
"topic": "File di registro",
"detail": "Ogni backend scrive il suo output completo a <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> e, in caso di guasto, offre di aprirlo in una finestra di dialogo scorrevole. Il percorso di log è stampato nel sommario di completamento solo quando il file ha contenuto."
},
{
"topic": "Sidecar (solo locale)",
"detail": "<code>hb_write_archive_sidecar</code> scrive un <code>*.proxmenux.json</code> accanto all'archivio locale, quindi il Monitor lo identifica come backup host ProxMenux anche dopo mosse o rinominazioni."
},
{
"topic": "Notifica (completamento/errore)",
"detail": "Viene eseguito <code>hb_notify_lifecycle \"complete\"</code> o <code>\"fail\"</code> con durata, dimensione dell’archivio e — in caso di errore — l’ultima riga del log che sembra indicare un errore."
}
]
},
"finishedScreens": {
"heading": "Che aspetto ha un backup finito",
"intro": "Lo stesso evento di completamento viene mostrato da entrambi i punti di accesso. La TUI scrive un riepilogo nel terminale; la scheda Backups di Monitor mostra l’esecuzione nell’elenco degli archivi con dimensione, durata e indicatori di stato.",
"scriptsAlt": "ProxMenux Scripts TUI che mostra un backup host finito — destinazione, ID di backup, percorso snapshot, dimensione dei dati, durata e stato di crittografia.",
"scriptsCaption": "Backup finito — ProxMenux Scripts (TUI). Il blocco di completamento stampa la destinazione, l'ID di backup, il nome dell'istantanea o dell'archivio risultante, la dimensione dei dati, la durata e lo stato di crittografia.",
"monitorAlt": "Scheda di backup ProxMenux Monitor che mostra una voce di backup host finita con dimensioni, durata, indicatore del metodo e indicatore di crittografia.",
"monitorCaption": "Backup finito — scheda di backup ProxMenux Monitor. Il nuovo backup appare nell'elenco di archivio con il badge metodo di destinazione, dimensione, durata e - quando applicabile - l'indicatore di blocco di crittografia."
},
"whereNext": {
"heading": "Dove andare dopo",
"items": [
{
"label": "Destinazioni",
"href": "/docs/backup-restore/destinations",
"tail": "— dettagli di configurazione per Local, PBS e Borg."
},
{
"label": "Lavori programmati",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": "— eseguire lo stesso backup incustodito su un programma invece di interattivamente."
},
{
"label": "Ripristino",
"href": "/docs/backup-restore/restoring",
"tail": "— il flusso che consuma ciò che questa pagina produce."
}
]
}
}
web/messages/it/docs/backup-restore/cross-kernel.json
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Ripristino tra versioni del kernel — direzione, filtro sicuro e idratazione | ProxMenux",
"description": "Come ProxMenux ripristina un backup host con una versione principale diversa del kernel. Rileva la direzione della differenza, esclude percorsi critici per l’avvio se il kernel di destinazione è più recente e riapplica in quattro fasi IOMMU, ID VFIO e parametri personalizzati senza ricopiare i file legati al kernel.",
"ogTitle": "ProxMenux Backup — ripristino tra versioni del kernel e idratazione",
"ogDescription": "Ripristino tra versioni del kernel che considera la direzione del cambiamento, con filtro sicuro e idratazione indipendente dal kernel.",
"twitterTitle": "Ripristino tra versioni del kernel | ProxMenux",
"twitterDescription": "Come ProxMenux gestisce un ripristino quando il kernel di destinazione differisce dal backup."
},
"header": {
"title": "Ripristino tra versioni del kernel",
"description": "Come ProxMenux gestisce un ripristino quando l'host di destinazione esegue un kernel diverso da quello registrato nel backup — soprattutto quando il target esegue un kernel più recente. Spiega come viene rilevata la differenza, come i percorsi boot-critical che potrebbero rompere il bersaglio sono filtrati e come la configurazione dell'utente viene riapplicata senza copiare i file legati al kernel verbatim.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Ogni salto del kernel viene gestito in modo diverso",
"body": "Il kernel di un host Proxmox è identificato da una stringa di versione come <code>6.17.13-2-pve</code>. I primi due numeri (<strong>6.17</strong> in questo esempio) definiscono la versione principale: quando cambiano, alcuni file di configurazione scritti per il kernel precedente potrebbero non essere validi sul nuovo. Quando il ripristino rileva che il backup e l'obiettivo hanno diverse versioni principali del kernel, i rami di flusso in base alla direzione del salto — se il backup è più vecchio o più recente del bersaglio — perché i due casi hanno modalità di guasto opposte. I backup più recenti rispetto al target ripristinano in modo pulito come-è (bench-verified attraverso salti multipli del kernel). I backup più vecchi del target hanno bisogno di un filtro per evitare di rompere il boot del target con la configurazione scritta per un kernel che è cambiato da allora."
},
"directionCheck": {
"heading": "Il controllo della direzione",
"intro": "Durante la verifica della compatibilità, <code>hb_compat_check</code> confronta il kernel registrato nel manifesto del backup contro il kernel corrente dell'obiettivo (<code>uname -r</code>) e classifica il ripristino in uno dei tre casi, memorizzato nella variabile interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{
"direction": "same",
"condition": "La versione principale del kernel corrisponde tra backup e target.",
"behavior": "Il flusso di ripristino completo scorre invariato. Nessun filtro extra, nessuna idratazione, nessun avviso speciale nell'interfaccia utente."
},
{
"direction": "bk_newer",
"condition": "Il kernel del backup è PIÙ RECENTE di quello di destinazione (ad esempio: backup su 7.0, destinazione su 6.17).",
"behavior": "Il flusso di ripristino completo scorre invariato, esattamente come <code>same</code>. Nessun filtro viene applicato. Verificato empiricamente: i driver auto-reinstallano contro il kernel del target, IOMMU config si applica in modo pulito, le VM con passthrough GPU arrivano senza problemi."
},
{
"direction": "bk_older",
"condition": "Il kernel del backup è PIÙ VECCHIO di quello di destinazione (ad esempio: backup su 6.17, destinazione su 7.0).",
"behavior": "Il filtro sicuro-sottoset e l'idratazione di quattro fasi qui sotto sono attivati. Il ripristino prosegue — il bersaglio riproduce la fonte, ma i file boot-critical non sono copiati verbatim."
}
]
},
"whyBkNewerIsSafe": {
"heading": "Perché un backup con un kernel più recente rispetto al target ripristina invariato",
"body": "Quando il ripristino viene eseguito contro un obiettivo con un kernel <em>più vecchio</em> rispetto a quello registrato nel backup, ogni meccanismo che il ripristino dipende è indipendente dalla versione del kernel. Gli installatori di driver GPU e altri installatori PCI-device rilevano il kernel in esecuzione con <code>uname -r</code> e compilano DKMS contro qualunque sia l'obiettivo. Il pacchetto APT install tira binari costruiti per la distribuzione del bersaglio. I gettoni cmdline IOMMU come <code>intel_iommu=on</code> sono stabili nelle principali versioni del kernel. Il backup trasporta i percorsi scritti sotto un kernel più recente, ma quei percorsi (module blacklists, GRUB defaults, initramfs config) sono ancora validi sintassi sul vecchio — i kernel ignorano i token che non riconoscono invece di fallire. Questo caso è equivalente in pratica a un ripristino dello stesso kernel, e ProxMenux lo tratta come tale."
},
"safeSubsetFilter": {
"heading": "Il filtro safe-subset (solo quando il kernel di destinazione è più recente)",
"intro": "Quando il kernel di destinazione è più recente di quello del backup, il controllo di compatibilità aggiunge percorsi critici di avvio 16 da <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Questi percorsi sono esclusi dal ripristino perché la scrittura di una versione di loro da un kernel più vecchio su un obiettivo che esegue un nuovo ha causato il panico del kernel nei test di panca. I percorsi coprono cinque categorie:",
"categoryRows": [
{
"category": "Caricatore di avvio",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB default legati all'ordine del kernel precedente e allo stato proxmox-boot-tool (cmdline, UUID ESP, ganci) che richiama i percorsi e gli identificatori dall'installazione precedente."
},
{
"category": "Moduli del kernel e artefatti del boot",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Le liste di carico automatico che possono riferire i moduli rinominati tra le major del kernel, le opzioni del modulo che potrebbero non essere applicate, initramfs hooks scritto per il kernel più vecchio."
},
{
"category": "Identità dello stack di stoccaggio e del filesystem",
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
"reason": "UUID che potrebbero non esistere su questa installazione, driver multipath che cambiano tra i kernel, iSCSI parametri che si evolvono, regole udev che possono legare a sottosistemi non esistenti, ZFS Stato (<code>zpool.cache</code> + <code>hostid</code>) che può bloccare pool come straniero."
},
{
"category": "Fonti APT",
"paths": "<code>/etc/apt</code>",
"reason": "Le suite sorgente APT possono attivare un downgrade di pacchetti critici sul prossimo aggiornamento."
},
{
"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": "Override delle unità e collegamenti .wants legati alla precedente versione principale di systemd; chiavi di configurazione che potrebbero non essere valide in una versione più recente."
}
],
"outroBody": "Il filtro viene eseguito PRIMA della finestra di dialogo di conferma in modo che l'utente veda l'elenco esatto dei percorsi che verranno saltati, categorizzati per ragione. Il ripristino continua — tutto il resto (configurazione VM/LXC, rete, /etc/pve, utenti, cron, stato ProxMenux, pacchetti, driver, /root) viene ripristinato normalmente."
},
"hydration": {
"heading": "Idratazione Kernel-agnostic",
"intro": "Il filtro omette file critici; l’idratazione riapplica impostazioni selezionate: cmdline IOMMU, ID VFIO, <code>GRUB_TIMEOUT</code> personalizzato e blacklist nvidia. Si esegue se il kernel di destinazione è più recente. La fusione cmdline conserva le chiavi di destinazione e i moduli mancanti vengono aggiunti. Valori GRUB e file consentiti possono sostituire contenuti diversi sul target. Ripetere gli stessi input è idempotente.",
"phaseRows": [
{
"phase": "1a — Via GRUB",
"detail": "Per host GRUB (installazioni ext4/lvm). <code>_rs_hyd_grub</code> unisce i parametri di <code>manifest.kernel_params.cmdline_extra</code> del backup in <code>GRUB_CMDLINE_LINUX_DEFAULT</code> del target, saltando le chiavi già presenti. Ripristina poi le chiavi consentite <code>GRUB_*</code> (<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>) da <code>/etc/default/grub</code> del backup se i valori differiscono dal target."
},
{
"phase": "1b — systemd-boot / ZFS",
"detail": "Per systemd-boot (tipicamente ZFS alla radice). <code>_rs_hyd_kernel_cmdline</code> unisce i parametri utente di <code>cmdline_extra</code> in <code>/etc/kernel/cmdline</code> del target, mantenendo intatti i parametri di avvio <code>root=</code>, <code>boot=</code> e <code>rootflags=</code> del target."
},
{
"phase": "2 — fusione /etc/modules",
"detail": "<code>_rs_hyd_modules</code> aggiunge moduli da <code>manifest.kernel_params.modules_loaded_at_boot</code> che sono nella lista bianca (<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>) E non già presente nell'obiettivo <code>/etc/modules</code>."
},
{
"phase": "3 — Copia di file whitelist",
"detail": "<code>_rs_hyd_files</code> copia i file scritti dall’utente dai rootf di staging al target live quando il contenuto differisce. La whitelist copre i file VFIO/nvidia/blacklist sotto le regole <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, e la regola di legatura ProxMenux VFIO + le regole nvidia udev sotto le regole <code>/etc/udev/rules.d</code>. I file distribuiti (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sono intenzionalmente esclusi: i loro contenuti si evolvono tra le versioni."
},
{
"phase": "4 — Forza rigenerazione dopo l’avvio",
"detail": "Le quattro fasi scrivono direttamente sul target attivo AL DI FUORI DEL il normale processo di ripristino. Per rendere i gettoni/moduli/file fusi effetto sul prossimo avvio, <code>HB_HYDRATION_APPLIED=1</code> si propaga attraverso <code>plan.env</code> a <code>apply_pending_restore.sh</code>, che forza <code>NEEDS_INITRAMFS=1</code> e <code>NEEDS_GRUB=1</code> indipendentemente da quello che era nell'elenco di applicazione. Il dispatcher post-avvio poi rigenera initramfs e rinfresca il bootloader."
}
]
},
"planCommit": {
"heading": "Plan vs commit — l'utente vede prima un'anteprima",
"body": "L'idratazione scorre in due modi. Prima della finestra di dialogo di conferma, ProxMenux funziona <code>_rs_apply_bk_older_hydration</code> in modalità <code>plan</code>: calcola esattamente ciò che sarebbe stato unito, popola <code>RS_HYDRATION_SUMMARY</code> con un blocco verde che elenca ogni azione, e restituisce senza scrivere. La finestra di dialogo di conferma mostra che il blocco verde accanto all'elenco arancione dei percorsi esclusi, così l'utente vede IN ANTICIPO ciò che verrà riapplicato automaticamente. Dopo la conferma dell'utente, ProxMenux replica lo stesso helper in modalità <code>commit</code> — stesse fasi, stessa logica, ma questa volta ogni fase scrive al target live. Cancellare la finestra di dialogo di conferma lascia il bersaglio intatto."
},
"flowDiagram": {
"heading": "Il flusso quando il kernel di destinazione è più recente di quello del backup",
"intro": "I passaggi aggiunti quando il kernel di destinazione è più recente siedono all'interno del normale flusso di ripristino. Tutto il resto — caldo applicare, in attesa di preparare, pacchetto di installazione, post-boot speditore — funziona identicamente a un ripristino dello stesso-kernel.",
"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": "Esempi concreti",
"intro": "Il passaggio di idratazione non è astratto — produce risultati osservabili, corretti per scenari comuni. Due esempi che l'idratazione gestisce automaticamente:",
"rows": [
{
"scenario": "GPU passante (VFIO)",
"detail": "Fonte aveva <code>intel_iommu=on iommu=pt</code> nel cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, e un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. L'idratazione fonde i token cmdline nel GRUB o nella cmdline del kernel, aggiunge i moduli vfio a <code>/etc/modules</code> e copia i due file modprobe scritti dall’utente. Sul prossimo avvio, IOMMU è attivo, modulo VFIO carico, il GPU è legato a vfio-pci e il VM viene fornito con il funzionamento passante."
},
{
"scenario": "Predefinizioni personalizzate GRUB",
"detail": "Fonte aveva <code>GRUB_TIMEOUT=1</code> e <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration legge entrambe le chiavi del backup <code>/etc/default/grub</code>, vede che differiscono dalle impostazioni di installazione fresche, e riscrive quelle due linee nel file del bersaglio (lasciando tutto il resto, incluso <code>GRUB_DISTRIBUTOR</code>, intatto)."
}
]
},
"callout": {
"warningTitle": "Ciò che l'idratazione non riapplica quando il kernel di destinazione è più recente",
"warningBody": "L'idratazione si applica solo alla configurazione ProxMenux sa essere sicura nelle versioni del kernel: IOMMU tokens, VFIO IDs, whitelist GRUB chiavi, e moduli da un elenco fisso (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Qualsiasi cosa al di fuori di quel set — initramfs personalizzato ganci sotto <code>/etc/initramfs-tools/hooks/</code>, file non whitelist sotto <code>/etc/modprobe.d/</code>, override unità systemd scritte dall’utente — rimane esclusa. Il motivo è concreto: questi file possono chiamare interfacce kernel-internal (module APIs, <code>/sys</code> layout, <code>udev</code> hooks) che cambiano tra le principali versioni, e applicandoli verbatim sopra il kernel più recente può impedire al bersaglio di avviare. Quando è richiesta la riproduzione esatta della catena di avvio, il ripristino deve essere eseguito su un host con la stessa versione del kernel principale del backup."
},
"codeReference": {
"heading": "Dove vivono i meccanismi",
"intro": "Per gli sviluppatori che cercano di tracciare o estendere il comportamento cross-kernel:",
"rows": [
{
"component": "Rilevamento della direzione",
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Imposta <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Elenco dei percorsi Safe-subset",
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emette linee <code>path\\treason</code> utilizzate sia dal filtro CLI che dal endpoint Web <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Fasi di idratazione",
"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>. Orchestrata da <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Rigenerazione forzata dopo l’avvio",
"location": "<code>apply_pending_restore.sh</code> legge <code>HB_HYDRATION_APPLIED</code> da <code>plan.env</code> e forza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Anteprima web",
"location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Carica la libreria helper, esegue <code>_rs_apply_bk_older_hydration</code> in modalità piano, restituisce le azioni al Web modal."
}
]
},
"whereNext": {
"heading": "Dove andare dopo",
"items": [
{
"label": "Ripristino",
"href": "/docs/backup-restore/restoring",
"tail": " — il processo completo di ripristino che integra i meccanismi di questa pagina."
},
{
"label": "Come funziona",
"href": "/docs/backup-restore/how-it-works",
"tail": " — manifesto e raccoglitori che producono il blocco <code>kernel_params</code> letto dall’idratazione."
}
]
}
}
web/messages/it/docs/backup-restore/destinations/borg.json
+234
View File
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Destinazione Borg — tipi di repository, autenticazione SSH, crittografia | ProxMenux",
"description": "La destinazione Borg salva i backup host ProxMenux in un repository locale, su un disco esterno montato o su un server remoto via SSH. Descrive la ricerca dell’eseguibile borg, le quattro opzioni iniziali per le chiavi SSH, la crittografia repokey, le destinazioni salvate e la conservazione per attività pianificata.",
"ogTitle": "ProxMenux Backup — Destinazione Borg",
"ogDescription": "Come ProxMenux salva i backup host nei repository Borg con autenticazione SSH e crittografia repokey.",
"twitterTitle": "Destinazione di backup Borg | ProxMenux",
"twitterDescription": "Repository Borg locali, su USB e accessibili via SSH per i backup host."
},
"header": {
"title": "Borg",
"description": "La destinazione Borg scrive i backup host a un repository Borg. Sono supportati tre tipi di repository: percorso filesystem locale, disco esterno montato o server remoto tramite SSH. Deduplicazione a livello di Chunk in tutti gli archivi del repository e crittografia repokey opzionale.",
"section": "Backup e ripristino"
},
"aboutBorg": {
"heading": "Quello che Borg è",
"body": "Borg (anche scritto BorgBackup) è uno strumento di backup deduplicante open source mantenuto dalla comunità di Borg Backup. Memorizza ogni archivio come un insieme di blocchi di lunghezza variabile all'interno di un repository; i pezzi sono condivisi in archivi in modo da ri-back up dati invariati ha un costo di archiviazione quasi zero. Borg non è legato a Proxmox — è uno strumento di backup generale utilizzato in molti ambienti. ProxMenux lo utilizza come una delle tre destinazioni per i backup host; ogni meccanismo specifico Borg descritto in questa pagina (tipo di repository, borg-serve su SSH, crittografia di repokey, prune) è il comportamento standard Borg."
},
"intro": {
"title": "Deduplicazione per blocchi con repository locali o accessibili via SSH",
"body": "Un repository Borg conserva blocchi condivisi tra tutti i suoi archivi: ripetere il backup di un file invariato non trasferisce né memorizza nuovi dati. ProxMenux usa <code>borg create</code> per il backup e <code>borg extract</code> per il ripristino. Il repository può trovarsi sullo stesso filesystem dell’origine, su un disco esterno montato o su un host remoto accessibile via SSH."
},
"binarySourcing": {
"heading": "Il binario di borg",
"intro": "Borg non è una dipendenza di base dell'installatore ProxMenux. Quando un backup viene eseguito, <code>hb_ensure_borg</code> risolve il binario da quattro fonti in ordine e restituisce il primo che funziona:",
"rows": [
{
"priority": "1",
"source": "Sistema <code>borg</code>",
"detail": "Se l'host ha già installato <code>borg</code> tramite APT (<code>which borg</code> risolve), questo binario viene utilizzato."
},
{
"priority": "2",
"source": "cache di stato",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — tenuto da un precedente download GitHub su questo host."
},
{
"priority": "3",
"source": "Pacchetto AppImage del Monitor",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — il AppImage fa un borg-linux64 firmato. Questo è il percorso offline: un host senza internet ha ancora un <code>borg</code> funzionante."
},
{
"priority": "4",
"source": "Scarica GitHub",
"detail": "<code>wget</code> contro l'URL pinned <code>borg-linux64</code> sotto <code>github.com/borgbackup/borg/releases/</code>, verificatosi contro una costante SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Su checksum sbagliato il binario viene scartato e il backup si interrompe. Il file scaricato viene memorizzato nella cache dello stato, quindi i backup successivi utilizzano il percorso 2."
}
]
},
"repoTypes": {
"heading": "Tipi di repository",
"intro": "Il tipo di repository viene scelto quando viene aggiunto un obiettivo. Ogni tipo si risolve in un altro URL di repository che Borg capisce.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "Repository vive su un server remoto che esegue <code>borg serve</code>. Richiede una connessione SSH a quel server."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "Il repository vive su un disco esterno montato (tipicamente USB). Il montaggio viene risolto tramite <code>hb_prompt_mounted_path</code>, che rileva, monta o formatta le partizioni USB come necessario."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "Repository vive su una directory locale. Significativo solo quando la directory di destinazione è su un disco fisico separato — un repository sullo stesso disco della fonte protegge dall'errore dell'operatore, ma non dall'errore del disco."
}
]
},
"serverSetup": {
"heading": "Preparazione del server Borg (lato server)",
"intro": "Il tipo di repository <code>remote</code> richiede un server Borg funzionante e accessibile via SSH. ProxMenux non configura il server: autorizza soltanto una chiave per un account esistente. Questa sezione descrive i requisiti del server prima della connessione.",
"hostChoicesTitle": "Dove il server può vivere",
"hostChoicesBody": "Qualsiasi host Linux con accesso SSH si qualifica. Configurazioni comuni:",
"hostChoicesItems": [
"Un NAS dedicato o una scatola di backup (Debian, Ubuntu, TrueNAS SCALE con una shell).",
"Un contenitore LXC all'interno di un nodo Proxmox. Piccola impronta, isolata dall'host che esegue i backup.",
"Un altro host Proxmox sulla stessa LAN, o un VM ovunque raggiungibile tramite SSH."
],
"lxcWarningTitle": "LXC come server Borg",
"lxcWarningBody": "Se il server Borg è in un LXC, generate-auto richiede un account che accetti l’autenticazione SSH con password per installare la chiave. In alternativa, usa l’installazione manuale o generate-pct tramite l’host PVE.",
"requirementsTitle": "Requisiti sul server",
"requirementsRows": [
{
"requirement": "Eseguibile borg in <code>/usr/bin/borg</code>",
"detail": "La riga <code>command=\"/usr/bin/borg serve ...\"</code> scritta da ProxMenux in <code>authorized_keys</code> usa questo percorso fisso. APT (<code>apt install borgbackup</code>) installa lì l’eseguibile. Per un binario autonomo occorre un collegamento simbolico in <code>/usr/bin/borg</code>."
},
{
"requirement": "Un account utente dedicato (tipicamente <code>borg</code>)",
"detail": "Possiede la directory del repository e riceve connessioni SSH in arrivo. Non ha bisogno di sudo o di accesso alla shell — la linea authorized_keys disabilita comunque le shell interattive."
},
{
"requirement": "Una directory di repository writable",
"detail": "Il percorso che l'operatore dà a ProxMenux (ad esempio <code>/backup/borgbackup</code>) deve esistere sul server ed essere di proprietà dell'utente borg."
},
{
"requirement": "SSH daemon accetta l'utente borg",
"detail": "<code>PubkeyAuthentication yes</code> (default). L'autenticazione della password è necessaria solo per il flusso <em>generate-auto</em> di un colpo — dopo l'installazione della chiave, il server può disabilitare completamente la password."
}
],
"minimalSetupTitle": "Configurazione server Minimal",
"minimalSetupBody": "Su un server Debian o Ubuntu Borg, una linea base di lavoro è quattro comandi come root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Con il server pronto e l’autenticazione SSH con password disponibile, <code>generate-auto</code> installa la chiave tramite un account che possa scrivere in authorized_keys dell’utente borg. I backup successivi usano questa chiave, limitata a <code>borg serve</code> sul percorso configurato. Senza accesso con password, installala manualmente o tramite l’host PVE."
},
"sshAuth": {
"heading": "Autenticazione SSH (lato cliente)",
"intro": "I repository Borg remoti sono accessibili su SSH. La connessione viene eseguita dall'host ProxMenux a un account utente sul server Borg che esegue <code>borg serve</code>. Questo utente è tipicamente chiamato <code>borg</code>, NON l'utente admin/root del server — la linea di comando borg-serve blocca la connessione a quel percorso di repository specifico (vedere le strategie chiave qui sotto).",
"strategiesTitle": "Strategie per le chiavi SSH",
"strategiesIntro": "Aggiungendo una destinazione remota, ProxMenux chiede utente SSH, host e percorso remoto, poi offre quattro opzioni di autenticazione. Se l’accesso con password viene rifiutato, propone anche generate-pct. Le modalità sono descritte di seguito:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Consigliato",
"detail": "ProxMenux genera o riutilizza una coppia di chiavi ed25519 in <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, poi usa <code>sshpass</code> per verificare l’accesso e installare la chiave pubblica in <code>~borg/.ssh/authorized_keys</code>. La password appartiene a un account che possa scrivere il file, solitamente root o borg. Serve durante la configurazione e non viene salvata."
},
{
"mode": "generate-manual",
"label": "Nessuna password di amministratore su questo host",
"detail": "ProxMenux genera il keypair come sopra ma visualizza la linea completa <code>authorized_keys</code> per l'operatore di incollare manualmente nel server. La password di amministratore non lascia mai l'host ProxMenux perché non viene mai chiesto."
},
{
"mode": "generate-pct",
"label": "Il server Borg è un PVE LXC",
"detail": "Il server Borg viene eseguito all'interno di un LXC su un nodo PVE. ProxMenux autorizza la chiave tramite <code>pct exec</code> dall'host PVE — root sull'host PVE scrive nel LXC <code>~borg/.ssh/authorized_keys</code> senza bisogno di SSH nel LXC stesso."
},
{
"mode": "existing",
"label": "Utilizzare una chiave esistente",
"detail": "ProxMenux scansiona <code>/root/.ssh/</code> e <code>$HOME/.ssh/</code> per le chiavi private parseable ed25519/RSA e le elenca. L'operatore sceglie uno o naviga manualmente su un percorso non standard."
},
{
"mode": "none",
"label": "Configurazione predefinita SSH",
"detail": "Nessuna chiave personalizzata — Borg si basa sulla configurazione predefinita SSH dell'host (tipicamente <code>~/.ssh/id_rsa</code> o un agente SSH)."
}
],
"restrictTitle": "La linea authorized_keys",
"restrictBody": "Per ogni chiave generata, la riga <code>authorized_keys</code> scritta da ProxMenux sul server limita la chiave a questa invocazione di borg-serve sul percorso configurato del repository:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "Il <code>command=</code> costringe ogni sessione SSH utilizzando questa chiave per eseguire solo il comando borg-serve; <code>restrict</code> disabilita l'inoltro della porta, l'inoltro dell'agente, l'inoltro di X11 e l'allocazione di PTY. La chiave non può essere utilizzata per aprire una shell interattiva sul server o per accedere a qualsiasi altro percorso di repository, anche se l'account ha privilegi più ampi."
},
"savedTargets": {
"heading": "Obiettivi salvati",
"intro": "Una destinazione salvata conserva la configurazione del repository con un nome riconoscibile, evitando di reinserire i dati. File nella directory di stato di ProxMenux:",
"rows": [
{
"file": "borg-targets.txt",
"content": "Una riga per destinazione: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> la legge per compilare il menu di selezione delle destinazioni."
},
{
"file": "borg-pass-NAME.txt",
"content": "Passphrase della destinazione indicata sopra come NAME (<code>chmod 600</code>). Presente soltanto se è stata scelta la crittografia repokey."
}
],
"outro": "Salvare la destinazione è facoltativo. Rifiutando non si salva la configurazione con nome, ma una chiave SSH generata non viene eliminata. Se si attiva repokey senza salvare la destinazione, ProxMenux conserva comunque la passphrase nel file preesistente borg-pass.txt."
},
"encryption": {
"heading": "Crittografia",
"body": "I repository sono inizializzati con una modalità di crittografia tramite <code>hb_borg_init_if_needed</code>: il moderno <code>borg repo-create -e MODE</code> quando disponibile, o il <code>borg init --encryption=MODE</code> legacy. ProxMenux espone due modalità: <code>repokey</code> (default) e <code>none</code>. In modalità <code>repokey</code> Borg memorizza la chiave di cifratura all'interno del repository stesso; l'accesso richiede una passphrase, che ProxMenux richiede due volte con verifica della corrispondenza e salva in <code>borg-pass-NAME.txt</code> per le destinazioni salvate, altrimenti nel file precedente descritto sopra. Una finestra di dialogo di riconoscimento obbligatoria viene mostrata dopo che il passphrase viene salvato: il passphrase è l'unico modo per accedere agli archivi crittografati, e perderlo rende ogni archivio nel repository non recuperabile."
},
"runtimeEnv": {
"heading": "Ambiente runtime",
"intro": "ProxMenux esporta le seguenti variabili ambientali prima di invocare <code>borg</code>. Configurano la connessione e sbloccano il repository senza inserire segreti nella riga di comando.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Comando remoto usato da Borg per i repository SSH. Una chiave selezionata aggiunge le opzioni di identità; una porta non standard aggiunge -p PORT. Senza chiave personalizzata e con la porta predefinita, la variabile resta non impostata e Borg usa la configurazione SSH dell’host."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passphrase da borg-pass-NAME.txt)",
"purpose": "Sblocca il repokey. Impostare solo quando il target utilizza la crittografia <code>repokey</code>. Non compare mai nell'elenco degli argomenti di processo."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Utilizzato da <code>hb_borg_init_if_needed</code> quando inizializza un repository che non esiste ancora. Ignorato da <code>borg create</code> su repository esistenti."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Supprime il prompt interattivo Borg solleva quando l'URL del repository differisce dall'URL che originariamente è stato raggiunto da (comune dopo un rinominamento del punto di montaggio o SSH-host raggiungibile tramite nuovo indirizzo)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suppresse il prompt interattivo Borg solleva la prima volta che un repository non crittografato è accessibile da un nuovo client."
}
]
},
"archiveFormat": {
"heading": "Archivio denominazione e ritenzione",
"intro": "Ogni backup crea un nuovo archivio all'interno del repository.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "Per i lavori programmati, <code>run_scheduled_backup.sh</code> esegue <code>borg prune</code> contro il repository dopo ogni backup di successo con i valori di ritenzione configurati sul lavoro (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). I backup interattivi non eliminano le vecchie copie."
},
"restoreAccess": {
"heading": "Recuperare sul lato del ripristino",
"body": "Il flusso di ripristino elenca gli archivi con <code>borg list REPO</code> ed estrae quello selezionato con <code>borg extract REPO::ARCHIVE-NAME</code> in una directory di staging che <code>_rs_check_layout</code> si alimenta alla pipeline di ripristino standard. Per il recupero manuale al di fuori di ProxMenux gli stessi comandi funzionano; l'albero estratto è il layout standard a tre payload descritto in <em>Come funziona </em>."
},
"references": {
"heading": "Referenze",
"intro": "Documentazione ufficiale di Borg per i componenti usati da ProxMenux.",
"items": [
{
"label": "Documentazione del Borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": "— punto di ingresso principale che copre concetti, distribuzione, avvio rapido e ogni comando."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " — il comando usato da ProxMenux per ogni backup, con tutte le opzioni supportate."
},
{
"label": "Crittografia del repository",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": "— le modalità di crittografia Borg supporta, incluso il repokey che ProxMenux utilizza per impostazione predefinita."
},
{
"label": "borg serve e configurazione tramite SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — configurazione di un server Borg centrale accessibile via SSH, con il comando borg-serve e l’opzione restrict-to-path che ProxMenux scrive in authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — il modello di conservazione di --keep-last / --keep-daily / --keep-weekly che ProxMenux applica a ogni attività pianificata."
}
]
}
}
web/messages/it/docs/backup-restore/destinations/index.json
+110
View File
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Destinazioni di backup — Locale, Proxmox Backup Server, Borg | ProxMenux",
"description": "Tre backend di storage ricevono lo stesso payload di backup ProxMenux: un archivio locale .tar.zst su qualsiasi filesystem scrivibile, un backup PBS in un datastore Proxmox Backup Server o un archivio Borg in un repository Borg locale o remoto. Ogni backend ha le proprie caratteristiche di compressione, deduplicazione, crittografia e rete.",
"ogTitle": "Destinazioni di backup ProxMenux",
"ogDescription": "Locale, Proxmox Backup Server e Borg — tre backend di archiviazione per lo stesso carico di backup host.",
"twitterTitle": "Destinazioni di backup ProxMenux | ProxMenux",
"twitterDescription": "Archivio locale, backend Proxmox Backup Server e Borg per i backup host."
},
"header": {
"title": "Destinazioni",
"description": "Tre backend di storage supportati da ProxMenux Backup: archivio locale, Proxmox Backup Server (consigliato) e Borg. Ognuno riceve lo stesso archivio con tre blocchi di dati; differiscono in formato di archiviazione, deduplicazione, modello di crittografia e requisiti di rete.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Stesso contenuto, tre backend",
"body": "Ogni backup produce gli stessi tre payload (rootfs, manifest, applicazioni). Ciò che cambia tra le destinazioni è il modo in cui questi carichi sono memorizzati e come l'operatore li recupera per un ripristino. Ogni backend viene implementato come funzione separata in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — ma tutti e tre condividono lo stesso passo di staging (<code>hb_prepare_staging</code>) e lo stesso percorso del codice di ripristino. La scelta della destinazione colpisce solo la scrittura e il recupero; non cambia ciò che un ripristino fa o come consuma l'archivio."
},
"comparison": {
"heading": "Confronto delle caratteristiche",
"intro": "La tabella seguente elenca le differenze concrete tra i tre backend come si comportano oggi in ProxMenux. Tutti i valori descrivono il comportamento osservato del backend stesso, non raccomandazioni editoriali.",
"rows": [
{
"feature": "Formato di archiviazione",
"local": "File <code>.tar.zst</code> singolo (o <code>.tar.gz</code> se <code>zstd</code> è assente).",
"pbs": "Backup PBS (blocchi <code>.pxar</code> nel datastore).",
"borg": "Archivio Borg all'interno di un repository Borg (file di segmento)."
},
{
"feature": "Compressione",
"local": "zstd (livello predefinito) tramite <code>tar --zstd</code>. gzip fallback.",
"pbs": "Gestita da proxmox-backup-client. ProxMenux non modifica le impostazioni di compressione.",
"borg": "Compressione integrata di Borg. ProxMenux richiama borg create senza modificare le impostazioni di compressione."
},
{
"feature": "Deduplicazione",
"local": "Nessuno. Ogni backup è un archivio completamente indipendente.",
"pbs": "Deduplicazione completa a livello di blocchi tra tutti i backup nel datastore.",
"borg": "Deduplicazione completa a livello di blocchi tra tutti gli archivi del repository."
},
{
"feature": "Crittografia a riposo",
"local": "Nessuno (si basa sulla protezione a livello di filesystem).",
"pbs": "Crittografia opzionale lato client mediante un file di chiave. Se abilitata, il blob di recupero viene caricato in un gruppo di backup separato.",
"borg": "Crittografia repokey opzionale (chiave memorizzata nel repo, sbloccata da una passphrase)."
},
{
"feature": "Conservazione / eliminazione delle vecchie copie",
"local": "Applicata a ogni attività pianificata tramite <code>KEEP_LAST</code>. I vecchi archivi vengono eliminati insieme ai file ausiliari e ai log di esecuzione. I backup interattivi non eliminano le vecchie copie.",
"pbs": "Applicato per lavoro programmato tramite <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. I backup interattivi non eliminano le vecchie copie.",
"borg": "Applicato per lavoro programmato tramite <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. I backup interattivi non eliminano le vecchie copie."
},
{
"feature": "Rete",
"local": "Nessuno. Scrive a un punto di montaggio locale (tipicamente un disco interno o un'unità USB).",
"pbs": "TCP al server PBS (porta di default 8007). Richiede credenziali PBS + impronta digitale.",
"borg": "percorso filesystem locale o tunnel SSH a un host Borg remoto."
},
{
"feature": "Dipendenze",
"local": "<code>tar</code>, <code>zstd</code> (presente su Proxmox per impostazione predefinita).",
"pbs": "Pacchetto <code>proxmox-backup-client</code> (incluso in Proxmox VE 8+).",
"borg": "binario <code>borg</code>. Auto-provisionato da ProxMenux dal pacchetto Monitor AppImage quando manca."
},
{
"feature": "Accesso per il ripristino",
"local": "Qualsiasi host con tar+zstd può estrarre l'archivio. Non è necessario PBS/Borg.",
"pbs": "Richiede <code>proxmox-backup-client</code>, le credenziali PBS e il file di chiave (se il backup è crittografato).",
"borg": "Richiede <code>borg</code> + il percorso del repository + la passphrase (se crittografato)."
}
],
"captionCode": "feature",
"captionLocal": "Locale",
"captionPbs": "Proxmox Backup Server (consigliato)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "Il layout dell'archivio non cambia con la destinazione",
"body": "All'interno di una delle tre destinazioni, lo stesso layout <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descritto in <em>Come funziona</em> è presente. Un <code>.tar.zst</code> estratto da un archivio locale, un <code>.pxar</code> restaurato da PBS, e un archivio Borg estratto con <code>borg extract</code> producono tutti un albero di directory identico. Il percorso del codice di ripristino (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano."
},
"extractStandalone": {
"heading": "Estrazione di un backup al di fuori di ProxMenux",
"intro": "Tutti i tre formati di archivio possono essere letti con strumenti standard senza ProxMenux installati sull'host di lettura. I comandi sottostanti producono lo stesso albero di directory che un ripristino consuma internamente.",
"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": "# Da un archivio Borg (richiede borg e la passphrase per i repository crittografati):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Su un repository remoto accessibile via SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "L'albero estratto può quindi essere ispezionato manualmente o alimentato a un ripristino manuale. Vedere le singole pagine di destinazione per l'esatto flusso di recupero ProxMenux utilizza sotto il cofano."
},
"whereNext": {
"heading": "Dettagli per destinazione",
"intro": "Ogni destinazione ha una propria pagina che copre il flusso di configurazione, il formato on-disk e il comando di recupero utilizzato dal ripristino.",
"items": [
{
"label": "Archivio locale",
"href": "/docs/backup-restore/destinations/local",
"tail": "— preconfigurazione di un target locale, montaggio dell'unità USB, controllo di sicurezza contro la scrittura dell'archivio in sé, la sidecar JSON che consente al Monitor di identificare il file."
},
{
"label": "Proxmox Backup Server (consigliato)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": "— selezione di datastore, credenziali e impronte digitali, ciclo di vita del keyfile di crittografia, passphrase di recupero, caricando il blob di recupero a PBS per il recupero di installazione fresca."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — repository locali o accessibili via SSH, provenienza del binario Borg (sistema / cache / pacchetto AppImage di Monitor / download GitHub), inizializzazione del repository, gestione delle passphrase e configurazione delle chiavi SSH per i repository remoti."
}
]
}
}
web/messages/it/docs/backup-restore/destinations/local.json
+75
View File
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Destinazione dell'archivio locale — tar.zst su un filesystem o unità USB | ProxMenux",
"description": "La destinazione di backup locale scrive un singolo archivio .tar.zst a qualsiasi directory scrivibile: un disco interno, un punto di montaggio Proxmox, una condivisione NFS o un'unità USB. Documenta il flusso di configurazione, la logica di rilevamento e montaggio USB, il controllo di sicurezza contro la scrittura dell'archivio in un percorso incluso nel backup, e il file ausiliario JSON che identifica il file.",
"ogTitle": "ProxMenux Backup — Destinazione dell'archivio locale",
"ogDescription": "Come ProxMenux scrive i backup locali come archivi .tar.zst e come configurare la directory di destinazione o unità USB.",
"twitterTitle": "Destinazione di backup locale | ProxMenux",
"twitterDescription": "Come ProxMenux scrive i backup locali come archivi .tar.zst su un filesystem o unità USB."
},
"header": {
"title": "Archivio locale",
"description": "La destinazione locale scrive un unico archivio tar compresso in una directory scrivibile sull’host: su un disco interno, un filesystem NFS o SMB montato oppure un’unità USB.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Un file, autocontenuto",
"body": "Un backup locale produce un singolo file <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (o <code>.tar.gz</code> quando <code>zstd</code> è assente). Il file contiene l'intero albero di archivio — <code>manifest.json</code>, <code>metadata/</code> e <code>rootfs/</code> — e può essere ripristinato su qualsiasi host Proxmox con il flusso di ripristino ProxMenux o estratto manualmente con <code>tar --zstd -xf</code> su qualsiasi sistema Linux. Nessun server, nessuna inizializzazione del repository, nessuna dipendenza esterna. Questa è la destinazione con il percorso di recupero più breve quando non è disponibile né PBS né Borg."
},
"targetConfig": {
"heading": "Configurazione della directory target",
"intro": "La destinazione locale è una <strong>unica directory di destinazione salvata in modo persistente</strong> — non un elenco. ProxMenux memorizza la scelta dell'operatore su <code>/usr/local/share/proxmenux/local-target.conf</code> e la legge su ogni backup. Quando non è stato configurato alcun obiettivo, viene utilizzato il <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> predefinito (la stessa directory Proxmox utilizza per le proprie uscite <code>vzdump</code>). L'obiettivo è configurato da <em>Configura destinazioni di backup → Destinazioni locali</em>:",
"options": [
"<strong>Utilizzo predefinito (<code>/var/lib/vz/dump</code>).</strong> Lo storage locale Proxmox. Presente su ogni installazione Proxmox; l'archivio si trova accanto alle uscite vzdump e viene ritirato dalla scheda Monitor Backups automaticamente.",
"<strong>Inserisci un percorso personalizzato.</strong> Puoi usare qualsiasi percorso assoluto del filesystem: un montaggio NFS, una condivisione SMB montata tramite <code>fstab</code>, un dataset ZFS dedicato o un secondo disco interno. Prima di salvarlo, ProxMenux verifica che il percorso esista e sia una directory.",
"<strong>Scegli un’unità USB.</strong> Apre il sottomenu USB (sotto), che rileva dispositivi rimovibili e offre di montare o formattarne uno."
]
},
"usbFlow": {
"heading": "Rilevamento dell'unità USB e montaggio",
"intro": "Il sottomenu USB elenca le partizioni su dispositivi rimovibili segnalate da <code>lsblk</code>. Ogni partizione è presentata con la sua dimensione, l'etichetta del filesystem e lo stato corrente. Lo stato determina l’azione proposta da ProxMenux.",
"statesTitle": "I tre stati del dispositivo",
"stateRows": [
{
"state": "montato",
"shown": "Dimensione · etichetta · [fstype] · → /mount/point",
"action": "La partizione è già montata da qualche parte. La selezione salva il punto di montaggio corrente come obiettivo locale. Nessun montaggio viene eseguito."
},
{
"state": "non montato",
"shown": "Dimensione · etichetta · [fstype] · (non montato — sarà montato)",
"action": "Un filesystem è presente ma non montato. A conferma, ProxMenux gestisce <code>hb_mount_usb_partition</code>: crea <code>/mnt/backup-LABEL</code> (o un percorso basato su UUID se non c'è etichetta), monta la partizione e persiste il punto di montaggio come obiettivo locale."
},
{
"state": "vuoto",
"shown": "Dimensione · disco USB grezzo — nessun filesystem (verrà FORMATTATO)",
"action": "Il dispositivo non ha un filesystem. Questa operazione distruttiva è protetta da due conferme. Prima una finestra Sì/No spiega che il disco verrà cancellato. Poi una casella di input richiede di <strong>digitare il percorso esatto del dispositivo</strong> (ad esempio <code>/dev/sdb</code>) prima che ProxMenux crei una nuova tabella GPT con una partizione ext4 e la monti."
}
],
"notMountedFallback": "Quando non viene rilevato alcun dispositivo USB, il submenu rientra in una semplice casella di input. L'operatore può immettere un percorso di mount point arbitrario; se il percorso non è un punto di montaggio registrato, una finestra di dialogo di conferma avvisa prima di procedere."
},
"safetyCheck": {
"heading": "Controllo di sicurezza — destinazione all'interno di un percorso di backup",
"body": "Prima di scrivere l'archivio, <code>_bk_local</code> verifica che la directory di destinazione sia <strong>non</strong> un sottopercorso di qualsiasi directory di cui viene eseguito il backup. Un errore comune sarebbe aggiungere <code>/root</code> al profilo e scegliere <code>/root/backups</code> come destinazione: l'archivio quindi includerebbe se stesso, producendo un archivio corrotto o crescendo senza limiti finché il disco non si riempie. Il controllo risolve entrambi i percorsi con <code>readlink -m</code>, li confronta e, in caso di conflitto, interrompe il backup con una finestra di dialogo che nomina il percorso in conflitto ed elenca tre modi per risolverlo: scegliere una destinazione al di fuori del percorso in conflitto, rimuovere la voce personalizzata che contiene la destinazione o utilizzare la modalità personalizzata per deselezionare il percorso in conflitto per questa esecuzione."
},
"archiveFormat": {
"heading": "Formato archivio e compressione",
"intro": "Il nome del file di output include il nome host di origine e la data e ora del backup, per consentire l’ordinamento cronologico delle varie copie nella directory e identificare ogni file.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Compressione",
"compressionBody": "Il metodo principale usa <code>tar --zstd -cf</code>: un singolo comando che comprime al livello predefinito di zstd. Se <code>zstd</code> non è presente sull’origine (raro su Proxmox, ma possibile nelle installazioni minime), ProxMenux ripiega su <code>gzip</code>. In questo caso, se <code>pv</code> è disponibile, viene aggiunta una barra di avanzamento per mostrare la crescita dell’archivio in tempo reale; senza <code>pv</code>, viene usato il semplice <code>tar -czf</code> senza output di avanzamento.",
"sourceTitle": "Cosa viene incluso nell’archivio",
"sourceBody": "Il comando tar viene richiamato con <code>-C \"$staging_root\" .</code> e archivia <strong>l’intera radice della directory temporanea</strong>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code>. I tre blocchi di dati si trovano affiancati al livello superiore dell’archivio tar. L’estrazione produce esattamente lo stesso albero utilizzato dal codice di ripristino."
},
"sidecar": {
"heading": "Il sidecar JSON",
"intro": "Ogni backup locale di successo produce un file compagno: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, scritto accanto all'archivio da <code>hb_write_archive_sidecar</code>. Questo piccolo file JSON consente a ProxMenux Monitor di identificare l'archivio come ProxMenux backup host anche se in seguito viene spostato, rinominato o archiviato altrove.",
"contentTitle": "Contenuto del sidecar",
"contentBody": "Il sidecar memorizza la versione schema, se il backup proveniva da un run interattivo o da un lavoro programmato (<code>kind</code>), l'ID di lavoro per le esecuzioni pianificate, la modalità profilo utilizzata (<code>default</code> o <code>custom</code>), il nome host sorgente, il nome base originale dell'archivio, un timestamp di creazione ISO-8601 e la dimensione dell'archivio in byte.",
"whyBody": "La scheda Backups di Monitor cerca i file ausiliari <code>*.proxmenux.json</code> nelle directory locali configurate, non i file <code>*.tar.zst</code>, perché un <code>.tar.zst</code> senza file ausiliario potrebbe non essere un backup ProxMenux. La scansione è veloce (i file JSON sono piccoli) e l’associazione resta valida quando l’archivio viene rinominato, purché anche il file ausiliario venga rinominato di conseguenza."
},
"restoreAccess": {
"heading": "Ripristino da un archivio locale",
"body": "Il flusso di ripristino ProxMenux scopre gli archivi locali scansionando l'obiettivo locale configurato per sidecars e visualizzandoli nell'elenco Archivi. Selezionando uno si attiva <code>_rs_check_layout</code>, che estrae il tarball in una directory di staging e conferma il layout a tre payload prima di procedere. Per estrazione manuale al di fuori di ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produce lo stesso albero che il codice di ripristino consuma."
}
}
web/messages/it/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -0,0 +1,113 @@
{
"meta": {
"title": "destinazione Proxmox Backup Server — repository, crittografia, ripristino | ProxMenux",
"description": "La destinazione PBS salva i backup host di ProxMenux come backup PBS. Descrive il rilevamento dei repository da /etc/pve/storage.cfg, la configurazione manuale, il caricamento .pxar, la crittografia lato client con file di chiave e la sua copia di recupero facoltativa protetta da passphrase, e il recupero della chiave da più fonti su un host appena installato.",
"ogTitle": "ProxMenux Backup — destinazione Proxmox Backup Server",
"ogDescription": "Come ProxMenux scrive i backup host a Proxmox Backup Server con la crittografia del keyfile lato client e l'escrow di recupero.",
"twitterTitle": "Destinazione di backup PBS | ProxMenux",
"twitterDescription": "Destinazione Proxmox Backup Server con crittografia tramite file di chiave e copia di recupero protetta da passphrase."
},
"header": {
"title": "Proxmox Backup Server",
"description": "La destinazione PBS carica l’intera directory di preparazione come un unico backup .pxar in un datastore Proxmox Backup Server, con crittografia facoltativa lato client tramite file di chiave. Facoltativamente, accanto a ogni backup viene caricata anche una copia della chiave protetta da passphrase per il recupero.",
"section": "Backup e ripristino"
},
"recommendedBadge": "Destinazione consigliata",
"aboutPbs": {
"heading": "Ciò che Proxmox Backup Server è",
"body": "Proxmox Backup Server (PBS) è il prodotto server di backup di Proxmox, sviluppato e mantenuto dallo stesso team che gli autori Proxmox VE. È un server di backup dedicato progettato per ricevere i backup da host Proxmox VE (VMs, LXCs e - via <code>proxmox-backup-client</code> - directory host arbitrari) con deduplicazione basata su blocchi, crittografia lato client e politiche di conservazione applicate lato server. ProxMenux utilizza PBS come una delle tre destinazioni per i backup host; ogni meccanismo specifico PBS descritto in questa pagina (gruppi di backup, archivi <code>.pxar</code>, <code>--backup-id</code>, crittografia keyfile) è un comportamento standard PBS."
},
"intro": {
"title": "Un backup per esecuzione, deduplicazione a livello di blocchi",
"body": "Un backup PBS crea una sola voce nel datastore, sotto l’ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. I dati sono un archivio <code>.pxar</code> con la stessa struttura in tre blocchi descritta in <em>Come funziona</em>. PBS deduplica i blocchi tra tutti i backup del datastore: i backup successivi dello stesso host trasferiscono e memorizzano soltanto i blocchi modificati. Per le attività pianificate, ProxMenux applica direttamente la conservazione: dopo ogni esecuzione riuscita, <code>run_scheduled_backup.sh</code> esegue <code>proxmox-backup-client prune</code> con <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> usando i valori configurati nell’attività."
},
"repoSelection": {
"heading": "Selezione dei repository",
"intro": "ProxMenux scopre i repository PBS da due fonti su ogni backup. L'operatore sceglie uno da un menu unificato; la scelta determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> per l'esecuzione.",
"sourceRows": [
{
"source": "storage.cfg di Proxmox (rilevamento automatico)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Ogni strofa <code>pbs:</code> nella configurazione di storage di Proxmox viene rilevata automaticamente. Server, datastore, nome utente e impronta digitale provengono dalla stanza. La password viene letta dalla directory delle credenziali di Proxmox. Nessun rientro necessario sul lato ProxMenux — il repository è disponibile non appena è configurato in Proxmox."
},
{
"source": "Configurazione manuale ProxMenux",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Aggiunto da <em>Configure destinazioni di backup → PBS destinazioni → Aggiungi PBS</em>. Prompts per un nome, nome utente (<code>root@pam</code> o <code>user@pbs!token</code>), host o IP, datastore e password. I re-prompt password su input vuoto — un salvataggio vuoto altrimenti persisterebbe silenziosamente e ogni backup successivo fallirebbe con un errore di autenticazione opaco. Questo percorso viene utilizzato quando il target PBS non è registrato come storage Proxmox."
}
],
"menuTitle": "Menu di selezione",
"menuBody": "Entrambe le fonti sono mostrate in un unico menu, ciascuna riga contrassegnata con la sua origine (<code>[proxmox]</code> o <code>[manual]</code>). Le voci di cui la password non poteva essere risolta sono contrassegnate con un avviso <code>⚠ no password</code> — selezionando uno attiva un rientro password prima dell'avvio del backup. L'impronta digitale viene passata a <code>proxmox-backup-client</code> tramite la variabile di ambiente <code>PBS_FINGERPRINT</code>; quando assente, il client chiede all'operatore di accettare il certificato del server in modo interattivo sul primo backup."
},
"backupCommand": {
"heading": "Il comando di backup",
"intro": "Il caricamento avviene con una sola invocazione di <code>proxmox-backup-client backup</code>. ProxMenux usa <code>env</code> per passare al client password, password di crittografia e impronta digitale come variabili d’ambiente.",
"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": "Nome ID di backup",
"backupIdBody": "L’ID di backup predefinito è <code>hostcfg-HOSTNAME</code>. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in <code>[A-Za-z0-9_-]</code> e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un <em>gruppo</em> e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.",
"pxarTitle": "Perché la fonte è la radice di staging completa",
"pxarBody": "La sorgente <code>.pxar</code> è l'intero <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> insieme. Le versioni precedenti hanno superato <code>$staging_root/rootfs</code> come fonte; che ha lasciato <code>metadata/</code> fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-<code>_rs_check_layout</code> di 3, che avvolge un albero <code>etc/var/root/usr</code> piatto di nuovo in una gerarchia <code>rootfs/</code>."
},
"encryption": {
"heading": "Crittografia lato cliente",
"glossaryHint": "Questa sezione usa i termini <em>file di chiave</em>, <em>passphrase</em> e <em>involucro di recupero</em>. Il <glosarioLink>glossario</glosarioLink> ne riassume le differenze con una frase per termine.",
"intro": "La crittografia PBS lato client con file di chiave cifra i blocchi sull’host di origine prima del caricamento. In ProxMenux è facoltativa. Se attivata, durante la configurazione l’operatore sceglie esplicitamente sì o no se caricare su PBS anche una copia di recupero del file di chiave protetta da passphrase; la scelta è modificabile in seguito dal Monitor. Il file di chiave risiede sempre nel percorso canonico <code>/usr/local/share/proxmenux/pbs-key.conf</code> e viene riutilizzato senza nuove richieste per ogni backup crittografato successivo.",
"keyfileTitle": "Impostazione del keyfile",
"keyfileBody": "Il dialogo di crittografia compare al primo backup crittografato dell’host. Prima chiede se crittografare il backup: <em>No</em> prosegue senza crittografia, <em>Sì</em> passa alla seconda fase. Questa dipende dalla presenza di un file di chiave in <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Se esiste, viene riutilizzato senza altre domande e il backup prosegue; i backup successivi non lo chiedono più. Altrimenti, un menu offre due opzioni. <em>Genera un nuovo file di chiave</em> esegue <code>proxmox-backup-client key create --kdf none</code>. <em>Usa un file di chiave esistente</em> rileva automaticamente una chiave gestita da PVE: se il repository PBS scelto è registrato in Proxmox con una chiave di crittografia in <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, il file viene copiato senza altre domande nel percorso canonico di ProxMenux. Se nessuna chiave PVE corrisponde al repository, viene richiesto il percorso assoluto dove l’operatore ha già collocato il file sull’host. In entrambi i casi, il file viene installato nel percorso canonico con <code>chmod 600</code>.",
"modesTitle": "Per-host o keyfile condiviso",
"modesIntro": "Entrambi i modelli sono supportati e nessuno è obbligatorio: l’operatore sceglie in base all’organizzazione dei propri host.",
"modesPerHostTitle": "File di chiave per host (predefinito)",
"modesPerHostBody": "Ogni host genera un proprio keyfile la prima volta che consente la crittografia PBS. L'isolamento è il massimo: compromettere il keyfile di un host non espone i backup di qualsiasi altro. Consigliato per flotte di produzione e per ambienti in cui gli host hanno diversi proprietari o confini di conformità.",
"modesSharedTitle": "Keyfile condiviso (importa su ogni host)",
"modesSharedBody": "Un master keyfile generato una volta e installato su ogni host tramite l’opzione <em>Usa un file di chiave esistente</em>. La gestione è più semplice: un singolo segreto per salvaguardare, e qualsiasi host può decifrare gli archivi di qualsiasi altro (utile per il consolidamento, le esercitazioni di ripristino cross-host o la verifica centralizzata di backup). Il trade-off è che una perdita del keyfile condiviso espone ogni host contemporaneamente. Raccomandato per homelabs e per flotte dove tutti gli host hanno lo stesso proprietario e il limite di fiducia.",
"recoveryTitle": "Caricare la chiave su PBS: decide l’operatore",
"recoveryBody": "Subito dopo la scelta del file di chiave, ProxMenux pone la domanda esplicita <em>Caricare la chiave su PBS?</em>, con due risposte. <strong>Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì.</strong> L’opzione predefinita è <em>No, conserva solo in locale</em>: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante <em>Scarica il file di chiave</em> del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo <em>Sì, carica</em>, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo <code>pbs-key.recovery.enc</code>. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.",
"blobUploadTitle": "Gruppo di backup abbinato su PBS",
"blobUploadBody1": "Quando la modalità escrow è <em>Sì, carica</em>, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in <code>-keyrecovery</code>. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. <strong>La busta non lascia mai l'host in plaintext</strong>: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
"envelopeSecurityTitle": "Caricare il file keyrecovery a PBS è un rischio di sicurezza?",
"envelopeSecurityBody": "Il file keyrecovery è crittografato in transito e a riposo. Il passphrase di recupero non lascia mai l'host: la crittografia avviene localmente prima del caricamento, e PBS vede solo il risultato già crittografato. Un amministratore PBS — o chiunque abbia accesso al datastore — può scaricare il file di keyrecovery, ma senza la passphrase di recupero non può leggere il keyfile all'interno: è un codice opaco. Ricostruire il keyfile richiede entrambi i pezzi contemporaneamente, il file keyrecovery e la passphrase, e solo l'operatore tiene entrambi.",
"blobUploadConstraintTitle": "Perché servono due gruppi anziché un unico gruppo crittografato",
"blobUploadConstraintBody": "Una singola invocazione di <code>proxmox-backup-client backup</code> cifra tutti i suoi archivi con lo stesso file di chiave oppure nessuno: non è possibile mescolare i due casi. Il backup host deve essere cifrato con la chiave dell’host, ma l’involucro di recupero non può accompagnarlo nello stesso caricamento, perché verrebbe cifrato con la chiave che contiene. Su un host appena reinstallato non sarebbe possibile aprirlo: servirebbe la chiave per decifrare la chiave stessa. Per questo i due elementi vengono caricati indipendentemente e appaiono in due gruppi. Il client PBS cifra il backup host con il file di chiave, mentre ProxMenux cifra l’involucro con la passphrase prima del caricamento. Due livelli di crittografia diversi proteggono due elementi distinti.",
"blobUploadImageAlt": "PBS UI che mostra i gruppi di backup hostcfg-HOSTNAME e hostcfg-HOSTNAME-keyrecovery adiacenti nell'elenco dei datastore.",
"blobUploadImageCaption": "PBS UI — i gruppi di backup accoppiati. Il gruppo principale contiene i backup host; il gruppo -keyrecovery detiene il keyfile passphrase-wrapped.",
"recoverTitle": "Recupero su un host fresco",
"recoverBody": "Quando il file di chiave manca nel percorso canonico, dopo una reinstallazione o una rimozione esplicita, il ripristino prova tre fonti in ordine e si ferma alla prima che fornisce una chiave utilizzabile. Prima, se il repository PBS selezionato ha una chiave corrispondente gestita da PVE in <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo <code>-keyrecovery</code>, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce <code>wrong key — manifest's key XX does not match provided key YY</code>. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.",
"monitorManagementTitle": "Gestione del keyfile dal Monitor",
"monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: <em>Scarica</em> esporta il file attuale nel browser; <em>Carica</em> sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; <em>Elimina</em> rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce."
},
"restoreAccess": {
"heading": "Recuperare sul lato del ripristino",
"body": "Il ripristino individua i backup host ProxMenux su PBS elencando i gruppi del repository configurato e filtrandoli per modello dell’ID. La scheda Backup del Monitor mostra lo stesso elenco. Scegliere un backup esegue <code>proxmox-backup-client restore</code> con gli stessi repository, password e impronta, oltre a <code>--keyfile</code> se il backup è crittografato. L’archivio <code>.pxar</code> viene estratto in una directory di preparazione che <code>_rs_check_layout</code> passa al normale processo di ripristino. Fuori da ProxMenux, lo stesso comando estrae l’archivio nel percorso desiderato per esaminare l’albero o procedere a un ripristino manuale."
},
"references": {
"heading": "Referenze",
"intro": "Documentazione ufficiale di Proxmox Backup Server per i componenti usati da ProxMenux.",
"items": [
{
"label": "Documentazione Proxmox Backup Server",
"href": "https://pbs.proxmox.com/docs/",
"tail": "— punto di ingresso principale che copre l'installazione, l'amministrazione, lo stoccaggio, gli utenti e i ruoli."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — lo strumento da riga di comando che ProxMenux usa per ogni backup e ripristino. Descrive ID e tipi di backup, archivi, sintassi dei repository e variabili d’ambiente."
},
{
"label": "Crittografia lato cliente",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — creazione del file di chiave, modalità --kdf e modello di crittografia che ProxMenux estende con una copia di recupero protetta da passphrase."
},
{
"label": "Gestione dei datastore",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": "— la creazione e la gestione dei datastores che ricevono i backup degli host, incluso il layout di chunk-store e le autorizzazioni."
},
{
"label": "Eliminazione delle vecchie copie e garbage collection",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — il modello di conservazione di --keep-last / --keep-daily / --keep-weekly che ProxMenux applica a ogni attività pianificata, e il recupero dei blocchi inutilizzati da parte di PBS dopo l’eliminazione delle vecchie copie."
}
]
}
}
web/messages/it/docs/backup-restore/glossary.json
+230
View File
@@ -0,0 +1,230 @@
{
"meta": {
"title": "Glossario — Backup & Ripristino | ProxMenux",
"description": "Glossario di termini e definizioni per lo stack di backup e ripristino ProxMenux: crittografia, keyfile, passphrase, busta di recupero, PBS, chunks, rootfs, manifesto, runner e cross-kernel idratazione.",
"ogTitle": "Backup & ripristino glossario | ProxMenux",
"ogDescription": "Definizioni chiare per il vocabolario utilizzato attraverso la documentazione di backup e ripristino ProxMenux.",
"twitterTitle": "Backup & ripristino glossario | ProxMenux",
"twitterDescription": "Passphrase, keyfile, busta di recupero, rootfs, manifesto, PBS, chunks — tutto definito in un unico luogo."
},
"header": {
"title": "Glossario",
"description": "Termini utilizzati attraverso la documentazione di backup e ripristino, con la loro definizione.",
"section": "Backup e ripristino"
},
"intro": {
"body": "I termini sono raggruppati per tema. Ogni voce dà il termine e una breve definizione."
},
"groups": [
{
"title": "Crittografia e recupero chiave",
"intro": "Vocabolario per il blocco di crittografia PBS. Si tratta di due segreti distinti: un keyfile binario e un passphrase scritto.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Passphrase di ripristino",
"def": "Password di testo che l'utente sceglie per proteggere la <a href=\"#sobre-recuperacion\">busta di recupero</a>. Viene richiesto due volte con un controllo match, ed è utilizzato solo per crittografare la busta e decifrarla se il keyfile ha bisogno di essere recuperato. <strong>Non è la passphrase che sblocca il keyfile stesso</strong>, e non viene mai inviata a PBS. Durante un backup normale non lascia mai l'host."
},
{
"id": "clave-cifrado",
"term": "Keyfile (chiave di crittografia)",
"def": "File di chiave usato da proxmox-backup-client per cifrare i <a href=\"#chunk\">blocchi</a> prima dell’invio a PBS. Senza la chiave corrispondente i dati cifrati non sono leggibili. ProxMenux lo salva in <code>/usr/local/share/proxmenux/pbs-key.conf</code> con modalità <code>600</code>. Proteggilo: la <a href=\"#sobre-recuperacion\">busta di recupero</a> serve a recuperarlo in caso di perdita."
},
{
"id": "contrasena-keyfile",
"term": "Passphrase Keyfile (KDF passphrase)",
"def": "Passphrase opzionale che il keyfile stesso può trasportare, distinto dal <a href=\"#passphrase-recuperacion\">passphrase di recupero</a>. Esiste solo quando il keyfile è stato creato con <code>--kdf scrypt</code> (tipicamente un keyfile importato). Senza di esso, il keyfile non può essere sbloccato per l'uso. ProxMenux persiste in forma crittografata sull'host in modo che i backup programmati possano funzionare senza un prompt interattivo."
},
{
"id": "sobre-recuperacion",
"term": "Busta di recupero",
"def": "Il <a href=\"#clave-cifrado\">keyfile</a> avvolto in uno strato aggiuntivo: viene crittografato con il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a> utilizzando <a href=\"#aes-256-cbc\">AES-256-CBC</a> e <a href=\"#pbkdf2\">PBKDF2</a> prima che lasci l'host. È ciò che viene caricato su PBS come gruppo <code>-keyrecovery</code>. Senza la passphrase, la busta è opaca: scaricarla da PBS non rivela il keyfile."
},
{
"id": "cifrado-cliente",
"term": "Crittografia lato cliente",
"def": "Modello di crittografia in cui i dati vengono crittografati sull'host sorgente prima di essere caricati. PBS riceve solo e memorizza il testo cifrario; nemmeno un amministratore PBS con accesso al datastore può leggerlo senza il keyfile. ProxMenux si basa su questo modello e aggiunge la <a href=\"#sobre-recuperacion\">busta di recupero</a> in cima."
},
{
"id": "kdf-none",
"term": "--kdf none",
"def": "Opzione a <code>proxmox-backup-client key create</code> che produce un keyfile senza passphrase allegato. Il keyfile può essere utilizzato direttamente senza un prompt, che è essenziale per i lavori programmati in esecuzione incustodito. Questo è ciò che ProxMenux utilizza per impostazione predefinita quando si genera un nuovo keyfile."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"def": "Opzione a <code>proxmox-backup-client key create</code> che produce un keyfile protetto da un <a href=\"#contrasena-keyfile\">passphrase del file di chiave</a>. Ogni utilizzo del keyfile richiede di sbloccarlo con quel passphrase. ProxMenux accetta questo stile di keyfile sull'importazione e memorizza il passphrase crittografato in modo che i backup programmati possano ancora essere eseguiti incustoditi."
},
{
"id": "aes-256-cbc",
"term": "AES-256-CBC",
"def": "Cifra simmetrica standard. ProxMenux lo utilizza (tramite <code>openssl enc -aes-256-cbc</code>) per avvolgere il <a href=\"#clave-cifrado\">keyfile</a> con il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a> e produrre il <a href=\"#sobre-recuperacion\">busta</a>."
},
{
"id": "pbkdf2",
"term": "PBKDF2",
"def": "Funzione crittografica che trasforma un passphrase di tipo umano in una chiave binaria adatta alla crittografia. Rallenta i tentativi di forza bruta applicando molte iterazioni. ProxMenux lo utilizza con iterazioni 600 000 e un sale casuale durante la crittografia della busta di recupero."
}
]
},
{
"title": "Struttura di backup",
"intro": "Termini che descrivono cosa vive all'interno di un backup, indipendentemente dalla destinazione.",
"entries": [
{
"id": "rootfs",
"term": "rootfs / filesystem radice",
"def": "Copia dei file dell’host sorgente prodotta da <code>rsync</code> secondo il <a href=\"#perfil-defecto\">profilo predefinito</a> e i <a href=\"#rutas-personalizadas\">percorsi personalizzati</a>. Non è un’immagine dell’intero disco: vengono copiati solo percorsi con configurazione o stato che Proxmox non può rigenerare da sé."
},
{
"id": "manifiesto",
"term": "Manifesto (manifest.json)",
"def": "Documento strutturato JSON che descrive l'host sorgente in tempo di backup: hardware, storage, kernel, componenti ProxMenux installati e inventario di VM e LXC. È prodotto da sei raccoglitori di dati indipendenti. Il flusso di ripristino lo utilizza per confrontare sorgente e obiettivo."
},
{
"id": "staging",
"term": "Directory di preparazione",
"def": "directory temporanea in cui ProxMenux assembla i tre blocchi (rootfs, metadati e manifest) prima di imballarli e caricare alla destinazione. Viene rimosso automaticamente quando il backup termina, anche abortito."
},
{
"id": "perfil-defecto",
"term": "Profilo predefinito",
"def": "Set di percorsi che ProxMenux copia per impostazione predefinita in ogni backup. Copre PVE config, rete, SSH, kernel, apt, strumenti ProxMenux e altro ancora. È definito in codice e documentato sul <em>Come funziona</em> pagina."
},
{
"id": "rutas-personalizadas",
"term": "Percorsi personalizzati",
"def": "Percorsi extra l'utente aggiunge in cima al profilo <a href=\"#perfil-defecto\">default</a>. O persistente (conservato in <code>backup-extra-paths.txt</code>) o per-run (in modalità personalizzata)."
}
]
},
{
"title": "Destinazioni e stoccaggio",
"intro": "Termini legati a dove il backup atterra — server PBS, archivio locale o repository Borg — e come PBS organizza i dati.",
"entries": [
{
"id": "repositorio-pbs",
"term": "Repository PBS",
"def": "Combinazione di Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + utente che riceve il backup. Identificata dalla stringa <code>user@realm@host:datastore</code>. Un singolo server PBS può ospitare diversi repository."
},
{
"id": "datastore",
"term": "Datastore",
"def": "Spazio di archiviazione specifico su un server PBS che contiene backup e relativi blocchi. Ogni datastore risiede su un file system del server PBS con propri permessi e criteri."
},
{
"id": "chunk",
"term": "Blocco (chunk) / deduplicazione dei blocchi",
"def": "PBS divide ogni backup in blocchi di dimensioni variabili, identifica ogni pezzo dal suo hash e memorizza ogni pezzo solo una volta, anche se appare in molti backup diversi. Ciò significa backup successivi dello stesso host — o attraverso host simili — prendere molto poco spazio aggiuntivo."
},
{
"id": "fingerprint",
"term": "Impronta digitale",
"def": "Impronte crittografica del certificato PBS del server TLS. Consente al client di verificare che stia parlando con il server previsto senza affidarsi a un'autorità di certificazione pubblica. ProxMenux passa a <code>proxmox-backup-client</code> tramite la variabile ambiente <code>PBS_FINGERPRINT</code>."
},
{
"id": "grupo-copia",
"term": "Gruppo backup",
"def": "Contenitore logico all'interno di PBS in cui si accumulano backup successivi dello stesso asset. Ogni nuovo backup condivide la deduplica con quelli precedenti nello stesso gruppo. ProxMenux utilizza due gruppi per host quando la crittografia è abilitata: uno per il backup host e uno con un suffisso <code>-keyrecovery</code> per la <a href=\"#sobre-recuperacion\">busta di recupero</a>."
},
{
"id": "backup-id",
"term": "ID backup",
"def": "Nome del gruppo <a href=\"#grupo-copia\">backup</a>. ProxMenux predefinisce <code>hostcfg-HOSTNAME</code> e consente all'utente di modificarlo prima del caricamento; i caratteri non supportati vengono rimossi automaticamente."
},
{
"id": "pxar",
"term": ".pxar",
"def": "Formato di archivio nativo di PBS per directory. Si comporta come un archivio tar ottimizzato per la deduplicazione del pezzo: piuttosto che memorizzare un file opaco, PBS rompe il suo contenuto in pezzi riutilizzabili."
}
]
},
{
"title": "Esecuzione e pianificazione",
"intro": "Termini utilizzati dal sistema di lavoro programmato ProxMenux.",
"entries": [
{
"id": "runner",
"term": "Processo di esecuzione",
"def": "Lo script <code>run_scheduled_backup.sh</code> che esegue un backup programmato. Legge la configurazione del lavoro, lancia il backend corrispondente (Local, PBS o Borg), applica la ritenzione sul successo e invia le notifiche configurate."
},
{
"id": "trabajo-programado",
"term": "Lavoro programmato",
"def": "Configurazione persistente di un backup ricorrente. Contiene destinazione, credenziali, crittografia, pianificazione e conservazione. È salvata in <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
},
{
"id": "modo-adjunto",
"term": "Modalità allegato",
"def": "Processo senza timer proprio. Un hook job-end PVE di <code>vzdump</code> lo avvia dopo i backup dei guest se lo storage corrisponde. Il processo padre fornisce destinazione e conservazione iniziale, ma il hook confronta lo storage, non l’ID padre. Anche un altro processo sullo stesso storage può attivarlo. Solo Local e PBS."
},
{
"id": "timer-systemd",
"term": "Timer di systemd",
"def": "Meccanismo standard systemd che accende un comando su un calendario. ProxMenux crea un timer per <em>indipendente</em> lavoro programmato; <a href=\"#modo-adjunto\">attach-mode</a> posti di lavoro non utilizzano timer, vengono eseguiti tramite lo script-hook PVE."
},
{
"id": "retencion",
"term": "Retenzione (keep-last, keep-daily...)",
"def": "Politica che decide quali backup più vecchi mantenere e quali prune. Definito per lavoro con parametri come <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Applicato dal processo di esecuzione dopo ogni backup di successo."
}
]
},
{
"title": "Ripristina",
"intro": "Termini dal flusso di ripristino.",
"entries": [
{
"id": "restauracion-universal",
"term": "Ripristino universale",
"def": "Il flusso di ripristino ProxMenux non si limita a estrarre il filesystem: legge il manifesto per individuare le differenze tra sorgente e obiettivo, riproduce la configurazione del sistema e riattiva gli installatori per i componenti gestiti da ProxMenux. L'obiettivo è quello di riprodurre l'host sorgente, non solo l'archivio."
},
{
"id": "hidratacion",
"term": "Idratazione (cross-kernel)",
"def": "Passo di ripristino che fonde la propria configurazione dell'utente dalla sorgente (token IOMMU, ID dispositivo VFIO, quirk personalizzati, chiavi GRUB) in cima alla configurazione di avvio fresco del bersaglio, senza copiare i file legati al kernel della fonte verbatim. Esegue quando il kernel di destinazione è più nuovo di quello del backup."
},
{
"id": "cross-kernel",
"term": "Ripristino tra versioni del kernel",
"def": "Ripristino in cui il kernel di destinazione è diverso, di solito più recente, da quello sorgente. Il passaggio di <a href=\"#hidratacion\">idratazione</a> evita di trascinare file incompatibili con il kernel di destinazione."
},
{
"id": "instalador-postboot",
"term": "Installatore post-boot",
"def": "Componenti reinstallati dopo il primo avvio dell'host ripristinato ( driver NVIDIA, driver Coral TPU, strumenti AMD GPU, strumenti Intel GPU). Ogni installatore viene eseguito contro il kernel del bersaglio, quindi l'host ripristinato non dipende dal kernel della sorgente presente."
},
{
"id": "compatibility-check",
"term": "Controllo di compatibilità",
"def": "Confronto tra il manifesto sorgente e lo stato del bersaglio che ProxMenux esegue all'inizio del ripristino. Decide quali parti sono copiate verbatim, che hanno bisogno di idratazione e che sono ricreati da un installatore."
},
{
"id": "equipo-recien-instalado",
"term": "Installazione da zero",
"def": "Host appena reinstallato da zero, senza <a href=\"#clave-cifrado\">keyfile</a> locale. Ripristino di un backup crittografato richiede prima di recuperare il file chiave dal <a href=\"#sobre-recuperacion\">busta</a> memorizzato su PBS, utilizzando il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a>."
}
]
}
],
"whereNext": {
"heading": "Dove proseguire",
"items": [
{
"label": "Come funziona",
"href": "/docs/backup-restore/how-it-works",
"tail": " — come rootfs, manifesto e inventario applicazioni si inseriscono nel backup."
},
{
"label": "Destinazione Proxmox Backup Server",
"href": "/docs/backup-restore/destinations/pbs",
"tail": "— in cui la crittografia lato client, keyfile, passphrase di recupero e busta sono documentati in profondità."
},
{
"label": "Ripristino",
"href": "/docs/backup-restore/restoring",
"tail": " — procedura di ripristino e uso del manifesto."
}
]
}
}
web/messages/it/docs/backup-restore/how-it-works.json
+205
View File
@@ -0,0 +1,205 @@
{
"meta": {
"title": "Come funziona il backup ProxMenux internamente — rootfs, manifesto, applicazioni",
"description": "Contenuto dettagliato di un backup ProxMenux: il rootfs copiato con rsync secondo il profilo di percorsi predefinito, il manifesto strutturato creato da sei moduli di raccolta indipendenti e l’inventario delle applicazioni che guida la reinstallazione automatica di pacchetti e componenti dopo il ripristino.",
"ogTitle": "Come funziona ProxMenux Backup internamente",
"ogDescription": "Le tre parti di un backup ProxMenux: rootfs, manifesto e applicazioni.",
"twitterTitle": "Come funziona ProxMenux Backup | ProxMenux",
"twitterDescription": "I tre payload di un backup ProxMenux e come il ripristino riproduce l'host sorgente da loro."
},
"header": {
"title": "Come funziona",
"description": "La ripartizione interna di un backup ProxMenux — filesystem, inventario manifesto e di applicazione — e come il ripristino consuma tutti e tre per riprodurre l'host sorgente su un obiettivo che potrebbe non condividere lo stesso kernel.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Un archivio, tre parti",
"body": "Ogni backup crea tre parti definite sotto un’unica directory di preparazione. L’archivio caricato sulla destinazione (<code>.tar.zst</code> locale, backup PBS o archivio Borg) conserva questa struttura. Il ripristino usa tutte e tre: <strong>il manifesto</strong> viene consultato prima delle modifiche per rilevare differenze e decidere cosa escludere; <strong>rootfs</strong> fornisce i file di configurazione, applicati subito o dopo il riavvio; <strong>l’inventario delle applicazioni</strong> guida l’installazione dei pacchetti e la reinstallazione dei componenti dopo l’avvio. Ogni parte può essere esaminata o estratta indipendentemente."
},
"layout": {
"heading": "Disposizione dell'archivio",
"intro": "Ogni archivio segue lo stesso layout albero indipendentemente dalla destinazione. La sottodirectory <code>metadata/</code> contiene i dati strutturati; la sottodirectory <code>rootfs/</code> contiene la copia del filesystem.",
"treeCaption": "La directory di preparazione creata durante il backup. Tutte le destinazioni ricevono lo stesso albero nel proprio formato nativo: tar per i backup locali, blocchi PBS per PBS e segmenti Borg per 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": "La parte rootfs",
"intro": "L’albero <code>rootfs/</code> è una <strong>semplice copia del filesystem</strong> prodotta da <code>rsync</code> dall’host di origine. Contiene un <strong>profilo predefinito</strong> di percorsi scelti per il ripristino Proxmox e gli eventuali <strong>percorsi personalizzati</strong> aggiunti all’attività o alla sessione interattiva. La selezione è volutamente limitata ai percorsi che <em>contengono configurazione</em> o <em>conservano uno stato che Proxmox non può rigenerare da solo</em>.",
"defaultProfileTitle": "Il profilo predefinito",
"defaultProfileBody": "Il profilo predefinito è definito da <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. Copre otto categorie fisse e, se necessario, lo stato ZFS, che insieme descrivono un host Proxmox operativo:",
"categoriesTitle": "Categorie dei percorsi",
"categoryRows": [
{
"category": "Nucleo PVE",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
"why": "Contenuto del filesystem Cluster e default vzdump. Il database PMxcfs (<code>config.db</code>) viene catturato come un'istantanea coerente tramite <code>sqlite3 .backup</code> senza interrompere il cluster, e i sidecar <code>.db-wal</code> / <code>.db-shm</code> sono esclusi dal rsync. Quando <code>sqlite3</code> non è disponibile, viene creato <code>config.db.raw-fallback</code>, che il ripristino usa automaticamente come database."
},
{
"category": "Identità e rete host",
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
"why": "Tutto ciò che serve all’host per tornare in rete con la stessa identità. I file <code>.link</code> in <code>/etc/systemd/network</code> associano i nomi delle schede alle rispettive MAC, mantenendo i nomi durante reinstallazioni e modifiche hardware."
},
{
"category": "Accesso e autenticazione",
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
"why": "Chiavi SSH, regole sudo e configurazione PAM. Perderle impedisce all’utente di accedere all’host ripristinato."
},
{
"category": "Kernel e avvio",
"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": "Parametri IOMMU, blacklist dei moduli, ID dei dispositivi VFIO, tabella dei montaggi e configurazione dello stack di archiviazione."
},
{
"category": "Shell e impostazioni locali",
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
"why": "Configurazione di shell a livello di sistema, variabili di ambiente, configurazione di generazione locale."
},
{
"category": "Gestione pacchetti e cron",
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
"why": "Fonti APT per una risoluzione coerente dei pacchetti, attività pianificate definite dall'utente."
},
{
"category": "ProxMenux stati e strumenti",
"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": "Utensili Proxmox opzionali ma comuni. I percorsi mancanti sono segnalati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
},
{
"category": "ProxMenux binari e root",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (sottodiri volatili esclusi)",
"why": "File binari ProxMenux e configurazione per utente sotto <code>/root</code>. I percorsi volatili (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sono esclusi dalla copia. <code>/var/lib/proxmenux</code> detiene i lavori di backup programmati e lo stato dell’host tenuto da ProxMenux; la messa in scena di ripristino, le copie rollback e i marcatori post-restore sono esclusi, perché appartengono all'host che gestisce un ripristino."
},
{
"category": "Stato ZFS (condizionato)",
"paths": "/etc/zfs",
"why": "Solo incluso quando l'host sorgente esegue ZFS. Contiene <code>zpool.cache</code> e <code>hostid</code>."
}
],
"customTitle": "Estendere il profilo con percorsi personalizzati",
"customBody": "Oltre al profilo predefinito, ProxMenux offre due modi per includere ulteriori percorsi in un backup. Si compone senza conflitti ed entrambi si applicano a backup interattivi e lavori programmati.",
"customExtrasTitle": "1. Extra persistenti (file per host)",
"customExtrasBody": "Un file di testo a <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contiene un elenco di percorsi assoluti che l'utente ha contrassegnato come \"sempre includere\" su questo host. Quando un backup viene eseguito in modalità <strong>Default</strong>, ProxMenux aggiunge questi percorsi al profilo predefinito automaticamente senza chiedere. Il file viene modificato dall'interfaccia — nessuna modifica manuale necessaria — e persiste attraverso riavvimenti e aggiornamenti. Un percorso assoluto per linea; sono consentiti commenti <code>#</code>.",
"customModeTitle": "2. Modalità personalizzata (per-run)",
"customModeBody": "Avviare un backup in modalità <strong>Custom</strong> sostituisce l'applicazione automatica del profilo predefinito con una lista di controllo che mostra ogni percorso: le voci del profilo predefinito e gli extra persistenti (prefissati con <code>[+]</code> e già selezionati). L'utente seleziona o deseleziona le voci per tale esecuzione specifica, e può anche premere <em>Aggiungi percorso personalizzato</em> per inserire un nuovo percorso — che viene poi persistito al file extra per i backup futuri.",
"customMissingTitle": "Sentieri assenti dalla fonte",
"customMissingBody": "Qualsiasi percorso dal profilo (default o aggiunto) che non esiste sull'host sorgente viene registrato in <code>metadata/missing_paths.txt</code> all'interno dell'archivio. Il backup non fallisce né si ferma — l'utente vede un riassunto di percorsi archiviati e percorsi mancanti alla fine. In pratica questo accade per percorsi di utensile opzionali come <code>/etc/wireguard</code> o <code>/etc/prometheus</code> quando questi strumenti non sono installati."
},
"manifest": {
"heading": "La parte manifesto",
"intro": "<code>manifest.json</code> è un documento strutturato JSON che descrive l'host sorgente al momento del backup. È prodotto da <strong>sei moduli di raccolta indipendenti</strong> orchestrati da <code>build_manifest.sh</code>. Ogni collettore è in sola lettura, produce un frammento JSON ben definito, e rientra in un default vuoto sicuro se non riesce — il manifesto è ancora utilizzabile se una sezione è incompleta.",
"orchestratorCaption": "I sei moduli di raccolta compongono il manifesto. Ogni collettore funziona nel proprio sottoprocesso; un guasto in uno rientra in un documento di default sicuro e avverte ma non interrompe il backup.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
"produces": "source_host",
"content": "Hostname, versione PVE (<code>pveversion</code>), versione PBS se l'host esegue il ruolo di backup-server, kernel (<code>uname -r</code>), modalità boot (efi/bios), tipo filesystem root, modello CPU + architettura, memoria in KB."
},
{
"collector": "collect_hardware.sh",
"produces": "hardware_inventory",
"content": "GPU (con il fornitore e la mappatura dell'installatore ProxMenux), TPU (Coral USB + M.2 con il rilevamento di <code>lsusb</code>/<code>lspci</code>), NIC (con MAC, slot PCI e ponti), dispositivi wireless. Le voci GPU portano un'euristica <code>passthrough_eligible</code>."
},
{
"collector": "collect_storage.sh",
"produces": "storage_inventory",
"content": "Pool ZFS con relativo tipo e dischi membri identificati tramite <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> o percorsi diretti <code>/dev/sdX</code>, a seconda di come il pool è stato creato; gruppi di volumi e thin pool LVM; dischi fisici con supporto SMART; voci PVE di <code>storage.cfg</code>; montaggi esterni."
},
{
"collector": "collect_kernel.sh",
"produces": "kernel_params",
"content": "Parametri aggiunti dall’operatore in <code>/proc/cmdline</code>, esclusi quelli standard come <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> e <code>splash</code>; moduli caricati all’avvio da <code>/etc/modules</code>; percorsi dei file <code>/etc/modprobe.d/*.conf</code> con direttive effettive (<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": "Leggi <code>/usr/local/share/proxmenux/managed_installs.json</code> (registry di tutto ciò che ProxMenux ha installato) e <code>installed_tools.json</code>. Ogni voce mantiene il percorso di installazione (<code>menu_script</code>) in modo che il ripristino possa attivare lo stesso flusso di installazione."
},
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
"content": "Elenca le VM (<code>qm list</code>) e i container LXC (<code>pct list</code>) presenti al momento del backup: VMID, nome e stato. È soltanto l’inventario; il backup dei dati effettivi dei guest spetta a <code>vzdump</code> / PBS."
}
],
"schemaTitle": "Validazione schema",
"schemaBody": "Il manifesto convalida contro <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'esecuzione di <code>build_manifest.sh --validate</code> attiva una validazione dello schema JSON (richiede <code>python3</code> + <code>jsonschema</code>). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime."
},
"applications": {
"heading": "inventario delle applicazioni",
"intro": "Due inventari elencano il software aggiunto ai pacchetti base di Proxmox VE: la lista dei pacchetti in <code>metadata/</code> e il registro dei componenti in rootfs, descritti di seguito. Il ripristino usa APT o gli installatori ProxMenux per riprodurre il software dell’utente secondo il metodo originale di installazione.",
"packagesTitle": "packages.manual.list",
"packagesBody": "Una lista alfabetica in testo semplice prodotta da <code>apt-mark showmanual</code> con tutti i pacchetti APT <em>installati esplicitamente</em> sull’host di origine. Sono escluse le dipendenze del sistema Proxmox VE di base, che APT installa automaticamente sul destinatario. Durante il ripristino, <code>_rs_run_complete_extras</code> legge la lista e applica un <em>filtro contro le rimozioni a cascata</em> in tre passaggi: <code>dpkg -s</code> rileva i pacchetti già installati, vengono rilevate altre versioni principali delle librerie e <code>apt-get install --simulate</code> verifica il rischio di rimozioni a cascata. Infine usa <code>apt-get install -y</code> per i pacchetti rimasti.",
"componentsTitle": "components_status.json (parte di rootfs)",
"componentsBody": "Un registro JSON sotto <code>/usr/local/share/proxmenux/</code> che registra ogni componente ProxMenux installato con il suo stato esatto: versione, bandiere ProxMenux-specifiche (per NVIDIA: <code>patched</code> boolean; per Coral: versione DKMS). Questo file vive all'interno dei rootfs — non in <code>metadata/</code> — perché è <em>letto dopo</em> la copia di rootfs al bersaglio. Il distaccatore post-boot (<code>apply_cluster_postboot.sh</code>) itera sulle sue voci ed esegue il gancio <code>--auto-reinstall</code> di ciascun componente, che legge lo stato registrato e riproduce l'installazione contro il kernel corrente dell'obiettivo.",
"componentInstallersTitle": "Installatori di componenti",
"componentInstallersBody": "Quattro installatori ProxMenux attualmente espongono un punto di ingresso <code>--auto-reinstall</code>:",
"installerRows": [
{
"component": "nvidia_driver",
"installer": "gpu_tpu/nvidia_installer.sh",
"action": "Leggi <code>version</code> + <code>patched</code>. Scarica lo stesso runfile NVIDIA, costruisce moduli DKMS contro il kernel dell'obiettivo, riapplica la patch ProxMenux se la sorgente lo avesse."
},
{
"component": "coral_driver",
"installer": "gpu_tpu/install_coral.sh",
"action": "Legge la versione del driver Coral. Compili il modulo DKMS contro il kernel dell'obiettivo."
},
{
"component": "amdgpu_top",
"installer": "gpu_tpu/amd_gpu_tools.sh",
"action": "Legge la versione registrata. Ricarica l'esatta <code>.deb</code> dalla versione GitHub."
},
{
"component": "intel_gpu_tools",
"installer": "gpu_tpu/intel_gpu_tools.sh",
"action": "APT-installa il pacchetto. Idemponte se già presente da <code>packages.manual.list</code>."
}
]
},
"restoreFlow": {
"heading": "Come il ripristino usa le tre parti",
"intro": "Il restauro e' una pipeline di sei stadi. Ogni fase legge un sottoinsieme specifico dell'archivio e aggiorna l'host di destinazione. Nessuna fase richiede che l'host sorgente sia raggiungibile — l'archivio è completamente autonomo.",
"stagesCaption": "La fase 1 usa il manifesto per decidere cosa modificare. La fase 2 copia i percorsi rootfs applicabili al sistema in esecuzione. La fase 3 prepara quelli rischiosi per il prossimo avvio. La fase 3b importa i pool ZFS di dati che non contengono la radice e hanno tutti i dischi presenti. La fase 4 gestisce i pacchetti. La fase 5 reinstalla i componenti dopo il riavvio per il kernel di destinazione.",
"stageRows": [
{
"stage": "1",
"name": "Controllo di compatibilità",
"reads": "manifest.json",
"action": "Esegue <code>hb_compat_check</code>. Confronta sorgente vs. hardware target (NIC, ID di archiviazione), versione PVE e versione kernel principale. Imposta <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> o <code>bk_older</code>) e popola <code>RS_SKIP_PATHS</code> con esclusione hardware-drift e cross-kernel."
},
{
"stage": "2",
"name": "Applicazione a sistema avviato",
"reads": "rootfs/ (solo percorsi sicuri)",
"action": "<code>_rs_apply … hot</code> copia le voci <code>hb_classify_path</code>=<code>hot</code> direttamente al target live. Qualsiasi cosa sotto <code>/etc/pve</code>, <code>/etc/network</code> o percorsi classificati come <em>reboot</em>/<em>dangerous</em> è differita."
},
{
"stage": "3",
"name": "Preparazione delle modifiche differite",
"reads": "rootfs/ (riavvio + percorsi pericolosi)",
"action": "<code>_rs_prepare_pending_restore</code> prepara i percorsi rischiosi in <code>/var/lib/proxmenux/pending-restore/</code>, scrive <code>plan.env</code>, <code>apply-on-boot.list</code> e <code>rs-skip-paths.txt</code> e abilita <code>proxmenux-restore-onboot.service</code> per il prossimo avvio."
},
{
"stage": "3b",
"name": "Importazione dei pool di dati",
"reads": "manifest.storage_inventory + target ZFS stato",
"action": "<code>_rs_import_data_pools</code> tenta di importare ogni pool ZFS che non contiene la radice e ha tutti i dischi presenti sul destinatario. Se il pool ha un hostid estraneo, riprova con <code>zpool import -f</code>. Se manca un disco, il pool viene saltato con un avviso. Il risultato per pool è registrato in <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
},
{
"stage": "4",
"name": "Installazione del pacchetto",
"reads": "metadata/packages.manual.list",
"action": "<code>_rs_run_complete_extras</code> gestisce il filtro a cascata e chiama <code>apt-get install -y</code> con l'elenco dei pacchetti sopravvissuti. L'uscita completa va a <code>/var/log/proxmenux/restore-apt-*.log</code>."
},
{
"stage": "5",
"name": "Dopo l'avvio",
"reads": "rootfs (già applicato) + components_status.json",
"action": "Dopo il riavvio, <code>apply_pending_restore.sh</code> riprende i percorsi differiti e <code>apply_cluster_postboot.sh</code> corre <code>update-initramfs</code>, <code>update-grub</code> (o <code>proxmox-boot-tool refresh</code>) e itera oltre <code>components_status.json</code> sparando il gancio <code>--auto-reinstall</code> di ogni componente."
}
]
},
"whyItWorks": {
"heading": "Perché suddividere il backup in tre parti",
"body": "La suddivisione segue il <strong>ciclo di vita</strong> dei dati. Il filesystem viene trasferito con <code>rsync</code>: rapidamente, in modo trasparente e atomico per file. Lo stato di configurazione da interpretare prima delle modifiche è <strong>JSON strutturato</strong>, leggibile separatamente, versionabile tramite schema e confrontabile automaticamente con lo stato di destinazione. Il software da reinstallare è descritto in un <strong>inventario</strong> di nomi e versioni; il gestore dei pacchetti e gli installatori ProxMenux scelgono i binari adatti. Ogni parte svolge il proprio compito. Insieme mirano a un ripristino coerente ma tollerante agli errori: un manifesto corrotto lascia rootfs ripristinabile, un pacchetto mancante non impedisce l’installazione dei componenti e un errore su una voce non ferma l’installazione della successiva."
}
}
web/messages/it/docs/backup-restore/index.json
+93
View File
@@ -0,0 +1,93 @@
{
"meta": {
"title": "ProxMenux Backup e ripristino — Panoramica | Backup e ripristino completo dell'host per Proxmox VE",
"description": "ProxMenux Backup e ripristino acquisisce lo stato completo di un host Proxmox (file system, manifest di configurazione strutturata e pacchetti/componenti installati) e lo riproduce sullo stesso host o su un host diverso. Il backup e il ripristino sono autonomi: nessuna dipendenza esterna e i ripristini tra kernel sono supportati tramite un filtro di sottoinsieme sicuro sensibile alla direzione e un'idratazione indipendente dal kernel.",
"ogTitle": "ProxMenux Backup e ripristino - Panoramica",
"ogDescription": "Backup e ripristino completo dell'host per Proxmox VE con manifest strutturato, elenco di pacchetti e programmi di reinstallazione dei componenti.",
"twitterTitle": "ProxMenux Backup e ripristino | ProxMenux",
"twitterDescription": "Backup e ripristino completo dell'host per Proxmox VE con manifest strutturato, elenco di pacchetti e programmi di reinstallazione dei componenti."
},
"header": {
"title": "Backup e ripristino",
"description": "Backup e ripristino dell'intero host per Proxmox VE. Cattura filesystem, configurazione e componenti installati in un unico archivio e riproduce l'host sulla stessa o su una diversa installazione Proxmox senza dipendenze esterne.",
"section": "Backup e ripristino"
},
"intro": {
"title": "Che cos'è, in un paragrafo",
"body": "Un backup di ProxMenux acquisisce lo stato completo di un host Proxmox: <strong>il filesystem</strong>, con le directory pertinenti in <code>/etc</code>, <code>/root</code> e <code>/var/lib/pve-cluster</code> e gli eventuali percorsi personalizzati; <strong>un manifesto strutturato</strong> in JSON con hardware rilevato, parametri del kernel, configurazione di rete, stato di ZFS, utenti e voci cron; e <strong>un inventario delle applicazioni</strong>, con i pacchetti contrassegnati da APT come installati manualmente e i componenti installati da ProxMenux, completi delle versioni esatte. Le tre destinazioni supportate — archivio locale, Proxmox Backup Server (consigliato) e Borg — ricevono lo stesso contenuto autonomo. Ognuna consente di ricostruire l’host di destinazione senza che l’host di origine debba essere raggiungibile durante il ripristino."
},
"video": {
"heading": "Video tutorial",
"intro": "Preferisci guardare Backup e ripristino in azione prima di configurarlo? Questa procedura dettagliata copre una demo completa end-to-end della funzionalità in ProxMenux.",
"title": "ProxMenux — Procedura dettagliata di backup e ripristino",
"caption": "Video esterno su YouTube. Riproduce in modalità di privacy avanzata (nessun cookie finché non premi Riproduci)."
},
"whatItIsNot": {
"heading": "Cosa non è",
"intro": "Questa sezione riguarda il backup e il ripristino <strong>dell’host</strong>: l’installazione di Proxmox, non le applicazioni e i sistemi guest che vi vengono eseguiti.",
"items": [
"<strong>Non è uno strumento di backup delle VM/CT.</strong> Questa funzione non acquisisce i dischi o lo stato della RAM dei guest: a questo serve <code>vzdump</code>. I <strong>file di configurazione</strong> dei guest (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> e <code>lxc/*.conf</code>) vengono <strong>invece</strong> salvati. Dopo il ripristino ricompare l’inventario e i dischi possono essere ripristinati o ricollegati da un backup esistente su PBS o in locale.",
"<strong>Non è un’operazione sull’intero cluster.</strong> Ogni nodo salva il proprio backup. L’appartenenza al cluster è inclusa in <code>/etc/pve</code>, così un nodo ripristinato può esservi reintegrato; il ripristino di tutto il cluster richiede però il coordinamento dei singoli nodi.",
"<strong>Non è un’immagine completa del disco.</strong> Non vengono salvati i binari del kernel, l’initramfs o la partizione di avvio. Durante il ripristino ProxMenux usa i file di avvio dell’host di destinazione, rigenerati automaticamente da <code>update-initramfs</code> e dallo strumento del bootloader, e installa i driver compatibili con il kernel in esecuzione sulla destinazione."
]
},
"threePillars": {
"heading": "I tre pilastri di un backup",
"intro": "Un archivio ProxMenux è strutturato attorno a tre payload autonomi. Il ripristino li utilizza tutti e tre insieme per riprodurre l'host di origine su una destinazione che potrebbe non avere nemmeno lo stesso kernel installato.",
"diagramCaption": "Ogni backup spedisce gli stessi tre payload indipendentemente dalla destinazione. Il ripristino utilizza tutti e tre: rootfs per depositare i file, manifest per rilevare deviazioni e differenze tra kernel e inventario delle applicazioni per reinstallare pacchetti e componenti sul kernel della destinazione.",
"pillar1Label": "Filesystem",
"pillar1Detail": "rootfs/\n(rsync di /etc,\n/etc/systemd/network,\n/root, più uno\nsnapshot sqlite3\ndi /var/lib/pve-cluster,\n+ percorsi opzionali)",
"pillar2Label": "Manifesto",
"pillar2Detail": "manifest.json\n(hardware, parametri\ndel kernel, rete,\nZFS, utenti, cron,\npool ZFS, archiviazione)",
"pillar3Label": "Applicazioni",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(pacchetti APT manuali + programmi\ndi installazione ProxMenux con versioni)"
},
"restoreIsUniversal": {
"heading": "Il ripristino riproduce l'host di origine, non l'archivio",
"body": "Il ripristino di un backup ProxMenux non si limita ad estrarre il filesystem. Il flusso di ripristino legge il manifest per rilevare la deviazione tra l'origine e la destinazione (differenze hardware, rinomina della scheda NIC, versione del kernel, identità del pool ZFS), riproduce il file system, quindi attiva il programma di installazione del componente corretto per ogni servizio installato sull'origine (driver NVIDIA, Coral TPU, strumenti GPU AMD, strumenti Intel GPU). Ogni programma di installazione viene eseguito sul <strong>kernel corrente della destinazione</strong>, quindi l'host ripristinato non dipende dalla presenza del kernel di origine. Quando il kernel della destinazione è più recente di quello del backup, un passaggio di <strong>idratazione</strong> indipendente dal kernel unisce l'ottimizzazione dell'utente (token IOMMU, ID dispositivo VFIO, quirk personalizzati, chiavi GRUB) nella nuova configurazione di avvio della destinazione senza copiare testualmente i file legati al kernel."
},
"twoInterfaces": {
"heading": "Due interfacce, un backend",
"intro": "Ogni fase del flusso di lavoro di backup e ripristino è disponibile da due punti di ingresso. Entrambi chiamano la stessa libreria di shell, producono archivi identici e leggono lo stesso registro dei lavori.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "menu → Utilità →\nBackup/Ripristino dell'host\n\nFlusso basato su dialoghi,\nSSH-friendly, scriptabile\nper uso non presidiato.",
"webLabel": "ProxMenux Monitor (Web UI)",
"webDetail": "Scheda Backups\nnell’interfaccia web di Monitor.\n\nRipristino con un clic, log\nin tempo reale, integrazione con\nle notifiche e il visualizzatore\ndelle differenze di rollback."
},
"whereNext": {
"heading": "Dove andare da qui",
"intro": "Ogni sottosezione seguente copre in modo approfondito un aspetto del flusso di lavoro. Inizia con <em>Come funziona</em> se l'obiettivo è capire cosa contiene l'archivio e perché. Vai a <em>Destinazioni</em> per configurare la destinazione per la copia. Leggi <em>Ripristino</em> e <em>Ripristino cross-kernel</em> per la parte di ripristino.",
"items": [
{
"label": "Come funziona",
"href": "/docs/backup-restore/how-it-works",
"tail": "— i tre payload (rootfs, manifest, applicazioni) in dettaglio, con i raccoglitori che li producono e il formato di ciascun file."
},
{
"label": "Destinazioni",
"href": "/docs/backup-restore/destinations",
"tail": " — confronto tra locale, Proxmox Backup Server (consigliato) e Borg e come configurarli."
},
{
"label": "Creazione di backup",
"href": "/docs/backup-restore/creating-backups",
"tail": " — backup una tantum, profilo di percorso predefinito, aggiunta di percorsi personalizzati, crittografia per PBS."
},
{
"label": "Lavori pianificati",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": " — nuovi lavori rispetto al collegamento a un lavoro vzdump PVE esistente, formati di pianificazione, finestra dei dettagli del lavoro."
},
{
"label": "Ripristino",
"href": "/docs/backup-restore/restoring",
"tail": " — le tre azioni su un archivio (visualizzazione, download, ripristino), ripristino completo e personalizzato, il dispatcher post-avvio e perché gli ultimi dieci minuti sono importanti."
},
{
"label": "Ripristino tra kernel",
"href": "/docs/backup-restore/cross-kernel",
"tail": " — comportamento che tiene conto della direzione del cambio di versione quando il kernel di destinazione è diverso da quello del backup, filtro del sottoinsieme sicuro e quattro fasi di idratazione."
}
]
}
}
web/messages/it/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/it/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Attività pianificate — timer, modalità di collegamento, conservazione | ProxMenux",
"description": "Attività pianificate di backup dell’host ProxMenux. Due modalità di creazione (timer systemd dedicato o collegamento a un’attività vzdump PVE esistente), regole di conservazione applicate per attività tramite proxmox-backup-client, Borg o pulizia locale, file in /var/lib/proxmenux/backup-jobs e script di esecuzione che produce gli stessi archivi del flusso interattivo.",
"ogTitle": "ProxMenux Backup — lavori programmati",
"ogDescription": "Backup host programmati non presidiati con modalità di aggancio, ritenzione e le stesse tre destinazioni del flusso interattivo.",
"twitterTitle": "Lavori programmati | ProxMenux",
"twitterDescription": "Attività pianificate di backup dell’host senza intervento, con modalità di collegamento e conservazione."
},
"header": {
"title": "Lavori programmati",
"description": "Lavori di backup incustoditi. Due modelli di creazione: un nuovo lavoro indipendente con il proprio programma, o un lavoro collegato ad un'attività PVE vzdump esistente che eredita il programma e la ritenzione di tale attività. Entrambi producono archivi identici al flusso interattivo.",
"section": "Backup e ripristino"
},
"intro": {
"title": "I due modelli di lavoro programmati",
"body": "Un lavoro programmato può essere creato seguendo uno dei due modelli:",
"modelsList": [
"<strong>Nuovo lavoro indipendente</strong> — ProxMenux definisce il programma di lavoro stesso con il proprio timer systemd, indipendente da qualsiasi altra attività sull'host. Compatibile con tutte e tre le destinazioni: Locale, PBS e Borg.",
"<strong>Collega a un’attività vzdump PVE esistente</strong> — l’attività non ha una pianificazione propria; viene eseguita automaticamente quando si attiva l’attività vzdump PVE principale che già esegue il backup di VM e LXC sull’host. Ne eredita pianificazione e conservazione. Compatibile con Locale e PBS (Borg non è supportato perché PVE non ha un pianificatore nativo per Borg)."
]
},
"attachBadge": {
"title": "Modalità di aggancio — consigliato quando esiste già un compito PVE vzdump",
"body": "Se esiste già un’attività vzdump PVE per VM e LXC del nodo, collegare il backup dell’host lo fa eseguire dopo il backup dei guest, nello <strong>stesso ciclo di backup</strong>. Nel ripristino, le configurazioni dei guest provengono dal backup dell’host (in <code>/etc/pve</code>) e i dischi dai backup vzdump dello stesso ciclo. Questo aiuta a coordinare il recupero dell’intero nodo, ma non è uno snapshot atomico: modifiche durante il ciclo possono lasciare differenze tra configurazione dell’host e stato dei dischi dei guest."
},
"frequencyBadge": {
"title": "Frequenza raccomandata",
"body": "Per massimizzare la compatibilità tra backup dell’host e ripristino futuro, esegui backup frequenti. Più la copia è vicina allo stato attuale dell’host, meno differenze di configurazione, pacchetti e componenti dovrà riconciliare il ripristino."
},
"modes": {
"heading": "Le due modalità",
"rows": [
{
"mode": "Nuova attività pianificata",
"backends": "Locale, PBS, Borg",
"schedule": "Espressione <code>OnCalendar</code> propria (sintassi del calendario systemd, ad esempio <code>daily</code> o <code>Mon..Fri 03:00</code>).",
"retention": "Richiesti separatamente: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applicato dallo script di esecuzione dopo ogni backup di successo."
},
{
"mode": "Attaccare a un lavoro PVE vzdump",
"backends": "Locale, PBS (Borg non ha pianificatore lato PVE)",
"schedule": "Ereditata dall’attività PVE principale. Non viene installato alcun timer systemd sul lato ProxMenux.",
"retention": "Ereditata dalla configurazione <code>prune-backups</code> dell’attività principale (mappata uno a uno alle variabili <code>KEEP_*</code> dello script di esecuzione tramite <code>hb_pve_prune_to_keep_env</code>)."
}
]
},
"attachDetail": {
"heading": "Come funziona la modalità di collegamento",
"intro": "PVE scrive le attività <code>vzdump</code> in <code>/etc/pve/jobs.cfg</code>, con una sezione per attività che indica lo storage dei backup VM e LXC. La modalità di collegamento richiede un backend supportato da ProxMenux (Locale o PBS). Il backup dell’host parte dall’hook job-end dopo il completamento dell’attività di backup dei guest.",
"steps": [
{
"step": "1",
"detail": "Durante la creazione dell’attività, ProxMenux elenca le attività PVE genitoriali compatibili tramite <code>hb_pve_list_vzdump_jobs_for_backend</code>. L'utente ne sceglie uno."
},
{
"step": "2",
"detail": "Il file <code>.env</code> dell’attività è scritto con <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> e i valori ereditati <code>KEEP_*</code>; non viene creato alcun timer systemd."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> registra un hook in <code>/etc/vzdump.conf</code>. Nella fase job-end di qualsiasi attività vzdump confronta il <code>$STOREID</code> ricevuto con il <code>PVE_STORAGE</code> di ogni attività collegata e abilitata, avviando lo script di esecuzione per quelle corrispondenti. Il confronto usa lo storage, non l’ID dell’attività principale selezionata."
},
{
"step": "4",
"detail": "L’archivio viene salvato nello stesso storage dei backup vzdump: <code>path/dump/</code> per Locale oppure il repository PBS configurato nella voce di storage PVE."
}
],
"outroBody": "La modalità di collegamento non ha un timer proprio. Disabilitare o eliminare l’attività PVE principale selezionata ferma quel trigger, ma un’altra attività vzdump sullo stesso storage può ancora avviare il backup dell’host. Per impedirlo, disabilita o elimina l’attività ProxMenux stessa. Se disabilitata, la voce resta su disco e può essere riabilitata o ricollegata."
},
"storageLayout": {
"heading": "File che compongono un lavoro",
"intro": "Ogni lavoro programmato è completamente descritto da tre o quattro file sul disco. Leggerli dà la configurazione completa del lavoro senza fare affidamento sull'interfaccia.",
"rows": [
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Backend, ID di backup o destinazione, pianificazione (Nuova modalità) o genitore PVE (Modalità allegato), abilitato flag, ritenzione valori <code>KEEP_*</code>, puntatori di credenziali."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "Un percorso assoluto per riga: la selezione ricavata dal profilo e fissata alla creazione dell’attività. Modificare il file fa usare la nuova selezione alla successiva attivazione del timer."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "Solo modalità nuova attività. Il servizio invoca <code>run_scheduled_backup.sh JOB_ID</code>. Il timer lo programma con <code>Persistent=true</code> (esecuzioni saltate recuperate al prossimo avvio) e un piccolo <code>RandomizedDelaySec=120</code> per diffondere il carico quando più attività condividono la stessa espressione OnCalendar."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Solo modalità di collegamento. Installato una volta da <code>hb_install_vzdump_hook</code>; confronta <code>PVE_STORAGE</code> di ogni attività collegata con <code>$STOREID</code>, passato da PVE allo script hook."
}
]
},
"runner": {
"heading": "Cosa fa un’attività quando si avvia",
"intro": "Ogni lavoro — se nuovo modello o allegato — esegue la stessa sequenza a tre fasi:",
"steps": [
"<strong>Prepara il backup.</strong> Legge la configurazione del lavoro (destinazione, profilo, percorsi) e assembla l'albero dell'archivio esattamente come fa il flusso interattivo. Il risultato è lo stesso archivio un backup manuale con quelle impostazioni produrrebbe.",
"<strong>Scrivi nella destinazione.</strong> Carica o scrive l'archivio alla destinazione configurata — un file <code>.tar.zst</code> locale, un backup PBS o un archivio Borg — utilizzando esattamente gli stessi strumenti e le credenziali che un backup manuale alla stessa destinazione avrebbe utilizzato.",
"<strong>Applica la conservazione.</strong> Rimuove i vecchi backup dalla destinazione, mantenendo i conti <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurati sul lavoro. La potatura viene eseguita dalla destinazione stessa: PBS applica la propria ritenzione, Borg esegue <code>borg prune</code>, e per Local ProxMenux elimina i file che cadono fuori dalla finestra <code>keep-last</code>."
]
},
"management": {
"heading": "Gestione dei lavori",
"intro": "Il menu scheduler (Script TUI) e la scheda Monitor Backups espongono le stesse azioni su qualsiasi lavoro.",
"rows": [
{
"action": "Esegui ora",
"detail": "Richiama subito lo script di esecuzione, senza attendere il timer o l’hook vzdump. Utile per verificare la configurazione senza aspettare la prossima esecuzione pianificata."
},
{
"action": "Attivare / disattivare",
"detail": "Nuova modalità: <code>systemctl enable/disable --now</code> il timer. Modalità di aggancio: cambia il flag <code>ENABLED</code> nel job env — lo script gancio lo onora alla prossima esecuzione PVE."
},
{
"action": "Modifica",
"detail": "Riapre le richieste di destinazione, pianificazione, profilo e ritenzione e riscrive i file di lavoro. Conserva l'ID del lavoro."
},
{
"action": "Elimina",
"detail": "Rimuove il job env, il file dei percorsi, il timer + servizio systemd (Nuova modalità), e disabilita il binding del gancio (Modalità allegato). Non tocca archivi già sulla destinazione."
},
{
"action": "Visualizza log",
"detail": "Mostra in tempo reale <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code>: un file di registro per esecuzione. Lo script di esecuzione emette anche una riga di stato compatta a journald sotto il servizio systemd."
}
]
},
"notifications": {
"heading": "Notifiche",
"body": "Ogni esecuzione programmata genera gli stessi eventi <code>hb_notify_lifecycle</code> del flusso interattivo (<code>start</code>, <code>complete</code>, <code>fail</code>). Se i canali di notifica sono configurati nel Monitor, i lavori incustoditi mostrano i risultati come fanno i backup manuali — un utente non ha bisogno di controllare il registro per sapere se un lavoro è riuscito."
},
"whereNext": {
"heading": "Dove andare dopo",
"items": [
{
"label": "Creazione di backup",
"href": "/docs/backup-restore/creating-backups",
"tail": "— il flusso interattivo che condivide il backend con il pianificatore."
},
{
"label": "Destinazioni",
"href": "/docs/backup-restore/destinations",
"tail": "— configurazione per-backend utilizzata sia dal flusso interattivo che dal pianificatore."
},
{
"label": "Ripristino",
"href": "/docs/backup-restore/restoring",
"tail": " — il flusso che utilizza i backup prodotti dalle attività."
}
]
}
}
web/messages/pt/docs/backup-restore/creating-backups.json
+220
View File
@@ -0,0 +1,220 @@
{
"meta": {
"title": "Criação de backups — fluxo de backup interativo ProxMenux",
"description": "O fluxo de backup interativo do ProxMenux: dois pontos de entrada (o menu TUI do Scripts e a interface web do Monitor), três destinos, dois modos de perfil, uma etapa de preparação temporária e uma janela de confirmação. A página descreve a matriz de seis opções, os perfis padrão e personalizado e o que o usuário vê desde a seleção do backup até o arquivo ser salvo no destino.",
"ogTitle": "Backup ProxMenux — criando backups",
"ogDescription": "O fluxo de backup interativo com três destinos, dois perfis e uma etapa comum de preparação temporária.",
"twitterTitle": "Criando backups ProxMenux",
"twitterDescription": "Fluxo de backup interativo com três destinos e dois modos de perfil."
},
"header": {
"title": "Criando backups",
"description": "O fluxo de backup interativo: escolha um destino e um perfil, confira o resumo de confirmação e acompanhe o salvamento do arquivo. Os dois pontos de entrada compartilham o mesmo backend e produzem arquivos idênticos.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Dois pontos de entrada, funcionalidade idêntica",
"body": "A TUI do Scripts e a interface web do Monitor oferecem <strong>exatamente as mesmas funções</strong>. Cada backup — manual ou agendado — passa pela mesma matriz de escolha (três destinos × dois perfis) e chama a mesma função do backend em cada célula (<code>_bk_pbs</code>, <code>_bk_borg</code> ou <code>_bk_local</code>). Os arquivos produzidos pelos dois pontos de entrada são indistinguíveis. A escolha depende da preferência: a TUI é adequada para SSH e scripts; o Monitor oferece controle por cliques junto às visualizações de notificações e acompanhamento dos logs."
},
"entryPoints": {
"heading": "Os dois pontos de entrada",
"rows": [
{
"entry": "ProxMenux Scripts (TUI)",
"path": "menu → Utilities → Host Config Backup",
"detail": "Fluxo baseado em diálogo, SSH-friendly. O menu principal apresenta as seis opções diretamente. Utiliza <code>backup_menu</code> em <code>backup_host.sh</code>."
},
{
"entry": "ProxMenux Monitor (UI Web)",
"path": "Backups tab → Create backup",
"detail": "Fluxo guiado por um assistente. As mesmas seis opções são apresentadas em um formulário de duas etapas (destino → perfil). As mesmas funções do backend são chamadas pela API Flask."
}
]
},
"modes": {
"heading": "Cópias de segurança manuais vs agendadas",
"body": "Os backups podem ser produzidos em dois modos: <strong>manual</strong> (o fluxo interativo descrito nesta página — o usuário escolhe um destino e um perfil de um menu e acompanha o salvamento do arquivo) ou <strong>agendado</strong> (um trabalho sem acompanhamento que roda em um temporizador no estilo cron e aplica a retenção configurada no trabalho). Ambos os modos suportam os mesmos três destinos e os mesmos dois perfis, e ambos estão disponíveis em ambos os pontos de entrada — o menu Scripts TUI e a aba Monitor Backups. Trabalhos agendados usam as mesmas funções de infraestrutura que o fluxo manual através do <code>run_scheduled_backup.sh</code>; os arquivos produzidos são indistinguíveis.",
"seeAlso": "A página de trabalhos agendados cobre o fluxo completo, incluindo como criar um trabalho, anexá-lo a um temporizador existente PVE vzdump e configurar os valores de retenção.",
"monitorAlt": "Página de backups do ProxMenux Monitor que mostra a nova janela de backup agendada com os campos de destino, perfil, agenda e retenção.",
"monitorCaption": "Backup agendado — ProxMenux Monitor. A mesma janela do assistente usada para criar um backup manual inclui, na parte inferior, os campos de agendamento e retenção para execução sem acompanhamento."
},
"matrix": {
"heading": "A matriz de seis opções",
"intro": "A escolha determina tanto o backend executado quanto a estratégia de seleção de caminhos. Consulte as páginas de cada destino para os detalhes de configuração de cada célula.",
"rows": [
{
"combo": "1",
"destination": "PBS",
"profile": "Padrão",
"action": "Envia o perfil padrão mais extras persistentes para um repositório PBS configurado."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Padrão",
"action": "Cria um arquivo com o perfil padrão mais extras persistentes no repositório Borg selecionado."
},
{
"combo": "3",
"destination": "Local",
"profile": "Padrão",
"action": "Escreve um arquivo <code>.tar.zst</code> com o perfil padrão mais extras persistentes para o alvo local configurado."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Personalizado",
"action": "Abre o seletor de caminhos antes do envio ao PBS; o usuário marca os caminhos e pode adicionar novos."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Personalizado",
"action": "Abre o seletor de caminhos antes de criar o arquivo Borg."
},
{
"combo": "6",
"destination": "Local",
"profile": "Personalizado",
"action": "Abre o selecionador de caminho antes de escrever o <code>.tar.zst</code> local."
}
]
},
"profiles": {
"heading": "Perfil padrão vs personalizado",
"defaultTitle": "Perfil padrão",
"defaultBody": "O perfil padrão é a lista com curadoria de <code>hb_default_profile_paths</code> (documentada em <em>Como funciona</em> sob <em>Categorias de caminho</em>) além de cada entrada no arquivo de extras persistente <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. O usuário confirma as opções de destino e criptografia e o backup prossegue sem mais seleção de caminho.",
"customTitle": "Perfil personalizado",
"customBody": "O perfil personalizado abre uma lista com todos os caminhos do perfil padrão (desmarcados) e todos os extras persistentes (pré-marcados, com o prefixo <code>[+]</code>). O usuário marca os caminhos para esta execução e pode pressionar <em>Adicionar caminho personalizado</em> para incluir um novo caminho absoluto. Todo caminho adicionado durante esse processo é salvo em <code>backup-extra-paths.txt</code>, para que os próximos backups o incluam automaticamente. Desmarcar um extra persistente o exclui apenas desta execução, sem removê-lo do arquivo — a remoção é feita pela ação separada <em>Gerenciar caminhos personalizados</em>, fora do fluxo de backup.",
"customPickerAlt": "Lista de verificação de perfil personalizada que mostra os caminhos de perfil padrão (desmarcados) e extras persistentes (pré-marcados com um prefixo [+]), além de botões para adicionar um novo caminho ou confirmar a seleção.",
"customPickerCaption": "Perfil personalizado — o seletor de caminhos. Os caminhos do perfil padrão estão desmarcados; os extras persistentes aparecem pré-marcados com o prefixo [+]. O usuário marca os caminhos para esta execução.",
"manageCustomAlt": "Menu de gerenciamento de caminhos personalizados com a lista de extras persistentes e opções para adicionar, remover ou editar.",
"manageCustomCaption": "Gerencie caminhos personalizados — o ponto de entrada onde extras persistentes são adicionados ou removidos. Cada caminho listado aqui é incluído automaticamente em backups de modo padrão sem precisar abrir o seletor Personalizado."
},
"commonPipeline": {
"heading": "O que é executado independentemente do destino",
"intro": "Depois de definir o perfil, cada backend executa o mesmo processo de preparação temporária antes de seguir para seu próprio método de envio. <code>hb_prepare_staging</code> monta a árvore do arquivo em <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> e preenche cada um dos três blocos de dados.",
"steps": [
{
"step": "1",
"name": "Montagem do rootfs",
"detail": "Executa <code>rsync -a</code> para cada caminho selecionado em <code>staging_root/rootfs/</code>. O banco de dados pmxcfs em <code>/var/lib/pve-cluster/config.db</code> é capturado separadamente via <code>sqlite3 .backup</code> para produzir um instantâneo consistente sem parar o cluster, e os sidecars <code>.db-wal</code> / <code>.db-shm</code> são excluídos do rsync; quando o <code>sqlite3</code> não está disponível é salvo um arquivo <code>config.db.raw-fallback</code>, que a restauração adota como banco de dados durante a importação. Os subcaminhos voláteis (histórico do bash, caches, lixo) são excluídos do <code>/root/</code>. Caminhos ausentes da fonte são registrados em <code>metadata/missing_paths.txt</code> sem parar o backup."
},
{
"step": "2",
"name": "Geração do manifesto",
"detail": "<code>build_manifest.sh</code> coordena os seis coletores e grava <code>manifest.json</code> na raiz da área de preparação temporária. Se um coletor falhar, a seção afetada usa um valor padrão vazio documentado; o manifesto continua válido."
},
{
"step": "3",
"name": "Inventário de pacotes",
"detail": "<code>apt-mark showmanual</code> é capturada literalmente em <code>metadata/packages.manual.list</code>. O estado do componente já está dentro do rootfs restaurado (<code>components_status.json</code>) porque o <code>/usr/local/share/proxmenux/</code> faz parte do perfil padrão."
},
{
"step": "4",
"name": "Informações da execução",
"detail": "<code>metadata/run_info.env</code> registra a identidade de execução de backup — hostname, timestamp, versão do kernel — usada pela verificação de compatibilidade da restauração para determinar a direção do cross-kernel."
},
{
"step": "5",
"name": "Notificação (início)",
"detail": "<code>hb_notify_lifecycle \"start\"</code> é acionado. Se as notificações estiverem configuradas no Monitor, um evento <em>Backup do host iniciado</em> é enviado ao usuário. Nada é enviado se não houver canais configurados."
}
]
},
"included": {
"heading": "O que entra e o que fica fora",
"intro": "Cada caminho no perfil resolvido (padrão + extras persistentes + seleção de modo personalizado) é copiado com <code>rsync -aAXH --numeric-ids</code>. Uma lista de exclusão compartilhada aplica-se a cada caminho, e dois diretórios carregam exclusões adicionais específicas do caminho.",
"globalTitle": "Exclusões globais (aplicadas a cada caminho)",
"globalItems": [
"<code>images/</code> — dumps de imagens.",
"<code>dump/</code> — saídas vzdump.",
"<code>tmp/</code> — ficheiros temporários.",
"<code>*.log</code> — ficheiros de registo."
],
"rootTitle": "Exclusões <code>/root/</code>",
"rootBody": "<code>/root/</code> faz parte do perfil padrão para incluir os scripts e a configuração do usuário no arquivo. Os subcaminhos voláteis são excluídos:",
"rootItems": [
"<code>.bash_history</code>",
"<code>.cache/</code>",
"<code>tmp/</code>",
"<code>.local/share/Trash/</code>"
],
"proxmenuxTitle": "Exclusões <code>/usr/local/share/proxmenux/</code>",
"proxmenuxBody": "Este diretório envia apenas o estado do usuário — <code>components_status.json</code>, preferências, cache pós-instalação. O código que o destino já terá a partir de sua própria instalação ProxMenux está excluído para que uma restauração não sobrescreva os binários atuais do alvo com os mais antigos:",
"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": "Caminhos fora do perfil",
"notInProfileBody": "Qualquer coisa não listada no <code>hb_default_profile_paths</code> e não adicionada como um extra personalizado ou persistente não faz parte do backup. Exemplos notáveis:",
"notInProfileItems": [
"<strong>Discos de VMs e LXC</strong> — manipulado por <code>vzdump</code>, não por esta característica. Os arquivos de configuração de hóspedes sob <code>/etc/pve/nodes/*/qemu-server/*.conf</code> e <code>lxc/*.conf</code> são capturados (eles vivem sob <code>/etc/pve</code>) para que a restauração reproduza o inventário; os próprios discos são re-anexados a partir de um backup existente vzdump/PBS.",
"<strong><code>/boot</code> e <code>/boot/efi</code></strong> — binários do kernel, initramfs e a partição UEFI ESP são regeneradas pelo próprio alvo <code>update-initramfs</code>, <code>update-grub</code> ou <code>proxmox-boot-tool refresh</code> após a restauração. O carregador de arranque nunca é copiado na íntegra.",
"<strong>Sistemas de arquivos de tempo de execução e sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> e <code>/run</code> são pseudo-sistemas de arquivos produzidos pelo kernel e udev; eles não são persistidos em nenhum lugar.",
"<strong>Binários dos pacotes em <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — reinstalados pelo APT do destino a partir de <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — estado de execução por host, não restaurado.",
"<strong><code>/home/USER</code></strong> — não no perfil padrão. Adicione-o como um caminho personalizado quando um sistema carrega diretórios domésticos do usuário que devem sobreviver a uma restauração."
],
"customPathsTitle": "Como os caminhos personalizados são tratados",
"customPathsBody": "Um caminho personalizado adicionado inline em modo Personalizado ou persistido em <code>backup-extra-paths.txt</code> passa pelo mesmo pipeline <code>rsync</code> como caminhos de perfil padrão. Exclusões globais aplicam-se. Se o caminho personalizado estiver sob <code>/root/</code> ou <code>/usr/local/share/proxmenux/</code>, as exclusões específicas do caminho acima ainda se aplicam. Cada caminho arquivado — padrão ou personalizado — é gravado em <code>metadata/paths_archived.txt</code>. Caminhos que não existem na fonte são gravados em <code>metadata/missing_paths.txt</code> sem parar o backup."
},
"archiveStructure": {
"heading": "Estrutura do arquivo",
"intro": "O diretório de preparação temporária produzido por cada infraestrutura segue o mesmo layout, independentemente do destino. O tarball, PBS <code>.pxar</code> ou arquivo Borg armazena esta árvore sem alterações.",
"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": "Resumo da confirmação",
"body": "Antes da infra- estrutura escrever qualquer coisa para o destino, o ProxMenux mostra uma janela sumária com o nome do destino, ID de backup ou arquivo, estado de criptografia e a lista de caminhos copiados. Cancelar aqui aborta o backup de forma limpa — o diretório de preparação temporária é removido pelo gancho <code>trap</code> definido na função de infraestrutura e nenhum dado parcial atinge o destino."
},
"writing": {
"heading": "Gravando para o destino",
"intro": "Após a confirmação, cada backend executa sua própria etapa de gravação. As páginas dos destinos descrevem o funcionamento; os elementos comuns são o log, o arquivo auxiliar e a notificação de conclusão.",
"rows": [
{
"topic": "Arquivo de registro",
"detail": "Cada infra- estrutura escreve sua saída completa para <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> e, em caso de falha, oferece abri-la em uma janela de rolagem. O caminho do log é impresso no resumo de conclusão somente quando o arquivo tem conteúdo."
},
{
"topic": "Sidecar (apenas local)",
"detail": "<code>hb_write_archive_sidecar</code> solta um <code>*.proxmenux.json</code> ao lado do arquivo local para que o monitor o identifique como um backup de host ProxMenux mesmo depois de mover ou renomear."
},
{
"topic": "Notificação (conclusão/falha)",
"detail": "<code>hb_notify_lifecycle \"complete\"</code> ou <code>\"fail\"</code> é acionado com a duração, o tamanho do arquivo e — em caso de falha — a última linha do log que parece indicar um erro."
}
]
},
"finishedScreens": {
"heading": "Como é uma cópia de segurança terminada",
"intro": "O mesmo evento de conclusão é exibido pelos dois pontos de entrada. O TUI escreve um bloco de resumo para o terminal; a aba Backups do Monitor mostra a execução na lista de arquivos com o tamanho, a duração e os crachás de status.",
"scriptsAlt": "ProxMenux Scripts TUI mostrando um backup final do host — destino, ID de backup, caminho de instantâneo, tamanho de dados, duração e estado de criptografia.",
"scriptsCaption": "Cópia de segurança terminada — ProxMenux Scripts (TUI). O bloco de conclusão imprime o destino, backup ID, instantâneo resultante ou nome do arquivo, tamanho dos dados, duração e estado de criptografia.",
"monitorAlt": "Página de backups ProxMenux Monitor mostrando uma entrada de backup de host terminada com tamanho, duração, crachá de método e indicador de criptografia.",
"monitorCaption": "Backup concluído — aba Backups do ProxMenux Monitor. O novo backup aparece na lista de arquivos com o indicador do método de destino, tamanho, duração e — quando aplicável — o ícone de cadeado da criptografia."
},
"whereNext": {
"heading": "Para onde ir a seguir",
"items": [
{
"label": "Destinos",
"href": "/docs/backup-restore/destinations",
"tail": " — detalhes de configuração para Local, PBS e Borg."
},
{
"label": "Trabalhos agendados",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": " — executar o mesmo backup sem acompanhamento em um cronograma em vez de interativamente."
},
{
"label": "Restauração",
"href": "/docs/backup-restore/restoring",
"tail": " — o fluxo que consome o que esta página produz."
}
]
}
}
web/messages/pt/docs/backup-restore/cross-kernel.json
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Restauro entre kernels diferentes — deteção, filtragem segura e adaptação | ProxMenux",
"description": "Como ProxMenux restaura um backup de host em um alvo executando uma versão diferente do kernel principal. Documenta como a direção do descompasso é detectada, o filtro seguro-subset que salta caminhos de inicialização-críticos quando o alvo executa um kernel mais novo do que o backup, e a hidratação quatro fases do kernel-agnóstico que reaplica a sintonia do usuário como IOMMU, IDs VFIO e tokens personalizados cmdline sem copiar arquivos de kernel-ligados verbatim.",
"ogTitle": "ProxMenux Backup – restauração e hidratação do kernel cruzado",
"ogDescription": "Restauração entre versões do kernel que considera a direção da mudança, com filtro seguro e hidratação independente do kernel.",
"twitterTitle": "Restauro entre kernels diferentes | ProxMenux",
"twitterDescription": "Como ProxMenux lida com uma restauração quando o kernel alvo difere do backup."
},
"header": {
"title": "Restauração do kernel cruzado",
"description": "Como o ProxMenux lida com uma restauração quando o host alvo executa um kernel diferente daquele gravado no backup — especialmente quando o alvo executa um kernel mais recente. Documenta como a diferença é detectada, como caminhos críticos de inicialização que podem quebrar o alvo são filtrados, e como a configuração do próprio usuário é reaplicada sem copiar arquivos ligados ao kernel verbatim.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Cada salto do kernel é tratado de forma diferente",
"body": "O kernel de um host Proxmox é identificado por uma string de versão como <code>6.17.13-2-pve</code>. Os dois primeiros números (<strong>6.17</strong> neste exemplo) definem a versão principal: quando eles mudam, alguns arquivos de configuração escritos para o kernel anterior podem não ser válidos no novo. Quando a restauração detecta que o backup e o alvo têm diferentes versões principais do kernel, os ramos de fluxo baseados na direção do salto — se o backup é mais antigo ou mais recente do que o alvo — porque os dois casos têm modos de falha opostos. Backups mais recentes do que o destino restaurar limpamente como-is (bench-verified em vários saltos do kernel). Backups mais antigos do que o alvo precisam de um filtro para evitar quebrar a inicialização do alvo com configuração escrita para um kernel que desde então mudou."
},
"directionCheck": {
"heading": "Verificação da direcção",
"intro": "Durante a verificação de compatibilidade, <code>hb_compat_check</code> compara o kernel registrado no manifesto do backup com o kernel atual do alvo (<code>uname -r</code>) e classifica a restauração em um dos três casos, armazenados na variável interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{
"direction": "same",
"condition": "A versão principal do kernel corresponde entre backup e alvo.",
"behavior": "O fluxo total de restauração corre inalterado. Sem filtro extra, sem hidratação, sem aviso especial na UI."
},
{
"direction": "bk_newer",
"condition": "O kernel de backup é mais novo do que o do alvo (por exemplo: o backup foi feito no kernel 7.0 e o alvo executa o kernel 6.17).",
"behavior": "O fluxo completo permanece inalterado, como em <code>same</code>, sem filtro. Nos testes relatados, os drivers foram reinstalados para o kernel de destino, a configuração IOMMU foi aplicada e as VMs iniciaram com passthrough de GPU."
},
{
"direction": "bk_older",
"condition": "O kernel do backup é MAIS ANTIGO que o de destino (por exemplo: backup no 6.17, destino no 7.0).",
"behavior": "O filtro seguro e a hidratação em quatro fases abaixo são ativados. A restauração prossegue — o alvo reproduz a fonte, mas os arquivos de inicialização críticos não são copiados literalmente."
}
]
},
"whyBkNewerIsSafe": {
"heading": "Por que um backup com um kernel mais novo do que o alvo restaura inalterado",
"body": "Quando a restauração corre contra um alvo com um kernel <em>mais antigo</em> do que o registrado no backup, cada mecanismo que a restauração depende é independente da versão do kernel. Os instaladores de driver GPU e outros instaladores de dispositivos PCI detectam o kernel em execução com <code>uname -r</code> e compilam DKMS contra qualquer que seja o alvo. O pacote APT install puxa binários construídos para a distribuição do alvo. Os tokens cmdline IOMMU como <code>intel_iommu=on</code> são estáveis nas principais versões do kernel. O backup carrega caminhos escritos sob um kernel mais recente, mas esses caminhos (listas-negra de módulos, padrões GRUB, configuração initramfs) ainda são sintaxe válida no antigo - kernels ignoram tokens que não reconhecem em vez de falhar. Este caso é, na prática, equivalente a uma restauração do mesmo núcleo, e o ProxMenux trata-o como tal."
},
"safeSubsetFilter": {
"heading": "O filtro de segurança (apenas quando o kernel alvo é mais novo)",
"intro": "Quando o kernel alvo é mais novo do que o backup, a verificação de compatibilidade adiciona 16 Caminhos críticos de arranque de <code>hb_unsafe_paths_cross_version</code> para <code>RS_SKIP_PATHS</code>. Estes caminhos são excluídos da restauração porque escrever uma versão deles de um kernel mais antigo sobre um alvo executando um mais recente causou pânico do kernel em testes de banco. Os caminhos abrangem cinco categorias:",
"categoryRows": [
{
"category": "Gestor de arranque",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB predefinições ligadas à ordem anterior do kernel, e estado proxmox-boot-tool (cmdline, ESP UUIDs, ganchos) que referencia caminhos e identificadores da instalação mais antiga."
},
{
"category": "Módulos de kernel e artefatos de inicialização",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Listas de autocarregamento que podem referenciar módulos renomeados entre majors de kernel, opções de módulo que podem não se aplicar, ganchos initramfs escritos para o kernel antigo."
},
{
"category": "Stack de armazenamento e identidade do sistema de arquivos",
"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 que podem não existir nesta instalação, drivers multicaminho que mudam entre kernels, parâmetros iSCSI que evoluem, regras udev que podem se ligar a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que podem bloquear o pool como estrangeiro."
},
{
"category": "Fontes APT",
"paths": "<code>/etc/apt</code>",
"reason": "As suítes de código fonte APT podem desencadear uma redução de pacotes críticos na próxima atualização."
},
{
"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": "Sobrescritas de unidades e links .wants ligados à versão principal antiga do systemd; chaves de configuração que podem não ser válidas na versão nova."
}
],
"outroBody": "O filtro é executado ANTES da janela de confirmação para que o utilizador veja a lista exacta dos caminhos que serão ignorados, categorizados pela razão. A restauração continua — tudo o resto (configuração VM/LXC, rede, /etc/pve, usuários, cron, ProxMenux estado, pacotes, drivers, /root) é restaurado normalmente."
},
"hydration": {
"heading": "Hidratação independente do kernel",
"intro": "O filtro omite arquivos críticos; a hidratação reaplica ajustes selecionados: cmdline IOMMU, IDs VFIO, <code>GRUB_TIMEOUT</code> personalizado e listas de bloqueio nvidia. Executa se o kernel de destino for mais novo. A mesclagem cmdline preserva chaves do destino e adiciona módulos ausentes. Valores GRUB e arquivos permitidos podem substituir conteúdo diferente no destino. Repetir as mesmas entradas é idempotente.",
"phaseRows": [
{
"phase": "1a — Via GRUB",
"detail": "Para hosts GRUB (instalações ext4/lvm). <code>_rs_hyd_grub</code> mescla os parâmetros de <code>manifest.kernel_params.cmdline_extra</code> do backup em <code>GRUB_CMDLINE_LINUX_DEFAULT</code> do destino, ignorando chaves já presentes. Depois restaura as chaves permitidas <code>GRUB_*</code> (<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>) de <code>/etc/default/grub</code> do backup se seus valores diferirem do destino."
},
{
"phase": "1b — systemd-boot / ZFS",
"detail": "Para systemd-boot (normalmente ZFS na raiz). <code>_rs_hyd_kernel_cmdline</code> mescla parâmetros do usuário de <code>cmdline_extra</code> em <code>/etc/kernel/cmdline</code> do destino, preservando os parâmetros de inicialização <code>root=</code>, <code>boot=</code> e <code>rootflags=</code> do destino."
},
{
"phase": "2 — fusão /etc/modules",
"detail": "<code>_rs_hyd_modules</code> adiciona os módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estão na lista branca (<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>) E ainda não está presente no objectivo <code>/etc/modules</code>."
},
{
"phase": "3 — Cópia de ficheiros na lista branca",
"detail": "<code>_rs_hyd_files</code> copia arquivos criados pelo usuário dos rootfs de estadiamento para o alvo ao vivo quando o conteúdo difere. A lista branca abrange arquivos VFIO/nvidia/blacklist sob <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, e a regra de ligação ProxMenux VFIO + nvidia regras udev sob <code>/etc/udev/rules.d</code>. Arquivos distro-proprietários (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) são intencionalmente excluídos — seu conteúdo evolui entre lançamentos."
},
{
"phase": "4 — Forçar regeneração após a inicialização",
"detail": "As quatro fases escrevem diretamente para o alvo vivo fora do processo de restauração normal. Para fazer com que os tokens/módulos/arquivos fundidos façam efeito na próxima inicialização, o <code>HB_HYDRATION_APPLIED=1</code> propaga-se através do <code>plan.env</code> ao <code>apply_pending_restore.sh</code>, que força o <code>NEEDS_INITRAMFS=1</code> e o <code>NEEDS_GRUB=1</code> independentemente do que estava na lista de aplicações. O expedidor pós-boot regenera initramfs e atualiza o carregador de boot."
}
]
},
"planCommit": {
"heading": "Plano vs commit — o utilizador vê uma antevisão primeiro",
"body": "A hidratação funciona em dois modos. Antes da janela de confirmação, o ProxMenux executa o <code>_rs_apply_bk_older_hydration</code> no modo <code>plan</code>: calcula exatamente o que seria mesclado, povoa o <code>RS_HYDRATION_SUMMARY</code> com um bloco verde listando cada ação e retorna sem escrever. O diálogo de confirmação mostra que o bloco verde ao lado da lista amarela dos caminhos excluídos, para que o usuário veja ANTES o que será reaplicado automaticamente. Depois que o usuário confirma, o ProxMenux executa novamente o mesmo helper no modo <code>commit</code> — as mesmas fases, a mesma lógica, mas desta vez cada fase escreve para o alvo ao vivo. Cancelar a janela de confirmação deixa o alvo intocado."
},
"flowDiagram": {
"heading": "O fluxo quando o kernel alvo é mais novo do que o backup",
"intro": "Os passos adicionados quando o kernel alvo é mais novo sentam-se dentro do fluxo de restauração normal. Tudo o resto — aplicar, preparar, instalar o pacote, enviar pós-boot — é executado de forma idêntica a uma restauração do mesmo kernel.",
"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": "Exemplos concretos",
"intro": "O passe de hidratação não é abstrato — produz resultados observáveis e corretos para cenários comuns. Dois exemplos que a hidratação manuseia automaticamente:",
"rows": [
{
"scenario": "Passagem GPU (VFIO)",
"detail": "Fonte: <code>intel_iommu=on iommu=pt</code> no cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> no <code>/etc/modules</code>, um <code>/etc/modprobe.d/vfio.conf</code> com <code>options vfio-pci ids=10de:2216</code>, e um <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. A hidração funde os tokens cmdline com o GRUB ou o kernel cmdline do alvo, adiciona os módulos vfio ao <code>/etc/modules</code> e copia os dois arquivos modprobe do usuário. Na próxima inicialização, o IOMMU está ativo, os módulos VFIO são carregados, o GPU está ligado ao vfio-pci e o VM vem com o trabalho de passagem."
},
{
"scenario": "Por omissão personalizada do GRUB",
"detail": "Fonte: <code>GRUB_TIMEOUT=1</code> e <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration lê ambas as chaves do <code>/etc/default/grub</code>, vê que elas diferem dos padrões da instalação recente, e reescreve essas duas linhas no arquivo do alvo (deixando tudo, incluindo o <code>GRUB_DISTRIBUTOR</code>, intocado)."
}
]
},
"callout": {
"warningTitle": "O que a hidratação não reaplica quando o kernel alvo é mais novo",
"warningBody": "A hidratação reaplica apenas a configuração ProxMenux sabe ser segura em todas as versões do kernel: tokens IOMMU, IDs VFIO, chaves GRUB permitidas e módulos de uma lista fixa (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Qualquer coisa fora desse conjunto — ganchos de initramfs personalizados sob <code>/etc/initramfs-tools/hooks/</code>, arquivos não listados em <code>/etc/modprobe.d/</code>, sobreposições de unidades systemd criadas pelo usuário — permanece excluída. A razão é concreta: esses arquivos podem chamar de interfaces internas do kernel (a APIs de módulo, layout <code>/sys</code>, ganchos <code>udev</code>) que mudam entre as versões principais, e aplicá-las literalmente sobre o kernel mais novo pode impedir que o alvo arranque. Quando a reprodução exata da cadeia de inicialização é necessária, a restauração deve ser executada em um host com a mesma versão principal do kernel que o backup."
},
"codeReference": {
"heading": "Onde vivem os mecanismos",
"intro": "Para os desenvolvedores que procuram rastrear ou estender o comportamento do cross-kernel:",
"rows": [
{
"component": "Detecção da direcção",
"location": "<code>hb_compat_check</code> em <code>lib_host_backup_common.sh</code>. Define <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Lista de caminhos do filtro seguro",
"location": "<code>hb_unsafe_paths_cross_version</code> em <code>lib_host_backup_common.sh</code>. Emite <code>path\\treason</code> linhas usadas tanto pelo filtro CLI como pelo endpoint da Web <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Fases de hidratação",
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> em <code>backup_host.sh</code>. Orquestrado por <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Regeneração forçada após a inicialização",
"location": "<code>apply_pending_restore.sh</code> lê <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> e força <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Visualização da Web",
"location": "<code>/api/host-backups/restore/prepare</code> em <code>flask_server.py</code>. Carrega a biblioteca auxiliar, executa <code>_rs_apply_bk_older_hydration</code> no modo plano, retorna as ações para o modal Web."
}
]
},
"whereNext": {
"heading": "Para onde ir a seguir",
"items": [
{
"label": "Restauração",
"href": "/docs/backup-restore/restoring",
"tail": " — o fluxo completo de restauração que integra os mecanismos desta página."
},
{
"label": "Como funciona",
"href": "/docs/backup-restore/how-it-works",
"tail": " — manifesto e coletores que produzem o bloco <code>kernel_params</code> lido pela hidratação."
}
]
}
}
web/messages/pt/docs/backup-restore/destinations/borg.json
+234
View File
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Destino Borg — tipos de repositório, autenticação SSH, criptografia | ProxMenux",
"description": "O destino Borg grava backups do host ProxMenux em um repositório local, em disco externo montado ou em servidor remoto via SSH. Descreve a busca pelo executável borg, as quatro opções iniciais de chave SSH, a criptografia repokey, os destinos salvos e a retenção por tarefa agendada.",
"ogTitle": "Cópia de segurança do ProxMenux — destino Borg",
"ogDescription": "Como ProxMenux escreve backups de host para repositórios Borg, com estratégias de autenticação SSH e criptografia repokey.",
"twitterTitle": "Destino de backup Borg | ProxMenux",
"twitterDescription": "Repositórios Borg locais, USB e SSH para backups de host."
},
"header": {
"title": "Borg",
"description": "O destino Borg escreve backups de host para um repositório Borg. Três tipos de repositório são suportados: caminho local do sistema de arquivos, disco externo montado, ou servidor remoto via SSH. Deduplicação de nível de chunk em todos os arquivos no repositório e criptografia opcional repokey.",
"section": "Cópias de segurança e restauro"
},
"aboutBorg": {
"heading": "O que é Borg",
"body": "Borg (também escrito BorgBackup) é uma ferramenta de backup de desduplicação de código aberto mantida pela comunidade Borg Backup. Ele armazena todos os arquivos como um conjunto de blocos de comprimento variável dentro de um repositório; blocos são compartilhados entre os arquivos, então fazer o backup de dados inalterados tem custo de armazenamento quase zero. Borg não está ligado ao Proxmox — é uma ferramenta de backup de propósito geral usada em muitos ambientes. ProxMenux usa-o como um dos três destinos para backups de host; cada mecanismo Borg-específico descrito nesta página (tipos de repositório, borg-serve sobre SSH, criptografia repokey, prune) é o comportamento padrão Borg."
},
"intro": {
"title": "Deduplicação por blocos com repositórios locais ou acessíveis via SSH",
"body": "Um repositório Borg armazena blocos compartilhados entre todos os seus arquivos de backup. Repetir o backup de um arquivo inalterado não transfere nem armazena novos dados. O ProxMenux usa <code>borg create</code> para o backup e <code>borg extract</code> para a restauração. O repositório pode estar no mesmo sistema de arquivos da origem, em disco externo montado ou em host remoto acessível via SSH."
},
"binarySourcing": {
"heading": "O binário borg",
"intro": "Borg não é uma dependência de base do instalador ProxMenux. Quando um backup é executado, o <code>hb_ensure_borg</code> resolve o binário de quatro fontes em ordem e retorna o primeiro que funciona:",
"rows": [
{
"priority": "1",
"source": "Sistema <code>borg</code>",
"detail": "Se o host já tem <code>borg</code> instalado via APT (<code>which borg</code> resolve), esse binário é usado."
},
{
"priority": "2",
"source": "Cache 'State-dir'",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — mantido de um anterior download GitHub neste host."
},
{
"priority": "3",
"source": "Pacote AppImage do Monitor",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — o AppImage agrupa um borg-linux64 assinado. Este é o caminho offline: um host sem internet ainda tem um <code>borg</code> funcionando."
},
{
"priority": "4",
"source": "Transferência do GitHub",
"detail": "<code>wget</code> contra a URL <code>borg-linux64</code> fixada em <code>github.com/borgbackup/borg/releases/</code>, verificada contra uma constante SHA-256 em <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). No checksum descompasso o binário é descartado e o backup aborta. O arquivo baixado é armazenado em cache na dir estado para backups subsequentes usar caminho 2."
}
]
},
"repoTypes": {
"heading": "Tipos de repositório",
"intro": "O tipo de repositório é escolhido quando um alvo é adicionado. Cada tipo resolve para um URL de repositório diferente que Borg entende.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "O repositório vive em um servidor remoto que executa <code>borg serve</code>. Requer uma conexão SSH para esse servidor."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "O repositório vive em um disco externo montado (tipicamente USB). A montagem é resolvida via <code>hb_prompt_mounted_path</code>, que detecta, monta ou formata partições USB conforme necessário."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "O repositório vive numa pasta local. Significativo apenas quando o diretório alvo está em um disco físico separado — um repositório no mesmo disco que a fonte protege contra o erro do operador, mas não contra a falha do disco."
}
]
},
"serverSetup": {
"heading": "Preparando o servidor Borg (lado do servidor)",
"intro": "O tipo de repositório <code>remote</code> exige um servidor Borg funcional acessível via SSH. O ProxMenux não configura o servidor; apenas autoriza uma chave em uma conta existente. Esta seção descreve os requisitos antes da conexão.",
"hostChoicesTitle": "Onde o servidor pode viver",
"hostChoicesBody": "Qualquer host Linux com acesso SSH se qualifica. Configuração comum:",
"hostChoicesItems": [
"Um NAS dedicado ou caixa de backup (Debian, Ubuntu, TrueNAS SCALE com uma shell).",
"Um recipiente LXC dentro de um nó Proxmox. Pegada pequena, isolada do hospedeiro a executar os backups.",
"Outro host Proxmox na mesma LAN, ou um VM em qualquer lugar acessível sobre SSH."
],
"lxcWarningTitle": "LXC como servidor Borg",
"lxcWarningBody": "Se o servidor Borg estiver em um LXC, generate-auto exige uma conta que aceite autenticação SSH por senha para instalar a chave. Caso contrário, use a instalação manual ou a alternativa generate-pct pelo host PVE.",
"requirementsTitle": "Requisitos no servidor",
"requirementsRows": [
{
"requirement": "Executável borg em <code>/usr/bin/borg</code>",
"detail": "A linha <code>command=\"/usr/bin/borg serve ...\"</code> gravada pelo ProxMenux em <code>authorized_keys</code> usa esse caminho fixo. A instalação via APT (<code>apt install borgbackup</code>) coloca o executável ali. Um binário independente precisa de um link simbólico em <code>/usr/bin/borg</code>."
},
{
"requirement": "Uma conta de usuário dedicada (tipicamente <code>borg</code>)",
"detail": "Possui o diretório do repositório e recebe conexões SSH recebidas. Não precisa de acesso sudo ou shell — a linha authorized_keys desativa shells interativos de qualquer maneira."
},
{
"requirement": "Um diretório de repositório com escrita",
"detail": "O caminho que o operador dá ProxMenux (por exemplo <code>/backup/borgbackup</code>) deve existir no servidor e ser propriedade do usuário borg."
},
{
"requirement": "O servidor SSH aceita o usuário borg",
"detail": "<code>PubkeyAuthentication yes</code> (padrão). A autenticação por senha só é necessária para instalar a chave pelo fluxo <em>generate-auto</em>. Depois disso, o servidor pode desativar completamente a autenticação por senha."
}
],
"minimalSetupTitle": "Configuração mínima do servidor",
"minimalSetupBody": "Em um servidor Debian ou Ubuntu Borg, uma linha de base de trabalho é quatro comandos como root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Com o servidor preparado e a autenticação SSH por senha disponível, <code>generate-auto</code> instala a chave por uma conta que possa gravar em authorized_keys do usuário borg. Os backups seguintes usam essa chave, restrita a <code>borg serve</code> no caminho configurado. Sem acesso por senha, instale-a manualmente ou pelo host PVE."
},
"sshAuth": {
"heading": "Autenticação SSH (lado cliente)",
"intro": "Repositórios Borg remotos são acessados sobre SSH. A conexão é executada do host ProxMenux para uma conta de usuário no servidor Borg que executa o <code>borg serve</code>. Este usuário é tipicamente chamado <code>borg</code>, NÃO o administrador/root usuário do servidor — a linha de comando borg-serve bloqueia a conexão com esse caminho específico do repositório (veja as estratégias chave abaixo).",
"strategiesTitle": "Estratégias de chave SSH",
"strategiesIntro": "Ao adicionar um destino remoto, o ProxMenux pede usuário SSH, host e caminho remoto e oferece quatro opções de autenticação. A alternativa generate-pct é oferecida quando o acesso por senha é recusado. Os modos são descritos abaixo:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Recomendado",
"detail": "O ProxMenux gera ou reutiliza um par de chaves ed25519 em <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> e usa <code>sshpass</code> para testar o acesso e instalar a chave pública em <code>~borg/.ssh/authorized_keys</code>. A senha pertence a uma conta com permissão para gravar esse arquivo, normalmente root ou borg. Ela é usada durante a configuração e não é salva."
},
{
"mode": "generate-manual",
"label": "Sem senha de administração nesta máquina",
"detail": "ProxMenux gera o keypair como acima, mas exibe a linha <code>authorized_keys</code> completa para o operador colar manualmente no servidor. A senha de administrador nunca deixa o host ProxMenux porque nunca é solicitado."
},
{
"mode": "generate-pct",
"label": "O servidor Borg é um PVE LXC",
"detail": "O servidor Borg é executado dentro de um LXC em um nó PVE. ProxMenux autoriza a chave via <code>pct exec</code> do host PVE — root no host PVE escreve no LXC <code>~borg/.ssh/authorized_keys</code> sem precisar de SSH no próprio LXC."
},
{
"mode": "existing",
"label": "Usar uma chave existente",
"detail": "O ProxMenux procura em <code>/root/.ssh/</code> e <code>$HOME/.ssh/</code> chaves privadas ed25519/RSA que consiga interpretar e as lista. O operador escolhe uma ou indica manualmente um caminho não padrão."
},
{
"mode": "none",
"label": "Configuração padrão do SSH",
"detail": "Nenhuma chave personalizada — Borg depende da configuração padrão SSH da máquina (tipicamente <code>~/.ssh/id_rsa</code> ou um agente SSH)."
}
],
"restrictTitle": "A linha authorized_keys",
"restrictBody": "Para cada chave gerada, a linha <code>authorized_keys</code> gravada pelo ProxMenux no servidor restringe a chave a esta chamada de borg-serve no caminho configurado do repositório:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "O <code>command=</code> força cada sessão de SSH usando esta chave para executar apenas o comando borg-serve; <code>restrict</code> desativa o encaminhamento de portas, o encaminhamento de agentes, o encaminhamento de X11 e a alocação de PTY. A chave não pode ser usada para abrir uma shell interativa no servidor ou para acessar qualquer outro caminho do repositório, mesmo que a conta tenha privilégios mais amplos."
},
"savedTargets": {
"heading": "Alvos salvos",
"intro": "Um destino salvo mantém a configuração do repositório com um nome reconhecível, evitando digitar os dados novamente. Arquivos no diretório de estado do ProxMenux:",
"rows": [
{
"file": "borg-targets.txt",
"content": "Uma linha por destino: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> lê o arquivo para preencher o menu de seleção de destinos."
},
{
"file": "borg-pass-NAME.txt",
"content": "Frase secreta do destino identificado acima por NAME (<code>chmod 600</code>). Presente somente quando se escolhe criptografia repokey."
}
],
"outro": "Salvar o destino é opcional. Recusar não grava a configuração com nome, mas não remove uma chave SSH gerada. Se repokey for ativado sem destino salvo, o ProxMenux ainda guarda a frase secreta no arquivo legado borg-pass.txt."
},
"encryption": {
"heading": "Criptografia",
"body": "Os repositórios são inicializados com um modo de criptografia via <code>hb_borg_init_if_needed</code>: o moderno <code>borg repo-create -e MODE</code> quando disponível, ou o legado <code>borg init --encryption=MODE</code>. ProxMenux expõe dois modos: <code>repokey</code> (padrão) e <code>none</code>. No modo <code>repokey</code> Borg armazena a chave de criptografia dentro do próprio repositório; o acesso requer uma frase-passe, que ProxMenux pede duas vezes com validação de correspondência e armazena em <code>borg-pass-NAME.txt</code> para destinos salvos, ou no arquivo legado descrito acima. Uma janela de reconhecimento obrigatória é mostrada após a frase- senha ser salva: a frase- senha é a única maneira de acessar os arquivos criptografados, e perdê- la torna cada arquivo no repositório irrecuperável."
},
"runtimeEnv": {
"heading": "Ambiente de execução",
"intro": "ProxMenux exporta as seguintes variáveis de ambiente antes de invocar <code>borg</code>. Eles configuram a conexão e desbloqueiam o repositório sem incorporar segredos na linha de comando.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Comando remoto usado pelo Borg para repositórios SSH. Uma chave selecionada acrescenta as opções de identidade; uma porta diferente da padrão acrescenta -p PORT. Sem chave personalizada e com a porta padrão, a variável fica indefinida e o Borg usa a configuração SSH do host."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passfrase de borg-pass-NAME.txt)",
"purpose": "Desbloqueia a chave repokey. Configure apenas quando o alvo usar criptografia <code>repokey</code>. Nunca aparece na lista de argumentos do processo."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Usado pelo <code>hb_borg_init_if_needed</code> ao inicializar um repositório que ainda não existe. Ignorado pelo <code>borg create</code> nos repositórios existentes."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime o prompt interativo que Borg levanta quando o URL do repositório difere do URL que foi originalmente alcançado (comum após um renomeamento de ponto de montagem ou SSH-host acessível via novo endereço)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime o prompt interativo Borg levanta a primeira vez que um repositório não criptografado é acessado de um novo cliente."
}
]
},
"archiveFormat": {
"heading": "Nome e retenção do arquivo",
"intro": "Cada backup cria um novo arquivo dentro do repositório.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "Para trabalhos agendados, o <code>run_scheduled_backup.sh</code> executa <code>borg prune</code> contra o repositório após cada backup bem sucedido com os valores de retenção configurados no trabalho (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Os backups interativos não removem backups antigos."
},
"restoreAccess": {
"heading": "Obtenção no lado da restauração",
"body": "A restauração lista os arquivos com <code>borg list REPO</code> e extrai o selecionado com <code>borg extract REPO::ARCHIVE-NAME</code> em um diretório de preparação. <code>_rs_check_layout</code> o encaminha ao processo padrão de restauração. Os mesmos comandos funcionam manualmente fora do ProxMenux; a árvore extraída tem a estrutura de três blocos descrita em <em>Como funciona</em>."
},
"references": {
"heading": "Referências",
"intro": "Documentação oficial do Borg para os componentes usados pelo ProxMenux.",
"items": [
{
"label": "Documentação Borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": " — ponto de entrada principal que abrange conceitos, implantação, arranque rápido e todos os comandos."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " — o comando usado pelo ProxMenux em cada backup, com todas as opções aceitas."
},
{
"label": "Criptografia do repositório",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": " — os modos de criptografia aceitos pelo Borg, incluindo repokey, usado por padrão pelo ProxMenux."
},
{
"label": "borg serve e implantação via SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — configuração de um servidor Borg central acessível via SSH, incluindo o comando borg-serve e a opção restrict-to-path que o ProxMenux grava em authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — o modelo de retenção de --keep-last / --keep-daily / --keep-weekly aplicado pelo ProxMenux em cada tarefa agendada."
}
]
}
}
web/messages/pt/docs/backup-restore/destinations/index.json
+110
View File
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Destinos das cópias de segurança — arquivo local, Proxmox Backup Server e Borg | ProxMenux",
"description": "Três backends de armazenamento recebem a mesma carga útil de backup ProxMenux: um arquivo .tar.zst local em qualquer sistema de arquivos com permissão de gravação, um backup PBS em uma datastore Proxmox Backup Server, ou um arquivo Borg em um repositório Borg local ou remoto. Cada infra-estrutura tem suas próprias características de compressão, desduplicação, criptografia e rede.",
"ogTitle": "Destinos de backup do ProxMenux",
"ogDescription": "Local, Proxmox Backup Server e Borg — três backends de armazenamento para a mesma carga útil de backup do host.",
"twitterTitle": "Destinos de backup do ProxMenux | ProxMenux",
"twitterDescription": "Arquivos locais, infraestruturas Proxmox Backup Server e Borg para backups de host."
},
"header": {
"title": "Destinos",
"description": "Três backends de armazenamento suportados pelo ProxMenux Backup: arquivo local, Proxmox Backup Server (recomendado) e Borg. Cada um recebe o mesmo arquivo de três blocos de dados; eles diferem em formato de armazenamento, deduplicação, modelo de criptografia e requisitos de rede.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Mesmo conteúdo, três backends",
"body": "Cada backup produz as mesmas três cargas (rootfs, manifesto, aplicações). O que muda entre destinos é como essas cargas são armazenadas e como o operador as recupera para uma restauração. Cada infra-estrutura é implementada como uma função separada em <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — mas todos os três compartilham a mesma etapa de preparação temporária (<code>hb_prepare_staging</code>) e o mesmo caminho de restauração de código. A escolha de destino apenas afeta a escrita e a recuperação; ela não altera o que uma restauração faz ou como consome o arquivo."
},
"comparison": {
"heading": "Comparação de características",
"intro": "A tabela a seguir lista as diferenças concretas entre as três infra-estruturas como se comportam hoje em ProxMenux. Todos os valores descrevem o comportamento observado da própria infra-estrutura, não as recomendações editoriais.",
"rows": [
{
"feature": "Formato de armazenamento",
"local": "Um ficheiro <code>.tar.zst</code> (ou <code>.tar.gz</code> se o <code>zstd</code> estiver ausente).",
"pbs": "Backup PBS (blocos <code>.pxar</code> no datastore).",
"borg": "Arquivo Borg dentro de um repositório Borg (arquivos de segmentos)."
},
{
"feature": "Compressão",
"local": "zstd (nível padrão) via <code>tar --zstd</code>. gzip fallback.",
"pbs": "Gerenciada pelo proxmox-backup-client. O ProxMenux não altera as configurações de compressão.",
"borg": "Compressão integrada do Borg. O ProxMenux chama borg create sem alterar as configurações de compressão."
},
{
"feature": "Desduplicação",
"local": "Nenhuma. Cada backup é um arquivo independente completo.",
"pbs": "Deduplicação completa por blocos entre todos os backups no datastore.",
"borg": "Deduplicação completa por blocos entre todos os arquivos do repositório."
},
{
"feature": "Criptografia em repouso",
"local": "Nenhum (depende da proteção do sistema de arquivos).",
"pbs": "Criptografia opcional do lado do cliente com um arquivo de chave. Quando ativada, o blob de recuperação é enviado em um grupo de backup separado.",
"borg": "Criptografia opcional repokey (chave armazenada no repo, desbloqueada por uma frase- senha)."
},
{
"feature": "Retenção / limpeza",
"local": "Aplicada por trabalho agendado via <code>KEEP_LAST</code>. Os arquivos antigos são removidos junto com seus arquivos auxiliares e logs de execução. Os backups interativos não fazem limpeza.",
"pbs": "Aplicado por trabalho programado via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Os backups interativos não fazem limpeza.",
"borg": "Aplicado por trabalho programado via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Os backups interativos não fazem limpeza."
},
{
"feature": "Rede",
"local": "Nenhuma. Escreve para um ponto de montagem local (tipicamente um disco interno ou uma unidade USB).",
"pbs": "TCP para o servidor PBS (porta padrão 8007). Requer credenciais PBS + impressão digital.",
"borg": "Localização local do sistema de ficheiros ou túnel SSH para uma máquina Borg remota."
},
{
"feature": "Dependências",
"local": "<code>tar</code>, <code>zstd</code> (presente no Proxmox por padrão).",
"pbs": "Pacote <code>proxmox-backup-client</code> (incluído no Proxmox VE 8+).",
"borg": "binário <code>borg</code>. Auto-fornecido por ProxMenux do pacote Monitor AppImage quando faltando."
},
{
"feature": "Acesso para restauração",
"local": "Qualquer máquina com tar+zstd pode extrair o arquivo. Não é necessário PBS/Borg.",
"pbs": "Requer <code>proxmox-backup-client</code>, credenciais PBS e o arquivo de chave (se o backup estiver criptografado).",
"borg": "Requer <code>borg</code> + o caminho do repositório + a senha (se criptografada)."
}
],
"captionCode": "feature",
"captionLocal": "Local",
"captionPbs": "Proxmox Backup Server (recomendado)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "A disposição do arquivo não muda com o destino",
"body": "Dentro de qualquer um dos três destinos, o mesmo <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> layout descrito em <em>Como funciona</em> está presente. Um <code>.tar.zst</code> extraído de um arquivo local, um <code>.pxar</code> restaurado de PBS, e um arquivo Borg extraído com <code>borg extract</code> todos produzem uma árvore de diretórios idêntica. O caminho do código de restauração (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lê as mesmas três cargas úteis sem saber de que destino vieram."
},
"extractStandalone": {
"heading": "Extraindo um backup fora de ProxMenux",
"intro": "Qualquer um dos três formatos de arquivo pode ser lido com ferramentas padrão sem ProxMenux instalado no host de leitura. Os comandos abaixo produzem a mesma árvore de diretórios que uma restauração consome internamente.",
"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": "# De um arquivo Borg (requer borg e a senha dos repositórios criptografados):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Em um repositório remoto acessível por SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "A árvore extraída pode então ser inspecionada manualmente ou alimentada a uma restauração manual. Veja as páginas de destino individuais para o fluxo de recuperação exato que o ProxMenux usa sob o capô."
},
"whereNext": {
"heading": "Detalhes por destino",
"intro": "Cada destino tem sua própria página cobrindo o fluxo de configuração, o formato on-disk e o comando de recuperação usado pela restauração.",
"items": [
{
"label": "Arquivo local",
"href": "/docs/backup-restore/destinations/local",
"tail": " — pré-configurando um alvo local, montagem da unidade USB, a verificação de segurança contra a gravação do arquivo em si, o sidecar JSON que permite ao Monitor identificar o arquivo."
},
{
"label": "Proxmox Backup Server (recomendado)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — seleção de datastore, credenciais e impressão digital, ciclo de vida do arquivo de chave de criptografia, senha de recuperação, carregando o blob de recuperação para PBS para recuperação de nova instalação."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — repositórios locais ou acessíveis por SSH, origem do binário Borg (sistema / cache / pacote AppImage do Monitor / download do GitHub), inicialização do repositório, gerenciamento da senha e configuração da chave SSH para repositórios remotos."
}
]
}
}
web/messages/pt/docs/backup-restore/destinations/local.json
+75
View File
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Destino de arquivo local — tar.zst em um sistema de arquivos ou unidade USB | ProxMenux",
"description": "O destino de backup local escreve um único arquivo .tar.zst para qualquer diretório com permissão de gravação: um disco interno, um ponto de montagem Proxmox, uma partilha NFS, ou uma unidade USB. Documenta o fluxo de configuração, a lógica de detecção e montagem USB, a verificação de segurança contra a gravação do arquivo em um caminho que está sendo feito backup, e o sidecar JSON que identifica o arquivo.",
"ogTitle": "Cópia de segurança do ProxMenux — Destino do arquivo local",
"ogDescription": "Como ProxMenux escreve backups locais como arquivos .tar.zst e como configurar o diretório de destino ou unidade USB.",
"twitterTitle": "Destino de backup local | ProxMenux",
"twitterDescription": "Como ProxMenux escreve backups locais como arquivos .tar.zst em um sistema de arquivos ou unidade USB."
},
"header": {
"title": "Arquivo local",
"description": "O destino local escreve um único arquivo de tar comprimido para qualquer diretório com permissão de gravação no host: um disco interno, uma montagem NFS ou SMB, ou uma unidade USB.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Um arquivo, auto-suficiente",
"body": "Um backup local produz um único arquivo <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (ou <code>.tar.gz</code> quando <code>zstd</code> está ausente). O arquivo contém toda a árvore de arquivos — <code>manifest.json</code>, <code>metadata/</code> e <code>rootfs/</code> — e pode ser restaurado em qualquer host Proxmox com o fluxo de restauração ProxMenux, ou extraído manualmente com <code>tar --zstd -xf</code> em qualquer sistema Linux. Nenhum servidor, nenhuma inicialização de repositório, nenhuma dependência externa. Este é o destino com o caminho de recuperação mais curto quando nem PBS nem Borg está disponível."
},
"targetConfig": {
"heading": "Configurando o diretório alvo",
"intro": "O destino local é um <strong>único diretório de destino salvo de forma persistente</strong> — não uma lista. ProxMenux armazena a escolha do operador em <code>/usr/local/share/proxmenux/local-target.conf</code> e lê essa escolha em cada backup. Quando nenhum alvo foi configurado, o <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> padrão é usado (o mesmo diretório que o Proxmox usa para suas próprias saídas <code>vzdump</code>). O alvo está configurado a partir de <em>Configure destinos de backup → Destinos locais</em>:",
"options": [
"<strong>Use o padrão (<code>/var/lib/vz/dump</code>).</strong> O armazenamento local Proxmox. Presente em cada instalação do Proxmox; o arquivo fica ao lado das saídas vzdump e é captado automaticamente pela aba Backups do Monitor.",
"<strong>Insira um caminho personalizado.</strong> Qualquer caminho absoluto do sistema de arquivos pode ser usado: uma montagem NFS, uma partilha SMB montada via <code>fstab</code>, um conjunto de dados dedicado ZFS, um segundo disco interno. ProxMenux valida que o caminho existe e é um diretório antes de persisti-lo.",
"<strong>Escolha uma unidade USB.</strong> Abre o submenu USB (abaixo), que detecta dispositivos removíveis e oferece para montar ou formatar um."
]
},
"usbFlow": {
"heading": "Detecção e montagem de unidades USB",
"intro": "O submenu USB lista partições em dispositivos removíveis relatados pelo <code>lsblk</code>. Cada partição é apresentada com seu tamanho, etiqueta do sistema de arquivos e estado atual. O estado determina a ação que o ProxMenux oferece.",
"statesTitle": "Os três estados do dispositivo",
"stateRows": [
{
"state": "montado",
"shown": "Tamanho · etiqueta · [fstype] · → /mount/point",
"action": "A partição já está montada em algum lugar. Selecioná-la salva o ponto de montagem atual como alvo local. Nenhuma montagem é realizada."
},
{
"state": "desmontado",
"shown": "Tamanho · etiqueta · [fstype] · (não montado — será montado)",
"action": "Um sistema de ficheiros está presente mas não está montado. Na confirmação, o ProxMenux executa o <code>hb_mount_usb_partition</code>: cria o <code>/mnt/backup-LABEL</code> (ou um caminho baseado em UUID, se não houver rótulo), monta a partição e persiste o ponto de montagem como alvo local."
},
{
"state": "vazia",
"shown": "Tamanho · disco USB bruto — sem sistema de arquivos (será FORMATADO)",
"action": "O dispositivo não tem sistema de arquivos. Essa operação destrutiva exige duas confirmações. Primeiro, uma janela Sim/Não explica que o disco será apagado. Depois, um campo exige que o usuário <strong>digite o caminho exato do dispositivo</strong> (por exemplo <code>/dev/sdb</code>) antes de o ProxMenux criar uma nova tabela GPT com uma partição ext4 e montá-la."
}
],
"notMountedFallback": "Quando nenhum dispositivo USB é detectado, o submenu cai de volta para uma caixa de entrada simples. O operador pode indicar uma localização arbitrária do ponto de montagem; se a localização não for um ponto de montagem registado, uma janela de confirmação avisa antes de prosseguir."
},
"safetyCheck": {
"heading": "Verificação de segurança — destino dentro de um caminho de backup",
"body": "Antes de gravar o arquivo, <code>_bk_local</code> verifica se o diretório de destino <strong>não</strong> é um subcaminho de qualquer diretório cujo backup está sendo feito. Um erro comum seria adicionar <code>/root</code> ao perfil e escolher <code>/root/backups</code> como destino - o arquivo então se incluiria, produzindo um arquivo corrompido ou crescendo sem limites até que o disco ficasse cheio. A verificação resolve ambos os caminhos com <code>readlink -m</code>, compara-os e, em caso de conflito, aborta o backup com uma caixa de diálogo que nomeia o caminho conflitante e lista três maneiras de resolvê-lo: escolha um destino fora do caminho conflitante, remova a entrada personalizada que contém o destino ou use o modo Personalizado para desmarcar o caminho conflitante para esta execução."
},
"archiveFormat": {
"heading": "Formato de arquivo e compressão",
"intro": "O nome do arquivo de saída inclui o nome do host de origem e a data e hora do backup, permitindo ordenar as cópias cronologicamente no diretório e identificar cada arquivo.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Compressão",
"compressionBody": "O caminho primário usa <code>tar --zstd -cf</code> — um pipeline de um único comando que comprime ao nível padrão do zstd. Quando <code>zstd</code> não está presente na fonte (raro em Proxmox, mas possível em instalações mínimas), ProxMenux cai de volta para <code>gzip</code>. No caminho de retorno, se o <code>pv</code> estiver disponível, uma barra de progresso é adicionada ao pipeline para que o operador veja o tamanho do arquivo crescer em tempo real; sem o <code>pv</code>, o <code>tar -czf</code> simples é usado silenciosamente.",
"sourceTitle": "O que vai para o arquivo",
"sourceBody": "O comando tar é chamado com <code>-C \"$staging_root\" .</code>, incluindo <strong>toda a raiz da área de preparação</strong>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code>. Os três blocos de dados ficam lado a lado na raiz do arquivo tar. A extração produz exatamente a árvore usada pelo código de restauração."
},
"sidecar": {
"heading": "O arquivo auxiliar JSON",
"intro": "Cada backup local bem sucedido produz um arquivo companheiro: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, escrito ao lado do arquivo por <code>hb_write_archive_sidecar</code>. Este pequeno arquivo JSON permite que o ProxMenux Monitor identifique o arquivo como um backup de host ProxMenux mesmo que mais tarde seja movido, renomeado ou arquivado em outro lugar.",
"contentTitle": "Conteúdo do sidecar",
"contentBody": "O sidecar armazena a versão do esquema, se o backup veio de uma execução interativa ou de uma tarefa agendada (<code>kind</code>), o ID do trabalho para as execuções agendadas, o modo de perfil usado (<code>default</code> ou <code>custom</code>), o nome de máquina de origem, o nome de base do arquivo original, um timestamp de criação ISO-8601 e o tamanho do arquivo em bytes.",
"whyBody": "A aba Backups do Monitor procura arquivos auxiliares <code>*.proxmenux.json</code> nos diretórios locais configurados, e não arquivos <code>*.tar.zst</code>, pois um <code>.tar.zst</code> sem arquivo auxiliar pode não ser um backup ProxMenux. A busca é rápida (os arquivos JSON são pequenos) e a associação permanece válida após renomear o arquivo, desde que o auxiliar seja renomeado de forma correspondente."
},
"restoreAccess": {
"heading": "Restaurando de um arquivo local",
"body": "O fluxo de restauração ProxMenux descobre arquivos locais digitalizando o alvo local configurado para sidecars e exibindo-os na lista Arquivos. A seleção de um arquivo aciona <code>_rs_check_layout</code>, que extrai o tarball em um diretório de preparação temporária e confirma o layout de três cargas antes de prosseguir. Para extração manual fora de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produz a mesma árvore que o código de restauração consome."
}
}
web/messages/pt/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -0,0 +1,113 @@
{
"meta": {
"title": "Proxmox Backup Server destino — repositório, encriptação, recuperação ProxMenux",
"description": "O destino PBS grava os backups do host ProxMenux como backups PBS. Documenta a descoberta de repositórios em /etc/pve/storage.cfg, a configuração manual, o envio de .pxar, a criptografia no cliente com arquivo de chave e sua cópia de recuperação opcional protegida por frase secreta, e a recuperação da chave por várias fontes em um host recém-instalado.",
"ogTitle": "Cópia de segurança ProxMenux — destino Proxmox Backup Server",
"ogDescription": "Como o ProxMenux grava backups do host no Proxmox Backup Server com criptografia por arquivo de chave no cliente e uma cópia da chave para recuperação.",
"twitterTitle": "PBS destino de backup □ ProxMenux",
"twitterDescription": "Destino Proxmox Backup Server com criptografia por arquivo de chave e cópia de recuperação protegida por frase secreta."
},
"header": {
"title": "Proxmox Backup Server",
"description": "O destino PBS envia todo o diretório de preparação como um único backup .pxar para um datastore Proxmox Backup Server. A criptografia no cliente com arquivo de chave é opcional, assim como o envio, junto a cada backup, de uma cópia da chave protegida por frase secreta para recuperação.",
"section": "Cópias de segurança e restauro"
},
"recommendedBadge": "Destino recomendado",
"aboutPbs": {
"heading": "O que é Proxmox Backup Server",
"body": "Proxmox Backup Server (PBS) é o próprio produto do servidor de backup da Proxmox, desenvolvido e mantido pela mesma equipe que o autor Proxmox VE. É um servidor de backup dedicado projetado para receber backups de hosts Proxmox VE (VMs, LXCs e — via <code>proxmox-backup-client</code> — diretórios host arbitrários) com deduplicação baseada em blocos, criptografia do lado do cliente e políticas de retenção aplicadas lado servidor. ProxMenux usa PBS como um dos três destinos para backups de host; cada mecanismo específico PBS descrito nesta página (grupos de backup, arquivos <code>.pxar</code>, criptografia de arquivos de chaves <code>--backup-id</code>) é o comportamento padrão PBS."
},
"intro": {
"title": "Um backup por execução, dedup de nível de blocos",
"body": "Um backup PBS cria uma única entrada no datastore, sob o ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Os dados formam um arquivo <code>.pxar</code> com a estrutura de três blocos descrita em <em>Como funciona</em>. O PBS deduplica blocos entre todos os backups do datastore, de modo que backups posteriores do mesmo host transferem e armazenam apenas os blocos alterados. Nas tarefas agendadas, o próprio ProxMenux aplica a retenção: após cada execução bem-sucedida, <code>run_scheduled_backup.sh</code> executa <code>proxmox-backup-client prune</code> com <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> e os valores configurados na tarefa."
},
"repoSelection": {
"heading": "Selecção do repositório",
"intro": "ProxMenux descobre repositórios PBS de duas fontes em cada backup. O operador escolhe um de um menu unificado; a escolha determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> para a execução.",
"sourceRows": [
{
"source": "storage.cfg do Proxmox (deteção automática)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Qualquer estrofe <code>pbs:</code> na própria configuração de armazenamento do Proxmox é captada automaticamente. Servidor, datastore, nome de usuário e impressão digital vêm da estrofe. A senha é lida no diretório de credenciais do Proxmox. Nenhuma reentrada necessária no lado ProxMenux — o repositório está disponível assim que estiver configurado no Proxmox."
},
{
"source": "Configuração manual do ProxMenux",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Adicionado de <em>Configure destinos de backup → destinos de PBS → Adicione PBS</em>. Pede um nome, nome de usuário (<code>root@pam</code> ou <code>user@pbs!token</code>), host ou IP, datastore e senha. A senha re-prompts na entrada vazia — uma gravação vazia persistiria silenciosamente e cada backup subsequente falharia com um erro de autenticação opaco. Este caminho é usado quando o PBS alvo não é registrado como armazenamento Proxmox."
}
],
"menuTitle": "Menu de seleção",
"menuBody": "Ambas as fontes são mostradas em um único menu, cada linha marcada com sua origem (<code>[proxmox]</code> ou <code>[manual]</code>). As entradas cuja senha não pôde ser resolvida são marcadas com um aviso <code>⚠ no password</code> — selecionando-se um aciona uma reentrada de senha antes do backup começar. A impressão digital é passada para <code>proxmox-backup-client</code> através da variável de ambiente <code>PBS_FINGERPRINT</code>; quando ausente, o cliente pede ao operador para aceitar o certificado do servidor de forma interativa no primeiro backup."
},
"backupCommand": {
"heading": "O comando de backup",
"intro": "O envio usa uma única chamada de <code>proxmox-backup-client backup</code>. O ProxMenux usa <code>env</code> para passar ao cliente a senha, a senha de criptografia e a impressão digital como variáveis de ambiente.",
"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": "Nome do ID de backup",
"backupIdBody": "O ID de backup padrão é <code>hostcfg-HOSTNAME</code>. Pede-se ao operador que o confirme ou edite antes do envio; quaisquer caracteres fora do <code>[A-Za-z0-9_-]</code> são despojados e os traços são aparados. Reutilizar o mesmo ID entre as execuções é intencional — o PBS trata o ID como um <em>group</em>, e cada backup subsequente aparece como um novo backup dentro desse grupo, compartilhando dedup com execuções anteriores.",
"pxarTitle": "Por que a fonte é a raiz de estadiamento completa",
"pxarBody": "A origem do arquivo <code>.pxar</code> é todo o <code>staging_root</code>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> em conjunto. Versões anteriores usavam <code>$staging_root/rootfs</code> como origem, deixando <code>metadata/</code> fora do arquivo. Sem esses dados, a verificação de compatibilidade emitia avisos de mudança de host mesmo ao restaurar no mesmo host. As cópias antigas continuam a ser restauradas pelo caso 3 de <code>_rs_check_layout</code>, que volta a colocar a árvore simples <code>etc/var/root/usr</code> dentro de uma hierarquia <code>rootfs/</code>."
},
"encryption": {
"heading": "Criptografia do lado do cliente",
"glossaryHint": "Esta seção usa os termos <em>arquivo de chave</em>, <em>frase secreta</em> e <em>envelope de recuperação</em>. O <glosarioLink>glossário</glosarioLink> resume as diferenças em uma frase por termo.",
"intro": "A criptografia PBS no cliente com arquivo de chave cifra os blocos no host de origem antes do envio. No ProxMenux ela é opcional. Ao ativá-la, o operador escolhe explicitamente sim ou não durante a configuração se deseja enviar ao PBS também uma cópia de recuperação do arquivo de chave protegida por frase secreta; a escolha pode ser alterada depois no Monitor. O arquivo fica sempre no caminho canônico <code>/usr/local/share/proxmenux/pbs-key.conf</code> e é reutilizado sem novas perguntas em todos os backups criptografados posteriores.",
"keyfileTitle": "Configurar o arquivo de chaves",
"keyfileBody": "O diálogo de criptografia aparece no primeiro backup criptografado do host. Primeiro pergunta se deseja criptografar o backup: <em>Não</em> continua sem criptografia, e <em>Sim</em> passa à segunda etapa. Esta depende da existência de um arquivo de chave em <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Se existir, ele é reutilizado sem novas perguntas e o backup continua; os backups posteriores também não perguntam novamente. Caso contrário, um menu oferece duas opções. <em>Gerar um novo arquivo de chave</em> executa <code>proxmox-backup-client key create --kdf none</code>. <em>Usar um arquivo de chave existente</em> detecta automaticamente uma chave gerenciada pelo PVE: se o repositório PBS selecionado estiver registrado no Proxmox com uma chave de criptografia em <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, o arquivo será copiado sem perguntas para o caminho canônico do ProxMenux. Se nenhuma chave PVE corresponder ao repositório, será solicitado o caminho absoluto onde o operador já colocou o arquivo neste host. Nos dois casos, o arquivo fica no caminho canônico com <code>chmod 600</code>.",
"modesTitle": "Arquivo de chave por host ou compartilhado",
"modesIntro": "Os dois modelos são aceitos e nenhum é obrigatório: o operador escolhe conforme a organização dos seus hosts.",
"modesPerHostTitle": "Arquivo de chave por host (padrão)",
"modesPerHostBody": "Cada host gera seu próprio arquivo de chaves na primeira vez que ele permite criptografia PBS. O isolamento é máximo: comprometer o arquivo de chaves de um host não expõe os backups de nenhum outro. Recomendado para frotas de produção e ambientes onde hospedeiros têm diferentes proprietários ou limites de conformidade.",
"modesSharedTitle": "Arquivo de chaves compartilhado (importação em cada máquina)",
"modesSharedBody": "Um arquivo-chave mestre gerado uma vez e instalado em cada host por meio da opção <em>Usar um arquivo-chave existente</em>. O gerenciamento é mais simples: um único segredo para proteger e qualquer host pode descriptografar os arquivos de qualquer outro (útil para consolidação, exercícios de restauração entre hosts ou verificação de backup centralizada). A desvantagem é que um vazamento do arquivo-chave compartilhado expõe todos os hosts de uma só vez. Recomendado para homelabs e frotas onde todos os hosts têm o mesmo proprietário e limite de confiança.",
"recoveryTitle": "Chave de envio para PBS — o operador decide",
"recoveryBody": "Logo após escolher o arquivo de chave, o ProxMenux pergunta explicitamente <em>Enviar a chave para o PBS?</em>, com duas respostas. <strong>Nenhum artefato de recuperação é enviado ao PBS até o operador responder Sim.</strong> O padrão é <em>Não, manter apenas localmente</em>: a chave fica no caminho canônico local, o ProxMenux não envia artefatos de recuperação ao PBS e o operador cuida da cópia externa. O botão <em>Baixar arquivo de chave</em> do Monitor, na linha do destino PBS, fornece essa cópia quando necessário. Ao escolher <em>Sim, enviar</em>, é solicitada duas vezes uma frase secreta de recuperação, verificando se as duas entradas coincidem. O ProxMenux protege o arquivo com AES-256-CBC e PBKDF2 (600.000 iterações, salt aleatório), produzindo <code>pbs-key.recovery.enc</code>. Cada backup criptografado posterior envia esse envelope ao PBS como um grupo de backup associado. Esses envios não transmitem ao PBS a frase secreta nem o arquivo de chave em texto claro. A escolha pode ser alterada a qualquer momento no Monitor: o controle na linha PBS permite Sim ou Não e aplica imediatamente Iniciar envio, Parar envio ou Atualizar frase secreta, conforme o estado atual.",
"blobUploadTitle": "Grupo de backup emparelhado no PBS",
"blobUploadBody1": "Quando o modo de garantia é <em>Sim, fazer upload</em>, ProxMenux carrega o envelope de recuperação para PBS após cada backup criptografado como um segundo grupo de backup emparelhado com o mesmo nome do grupo host, mas terminando em <code>-keyrecovery</code>. Os dois grupos ficam próximos um do outro na listagem do armazenamento de dados – um para backups de host e outro para envelopes de recuperação. <strong>O envelope nunca sai do host em texto simples</strong>: a criptografia acontece no próprio host com AES-256-CBC e PBKDF2 antes que qualquer byte seja transmitido (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recebe apenas o envelope já criptografado.",
"envelopeSecurityTitle": "Carregar o arquivo de recuperação de chaves para PBS é um risco de segurança?",
"envelopeSecurityBody": "O arquivo de recuperação de chaves está criptografado em trânsito e em repouso. A senha de recuperação nunca deixa o host: criptografia acontece localmente antes do upload, e PBS só vê o resultado já criptografado. Um administrador PBS — ou qualquer pessoa com acesso ao datastore — pode baixar o arquivo keyrecovery, mas sem a frase-passe de recuperação eles não podem ler o arquivo de chave dentro: é cifrar opaco. Reconstruir o arquivo de chaves requer ambas as peças ao mesmo tempo, o arquivo de recuperação de chaves e a frase-passe, e apenas o operador detém ambas.",
"blobUploadConstraintTitle": "Por que dois grupos em vez de um único criptografado",
"blobUploadConstraintBody": "Uma única chamada de <code>proxmox-backup-client backup</code> criptografa todos os seus arquivos com a mesma chave ou não criptografa nenhum; não permite misturar os dois casos. O backup do host precisa ser criptografado com a chave do host, mas o envelope de recuperação não pode acompanhá-lo no mesmo envio, pois acabaria criptografado com a própria chave que contém. Em um host recém-instalado, seria impossível abri-lo: seria necessária a chave para descriptografar a própria chave. Por isso os dois artefatos são enviados separadamente e aparecem em dois grupos. O cliente PBS criptografa o backup do host com o arquivo de chave, e o ProxMenux criptografa o envelope com a frase secreta antes do envio. Duas camadas de criptografia diferentes protegem dois elementos distintos.",
"blobUploadImageAlt": "PBS UI mostrando os grupos de backup hostcfg-HOSTNAME e hostcfg-HOSTNAME-keyrecovery adjacentes na listagem de datastore.",
"blobUploadImageCaption": "Interface PBS — os grupos de backup associados. O grupo principal contém os backups do host; o grupo -keyrecovery contém o arquivo de chave protegido por frase secreta.",
"recoverTitle": "Recuperação num novo hospedeiro",
"recoverBody": "Quando o arquivo de chave falta no caminho canônico, após reinstalar o host ou removê-lo explicitamente, a restauração tenta três fontes em ordem e para na primeira que fornece uma chave utilizável. Primeiro, se houver uma chave gerenciada pelo PVE correspondente ao repositório PBS selecionado em <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ela será copiada sem perguntas para o caminho canônico. Segundo, se houver um grupo <code>-keyrecovery</code> no PBS, será baixado o instantâneo mais recente e solicitada a frase secreta de recuperação para descriptografá-lo. Terceiro, se as opções anteriores falharem ou forem recusadas, o diálogo pedirá o caminho absoluto do arquivo de chave neste host e o copiará para o caminho canônico. O Monitor oferece o mesmo fluxo de importação na janela de detalhes do backup. Um painel âmbar aparece no topo quando Restaurar, Baixar ou Ver conteúdo exige uma chave ausente. Se a chave instalada não corresponde à usada no backup, o PBS retorna <code>wrong key — manifest's key XX does not match provided key YY</code>. As mesmas três ações exibem então um painel estruturado com a impressão digital exigida pelo manifesto em destaque, permitindo identificar qual chave importar para abrir o backup.",
"monitorManagementTitle": "Gerenciando o arquivo de chaves do Monitor",
"monitorManagementBody": "O Monitor mostra os controles do arquivo de chave diretamente em cada linha de destino PBS na configuração dos backups. Há três ações: <em>Baixar</em> exporta o arquivo atual para o navegador; <em>Enviar</em> substitui o arquivo instalado pelo fornecido pelo operador, sobrescrevendo o anterior somente após a instalação bem-sucedida do novo no caminho canônico; <em>Excluir</em> remove o arquivo do host. Ao lado fica o controle da cópia de recuperação: uma opção Sim/Não para <em>Enviar a chave para o PBS?</em>, um campo de frase secreta quando Sim é escolhido e um botão contextual para aplicar <em>Iniciar envio</em>, <em>Parar envio</em> ou <em>Atualizar frase secreta</em>. Todas as ações usam os mesmos endpoints Flask da interface de terminal; portanto, o efeito em disco e o estado no PBS são idênticos nas duas interfaces."
},
"restoreAccess": {
"heading": "Obtenção no lado da restauração",
"body": "A restauração localiza os backups do host ProxMenux no PBS listando os grupos do repositório configurado e filtrando pelo padrão do ID. A aba Backups do Monitor exibe a mesma lista. Escolher um backup executa <code>proxmox-backup-client restore</code> com os mesmos repositório, senha e impressão digital, além de <code>--keyfile</code> se estiver criptografado. O arquivo <code>.pxar</code> é extraído em um diretório de preparação que <code>_rs_check_layout</code> encaminha ao processo normal de restauração. Fora do ProxMenux, o mesmo comando extrai o arquivo no caminho desejado para inspecionar a árvore ou realizar uma restauração manual."
},
"references": {
"heading": "Referências",
"intro": "Documentação oficial do Proxmox Backup Server para os componentes usados pelo ProxMenux.",
"items": [
{
"label": "Documentação Proxmox Backup Server",
"href": "https://pbs.proxmox.com/docs/",
"tail": " — o ponto de entrada principal que abrange a instalação, administração, armazenagem, utilizadores e funções."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — a ferramenta de linha de comando que o ProxMenux usa em cada backup e restauração. Descreve IDs e tipos de backup, arquivos, sintaxe dos repositórios e variáveis de ambiente."
},
{
"label": "Criptografia do lado do cliente",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — criação do arquivo de chave, modos --kdf e modelo de criptografia que o ProxMenux amplia com uma cópia de recuperação protegida por frase secreta."
},
{
"label": "Gestão de armazenamento de dados",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": " — criação e gerenciamento dos datastores que recebem backups do host, incluindo a estrutura do armazenamento de blocos e as permissões."
},
{
"label": "Poda e coleta de lixo",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — o modelo de retenção de --keep-last / --keep-daily / --keep-weekly aplicado pelo ProxMenux em cada tarefa agendada e como o PBS libera blocos não usados após a remoção de backups antigos."
}
]
}
}
web/messages/pt/docs/backup-restore/glossary.json
+230
View File
@@ -0,0 +1,230 @@
{
"meta": {
"title": "Glossário — Cópia de segurança e restauração ProxMenux",
"description": "Termos do sistema de backup e restauração ProxMenux: criptografia, arquivo de chaves, frase-senha, envelope de recuperação, PBS, blocos, rootfs, manifesto, executor e hidratação entre versões do kernel.",
"ogTitle": "Glossário das cópias de segurança e do restauro | ProxMenux",
"ogDescription": "Definições claras dos termos usados na documentação de backup e restauração ProxMenux.",
"twitterTitle": "Glossário das cópias de segurança e do restauro | ProxMenux",
"twitterDescription": "Senha, arquivo de chaves, envelope de recuperação, rootfs, manifesto, PBS, blocos — todos definidos em um só lugar."
},
"header": {
"title": "Glossário",
"description": "Termos usados através da documentação de backup e restauração, com sua definição.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"body": "Os termos são agrupados por tema. Cada entrada dá o termo e uma definição curta."
},
"groups": [
{
"title": "Criptografia e recuperação de chaves",
"intro": "Vocabulário para o bloco de criptografia PBS. Envolve dois segredos distintos: um arquivo binário e uma frase-passe escrita.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Senha de recuperação",
"def": "Senha de texto que o usuário escolhe para proteger o <a href=\"#sobre-recuperacion\">envelope de recuperação</a>. Ele é solicitado duas vezes com uma verificação de correspondência, e só é usado para criptografar o envelope e para decifrá-lo se o arquivo de chaves alguma vez precisa ser recuperado. <strong>Não é a frase-passe que desbloqueia o próprio arquivo de chaves</strong>, e nunca é enviado para PBS. Durante um backup normal, ele nunca deixa o hospedeiro."
},
{
"id": "clave-cifrado",
"term": "Arquivo de chaves (chave de criptografia)",
"def": "Arquivo de chave usado por proxmox-backup-client para criptografar os <a href=\"#chunk\">blocos</a> antes do envio ao PBS. Sem a chave correspondente, os dados criptografados não podem ser lidos. O ProxMenux o salva em <code>/usr/local/share/proxmenux/pbs-key.conf</code> com modo <code>600</code>. Proteja-o: o <a href=\"#sobre-recuperacion\">envelope de recuperação</a> permite recuperá-lo se for perdido."
},
{
"id": "contrasena-keyfile",
"term": "Frase- senha do ficheiro de chaves (frase- senha do KDF)",
"def": "Senha opcional que o próprio arquivo de chaves pode carregar, distinta da frase-passe <a href=\"#passphrase-recuperacion\">de recuperação</a>. Ele só existe quando o arquivo de chaves foi criado com <code>--kdf scrypt</code> (normalmente um arquivo de chaves importadas). Sem ele, o arquivo de chaves não pode ser desbloqueado para uso. ProxMenux persiste em forma criptografada no host para que os backups agendados possam ser executados sem um prompt interativo."
},
{
"id": "sobre-recuperacion",
"term": "Envelope de recuperação",
"def": "O <a href=\"#clave-cifrado\">ficheiro de chaves</a> protegido por uma camada adicional: é encriptado com a <a href=\"#passphrase-recuperacion\">frase-passe de recuperação</a> através de <a href=\"#aes-256-cbc\">AES-256-CBC</a> e <a href=\"#pbkdf2\">PBKDF2</a> antes de sair do host. É esta versão protegida que é enviada para o PBS no grupo <code>-keyrecovery</code>. Sem a frase-passe, o conteúdo permanece inacessível: descarregá-lo do PBS não revela o ficheiro de chaves."
},
{
"id": "cifrado-cliente",
"term": "Criptografia do lado do cliente",
"def": "Modelo de criptografia em que os dados são criptografados na máquina de origem antes de serem enviados. O PBS só recebe e armazena texto cifrado; nem mesmo um administrador PBS com acesso a datastore pode lê-lo sem o arquivo de chaves. O ProxMenux baseia-se neste modelo e adiciona o <a href=\"#sobre-recuperacion\">envelope de recuperação</a> no topo."
},
{
"id": "kdf-none",
"term": "--kdf none",
"def": "Opção para <code>proxmox-backup-client key create</code> que produz um arquivo de chaves sem senha anexada. O arquivo de chaves pode ser usado diretamente sem um prompt, o que é essencial para trabalhos agendados sem acompanhamento. Isto é o que o ProxMenux usa por padrão ao gerar um novo arquivo de chaves."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"def": "Opção para <code>proxmox-backup-client key create</code> que produz um arquivo de chaves protegido por uma <a href=\"#contrasena-keyfile\">frase-senha do arquivo de chave</a>. Cada uso do arquivo de chaves requer desbloqueá-lo com essa frase-passe. O ProxMenux aceita este estilo de arquivo de chaves na importação e armazena a frase-passe criptografada para que os backups agendados ainda possam ser executados sem acompanhamento."
},
{
"id": "aes-256-cbc",
"term": "AES-256-CBC",
"def": "Cifra simétrica padrão. ProxMenux usa-o (via <code>openssl enc -aes-256-cbc</code>) para embrulhar o <a href=\"#clave-cifrado\">keyfile</a> com a <a href=\"#passphrase-recuperacion\">frase-senha de recuperação</a> e produzir o <a href=\"#sobre-recuperacion\">envelope</a>."
},
{
"id": "pbkdf2",
"term": "PBKDF2",
"def": "Função criptográfica que transforma uma frase-passe tipo humano em uma chave binária adequada para criptografia. Atrasa as tentativas de força bruta aplicando muitas iterações. ProxMenux usa-o com iterações 600 000 e um sal aleatório ao criptografar o envelope de recuperação."
}
]
},
{
"title": "Estrutura de backup",
"intro": "Termos que descrevem o que vive dentro de um backup, independentemente do destino.",
"entries": [
{
"id": "rootfs",
"term": "rootfs / sistema de ficheiros root",
"def": "Uma cópia plana do sistema de arquivos do host fonte, produzido pela <code>rsync</code> sobre o perfil <a href=\"#perfil-defecto\">default</a> mais qualquer caminho <a href=\"#rutas-personalizadas\">custom</a>. Não é uma imagem de disco inteiro: apenas caminhos que contêm configuração ou estado Proxmox não pode regenerar por conta própria são copiados."
},
{
"id": "manifiesto",
"term": "Manifesto (manifest.json)",
"def": "Documento estruturado JSON descrevendo o host fonte no momento do backup: hardware, armazenamento, kernel, componentes instalados ProxMenux e inventário de VMs e LXCs. É produzido por seis coletores de dados independentes. O fluxo de restauração usa-o para comparar fonte e alvo."
},
{
"id": "staging",
"term": "Diretório de preparação",
"def": "Diretório temporário onde ProxMenux monta os três blocos (rootfs, metadados e manifestos) antes de embalá-los e enviar para o destino. É removido automaticamente quando o backup termina, mesmo ao abortar."
},
{
"id": "perfil-defecto",
"term": "Perfil padrão",
"def": "Conjunto selecionado de caminhos copiados por padrão em cada backup: configuração PVE, rede, SSH, kernel, apt, ferramentas ProxMenux e outros. É definido no código e documentado na página <em>Como funciona</em>."
},
{
"id": "rutas-personalizadas",
"term": "Caminhos personalizados",
"def": "Caminhos extras que o usuário adiciona no topo do perfil <a href=\"#perfil-defecto\">default</a>. Persistente (armazenada em <code>backup-extra-paths.txt</code>) ou por execução (escolhida em modo Personalizado)."
}
]
},
{
"title": "Destinos e armazenagem",
"intro": "Termos ligados ao local onde o backup chega — servidor PBS, arquivo local ou repositório Borg — e como o PBS organiza os dados.",
"entries": [
{
"id": "repositorio-pbs",
"term": "Repositório PBS",
"def": "Combinação de Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuário que recebe o backup. Identificado pela string <code>user@realm@host:datastore</code>. Um único servidor PBS pode hospedar vários repositórios."
},
{
"id": "datastore",
"term": "Armazenamento de dados",
"def": "Armazenamento específico em um servidor PBS para backups e seus blocos. Cada datastore fica em um sistema de arquivos do servidor PBS e tem permissões e políticas próprias."
},
{
"id": "chunk",
"term": "Bloco (chunk) / desduplicação de blocos",
"def": "PBS divide cada backup em blocos de tamanho variável, identifica cada pedaço pelo seu hash e armazena cada pedaço apenas uma vez, mesmo que apareça em muitos backups diferentes. Isto significa que os backups sucessivos da mesma máquina — ou através de hosts semelhantes — ocupam muito pouco espaço adicional."
},
{
"id": "fingerprint",
"term": "Impressão digital",
"def": "Impressões digitais criptográficas do certificado PBS do servidor TLS. Permite ao cliente verificar se está a falar com o servidor pretendido sem depender de uma autoridade pública de certificação. ProxMenux passa para <code>proxmox-backup-client</code> através da variável de ambiente <code>PBS_FINGERPRINT</code>."
},
{
"id": "grupo-copia",
"term": "Grupo de backup",
"def": "Container lógico dentro do PBS sob o qual se acumulam sucessivos backups do mesmo ativo. Cada novo backup compartilha deduplicação com os anteriores no mesmo grupo. ProxMenux usa dois grupos por host quando a criptografia está habilitada: um para o backup do host e outro com um sufixo <code>-keyrecovery</code> para o <a href=\"#sobre-recuperacion\">envelope de recuperação</a>."
},
{
"id": "backup-id",
"term": "ID de backup",
"def": "Nome do <a href=\"#grupo-copia\">grupo de backup</a>. ProxMenux padrão para <code>hostcfg-HOSTNAME</code> e permite que o usuário editá-lo antes do upload; caracteres não suportados são despojados automaticamente."
},
{
"id": "pxar",
"term": ".pxar",
"def": "Formato de arquivo PBS-native para diretórios. Ele se comporta como um arquivo tar otimizado para desduplicação de blocos: ao invés de armazenar um arquivo opaco, PBS quebra seu conteúdo em pedaços reutilizáveis."
}
]
},
{
"title": "Execução e agendamento",
"intro": "Termos usados pelo sistema ProxMenux-jobs programados.",
"entries": [
{
"id": "runner",
"term": "Executor",
"def": "O script <code>run_scheduled_backup.sh</code> que executa um backup agendado. Ele lê a configuração do trabalho, lança o backend correspondente (Local, PBS ou Borg), aplica retenção no sucesso e envia as notificações configuradas."
},
{
"id": "trabajo-programado",
"term": "Trabalho agendado",
"def": "Configuração persistente de uma cópia de segurança recorrente. Mantém o destino, credenciais, criptografia, programação e retenção. Vive em <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
},
{
"id": "modo-adjunto",
"term": "Anexar modo",
"def": "Tarefa sem temporizador próprio. Um hook job-end PVE de <code>vzdump</code> a executa após os backups dos convidados quando o armazenamento coincide. A tarefa pai fornece destino e retenção inicial, mas o hook compara armazenamento, não ID pai. Outra tarefa no mesmo armazenamento também pode acioná-la. Somente Local e PBS."
},
{
"id": "timer-systemd",
"term": "Temporizador Systemd",
"def": "Mecanismo systemd padrão que dispara um comando em um calendário. ProxMenux cria um temporizador por <em>independente</em> trabalho programado; <a href=\"#modo-adjunto\">attach-mode</a> trabalhos não usam temporizador, eles rodam através do script-hook PVE."
},
{
"id": "retencion",
"term": "Retenção (keep-last, keep-daily…)",
"def": "Política que decide quais backups mais antigos manter e qual podar. Definido por trabalho com parâmetros como <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Aplicado pelo executor após cada backup bem sucedido."
}
]
},
{
"title": "Restaurar",
"intro": "Termos do fluxo de restauração.",
"entries": [
{
"id": "restauracion-universal",
"term": "Restauração universal",
"def": "O fluxo de restauração ProxMenux não apenas extrai o sistema de arquivos: ele lê o manifesto para detectar diferenças entre fonte e alvo, reproduz a configuração do sistema e executa novamente os instaladores para os componentes gerenciados ProxMenux. O objetivo é reproduzir o host de origem, não apenas o arquivo."
},
{
"id": "hidratacion",
"term": "Hidratação entre versões do kernel",
"def": "Etapa de restauração que combina as configurações do usuário na origem (parâmetros IOMMU, IDs VFIO, ajustes específicos e chaves GRUB) com a configuração nova de inicialização do destino, sem copiar literalmente arquivos ligados ao kernel de origem. Executa quando o kernel de destino é mais novo que o do backup."
},
{
"id": "cross-kernel",
"term": "Restauração do kernel cruzado",
"def": "Restaurar onde o kernel do alvo difere (normalmente é mais novo do que) da fonte. Requer o passe <a href=\"#hidratacion\">hydration</a> para evitar arrastar arquivos incompatíveis com o kernel do alvo."
},
{
"id": "instalador-postboot",
"term": "Instalador pós-inicial",
"def": "Componentes reinstalados após a primeira inicialização do host restaurado ( drivers NVIDIA, drivers Coral TPU, ferramentas AMD GPU, ferramentas Intel GPU). Cada instalador corre contra o kernel do alvo, então o host restaurado não depende do kernel da fonte estar presente."
},
{
"id": "compatibility-check",
"term": "Verificação de compatibilidade",
"def": "Comparação entre o manifesto da fonte e o estado do alvo que o ProxMenux realiza no início da restauração. Ele decide quais partes são copiadas verbatim, que precisam de hidratação e que são recriadas por um instalador."
},
{
"id": "equipo-recien-instalado",
"term": "Instalação fresca",
"def": "Host recém-reinstalado do zero, sem <a href=\"#clave-cifrado\">arquivo de chave</a> local. Para restaurar um backup criptografado, primeiro recupere a chave do <a href=\"#sobre-recuperacion\">envelope</a> armazenado no PBS usando a <a href=\"#passphrase-recuperacion\">frase-senha de recuperação</a>."
}
]
}
],
"whereNext": {
"heading": "Onde se segue",
"items": [
{
"label": "Como funciona",
"href": "/docs/backup-restore/how-it-works",
"tail": " — quando o rootfs, o manifesto e o inventário da aplicação se encaixam num backup."
},
{
"label": "Destino Proxmox Backup Server",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — quando a criptografia do lado do cliente, o arquivo de chaves, a frase-passe de recuperação e o envelope são documentados em profundidade."
},
{
"label": "Restauração",
"href": "/docs/backup-restore/restoring",
"tail": " — fluxo de restauração e uso do manifesto."
}
]
}
}
web/messages/pt/docs/backup-restore/how-it-works.json
+205
View File
@@ -0,0 +1,205 @@
{
"meta": {
"title": "Como o backup ProxMenux funciona internamente — rootfs, manifestos, aplicativos",
"description": "Descrição detalhada do que um backup ProxMenux contém: os rootfs produzidos pelo rsync do perfil de caminho padrão, o manifesto estruturado construído por seis coletores independentes e o inventário de aplicativos que impulsiona a reinstalação automática de pacotes e componentes após uma restauração.",
"ogTitle": "Como o backup ProxMenux funciona internamente",
"ogDescription": "Os três blocos de um backup ProxMenux: rootfs, manifesto e aplicativos.",
"twitterTitle": "Como funcionam as cópias de segurança ProxMenux | ProxMenux",
"twitterDescription": "As três cargas de um backup ProxMenux e como a restauração reproduz o host fonte deles."
},
"header": {
"title": "Como funciona",
"description": "A estrutura interna de um backup ProxMenux — sistema de arquivos, manifesto e inventário de aplicativos — e como a restauração usa os três para reproduzir o host de origem em um destino que pode ter outro kernel.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Um arquivo, três blocos",
"body": "Cada backup cria três blocos bem definidos em um único diretório de preparação. O arquivo enviado ao destino (<code>.tar.zst</code> local, backup PBS ou arquivo Borg) mantém essa estrutura. A restauração usa os três: <strong>o manifesto</strong> é consultado antes das alterações para detectar diferenças e decidir o que excluir; <strong>rootfs</strong> fornece os arquivos de configuração, aplicados em execução ou após reiniciar; <strong>o inventário de aplicativos</strong> orienta a instalação de pacotes e a reinstalação de componentes após o boot. Cada bloco pode ser inspecionado ou extraído separadamente."
},
"layout": {
"heading": "Disposição do arquivo",
"intro": "Cada arquivo segue o mesmo layout de árvore, independentemente do destino. O subdiretório <code>metadata/</code> contém as cargas estruturadas; o subdiretório <code>rootfs/</code> contém a cópia do sistema de arquivos.",
"treeCaption": "O diretório de preparação criado durante o backup. Todos os destinos recebem a mesma árvore no formato nativo: tar para backups locais, blocos PBS para PBS e segmentos Borg para 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": "A carga útil do rootfs",
"intro": "A árvore <code>rootfs/</code> é uma <strong>cópia simples do sistema de arquivos</strong> criada pelo <code>rsync</code> a partir do host de origem. Contém um <strong>perfil padrão</strong> de caminhos selecionados para restaurar o Proxmox e os <strong>caminhos personalizados</strong> adicionados à tarefa ou sessão interativa. A seleção é intencionalmente restrita a caminhos que <em>guardam configuração</em> ou <em>guardam um estado que o Proxmox não consegue recriar sozinho</em>.",
"defaultProfileTitle": "O perfil por omissão",
"defaultProfileBody": "O perfil padrão é definido por <code>hb_default_profile_paths</code> em <code>lib_host_backup_common.sh</code>. Abrange oito categorias fixas e, quando necessário, o estado ZFS, que juntas descrevem um host Proxmox funcional:",
"categoriesTitle": "Categorias de localização",
"categoryRows": [
{
"category": "Núcleo PVE",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
"why": "Conteúdo do sistema de ficheiros de cluster e valores por omissão do vzdump. O banco de dados pmxcfs (<code>config.db</code>) é capturado como um instantâneo consistente via <code>sqlite3 .backup</code> sem parar o cluster, e os sidecars <code>.db-wal</code> / <code>.db-shm</code> são excluídos do rsync. Quando o <code>sqlite3</code> não está disponível, é criado <code>config.db.raw-fallback</code>, que a restauração usa automaticamente como banco de dados."
},
{
"category": "Identidade do host e rede",
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
"why": "Tudo que o host precisa para entrar na rede com a mesma identidade. Os arquivos <code>.link</code> em <code>/etc/systemd/network</code> fixam nomes de NIC em seus MAC, portanto, reinstalações e alterações de hardware não renomeiam interfaces."
},
{
"category": "Acesso e autenticação",
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
"why": "SSH chaves, regras de sudo e configuração PAM. Perder estas trava o usuário fora da máquina restaurada."
},
{
"category": "Kernel e inicialização",
"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": "Tokens IOMMU, lista negra do módulo, IDs do dispositivo VFIO, tabela de montagem, configuração da pilha de armazenamento."
},
{
"category": "Shell e definições regionais",
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
"why": "Configuração do shell, variáveis de ambiente, configuração de geração local."
},
{
"category": "Gerenciamento de pacotes e cron",
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
"why": "Fontes APT para resolução consistente de pacotes, tarefas agendadas definidas pelo usuário."
},
{
"category": "Estado e ferramentas do ProxMenux",
"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": "Ferramentas opcionais, mas comuns Proxmox. Caminhos ausentes são observados em <code>metadata/missing_paths.txt</code> sem parar o backup."
},
{
"category": "Binários & root do ProxMenux",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (subdires voláteis excluídos)",
"why": "Binários instalados em ProxMenux e configuração por usuário sob <code>/root</code>. Os caminhos voláteis (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) são excluídos da cópia. O <code>/var/lib/proxmenux</code> mantém as tarefas de backup programadas e o estado de host mantido pelo ProxMenux; o estadiamento da restauração, as cópias de rollback e os marcadores pós-restore são excluídos, porque pertencem ao host que executa uma restauração."
},
{
"category": "Estado ZFS (condicional)",
"paths": "/etc/zfs",
"why": "Apenas incluído quando o host de origem roda ZFS. Contém <code>zpool.cache</code> e <code>hostid</code>."
}
],
"customTitle": "Estendendo o perfil com caminhos personalizados",
"customBody": "Além do perfil padrão, o ProxMenux oferece duas maneiras de incluir caminhos adicionais em um backup. Eles compõem sem conflito e ambos se aplicam a backups interativos e trabalhos agendados.",
"customExtrasTitle": "1. Extras persistentes (por máquina)",
"customExtrasBody": "Um arquivo de texto no <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contém uma lista de caminhos absolutos que o usuário marcou como \"incluir sempre\" nesta máquina. Quando um backup é executado no modo <strong>Default</strong>, o ProxMenux adiciona esses caminhos ao perfil padrão automaticamente sem perguntar. O arquivo é editado a partir da interface — nenhuma edição manual necessária — e persiste através de reiniciais e atualizações. Um caminho absoluto por linha; <code>#</code> comentários são permitidos.",
"customModeTitle": "2. Modo personalizado (por execução)",
"customModeBody": "O lançamento de um backup no modo <strong>Custom</strong> substitui a aplicação automática do perfil padrão por uma lista de verificação mostrando todos os caminhos: as entradas de perfil padrão e os extras persistentes (prefixados com <code>[+]</code> e pré-selecionados). O usuário seleciona ou desmarca entradas para essa execução específica, e também pode pressionar <em>Adicionar caminho personalizado</em> para inserir um novo caminho — que é então persistido para o arquivo extras para backups futuros.",
"customMissingTitle": "Caminhos ausentes da fonte",
"customMissingBody": "Qualquer caminho do perfil (padrão ou adicionado) que não exista no host fonte é gravado em <code>metadata/missing_paths.txt</code> dentro do arquivo. O backup não falha nem para — o usuário vê um resumo de caminhos arquivados e caminhos faltando no final. Na prática, isso acontece para caminhos de ferramentas opcionais como <code>/etc/wireguard</code> ou <code>/etc/prometheus</code> quando essas ferramentas não estão instaladas."
},
"manifest": {
"heading": "O bloco do manifesto",
"intro": "<code>manifest.json</code> é um documento JSON estruturado que descreve o host de origem no momento do backup. É produzido por <strong>seis coletores independentes</strong> orquestrados por <code>build_manifest.sh</code>. Cada coletor é somente leitura, produz um fragmento JSON bem definido, e cai de volta para um padrão vazio seguro se falhar — o manifesto ainda é utilizável se uma seção estiver incompleta.",
"orchestratorCaption": "Os seis coletores compõem o manifesto. Cada colecionador corre em seu próprio subprocesso; uma falha em um cai de volta para um padrão seguro documentado e avisa, mas não aborta o backup.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
"produces": "source_host",
"content": "Hostname, versão PVE (<code>pveversion</code>), versão PBS se o host executar o papel do servidor de backup, kernel (<code>uname -r</code>), modo de inicialização (efi/bios), tipo de sistema de arquivos raiz, modelo CPU + arquitetura, memória em KB."
},
{
"collector": "collect_hardware.sh",
"produces": "hardware_inventory",
"content": "GPUs (com o mapeamento do instalador do fornecedor e ProxMenux), TPUs (Coral USB + M.2 com detecção de <code>lsusb</code>/<code>lspci</code>), NICs (com a associação MAC, slot PCI e ponte), dispositivos sem fio. As entradas GPU têm uma heurística <code>passthrough_eligible</code>."
},
{
"collector": "collect_storage.sh",
"produces": "storage_inventory",
"content": "ZFS pools (com pool disco do tipo + membro resolvido para <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> ou em bruto <code>/dev/sdX</code> caminhos dependendo de como cada pool foi originalmente criado), LVM grupos de volume + finos pools, discos físicos com SMART capacidade, PVE <code>storage.cfg</code> entradas, montagens externas."
},
{
"collector": "collect_kernel.sh",
"produces": "kernel_params",
"content": "Parâmetros adicionados pelo operador em <code>/proc/cmdline</code>, sem os itens padrão como <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> e <code>splash</code>; módulos carregados na inicialização de <code>/etc/modules</code>; caminhos dos arquivos <code>/etc/modprobe.d/*.conf</code> com diretivas efetivas (<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": "Lê <code>/usr/local/share/proxmenux/managed_installs.json</code> (registo de tudo que ProxMenux instalou) e <code>installed_tools.json</code>. Cada entrada mantém o caminho do instalador (<code>menu_script</code>) para que a restauração possa desencadear o mesmo fluxo de instalação."
},
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
"content": "Enumera VMs (<code>qm list</code>) e LXCs (<code>pct list</code>) presentes na hora de backup — VMID, nome, estado atual. Apenas o inventário: os dados reais dos hóspedes são da responsabilidade do <code>vzdump</code> / PBS."
}
],
"schemaTitle": "Validação do esquema",
"schemaBody": "O manifesto valida contra <code>scripts/backup_restore/schema/manifest.schema.json</code>. Executar o <code>build_manifest.sh --validate</code> desencadeia uma validação do esquema JSON do lado Python (exige o <code>python3</code> + <code>jsonschema</code>). Se o módulo não estiver presente, a verificação é ignorada silenciosamente — a validação é principalmente um auxílio ao desenvolvedor, não uma dependência de execução."
},
"applications": {
"heading": "O inventário de aplicativos",
"intro": "Dois inventários catalogam o software acrescentado aos pacotes básicos do Proxmox VE: a lista de pacotes em <code>metadata/</code> e o registro de componentes em rootfs, detalhados abaixo. A restauração usa APT ou os instaladores do ProxMenux para reproduzir o software do usuário conforme o método original de instalação.",
"packagesTitle": "packages.manual.list",
"packagesBody": "Uma lista alfabética em texto simples produzida por <code>apt-mark showmanual</code> com os pacotes APT <em>instalados explicitamente</em> no host de origem. As dependências do sistema Proxmox VE básico são excluídas; o APT do destino as instala automaticamente. Durante a restauração, <code>_rs_run_complete_extras</code> lê a lista e aplica um <em>filtro contra remoções em cascata</em> em três etapas: <code>dpkg -s</code> identifica pacotes já instalados, outras versões principais de bibliotecas são detectadas e <code>apt-get install --simulate</code> verifica o risco de remoções em cascata. Os pacotes restantes são instalados com <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (parte dos rootfs)",
"componentsBody": "Um registro JSON sob <code>/usr/local/share/proxmenux/</code> que registra cada componente ProxMenux instalou com seu estado exato: versão, bandeiras ProxMenux específicas (para NVIDIA: <code>patched</code> booleano; para Coral: versão DKMS). Este arquivo vive dentro dos rootfs — não em <code>metadata/</code> — porque é <em>lido depois</em> que rootfs foi copiado para o alvo. O expedidor pós-boot (<code>apply_cluster_postboot.sh</code>) itera sobre suas entradas e executa o gancho <code>--auto-reinstall</code> de cada componente, que lê o estado gravado e reproduz a instalação contra o kernel atual do alvo.",
"componentInstallersTitle": "Instaladores de componentes",
"componentInstallersBody": "Quatro instaladores ProxMenux atualmente expõem um ponto de entrada <code>--auto-reinstall</code>:",
"installerRows": [
{
"component": "nvidia_driver",
"installer": "gpu_tpu/nvidia_installer.sh",
"action": "Lê-se <code>version</code> + <code>patched</code>. Transfere exatamente o mesmo arquivo de execução NVIDIA, constrói módulos DKMS contra o kernel do alvo, reaplica o patch ProxMenux se a fonte o tiver."
},
{
"component": "coral_driver",
"installer": "gpu_tpu/install_coral.sh",
"action": "Lê a versão do driver Coral. Compila o módulo DKMS contra o kernel do alvo."
},
{
"component": "amdgpu_top",
"installer": "gpu_tpu/amd_gpu_tools.sh",
"action": "Lê a versão gravada. Baixa novamente o <code>.deb</code> exato da versão GitHub."
},
{
"component": "intel_gpu_tools",
"installer": "gpu_tpu/intel_gpu_tools.sh",
"action": "O APT instala o pacote. Idempotente se já presente de <code>packages.manual.list</code>."
}
]
},
"restoreFlow": {
"heading": "Como a restauração consome as três cargas",
"intro": "A restauração é um processo de seis etapas. Cada etapa lê um subconjunto específico do arquivo e atualiza o host alvo. Nenhuma etapa requer que o host de origem seja acessível — o arquivo é totalmente auto-suficiente.",
"stagesCaption": "Estágio 1 usa o manifesto para decidir o que tocar. Estágio 2 copia rootfs caminhos que são seguros para aplicar em um sistema em execução. O estágio 3 encena os caminhos arriscados para a próxima inicialização. Fase 3b importa conjuntos de dados ZFS não-root cujos discos estão todos presentes. Estágio 4 lida com pacotes. O estágio 5 é executado após a reinicialização e reinstala componentes contra o kernel do alvo.",
"stageRows": [
{
"stage": "1",
"name": "Verificação de compatibilidade",
"reads": "manifest.json",
"action": "Corre <code>hb_compat_check</code>. Compara hardware fonte vs. alvo (NICs, IDs de armazenamento), versão PVE e versão principal do kernel. Define <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> ou <code>bk_older</code>) e povoa <code>RS_SKIP_PATHS</code> com exclusões de hardware-drift e cross-kernel."
},
{
"stage": "2",
"name": "Aplicação em execução",
"reads": "rootfs/ (somente caminhos seguros)",
"action": "<code>_rs_apply … hot</code> copia entradas <code>hb_classify_path</code>=<code>hot</code> diretamente para o alvo ao vivo. Qualquer coisa sob <code>/etc/pve</code>, <code>/etc/network</code> ou caminhos classificados como <em>reboot</em>/<em>dangerous</em> é adiada."
},
{
"stage": "3",
"name": "Preparações pendentes",
"reads": "rootfs/ (reboot + caminhos perigosos)",
"action": "<code>_rs_prepare_pending_restore</code> prepara os caminhos de risco em <code>/var/lib/proxmenux/pending-restore/</code>, grava <code>plan.env</code>, <code>apply-on-boot.list</code> e <code>rs-skip-paths.txt</code> e ativa <code>proxmenux-restore-onboot.service</code> para a próxima inicialização."
},
{
"stage": "3b",
"name": "Importação de pools de dados",
"reads": "manifest.storage_inventory + estado ZFS do destino",
"action": "<code>_rs_import_data_pools</code> tenta importar cada pool ZFS que não contém a raiz e tem todos os discos presentes no destino. Com hostid de outro host, tenta novamente com <code>zpool import -f</code>. Se faltar um disco, o pool é ignorado com aviso. O resultado por pool é registrado em <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
},
{
"stage": "4",
"name": "Instalar pacote",
"reads": "metadata/packages.manual.list",
"action": "<code>_rs_run_complete_extras</code> executa o filtro de segurança em cascata e chama <code>apt-get install -y</code> com a lista de pacotes sobreviventes. Saída completa vai para <code>/var/log/proxmenux/restore-apt-*.log</code>."
},
{
"stage": "5",
"name": "Após o arranque",
"reads": "rootfs (já aplicado) + components_status.json",
"action": "Após reiniciar, <code>apply_pending_restore.sh</code> reproduz os caminhos diferidos e <code>apply_cluster_postboot.sh</code> executa <code>update-initramfs</code>, <code>update-grub</code> (ou <code>proxmox-boot-tool refresh</code>) e itera sobre <code>components_status.json</code> disparando o gancho <code>--auto-reinstall</code> de cada componente."
}
]
},
"whyItWorks": {
"heading": "Por que dividir o backup em três blocos",
"body": "A divisão segue o <strong>ciclo de vida</strong> dos dados. O sistema de arquivos é transferido com <code>rsync</code>: rápido, transparente e atômico por arquivo. O estado de configuração a interpretar antes das alterações é <strong>JSON estruturado</strong>, legível separadamente, versionável por esquema e comparável automaticamente com o estado do destino. O software a reinstalar é descrito em um <strong>inventário</strong> de nomes e versões; o gerenciador de pacotes e os instaladores do ProxMenux escolhem os binários adequados. Cada bloco atende ao próprio objetivo. Juntos, buscam uma restauração coerente com tolerância a falhas: um manifesto corrompido deixa rootfs recuperável, um pacote ausente não impede instalar componentes e uma falha em uma entrada não interrompe a seguinte."
}
}
web/messages/pt/docs/backup-restore/index.json
+93
View File
@@ -0,0 +1,93 @@
{
"meta": {
"title": "ProxMenux Backup e restauração — Visão geral | Backup e restauração completos do host para Proxmox VE",
"description": "ProxMenux Backup & Restore captura o estado completo de um host Proxmox – sistema de arquivos, manifesto de configuração estruturado e pacotes/componentes instalados – e o reproduz no mesmo host ou em um host diferente. O backup e a restauração são independentes: não há dependências externas e as restaurações entre kernels são suportadas por meio de um filtro de subconjunto seguro com reconhecimento de direção e hidratação independente do kernel.",
"ogTitle": "ProxMenux Backup e restauração — Visão geral",
"ogDescription": "Backup e restauração completos do host para Proxmox VE com manifesto estruturado, lista de pacotes e reinstaladores de componentes.",
"twitterTitle": "ProxMenux Backup e restauração | ProxMenux",
"twitterDescription": "Backup e restauração completos do host para Proxmox VE com manifesto estruturado, lista de pacotes e reinstaladores de componentes."
},
"header": {
"title": "Backup e restauração",
"description": "Backup e restauração de host completo para Proxmox VE. Captura o sistema de arquivos, a configuração e os componentes instalados em um único arquivo e reproduz o host na mesma instalação do Proxmox ou em uma instalação diferente, sem dependências externas.",
"section": "Backup e restauração"
},
"intro": {
"title": "O que é, em um parágrafo",
"body": "Uma cópia do ProxMenux guarda o estado completo de um host Proxmox: <strong>o sistema de ficheiros</strong>, com os diretórios relevantes em <code>/etc</code>, <code>/root</code> e <code>/var/lib/pve-cluster</code> e os caminhos personalizados opcionais; <strong>um manifesto estruturado</strong> em JSON com o hardware detetado, parâmetros do kernel, configuração de rede, estado do ZFS, utilizadores e entradas cron; e <strong>um inventário de aplicações</strong>, com os pacotes que o APT marca como instalados manualmente e os componentes instalados pelo ProxMenux, incluindo as versões exatas. Os três destinos suportados — arquivo local, Proxmox Backup Server (recomendado) e Borg — recebem o mesmo conteúdo autónomo. Qualquer um permite reconstruir o host de destino sem que o host de origem tenha de estar acessível durante o restauro."
},
"video": {
"heading": "Vídeo passo a passo",
"intro": "Prefere assistir o Backup e Restauração em ação antes de configurá-lo? Este passo a passo abrange uma demonstração completa do recurso em ProxMenux.",
"title": "ProxMenux — Passo a passo sobre backup e restauração",
"caption": "Vídeo externo em YouTube. Reproduz no modo de privacidade aprimorada (sem cookies até você apertar play)."
},
"whatItIsNot": {
"heading": "O que não é",
"intro": "Esta secção abrange a cópia de segurança e o restauro <strong>do host</strong>: a instalação do Proxmox, não as aplicações e os sistemas convidados que nela são executados.",
"items": [
"<strong>Não é uma ferramenta de backup de VM/CT.</strong> Esta funcionalidade não guarda os discos nem o estado da RAM dos sistemas convidados; essa é a função do <code>vzdump</code>. Os <strong>ficheiros de configuração</strong> dos convidados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> e <code>lxc/*.conf</code>) <strong>são</strong> guardados. Após o restauro, o inventário reaparece e os discos podem ser restaurados ou associados a partir de um backup existente no PBS ou em armazenamento local.",
"<strong>Não é uma operação sobre todo o cluster.</strong> Cada nó cria a sua própria cópia. A pertença ao cluster é guardada em <code>/etc/pve</code> para permitir reintegrar um nó restaurado, mas recuperar todo o cluster exige coordenar o restauro dos vários nós.",
"<strong>Não é uma imagem completa do disco.</strong> Os binários do kernel, o initramfs e a partição de arranque não são guardados. Durante o restauro, o ProxMenux utiliza os ficheiros de arranque do host de destino, regenerados automaticamente por <code>update-initramfs</code> e pela ferramenta do gestor de arranque, e instala os controladores adequados ao kernel em execução no destino."
]
},
"threePillars": {
"heading": "Os três pilares de um backup",
"intro": "Um arquivo ProxMenux é estruturado em torno de três cargas independentes. A restauração usa as três em conjunto para reproduzir o host de origem em um destino que pode nem ter o mesmo kernel instalado.",
"diagramCaption": "Cada backup envia as mesmas três cargas, independentemente do destino. A restauração consome todos os três: rootfs para estabelecer arquivos, manifesto para detectar desvios e diferenças entre kernels e inventário de aplicativos para reinstalar pacotes e componentes no próprio kernel do destino.",
"pillar1Label": "Sistema de ficheiros",
"pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, mais um\ninstantâneo sqlite3\nde /var/lib/pve-cluster,\n+ caminhos opcionais)",
"pillar2Label": "Manifesto",
"pillar2Detail": "manifest.json\n(hardware, parâmetros\ndo kernel, rede,\nZFS, usuários, cron,\npools ZFS, armazenamento)",
"pillar3Label": "Aplicativos",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(pacotes APT manuais + instaladores\nProxMenux com versões)"
},
"restoreIsUniversal": {
"heading": "A restauração reproduz o host de origem, não o arquivo",
"body": "A restauração de um backup ProxMenux não extrai apenas o sistema de arquivos. O fluxo de restauração lê o manifesto para detectar desvios entre a origem e o destino (diferenças de hardware, renomeações de NIC, versão do kernel, identidade do pool ZFS), reproduz o sistema de arquivos e aciona o instalador de componente correto para cada serviço que foi instalado na origem (driver NVIDIA, Coral TPU, ferramentas de GPU AMD, ferramentas Intel GPU). Cada instalador é executado no <strong>kernel atual do destino</strong>, portanto, o host restaurado não depende da presença do kernel da origem. Quando o kernel do destino é mais recente que o do backup, um passo de <strong>hidratação</strong> independente do kernel mescla o próprio ajuste do usuário (tokens IOMMU, IDs de dispositivos VFIO, peculiaridades personalizadas, chaves GRUB) na nova configuração de inicialização do destino sem copiar arquivos vinculados ao kernel literalmente."
},
"twoInterfaces": {
"heading": "Duas interfaces, um back-end",
"intro": "Cada etapa do fluxo de trabalho de backup e restauração está disponível em dois pontos de entrada. Ambos chamam a mesma biblioteca shell, produzem arquivos idênticos e leem o mesmo registro de tarefas.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "menu → Utilitários →\nBackup/restauração de host\n\nFluxo baseado em diálogo,\nSSH amigável, programável\npara uso não supervisionado.",
"webLabel": "ProxMenux Monitor (Web UI)",
"webDetail": "Aba Backups na\ninterface web do Monitor.\n\nRestauração com um clique,\nacompanhamento dos logs ao vivo,\nintegração com notificações e o\nvisualizador de diferenças da reversão."
},
"whereNext": {
"heading": "Para onde ir a partir daqui",
"intro": "Cada subseção abaixo aborda detalhadamente um aspecto do fluxo de trabalho. Comece com <em>Como funciona</em> se o objetivo é entender o que o arquivo contém e por quê. Vá para <em>Destinos</em> para configurar o destino da cópia. Leia <em>Restauração</em> e <em>Restauração entre kernels</em> para o lado da recuperação.",
"items": [
{
"label": "Como funciona",
"href": "/docs/backup-restore/how-it-works",
"tail": "— os três payloads (rootfs, manifesto, aplicações) em detalhes, com os coletores que os produzem e o formato de cada arquivo."
},
{
"label": "Destinos",
"href": "/docs/backup-restore/destinations",
"tail": "— comparação entre local, Proxmox Backup Server (recomendado) e Borg, e como configurar cada um."
},
{
"label": "Criando backups",
"href": "/docs/backup-restore/creating-backups",
"tail": "— backups únicos, perfil de caminho padrão, adição de caminhos personalizados, criptografia para PBS."
},
{
"label": "Trabalhos agendados",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": "— novos trabalhos versus anexação a um trabalho PVE vzdump existente, formatos de agendamento, modal de detalhes do trabalho."
},
{
"label": "Restauração",
"href": "/docs/backup-restore/restoring",
"tail": "— as três ações em um arquivo (visualizar, baixar, restaurar), restauração completa versus restauração personalizada, o despachante pós-inicialização e por que os últimos dez minutos são importantes."
},
{
"label": "Restauração entre kernels",
"href": "/docs/backup-restore/cross-kernel",
"tail": " — comportamento que considera a direção da mudança de versão quando o kernel do destino difere do kernel do backup, filtro de subconjunto seguro e quatro fases de hidratação."
}
]
}
}
web/messages/pt/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/pt/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Trabalhos agendados — temporizadores, modo de anexação, retenção ProxMenux",
"description": "Trabalhos de backup programados do host ProxMenux. Dois modos de criação (horário systemd próprio ou anexar a um trabalho existente PVE vzdump), valores de retenção aplicados por trabalho via proxmox-backup-client/borg/local prune, layout de armazenamento sob /var/lib/proxmenux/backup-jobs, e o script de execução que produz arquivos idênticos ao fluxo interativo.",
"ogTitle": "Cópia de segurança ProxMenux — tarefas agendadas",
"ogDescription": "Backups de host agendados não vigiados com modo de anexação, retenção e os mesmos três destinos do fluxo interativo.",
"twitterTitle": "Trabalhos agendados | ProxMenux",
"twitterDescription": "Trabalhos de backup agendados sem acompanhamento com modo de anexação e retenção."
},
"header": {
"title": "Trabalhos agendados",
"description": "Trabalhos de backup da máquina não vigiados. Dois modelos de criação: um novo trabalho independente com sua própria programação, ou um trabalho anexado a uma tarefa existente PVE vzdump que herda o cronograma e retenção dessa tarefa. Ambos produzem arquivos idênticos ao fluxo interativo.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Os dois modelos de trabalho programados",
"body": "Um trabalho programado pode ser criado seguindo um dos dois modelos:",
"modelsList": [
"<strong>Novo trabalho independente</strong> — ProxMenux define o horário de trabalho com seu próprio temporizador systemd, independente de qualquer outra tarefa no host. Compatível com os três destinos: Local, PBS e Borg.",
"<strong>Anexar a uma tarefa existente PVE vzdump</strong> — o trabalho não tem agendamento próprio; ele é executado automaticamente sempre que a tarefa pai PVE vzdump que já faz backup das VMs e LXCs nesta máquina dispara. Herda a programação e a retenção da tarefa dos pais. Compatível com Local e PBS (Borg não é suportado porque PVE não tem agendador nativo para Borg)."
]
},
"attachBadge": {
"title": "Modo de anexação — recomendado quando já existe uma tarefa PVE vzdump",
"body": "Se já existe uma tarefa vzdump PVE para as VMs e LXCs do nó, anexar o backup do host faz com que ele seja executado depois do backup dos convidados, no <strong>mesmo ciclo de backup</strong>. Na restauração, as configurações dos convidados vêm do backup do host (em <code>/etc/pve</code>) e os discos vêm dos backups vzdump desse ciclo. Isso ajuda a coordenar a recuperação do nó inteiro, mas não é um snapshot atômico: alterações durante o ciclo podem deixar diferenças entre a configuração do host e o estado dos discos dos convidados."
},
"frequencyBadge": {
"title": "Frequência recomendada",
"body": "Para maximizar a compatibilidade entre um backup do host e sua restauração futura, faça backups frequentes. Quanto mais próxima a cópia estiver do estado atual do host, menos diferenças de configuração, pacotes e componentes a restauração precisará conciliar."
},
"modes": {
"heading": "Os dois modos",
"rows": [
{
"mode": "Novo trabalho agendado",
"backends": "Local, PBS, Borg",
"schedule": "Expressão <code>OnCalendar</code> própria (sintaxe de calendário systemd, por exemplo <code>daily</code> ou <code>Mon..Fri 03:00</code>).",
"retention": "Solicitado separadamente: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Aplicado pelo script de execução após cada backup bem sucedido."
},
{
"mode": "Anexar a uma tarefa PVE vzdump",
"backends": "Local, PBS (Borg não tem agendador do lado PVE)",
"schedule": "Herdado da tarefa PVE principal. Nenhum temporizador systemd é instalado no lado do ProxMenux.",
"retention": "Herdada da configuração <code>prune-backups</code> da tarefa principal (mapeada um a um para as variáveis <code>KEEP_*</code> do script de execução via <code>hb_pve_prune_to_keep_env</code>)."
}
]
},
"attachDetail": {
"heading": "Como funciona o modo de anexação",
"intro": "O PVE grava as tarefas <code>vzdump</code> em <code>/etc/pve/jobs.cfg</code>, com uma seção por tarefa indicando o armazenamento dos backups de VM e LXC. O modo de anexação exige um backend suportado pelo ProxMenux (Local ou PBS). O backup do host é executado pelo hook job-end após o fim da tarefa de backup dos convidados.",
"steps": [
{
"step": "1",
"detail": "Durante a criação do trabalho, ProxMenux lista tarefas PVE pai compatíveis via <code>hb_pve_list_vzdump_jobs_for_backend</code>. O utilizador escolhe uma."
},
{
"step": "2",
"detail": "O <code>.env</code> do trabalho é escrito com <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> e os valores herdados <code>KEEP_*</code>; nenhum temporizador systemd é criado."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> registra um hook em <code>/etc/vzdump.conf</code>. Na fase job-end de qualquer tarefa vzdump, compara o <code>$STOREID</code> recebido com o <code>PVE_STORAGE</code> de cada trabalho anexado e habilitado, chamando o script de execução para as correspondências. A associação é feita pelo armazenamento, não pelo ID da tarefa principal selecionada."
},
{
"step": "4",
"detail": "O arquivo é salvo no mesmo armazenamento dos backups vzdump: <code>path/dump/</code> para Local ou o repositório PBS configurado na entrada de armazenamento PVE."
}
],
"outroBody": "O modo de anexação não tem temporizador próprio. Desabilitar ou excluir a tarefa PVE principal selecionada interrompe esse disparo, mas outra tarefa vzdump usando o mesmo armazenamento ainda pode acionar o backup do host. Desabilite ou exclua o próprio trabalho ProxMenux para impedir isso. Ao ser desabilitada, a entrada permanece no disco e pode ser reativada ou anexada novamente."
},
"storageLayout": {
"heading": "Arquivos que compõem um trabalho",
"intro": "Cada trabalho agendado é totalmente descrito por três ou quatro arquivos no disco. Lendo-os dá a configuração completa do trabalho sem depender da interface.",
"rows": [
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Infraestrutura, ID de backup ou destino, agenda (novo modo) ou pai PVE (modo de Attach), sinalizador habilitado, valores de retenção <code>KEEP_*</code>, ponteiros de credenciais."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "Um caminho absoluto por linha — a seleção congelada resolvido a partir do perfil no tempo de criação de emprego. A edição do ficheiro volta a executar o trabalho com a nova selecção no próximo temporizador."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "Apenas modo novo. O serviço invoca o <code>run_scheduled_backup.sh JOB_ID</code>. O timer agenda-o com <code>Persistent=true</code> (execuções perdidas recuperadas na próxima inicialização) e um pequeno <code>RandomizedDelaySec=120</code> para espalhar carga quando vários trabalhos compartilham a mesma expressão OnCalendar."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Somente modo de anexação. Instalado uma vez por <code>hb_install_vzdump_hook</code>; compara <code>PVE_STORAGE</code> de cada trabalho anexado com <code>$STOREID</code>, passado pelo PVE ao hook."
}
]
},
"runner": {
"heading": "O que um trabalho faz quando dispara",
"intro": "Cada trabalho — novo ou anexado — executa a mesma sequência de três passos:",
"steps": [
"<strong>Prepare o backup.</strong> Lê a configuração do trabalho (destino, perfil, caminhos) e monta a árvore de arquivos exatamente da mesma forma que o fluxo interativo faz. O resultado é o mesmo arquivo que um backup manual com essas configurações produziria.",
"<strong>Escreva o destino.</strong> Envia ou escreve o arquivo para o destino configurado — um arquivo <code>.tar.zst</code> local, um backup PBS, ou um arquivo Borg — usando exatamente as mesmas ferramentas e credenciais que um backup manual para o mesmo destino usaria.",
"<strong>Aplicar retenção.</strong> Remove backups antigos do destino, mantendo as contagens <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configuradas no trabalho. A poda é realizada pelo próprio destino: PBS aplica sua própria retenção, Borg executa <code>borg prune</code>, e para ProxMenux Local apaga os arquivos que caem fora da janela <code>keep-last</code>."
]
},
"management": {
"heading": "Gestão de tarefas",
"intro": "O menu de agendamento (Scripts TUI) e a aba Monitor Backups expõem as mesmas ações em qualquer trabalho.",
"rows": [
{
"action": "Executar agora",
"detail": "Chama imediatamente o script de execução, sem esperar o temporizador ou o hook vzdump. Útil para verificar a configuração sem aguardar a próxima execução agendada."
},
{
"action": "Activar / Desactivar",
"detail": "Novo modo: <code>systemctl enable/disable --now</code> o temporizador. Modo Anexar: altera o sinalizador <code>ENABLED</code> no env de trabalho — o script gancho honra-o na próxima execução PVE."
},
{
"action": "Editar",
"detail": "Abre novamente o destino, agenda, perfil e avisos de retenção e reescreve os arquivos de trabalho. Preserva a identificação do trabalho."
},
{
"action": "Excluir",
"detail": "Remove o env do trabalho, o arquivo de caminhos, o temporizador e o serviço systemd (modo novo) e desativa a associação ao hook (modo de anexação). Não altera os arquivos já existentes no destino."
},
{
"action": "Ver registo",
"detail": "Mostra em tempo real <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — um arquivo de log por execução. O executor também emite uma linha de status compacta para journald no serviço systemd."
}
]
},
"notifications": {
"heading": "Notificações",
"body": "Cada execução programada dispara os mesmos eventos <code>hb_notify_lifecycle</code> que o fluxo interativo (<code>start</code>, <code>complete</code>, <code>fail</code>). Se os canais de notificação estiverem configurados no Monitor, os trabalhos não vigiados mostram seus resultados da mesma forma que backups manuais – um usuário não precisa verificar o log para saber se um trabalho foi bem sucedido."
},
"whereNext": {
"heading": "Para onde ir a seguir",
"items": [
{
"label": "Criando backups",
"href": "/docs/backup-restore/creating-backups",
"tail": " — o fluxo interactivo que partilha a infra-estrutura com o agendador."
},
{
"label": "Destinos",
"href": "/docs/backup-restore/destinations",
"tail": " — a configuração por infra-estrutura utilizada tanto pelo fluxo interactivo como pelo agendador."
},
{
"label": "Restauração",
"href": "/docs/backup-restore/restoring",
"tail": " — o fluxo que utiliza os backups produzidos pelos trabalhos."
}
]
}
}
web/messages/sk/docs/backup-restore/creating-backups.json
+220
View File
@@ -0,0 +1,220 @@
{
"meta": {
"title": "Vytváranie záloh — interaktívny postup zálohovania | ProxMenux",
"description": "Interaktívny postup zálohovania v ProxMenux: dva vstupné body (ponuka TUI nástroja Scripts a webové rozhranie Monitor), tri ciele, dva režimy profilu, jeden krok dočasnej prípravy a jeden potvrdzovací dialóg. Stránka opisuje maticu šiestich možností, predvolený a vlastný profil a to, čo používateľ vidí od výberu zálohy až po uloženie archívu do cieľa.",
"ogTitle": "Zálohovanie ProxMenux — vytváranie záloh",
"ogDescription": "Interaktívny postup zálohovania s tromi cieľmi, dvoma profilmi a spoločným krokom dočasnej prípravy.",
"twitterTitle": "Vytváranie záloh | ProxMenux",
"twitterDescription": "Interaktívny postup zálohovania s tromi cieľmi a dvoma režimami profilu."
},
"header": {
"title": "Vytváranie záloh",
"description": "Interaktívny postup zálohovania: vyberte cieľ a profil, skontrolujte súhrn v potvrdzovacom dialógu a sledujte uloženie archívu. Oba vstupné body používajú rovnaký backend a vytvárajú zhodné archívy.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Dva vstupné body, rovnaká funkčnosť",
"body": "TUI nástroja Scripts a webové rozhranie Monitor ponúkajú <strong>presne rovnaké funkcie</strong>. Každá záloha — manuálna aj plánovaná — prechádza rovnakou maticou výberu (tri ciele × dva profily) a pre každú bunku volá rovnakú funkciu backendu (<code>_bk_pbs</code>, <code>_bk_borg</code> alebo <code>_bk_local</code>). Archívy vytvorené cez oba vstupné body sú nerozoznateľné. Výber závisí od preferencií: TUI je vhodné pre SSH a skripty; Monitor umožňuje ovládanie myšou a obsahuje aj zobrazenia upozornení a priebežného výpisu záznamov."
},
"entryPoints": {
"heading": "Dva vstupné body",
"rows": [
{
"entry": "ProxMenux Scripts (TUI)",
"path": "menu → Utilities → Host Config Backup",
"detail": "Dialógový tok, SSH-priateľský. Hlavné menu predstavuje šesť možností priamo. Používa <code>backup_menu</code> v <code>backup_host.sh</code>."
},
{
"entry": "ProxMenux Monitor (webové rozhranie)",
"path": "Backups tab → Create backup",
"detail": "Postup vedený sprievodcom. Rovnakých šesť možností je zobrazených v dvojkrokovom formulári (cieľ → profil). Cez rozhranie Flask API sa volajú rovnaké funkcie backendu."
}
]
},
"modes": {
"heading": "Manuálne vs plánované zálohy",
"body": "Zálohy možno vytvárať v dvoch režimoch: <strong>manuálne</strong> (interaktívny postup opísaný na tejto stránke — používateľ vyberie cieľ a profil z ponuky a sleduje uloženie archívu) alebo <strong>plánovane</strong> (úloha bez obsluhy, ktorá sa spúšťa časovačom v štýle cron a používa pravidlá uchovávania nastavené pre danú úlohu). Oba režimy podporujú rovnaké tri ciele a dva profily a sú dostupné cez oba vstupné body — ponuku TUI nástroja Scripts a kartu Backups v Monitore. Plánované úlohy používajú cez <code>run_scheduled_backup.sh</code> rovnaké funkcie backendu ako manuálny postup; vytvorené archívy sú nerozoznateľné.",
"seeAlso": "Stránka plánovaných úloh opisuje celý postup vrátane vytvorenia úlohy, jej pripojenia k existujúcemu časovaču vzdump v PVE a nastavenia hodnôt uchovávania.",
"monitorAlt": "ProxMenux Monitor Zálohy zobrazí nový plánovaný dialóg zálohovania s cieľovým, profilom, harmonogramom a retenčnými poľami.",
"monitorCaption": "Plánovaná záloha — ProxMenux Monitor. Rovnaký dialóg sprievodcu ako pri manuálnej zálohe má v dolnej časti polia plánu a uchovávania pre spúšťanie bez obsluhy."
},
"matrix": {
"heading": "Matica šiestich možností",
"intro": "Výber určuje spustený backend aj použitú stratégiu výberu ciest. Podrobnosti o konfigurácii každej bunky nájdete na stránkach jednotlivých cieľov.",
"rows": [
{
"combo": "1",
"destination": "PBS",
"profile": "Štandardné",
"action": "Uploaduje štandardný profil plus trvalé doplnky do nakonfigurovaného PBS úložiska."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Štandardné",
"action": "Vytvorí archív so štandardným profilom plus trvalé doplnky vo vybranom úložisku Borg."
},
{
"combo": "3",
"destination": "Lokálne",
"profile": "Štandardné",
"action": "Napíše archív <code>.tar.zst</code> so štandardným profilom plus trvalé doplnky k nakonfigurovanému lokálnemu cieľu."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Vlastné",
"action": "Pred odoslaním do PBS otvorí výber ciest; používateľ zaškrtne požadované cesty a môže pridať nové."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Vlastné",
"action": "Pred vytvorením archívu Borg otvorí výber ciest."
},
{
"combo": "6",
"destination": "Lokálne",
"profile": "Vlastné",
"action": "Pred zápisom lokálneho súboru <code>.tar.zst</code> otvorí výber ciest."
}
]
},
"profiles": {
"heading": "Štandardný vs vlastný profil",
"defaultTitle": "Predvolený profil",
"defaultBody": "Predvolený profil je pripravený zoznam z <code>hb_default_profile_paths</code> (opísaný v časti <em>Ako to funguje</em> pod nadpisom <em>Kategórie ciest</em>) spolu so všetkými položkami zo súboru trvalých doplnkov <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. Používateľ potvrdí cieľ a možnosti šifrovania a záloha pokračuje bez ďalšieho výberu ciest.",
"customTitle": "Vlastný profil",
"customBody": "Vlastný profil otvorí zoznam so všetkými cestami predvoleného profilu (nezaškrtnuté) a všetkými trvalými doplnkami (vopred zaškrtnuté, s predponou <code>[+]</code>). Používateľ zaškrtne cesty pre toto spustenie a cez <em>Pridať vlastnú cestu</em> môže doplniť novú absolútnu cestu. Takto pridaná cesta sa uloží do <code>backup-extra-paths.txt</code>, aby ju budúce zálohy zahrnuli automaticky bez opätovného pridávania. Odškrtnutie trvalého doplnku ho vynechá len pri tomto spustení, ale neodstráni ho zo súboru — na odstránenie slúži samostatná akcia <em>Spravovať vlastné cesty</em> mimo postupu zálohovania.",
"customPickerAlt": "Vlastný kontrolný zoznam profilu zobrazujúci predvolené cesty profilu (nezaškrtnuté) a trvalé doplnky (vopred zaškrtnuté s predponou [+]) plus tlačidlá na pridanie novej cesty alebo potvrdenie výberu.",
"customPickerCaption": "Vlastný profil — výber ciest. Cesty predvoleného profilu nie sú zaškrtnuté; trvalé doplnky sú vopred zaškrtnuté s predponou [+]. Používateľ zaškrtne cesty pre toto spustenie.",
"manageCustomAlt": "Ponuka správy vlastných ciest so zoznamom trvalých doplnkov a možnosťami pridávania, odstraňovania a úprav.",
"manageCustomCaption": "Spravovať vlastné cesty — miesto, kde sa pridávajú alebo odstraňujú trvalé doplnky. Každá tu uvedená cesta sa automaticky zahrnie do záloh v predvolenom režime bez potreby otvárať výber ciest vlastného profilu."
},
"commonPipeline": {
"heading": "Čo beží bez ohľadu na cieľ",
"intro": "Po určení profilu každý backend vykoná rovnaký postup dočasnej prípravy a potom pokračuje vlastným spôsobom odosielania. <code>hb_prepare_staging</code> zostaví strom archívu v <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> a naplní každý z troch blokov údajov.",
"steps": [
{
"step": "1",
"name": "Zostava rootfs",
"detail": "Pre každú vybranú cestu spustí <code>rsync -a</code> do <code>staging_root/rootfs/</code>. Databáza pmxcfs v <code>/var/lib/pve-cluster/config.db</code> sa zachytí samostatne cez <code>sqlite3 .backup</code>, aby vznikla konzistentná snímka bez zastavenia klastra; pomocné súbory <code>.db-wal</code> / <code>.db-shm</code> sa z rsync vylúčia. Ak <code>sqlite3</code> nie je dostupné, uloží sa namiesto toho súbor <code>config.db.raw-fallback</code>, ktorý obnova pri importe prevezme ako databázu. Z <code>/root/</code> sa vylúčia dočasné podcesty (história bash, vyrovnávacie pamäte, kôš). Cesty chýbajúce v zdroji sa zapíšu do <code>metadata/missing_paths.txt</code> bez zastavenia zálohy."
},
{
"step": "2",
"name": "Vytvorenie manifestu",
"detail": "<code>build_manifest.sh</code> koordinuje šesť zberných modulov a zapíše <code>manifest.json</code> do koreňa dočasného adresára. Pri zlyhaní modulu sa pre príslušnú sekciu použije zdokumentovaná prázdna predvolená hodnota; manifest zostane platný."
},
{
"step": "3",
"name": "Zoznam balíkov",
"detail": "<code>apt-mark showmanual</code> je zachytený doslovne do <code>metadata/packages.manual.list</code>. Stav komponentu je už vnútri obnovených rootfs (<code>components_status.json</code>), pretože <code>/usr/local/share/proxmenux/</code> je súčasťou štandardného profilu."
},
{
"step": "4",
"name": "Informácie o spustení",
"detail": "<code>metadata/run_info.env</code> zaznamenáva identitu spustenia zálohy – názov hostiteľa, časovú pečiatku, verziu jadra – používanú pri kontrole kompatibility obnovy na určenie smeru medzi jadrami."
},
{
"step": "5",
"name": "Oznámenie (začiatok)",
"detail": "Spustí sa <code>hb_notify_lifecycle \"start\"</code>. Ak sú v Monitore nastavené upozornenia, používateľ dostane udalosť <em>Zálohovanie hostiteľa sa začalo</em>. Bez nakonfigurovaných kanálov sa upozornenie neodošle."
}
]
},
"included": {
"heading": "Čo ide dnu a čo zostane vonku",
"intro": "Každá cesta v určenom profile (predvolené + trvalé doplnky + výber vo vlastnom režime) je skopírovaná s <code>rsync -aAXH --numeric-ids</code>. Spoločný zoznam vylúčení sa vzťahuje na každú cestu a dva adresáre majú dodatočné výnimky špecifické pre jednotlivé trasy.",
"globalTitle": "Globálne vylúčenia (uplatnené na každú cestu)",
"globalItems": [
"<code>images/</code> — výpisy obrazov.",
"<code>dump/</code> — výstupy vzdump.",
"<code>tmp/</code> - dočasné súbory.",
"<code>*.log</code> — súbory záznamov."
],
"rootTitle": "Výnimky <code>/root/</code>",
"rootBody": "<code>/root/</code> je súčasťou predvoleného profilu, aby sa do archívu zahrnuli používateľské skripty a konfigurácia. Dočasné podcesty sa vynechajú:",
"rootItems": [
"<code>.bash_history</code>",
"<code>.cache/</code>",
"<code>tmp/</code>",
"<code>.local/share/Trash/</code>"
],
"proxmenuxTitle": "Výnimky <code>/usr/local/share/proxmenux/</code>",
"proxmenuxBody": "Tento adresár obsahuje iba používateľský stav — <code>components_status.json</code>, predvoľby a vyrovnávaciu pamäť po inštalácii. Kód, ktorý už cieľ má z vlastnej inštalácie ProxMenux, sa vylúči, aby obnova neprepísala aktuálne binárne súbory cieľa staršími:",
"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": "Cesty mimo profilu",
"notInProfileBody": "Všetko, čo nie je uvedené v <code>hb_default_profile_paths</code> a nepridal ako vlastné alebo trvalé extra nie je súčasťou zálohy. Pozoruhodné príklady:",
"notInProfileItems": [
"<strong>Disky VM a LXC</strong> — zálohuje ich <code>vzdump</code>, nie táto funkcia. Konfiguračné súbory hostí v <code>/etc/pve/nodes/*/qemu-server/*.conf</code> a <code>lxc/*.conf</code> sa zachytia (nachádzajú sa v <code>/etc/pve</code>), aby obnova obnovila inventár; samotné disky sa znovu pripoja z existujúcej zálohy vzdump/PBS.",
"<strong><code>/boot</code> a <code>/boot/efi</code></strong> — binárne súbory jadra, initramfs a oddiel UEFI ESP po obnove znova vytvorí cieľový systém pomocou <code>update-initramfs</code>, <code>update-grub</code> alebo <code>proxmox-boot-tool refresh</code>. Zavádzač sa nikdy nekopíruje doslova.",
"<strong>Súborové systémy jadra a behu systému</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> a <code>/run</code> sú pseudosúborové systémy vytvárané jadrom a udev; nikde sa trvalo neukladajú.",
"<strong>Binárne súbory balíkov v <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — APT na cieľovom systéme ich znova nainštaluje podľa <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — priebežný stav konkrétneho hostiteľa, ktorý sa neobnovuje.",
"<strong><code>/home/USER</code></strong> Nie v štandardnom profile. Pridať ako vlastnú cestu, keď systém nesie užívateľské domovské adresáre, ktoré musia prežiť obnovenie."
],
"customPathsTitle": "Ako sa spracúvajú vlastné cesty",
"customPathsBody": "Vlastná cesta pridaná priamo vo vlastnom režime alebo uložená v <code>backup-extra-paths.txt</code> prechádza rovnakým postupom <code>rsync</code> ako cesty predvoleného profilu. Platia globálne vylúčenia. Ak sa vlastná cesta nachádza pod <code>/root/</code> alebo <code>/usr/local/share/proxmenux/</code>, naďalej platia aj uvedené vylúčenia pre konkrétnu cestu. Každá archivovaná cesta — predvolená aj vlastná — sa zaznamená v <code>metadata/paths_archived.txt</code>. Cesty, ktoré v zdroji neexistujú, sa zapíšu do <code>metadata/missing_paths.txt</code> bez zastavenia zálohy."
},
"archiveStructure": {
"heading": "Štruktúra archívu",
"intro": "Dočasný prípravný adresár vytvorený každým backendom má rovnaké usporiadanie bez ohľadu na miesto určenia. Archív tarball, PBS <code>.pxar</code> alebo Borg uchováva tento strom doslovne.",
"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": "Zhrnutie potvrdenia",
"body": "Pred zápisom akýchkoľvek údajov do cieľa ProxMenux zobrazí súhrnný dialóg s cieľom, ID zálohy alebo názvom archívu, stavom šifrovania a zoznamom kopírovaných ciest. Zrušenie v tomto bode zálohovanie bezpečne ukončí — obslužný mechanizmus <code>trap</code> nastavený vo funkcii backendu odstráni dočasný prípravný adresár a do cieľa sa nedostanú žiadne čiastočné údaje."
},
"writing": {
"heading": "Písanie na miesto určenia",
"intro": "Po potvrdení každý backend vykoná vlastný krok zápisu. Podrobnosti opisujú stránky jednotlivých cieľov; spoločnými prvkami sú záznam, sprievodný súbor a upozornenie o dokončení.",
"rows": [
{
"topic": "Súbor záznamu",
"detail": "Každý backend napíše celý svoj výstup do <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> a pri zlyhaní ponúkne jeho otvorenie v rolovacom dialógu. Cesta záznamu je vytlačená v súhrne dokončenia iba vtedy, keď má súbor obsah."
},
{
"topic": "Sprievodný súbor (iba lokálne)",
"detail": "<code>hb_write_archive_sidecar</code> vytvorí <code>*.proxmenux.json</code> vedľa lokálneho archívu, takže Monitor ho identifikuje ako zálohu hostiteľa ProxMenux aj po presunutí alebo premenovaní."
},
{
"topic": "Upozornenie (dokončenie/zlyhanie)",
"detail": "Spustí sa <code>hb_notify_lifecycle \"complete\"</code> alebo <code>\"fail\"</code> s trvaním, veľkosťou archívu a — pri zlyhaní — posledným riadkom záznamu, ktorý vyzerá ako chyba."
}
]
},
"finishedScreens": {
"heading": "Ako vyzerá dokončená záloha",
"intro": "Rovnaká udalosť dokončenia sa zobrazí cez oba vstupné body. TUI vypíše súhrn do terminálu; karta Backups v Monitore zobrazí spustenie v zozname archívov s veľkosťou, trvaním a indikátormi stavu.",
"scriptsAlt": "ProxMenux Scripts TUI zobrazujúce dokončenú zálohu hostiteľa – cieľ, ID zálohy, cestu snapshot, veľkosť údajov, trvanie a stav šifrovania.",
"scriptsCaption": "Dokončená záloha — ProxMenux Scripts (TUI). Súhrn dokončenia vypíše cieľ, ID zálohy, názov výslednej snímky alebo archívu, veľkosť údajov, trvanie a stav šifrovania.",
"monitorAlt": "ProxMenux Monitor s kartou Backups znázorňujúcou dokončenú zálohovaciu položku hostiteľa s veľkosťou, trvaním, indikátorom metódy a indikátorom šifrovania.",
"monitorCaption": "Dokončená záloha — karta Backups v ProxMenux Monitor. Nová záloha sa objaví v zozname archívov s indikátorom cieľovej metódy, veľkosťou, trvaním a — ak je to relevantné — ikonou zámku šifrovania."
},
"whereNext": {
"heading": "Kam ísť ďalej",
"items": [
{
"label": "Ciele",
"href": "/docs/backup-restore/destinations",
"tail": " — Detaily konfigurácie pre Local, PBS a Borg."
},
{
"label": "Plánované úlohy",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": " — spúšťanie rovnakej zálohy bez obsluhy podľa plánu namiesto interaktívneho spúšťania."
},
{
"label": "Obnovenie",
"href": "/docs/backup-restore/restoring",
"tail": " — postup, ktorý používa zálohy vytvorené podľa tejto stránky."
}
]
}
}
web/messages/sk/docs/backup-restore/cross-kernel.json
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Obnova medzi rôznymi jadrami — rozpoznanie smeru, bezpečný výber a prispôsobenie | ProxMenux",
"description": "Ako ProxMenux obnoví zálohu hostiteľa na cieľ s inou hlavnou verziou jadra. Vysvetľuje rozpoznanie smeru rozdielu, bezpečný filter vynechávajúci kritické cesty pri novšom cieľovom jadre a štvorfázové doplnenie nastavení IOMMU, ID VFIO a vlastných parametrov bez doslovného kopírovania súborov viazaných na jadro.",
"ogTitle": "ProxMenux Backup — obnova medzi verziami jadra a doplnenie nastavení",
"ogDescription": "Obnova medzi verziami jadra podľa smeru zmeny s bezpečným filtrom a doplnením nastavení nezávislým od jadra.",
"twitterTitle": "Obnova medzi rôznymi jadrami | ProxMenux",
"twitterDescription": "Ako ProxMenux spracováva obnovenie, keď sa cieľové jadro líši od zálohy."
},
"header": {
"title": "Obnova medzi kernelmi",
"description": "Ako ProxMenux zvláda obnovenie, keď cieľový hostiteľ spustí iné jadro od toho, ktoré je zaznamenané v zálohe, najmä keď cieľ spustí novšie jadro. Opisuje, ako sa rozdiel detekuje, ako sa prefiltrujú cesty kritické z hľadiska zavádzania, ktoré by mohli porušiť cieľ, a ako sa užívateľská konfigurácia znovu dodáva bez kopírovania súborov viazaných na jadro doslova.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Každý skok do jadra je riadený inak",
"body": "Jadro hostiteľa Proxmox má verziu ako <code>6.17.13-2-pve</code>. Prvé dve čísla (<strong>6.17</strong>) označujú hlavnú verziu; po ich zmene nemusia byť staršie konfiguračné súbory platné. Pri odlišnej verzii jadra v zálohe a cieli sa postup vetví podľa smeru zmeny, pretože obe situácie majú odlišné riziká. Zálohy s novším jadrom než cieľ sa obnovujú bez filtra, podľa zaznamenaných testov cez viac verzií. Zálohy so starším jadrom potrebujú filter, aby staré nastavenia nebránili štartu novšieho cieľa."
},
"directionCheck": {
"heading": "Kontrola smeru",
"intro": "Počas kontroly kompatibility <code>hb_compat_check</code> porovnáva jadro zaznamenané v manifeste zálohy s aktuálnym jadrom cieľa (<code>uname -r</code>) a klasifikuje obnovenie do jedného z troch prípadov, uložené vo vnútornej premennej <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{
"direction": "same",
"condition": "Hlavná verzia jadra sa zhoduje medzi zálohou a cieľom.",
"behavior": "Úplné obnovenie toku beží nezmenený. Žiadny ďalší filter, žiadna hydratácia, žiadne špeciálne upozornenie v UI."
},
{
"direction": "bk_newer",
"condition": "Jadro zálohy je NOVŠIE než cieľové (napríklad záloha z jadra 7.0 a cieľ s jadrom 6.17).",
"behavior": "Úplný postup obnovy zostáva nezmenený, ako pri <code>same</code>, bez filtra. Uvedené testy overili reinštaláciu ovládačov pre cieľové jadro, nastavenie IOMMU a spustenie VM s odovzdanou GPU."
},
{
"direction": "bk_older",
"condition": "Jadro zálohy je STARŠIE než cieľové (napríklad záloha z jadra 6.17 a cieľ s jadrom 7.0).",
"behavior": "Filter bezpečnej podskupiny a štvorfázová hydratácia nižšie sú aktivované. Obnova pokračuje – cieľ reprodukuje zdroj, ale súbory kritické pri zavádzaní sa neskopírujú doslovne."
}
]
},
"whyBkNewerIsSafe": {
"heading": "Prečo záloha s novším jadrom ako cieľ obnoví nezmenený",
"body": "Pri cieli so <em>starším</em> jadrom než v zálohe používa obnova mechanizmy nezávislé od verzie jadra. Inštalátory ovládačov GPU a PCI zistia bežiace jadro cez <code>uname -r</code> a zostavia DKMS pre cieľ. APT použije binárne balíky cieľovej distribúcie. Parametre IOMMU, napríklad <code>intel_iommu=on</code>, zostávajú stabilné medzi hlavnými verziami. Podľa tohto návrhu sú zoznamy zakázaných modulov, nastavenia GRUB a initramfs zo zálohy syntakticky použiteľné aj na staršom jadre; neznáme parametre jadro ignoruje. ProxMenux preto tento smer spracúva rovnako ako obnovu s rovnakým jadrom."
},
"safeSubsetFilter": {
"heading": "Bezpečný subsetový filter (iba ak je cieľové jadro novšie)",
"intro": "Keď je cieľové jadro novšie ako záložné, kontrola kompatibility pridáva 16 ciest kritických pre štart z <code>hb_unsafe_paths_cross_version</code> do <code>RS_SKIP_PATHS</code>. Tieto cesty sú vylúčené z obnovy, pretože písanie ich verzie zo staršieho jadra nad cieľom spusteným novším spôsobilo paniku jadra pri testovaní. Trasy pokrývajú päť kategórií:",
"categoryRows": [
{
"category": "Zavádzač",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB defaults viazaná na predchádzajúce poradie jadier a stav proxmox-boot-tool (cmdline, ESP UUIDs, háčiky), ktorý odkazuje na cesty a identifikátory zo staršej inštalácie."
},
{
"category": "Kernelové moduly a štartovacie artefakty",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Zoznamy automaticky načítaných modulov premenovaných medzi hlavnými verziami jadra, neplatné voľby modulov a hooky initramfs napísané pre staršie jadro."
},
{
"category": "Úložný systém a identita súborového systému",
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
"reason": "UUID, ktoré v tejto inštalácii nemusia existovať, viaccestné ovládače, ktoré sa menia medzi jadrami, iSCSI parametre, ktoré sa vyvíjajú, pravidlá udev, ktoré sa môžu viazať na neexistujúce podsystémy, stav ZFS (<code>zpool.cache</code> + <code>hostid</code>), ktoré môžu uzamknúť pool ako cudzie."
},
{
"category": "APT zdroje",
"paths": "<code>/etc/apt</code>",
"reason": "Vydania v zdrojoch APT môžu pri ďalšej aktualizácii spôsobiť zníženie verzií kritických balíkov."
},
{
"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": "Vlastné úpravy jednotiek a odkazy .wants viazané na staršiu hlavnú verziu systemd; konfiguračné kľúče, ktoré novší systemd nemusí rozpoznať."
}
],
"outroBody": "Filter beží PRED konfirmačným dialógom, takže užívateľ vidí presný zoznam ciest, ktoré budú preskočené, kategorizované z dôvodu. Obnovenie stále pokračuje všetko ostatné (konfigurácia VM/LXC, sieť, /etc/pve, užívatelia, cron, ProxMenux stav, balíčky, ovládače, /root) je obnovená normálne."
},
"hydration": {
"heading": "Kernel-agnostická hydratácia",
"intro": "Filter vynechá kritické súbory, preto doplnenie znovu použije vybrané nastavenia: parametre IOMMU, ID VFIO, vlastný <code>GRUB_TIMEOUT</code> a zoznamy blokovaných modulov nvidia. Beží pri novšom cieľovom jadre. Zlúčenie cmdline zachová kľúče cieľa a doplní chýbajúce moduly. Povolené hodnoty GRUB a používateľské súbory môžu nahradiť odlišný obsah cieľa. Opakovanie rovnakých vstupov je idempotentné.",
"phaseRows": [
{
"phase": "1a GRUB cesta",
"detail": "Pre hostiteľov s GRUB (ext4/lvm). <code>_rs_hyd_grub</code> zlúči parametre z <code>manifest.kernel_params.cmdline_extra</code> zálohy do <code>GRUB_CMDLINE_LINUX_DEFAULT</code> cieľa a preskočí existujúce kľúče. Potom obnoví povolené kľúče <code>GRUB_*</code> (<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>) zo súboru <code>/etc/default/grub</code> zálohy, ak sa ich hodnoty líšia od cieľa."
},
{
"phase": "1b — systemd-boot / ZFS",
"detail": "Pre systemd-boot (zvyčajne ZFS ako koreňový systém). <code>_rs_hyd_kernel_cmdline</code> zlúči používateľské parametre z <code>cmdline_extra</code> do cieľového <code>/etc/kernel/cmdline</code>, pričom zachová jeho vlastné parametre štartu <code>root=</code>, <code>boot=</code> a <code>rootflags=</code>."
},
{
"phase": "2 — /etc/modules zlúčenie",
"detail": "<code>_rs_hyd_modules</code> dopĺňa moduly z <code>manifest.kernel_params.modules_loaded_at_boot</code>, ktoré sú na bielom zozname (<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>) a ešte nie sú prítomné v cieľovom <code>/etc/modules</code>."
},
{
"phase": "3 — Kopírovanie povolených súborov",
"detail": "<code>_rs_hyd_files</code> skopíruje súbory vytvorené používateľom z prípravného rootfs na živý cieľ, keď sa obsah líši. Whitelist pokrýva súbory VFIO/nvidia/blacklist podľa pravidiel <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code> a ProxMenux VFIO sa viaže na pravidlo + nvidia udev podľa pravidiel <code>/etc/udev/rules.d</code>. Distro-vlastnené súbory (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sú zámerne vylúčené, pretože sa ich obsah mení medzi vydaniami."
},
{
"phase": "4 — Vynútenie obnovy po štarte",
"detail": "Štyri fázy píšu priamo na živý cieľ mimo bežného postupu obnovy. Aby zlúčené žetóny/moduly/súbory nadobudli účinnosť na ďalšom štarte, <code>HB_HYDRATION_APPLIED=1</code> sa šíri cez <code>plan.env</code> na <code>apply_pending_restore.sh</code>, čo núti <code>NEEDS_INITRAMFS=1</code> a <code>NEEDS_GRUB=1</code> bez ohľadu na to, čo bolo v zozname. Post-boot dispečer potom regeneruje initramfs a osvieži bootloader."
}
]
},
"planCommit": {
"heading": "Plánovanie a vykonanie — používateľ najprv vidí náhľad",
"body": "Doplnenie má dva režimy. Pred potvrdením ProxMenux spustí <code>_rs_apply_bk_older_hydration</code> v režime <code>plan</code>: vypočíta zmeny, naplní <code>RS_HYDRATION_SUMMARY</code> zeleným zoznamom akcií a nič nezapíše. Dialóg ho zobrazí vedľa žltého zoznamu vynechaných ciest, aby používateľ vopred poznal zmeny. Po potvrdení spustí rovnakú funkciu v režime <code>commit</code>: tie isté fázy a logika, teraz so zápisom do cieľa. Zrušenie ponechá cieľ nedotknutý."
},
"flowDiagram": {
"heading": "Tok, keď je cieľové jadro novšie ako záložné",
"intro": "Kroky pridané, keď je cieľové jadro novšie, sú v rámci normálneho toku obnovy. Všetko ostatné – horúce použitie, čakajúca príprava, inštalácia balíka, dispečer po spustení – beží identicky ako pri obnove rovnakého jadra.",
"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": "Konkrétne príklady",
"intro": "Doplnenie nastavení má pri bežných scenároch pozorovateľné výsledky. Dva príklady automaticky spracovaných prípadov:",
"rows": [
{
"scenario": "GPU priechod (VFIO)",
"detail": "Zdroj mal <code>intel_iommu=on iommu=pt</code> v cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> v <code>/etc/modules</code>, <code>/etc/modprobe.d/vfio.conf</code> s <code>options vfio-pci ids=10de:2216</code>, a <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydratácia zlučuje žetóny cmdline do cieľovej GRUB alebo jadra cmdline, pridá vfio moduly do <code>/etc/modules</code>, a skopíruje dva používateľom vytvorené modprobe súbory. Pri ďalšom štarte je IOMMU aktívna, moduly VFIO sa načítajú, GPU je viazaný na vfio-pci a VM sa spustí s funkčným odovzdaním GPU."
},
{
"scenario": "Vlastné GRUB predvolené",
"detail": "Zdroj mal <code>GRUB_TIMEOUT=1</code> a <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydratácia číta oba kľúče z <code>/etc/default/grub</code> zálohy, vidí, že sa líšia od čerstvých predvolených inštalácií, a prepíše tieto dva riadky v cieľovom súbore (uloženie všetko ostatné, vrátane <code>GRUB_DISTRIBUTOR</code>, nedotknuté)."
}
]
},
"callout": {
"warningTitle": "Čo sa pri novšom cieľovom jadre neobnovuje",
"warningBody": "Doplnenie obnoví iba vybrané nastavenia považované za prenosné medzi jadrami: parametre IOMMU, ID VFIO, povolené kľúče GRUB a moduly z pevného zoznamu (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Ostatné položky, ako vlastné hooky initramfs v <code>/etc/initramfs-tools/hooks/</code>, nepovolené súbory v <code>/etc/modprobe.d/</code> a vlastné úpravy jednotiek systemd, zostanú vynechané. Môžu používať rozhrania jadra, rozloženie <code>/sys</code> a hooky <code>udev</code>, ktoré sa medzi hlavnými verziami menia a môžu zabrániť štartu. Na presné obnovenie štartovacieho reťazca použite rovnakú hlavnú verziu jadra ako v zálohe."
},
"codeReference": {
"heading": "Kde mechanizmy žijú",
"intro": "Pre vývojárov, ktorí chcú sledovať alebo rozšíriť správanie obnovy medzi verziami jadra:",
"rows": [
{
"component": "Smerové zistenie",
"location": "<code>hb_compat_check</code> v <code>lib_host_backup_common.sh</code>. Nastaví <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Zoznam ciest bezpečného filtra",
"location": "<code>hb_unsafe_paths_cross_version</code> v <code>lib_host_backup_common.sh</code>. Vypíše <code>path\\treason</code> riadky používané ako CLI filter a webový koncový ukazovateľ <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Hydratačné fázy",
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> v <code>backup_host.sh</code>. Orchestrovaný <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Vynútenie obnovy po štarte",
"location": "<code>apply_pending_restore.sh</code> prečíta <code>HB_HYDRATION_APPLIED</code> z <code>plan.env</code> a vynúti <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Webový náhľad",
"location": "<code>/api/host-backups/restore/prepare</code> v <code>flask_server.py</code>. Načíta pomocnú knižnicu, spustí <code>_rs_apply_bk_older_hydration</code> v režime plánu, vráti akcie na Web modus."
}
]
},
"whereNext": {
"heading": "Kam ísť ďalej",
"items": [
{
"label": "Obnovenie",
"href": "/docs/backup-restore/restoring",
"tail": " — úplný postup obnovy, do ktorého sa tieto mechanizmy zapájajú."
},
{
"label": "Ako to funguje",
"href": "/docs/backup-restore/how-it-works",
"tail": " — manifest a zberné funkcie vytvárajúce blok <code>kernel_params</code>, z ktorého doplnenie číta."
}
]
}
}
web/messages/sk/docs/backup-restore/destinations/borg.json
+234
View File
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Cieľ Borg — typy repozitárov, overenie SSH a šifrovanie | ProxMenux",
"description": "Cieľ Borg ukladá zálohy hostiteľa ProxMenux do lokálneho úložiska, na pripojený externý disk alebo na vzdialený server cez SSH. Opisuje vyhľadanie spustiteľného súboru borg, štyri úvodné možnosti kľúča SSH, šifrovanie repokey, uloženú konfiguráciu cieľa a uchovávanie podľa plánovanej úlohy.",
"ogTitle": "ProxMenux Backup — cieľ Borg",
"ogDescription": "Ako ProxMenux ukladá zálohy hostiteľa do úložísk Borg s overením SSH a šifrovaním repokey.",
"twitterTitle": "Cieľ záloh Borg | ProxMenux",
"twitterDescription": "Lokálne úložiská Borg, úložiská na USB a dostupné cez SSH pre zálohy hostiteľa."
},
"header": {
"title": "Borg",
"description": "Cieľ Borg píše zálohy hostiteľa do úložiska Borg. Podporujú sa tri typy úložiska: cesta k lokálnemu súborovému systému, namontovaný externý disk alebo vzdialený server cez SSH. Deduplikácia po blokoch vo všetkých archívoch v úložisku a voliteľné šifrovanie repokey.",
"section": "Záloha a obnova"
},
"aboutBorg": {
"heading": "Čo je Borg?",
"body": "Borg, známy aj ako BorgBackup, je otvorený zálohovací nástroj s deduplikáciou, ktorý udržiava komunita Borg Backup. Každý archív ukladá ako bloky premenlivej dĺžky v úložisku. Bloky sa zdieľajú medzi archívmi, takže opakovaná záloha nezmenených údajov spotrebuje takmer nulové dodatočné miesto. Borg nie je viazaný na Proxmox: je to univerzálny nástroj používaný v mnohých prostrediach. ProxMenux ho používa ako jeden z troch cieľov záloh hostiteľa. Všetky tu opísané mechanizmy (typy úložísk, borg-serve cez SSH, šifrovanie repokey a prune) sú štandardným správaním Borgu."
},
"intro": {
"title": "Deduplikácia po blokoch s lokálnymi úložiskami alebo úložiskami cez SSH",
"body": "Úložisko Borg ukladá bloky zdieľané medzi všetkými svojimi archívmi. Opakovaná záloha nezmeneného súboru preto neprenáša ani neukladá nové údaje. ProxMenux používa pri zálohovaní <code>borg create</code> a pri obnove <code>borg extract</code>. Úložisko môže byť na rovnakom súborovom systéme ako zdroj, na pripojenom externom disku alebo na vzdialenom hostiteľovi cez SSH."
},
"binarySourcing": {
"heading": "Spustiteľný súbor borg",
"intro": "Borg nie je základnou závislosťou inštalátora ProxMenux. Keď beží záloha, <code>hb_ensure_borg</code> vyrieši binárny zo štyroch zdrojov v poradí a vráti prvý, ktorý funguje:",
"rows": [
{
"priority": "1",
"source": "Systém <code>borg</code>",
"detail": "Ak má hostiteľ už <code>borg</code> nainštalovaný cez APT (<code>which borg</code>), použije sa tento binárny kód."
},
{
"priority": "2",
"source": "Vyrovnávacia pamäť stavového adresára",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — súbor uchovaný po predchádzajúcom stiahnutí z GitHubu na tomto hostiteľovi."
},
{
"priority": "3",
"source": "Balík AppImage Monitora",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — AppImage obsahuje podpísaný borg-linux64. Táto možnosť funguje aj bez internetu: hostiteľ má stále použiteľný <code>borg</code>."
},
{
"priority": "4",
"source": "GitHub stiahnuť",
"detail": "Stiahnutie pomocou <code>wget</code> z pevne určenej URL súboru <code>borg-linux64</code> v <code>github.com/borgbackup/borg/releases/</code>, overené oproti konštante SHA-256 v <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Pri nesúlade kontrolného súčtu sa binárny súbor odstráni a zálohovanie sa preruší. Stiahnutý súbor sa uchová v stavovom adresári, takže ďalšie zálohovania použijú postup 2."
}
]
},
"repoTypes": {
"heading": "Typy úložísk",
"intro": "Typ úložiska je vybraný pri pridaní cieľa. Každý typ rieši inú URL úložiska, ktorému Borg rozumie.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "Úložisko žije na vzdialenom serveri, ktorý prevádzkuje <code>borg serve</code>. Vyžaduje pripojenie SSH k tomu serveru."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "Repozitár žije na pripojenom externom disku (zvyčajne USB). Pripojenie je riešené pomocou <code>hb_prompt_mounted_path</code>, ktorý detekuje, pripojí alebo formáty USB partícií podľa potreby."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "Úložisko žije v lokálnom adresári. Zmysluplné iba vtedy, keď je cieľový adresár na samostatnom fyzickom disku – úložisko na rovnakom disku ako zdroj chráni pred chybou operátora, ale nie pred zlyhaním disku."
}
]
},
"serverSetup": {
"heading": "Príprava servera Borg (strana servera)",
"intro": "Typ úložiska <code>remote</code> vyžaduje funkčný server Borg dostupný cez SSH. ProxMenux server sám nenastavuje; iba autorizuje kľúč pre existujúci účet. Táto časť opisuje požiadavky pred pripojením.",
"hostChoicesTitle": "Kde môže server žiť",
"hostChoicesBody": "Každý host Linux s prístupom SSH spĺňa požiadavky. Spoločné nastavenia:",
"hostChoicesItems": [
"Dedikovaný NAS alebo záložný box (Debian, Ubuntu, TrueNAS SCALE so shellom).",
"Kontajner LXC vnútri uzol Proxmox. Malá stopa, izolovaná od hostiteľa, ktorý riadi zálohy.",
"Ďalší hostiteľ Proxmox v rovnakej sieti LAN alebo VM kdekoľvek dosiahnuteľný cez SSH."
],
"lxcWarningTitle": "LXC ako server Borg",
"lxcWarningBody": "Ak server Borg beží v LXC, generate-auto vyžaduje pri inštalácii kľúča účet povoľujúci overenie SSH heslom. Ak nie je dostupný, použite ručnú inštaláciu kľúča alebo alternatívu generate-pct cez hostiteľa PVE.",
"requirementsTitle": "Požiadavky na server",
"requirementsRows": [
{
"requirement": "Spustiteľný súbor borg na ceste <code>/usr/bin/borg</code>",
"detail": "Riadok <code>command=\"/usr/bin/borg serve ...\"</code>, ktorý ProxMenux zapíše do <code>authorized_keys</code>, používa túto pevnú cestu. APT (<code>apt install borgbackup</code>) sem program nainštaluje. Samostatný binárny súbor musí mať symbolický odkaz na ceste <code>/usr/bin/borg</code>."
},
{
"requirement": "Dedikovaný užívateľský účet (zvyčajne <code>borg</code>)",
"detail": "Vlastní adresár úložiska a prijíma prichádzajúce SSH spojenie. Nepotrebuje sudo alebo shell prístup authorized_keys linka aj tak znemožňuje interaktívne shelly."
},
{
"requirement": "Zapisovateľný adresár úložiska",
"detail": "Cesta, ktorú operátor poskytuje ProxMenux (napríklad <code>/backup/borgbackup</code>) musí existovať na serveri a musí byť vo vlastníctve používateľa borg."
},
{
"requirement": "SSH démon akceptujúci používateľa borg",
"detail": "<code>PubkeyAuthentication yes</code> (predvolené). Overenie heslom je potrebné iba pri inštalácii kľúča cez <em>generate-auto</em>. Po nainštalovaní kľúča môže server overenie heslom úplne vypnúť."
}
],
"minimalSetupTitle": "Nastavenie minimálneho servera",
"minimalSetupBody": "Na serveri Borg so systémom Debian alebo Ubuntu tvoria základ konfigurácie štyri príkazy spustené ako root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Keď je server pripravený a povoľuje overenie SSH heslom, režim <code>generate-auto</code> nainštaluje kľúč cez účet s právom zapisovať do authorized_keys používateľa borg. Ďalšie zálohy používajú tento kľúč obmedzený na <code>borg serve</code> v nastavenej ceste. Bez prihlásenia heslom ho nainštalujte ručne alebo cez hostiteľa PVE."
},
"sshAuth": {
"heading": "Overenie SSH (klientská strana)",
"intro": "Remote Borg archívy sú prístupné cez SSH. Spojenie beží od ProxMenux host na užívateľský účet na serveri Borg, ktorý beží <code>borg serve</code>. Tento užívateľ je zvyčajne pomenovaný <code>borg</code>, NIE je admin / root užívateľa servera borg-serve príkazový riadok zablokuje pripojenie k tejto konkrétnej trase úložiska (pozri nižšie kľúčové stratégie).",
"strategiesTitle": "Možnosti kľúča SSH",
"strategiesIntro": "Pri pridaní vzdialeného cieľa vyžiada ProxMenux používateľa SSH, hostiteľa a vzdialenú cestu a ponúkne štyri možnosti overenia. Ak je overenie heslom odmietnuté, ponúkne aj alternatívu generate-pct. Režimy sú opísané nižšie:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Odporúčané",
"detail": "ProxMenux vygeneruje alebo znovu použije pár kľúčov ed25519 na ceste <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>. Pomocou <code>sshpass</code> otestuje prihlásenie a nainštaluje verejný kľúč do <code>~borg/.ssh/authorized_keys</code>. Heslo patrí účtu, ktorý môže do súboru zapisovať, zvyčajne root alebo borg. Používa sa pri nastavení a neukladá sa."
},
{
"mode": "generate-manual",
"label": "Žiadne admin heslo na tomto hostiteľovi",
"detail": "ProxMenux generuje pár kľúčov, ako je uvedené vyššie, ale zobrazuje plnú linku <code>authorized_keys</code> pre operátora na manuálne vkladanie do servera. Admin heslo nikdy neopustí ProxMenux hostiteľa, pretože to nie je nikdy žiadané."
},
{
"mode": "generate-pct",
"label": "Borg server je PVE LXC",
"detail": "Server Borg beží vo vnútri LXC na uzle PVE. ProxMenux povoľuje kľúč cez <code>pct exec</code> z PVE hostiteľa a root na hostiteľovi PVE píše do LXC's <code>~borg/.ssh/authorized_keys</code> bez potreby SSH do LXC sama o sebe."
},
{
"mode": "existing",
"label": "Použiť existujúci kľúč",
"detail": "ProxMenux skenuje <code>/root/.ssh/</code> a <code>$HOME/.ssh/</code> na analyzovateľné súkromné ​​kľúče ed25519/RSA a uvádza ich. Operátor vyberie jednu alebo manuálne prejde na neštandardnú cestu."
},
{
"mode": "none",
"label": "Štandardná konfigurácia SSH",
"detail": "Bez vlastného kľúča: Borg používa predvolenú konfiguráciu SSH hostiteľa, zvyčajne <code>~/.ssh/id_rsa</code> alebo agenta SSH."
}
],
"restrictTitle": "Čiara authorized_keys",
"restrictBody": "Pre každý vygenerovaný kľúč obmedzí riadok <code>authorized_keys</code> zapísaný na serveri použitie kľúča na toto volanie borg-serve pre nastavenú cestu úložiska:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "<code>command=</code> núti každé SSH sedenie pomocou tohto kľúča spustiť len to borg-serve príkaz; <code>restrict</code> vypne port forwarding, agent forwarding, X11 forwarding a PTY alokácie. Kľúč nemožno použiť na otvorenie interaktívneho shellu na serveri alebo na prístup k akejkoľvek inej ceste úložiska, aj keď má účet širšie práva."
},
"savedTargets": {
"heading": "Uložené ciele",
"intro": "Uložený cieľ uchová konfiguráciu úložiska pod zrozumiteľným názvom, aby údaje nebolo potrebné zadávať znova. Súbory v stavovom adresári ProxMenux:",
"rows": [
{
"file": "borg-targets.txt",
"content": "Jeden riadok pre každý cieľ: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Funkcia <code>hb_collect_borg_configs</code> ho načíta pri zostavovaní ponuky cieľov."
},
{
"file": "borg-pass-NAME.txt",
"content": "Passfráza pre cieľ uvedený vyššie (<code>chmod 600</code>). Prítomný len vtedy, keď si operátor vybral kódovanie repokey."
}
],
"outro": "Uloženie cieľa je voliteľné. Odmietnutím sa neuloží pomenovaná konfigurácia, ale vygenerovaný kľúč SSH sa neodstráni. Ak je šifrovanie repokey zapnuté bez uloženého cieľa, ProxMenux aj tak uloží prístupovú frázu do staršieho súboru borg-pass.txt."
},
"encryption": {
"heading": "Šifrovanie",
"body": "Repozitáre sa inicializujú so zvoleným režimom šifrovania cez <code>hb_borg_init_if_needed</code>: ak je dostupný novší príkaz <code>borg repo-create -e MODE</code>, použije sa ten, inak starší <code>borg init --encryption=MODE</code>. ProxMenux ponúka dva režimy: <code>repokey</code> (predvolený) a <code>none</code>. V režime <code>repokey</code> Borg ukladá šifrovací kľúč priamo do repozitára. Prístup vyžaduje heslovú frázu, ktorú ProxMenux žiada zadať dvakrát, overí zhodu a pri uloženom cieli ju uloží do <code>borg-pass-NAME.txt</code>, inak do staršieho súboru opísaného vyššie. Po uložení sa zobrazí povinné potvrdenie: heslová fráza je jedinou cestou k zašifrovaným archívom a jej strata znemožní obnovu všetkých archívov v repozitári."
},
"runtimeEnv": {
"heading": "Runtime prostredie",
"intro": "ProxMenux exportuje nasledujúce premenné prostredia pred vyvolaním <code>borg</code>. Konfigurujú pripojenie a odomykajú úložisko bez vloženia tajomstiev do príkazového riadku.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Príkaz vzdialeného shellu pre úložiská Borg cez SSH. Vybraný kľúč pridá voľby identity; neštandardný port pridá -p PORT. Bez vlastného kľúča a s predvoleným portom zostane premenná nenastavená a Borg používa konfiguráciu SSH hostiteľa."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passfráza z borg-pass-NAME.txt)",
"purpose": "Odomkne repokey. Nastaviť iba vtedy, keď cieľ používa šifrovanie <code>repokey</code>. Nikdy sa neobjaví v zozname procesných argumentov."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Použité <code>hb_borg_init_if_needed</code> pri inicializácii úložiska, ktoré ešte neexistuje. Ignorované <code>borg create</code> na existujúcich archívoch."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Potlačí interaktívnu otázku Borgu, keď sa URL úložiska líši od pôvodnej adresy, napríklad po premenovaní bodu pripojenia alebo zmene adresy hostiteľa SSH."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Potlačí interaktívnu výzvu, ktorú Borg vyvolá pri prvom prístupe k nezašifrovanému úložisku z nového klienta."
}
]
},
"archiveFormat": {
"heading": "Archive pomenovanie a uchovávanie",
"intro": "Každá záloha vytvorí nový archív vo vnútri úložiska.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "Pre plánované úlohy, <code>run_scheduled_backup.sh</code> beží <code>borg prune</code> proti úložisku po každom úspešnom zálohovaní s retenčnými hodnotami nastavenými na úlohu (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Interaktívne zálohy neprerezávajú."
},
"restoreAccess": {
"heading": "Získavanie na strane obnovy",
"body": "Obnova vypíše archívy pomocou <code>borg list REPO</code> a vybraný archív rozbalí príkazom <code>borg extract REPO::ARCHIVE-NAME</code> do prípravného adresára. Funkcia <code>_rs_check_layout</code> ho odovzdá štandardnému procesu obnovy. Rovnaké príkazy fungujú aj ručne mimo ProxMenux. Rozbalený strom má trojblokovú štruktúru opísanú v časti <em>Ako to funguje</em>."
},
"references": {
"heading": "Odkazy",
"intro": "Oficiálna dokumentácia Borg ku komponentom, ktoré ProxMenux používa.",
"items": [
{
"label": "Dokumentácia Borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": " — hlavný rozcestník pre pojmy, nasadenie, rýchly začiatok a všetky príkazy."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " — príkaz, ktorý ProxMenux používa pri každej zálohe, so všetkými podporovanými voľbami."
},
{
"label": "Šifrovanie úložiska",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": " — režimy šifrovania podporované Borgom vrátane repokey, ktorý ProxMenux používa predvolene."
},
{
"label": "borg serve a nasadenie cez SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — nastavenie centrálneho servera Borg dostupného cez SSH vrátane príkazu borg-serve a voľby restrict-to-path, ktoré ProxMenux zapisuje do authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — model uchovávania pre --keep-last / --keep-daily / --keep-weekly, ktorý ProxMenux uplatňuje pri každej plánovanej úlohe."
}
]
}
}
web/messages/sk/docs/backup-restore/destinations/index.json
+110
View File
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Ciele záloh — lokálny archív, Proxmox Backup Server a Borg | ProxMenux",
"description": "Tri úložné backendy prijímajú rovnaký obsah zálohy ProxMenux: lokálny archív .tar.zst na ľubovoľnom zapisovateľnom súborovom systéme, zálohu PBS v dátovom úložisku Proxmox Backup Server alebo archív Borg v lokálnom či vzdialenom repozitári Borg. Každý backend má vlastné vlastnosti kompresie, deduplikácie, šifrovania a sieťovej komunikácie.",
"ogTitle": "Ciele záloh ProxMenux",
"ogDescription": "Lokálny archív, Proxmox Backup Server a Borg — tri úložné backendy pre rovnaký obsah zálohy hostiteľa.",
"twitterTitle": "Ciele záloh ProxMenux | ProxMenux",
"twitterDescription": "Miestny archív, Proxmox Backup Server a Borg backendy pre zálohovanie hostiteľov."
},
"header": {
"title": "Ciele",
"description": "Tri úložné backendy podporované funkciou ProxMenux Backup: lokálny archív, Proxmox Backup Server (odporúčaný) a Borg. Každý prijíma rovnaký archív s tromi blokmi údajov; líšia sa formátom úložiska, deduplikáciou, modelom šifrovania a sieťovými požiadavkami.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Rovnaký obsah, tri backendy",
"body": "Každá záloha vytvorí rovnaké tri bloky údajov (rootfs, manifest, aplikácie). Jednotlivé ciele sa líšia spôsobom uloženia týchto údajov a ich získania na obnovu. Každý backend je samostatná funkcia v <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — všetky tri však zdieľajú rovnaký krok dočasnej prípravy (<code>hb_prepare_staging</code>) a rovnakú vetvu kódu obnovy. Voľba cieľa ovplyvňuje iba zápis a získanie údajov; nemení priebeh obnovy ani spôsob použitia archívu."
},
"comparison": {
"heading": "Porovnanie funkcií",
"intro": "Nasledujúca tabuľka uvádza konkrétne rozdiely medzi tromi backendmi, ako sa správajú v ProxMenux dnes. Všetky hodnoty opisujú pozorované správanie samotného backendu, nie redakčné odporúčania.",
"rows": [
{
"feature": "Formát úložiska",
"local": "Jeden súbor <code>.tar.zst</code> (alebo <code>.tar.gz</code>, ak <code>zstd</code> chýba).",
"pbs": "Záloha PBS (bloky <code>.pxar</code> v dátovom úložisku).",
"borg": "Borg archív vnútri úložiska Borg (segment súbory)."
},
{
"feature": "Kompresia",
"local": "zstd (štandardná úroveň) cez <code>tar --zstd</code>. gzip fallback.",
"pbs": "Spravuje ju proxmox-backup-client. ProxMenux nemení nastavenia kompresie.",
"borg": "Vstavaná kompresia Borg. ProxMenux volá borg create bez zmeny nastavení kompresie."
},
{
"feature": "Deduplikácia",
"local": "Žiadne. Každá záloha je úplne nezávislý archív.",
"pbs": "Úplná deduplikácia na úrovni blokov medzi všetkými zálohami v dátovom úložisku.",
"borg": "Úplná deduplikácia na úrovni blokov medzi všetkými archívmi v repozitári."
},
{
"feature": "Šifrovanie v pokoji",
"local": "Žiadne (podliehajú ochrane súborového systému).",
"pbs": "Voliteľné šifrovanie na strane klienta pomocou súboru kľúča. Po zapnutí sa objekt obnovy odošle ako samostatná skupina záloh.",
"borg": "Voliteľné šifrovanie repokey (kľúč uložený v repo, odomknutý heslom)."
},
{
"feature": "Uchovávanie / čistenie",
"local": "Použije sa pre každú plánovanú úlohu cez <code>KEEP_LAST</code>. Staré archívy sa odstránia spolu so sprievodnými súbormi a záznamami spúšťacieho skriptu. Interaktívne zálohy nevykonávajú čistenie.",
"pbs": "Použité pre každú plánovanú úlohu cez <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktívne zálohy nevykonávajú čistenie.",
"borg": "Použité pre každú plánovanú úlohu cez <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktívne zálohy nevykonávajú čistenie."
},
{
"feature": "Sieť",
"local": "Žiadne. Píše do lokálneho bodu pripojenia (obvykle interný disk alebo USB disk).",
"pbs": "TCP na server PBS (predvolený port 8007). Požaduje prihlasovacie údaje PBS + odtlačok certifikátu.",
"borg": "Lokálna cesta súborového systému alebo tunel SSH k vzdialenému Borg hostiteľovi."
},
{
"feature": "Závislosti",
"local": "<code>tar</code>, <code>zstd</code> (predvolene prítomné na Proxmoxe).",
"pbs": "Balík <code>proxmox-backup-client</code> (dodávaný s Proxmox VE 8+).",
"borg": "Binárny <code>borg</code>. Automatické poskytovanie ProxMenux z balíka Monitor AppImage v prípade, že chýba."
},
{
"feature": "Prístup potrebný na obnovu",
"local": "Akýkoľvek hostiteľ s tar+zstd môže extrahovať archív. Nie je potrebné PBS/Borg.",
"pbs": "Vyžaduje <code>proxmox-backup-client</code>, prihlasovacie údaje PBS a súbor kľúča (pri šifrovanej zálohe).",
"borg": "Vyžaduje <code>borg</code> + cestu k úložisku + heslo (ak je zašifrované)."
}
],
"captionCode": "feature",
"captionLocal": "Lokálne",
"captionPbs": "Proxmox Backup Server (odporúčané)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "Rozloženie archívu sa nemení s destináciou",
"body": "V každom z troch cieľov sa nachádza rovnaká štruktúra <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> opísaná v časti <em>Ako to funguje</em>. Rozbalenie lokálneho archívu <code>.tar.zst</code>, obnova <code>.pxar</code> z PBS aj rozbalenie archívu Borg cez <code>borg extract</code> vytvoria rovnaký adresárový strom. Vetva kódu obnovy (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) číta rovnaké tri bloky údajov bez potreby vedieť, z ktorého cieľa pochádzajú."
},
"extractStandalone": {
"heading": "Rozbalenie zálohy mimo ProxMenux",
"intro": "Akýkoľvek z troch formátov archívu je možné čítať pomocou štandardných nástrojov bez nainštalovaného ProxMenux na počítači. Nižšie uvedené príkazy vytvárajú rovnaký adresárový strom, ktorý obnova používa interne.",
"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": "# Z archívu Borg (vyžaduje borg a heslo pre šifrované repozitáre):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Zo vzdialeného repozitára dostupného cez SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "Rozbalený strom možno ručne skontrolovať alebo použiť na manuálnu obnovu. Presný postup získania údajov, ktorý ProxMenux používa na pozadí, opisujú stránky jednotlivých cieľov."
},
"whereNext": {
"heading": "Podrobnosti jednotlivých cieľov",
"intro": "Každá destinácia má svoju vlastnú stránku pokrývajúcu konfiguračný tok, formát on-disku a príkaz na získanie údajov použitý pri obnove.",
"items": [
{
"label": "Lokálny archív",
"href": "/docs/backup-restore/destinations/local",
"tail": " — prednastavenie lokálneho cieľa, pripojenie USB disku, ochrana pred uložením archívu do jeho vlastného zdroja a sprievodný súbor JSON, pomocou ktorého Monitor rozpozná zálohu."
},
{
"label": "Proxmox Backup Server (odporúčané)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — výber dátového úložiska, prihlasovacie údaje a odtlačok certifikátu, životný cyklus súboru šifrovacieho kľúča, prístupová fráza na obnovu a odoslanie objektu obnovy do PBS na obnovu po čistej inštalácii."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — lokálne repozitáre a repozitáre dostupné cez SSH, zdroje binárneho súboru Borg (systém / vyrovnávacia pamäť / balík AppImage nástroja Monitor / stiahnutie z GitHubu), inicializácia repozitára, správa prístupových fráz a nastavenie kľúča SSH pre vzdialené repozitáre."
}
]
}
}
web/messages/sk/docs/backup-restore/destinations/local.json
+75
View File
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Lokálny archív — tar.zst na súborovom systéme alebo USB disku | ProxMenux",
"description": "Lokálny cieľ zálohy vytvorí jediný archív .tar.zst v ľubovoľnom zapisovateľnom adresári: na internom disku, v bode pripojenia Proxmoxu, na zdieľaní NFS alebo na USB disku. Stránka opisuje nastavenie, rozpoznanie a pripojenie USB diskov, ochranu pred uložením archívu do zálohovanej cesty a sprievodný súbor JSON, ktorý zálohu identifikuje.",
"ogTitle": "ProxMenux Backup — lokálny cieľ archívu",
"ogDescription": "Ako ProxMenux píše lokálne zálohy ako .tar.zst archívy a ako nastaviť cieľový adresár alebo USB disk.",
"twitterTitle": "Lokálny cieľ zálohy | ProxMenux",
"twitterDescription": "Ako ProxMenux píše lokálne zálohy ako .tar.zst archívy na súborovom systéme alebo USB disku."
},
"header": {
"title": "Lokálny archív",
"description": "Lokálny cieľ zapisuje jeden komprimovaný archív tar do ľubovoľného zapisovateľného adresára na hostiteľovi: na interný disk, pripojenie NFS alebo SMB či USB disk.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Jeden súbor, samostatný",
"body": "Lokálna záloha vytvorí jediný súbor <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (alebo <code>.tar.gz</code>, ak <code>zstd</code> nie je dostupné). Súbor obsahuje celý strom archívu — <code>manifest.json</code>, <code>metadata/</code> a <code>rootfs/</code> — a možno ho obnoviť na ľubovoľnom hostiteľovi Proxmox postupom obnovy ProxMenux alebo ručne rozbaliť cez <code>tar --zstd -xf</code> na ľubovoľnom systéme Linux. Netreba server, inicializáciu repozitára ani externú závislosť. Ak nie sú dostupné PBS ani Borg, tento cieľ ponúka najkratšiu cestu obnovy."
},
"targetConfig": {
"heading": "Nastavenie cieľového adresára",
"intro": "Miestny cieľ je <strong>jeden trvalý cieľový adresár</strong> — nie zoznam. ProxMenux ukladá voľbu operátora na <code>/usr/local/share/proxmenux/local-target.conf</code> a číta ju pri každej zálohe. Ak nie je nakonfigurovaný žiadny cieľ, použije sa predvolený <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> (rovnaký adresár, ktorý Proxmox používa pre svoje vlastné výstupy <code>vzdump</code>). Cieľ sa konfiguruje z <em>Konfigurovať ciele zálohovania → Lokálne ciele</em>:",
"options": [
"<strong>Použiť predvolené (<code>/var/lib/vz/dump</code>).</strong> Lokálne úložisko Proxmox. Prítomný pri každej inštalácii Proxmox; archív sa nachádza vedľa výstupov vzdump a automaticky ho preberá karta Zálohy monitora.",
"<strong>Zadajte vlastnú cestu.</strong> Môžete použiť akúkoľvek absolútnu cestu súborového systému: pripojenie NFS, zdieľanie SMB pripojené cez <code>fstab</code>, vyhradený súbor údajov ZFS, druhý interný disk. ProxMenux overí, že cesta existuje a je adresárom, pred jej uložením.",
"<strong>Vyberte jednotku USB.</strong> Otvorí podponuku USB (nižšie), ktorá detekuje vymeniteľné zariadenia a ponúka pripojenie alebo formátovanie."
]
},
"usbFlow": {
"heading": "Rozpoznanie a pripojenie USB disku",
"intro": "Podponuka USB uvádza oddiely na vymeniteľných zariadeniach hlásených nástrojom <code>lsblk</code>. Každý oddiel sa zobrazí s veľkosťou, menovkou súborového systému a aktuálnym stavom. Stav určuje ponúkanú akciu ProxMenux.",
"statesTitle": "Tri stavy zariadenia",
"stateRows": [
{
"state": "pripojené",
"shown": "Veľkosť · štítok · [fstype] · → /mount/point",
"action": "Oddiel je už pripojený. Jeho výber uloží aktuálny bod pripojenia ako lokálny cieľ zálohy. Žiadne nové pripojenie sa nevykoná."
},
{
"state": "odmontované",
"shown": "Veľkosť · menovka · [fstype] · (nepripojený — bude pripojený)",
"action": "Súborový systém je prítomný, ale nie je namontovaný. Po potvrdení, ProxMenux spustí <code>hb_mount_usb_partition</code>: vytvorí <code>/mnt/backup-LABEL</code> (alebo cestu založenú na UUID, ak nie je označenie), pripojí partíciu a uloží bod pripojenia ako miestny cieľ."
},
{
"state": "prázdny",
"shown": "Veľkosť · surový USB disk — bez súborového systému (bude NAFORMÁTOVANÝ)",
"action": "Zariadenie nemá súborový systém. Tento deštruktívny postup chráni dvojité potvrdenie. Najprv dialóg Áno/Nie upozorní, že operácia vymaže disk. Potom musí používateľ do vstupného poľa <strong>zadať presnú cestu zariadenia</strong> (napr. <code>/dev/sdb</code>), až následne ProxMenux vytvorí novú tabuľku GPT s oddielom ext4 a pripojí ho."
}
],
"notMountedFallback": "Ak nie je detekované žiadne USB zariadenie, podmenu spadne späť do jednoduchého vstupného poľa. Operátor môže zadať ľubovoľnú cestu k bodu pripojenia; ak cesta nie je registrovaným bodom pripojenia, dialóg s potvrdením varuje pred pokračovaním."
},
"safetyCheck": {
"heading": "Bezpečnostná kontrola - cieľ vnútri záložnej cesty",
"body": "Pred zapísaním archívu <code>_bk_local</code> overí, že cieľový adresár <strong>nie je</strong> podcestou žiadneho zálohovaného adresára. Bežnou chybou by bolo pridanie <code>/root</code> do profilu a výber <code>/root/backups</code> ako cieľ — archív by potom zahrnul sám seba, buď by vytvoril poškodený archív, alebo by rástol bez obmedzenia, kým sa disk nezaplní. Kontrola vyrieši obe cesty pomocou <code>readlink -m</code>, porovná ich a v prípade konfliktu preruší zálohovanie pomocou dialógového okna, ktoré pomenuje konfliktnú cestu a uvedie tri spôsoby, ako to vyriešiť: vybrať cieľ mimo konfliktnej cesty, odstrániť vlastnú položku, ktorá obsahuje cieľ, alebo použiť vlastný režim na zrušenie začiarknutia konfliktnej cesty pre toto spustenie."
},
"archiveFormat": {
"heading": "Formát archívu a kompresia",
"intro": "Výstupné meno súboru vloží zdrojové meno hostiteľa a záložnú časovú pečiatku tak, že adresár, v ktorom je niekoľko archívov, sa chronologicky triedi a každý súbor je sebaidentifikačný.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Kompresia",
"compressionBody": "Hlavný postup používa <code>tar --zstd -cf</code> — jediný príkaz komprimujúci na predvolenej úrovni zstd. Ak <code>zstd</code> v zdroji nie je dostupné (na Proxmoxe zriedkavé, ale možné pri minimálnych inštaláciách), ProxMenux použije <code>gzip</code>. V tomto náhradnom postupe sa pri dostupnom <code>pv</code> pridá ukazovateľ priebehu, takže používateľ vidí rast veľkosti archívu v reálnom čase; bez <code>pv</code> sa použije obyčajné <code>tar -czf</code> bez priebežného výpisu.",
"sourceTitle": "Čo ide do archívu",
"sourceBody": "Príkaz tar sa spustí s <code>-C \"$staging_root\" .</code>, čím archivuje <strong>celý koreň dočasného prípravného adresára</strong>: <code>rootfs/</code>, <code>metadata/</code> a <code>manifest.json</code>. Všetky tri bloky údajov ležia vedľa seba na najvyššej úrovni archívu tar. Rozbalením vznikne presne ten strom, ktorý používa kód obnovy."
},
"sidecar": {
"heading": "Sprievodný súbor JSON",
"intro": "Každá úspešná lokálna záloha produkuje sesterský súbor: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, zapísaný vedľa archívu funkciou <code>hb_write_archive_sidecar</code>. Tento malý súbor JSON umožňuje ProxMenux Monitor identifikovať archív ako zálohu ProxMenux hostiteľa, aj keď je neskôr presunutý, premenovaný alebo archivovaný inde.",
"contentTitle": "Obsah sprievodného súboru",
"contentBody": "Sprievodný súbor obsahuje verziu schémy, údaj o tom, či záloha vznikla interaktívne alebo plánovanou úlohou (<code>kind</code>), ID úlohy pri plánovaných spusteniach, použitý režim profilu (<code>default</code> alebo <code>custom</code>), názov zdrojového hostiteľa, pôvodný názov súboru archívu, časovú pečiatku vytvorenia ISO-8601 a veľkosť archívu v bajtoch.",
"whyBody": "Karta Backups v Monitore prehľadáva nakonfigurované lokálne adresáre a hľadá sprievodné súbory <code>*.proxmenux.json</code>, nie súbory <code>*.tar.zst</code>, pretože <code>.tar.zst</code> bez sprievodného súboru nemusí byť zálohou ProxMenux. Hľadanie je rýchle (súbory JSON sú malé) a párovanie zostane platné aj po premenovaní archívu, ak sa zodpovedajúco premenuje aj sprievodný súbor."
},
"restoreAccess": {
"heading": "Obnova z miestneho archívu",
"body": "Postup obnovy ProxMenux nájde lokálne archívy vyhľadaním sprievodných súborov v nastavenom lokálnom cieli a zobrazí ich v zozname archívov. Výber archívu spustí <code>_rs_check_layout</code>, ktorý rozbalí archív tar do dočasného prípravného adresára a pred pokračovaním overí štruktúru troch blokov údajov. Pri ručnom rozbalení mimo ProxMenux príkaz <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> vytvorí rovnaký strom, ktorý používa kód obnovy."
}
}
web/messages/sk/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -0,0 +1,113 @@
{
"meta": {
"title": "Cieľ Proxmox Backup Server — repozitár, šifrovanie a obnova | ProxMenux",
"description": "Cieľ PBS ukladá zálohy hostiteľa ProxMenux ako zálohy PBS. Stránka opisuje zisťovanie úložísk z /etc/pve/storage.cfg, ručnú konfiguráciu PBS, odoslanie .pxar, šifrovanie na strane klienta so súborom kľúča a voliteľnou obnovovacou kópiou chránenou prístupovou frázou aj obnovu kľúča z viacerých zdrojov na novo nainštalovanom hostiteľovi.",
"ogTitle": "Zálohovanie ProxMenux — cieľ Proxmox Backup Server",
"ogDescription": "Ako ProxMenux ukladá zálohy hostiteľa na Proxmox Backup Server so šifrovaním súborom kľúča na strane klienta a uloženou kópiou na obnovu.",
"twitterTitle": "PBS Záložné miesto ProxMenux",
"twitterDescription": "Cieľ Proxmox Backup Server so šifrovaním súborom kľúča a obnovovacou kópiou chránenou prístupovou frázou."
},
"header": {
"title": "Proxmox Backup Server",
"description": "Cieľ PBS odosiela celý prípravný adresár ako jednu zálohu .pxar do dátového úložiska Proxmox Backup Server. Voliteľne ju šifruje na strane klienta súborom kľúča a vedľa každej zálohy môže uložiť aj obnovovaciu kópiu kľúča chránenú prístupovou frázou.",
"section": "Záloha a obnova"
},
"recommendedBadge": "Odporúčané miesto určenia",
"aboutPbs": {
"heading": "Čo je Proxmox Backup Server",
"body": "Proxmox Backup Server (PBS) je zálohovací server spoločnosti Proxmox, ktorý vyvíja a udržiava rovnaký tím ako Proxmox VE. Prijíma zálohy z hostiteľov Proxmox VE (VM, kontajnerov LXC a cez <code>proxmox-backup-client</code> aj ľubovoľných adresárov hostiteľa), podporuje deduplikáciu po blokoch, šifrovanie na strane klienta a pravidlá uchovávania na serveri. ProxMenux používa PBS ako jeden z troch cieľov záloh hostiteľa. Všetky tu opísané mechanizmy PBS (skupiny záloh, archívy <code>.pxar</code>, <code>--backup-id</code> a šifrovanie súborom kľúča) patria k štandardnému správaniu PBS."
},
"intro": {
"title": "Jedna záloha pri každom spustení, deduplikácia po blokoch",
"body": "Záloha PBS vytvorí v dátovom úložisku jednu položku pod identifikátorom <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Obsah tvorí archív <code>.pxar</code> s rovnakou trojblokovou štruktúrou ako v časti <em>Ako to funguje</em>. PBS deduplikuje bloky medzi všetkými zálohami v úložisku, takže ďalšie zálohy toho istého hostiteľa prenášajú a ukladajú iba zmenené bloky. Uchovávanie pri plánovaných úlohách riadi samotný ProxMenux: po každom úspešnom spustení vykoná <code>run_scheduled_backup.sh</code> príkaz <code>proxmox-backup-client prune</code> s voľbami <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> podľa hodnôt nastavených v úlohe."
},
"repoSelection": {
"heading": "Výber úložiska",
"intro": "ProxMenux objavuje archív PBS z dvoch zdrojov na každej zálohe. Operátor vyberie jeden z jednotného menu; voľba určuje <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> a <code>HB_PBS_FINGERPRINT</code> pre spustenie.",
"sourceRows": [
{
"source": "Proxmox storage.cfg (automaticky zistené)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Každá sekcia <code>pbs:</code> v konfigurácii úložísk Proxmoxu sa zistí automaticky. Server, dátové úložisko, používateľské meno a odtlačok certifikátu sa prevezmú z tejto sekcie. Heslo sa načíta z adresára prihlasovacích údajov Proxmoxu. V ProxMenux ho netreba zadávať znova: úložisko je dostupné hneď po konfigurácii v Proxmoxe."
},
{
"source": "ProxMenux manuálna konfigurácia",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Pridáva sa cez <em>Nastaviť ciele záloh → Ciele PBS → Pridať PBS</em>. Zadáva sa názov, používateľské meno (<code>root@pam</code> alebo <code>user@pbs!token</code>), hostiteľ alebo IP adresa, dátové úložisko a heslo. Pri prázdnom hesle sa výzva zopakuje: inak by sa prázdna hodnota potichu uložila a každá ďalšia záloha by zlyhala s nejasnou chybou overenia. Táto možnosť slúži pre PBS, ktorý nie je zaregistrovaný ako úložisko Proxmoxu."
}
],
"menuTitle": "Výberové menu",
"menuBody": "Oba zdroje sú v jednej ponuke a každý riadok označuje pôvod (<code>[proxmox]</code> alebo <code>[manual]</code>). Položky bez zisteného hesla majú upozornenie <code>⚠ no password</code>; pri ich výbere treba heslo zadať pred spustením zálohy. Odtlačok sa odovzdáva nástroju <code>proxmox-backup-client</code> cez premennú prostredia <code>PBS_FINGERPRINT</code>. Ak odtlačok chýba, klient pri prvej zálohe interaktívne požiada operátora o prijatie certifikátu servera."
},
"backupCommand": {
"heading": "Záložný príkaz",
"intro": "Odoslanie používa jediné volanie <code>proxmox-backup-client backup</code>. ProxMenux pomocou <code>env</code> odovzdáva klientovi heslo, šifrovacie heslo a odtlačok ako premenné prostredia.",
"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": "Identifikačné meno zálohy",
"backupIdBody": "Predvolený identifikátor zálohy je <code>hostcfg-HOSTNAME</code>. Pred odoslaním ho operátor potvrdí alebo upraví. Znaky mimo <code>[A-Za-z0-9_-]</code> aj pomlčky na konci sa odstránia. Opakované použitie rovnakého ID je zámerné: PBS ho chápe ako <em>skupinu</em> a každá ďalšia záloha pribudne do tejto skupiny ako nová položka so spoločnou deduplikáciou s predchádzajúcimi zálohami.",
"pxarTitle": "Prečo je zdrojom celý prípravný adresár",
"pxarBody": "Zdrojom archívu <code>.pxar</code> je celý <code>staging_root</code>: spolu <code>rootfs/</code>, <code>metadata/</code> aj <code>manifest.json</code>. Staršie verzie používali ako zdroj <code>$staging_root/rootfs</code>, takže v archíve chýbal adresár <code>metadata/</code>. Kontrola kompatibility pri obnove nemala čo čítať a zobrazovala upozornenia na iného hostiteľa aj pri obnove na pôvodnom hostiteľovi. Staré zálohy obsahujúce iba rootfs sa stále obnovujú správne pomocou tretej vetvy <code>_rs_check_layout</code>, ktorá plochý strom <code>etc/var/root/usr</code> zabalí do hierarchie <code>rootfs/</code>."
},
"encryption": {
"heading": "Šifrovanie na strane klienta",
"glossaryHint": "Táto časť používa pojmy <em>súbor kľúča</em>, <em>prístupová fráza</em> a <em>obnovovacia obálka</em>. <glosarioLink>Slovník pojmov</glosarioLink> vysvetľuje ich rozdiely jednou vetou pre každý pojem.",
"intro": "Šifrovanie PBS na strane klienta šifruje bloky súborom kľúča na zdrojovom hostiteľovi ešte pred odoslaním. V ProxMenux je voliteľné. Ak sa zapne, operátor pri nastavení výslovne zvolí áno alebo nie, či sa má na PBS uložiť aj obnovovacia kópia súboru kľúča chránená prístupovou frázou. Voľbu môže neskôr zmeniť v Monitore. Súbor kľúča je vždy na kanonickej ceste <code>/usr/local/share/proxmenux/pbs-key.conf</code> a pri každej ďalšej šifrovanej zálohe sa použije bez ďalších otázok.",
"keyfileTitle": "Nastavenie súboru kľúčov",
"keyfileBody": "Dialóg šifrovania sa zobrazí pri prvej šifrovanej zálohe hostiteľa. Najprv sa opýta, či sa má záloha šifrovať: <em>Nie</em> pokračuje bez šifrovania, <em>Áno</em> prejde na druhý krok. Ten závisí od toho, či je na ceste <code>/usr/local/share/proxmenux/pbs-key.conf</code> už nainštalovaný súbor kľúča. Ak áno, použije sa bez otázok a zálohovanie pokračuje; ani pri ďalších zálohách sa otázka neopakuje. Ak nie, ponuka poskytne dve možnosti. <em>Vygenerovať nový súbor kľúča</em> spustí <code>proxmox-backup-client key create --kdf none</code>. <em>Použiť existujúci súbor kľúča</em> automaticky zistí kľúč spravovaný PVE: ak je vybrané úložisko PBS v Proxmoxe zaregistrované so šifrovacím kľúčom na ceste <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, súbor sa bez otázok skopíruje na kanonickú cestu ProxMenux. Ak sa nenájde zodpovedajúci kľúč PVE, dialóg vyžiada absolútnu cestu, kam operátor už súbor kľúča na hostiteľovi umiestnil. V oboch prípadoch sa uloží na kanonickú cestu s <code>chmod 600</code>.",
"modesTitle": "Súbor kľúča pre každý hostiteľ alebo spoločný súbor",
"modesIntro": "Oba modely sú podporované a ani jeden nie je povinný. Operátor si vyberie podľa organizácie svojich hostiteľov.",
"modesPerHostTitle": "Vlastný súbor kľúča pre každý hostiteľ (predvolené)",
"modesPerHostBody": "Každý hostiteľ generuje svoj vlastný súbor kľúčov prvýkrát, čo umožňuje šifrovanie PBS. Izolácia je maximálna: ohrozenie súboru kľúčov jedného hostiteľa nevystavuje zálohy žiadneho iného hostiteľa. Odporúčané pre produkčné prostredia a pre prostredia, v ktorých majú hostitelia rôznych vlastníkov alebo hranice súladu.",
"modesSharedTitle": "Zdieľaný súbor kľúča (import na každom hostiteľovi)",
"modesSharedBody": "Jeden súbor hlavného kľúča vygenerovaný raz a nainštalovaný na každom hostiteľovi pomocou možnosti <em>Použiť existujúci súbor kľúča</em>. Správa je jednoduchšia: jediné tajomstvo na ochranu a ktorýkoľvek hostiteľ môže dešifrovať archívy akéhokoľvek iného (užitočné na konsolidáciu, nácvik obnovy medzi hostiteľmi alebo centralizované overenie zálohy). Kompromisom je, že únik zdieľaného súboru kľúča odhalí každého hostiteľa naraz. Odporúča sa pre domáce laboratóriá a pre flotily, kde majú všetci hostitelia rovnakého vlastníka a hranice dôvery.",
"recoveryTitle": "Odoslanie kľúča na PBS — rozhoduje operátor",
"recoveryBody": "Hneď po výbere súboru kľúča položí ProxMenux výslovnú otázku <em>Odoslať kľúč na PBS?</em> s dvoma odpoveďami. <strong>Kým operátor nezvolí Áno, na PBS sa neodošle žiadny obnovovací artefakt.</strong> Predvolená voľba je <em>Nie, ponechať iba lokálne</em>: kľúč zostane na kanonickej miestnej ceste, ProxMenux neodosiela na PBS žiadne obnovovacie artefakty a externú kópiu zabezpečí operátor. Tlačidlo <em>Stiahnuť súbor kľúča</em> v riadku cieľa PBS v Monitore ju poskytne na požiadanie. Voľba <em>Áno, odoslať</em> vyžiada dvakrát prístupovú frázu na obnovu a overí zhodu. ProxMenux ňou zašifruje súbor kľúča pomocou AES-256-CBC a PBKDF2 (600 000 iterácií, náhodná soľ) a vytvorí <code>pbs-key.recovery.enc</code>. Každá ďalšia šifrovaná záloha odošle túto obálku na PBS ako priradenú skupinu záloh. Pri týchto odoslaniach sa na PBS neposiela prístupová fráza ani súbor kľúča v otvorenom tvare. Voľbu možno kedykoľvek zmeniť v Monitore: ovládací prvok v riadku PBS prepína Áno/Nie a okamžite použije Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu podľa aktuálneho stavu.",
"blobUploadTitle": "Párovaná záložná skupina na PBS",
"blobUploadBody1": "Keď je režim úschovy <em>Áno, nahrať</em>, ProxMenux odošle obálku na obnovenie do PBS po každej zašifrovanej zálohe ako druhá, spárovaná skupina záloh s rovnakým názvom ako hostiteľská skupina, ale končiaca na <code>-keyrecovery</code>. Tieto dve skupiny sedia vedľa seba v zozname dátového skladu – jedna pre zálohy hostiteľa, druhá pre obálky na obnovenie. <strong>Obálka nikdy neopustí hostiteľa v obyčajnom texte</strong>: šifrovanie prebieha na samotnom hostiteľovi pomocou AES-256-CBC a PBKDF2 predtým, ako prejdú akékoľvek bajty na drôt (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS prijíma iba už zašifrovanú obálku.",
"envelopeSecurityTitle": "Predstavuje odoslanie obnovovacieho súboru na PBS bezpečnostné riziko?",
"envelopeSecurityBody": "Obnovovací súbor je šifrovaný pri prenose aj pri uložení. Prístupová fráza na obnovu neopúšťa hostiteľa: šifrovanie prebehne lokálne pred odoslaním a PBS dostane iba zašifrovaný výsledok. Správca PBS alebo ktokoľvek s prístupom k dátovému úložisku môže obnovovací súbor stiahnuť, ale bez prístupovej frázy nedokáže prečítať súbor kľúča vnútri; ide o nečitateľný šifrovaný text. Na získanie súboru kľúča treba obe časti súčasne: obnovovací súbor aj prístupovú frázu. Obe má iba operátor.",
"blobUploadConstraintTitle": "Prečo dve skupiny namiesto jedného zašifrovaného",
"blobUploadConstraintBody": "Jediné volanie <code>proxmox-backup-client backup</code> zašifruje všetky svoje archívy rovnakým súborom kľúča alebo nezašifruje žiadny; kombinácia nie je možná. Záloha hostiteľa sa musí zašifrovať jeho kľúčom, ale obnovovacia obálka sa nesmie odoslať v tom istom volaní. Bola by zašifrovaná práve kľúčom, ktorý obsahuje. Na novo nainštalovanom hostiteľovi by ju nebolo možné otvoriť: na dešifrovanie kľúča by bol potrebný ten istý kľúč. Preto sa oba artefakty odosielajú nezávisle a zobrazujú sa ako dve skupiny. Klient PBS šifruje zálohu hostiteľa súborom kľúča a ProxMenux pred odoslaním šifruje obnovovaciu obálku prístupovou frázou. Dve odlišné šifrovacie vrstvy chránia dva odlišné objekty.",
"blobUploadImageAlt": "Rozhranie PBS zobrazuje skupiny záloh hostcfg-HOSTNAME a hostcfg-HOSTNAME-keyrecovery vedľa seba v zozname dátového úložiska.",
"blobUploadImageCaption": "Rozhranie PBS — priradené skupiny záloh. Hlavná skupina obsahuje zálohy hostiteľa; skupina -keyrecovery obsahuje súbor kľúča chránený prístupovou frázou.",
"recoverTitle": "Obnovenie nového hostiteľa",
"recoverBody": "Ak miestny súbor kľúča chýba na kanonickej ceste, napríklad po preinštalovaní hostiteľa alebo úmyselnom odstránení, obnova vyskúša tri zdroje v poradí a skončí pri prvom použiteľnom kľúči. Najprv sa bez otázok skopíruje zodpovedajúci kľúč spravovaný PVE z <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code> na kanonickú cestu, ak existuje pre vybrané úložisko PBS. Ak je na PBS dostupná skupina <code>-keyrecovery</code>, druhý krok stiahne jej najnovšiu snímku a vyžiada prístupovú frázu na dešifrovanie. Ak ani jedna možnosť nefunguje alebo ich operátor odmietne, tretí krok vyžiada absolútnu cestu k súboru kľúča na tomto hostiteľovi a skopíruje ho na kanonickú cestu. Monitor poskytuje rovnaký import v okne podrobností zálohy. Ak Obnoviť, Stiahnuť alebo Zobraziť obsah potrebuje chýbajúci kľúč, hore sa zobrazí jantárový panel. Ak je kľúč nainštalovaný, ale nezodpovedá šifrovaniu zálohy, PBS vráti chybu <code>wrong key — manifest's key XX does not match provided key YY</code>. Rovnaké tri akcie potom zobrazia štruktúrovaný panel so zvýrazneným odtlačkom kľúča požadovaným manifestom, aby operátor vedel, ktorý kľúč má pre túto zálohu importovať.",
"monitorManagementTitle": "Správa súboru kľúčov z monitora",
"monitorManagementBody": "Monitor zobrazuje ovládanie súboru kľúča priamo v každom riadku cieľa PBS na stránke konfigurácie záloh. Sú tam tri akcie: <em>Stiahnuť</em> exportuje aktuálny súbor do prehliadača operátora; <em>Nahrať</em> nahradí nainštalovaný súbor dodaným súborom, pričom pôvodný prepíše až po úspešnom uložení nového na kanonickú cestu; <em>Odstrániť</em> zmaže súbor z hostiteľa. Vedľa je ovládanie obnovovacej kópie: výber Áno/Nie pre <em>Odoslať kľúč na PBS?</em>, pole prístupovej frázy pri voľbe Áno a kontextové tlačidlo na použitie voľby <em>Spustiť odosielanie</em>, <em>Zastaviť odosielanie</em> alebo <em>Aktualizovať prístupovú frázu</em>. Všetky akcie používajú rovnaké koncové body Flask ako terminálové rozhranie, takže účinok na disku a stav na PBS sú z oboch rozhraní rovnaké."
},
"restoreAccess": {
"heading": "Získavanie na strane obnovy",
"body": "Obnova zisťuje zálohy hostiteľa ProxMenux na PBS zoznamom skupín v nakonfigurovanom úložisku a filtrovaním podľa vzoru identifikátora zálohy. Karta Zálohy v Monitore zobrazuje rovnaký zoznam. Výber zálohy spustí <code>proxmox-backup-client restore</code> s rovnakým úložiskom, heslom a odtlačkom, prípadne aj s <code>--keyfile</code>, ak bola záloha šifrovaná. Archív <code>.pxar</code> sa rozbalí do prípravného adresára, ktorý <code>_rs_check_layout</code> odovzdá štandardnému procesu obnovy. Pri ručnom získaní mimo ProxMenux rozbalí ten istý príkaz archív na ľubovoľnú cestu; výsledný strom možno skontrolovať alebo použiť pri ručnej obnove."
},
"references": {
"heading": "Odkazy",
"intro": "Oficiálna dokumentácia Proxmox Backup Server ku komponentom, ktoré ProxMenux používa.",
"items": [
{
"label": "Dokumentácia Proxmox Backup Server",
"href": "https://pbs.proxmox.com/docs/",
"tail": " — hlavný rozcestník pre inštaláciu, správu, úložiská, používateľov a roly."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — nástroj príkazového riadka, ktorý ProxMenux používa pri každej zálohe a obnove. Opisuje identifikátory a typy záloh, archívy, syntax úložísk a premenné prostredia."
},
{
"label": "Šifrovanie na strane klienta",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — vytvorenie súboru kľúča, režimy --kdf a model šifrovania, ktorý ProxMenux rozširuje o obnovovaciu kópiu chránenú prístupovou frázou."
},
{
"label": "Správa dátových úložísk",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": "— vytváranie a správa dátových úložísk, ktoré prijímajú zálohy hostiteľa, vrátane rozloženia chunk-store a povolení."
},
{
"label": "Prerezávanie a zber odpadu",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — model uchovávania pre --keep-last / --keep-daily / --keep-weekly, ktorý ProxMenux uplatňuje pre každú plánovanú úlohu, aj spôsob, akým PBS uvoľňuje nepoužívané bloky po odstránení starých záloh."
}
]
}
}
web/messages/sk/docs/backup-restore/glossary.json
+230
View File
@@ -0,0 +1,230 @@
{
"meta": {
"title": "Slovník — zálohovanie a obnova | ProxMenux",
"description": "Slovník systému zálohovania a obnovy ProxMenux: šifrovanie, súbor kľúčov, prístupová fráza, obálka obnovy, PBS, bloky, rootfs, manifest, vykonávací proces a doplnenie medzi verziami jadra.",
"ogTitle": "Slovník zálohovania a obnovy | ProxMenux",
"ogDescription": "Jasné definície slovnej zásoby použitej cez zálohovanie a obnovenie dokumentácie ProxMenux.",
"twitterTitle": "Slovník zálohovania a obnovy | ProxMenux",
"twitterDescription": "Prístupová fráza, súbor kľúčov, obálka obnovy, rootfs, manifest, PBS a bloky — všetko vysvetlené na jednom mieste."
},
"header": {
"title": "Slovník pojmov",
"description": "Pojmy z dokumentácie zálohovania a obnovy spolu s definíciami.",
"section": "Záloha a obnova"
},
"intro": {
"body": "Pojmy sú zoskupené podľa témy. Každý záznam dáva termín a krátku definíciu."
},
"groups": [
{
"title": "Šifrovanie a obnovenie kľúča",
"intro": "Slovník pre šifrovací blok PBS. Zahŕňa dve odlišné tajomstvá: binárny súbor kľúčov a písomné heslo.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Prístupová fráza na obnovu",
"def": "Textové heslo, ktoré užívateľ vyberá na ochranu obálky <a href=\"#sobre-recuperacion\">obnovenie </a>. Vyžaduje sa dvakrát s kontrolou zhody a používa sa len na šifrovanie obálky a dešifrovanie súboru, ak je niekedy potrebné obnoviť súbor kľúčov. <strong>Nie je to heslo, ktoré odomkne samotný súbor kľúčov </strong> a nikdy sa nepošle PBS. Počas normálnej zálohy nikdy neopustí hostiteľa."
},
{
"id": "clave-cifrado",
"term": "Súbor kľúčov (šifrovací kľúč)",
"def": "Súbor kľúča používaný proxmox-backup-client na šifrovanie <a href=\"#chunk\">blokov</a> pred odoslaním do PBS. Bez príslušného kľúča sa šifrované dáta nedajú čítať. ProxMenux ho uloží do <code>/usr/local/share/proxmenux/pbs-key.conf</code> s režimom <code>600</code>. Chráňte ho; <a href=\"#sobre-recuperacion\">obálka obnovy</a> slúži na jeho získanie pri strate."
},
{
"id": "contrasena-keyfile",
"term": "Heslo súboru kľúčov (KDF heslo)",
"def": "Voliteľné heslo, ktoré môže byť prenášané samotným súborom kľúčov, odlišné od <a href=\"#passphrase-recuperacion\">prístupovej frázy na obnovu</a>. Existuje len vtedy, keď bol súbor s kľúčom vytvorený <code>--kdf scrypt</code> (zvyčajne importovaný súbor kľúčov). Bez neho nie je možné súbor kľúčov odomknúť pre použitie. ProxMenux pretrváva v zašifrovanej forme na hostiteľa, takže plánované zálohy môžu bežať bez interaktívneho promptu."
},
{
"id": "sobre-recuperacion",
"term": "Obálka obnovy",
"def": "Súbor <a href=\"#clave-cifrado\">súbor kľúčov</a> zabalený do ďalšej vrstvy: je zašifrovaný <a href=\"#passphrase-recuperacion\">prístupovou frázou na obnovu</a> použitie <a href=\"#aes-256-cbc\">AES-256-CBC</a> a <a href=\"#pbkdf2\">PBKDF2</a> predtým, než opustí hostiteľa. Nahrá sa do PBS ako <code>-keyrecovery</code> skupina. Bez passfrázy je obálka nepriehľadná: sťahovanie z PBS neodhaľuje súbor kľúčov."
},
{
"id": "cifrado-cliente",
"term": "Šifrovanie na strane klienta",
"def": "Model šifrovania, pri ktorom sa dáta zašifrujú na zdrojovom hostiteľovi pred odoslaním. PBS prijíma a ukladá iba šifrované dáta; bez súboru kľúča ich neprečíta ani správca PBS s prístupom k dátovému úložisku. ProxMenux na tomto modeli stavia a pridáva <a href=\"#sobre-recuperacion\">obálku obnovy</a>."
},
{
"id": "kdf-none",
"term": "--kdf none",
"def": "Možnosť <code>proxmox-backup-client key create</code>, ktorá vytvára súbor kľúčov bez pripojenej pasovej frázy. Súbor kľúčov možno použiť priamo bez promptu, ktorý je nevyhnutný pre plánované pracovné miesta bez dozoru. Toto ProxMenux používa štandardne pri generovaní nového súboru kľúčov."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"def": "Možnosť <code>proxmox-backup-client key create</code>, ktorá vytvára súbor kľúčov chránený pomocou <a href=\"#contrasena-keyfile\">prístupovej frázy súboru kľúča</a>. Každé použitie súboru kľúčov si vyžaduje odomknutie s touto passfrázou. ProxMenux akceptuje tento štýl súboru kľúčov pri importe a ukladá heslo šifrované, takže plánované zálohy môžu spustiť bez dozoru."
},
{
"id": "aes-256-cbc",
"term": "AES-256-CBC",
"def": "Štandardné symetrické šifrovanie. ProxMenux ju používa (prostredníctvom <code>openssl enc -aes-256-cbc</code>) na zabalenie <a href=\"#clave-cifrado\">súboru kľúča</a> s <a href=\"#passphrase-recuperacion\"> prístupovou frázou na obnovu</a> a výrobu <a href=\"#sobre-recuperacion\">obálky</a>."
},
{
"id": "pbkdf2",
"term": "PBKDF2",
"def": "Kryptografická funkcia, ktorá z prístupovej frázy zadanej človekom odvodí binárny šifrovací kľúč. Mnohými iteráciami spomaľuje útoky hrubou silou. Pri šifrovaní obálky obnovy ju ProxMenux používa so 600 000 iteráciami a náhodnou soľou."
}
]
},
{
"title": "Štruktúra zálohy",
"intro": "Pojmy popisujúce, čo žije v zálohe, bez ohľadu na cieľ.",
"entries": [
{
"id": "rootfs",
"term": "rootfs / koreňový súborový systém",
"def": "Súborová kópia systému zdrojového hostiteľa vytvorená pomocou <code>rsync</code> podľa <a href=\"#perfil-defecto\">predvoleného profilu</a> a <a href=\"#rutas-personalizadas\">vlastných ciest</a>. Nie je to obraz celého disku: kopírujú sa iba cesty s konfiguráciou alebo stavom, ktoré Proxmox nedokáže sám obnoviť."
},
{
"id": "manifiesto",
"term": "Manifest (manifest.json)",
"def": "Štruktúrovaný dokument JSON opisujúci zdrojový hostiteľ v čase zálohovania: hardvér, úložisko, jadro, ProxMenux-inštalované komponenty a inventár VM a LXC. Vyrába ho šesť nezávislých zberateľov. Obnoviteľný tok ho využíva na porovnanie zdroja a cieľa."
},
{
"id": "staging",
"term": "Staging adresár",
"def": "Dočasný adresár, kde ProxMenux zhromažďuje tri bloky (rootfs, metaúdaje a manifest) pred ich zabalením a nahrávanie do cieľa. Po dokončení zálohy sa automaticky odstráni, a to aj po prerušení."
},
{
"id": "perfil-defecto",
"term": "Predvolený profil",
"def": "Vybraná sada ciest, ktoré ProxMenux predvolene kopíruje v každej zálohe. Zahŕňa konfiguráciu PVE, sieť, SSH, jadro, apt, nástroje ProxMenux a ďalšie. Je definovaná v kóde a opísaná na stránke <em>Ako to funguje</em>."
},
{
"id": "rutas-personalizadas",
"term": "Vlastné cesty",
"def": "Extra cesty, ktoré užívateľ pridáva na vrchol <a href=\"#perfil-defecto\">predvoleného profilu</a>. Buď perzistentné (uložené v <code>backup-extra-paths.txt</code>) alebo iba pre dané spustenie (vybrané vo vlastnom režime)."
}
]
},
{
"title": "Miesta určenia a skladovanie",
"intro": "Pojmy súvisiace s cieľom zálohy — server PBS, lokálny archív alebo repozitár Borg — a usporiadaním dát v PBS.",
"entries": [
{
"id": "repositorio-pbs",
"term": "PBS repozitár",
"def": "Kombinácia Proxmox Backup Server + <a href=\"#datastore\">úložisko údajov</a> + používateľ, ktorý prijíma zálohu. Identifikované podľa reťazca <code>user@realm@host:datastore</code>. Jeden PBS server môže hostiť niekoľko úložísk."
},
{
"id": "datastore",
"term": "Dátové úložisko",
"def": "Konkrétne dátové úložisko na serveri PBS so zálohami a ich blokmi. Každé je na súborovom systéme servera PBS a má vlastné oprávnenia a pravidlá."
},
{
"id": "chunk",
"term": "Chunk / chunk deduplikácia",
"def": "PBS rozdelí zálohu na bloky premenlivej veľkosti, každý identifikuje hashom a uloží ho iba raz, aj keď sa vyskytuje vo viacerých zálohách. Následné zálohy rovnakého alebo podobných hostiteľov tak vyžadujú málo ďalšieho miesta."
},
{
"id": "fingerprint",
"term": "Odtlačok prsta",
"def": "Kryptografický odtlačok certifikátu PBS servera TLS. Umožňuje klientovi overiť, či sa rozpráva s plánovaným serverom bez toho, aby sa spoliehal na verejný certifikačný orgán. ProxMenux ho prenáša na <code>proxmox-backup-client</code> prostredníctvom premennej prostredia <code>PBS_FINGERPRINT</code>."
},
{
"id": "grupo-copia",
"term": "Skupina zálohy",
"def": "Logická skupina v PBS pre postupné zálohy toho istého zdroja. Nové zálohy využívajú deduplikáciu s predchádzajúcimi. Pri zapnutom šifrovaní používa ProxMenux dve skupiny na hostiteľa: jednu pre jeho zálohu a druhú s príponou <code>-keyrecovery</code> pre <a href=\"#sobre-recuperacion\">obálku obnovy</a>."
},
{
"id": "backup-id",
"term": "ID zálohy",
"def": "Názov skupiny <a href=\"#grupo-copia\">backup</a>. ProxMenux predvolený <code>hostcfg-HOSTNAME</code> a umožňuje užívateľovi upraviť pred nahrávaním; nepodporované znaky sú automaticky odstránené."
},
{
"id": "pxar",
"term": ".pxar",
"def": "PBS-native archív formát pre adresáre. Správa sa ako archív tar optimalizovaný pre deduplikáciu kúskov: PBS namiesto ukladania nepriehľadného súboru rozbije svoj obsah na opakovane použiteľné kúsky."
}
]
},
{
"title": "Vykonávanie a plánovanie",
"intro": "Pojmy systému plánovaných úloh ProxMenux.",
"entries": [
{
"id": "runner",
"term": "Vykonávací proces",
"def": "Skript <code>run_scheduled_backup.sh</code> vykonávajúci plánovanú zálohu. Prečíta konfiguráciu úlohy, spustí príslušný backend (Local, PBS alebo Borg), po úspechu uplatní pravidlá uchovávania a odošle nastavené oznámenia."
},
{
"id": "trabajo-programado",
"term": "Plánovaná úloha",
"def": "Pretrvávajúca konfigurácia opakovaného zálohovania. Drží cieľ, poverovacie listiny, šifrovanie, harmonogram a uchovávanie. Žije na <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
},
{
"id": "modo-adjunto",
"term": "Pripojený režim",
"def": "Úloha bez vlastného časovača. Hook job-end PVE <code>vzdump</code> ju spustí po zálohách hostí pri zhodnom úložisku. Vybraná nadradená úloha poskytne cieľ a počiatočné uchovávanie, ale hook porovnáva úložisko, nie ID nadradenej úlohy. Spustiť ju môže aj iná úloha s tým istým úložiskom. Iba Local a PBS."
},
{
"id": "timer-systemd",
"term": "Časovač Systemd",
"def": "Štandardný mechanizmus systemd, ktorý spúšťa príkaz podľa kalendára. ProxMenux vytvára časovač pre každú <em>nezávislú</em> plánovanú úlohu. Úlohy v <a href=\"#modo-adjunto\">pripojenom režime</a> časovač nemajú; spúšťa ich hook PVE."
},
{
"id": "retencion",
"term": "Uchovávanie (keep-last, keep-daily…)",
"def": "Politika, ktorá rozhodne, ktoré staršie zálohy udržať a ktoré prerezávať. Definované podľa úloh s parametrami ako <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Aplikuje vykonávací proces po každej úspešnej zálohe."
}
]
},
{
"title": "Obnoviť",
"intro": "Pojmy z postupu obnovy.",
"entries": [
{
"id": "restauracion-universal",
"term": "Všeobecná obnova",
"def": "Tok obnovy ProxMenux neextrahuje iba súborový systém: prečíta manifest, aby zistil rozdiely medzi zdrojom a cieľom, reprodukuje konfiguráciu systému a znova spustí inštalačné programy pre komponenty spravované ProxMenux. Cieľom je reprodukovať hostiteľa zdroja, nielen archív."
},
{
"id": "hidratacion",
"term": "Hydratácia (cross-kernel)",
"def": "Krok obnovy, ktorý zlúči používateľské nastavenia zo zdroja (parametre IOMMU, ID zariadení VFIO, vlastné úpravy a kľúče GRUB) s novou konfiguráciou štartu cieľa bez doslovného kopírovania súborov viazaných na zdrojové jadro. Beží, ak je jadro cieľa novšie než v zálohe."
},
{
"id": "cross-kernel",
"term": "Obnova medzi kernelmi",
"def": "Obnovte tam, kde sa jadro cieľa líši od jadra zdroja (zvyčajne je novšie). Vyžaduje sa prechod <a href=\"#hidratacion\">hydratácia</a>, aby sa predišlo presúvaniu súborov nekompatibilných s jadrom cieľa."
},
{
"id": "instalador-postboot",
"term": "Inštalátor post-boot",
"def": "Komponenty reinštalované po prvom štarte obnoveného hostiteľa (ovládače NVIDIA, ovládače Coral TPU, nástroje AMD GPU, nástroje Intel GPU). Každý inštalátor beží proti jadru cieľa, takže obnovený hostiteľ nezávisí od prítomnosti jadra zdroja."
},
{
"id": "compatibility-check",
"term": "Kontrola kompatibility",
"def": "Porovnanie medzi zdrojovým manifestom a cieľovým stavom, ktorý ProxMenux vykonáva na začiatku obnovy. Rozhoduje, ktoré časti sú skopírované doslovne, ktoré potrebujú hydratáciu a ktoré sú znovu vytvorené inštalátorom."
},
{
"id": "equipo-recien-instalado",
"term": "Čerstvá inštalácia",
"def": "Hostiteľ preinštalovaný od nuly bez lokálneho <a href=\"#clave-cifrado\">súboru kľúča</a>. Obnova šifrovanej zálohy vyžaduje najprv získať kľúč z <a href=\"#sobre-recuperacion\">obálky</a> uloženej v PBS pomocou <a href=\"#passphrase-recuperacion\">prístupovej frázy na obnovu</a>."
}
]
}
],
"whereNext": {
"heading": "Kde ďalej",
"items": [
{
"label": "Ako to funguje",
"href": "/docs/backup-restore/how-it-works",
"tail": " — kde sa v zálohe nachádza rootfs, manifest a inventár aplikácií."
},
{
"label": "Cieľ Proxmox Backup Server",
"href": "/docs/backup-restore/destinations/pbs",
"tail": "— kde sú do hĺbky zdokumentované šifrovanie na strane klienta, súbor kľúčov, prístupová fráza na obnovenie a obálka."
},
{
"label": "Obnovenie",
"href": "/docs/backup-restore/restoring",
"tail": " — postup obnovy a použitie manifestu."
}
]
}
}
web/messages/sk/docs/backup-restore/how-it-works.json
+205
View File
@@ -0,0 +1,205 @@
{
"meta": {
"title": "Ako ProxMenux Backup funguje interne — rootfs, manifest a aplikácie",
"description": "Podrobný obsah zálohy ProxMenux: rootfs skopírovaný pomocou rsync podľa predvoleného profilu ciest, štruktúrovaný manifest vytvorený šiestimi nezávislými zbernými skriptmi a inventár aplikácií, ktorý riadi automatickú reinštaláciu balíkov a komponentov po obnove.",
"ogTitle": "Ako ProxMenux Backup funguje interne",
"ogDescription": "Tri časti zálohy ProxMenux: rootfs, manifest a aplikácie.",
"twitterTitle": "Ako funguje zálohovanie ProxMenux | ProxMenux",
"twitterDescription": "Tri časti zálohy ProxMenux a spôsob, akým z nich obnova znovu vytvorí zdrojového hostiteľa."
},
"header": {
"title": "Ako to funguje",
"description": "Vnútorná štruktúra zálohy ProxMenux — súborový systém, manifest a inventár aplikácií — a spôsob, akým ich obnova používa na vytvorenie pôvodného hostiteľa na cieli, ktorý môže mať iné jadro.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Jeden archív, tri časti",
"body": "Každá záloha vytvorí tri jasne oddelené časti v spoločnom prípravnom adresári. Archív odoslaný do cieľa (lokálny <code>.tar.zst</code>, záloha PBS alebo archív Borg) obsahuje túto istú štruktúru. Obnova používa všetky tri: <strong>manifest</strong> pred zmenami určí rozdiely a výnimky; <strong>rootfs</strong> poskytne konfiguračné súbory, ktoré sa použijú za behu alebo po reštarte; <strong>inventár aplikácií</strong> riadi inštaláciu balíkov a reinštaláciu komponentov po štarte. Každú časť možno skontrolovať alebo rozbaliť samostatne."
},
"layout": {
"heading": "Rozloženie archívu",
"intro": "Každý archív sleduje rovnaké rozloženie stromov bez ohľadu na cieľ. Podadresár <code>metadata/</code> má štruktúrované užitočné zaťaženie; podadresár <code>rootfs/</code> má kópiu súborového systému.",
"treeCaption": "Prípravný adresár vytvorený pri zálohe. Každý cieľ dostane rovnaký strom vo svojom formáte: tar pri lokálnom cieli, bloky PBS pri PBS a segmenty Borg pri Borgu.",
"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": "Časť rootfs",
"intro": "Strom <code>rootfs/</code> je <strong>obyčajná kópia súborového systému</strong> vytvorená pomocou <code>rsync</code> zo zdrojového hostiteľa. Obsahuje vybraný <strong>predvolený profil</strong> ciest dôležitých pre obnovu Proxmoxu a <strong>vlastné cesty</strong>, ktoré používateľ pridal do úlohy alebo interaktívnej relácie. Výber je zámerne úzky: iba cesty, ktoré <em>obsahujú konfiguráciu</em> alebo <em>uchovávajú stav, ktorý Proxmox nedokáže sám znovu vytvoriť</em>.",
"defaultProfileTitle": "Štandardný profil",
"defaultProfileBody": "Predvolený profil definuje <code>hb_default_profile_paths</code> v <code>lib_host_backup_common.sh</code>. Zahŕňa osem pevných kategórií a prípadne stav ZFS, ktoré spolu opisujú funkčného hostiteľa Proxmox:",
"categoriesTitle": "Kategórie ciest",
"categoryRows": [
{
"category": "Jadro PVE",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
"why": "Obsah klastrového súborového systému a predvolené nastavenia vzdump. Databáza pmxcfs (<code>config.db</code>) sa zachytí ako konzistentná snímka cez <code>sqlite3 .backup</code> bez zastavenia klastra. Sprievodné súbory <code>.db-wal</code> / <code>.db-shm</code> sa z rsync vylúčia. Ak <code>sqlite3</code> nie je dostupný, vytvorí sa <code>config.db.raw-fallback</code>, ktorý obnova automaticky použije ako databázu."
},
{
"category": "Identita hostiteľa & sieť",
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
"why": "Všetko potrebné na spustenie hostiteľa v sieti s rovnakou identitou. Súbory <code>.link</code> v <code>/etc/systemd/network</code> priraďujú názvy sieťových kariet k ich MAC adresám, aby sa názvy zachovali pri reinštalácii a zmenách hardvéru."
},
{
"category": "Prístup a overovanie",
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
"why": "Kľúče SSH, pravidlá sudo a konfigurácia PAM. Ich strata môže používateľovi znemožniť prístup k obnovenému hostiteľovi."
},
{
"category": "Jadro a štart systému",
"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": "Parametre IOMMU, zoznamy zakázaných modulov, ID zariadení VFIO, tabuľka pripojení a konfigurácia úložísk."
},
{
"category": "Shell a miestne nastavenia",
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
"why": "Systémová konfigurácia shellu, premenné prostredia a nastavenie generovania miestnych nastavení."
},
{
"category": "Správa balíkov a 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 zdroje pre konzistentné riešenie balíkov, plánované úlohy definované užívateľom."
},
{
"category": "Stav a nástroje ProxMenux",
"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": "Voliteľné, ale bežné náradie Proxmox. Chýbajúce cesty sú zaznamenané v <code>metadata/missing_paths.txt</code> bez zastavenia zálohy."
},
{
"category": "Spustiteľné súbory ProxMenux a účet root",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (bez dočasných podadresárov)",
"why": "Binárne systémy nainštalované ProxMenux a konfigurácia na užívateľa podľa <code>/root</code>. Prchavé cesty (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sú z kópie vylúčené. <code>/var/lib/proxmenux</code> drží plánované záložné úlohy a stav hostiteľa udržiava ProxMenux; obnovenie inscenácie, rollback kópie a post-restore markery sú vylúčené, pretože patria k hostiteľovi, ktorý prevádzkuje obnovenie."
},
{
"category": "Stav ZFS (podmienený)",
"paths": "/etc/zfs",
"why": "Zahrnuté iba vtedy, keď zdroj spustí ZFS. Obsahuje <code>zpool.cache</code> a <code>hostid</code>."
}
],
"customTitle": "Rozšírenie profilu vlastnými cestami",
"customBody": "Okrem predvoleného profilu, ProxMenux ponúka dva spôsoby, ako zahrnúť ďalšie cesty do zálohy. Skladajú sa bez konfliktu a obe sa vzťahujú na interaktívne zálohy a plánované pracovné miesta.",
"customExtrasTitle": "1. Trvalé doplnky (na-host súbor)",
"customExtrasBody": "Textový súbor <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> obsahuje absolútne cesty, ktoré používateľ na tomto hostiteľovi označil ako „vždy zahrnúť“. Pri zálohe v režime <strong>Predvolené</strong> sa automaticky pridajú do predvoleného profilu bez otázok. Súbor sa upravuje cez rozhranie, bez ručnej úpravy, a pretrváva medzi reštartmi aj aktualizáciami. Každý riadok obsahuje jednu absolútnu cestu; komentáre s <code>#</code> sú povolené.",
"customModeTitle": "2. Vlastný režim (na beh)",
"customModeBody": "Spustenie zálohy v režime <strong>Vlastný</strong> nahradí automatickú aplikáciu predvoleného profilu kontrolným zoznamom zobrazujúcim každú cestu: položky predvoleného profilu a trvalé doplnky (s predponou <code>[+]</code> a vopred začiarknuté). Používateľ začiarkne alebo odznačí položky pre daný konkrétny chod a môže tiež stlačiť <em>Pridať vlastnú cestu</em> na zadanie novej cesty – ktorá sa potom uloží do extra súboru pre budúce zálohy.",
"customMissingTitle": "Cesta neprítomná zo zdroja",
"customMissingBody": "Akákoľvek cesta z profilu (predvolená alebo pridaná), ktorá neexistuje na zdrojovom hostiteľovi, sa zaznamenáva v <code>metadata/missing_paths.txt</code> vo vnútri archívu. Zálohovanie nezlyhá, ani sa nezastaví. Užívateľ vidí súhrn archivovaných ciest a chýbajúce cesty na konci. V praxi sa to stane pre voliteľné cesty nástrojov, ako je <code>/etc/wireguard</code> alebo <code>/etc/prometheus</code>, ak tieto nástroje nie sú nainštalované."
},
"manifest": {
"heading": "Časť s manifestom",
"intro": "<code>manifest.json</code> je štruktúrovaný dokument JSON opisujúci zdrojového hostiteľa v čase zálohy. Vytvára ho <strong>šesť nezávislých zberných skriptov</strong> riadených skriptom <code>build_manifest.sh</code>. Každý iba číta údaje a vytvorí presne definovanú časť JSON. Pri zlyhaní použije bezpečnú prázdnu predvolenú hodnotu, takže manifest zostáva použiteľný aj s neúplnou časťou.",
"orchestratorCaption": "Manifest tvorí šesť zberných skriptov. Každý beží vo vlastnom podprocese. Pri zlyhaní jednej časti sa použije zdokumentovaná bezpečná predvolená hodnota a zobrazí upozornenie, ale záloha sa nepreruší.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
"produces": "source_host",
"content": "Názov hostiteľa, verzia PVE (<code>pveversion</code>), verzia PBS, ak hostiteľ plní úlohu zálohovacieho servera, jadro (<code>uname -r</code>), režim zavádzania (efi/bios), typ koreňového súborového systému, model a architektúra CPU, pamäť v KB."
},
{
"collector": "collect_hardware.sh",
"produces": "hardware_inventory",
"content": "GPU s výrobcom a priradeným inštalátorom ProxMenux; TPU Coral USB a M.2 zistené pomocou <code>lsusb</code>/<code>lspci</code>; sieťové karty s MAC adresou, PCI slotom a priradením k mostu; bezdrôtové zariadenia. Záznamy GPU obsahujú heuristiku <code>passthrough_eligible</code>."
},
{
"collector": "collect_storage.sh",
"produces": "storage_inventory",
"content": "ZFS pools (s pool typ + členské disky vyriešené na <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> alebo surové <code>/dev/sdX</code> cesty v závislosti od toho, ako každý pool bol pôvodne vytvorený), LVM objemové skupiny + thin pools, fyzické disky s SMART schopnosť, PVE <code>storage.cfg</code> vstupy, externé pripojenia."
},
{
"collector": "collect_kernel.sh",
"produces": "kernel_params",
"content": "Parametre pridané správcom do <code>/proc/cmdline</code> bez bežných predvolených položiek, ako sú <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> a <code>splash</code>; moduly načítavané pri štarte z <code>/etc/modules</code>; a cesty súborov <code>/etc/modprobe.d/*.conf</code>, ktoré obsahujú skutočné direktívy (<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": "Číta <code>/usr/local/share/proxmenux/managed_installs.json</code> (registrácia všetkého, čo ProxMenux nainštaloval) a <code>installed_tools.json</code>. Každý záznam udržuje inštalačnú dráhu (<code>menu_script</code>), takže obnovenie môže spustiť presne rovnaký inštalačný tok."
},
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
"content": "Vypíše VM (<code>qm list</code>) a kontajnery LXC (<code>pct list</code>) prítomné v čase zálohy: VMID, názov a aktuálny stav. Ide iba o inventár; samotné údaje hostí zálohujú <code>vzdump</code> / PBS."
}
],
"schemaTitle": "Potvrdenie schémy",
"schemaBody": "Manifest sa overuje podľa <code>scripts/backup_restore/schema/manifest.schema.json</code>. Príkaz <code>build_manifest.sh --validate</code> spustí validáciu JSON Schema v Pythone, ktorá vyžaduje <code>python3</code> a <code>jsonschema</code>. Ak modul chýba, kontrola sa bez upozornenia preskočí. Validácia slúži najmä vývojárom, nie je závislosťou potrebnou pri bežnom behu."
},
"applications": {
"heading": "Inventár aplikácií",
"intro": "Dva inventáre evidujú softvér pridaný k základným balíkom Proxmox VE: zoznam balíkov v <code>metadata/</code> a register komponentov v rootfs, podrobne opísané nižšie. Obnova podľa pôvodného spôsobu inštalácie používa APT alebo inštalátory ProxMenux na opätovnú inštaláciu používateľského softvéru.",
"packagesTitle": "packages.manual.list",
"packagesBody": "Abecedný textový zoznam z <code>apt-mark showmanual</code> obsahuje všetky balíky APT <em>výslovne nainštalované</em> na zdrojovom hostiteľovi. Nezahŕňa závislosti základného systému Proxmox VE, ktoré APT cieľa nainštaluje automaticky. Pri obnove ho číta <code>_rs_run_complete_extras</code> a použije trojstupňový <em>filter proti kaskádovému odstraňovaniu</em>: <code>dpkg -s</code> zistí už nainštalované balíky, pri knižniciach sa zistia iné hlavné verzie a <code>apt-get install --simulate</code> overí riziko následného odstraňovania. Zvyšné balíky sa nainštalujú cez <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (súčasť rootfs)",
"componentsBody": "Register JSON v <code>/usr/local/share/proxmenux/</code> eviduje každý komponent nainštalovaný cez ProxMenux s presným stavom: verziou a osobitnými príznakmi (pri NVIDIA logická hodnota <code>patched</code>, pri Coral verzia DKMS). Súbor je v rootfs, nie v <code>metadata/</code>, pretože sa <em>číta až po</em> skopírovaní rootfs na cieľ. Dispečer po štarte (<code>apply_cluster_postboot.sh</code>) prejde záznamy a spustí pre každý komponent jeho <code>--auto-reinstall</code> hook. Ten prečíta uložený stav a zopakuje inštaláciu pre aktuálne jadro cieľa.",
"componentInstallersTitle": "Inštalátory komponentov",
"componentInstallersBody": "Štyri inštalátory ProxMenux v súčasnosti vystavujú vstupný bod <code>--auto-reinstall</code>:",
"installerRows": [
{
"component": "nvidia_driver",
"installer": "gpu_tpu/nvidia_installer.sh",
"action": "Číta <code>version</code> a <code>patched</code>. Stiahne ten istý inštalačný súbor NVIDIA, zostaví moduly DKMS pre jadro cieľa a znovu použije opravu ProxMenux, ak bola na zdroji zapnutá."
},
{
"component": "coral_driver",
"installer": "gpu_tpu/install_coral.sh",
"action": "Číta verziu Coral ovládač. Kompiluje modul DKMS s jadrom cieľa."
},
{
"component": "amdgpu_top",
"installer": "gpu_tpu/amd_gpu_tools.sh",
"action": "Číta nahranú verziu. Znovu stiahne presný <code>.deb</code> z GitHub vydania."
},
{
"component": "intel_gpu_tools",
"installer": "gpu_tpu/intel_gpu_tools.sh",
"action": "APT inštaluje balík. Idempotentné, ak už prítomný z <code>packages.manual.list</code>."
}
]
},
"restoreFlow": {
"heading": "Ako obnova používa tri časti",
"intro": "Obnova má šesť fáz. Každá číta konkrétnu časť archívu a aktualizuje cieľového hostiteľa. Žiadna nevyžaduje dostupnosť zdrojového hostiteľa: archív obsahuje všetky potrebné zálohované údaje.",
"stagesCaption": "Fáza 1 podľa manifestu rozhodne, čo upraviť. Fáza 2 skopíruje cesty rootfs použiteľné za behu. Fáza 3 pripraví rizikové cesty na ďalší štart. Fáza 3b importuje dátové pooly ZFS bez koreňového systému, ktorých disky sú všetky prítomné. Fáza 4 rieši balíky. Fáza 5 po reštarte preinštaluje komponenty pre jadro cieľa.",
"stageRows": [
{
"stage": "1",
"name": "Kontrola kompatibility",
"reads": "manifest.json",
"action": "Spúšťa <code>hb_compat_check</code>. Porovnáva zdrojový a cieľový hardvér (NIC, identifikátory úložísk), verziu PVE a hlavnú verziu jadra. Nastavuje <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> alebo <code>bk_older</code>) a zaľudňuje <code>RS_SKIP_PATHS</code> s hardware-drift a cross-kernel s výnimkou."
},
{
"stage": "2",
"name": "Použitie za tepla",
"reads": "rootfs/ (len bezpečné cesty)",
"action": "<code>_rs_apply … hot</code> kopíruje <code>hb_classify_path</code>=<code>hot</code> položky priamo do živého cieľa. Všetko pod <code>/etc/pve</code>, <code>/etc/network</code> alebo cesty klasifikované ako <em>reboot</em>/<em>dangerous</em> je odložený."
},
{
"stage": "3",
"name": "Príprava odložených zmien",
"reads": "rootfs/ (reboot + nebezpečné cesty)",
"action": "<code>_rs_prepare_pending_restore</code> pripraví rizikové cesty v <code>/var/lib/proxmenux/pending-restore/</code>, zapíše <code>plan.env</code>, <code>apply-on-boot.list</code> a <code>rs-skip-paths.txt</code> a povolí spustenie <code>proxmenux-restore-onboot.service</code> pri ďalšom štarte."
},
{
"stage": "3b",
"name": "Import dátových poolov",
"reads": "manifest.storage_inventory + cieľový ZFS stav",
"action": "<code>_rs_import_data_pools</code> importuje každého ZFS pool každého iného typu než root, ktorého úplná sada diskov sa nachádza v cieli. Pools nesúci cudzí hostid sa zopakuje s <code>zpool import -f</code>. Pools chýbajúce disky sú preskočené s varovaním. Výsledok per-pool je zaznamenaný v <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
},
{
"stage": "4",
"name": "Inštalácia balíka",
"reads": "metadata/packages.manual.list",
"action": "<code>_rs_run_complete_extras</code> spustí kaskádovo bezpečný filter a zavolá <code>apt-get install -y</code> so zoznamom prežitých balíkov. Celý výstup ide do <code>/var/log/proxmenux/restore-apt-*.log</code>."
},
{
"stage": "5",
"name": "Po štarte systému",
"reads": "rootfs (už použité) + components_status.json",
"action": "Po reštarte <code>apply_pending_restore.sh</code> použije odložené cesty a <code>apply_cluster_postboot.sh</code> spustí <code>update-initramfs</code>, <code>update-grub</code> alebo <code>proxmox-boot-tool refresh</code>. Potom prejde <code>components_status.json</code> a pre každý komponent spustí jeho <code>--auto-reinstall</code> hook."
}
]
},
"whyItWorks": {
"heading": "Prečo je záloha rozdelená na tri časti",
"body": "Rozdelenie sleduje <strong>životný cyklus</strong> údajov. Súborový systém sa prenáša cez <code>rsync</code>: rýchlo, prehľadne a atómovo po súboroch. Konfiguračný stav, ktorý treba vyhodnotiť pred zmenami, je <strong>štruktúrovaný JSON</strong>, samostatne čitateľný, verzovateľný schémou a strojovo porovnateľný so stavom cieľa. Softvér na reinštaláciu opisuje <strong>inventár</strong> názvov a verzií; správca balíkov a inštalátory ProxMenux vyberú vhodné binárne súbory. Každá časť plní vlastnú úlohu. Spolu smerujú ku konzistentnej obnove odolnej voči chybám: poškodený manifest ponecháva rootfs obnoviteľný, chýbajúci balík nebráni inštalácii komponentov a zlyhanie pri jednej položke nezastaví ďalšiu."
}
}
web/messages/sk/docs/backup-restore/index.json
+93
View File
@@ -0,0 +1,93 @@
{
"meta": {
"title": "ProxMenux Zálohovanie a obnovenie — Prehľad | Úplné zálohovanie a obnovenie hostiteľa pre Proxmox VE",
"description": "ProxMenux Backup & Restore zachytáva úplný stav hostiteľa Proxmox – súborový systém, štruktúrovaný konfiguračný manifest a nainštalované balíky/komponenty – a reprodukuje ho na rovnakom alebo inom hostiteľovi. Zálohovanie a obnova sú samostatné: žiadne externé závislosti a obnovy medzi jadrami sú podporované prostredníctvom filtra bezpečnej podmnožiny zohľadňujúceho smer zmeny verzie a hydratácie nezávislej od jadra.",
"ogTitle": "ProxMenux Zálohovanie a obnovenie — Prehľad",
"ogDescription": "Úplné zálohovanie a obnovenie hostiteľa pre Proxmox VE so štruktúrovaným manifestom, zoznamom balíkov a preinštalátormi komponentov.",
"twitterTitle": "ProxMenux Zálohovanie a obnovenie | ProxMenux",
"twitterDescription": "Úplné zálohovanie a obnovenie hostiteľa pre Proxmox VE so štruktúrovaným manifestom, zoznamom balíkov a preinštalátormi komponentov."
},
"header": {
"title": "Zálohovanie a obnovenie",
"description": "Zálohovanie a obnovenie úplného hostiteľa pre Proxmox VE. Zachytáva súborový systém, konfiguráciu a nainštalované komponenty do jedného archívu a reprodukuje hostiteľa v rovnakej alebo inej inštalácii Proxmox bez externých závislostí.",
"section": "Zálohovanie a obnovenie"
},
"intro": {
"title": "Čo to je, v jednom odseku",
"body": "Záloha ProxMenux zachytáva úplný stav hostiteľa Proxmox: <strong>súborový systém</strong>, teda príslušné adresáre v <code>/etc</code>, <code>/root</code> a <code>/var/lib/pve-cluster</code> spolu s voliteľnými vlastnými cestami; <strong>štruktúrovaný manifest</strong> vo formáte JSON s detegovaným hardvérom, parametrami jadra, konfiguráciou siete, stavom ZFS, používateľmi a záznamami cron; a <strong>inventár aplikácií</strong> s balíkmi označenými v APT ako manuálne nainštalované a komponentmi nainštalovanými cez ProxMenux vrátane presných verzií. Všetky tri podporované ciele – lokálny archív, Proxmox Backup Server (odporúčaný) a Borg – dostávajú rovnaký samostatný obsah. Z každého možno obnoviť cieľového hostiteľa bez toho, aby bol zdrojový hostiteľ počas obnovy dostupný."
},
"video": {
"heading": "Videonávod",
"intro": "Uprednostňujete sledovanie zálohovania a obnovenia v akcii pred jeho konfiguráciou? Tento návod obsahuje úplné demo funkcie v ProxMenux.",
"title": "ProxMenux — Návod na zálohovanie a obnovenie",
"caption": "Externé video na YouTube. Prehráva sa v režime ochrany osobných údajov (žiadne súbory cookie, kým nestlačíte tlačidlo prehrávania)."
},
"whatItIsNot": {
"heading": "Čo to nie je",
"intro": "Táto časť sa venuje zálohovaniu a obnove <strong>hostiteľa</strong>: samotnej inštalácie Proxmoxu, nie aplikácií a virtuálnych systémov, ktoré na nej bežia.",
"items": [
"<strong>Nejde o nástroj na zálohovanie VM/CT.</strong> Táto funkcia nezachytáva disky ani stav RAM virtuálnych systémov; na to slúži <code>vzdump</code>. Ich <strong>konfiguračné súbory</strong> (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> a <code>lxc/*.conf</code>) sa <strong>však zálohujú</strong>. Po obnove sa inventár znovu zobrazí a disky možno obnoviť alebo pripojiť z existujúcej zálohy v PBS či na lokálnom úložisku.",
"<strong>Nejde o operáciu pre celý klaster.</strong> Každý uzol zálohuje sám seba. Členstvo v klastri sa zachytáva v <code>/etc/pve</code>, aby sa obnovený uzol mohol opäť pridať do klastra. Obnova celého klastra však vyžaduje koordináciu jednotlivých uzlov.",
"<strong>Nejde o úplný obraz disku.</strong> Binárne súbory jadra, initramfs ani zavádzacia partícia sa nezálohujú. Pri obnove ProxMenux využíva zavádzacie súbory cieľového hostiteľa, automaticky vytvorené pomocou <code>update-initramfs</code> a nástroja zavádzača, a inštaluje ovládače zodpovedajúce jadru spustenému na cieľovom hostiteľovi."
]
},
"threePillars": {
"heading": "Tri piliere zálohovania",
"intro": "Archív ProxMenux je štruktúrovaný okolo troch samostatných blokov údajov. Obnova používa všetky tri spolu na reprodukciu zdrojového hostiteľa na cieli, ktorý nemusí mať dokonca nainštalované rovnaké jadro.",
"diagramCaption": "Každá záloha obsahuje rovnaké tri bloky údajov bez ohľadu na cieľ. Obnova používa všetky tri: rootfs na uloženie súborov, manifest na zistenie odchýlok a rozdielov medzi verziami jadra a inventár aplikácií na opätovnú inštaláciu balíkov a komponentov pre vlastné jadro cieľa.",
"pillar1Label": "Súborový systém",
"pillar1Detail": "rootfs/\n(rsync z /etc,\n/etc/systemd/network,\n/root, plus\nsnímka sqlite3\nz /var/lib/pve-cluster,\n+ voliteľné cesty)",
"pillar2Label": "Manifest",
"pillar2Detail": "manifest.json\n(hardvér, parametre\njadra, sieť,\nZFS, používatelia, cron,\npooly ZFS, úložisko)",
"pillar3Label": "Aplikácie",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(manuálne balíky APT + inštalátory\nProxMenux s verziami)"
},
"restoreIsUniversal": {
"heading": "Obnova reprodukuje hostiteľa zdroja, nie archív",
"body": "Obnova zálohy ProxMenux neznamená len rozbalenie súborového systému. Postup obnovy prečíta manifest, aby zistil rozdiely medzi zdrojom a cieľom (hardvér, premenovanie sieťových kariet, verziu jadra, identitu poolu ZFS), obnoví súborový systém a potom spustí príslušný inštalátor komponentu pre každú službu nainštalovanú v zdroji (ovládač NVIDIA, Coral TPU, nástroje GPU AMD a Intel). Každý inštalátor sa spúšťa pre <strong>aktuálne jadro cieľa</strong>, takže obnovený hostiteľ nezávisí od prítomnosti zdrojového jadra. Ak je jadro cieľa novšie než jadro zálohy, fáza <strong>hydratácie</strong> nezávislá od jadra zlúči vlastné nastavenia používateľa (tokeny IOMMU, ID zariadení VFIO, osobitné úpravy, kľúče GRUB) s novou zavádzacou konfiguráciou cieľa bez doslovného kopírovania súborov viazaných na jadro."
},
"twoInterfaces": {
"heading": "Dve rozhrania, jeden backend",
"intro": "Každý krok pracovného postupu zálohovania a obnovy je dostupný z dvoch vstupných bodov. Oba volajú rovnakú knižnicu shellu, vytvárajú identické archívy a čítajú rovnaký register úloh.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "menu → Nástroje →\nZálohovanie / obnovenie hostiteľa\n\nDialógový tok,\nSSH priateľský, skriptovateľný\nna použitie bez dozoru.",
"webLabel": "ProxMenux Monitor (Web UI)",
"webDetail": "Karta Backups vo\nwebovom rozhraní Monitor.\n\nObnova jedným kliknutím,\npriebežný výpis záznamov,\nprepojenie s upozorneniami\na zobrazením rozdielov rollbacku."
},
"whereNext": {
"heading": "Kam ísť odtiaľto",
"intro": "Každá podsekcia nižšie podrobne pokrýva jeden aspekt pracovného postupu. Začnite s <em>Ako to funguje</em>, ak je cieľom pochopiť, čo archív obsahuje a prečo. Prejdite na <em>Ciele</em> a nakonfigurujte cieľ pre kópiu. Prečítajte si <em>Obnovovanie</em> a <em>Obnova medzi jadrami</em> pre stranu obnovy.",
"items": [
{
"label": "Ako to funguje",
"href": "/docs/backup-restore/how-it-works",
"tail": "— podrobne tri bloky údajov (rootfs, manifest, aplikácie) s kolektormi, ktoré ich vytvárajú, a formátom každého súboru."
},
{
"label": "Destinácie",
"href": "/docs/backup-restore/destinations",
"tail": "— porovnanie lokálneho úložiska, Proxmox Backup Server (odporúča sa) a Borg a ako nakonfigurovať každý z nich."
},
{
"label": "Vytváranie záloh",
"href": "/docs/backup-restore/creating-backups",
"tail": "— jednorazové zálohy, predvolený profil cesty, pridávanie vlastných ciest, šifrovanie pre PBS."
},
{
"label": "Plánované úlohy",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": "— nové úlohy verzus pripojenie k existujúcej úlohe PVE vzdump, formáty plánovania, modálny detail úlohy."
},
{
"label": "Obnova",
"href": "/docs/backup-restore/restoring",
"tail": "– tri akcie s archívom (zobrazenie, stiahnutie, obnovenie), úplná a vlastná obnova, dispečer po spustení a prečo záleží na posledných desiatich minútach."
},
{
"label": "Obnova medzi jadrami",
"href": "/docs/backup-restore/cross-kernel",
"tail": " — správanie zohľadňujúce smer zmeny verzie pri odlišnom jadre cieľa a zálohy, filter bezpečnej podmnožiny a štyri fázy hydratácie."
}
]
}
}
web/messages/sk/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/sk/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Plánované úlohy — časovače, režim attach a uchovávanie záloh | ProxMenux",
"description": "Plánované úlohy zálohovania hostiteľa ProxMenux. Dva režimy vytvorenia (vlastný časovač systemd alebo pripojenie k existujúcej úlohe vzdump PVE), pravidlá uchovávania pre jednotlivé úlohy cez proxmox-backup-client, Borg alebo lokálne čistenie, súbory v /var/lib/proxmenux/backup-jobs a spúšťací skript vytvárajúci rovnaké archívy ako interaktívny postup.",
"ogTitle": "Zálohovanie ProxMenux — plánované úlohy",
"ogDescription": "Plánované zálohy hostiteľa bez obsluhy s režimom pripojenia, pravidlami uchovávania a rovnakými tromi cieľmi ako interaktívny postup.",
"twitterTitle": "Plánované úlohy | ProxMenux",
"twitterDescription": "Plánované úlohy zálohovania hostiteľa bez obsluhy s režimom pripojenia a uchovávaním."
},
"header": {
"title": "Plánované úlohy",
"description": "Úlohy zálohovania hostiteľa bez obsluhy. Dva modely vytvorenia: nová nezávislá úloha s vlastným plánom alebo úloha pripojená k existujúcej úlohe vzdump PVE, z ktorej preberá plán a pravidlá uchovávania. Oba modely vytvárajú rovnaké archívy ako interaktívny postup.",
"section": "Záloha a obnova"
},
"intro": {
"title": "Dva modely plánovaných úloh",
"body": "Plánovanú úlohu možno vytvoriť podľa jedného z dvoch modelov:",
"modelsList": [
"<strong>Nová nezávislá úloha</strong> — ProxMenux nastaví vlastný plán pomocou samostatného časovača systemd, nezávisle od ostatných úloh na hostiteľovi. Podporuje všetky tri ciele: lokálny, PBS a Borg.",
"<strong>Pripojenie k existujúcej úlohe vzdump PVE</strong> — úloha nemá vlastný plán; spúšťa sa automaticky pri nadradenej úlohe vzdump PVE, ktorá už zálohuje VM a LXC na hostiteľovi. Preberá jej plán a pravidlá uchovávania. Podporuje lokálny cieľ a PBS (Borg nie je podporovaný, pretože PVE preň nemá natívny plánovač)."
]
},
"attachBadge": {
"title": "Režim pripojenia — odporúčaný, ak už existuje úloha vzdump PVE",
"body": "Ak už existuje úloha vzdump PVE pre VM a LXC na uzle, pripojená záloha hostiteľa sa vykoná po zálohe hostí v <strong>rovnakom zálohovacom cykle</strong>. Pri obnove pochádzajú konfigurácie hostí zo zálohy hostiteľa (v <code>/etc/pve</code>) a ich disky zo záloh vzdump daného cyklu. To pomáha koordinovať obnovu celého uzla, ale nejde o atómovú snímku: zmeny počas cyklu môžu zanechať rozdiely medzi konfiguráciou hostiteľa a stavom diskov hostí."
},
"frequencyBadge": {
"title": "Odporúčaná frekvencia",
"body": "Ak chcete maximalizovať kompatibilitu zálohy hostiteľa s budúcou obnovou, zálohujte často. Čím bližšie je záloha aktuálnemu stavu hostiteľa, tým menej rozdielov v konfigurácii, balíkoch a komponentoch musí obnova zosúladiť."
},
"modes": {
"heading": "Dva režimy",
"rows": [
{
"mode": "Nová plánovaná úloha",
"backends": "Miestne, PBS, Borg",
"schedule": "Vlastný výraz <code>OnCalendar</code> (syntax kalendára systemd, napr. <code>daily</code> alebo <code>Mon..Fri 03:00</code>).",
"retention": "Zadáva sa samostatne: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Použije spúšťací skript po každej úspešnej zálohe."
},
{
"mode": "Pripojiť k úlohe vzdump PVE",
"backends": "Local, PBS (Borg nemá plánovač na strane PVE)",
"schedule": "Preberá sa z nadradenej úlohy PVE. Na strane ProxMenux sa neinštaluje žiadny časovač systemd.",
"retention": "Preberá sa z konfigurácie <code>prune-backups</code> nadradenej úlohy (pomocou <code>hb_pve_prune_to_keep_env</code> mapovanej jedna k jednej na premenné <code>KEEP_*</code> spúšťacieho skriptu)."
}
]
},
"attachDetail": {
"heading": "Ako funguje režim pripojenia",
"intro": "PVE zapisuje úlohy <code>vzdump</code> do <code>/etc/pve/jobs.cfg</code> — jednu sekciu pre každú úlohu s úložiskom záloh VM a LXC. Režim pripojenia vyžaduje backend podporovaný ProxMenux (lokálny alebo PBS). Záloha hostiteľa sa spustí cez hook job-end po dokončení úlohy zálohovania hostí.",
"steps": [
{
"step": "1",
"detail": "Počas vytvárania úlohy ProxMenux uvádza kompatibilné rodičovské PVE úlohy prostredníctvom <code>hb_pve_list_vzdump_jobs_for_backend</code>. Užívateľ si vyberie jednu."
},
{
"step": "2",
"detail": "Súbor <code>.env</code> úlohy sa zapíše s <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> a prevzatými hodnotami <code>KEEP_*</code>; časovač systemd sa nevytvorí."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> zaregistruje hook v <code>/etc/vzdump.conf</code>. Vo fáze job-end ľubovoľnej úlohy vzdump porovná prijaté <code>$STOREID</code> s <code>PVE_STORAGE</code> každej povolenej pripojenej úlohy a pri zhode zavolá spúšťací skript. Zhoda sa určuje podľa úložiska, nie podľa ID vybranej nadradenej úlohy."
},
{
"step": "4",
"detail": "Archív sa uloží do rovnakého úložiska ako zálohy vzdump: <code>path/dump/</code> pri lokálnom cieli alebo repozitár PBS nastavený v úložisku PVE."
}
],
"outroBody": "Režim pripojenia nemá vlastný časovač. Vypnutie alebo odstránenie vybranej nadradenej úlohy PVE zastaví jej spúšťanie, ale iná úloha vzdump s rovnakým úložiskom môže pripojenú zálohu hostiteľa stále spustiť. Ak tomu chcete zabrániť, vypnite alebo odstráňte samotnú úlohu ProxMenux. Pri vypnutí zostane záznam na disku a možno ho neskôr povoliť alebo znovu pripojiť."
},
"storageLayout": {
"heading": "Súbory, ktoré tvoria prácu",
"intro": "Každá plánovaná úloha je plne popísaná tromi alebo štyrmi súbormi na disku. Čítanie im dáva plnú konfiguráciu úlohy bez spoliehania sa na rozhranie.",
"rows": [
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Backend, ID zálohy alebo cieľ, plán (nový režim) alebo nadradená úloha PVE (režim pripojenia), príznak povolenia, hodnoty uchovávania <code>KEEP_*</code> a odkazy na prihlasovacie údaje."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "Jedna absolútna cesta na riadok — výber odvodený z profilu a uložený pri vytvorení úlohy. Po úprave súboru sa pri ďalšom spustení časovačom použije nový výber."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "Iba nový režim. Služba vyvoláva <code>run_scheduled_backup.sh JOB_ID</code>. Časovač ho naplánuje s <code>Persistent=true</code> (zmeškané spustenia sa vykonajú pri ďalšom štarte) a malým <code>RandomizedDelaySec=120</code> rozložiť zaťaženie, keď viaceré úlohy zdieľa rovnaký OnCalendar výraz."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Iba režim pripojenia. Raz ho nainštaluje <code>hb_install_vzdump_hook</code>; porovnáva <code>PVE_STORAGE</code> každej pripojenej úlohy s <code>$STOREID</code>, ktoré PVE odovzdáva hooku."
}
]
},
"runner": {
"heading": "Čo úloha vykoná pri spustení",
"intro": "Každá práca, či je nový model alebo pripojený, má rovnakú trojstupňovú sekvenciu:",
"steps": [
"<strong>Pripraví zálohu.</strong> Načíta konfiguráciu úlohy (cieľ, profil, cesty) a zostaví strom archívu rovnako ako interaktívny postup. Výsledkom je rovnaký archív, aký by vytvorila manuálna záloha s týmito nastaveniami.",
"<strong>Zapíše do cieľa.</strong> Odošle alebo zapíše archív do nastaveného cieľa — lokálny súbor <code>.tar.zst</code>, záloha PBS alebo archív Borg — s presne rovnakými nástrojmi a prihlasovacími údajmi ako manuálna záloha do rovnakého cieľa.",
"<strong>Použije pravidlá uchovávania.</strong> Odstráni staré zálohy z cieľa a ponechá počty nastavené v úlohe cez <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code>. Čistenie vykonáva príslušný backend: PBS používa svoje pravidlá uchovávania, Borg spustí <code>borg prune</code> a pri lokálnom cieli ProxMenux odstráni súbory mimo rozsahu <code>keep-last</code>."
]
},
"management": {
"heading": "Správa úloh",
"intro": "Menu rozvrhu (Scripts TUI) a záložka Monitor Backup odhaľujú rovnaké akcie na akejkoľvek práci.",
"rows": [
{
"action": "Spustiť teraz",
"detail": "Okamžite zavolá spúšťací skript bez čakania na časovač alebo hook vzdump. Umožní overiť konfiguráciu úlohy bez čakania na ďalšie plánované spustenie."
},
{
"action": "Povoliť / zakázať",
"detail": "Nový režim: časovač sa ovláda cez <code>systemctl enable/disable --now</code>. Režim pripojenia: zmení príznak <code>ENABLED</code> v súbore env úlohy — hook ho zohľadní pri ďalšom spustení PVE."
},
{
"action": "Upraviť",
"detail": "Znovu otvorí destináciu, rozvrh, profil a retenčný postup a prepíše pracovné súbory. Zachováva ID práce."
},
{
"action": "Odstrániť",
"detail": "Odstráni súbor env úlohy, súbor ciest, časovač a službu systemd (nový režim) a vypne pripojenie k hooku (režim pripojenia). Existujúce archívy v cieli nemení."
},
{
"action": "Zobraziť záznam",
"detail": "Priebežne zobrazuje <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — jeden protokolový súbor na beh. Spúšťací skript tiež vydáva kompaktný stavový riadok na journald pod systemd služby."
}
]
},
"notifications": {
"heading": "Oznámenia",
"body": "Každé plánované spustenie vyvolá rovnaké udalosti <code>hb_notify_lifecycle</code> ako interaktívny postup (<code>start</code>, <code>complete</code>, <code>fail</code>). Ak sú v Monitore nastavené kanály upozornení, úlohy bez obsluhy oznámia výsledky rovnako ako manuálne zálohy — používateľ nemusí kontrolovať záznam, aby zistil úspech úlohy."
},
"whereNext": {
"heading": "Kam ísť ďalej",
"items": [
{
"label": "Vytváranie záloh",
"href": "/docs/backup-restore/creating-backups",
"tail": " — interaktívny postup, ktorý zdieľa backend s plánovačom."
},
{
"label": "Ciele",
"href": "/docs/backup-restore/destinations",
"tail": " — konfigurácia jednotlivých backendov používaná interaktívnym postupom aj plánovačom."
},
{
"label": "Obnovenie",
"href": "/docs/backup-restore/restoring",
"tail": " — postup používajúci zálohy vytvorené úlohami."
}
]
}
}
web/messages/sv/docs/backup-restore/creating-backups.json
+220
View File
@@ -0,0 +1,220 @@
{
"meta": {
"title": "Skapa säkerhetskopior — interaktivt säkerhetskopieringsflöde | ProxMenux",
"description": "Det interaktiva säkerhetskopieringsflödet i ProxMenux: två ingångspunkter (Scripts TUI-meny och Monitors webbgränssnitt), tre destinationer, två profillägen, ett gemensamt steg för tillfällig förberedelse och en bekräftelsedialog. Sidan beskriver matrisen med sex alternativ, standardprofilen och den anpassade profilen samt vad användaren ser från valet av säkerhetskopia tills arkivet sparas på destinationen.",
"ogTitle": "ProxMenux Backup - skapa backup",
"ogDescription": "Det interaktiva säkerhetskopieringsflödet med tre destinationer, två profiler och ett gemensamt steg för tillfällig förberedelse.",
"twitterTitle": "Skapa backups | ProxMenux",
"twitterDescription": "Interaktivt backupflöde med tre destinationer och två profillägen."
},
"header": {
"title": "Skapa backups",
"description": "Det interaktiva säkerhetskopieringsflödet: välj en destination och en profil, granska bekräftelsen och följ hur arkivet sparas. De två ingångspunkterna använder samma backend och skapar identiska arkiv.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "Två ingångspunkter, identisk funktionalitet",
"body": "Scripts TUI och Monitors webbgränssnitt erbjuder <strong>exakt samma funktioner</strong>. Varje säkerhetskopia — manuell eller schemalagd — går genom samma valmatris (tre destinationer × två profiler) och anropar samma backendfunktion per cell (<code>_bk_pbs</code>, <code>_bk_borg</code> eller <code>_bk_local</code>). Arkiven som skapas via de två ingångspunkterna är identiska. Valet beror på vad man föredrar: TUI passar för SSH och skript; Monitor erbjuder musklick tillsammans med vyerna för aviseringar och löpande loggutdata."
},
"entryPoints": {
"heading": "De två ingångspunkterna",
"rows": [
{
"entry": "ProxMenux Scripts (TUI)",
"path": "menu → Utilities → Host Config Backup",
"detail": "Dialogbaserat flöde, SSH-vänligt. Huvudmenyn presenterar de sex alternativen direkt. Använder <code>backup_menu</code> i <code>backup_host.sh</code>."
},
{
"entry": "ProxMenux Monitor (Webb UI)",
"path": "Backups tab → Create backup",
"detail": "Guidebaserat flöde. Samma sex alternativ visas i ett formulär med två steg (destination → profil). Samma backendfunktioner anropas via Flask-API:et."
}
]
},
"modes": {
"heading": "Manuella och schemalagda säkerhetskopior",
"body": "Säkerhetskopior kan produceras i två lägen: <strong>manuellt</strong> (det interaktiva flöde som beskrivs på denna sida - användaren plockar en destination och en profil från en meny och följer hur arkivet sparas) eller <strong>schemalagt</strong> (ett obevakat jobb som körs på en timer i cron-stil och tillämpar bevarandeinställningarna för jobbet). Båda lägena stöder samma tre destinationer och samma två profiler, och båda är tillgängliga från båda ingångspunkterna - Scripts TUI-meny och Monitors Backups-flik. Planerade jobb använder samma backendfunktioner som manuellt flöde genom <code>run_scheduled_backup.sh</code>; de arkiv som produceras är oskiljbara.",
"seeAlso": "Sidan schemalagda jobb täcker hela flödet, inklusive hur man skapar ett jobb, bifogar det till en befintlig PVE vzdump timer och konfigurerar retentionsvärdena.",
"monitorAlt": "ProxMenux Monitor Backups-fliken som visar den nya schemalagda backup-dialogen med destination, profil, schema och fält för bevarande.",
"monitorCaption": "Schemalagd säkerhetskopia — ProxMenux Monitor. Samma guidedialog som skapar en manuell säkerhetskopia har fält för schema och bevarande längst ner för obevakad körning."
},
"matrix": {
"heading": "Matrisen med sex alternativ",
"intro": "Valet avgör både vilken backend som körs och vilken strategi för sökvägsval som används. Se sidorna för respektive destination för konfigurationsdetaljer om varje cell.",
"rows": [
{
"combo": "1",
"destination": "PBS",
"profile": "Standard",
"action": "Laddar upp standardprofilen och de beständiga tilläggen till ett konfigurerat PBS-arkiv."
},
{
"combo": "2",
"destination": "Borg",
"profile": "Standard",
"action": "Skapar ett arkiv med standardprofilen plus beständiga tillägg i det valda Borg-förvaret."
},
{
"combo": "3",
"destination": "Lokal",
"profile": "Standard",
"action": "Skriver ett <code>.tar.zst</code>-arkiv med standardprofilen plus beständiga tillägg till det konfigurerade lokala målet."
},
{
"combo": "4",
"destination": "PBS",
"profile": "Anpassad",
"action": "Öppnar sökvägsväljaren före uppladdningen till PBS; användaren markerar sökvägar och kan lägga till nya."
},
{
"combo": "5",
"destination": "Borg",
"profile": "Anpassad",
"action": "Öppnar sökvägsväljaren innan Borg-arkivet skapas."
},
{
"combo": "6",
"destination": "Lokal",
"profile": "Anpassad",
"action": "Öppnar sökvägsväljaren innan det lokala <code>.tar.zst</code>-arkivet skrivs."
}
]
},
"profiles": {
"heading": "Standard vs anpassad profil",
"defaultTitle": "Standardprofil",
"defaultBody": "Standardprofilen är den kurerade listan från <code>hb_default_profile_paths</code> (dokumenterad i <em>Hur det fungerar</em> under <em>Sökvägskategorier</em>) plus varje post i den filen med beständiga tillägg <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. Användaren bekräftar destinationen och krypteringsalternativen och backupen fortsätter utan ytterligare sökvägsval.",
"customTitle": "Anpassad profil",
"customBody": "Den anpassade profilen öppnar en checklista med alla sökvägar i standardprofilen (omarkerade) och alla beständiga tillägg (förmarkerade, med prefixet <code>[+]</code>). Användaren markerar sökvägarna för denna körning och kan trycka på <em>Lägg till anpassad sökväg</em> för att lägga till en ny absolut sökväg. Sökvägar som läggs till här sparas i <code>backup-extra-paths.txt</code> så att framtida säkerhetskopior tar med dem automatiskt. Att avmarkera ett beständigt tillägg utesluter det från denna körning men tar inte bort det ur filen — borttagning görs separat via <em>Hantera anpassade sökvägar</em>, utanför säkerhetskopieringsflödet.",
"customPickerAlt": "Checklista för anpassad profil med standardprofilens sökvägar (omarkerade) och beständiga tillägg (förmarkerade med prefixet [+]), samt knappar för att lägga till en sökväg eller bekräfta valet.",
"customPickerCaption": "Anpassad profil — sökvägsväljaren. Standardprofilens sökvägar är omarkerade; beständiga tillägg är förmarkerade med prefixet [+]. Användaren markerar sökvägarna för denna körning.",
"manageCustomAlt": "Menyn för att hantera anpassade sökvägar med listan över beständiga tillägg och alternativ för att lägga till, ta bort eller redigera dem.",
"manageCustomCaption": "Hantera anpassade sökvägar — platsen där beständiga tillägg läggs till eller tas bort. Varje sökväg här ingår automatiskt i säkerhetskopior med standardprofilen utan att den anpassade sökvägsväljaren behöver öppnas."
},
"commonPipeline": {
"heading": "Vad som går oavsett destination",
"intro": "När profilen har fastställts kör varje backend samma tillfälliga förberedelsesteg innan den går vidare till sin egen uppladdningsmetod. <code>hb_prepare_staging</code> bygger arkivträdet i <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> och fyller vart och ett av de tre datablocken.",
"steps": [
{
"step": "1",
"name": "Sammanställning av rootfs",
"detail": "Kör <code>rsync -a</code> för varje vald sökväg till <code>staging_root/rootfs/</code>. Databasen pmxcfs i <code>/var/lib/pve-cluster/config.db</code> sparas separat via <code>sqlite3 .backup</code> för att få en konsekvent ögonblicksbild utan att stoppa klustret; hjälpfilerna <code>.db-wal</code> / <code>.db-shm</code> utesluts från rsync. Om <code>sqlite3</code> saknas sparas i stället en fil <code>config.db.raw-fallback</code>, som återställningen använder som databas vid importen. Flyktiga undersökvägar (bash-historik, cache, papperskorg) utesluts från <code>/root/</code>. Sökvägar som saknas i källan registreras i <code>metadata/missing_paths.txt</code> utan att säkerhetskopieringen avbryts."
},
{
"step": "2",
"name": "Manifestgenerering",
"detail": "<code>build_manifest.sh</code> samordnar de sex insamlingsmodulerna och skriver <code>manifest.json</code> i roten av den tillfälliga katalogen. Om en modul misslyckas får det berörda avsnittet ett dokumenterat tomt standardvärde; manifestet är fortfarande giltigt."
},
{
"step": "3",
"name": "Paketinventering",
"detail": "<code>apt-mark showmanual</code> fångas verbatim i <code>metadata/packages.manual.list</code>. Komponentstatus är redan inne i det återställda rootfs (<code>components_status.json</code>) eftersom <code>/usr/local/share/proxmenux/</code> är en del av standardprofilen."
},
{
"step": "4",
"name": "Information om körningen",
"detail": "<code>metadata/run_info.env</code> registrerar säkerhetskopieringens identitet - värdnamn, tidsstämpel, kärnversion - som används av återställningens kompatibilitetskontroll för att bestämma riktningen mellan kärnversionerna."
},
{
"step": "5",
"name": "Avisering (start)",
"detail": "<code>hb_notify_lifecycle \"start\"</code> utlöses. Om aviseringar är konfigurerade i Monitor skickas händelsen <em>Säkerhetskopiering av värden startad</em> till användaren. Inget skickas om inga kanaler har konfigurerats."
}
]
},
"included": {
"heading": "Vad går in och vad stannar ut",
"intro": "Varje sökväg i den fastställda profilen (standard + beständiga tillägg + val i anpassat läge) kopieras med <code>rsync -aAXH --numeric-ids</code>. En delad uteslutningslista gäller för varje sökväg, och två kataloger har ytterligare sökvägsspecifika uteslutningar.",
"globalTitle": "Globala uteslutningar (tillämpas varje väg)",
"globalItems": [
"<code>images/</code> - bilddumpar.",
"<code>dump/</code> — utdata från vzdump.",
"<code>tmp/</code> - tillfälliga filer.",
"<code>*.log</code> loggfiler."
],
"rootTitle": "<code>/root/</code>-uteslutningar",
"rootBody": "<code>/root/</code> ingår i standardprofilen så att användarens skript och konfiguration sparas i arkivet. Flyktiga undersökvägar utesluts:",
"rootItems": [
"<code>.bash_history</code>",
"<code>.cache/</code>",
"<code>tmp/</code>",
"<code>.local/share/Trash/</code>"
],
"proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code>-uteslutningar",
"proxmenuxBody": "Denna katalog skickar användarstatus endast - <code>components_status.json</code>, preferenser, post-install cache. Kod som destinationen redan har från sin egen ProxMenux-installation utesluts så att en återställning inte överskriver målets nuvarande binärer med äldre:",
"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": "Vägar utanför profilen",
"notInProfileBody": "Allt som inte anges i <code>hb_default_profile_paths</code> och inte läggs till som en anpassad eller ihållande extra är inte en del av backupen. Anmärkningsvärda exempel:",
"notInProfileItems": [
"<strong>VM- och LXC-diskar</strong> - hanteras av <code>vzdump</code>, inte av denna funktion. Gästkonfigurationsfiler under <code>/etc/pve/nodes/*/qemu-server/*.conf</code> och <code>lxc/*.conf</code> fångas (de lever under <code>/etc/pve</code>) så återställningen reproducerar inventeringen; diskarna själva är återanslutna från en befintlig vzdump / PBS backup.",
"<strong><code>/boot</code> och <code>/boot/efi</code></strong> - kärnbinärer, initramfs och UEFI ESP-partitionen regenereras av målets egen <code>update-initramfs</code>, <code>update-grub</code> eller <code>proxmox-boot-tool refresh</code> efter återställningen. Starthanteraren kopieras aldrig ordagrant.",
"<strong>Filsystem för kärnan och systemets körning</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> och <code>/run</code> är pseudofilsystem som skapas av kärnan och udev; de lagras inte beständigt någonstans.",
"<strong>Paketbinärer under <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> - ominstallerad av målets APT från <code>packages.manual.list</code>.",
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> - per-värd runtime tillstånd, inte återställd.",
"<strong><code>/home/USER</code></strong> - inte i standardprofilen. Lägg till det som en anpassad väg när ett system bär hemkataloger som måste överleva en återställning."
],
"customPathsTitle": "Hur anpassade vägar hanteras",
"customPathsBody": "En anpassad väg som läggs till i anpassat läge eller kvarstår i <code>backup-extra-paths.txt</code> går igenom samma <code>rsync</code>-pipeline som standardprofilvägar. Globala uteslutningar gäller. Om den anpassade vägen råkar vara under <code>/root/</code> eller <code>/usr/local/share/proxmenux/</code> gäller fortfarande de vägspecifika uteslutningarna ovan. Varje arkiverad väg - standard eller anpassad - registreras i <code>metadata/paths_archived.txt</code>. Sökvägar som inte finns på källan registreras i <code>metadata/missing_paths.txt</code> utan att stoppa backupen."
},
"archiveStructure": {
"heading": "Arkivstruktur",
"intro": "Den tillfälliga katalog som varje backend skapar har samma struktur oavsett destination. Tar-arkivet, PBS-arkivet <code>.pxar</code> eller Borg-arkivet lagrar detta träd oförändrat.",
"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": "Sammanfattning för bekräftelse",
"body": "Innan backend skriver något till destinationen visar ProxMenux en sammanfattande dialog med destinationen, backup-ID eller arkivnamn, krypteringstillstånd och listan över vägar som kopieras. Avbokning här avbryter backupen rent - staging katalogen tas bort av <code>trap</code> kroken på backend funktionen och ingen partiell data når destinationen."
},
"writing": {
"heading": "Skriva till destinationen",
"intro": "Efter bekräftelsen kör varje backend sitt eget skrivsteg. Sidorna för destinationerna beskriver hur det fungerar; de gemensamma delarna är loggen, sidofilen och aviseringen om slutförande.",
"rows": [
{
"topic": "Loggfil",
"detail": "Varje backend skriver sin fullständiga utdata till <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> och, på misslyckande, erbjuder att öppna den i en rullande dialog. Loggsökvägen visas i sammanfattningen endast när filen har innehåll."
},
{
"topic": "Sidecar (endast lokal)",
"detail": "<code>hb_write_archive_sidecar</code> släpper en <code>*.proxmenux.json</code> bredvid det lokala arkivet så att Monitor identifierar det som en ProxMenux-värdbackup även efter flytt eller namnbyte."
},
{
"topic": "Avisering (slutförd/misslyckad)",
"detail": "<code>hb_notify_lifecycle \"complete\"</code> eller <code>\"fail\"</code> utlöses med varaktighet, arkivstorlek och — vid fel — den sista loggraden som ser ut att beskriva ett fel."
}
]
},
"finishedScreens": {
"heading": "Vad en färdig backup ser ut",
"intro": "Samma slutförandehändelse uppträder av båda ingångspunkterna. TUI skriver ett sammanfattande block till terminalen; Monitor's Backups-fliken visar körningen i arkivlistan med storlek, varaktighet och statusmärken.",
"scriptsAlt": "ProxMenux Scripts TUI visar en färdig värd backup — destination, backup ID, snapshot väg, data storlek, varaktighet och kryptering tillstånd.",
"scriptsCaption": "Avslutad backup - ProxMenux Scripts (TUI). Slutförande blocket trycker destinationen, backup-ID, vilket resulterar i snapshot eller arkivnamn, datastorlek, varaktighet och krypteringstillstånd.",
"monitorAlt": "ProxMenux Monitor Backups-fliken som visar en färdig värdbackuppost med storlek, varaktighet, metodmärke och krypteringsindikator.",
"monitorCaption": "Avslutad backup - ProxMenux Monitor Backups-fliken. Den nya säkerhetskopian visas i arkivlistan med destinationsmetodens märke, storlek, varaktighet och - när det är tillämpligt - krypteringslåsindikatorn."
},
"whereNext": {
"heading": "Nästa steg",
"items": [
{
"label": "Destinationer",
"href": "/docs/backup-restore/destinations",
"tail": " - konfigurationsdetaljer för Local, PBS och Borg."
},
{
"label": "Planerade jobb",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": " - kör samma backup obevakad på ett schema istället för interaktivt."
},
{
"label": "Återställande",
"href": "/docs/backup-restore/restoring",
"tail": " — flödet som förbrukar vad denna sida producerar."
}
]
}
}
web/messages/sv/docs/backup-restore/cross-kernel.json
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Återställning mellan kärnversioner — riktning, säkert urval och komplettering | ProxMenux",
"description": "Hur ProxMenux återställer en värdbackup på ett mål som kör en annan stor kärnversion. Dokument hur riktningen av felmatchen detekteras, det säkra subsetfiltret som hoppar över boot-kritiska vägar när målet kör en nyare kärna än backupen, och den fyrfasiga kärnan-agnostiska hydrering som återanvänder användarjustering som IOMMU, VFIO IDs och anpassade cmdline tokens utan att kopiera kernel-tied filer verbatim.",
"ogTitle": "ProxMenux Backup - cross-kernel restaurering och hydrering",
"ogDescription": "Återställning mellan kärnversioner med riktningskontroll, säkert urval och kärnoberoende komplettering.",
"twitterTitle": "Cross-kernel återställning | ProxMenux",
"twitterDescription": "Hur ProxMenux hanterar en återställning när målkärnan skiljer sig från säkerhetskopiorna."
},
"header": {
"title": "Återställning mellan kärnversioner",
"description": "Hur ProxMenux hanterar en återställning när målvärden kör en annan kärna från den som spelas in i backupen - särskilt när målet kör en nyare kärna. Dokument hur skillnaden upptäcks, hur startkritiska vägar som kan bryta målet filtreras, och hur användarens egen konfiguration återanvänds utan att kopiera kärnbundna filer verbatim.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "Varje kärnhopp hanteras annorlunda",
"body": "En Proxmox värd kärna identifieras av en version sträng som <code>6.17.13-2-pve</code>. De två första siffrorna (<strong>6.17</strong> i det här exemplet) definierar den stora versionen: när de ändras kan vissa konfigurationsfiler skrivna för den tidigare kärnan inte vara giltiga på den nya. När återställningen upptäcker att backupen och målet har olika stora kärnversioner, flödesgrenarna baserat på hoppets riktning - oavsett om backupen är äldre eller nyare än målet - eftersom de två fallen har motsatta fellägen. Säkerhetskopior nyare än målet återställs rent as-is (bänk-verifierad över flera kärnhopp). Säkerhetskopior äldre än målet behöver ett filter för att undvika att bryta målets start med konfiguration skriven för en kärna som sedan dess har ändrats."
},
"directionCheck": {
"heading": "Riktningskontroll",
"intro": "Under kompatibilitetskontrollen jämför <code>hb_compat_check</code> kärnan registrerad i backupens manifest mot målets nuvarande kärna (<code>uname -r</code>) och klassificerar återställningen i ett av tre fall, lagrad i den interna variabla <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
"rows": [
{
"direction": "same",
"condition": "Den stora kärnversionen matchar mellan backup och mål.",
"behavior": "Det fullständiga återställningsflödet går oförändrat. Inget extra filter, ingen hydrering, inget särskilt meddelande i UI."
},
{
"direction": "bk_newer",
"condition": "Säkerhetskopians kärna är NYARE än målets (exempel: säkerhetskopian gjordes på 7.0 och målet kör 6.17).",
"behavior": "Hela återställningsflödet körs oförändrat som vid <code>same</code>, utan filter. Rapporterade tester visade ominstallation av drivrutiner för målkärnan, fungerande IOMMU-konfiguration och start av VM:ar med GPU-genomkoppling."
},
{
"direction": "bk_older",
"condition": "Säkerhetskopians kärna är ÄLDRE än målets (exempel: säkerhetskopian gjordes på 6.17 och målet kör 7.0).",
"behavior": "Det säkra filtret och fyrfasens hydrering nedan aktiveras. Återställningen fortsätter - målet reproducerar källan, men startkritiska filer kopieras inte."
}
]
},
"whyBkNewerIsSafe": {
"heading": "Varför en backup med en nyare kärna än målet återställer oförändrad",
"body": "När återställningen går mot ett mål med en <em>äldre</em>-kärna än den som spelas in i backupen, är varje mekanism som återställningen beror på oberoende av kärnversionen. GPU-drivrutininstallatörer och andra PCI-enhetsinstallatörer upptäcker körkärnan med <code>uname -r</code> och sammanställer DKMS mot vad målet har. APT-paketet installerar binärer byggda för målets distribution. IOMMU cmdline tokens som <code>intel_iommu=on</code> är stabila över stora kärnversioner. Backupen bär vägar skrivna under en nyare kärna, men de vägar (modul svartlistor, GRUB standarder, initramfs config) är fortfarande giltig syntax på den äldre - kärnor ignorerar tokens de inte känner igen i stället för att misslyckas. Detta fall är likvärdigt i praktiken med en återställning av samma kärna, och ProxMenux behandlar det som sådant."
},
"safeSubsetFilter": {
"heading": "Det säkra filtret (endast när målkärnan är nyare)",
"intro": "När målkärnan är nyare än backupen, tillägger kompatibilitetskontrollen 16 boot-kritiska vägar från <code>hb_unsafe_paths_cross_version</code> till <code>RS_SKIP_PATHS</code>. Dessa vägar är uteslutna från återställningen eftersom att skriva en version av dem från en äldre kärna över ett mål som kör en nyare har orsakat kärnpaniker i bänkprov. Vägarna täcker fem kategorier:",
"categoryRows": [
{
"category": "Starthanterare",
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
"reason": "GRUB standarder knutna till den tidigare kärnordern, och proxmox-boot-tool tillstånd (cmdline, ESP UUID, krokar) som refererar vägar och identifierare från den äldre installationen."
},
{
"category": "Kernel moduler och boot artefakter",
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
"reason": "Autoload listor som kan referera moduler döpt mellan kärn majors, modulalternativ som kanske inte gäller, initramfs krokar skrivna för den äldre kärnan."
},
{
"category": "Lagring stack och filsystem identitet",
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
"reason": "UUID som kanske inte finns på denna installation, multipath drivrutiner som ändras mellan kärnor, iSCSI parametrar som utvecklas, udev regler som kan binda till icke-existerande delsystem, ZFS tillstånd (<code>zpool.cache</code> + <code>hostid</code>) som kan låsa poolen som främmande."
},
{
"category": "APT-källor",
"paths": "<code>/etc/apt</code>",
"reason": "APT-källor kan utlösa en nedgradering av kritiska paket på nästa uppgradering."
},
{
"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": "Enhetsåsidosättningar och .wants-länkar bundna till en äldre huvudversion av systemd samt inställningsnycklar som kanske inte kan tolkas av en nyare version."
}
],
"outroBody": "Filtret kör FÖRE bekräftelsedialogen så att användaren ser den exakta listan över vägar som kommer att hoppas, kategoriseras av förnuftet. Återställningen fortsätter fortfarande - allt annat (VM-/LXC-konfiguration, nätverk, /etc/pve, användare, cron, ProxMenux tillstånd, paket, drivrutiner, /root) återställs normalt."
},
"hydration": {
"heading": "Kernel-agnostisk hydrering",
"intro": "Filtret utelämnar startkritiska filer, så kompletteringen återställer utvalda inställningar: IOMMU-parametrar, VFIO-ID:n, eget <code>GRUB_TIMEOUT</code> och nvidia-spärrlistor. Den körs när målkärnan är nyare. Cmdline-nycklar på målet bevaras och saknade moduler läggs till. Tillåtna GRUB-värden och användarfiler kan ersätta avvikande målinnehåll. Upprepning med samma indata är idempotent.",
"phaseRows": [
{
"phase": "1a - GRUB väg",
"detail": "För GRUB-värdar (ext4/lvm). <code>_rs_hyd_grub</code> sammanfogar parametrar från säkerhetskopians <code>manifest.kernel_params.cmdline_extra</code> i målets <code>GRUB_CMDLINE_LINUX_DEFAULT</code> och hoppar över nycklar som redan finns. Därefter återställs tillåtna <code>GRUB_*</code>-nycklar (<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>) från säkerhetskopians <code>/etc/default/grub</code> när värdena skiljer sig från målets."
},
{
"phase": "1b — systemd-boot / ZFS",
"detail": "För systemd-boot (vanligen ZFS på roten). <code>_rs_hyd_kernel_cmdline</code> sammanfogar användarparametrar från <code>cmdline_extra</code> i målets <code>/etc/kernel/cmdline</code> och bevarar målets startparametrar <code>root=</code>, <code>boot=</code> och <code>rootflags=</code>."
},
{
"phase": "2 — /etc/modules Sammanslagning",
"detail": "<code>_rs_hyd_modules</code> Lägger till moduler från <code>manifest.kernel_params.modules_loaded_at_boot</code> som finns i den vita listan (<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>) och inte redan närvarande i målets mål <code>/etc/modules</code>."
},
{
"phase": "3 — Kopiera tillåtna filer",
"detail": "<code>_rs_hyd_files</code> kopierar användarskrivna filer från staging rootfs till det levande målet när innehållet skiljer sig. Whitelist täcker VFIO/nvidia/blacklist-filer under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code> och ProxMenux VFIO bind regel + nvidia udev regler under <code>/etc/udev/rules.d</code>. Distro-ägda filer (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) är avsiktligt uteslutna - deras innehåll utvecklas mellan releaser."
},
{
"phase": "4 — Framtvinga ombyggnad efter uppstart",
"detail": "De fyra faserna skriver direkt till det levande målet UTANFÖR den normala återställningsledningen. För att göra de sammanslagna tokens/modulerna/filerna träder i kraft vid nästa start, <code>HB_HYDRATION_APPLIED=1</code> förökar genom <code>plan.env</code> för att <code>apply_pending_restore.sh</code>, som tvingar <code>NEEDS_INITRAMFS=1</code> och <code>NEEDS_GRUB=1</code> Oavsett vad som fanns i appliceringslistan. Post-boot dispatcher regenererar sedan initramfs och uppdaterar bootloader."
}
]
},
"planCommit": {
"heading": "Plan och commit — användaren ser först en förhandsvisning",
"body": "Kompletteringen körs i två lägen. Innan bekräftelsedialogen kör ProxMenux <code>_rs_apply_bk_older_hydration</code> i <code>plan</code>-läge: det beräknar exakt vad som skulle slås samman, fyller <code>RS_HYDRATION_SUMMARY</code> med ett grönt block som listar varje åtgärd och returnerar utan att skriva. Bekräftelsedialogen visar att grönt block tillsammans med den gula listan över uteslutna sökvägar, så användaren ser I FÖRVÄG vad som kommer att återanvändas automatiskt. När användaren bekräftar, ProxMenux kör samma hjälpare i <code>commit</code> läge - samma faser, samma logik, men denna gång varje fas skriver till levande mål. Annullera bekräftelsedialogen lämnar målet orört."
},
"flowDiagram": {
"heading": "Flödet när målkärnan är nyare än backupens",
"intro": "Stegen som läggs till när målkärnan är nyare sitter inuti det normala återställningsflödet. Allt annat - varmt applicera, i väntan på förberedelse, paketinstallation, post-boot dispatcher - körs identiskt till en same-kernel restaurering.",
"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": "Konkreta exempel",
"intro": "Kompletteringen är inte abstrakt - det ger observerbara, korrekta resultat för vanliga scenarier. Två exempel som hydrering hanterar automatiskt:",
"rows": [
{
"scenario": "GPU-genomkoppling (VFIO)",
"detail": "Källan hade <code>intel_iommu=on iommu=pt</code> i cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> i <code>/etc/modules</code>, en <code>/etc/modprobe.d/vfio.conf</code> med <code>options vfio-pci ids=10de:2216</code> och en <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration sammanfogar cmdline-tokens i målets GRUB eller kernel cmdline, appends vfio-modulerna till <code>/etc/modules</code> och kopierar de två användarskrivna modprobe-filerna. På nästa start är IOMMU aktiv, VFIO-moduler laddas, GPU är bunden till vfio-pci och VM kommer upp med genomgående arbete."
},
{
"scenario": "Anpassade GRUB standarder",
"detail": "Källan hade <code>GRUB_TIMEOUT=1</code> och <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration läser båda nycklarna från säkerhetskopieringens <code>/etc/default/grub</code>, ser att de skiljer sig från den färska installationens standarder och skriver om de två linjerna i målets fil (som lämnar allt annat, inklusive <code>GRUB_DISTRIBUTOR</code>, orörd)."
}
]
},
"callout": {
"warningTitle": "Vad kompletteringen utelämnar när målkärnan är nyare",
"warningBody": "Hydration återanvänder endast konfigurationen ProxMenux vet att vara säker över kärnversioner: IOMMU-tokens, VFIO-ID, vitlistade GRUB-nycklar och moduler från en fast lista (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Allt utanför den uppsättningen - anpassade initramfs krokar under <code>/etc/initramfs-tools/hooks/</code>, icke-vitlistade filer under <code>/etc/modprobe.d/</code>, användarskrivna systemd-enhetsåsidosättningar - förblir uteslutna. Anledningen är konkret: dessa filer kan ringa kärnintern gränssnitt (modul API, <code>/sys</code> layout, <code>udev</code> krokar) som ändras mellan stora versioner och tillämpar dem verbatim över den nyare kärnan kan förhindra att målet startar. När exakt reproduktion av startkedjan krävs måste återställningen köras på en värd med samma stora kärnversion som backup."
},
"codeReference": {
"heading": "Där mekanismerna lever",
"intro": "För utvecklare som vill spåra eller förlänga cross-kernel beteende:",
"rows": [
{
"component": "Direktionsdetektering",
"location": "<code>hb_compat_check</code> i <code>lib_host_backup_common.sh</code>. Sätter <code>HB_COMPAT_KERNEL_DIRECTION</code>."
},
{
"component": "Sökvägslista för säkert urval",
"location": "<code>hb_unsafe_paths_cross_version</code> i <code>lib_host_backup_common.sh</code>. Ger <code>path\\treason</code>-linjer som används av både CLI-filtret och Web endpoint <code>/api/host-backups/restore/prepare</code>."
},
{
"component": "Hydrationsfaser",
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> i <code>backup_host.sh</code>. Orkestrerad av <code>_rs_apply_bk_older_hydration</code>."
},
{
"component": "Framtvingad ombyggnad efter uppstart",
"location": "<code>apply_pending_restore.sh</code> läser <code>HB_HYDRATION_APPLIED</code> från <code>plan.env</code> och tvingar <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
},
{
"component": "Web Preview",
"location": "<code>/api/host-backups/restore/prepare</code> i <code>flask_server.py</code>. Läser in hjälpbiblioteket, kör <code>_rs_apply_bk_older_hydration</code> i planläge, returnerar åtgärderna till webbmodalen."
}
]
},
"whereNext": {
"heading": "Vart ska man gå nästa",
"items": [
{
"label": "Återställande",
"href": "/docs/backup-restore/restoring",
"tail": " — Den fullständiga återställningspipeline denna sidas mekanismer ansluter till."
},
{
"label": "Hur det fungerar",
"href": "/docs/backup-restore/how-it-works",
"tail": " — manifestet och insamlingsrutinerna som skapar blocket <code>kernel_params</code> som kompletteringen läser."
}
]
}
}
web/messages/sv/docs/backup-restore/destinations/borg.json
+234
View File
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Borg-mål — förvarstyper, SSH-autentisering, kryptering | ProxMenux",
"description": "Borg-målet lagrar ProxMenux värdsäkerhetskopior i ett lokalt förvar, på en monterad extern disk eller på en fjärrserver via SSH. Beskriver sökordningen för borg-programmet, de fyra inledande SSH-nyckelalternativen, repokey-kryptering, sparade mål och lagringsregler per schemalagt jobb.",
"ogTitle": "ProxMenux Backup - Borg destination",
"ogDescription": "Så lagrar ProxMenux värdsäkerhetskopior i Borg-förvar med SSH-autentisering och repokey-kryptering.",
"twitterTitle": "Borg som mål för säkerhetskopior | ProxMenux",
"twitterDescription": "Lokala, USB och SSH-serverade Borg repositorier för värdbackups."
},
"header": {
"title": "Borg",
"description": "Borg-destinationen skriver värdbackups till ett Borg-förvar. Tre förvarstyper stöds: lokal filsystemväg, monterad extern disk eller fjärrserver via SSH. Chunk-nivå deduplicering över alla arkiv i förvaret och valfri repokey kryptering.",
"section": "Säkerhetskopiering och återställning"
},
"aboutBorg": {
"heading": "Vad Borg är",
"body": "Borg (även stavat BorgBackup) är en öppen källkod som deduplicerar backupverktyg som upprätthålls av Borg Backup community. Det lagrar varje arkiv som en uppsättning av variabel-längd bitar inuti ett arkiv; bitar delas över arkiv så åter backa upp oförändrade data har nästan noll lagringskostnad. Borg är inte knuten till Proxmox - det är ett allmänt ändamål backupverktyg som används i många miljöer. ProxMenux använder den som en av de tre destinationerna för värdbackups; varje Borg-specifik mekanism som beskrivs på denna sida (förvarstyper, borg-serve över SSH, repokey kryptering, beskärning) är standard Borg beteende."
},
"intro": {
"title": "Blockbaserad deduplicering med lokala förvar eller förvar via SSH",
"body": "Ett Borg-förvar lagrar block som delas mellan alla arkiv. Att säkerhetskopiera en oförändrad fil igen överför och lagrar därför inga nya data. ProxMenux kör <code>borg create</code> vid säkerhetskopiering och <code>borg extract</code> vid återställning. Förvaret kan ligga på samma filsystem som källan, på en monterad extern disk eller på en fjärrvärd via SSH."
},
"binarySourcing": {
"heading": "Det körbara borg-programmet",
"intro": "Borg är inte en bas beroende av ProxMenux installer. När en backup körs, <code>hb_ensure_borg</code> löser binären från fyra källor i ordning och returnerar den första som fungerar:",
"rows": [
{
"priority": "1",
"source": "Systemets <code>borg</code>",
"detail": "Om värden redan har <code>borg</code> installerat via APT (<code>which borg</code> löser), den binära används."
},
{
"priority": "2",
"source": "Cache för tillståndskatalogen",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — sparat från en tidigare GitHub-nedladdning på värden."
},
{
"priority": "3",
"source": "Monitors AppImage-paket",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> - den AppImage buntar en signerad borg-linux64. Detta är offline-säker väg: en värd utan internet har fortfarande en fungerande <code>borg</code>."
},
{
"priority": "4",
"source": "GitHub nedladdning",
"detail": "<code>wget</code> mot <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verifierad mot en konstant SHA-256 i <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). På checksum missmatch binären kasseras och backupen aborter. Den nedladdade filen är cachad i tillståndskatalogen så efterföljande säkerhetskopior använder sökväg 2."
}
]
},
"repoTypes": {
"heading": "Förvarstyper",
"intro": "Förvarstypen väljs när ett mål läggs till. Varje typ löser sig till en annan adress som Borg förstår.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "Repository bor på en fjärrserver som kör <code>borg serve</code>. Kräver en SSH-anslutning till den servern."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "Repository bor på en monterad extern disk (typiskt USB). Monteringen löses via <code>hb_prompt_mounted_path</code>, som upptäcker, monterar eller formaterar USB-partitioner efter behov."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "Repository bor på en lokal katalog. Meningsfullt endast när målkatalogen är på en separat fysisk disk - ett förvar på samma disk som källan skyddar mot operatörsfel men inte mot diskfel."
}
]
},
"serverSetup": {
"heading": "Förbereda Borg-servern (server sida)",
"intro": "<code>remote</code> repository typ förväntar sig en fungerande Borg server tillgänglig över SSH. ProxMenux startar inte själva servern - den tillåter bara en nyckel mot ett befintligt konto på den. Det här avsnittet dokumenterar vad servern behöver innan ProxMenux kan ansluta.",
"hostChoicesTitle": "Där servern kan leva",
"hostChoicesBody": "Alla Linux värd med SSH åtkomst kvalificerar. Vanliga inställningar:",
"hostChoicesItems": [
"En dedikerad NAS eller backup box (Debian, Ubuntu, TrueNAS SCALE med ett skal).",
"En LXC-behållare inuti en Proxmox-nod. Litet fotavtryck, isolerat från värden som kör säkerhetskopiorna.",
"En annan Proxmox värd på samma LAN, eller en VM var som helst nås över SSH."
],
"lxcWarningTitle": "LXC som Borg server",
"lxcWarningBody": "Om Borg-servern körs i en LXC kräver generate-auto ett konto som tillåter SSH-inloggning med lösenord när nyckeln installeras. Annars används manuell nyckelinstallation eller alternativet generate-pct via PVE-värden.",
"requirementsTitle": "Krav på servern",
"requirementsRows": [
{
"requirement": "Körbart borg-program på <code>/usr/bin/borg</code>",
"detail": "<code>command=\"/usr/bin/borg serve ...\"</code>-linjen ProxMenux skriver i <code>authorized_keys</code> hårdkoder som väg. Installera via APT (<code>apt install borgbackup</code>) sätter den där. En fristående binär måste symlinkeras till <code>/usr/bin/borg</code>."
},
{
"requirement": "Ett dedikerat användarkonto (vanligtvis <code>borg</code>)",
"detail": "Äger förvarskatalogen och tar emot inkommande SSH-anslutningar. Behöver inte sudo eller skal åtkomst - authorized_keys-linjen inaktiverar interaktiva skal ändå."
},
{
"requirement": "En skrivbar repository katalog",
"detail": "Den väg som operatören ger ProxMenux (till exempel <code>/backup/borgbackup</code>) måste finnas på servern och ägas av borganvändaren."
},
{
"requirement": "SSH daemon accepterar borganvändaren",
"detail": "<code>PubkeyAuthentication yes</code> (standard). Lösenordsautentisering behövs endast för en-shot <em>generate-auto</em>-flödet - efter att nyckeln är installerad kan servern inaktivera lösenord auth helt."
}
],
"minimalSetupTitle": "Minimal serverkonfiguration",
"minimalSetupBody": "På en Borg-server med Debian eller Ubuntu ger fyra kommandon som root en grundkonfiguration:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "När servern är förberedd och SSH-lösenordsinloggning är tillgänglig kan <code>generate-auto</code> installera nyckeln via ett konto som får skriva i borg-användarens authorized_keys. Senare säkerhetskopior använder nyckeln, begränsad till <code>borg serve</code> på den konfigurerade sökvägen. Utan lösenordsinloggning installeras nyckeln manuellt eller via PVE-värden."
},
"sshAuth": {
"heading": "SSH autentisering (klientsida)",
"intro": "Remote Borg repositorier är tillgängliga över SSH. Anslutningen går från ProxMenux-värden till ett användarkonto på Borg-servern som kör <code>borg serve</code>. Den här användaren heter vanligtvis <code>borg</code>, inte admin/root-användaren av servern - borg-serve-kommandoraden låser anslutningen till den specifika förvaringsbanan (se de viktigaste strategierna nedan).",
"strategiesTitle": "SSH-nyckelalternativ",
"strategiesIntro": "När ett fjärrmål läggs till frågar ProxMenux efter SSH-användare, värd och fjärrsökväg och erbjuder fyra autentiseringsval. Alternativet generate-pct erbjuds om lösenordsautentisering nekas. Lägena beskrivs nedan:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Rekommenderas",
"detail": "ProxMenux skapar eller återanvänder ett ed25519-nyckelpar på <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> och använder <code>sshpass</code> för att testa inloggningen och installera den offentliga nyckeln i <code>~borg/.ssh/authorized_keys</code>. Lösenordet tillhör ett konto som får skriva i filen, oftast root eller borg. Det används under installationen och sparas inte."
},
{
"mode": "generate-manual",
"label": "Inget admin lösenord på denna värd",
"detail": "ProxMenux genererar nyckelparet som ovan men visar hela <code>authorized_keys</code>-linjen för operatören att klistra in manuellt i servern. Admin lösenord lämnar aldrig ProxMenux värd eftersom det aldrig bett om."
},
{
"mode": "generate-pct",
"label": "Borg server är en PVE LXC",
"detail": "Borg-servern körs inuti en LXC på en PVE-nod. ProxMenux tillåter nyckeln via <code>pct exec</code> från PVE-värden - root på PVE-värden skriver in i LXC <code>~borg/.ssh/authorized_keys</code> utan att behöva SSH i LXC själv."
},
{
"mode": "existing",
"label": "Använd en befintlig nyckel",
"detail": "ProxMenux skannar <code>/root/.ssh/</code> och <code>$HOME/.ssh/</code> för parseable ed25519/RSA privata nycklar och listar dem. Operatören väljer en eller bläddrar manuellt till en icke-standardväg."
},
{
"mode": "none",
"label": "Standard SSH konfig",
"detail": "Ingen anpassad nyckel - Borg är beroende av värdens standard SSH-konfiguration (vanligtvis <code>~/.ssh/id_rsa</code> eller en SSH-agent)."
}
],
"restrictTitle": "authorized_keys-linjen",
"restrictBody": "För varje skapad nyckel begränsar raden <code>authorized_keys</code> som ProxMenux skriver på servern nyckeln till följande borg-serve-anrop för den konfigurerade förvarssökvägen:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "<code>command=</code> tvingar varje SSH-session med hjälp av den här nyckeln för att bara köra borg-serve-kommandot; <code>restrict</code> inaktiverar portöverföring, agentöverföring, X11-överföring och PTY-tilldelning. Nyckeln kan inte användas för att öppna ett interaktivt skal på servern eller för att komma åt någon annan förvaringsväg, även om kontot har bredare privilegier."
},
"savedTargets": {
"heading": "Sparade mål",
"intro": "Ett sparat mål behåller förvarskonfigurationen under ett tydligt namn, så att uppgifterna inte behöver anges igen. Filer i ProxMenux tillståndskatalog:",
"rows": [
{
"file": "borg-targets.txt",
"content": "En linje per mål: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Läs av <code>hb_collect_borg_configs</code> för att befolka målvalsmenyn."
},
{
"file": "borg-pass-NAME.txt",
"content": "Lösenfras för målet som anges som NAME ovan (<code>chmod 600</code>). Finns endast om repokey-kryptering har valts."
}
],
"outro": "Det är valfritt att spara målet. Om frågan avböjs sparas ingen namngiven målkonfiguration, men en skapad SSH-nyckel tas inte bort. Om repokey aktiveras utan ett sparat mål lagrar ProxMenux ändå lösenfrasen i den äldre filen borg-pass.txt."
},
"encryption": {
"heading": "Kryptering",
"body": "Repositorier inleds med ett krypteringsläge via <code>hb_borg_init_if_needed</code>: den moderna <code>borg repo-create -e MODE</code> när den är tillgänglig, eller arvet <code>borg init --encryption=MODE</code>. ProxMenux avslöjar två lägen: <code>repokey</code> (standard) och <code>none</code>. I <code>repokey</code>-läget lagrar Borg krypteringsnyckeln inuti själva förvaret; tillgång kräver en passfras, som ProxMenux uppmanar till två gånger med match validering och lagrar i <code>borg-pass-NAME.txt</code> för sparade mål, annars i den äldre fil som beskrivs ovan. En obligatorisk bekräftelsedialog visas efter passfrasen sparas: passfrasen är det enda sättet att komma åt krypterade arkiv och förlora det gör varje arkiv i förvaret oåterkallelig."
},
"runtimeEnv": {
"heading": "Runtime miljö",
"intro": "ProxMenux exporterar följande miljövariabler innan <code>borg</code>. De konfigurerar anslutningen och låser upp förvaret utan att bädda in hemligheter i kommandoraden.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Fjärrskalskommandot som Borg använder för SSH-förvar. En vald nyckel lägger till identitetsalternativen; en annan port än standard lägger till -p PORT. Utan egen nyckel och med standardport lämnas variabeln osatt och Borg använder värdens SSH-konfiguration."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passfras från borg-pass-NAME.txt)",
"purpose": "låser upp repokey. Ange endast när målet använder <code>repokey</code>-kryptering. Aldrig visas i processargumentlistan."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Används av <code>hb_borg_init_if_needed</code> när du startar ett förvar som ännu inte existerar. Ignorerad av <code>borg create</code> på befintliga repositorier."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Undertrycker den interaktiva prompten Borg höjer när förvaringsadressen skiljer sig från webbadressen som den ursprungligen nåddes från (gemensamt efter ett monteringsnamn eller SSH-värd som nås via ny adress)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Undertrycker den interaktiva prompten Borg höjer första gången ett okrypterat förvar nås från en ny klient."
}
]
},
"archiveFormat": {
"heading": "Arkivnamn och retention",
"intro": "Varje backup skapar ett nytt arkiv inuti förvaret.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "För schemalagda jobb kör <code>run_scheduled_backup.sh</code> <code>borg prune</code> mot förvaret efter varje framgångsrik backup med lagringsvärdena konfigurerade på jobbet (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Interaktiva säkerhetskopior inte beskär."
},
"restoreAccess": {
"heading": "Hämta vid återställning",
"body": "Återställningsflödet listar arkiv med <code>borg list REPO</code> och extraherar den valda med <code>borg extract REPO::ARCHIVE-NAME</code> i en staging katalog som <code>_rs_check_layout</code> matar till standardåterställning pipeline. För manuell hämtning utanför ProxMenux samma kommandon arbete; det extraherade trädet är den standard tre-payload layout som beskrivs i <em>Hur det fungerar</em>."
},
"references": {
"heading": "Referenser",
"intro": "Officiell Borg-dokumentation för komponenterna ProxMenux är beroende av.",
"items": [
{
"label": "Borg dokumentation",
"href": "https://borgbackup.readthedocs.io/",
"tail": " - huvudingångspunkt som täcker koncept, distribution, snabbstart och varje kommando."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " - kommandot ProxMenux åberopar varje backup, med alla stödda flaggor."
},
{
"label": "Repository kryptering",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": " - krypteringslägen Borg stöder, inklusive repokey som ProxMenux använder som standard."
},
{
"label": "borg serve och driftsättning via SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " - hur man ställer in en central Borg-server som nås över SSH, inklusive borg-serve-kommandot och restrict-to-path-flaggan ProxMenux skriver i authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — lagringsreglerna bakom --keep-last / --keep-daily / --keep-weekly som ProxMenux tillämpar per schemalagt jobb."
}
]
}
}
web/messages/sv/docs/backup-restore/destinations/index.json
+110
View File
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Destinationer för säkerhetskopior — lokalt, Proxmox Backup Server, Borg | ProxMenux",
"description": "Tre lagringsbackender tar emot samma säkerhetskopieringsinnehåll från ProxMenux: ett lokalt .tar.zst-arkiv på ett skrivbart filsystem, en PBS-säkerhetskopia i en Proxmox Backup Server-datastore eller ett Borg-arkiv i ett lokalt eller fjärranslutet Borg-arkivlager. Varje backend har egna egenskaper för komprimering, deduplicering, kryptering och nätverk.",
"ogTitle": "ProxMenux mål för säkerhetskopior",
"ogDescription": "Lokal, Proxmox Backup Server och Borg - tre lagringsbackends för samma värdbackup payload.",
"twitterTitle": "Destinationer för ProxMenux-säkerhetskopior | ProxMenux",
"twitterDescription": "Lokal arkiv, Proxmox Backup Server och Borg backends för värdbackups."
},
"header": {
"title": "Destinationer",
"description": "Tre lagringsbackends som stöds av ProxMenux Backup: lokal arkiv, Proxmox Backup Server (rekommenderas) och Borg. Varje får samma tre-payload arkiv; de skiljer sig i lagringsformat, deduplicering, krypteringsmodell och nätverkskrav.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "Samma nyttolast, tre backends",
"body": "Varje säkerhetskopia skapar samma tre datablock (rootfs, manifest, program). Det som skiljer destinationerna åt är hur innehållet lagras och hämtas inför en återställning. Varje backend är en separat funktion i <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — men alla tre använder samma tillfälliga förberedelsesteg (<code>hb_prepare_staging</code>) och samma återställningskod. Valet av destination påverkar bara skrivning och hämtning; det ändrar inte hur återställningen fungerar eller använder arkivet."
},
"comparison": {
"heading": "Funktionsjämförelse",
"intro": "Följande tabell listar de konkreta skillnaderna mellan de tre backends som de beter sig i ProxMenux idag. Alla värden beskriver observerat beteende av backend själv, inte redaktionella rekommendationer.",
"rows": [
{
"feature": "Lagringsformat",
"local": "Enkel <code>.tar.zst</code>-fil (eller <code>.tar.gz</code> om <code>zstd</code> är frånvarande).",
"pbs": "PBS-säkerhetskopia (<code>.pxar</code>-block i datastoren).",
"borg": "Borg arkiv inuti ett Borg-förvar (segmentfiler)."
},
{
"feature": "Kompression",
"local": "zstd (standardnivå) via <code>tar --zstd</code>. gzip fallback.",
"pbs": "Hanteras av proxmox-backup-client. ProxMenux åsidosätter inte komprimeringsinställningarna.",
"borg": "Borgs inbyggda komprimering. ProxMenux anropar borg create utan att åsidosätta komprimeringsinställningarna."
},
{
"feature": "Deduplicering",
"local": "Ingen. Varje backup är ett fullt oberoende arkiv.",
"pbs": "Full chunk-nivå deduplicering över alla säkerhetskopior i databutiken.",
"borg": "Full chunk-nivå deduplicering över alla arkiv i förvaret."
},
{
"feature": "Kryptering i vila",
"local": "Ingen (förlitar sig på skydd av filsystemnivå).",
"pbs": "Valfri kryptering på klientsidan med en nyckelfil. När den är aktiverad laddas återställningsbloben upp som en separat säkerhetskopieringsgrupp.",
"borg": "Valfri repokey kryptering (nyckel lagrad i repan, upplåst med en passfras)."
},
{
"feature": "Bevarande / rensning",
"local": "Tillämpas per schemalagt jobb via <code>KEEP_LAST</code>. Gamla arkiv tas bort tillsammans med sina sidofiler och körningsloggar. Interaktiva säkerhetskopior utför ingen rensning.",
"pbs": "Tillämpas per schemalagt jobb via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktiva säkerhetskopior utför ingen rensning.",
"borg": "Tillämpas per schemalagt jobb via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktiva säkerhetskopior utför ingen rensning."
},
{
"feature": "Nätverk",
"local": "Ingen. Skriver till en lokal monteringspunkt (vanligtvis en intern disk eller en USB-enhet).",
"pbs": "TCP till PBS-servern (standardport 8007). Kräver PBS-uppgifter + fingeravtryck.",
"borg": "Lokal filsystemväg eller SSH tunnel till en avlägsen Borg värd."
},
{
"feature": "Beroenden",
"local": "<code>tar</code>, <code>zstd</code> (på Proxmox som standard).",
"pbs": "Paketet <code>proxmox-backup-client</code> (medföljer Proxmox VE 8+).",
"borg": "<code>borg</code> binär. Autotillhandahållen av ProxMenux från Monitor AppImage-paketet när det saknas."
},
{
"feature": "Åtkomst för återställning",
"local": "Alla värdar med tar+zstd kan extrahera arkivet. Inget PBS/Borg behövs.",
"pbs": "Kräver <code>proxmox-backup-client</code>, PBS-inloggningsuppgifter och nyckelfilen (om säkerhetskopian är krypterad).",
"borg": "Kräver <code>borg</code> + sökvägen till arkivlagret + passfrasen (om krypterad)."
}
],
"captionCode": "feature",
"captionLocal": "Lokal",
"captionPbs": "Proxmox Backup Server (rekommenderas)",
"captionBorg": "Borg"
},
"sameArchive": {
"heading": "Arkivlayouten ändras inte med destinationen",
"body": "Alla tre destinationerna innehåller samma struktur med <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> som beskrivs i <em>Så fungerar det</em>. Ett uppackat lokalt <code>.tar.zst</code>-arkiv, ett <code>.pxar</code>-arkiv återställt från PBS och ett Borg-arkiv uppackat med <code>borg extract</code> ger samma katalogträd. Återställningskoden (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) läser samma tre datablock utan att behöva veta vilken destination de kommer från."
},
"extractStandalone": {
"heading": "Extrahera en backup utanför ProxMenux",
"intro": "Alla tre arkivformat kan läsas med standardverktyg utan ProxMenux installerat på läsvärden. Kommandona nedan producerar samma katalogträd som en återställning konsumerar internt.",
"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": "# Från ett Borg-arkiv (kräver borg och passfrasen för krypterade arkivlager):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Från ett fjärranslutet arkivlager via SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "Det extraherade trädet kan sedan inspekteras manuellt eller matas till en manuell återställning. Se de enskilda destinationssidorna för det exakta hämtningsflödet ProxMenux använder under huven."
},
"whereNext": {
"heading": "Detaljer per destination",
"intro": "Varje destination har sin egen sida som täcker konfigurationsflödet, on-disk-formatet och hämtningskommandot som används av återställningen.",
"items": [
{
"label": "Lokalt arkiv",
"href": "/docs/backup-restore/destinations/local",
"tail": " — förkonfigurera ett lokalt mål, montera USB-enheter, skydd mot att arkivet inkluderar sig självt samt JSON-sidofilen som låter Monitor identifiera filen."
},
{
"label": "Proxmox Backup Server (rekommenderas)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — val av datastore, inloggningsuppgifter och certifikatets fingeravtryck, nyckelfilens livscykel, återställningspassfras samt uppladdning av återställningsbloben till PBS för återställning efter en nyinstallation."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — lokala arkivlager och arkivlager via SSH, var Borg-binären hämtas (system / cache / Monitors AppImage-paket / GitHub), initiering av arkivlager, hantering av passfraser och SSH-nycklar för fjärranslutna arkivlager."
}
]
}
}
web/messages/sv/docs/backup-restore/destinations/local.json
+75
View File
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Lokalt arkivmål — tar.zst på ett filsystem eller en USB-enhet | ProxMenux",
"description": "Det lokala säkerhetskopieringsmålet skriver ett enda .tar.zst-arkiv till en skrivbar katalog: en intern disk, en Proxmox-monteringspunkt, en NFS-delning eller en USB-enhet. Sidan beskriver konfigurationen, hur USB-enheter upptäcks och monteras, skyddet mot att skriva arkivet till en sökväg som säkerhetskopieras samt JSON-sidofilen som identifierar arkivet.",
"ogTitle": "ProxMenux Backup - Lokal arkiv destination",
"ogDescription": "Hur ProxMenux skriver lokala säkerhetskopior som .tar.zst arkiv och hur man konfigurerar destinationskatalogen eller USB-enheten.",
"twitterTitle": "Lokal backup destination | ProxMenux",
"twitterDescription": "Hur ProxMenux skriver lokala säkerhetskopior som .tar.zst arkiv på ett filsystem eller USB-enhet."
},
"header": {
"title": "Lokalt arkiv",
"description": "Det lokala målet skriver ett enda komprimerat tar-arkiv till en skrivbar katalog på värden: en intern disk, ett monterat NFS- eller SMB-filsystem eller en USB-enhet.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "En fristående fil",
"body": "En lokal säkerhetskopia producerar en enda <code>hostcfg-HOST-TIMESTAMP.tar.zst</code>-fil (eller <code>.tar.gz</code> när <code>zstd</code> är frånvarande). Filen innehåller hela arkivträdet - <code>manifest.json</code>, <code>metadata/</code> och <code>rootfs/</code> - och kan återställas på någon Proxmox värd med ProxMenux återställningsflöde, eller extraheras manuellt med <code>tar --zstd -xf</code> på alla Linux-system. Ingen server, ingen initiering av arkivlager, inget externt beroende. Detta är destinationen med den kortaste återhämtningsvägen när varken PBS eller Borg är tillgänglig."
},
"targetConfig": {
"heading": "Konfigurera målkatalogen",
"intro": "Det lokala målet är en <strong>enda sparad målkatalog</strong> — inte en lista. ProxMenux sparar användarens val i <code>/usr/local/share/proxmenux/local-target.conf</code> och läser det vid varje säkerhetskopiering. Om inget mål har konfigurerats används standardvärdet <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> (samma katalog som Proxmox använder för sina egna <code>vzdump</code>-utdata). Målet konfigureras via <em>Konfigurera säkerhetskopieringsmål → Lokala mål</em>:",
"options": [
"<strong>Använd standard (<code>/var/lib/vz/dump</code>).</strong> Proxmox lokal lagring. Finns på varje Proxmox-installation; arkivet sitter bredvid vzdump-utdata och hämtas av fliken Monitor's Backups automatiskt.",
"<strong>Ange en anpassad sökväg.</strong> Alla absoluta filsystemsökvägar kan användas: en NFS-montering, en SMB-delning monterad via <code>fstab</code>, ett särskilt ZFS-dataset eller en andra intern disk. ProxMenux kontrollerar att sökvägen finns och är en katalog innan valet sparas.",
"<strong>Välj en USB-enhet.</strong> Öppnar USB-undermenyn (nedan), som upptäcker flyttbara enheter och erbjuder sig att montera eller formatera en."
]
},
"usbFlow": {
"heading": "USB-enhetsdetektering och montering",
"intro": "USB-undermenyn listar partitioner på flyttbara enheter som rapporteras av <code>lsblk</code>. Varje partition visas med storlek, filsystemets etikett och aktuellt tillstånd. Tillståndet avgör vilken åtgärd ProxMenux erbjuder.",
"statesTitle": "De tre enhetstillstånden",
"stateRows": [
{
"state": "monterad",
"shown": "Storlek · etikett · [fstype] · → /mount/point",
"action": "Partitionen är redan monterad. Om den väljs sparas dess aktuella monteringspunkt som lokalt mål. Ingen ny montering utförs."
},
{
"state": "ej monterad",
"shown": "Storlek · etikett · [fstype] · (ej monterad — kommer att monteras)",
"action": "Ett filsystem är närvarande men inte monterat. På bekräftelse kör ProxMenux <code>hb_mount_usb_partition</code>: skapar <code>/mnt/backup-LABEL</code> (eller en UUID-baserad väg om det inte finns någon etikett), monterar partitionen och sparar monteringspunkten som det lokala målet."
},
{
"state": "tom",
"shown": "Storlek · rå USB-disk — inget filsystem (kommer att FORMATERAS)",
"action": "Enheten har inget filsystem. Denna destruktiva åtgärd skyddas av två bekräftelser. Först förklarar en Ja/Nej-dialog att disken raderas. Sedan måste användaren <strong>skriva den exakta enhetssökvägen</strong> (t.ex. <code>/dev/sdb</code>) innan ProxMenux skapar en ny GPT med en ext4-partition och monterar den."
}
],
"notMountedFallback": "Om ingen USB-enhet upptäcks visar undermenyn ett vanligt inmatningsfält. Användaren kan ange valfri sökväg till en monteringspunkt; om sökvägen inte är en registrerad monteringspunkt visas en varning i en bekräftelsedialog innan processen fortsätter."
},
"safetyCheck": {
"heading": "Säkerhetskontroll - destination inuti en backupbana",
"body": "Innan du skriver arkivet, verifierar <code>_bk_local</code> att destinationskatalogen <strong>inte</strong> är en undersökväg till någon katalog som säkerhetskopieras. Ett vanligt misstag skulle vara att lägga till <code>/root</code> till profilen och välja <code>/root/backups</code> som destination — arkivet skulle då inkludera sig självt, antingen producera ett korrupt arkiv eller växa utan gräns tills skivan fylls. Kontrollen löser båda sökvägarna med <code>readlink -m</code>, jämför dem och, vid konflikt, avbryter säkerhetskopieringen med en dialogruta som namnger den motstridiga sökvägen och listar tre sätt att lösa den: välj en destination utanför den motstridiga sökvägen, ta bort den anpassade posten som innehåller destinationen, eller använd anpassat läge för att avmarkera den motstridiga sökvägen för denna körning."
},
"archiveFormat": {
"heading": "Arkivformat och komprimering",
"intro": "Utdatafilnamnet bäddar in källvärdnamnet och backup timestamp så att en katalog med flera arkiv sorterar kronologiskt och varje fil är självidentifierande.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Kompression",
"compressionBody": "Huvudmetoden använder <code>tar --zstd -cf</code> — ett enda kommando som komprimerar med zstd:s standardnivå. Om <code>zstd</code> saknas på källan (ovanligt på Proxmox, men möjligt på minimala installationer) används <code>gzip</code>. Om <code>pv</code> finns vid denna reservmetod läggs en förloppsindikator till så att användaren ser arkivstorleken växa i realtid; utan <code>pv</code> används vanlig <code>tar -czf</code> utan förloppsutdata.",
"sourceTitle": "Vad går in i arkivet",
"sourceBody": "Kommandot tar anropas med <code>-C \"$staging_root\" .</code> och arkiverar därmed <strong>hela roten i den tillfälliga katalogen</strong>: <code>rootfs/</code>, <code>metadata/</code> och <code>manifest.json</code>. Alla tre datablocken ligger bredvid varandra högst upp i tar-arkivet. Uppackningen ger exakt samma träd som återställningskoden använder."
},
"sidecar": {
"heading": "JSON-sidofilen",
"intro": "Varje framgångsrik lokal backup producerar en följeslagare fil: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, skriven bredvid arkivet av <code>hb_write_archive_sidecar</code>. Denna lilla JSON-fil låter ProxMenux Monitor identifiera arkivet som en ProxMenux-värdbackup även om det senare flyttas, bytas namn eller arkiveras någon annanstans.",
"contentTitle": "Sidofilens innehåll",
"contentBody": "Sidofilen lagrar schemaversionen, om säkerhetskopian kom från en interaktiv körning eller ett schemalagt jobb (<code>kind</code>), jobb-ID för schemalagda körningar, det profilläge som används (<code>default</code> eller <code>custom</code>), källvärdnamnet, den ursprungliga arkivbasnamnet, en tidsstämpel för skapandet i ISO-8601-format och arkivstorleken i byte.",
"whyBody": "Monitors Backups-flik söker igenom konfigurerade lokala kataloger efter <code>*.proxmenux.json</code>-sidofiler, inte efter <code>*.tar.zst</code>-filer, eftersom en <code>.tar.zst</code> utan sidofil kanske inte är en ProxMenux-säkerhetskopia. Sökningen är snabb (JSON-filer är små) och kopplingen fungerar även efter namnbyte om sidofilen får ett motsvarande nytt namn."
},
"restoreAccess": {
"heading": "Återställande från ett lokalt arkiv",
"body": "ProxMenux återställningsflödet upptäcker lokala arkiv genom att skanna det konfigurerade lokala målet efter sidofiler och visa dem i arkivlistan. Valet av ett arkiv utlöser <code>_rs_check_layout</code>, som extraherar tarball i en staging katalog och bekräftar strukturen med tre datablock innan du fortsätter. För manuell utvinning utanför ProxMenux ger <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> samma träd som återställningskoden förbrukar."
}
}
web/messages/sv/docs/backup-restore/destinations/pbs.json
+113
View File
@@ -0,0 +1,113 @@
{
"meta": {
"title": "Proxmox Backup Server destination - förvar, kryptering, återhämtning | ProxMenux",
"description": "PBS-målet lagrar ProxMenux värdsäkerhetskopior som PBS-säkerhetskopior. Sidan beskriver automatisk identifiering från /etc/pve/storage.cfg, manuell PBS-konfiguration, uppladdning av .pxar, klientkryptering med nyckelfil och en valfri återställningskopia skyddad med lösenfras samt återställning av nyckeln från flera källor på en nyinstallerad värd.",
"ogTitle": "ProxMenux Backup - Proxmox Backup Server destination",
"ogDescription": "Hur ProxMenux skriver värdbackups till Proxmox Backup Server med klient-side keyfile kryptering och återhämtning escrow.",
"twitterTitle": "PBS som mål för säkerhetskopior | ProxMenux",
"twitterDescription": "Proxmox Backup Server som mål med nyckelfilskryptering och en återställningskopia skyddad med lösenfras."
},
"header": {
"title": "Proxmox Backup Server",
"description": "PBS-målet laddar upp hela förberedelsekatalogen som en enda .pxar-säkerhetskopia till ett Proxmox Backup Server-datalager. Klientkryptering med nyckelfil är valfri, liksom uppladdning av en återställningskopia av nyckelfilen, skyddad med lösenfras, bredvid varje säkerhetskopia.",
"section": "Säkerhetskopiering och återställning"
},
"recommendedBadge": "Rekommenderad destination",
"aboutPbs": {
"heading": "Vad Proxmox Backup Server är",
"body": "Proxmox Backup Server (PBS) är Proxmox egen backup server produkt, utvecklad och underhålls av samma team som författare Proxmox VE. Det är en dedikerad säkerhetskopieringsserver utformad för att ta emot säkerhetskopior från Proxmox VE-värdar (VM, LXCs och - via <code>proxmox-backup-client</code> - godtyckliga värdkataloger) med chunk-baserad deduplicering, klient-side-kryptering och lagringspolicy tillämpad server-side. ProxMenux använder PBS som en av de tre destinationerna för värdbackups; varje PBS-specifik mekanism som beskrivs på denna sida (backupgrupper, <code>.pxar</code> arkiv, <code>--backup-id</code>, keyfile kryptering) är standard PBS beteende."
},
"intro": {
"title": "En säkerhetskopia per körning, deduplicering på blocknivå",
"body": "En PBS-säkerhetskopia skapar en enda post i datalagret under säkerhetskopierings-ID:t <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Innehållet är ett <code>.pxar</code>-arkiv med samma struktur i tre delar som beskrivs i <em>Så fungerar det</em>. PBS deduplicerar block mellan alla säkerhetskopior i datalagret, så senare säkerhetskopior av samma värd överför och lagrar endast ändrade block. ProxMenux tillämpar själv lagringsreglerna för schemalagda jobb: efter varje lyckad körning kör <code>run_scheduled_backup.sh</code> kommandot <code>proxmox-backup-client prune</code> med <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> och jobbets inställda värden."
},
"repoSelection": {
"heading": "Repository urval",
"intro": "ProxMenux upptäcker PBS repositorier från två källor på varje backup. Operatören väljer en från en enhetlig meny; valet bestämmer <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> och <code>HB_PBS_FINGERPRINT</code> för körningen.",
"sourceRows": [
{
"source": "Proxmox storage.cfg (identifierad automatiskt)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Varje <code>pbs:</code>-avsnitt i Proxmox egen lagringskonfiguration identifieras automatiskt. Server, datalager, användarnamn och fingeravtryck hämtas från avsnittet. Lösenordet läses från Proxmox egen katalog för inloggningsuppgifter. Uppgifterna behöver inte anges på nytt i ProxMenux; förvaret är tillgängligt så snart det har konfigurerats i Proxmox."
},
{
"source": "ProxMenux manuell konfig",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Läggs till via <em>Konfigurera säkerhetskopieringsmål → PBS-mål → Lägg till PBS</em>. Du anger namn, användarnamn (<code>root@pam</code> eller <code>user@pbs!token</code>), värd eller IP-adress, datalager och lösenord. Om lösenordet lämnas tomt visas frågan igen; annars skulle en tom uppgift sparas utan varning och alla senare säkerhetskopior misslyckas med ett otydligt autentiseringsfel. Detta används när PBS-målet inte är registrerat som Proxmox-lagring."
}
],
"menuTitle": "Urvalsmenyn",
"menuBody": "Båda källorna visas i en enda meny, varje rad märkt med sitt ursprung (<code>[proxmox]</code> eller <code>[manual]</code>). Anteckningar vars lösenord inte kunde lösas är taggade med en <code>⚠ no password</code>-varning - välja en utlöser ett lösenord återinträde innan backupen startar. Fingeravtrycket överförs till <code>proxmox-backup-client</code> via <code>PBS_FINGERPRINT</code>-miljövariabeln; när det saknas frågar klienten operatören att acceptera servercertifikatet interaktivt på den första säkerhetskopian."
},
"backupCommand": {
"heading": "Backup kommandot",
"intro": "Uppladdningen sker med ett enda anrop till <code>proxmox-backup-client backup</code>. ProxMenux använder <code>env</code> för att överföra lösenord, krypteringslösenord och fingeravtryck till klienten som miljövariabler.",
"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": "Namnge säkerhetskopierings-ID",
"backupIdBody": "Standard-ID är <code>hostcfg-HOSTNAME</code>. Operatören bekräftar eller redigerar det före uppladdning; tecken utanför <code>[A-Za-z0-9_-]</code> och avslutande bindestreck tas bort. Att återanvända samma ID är avsiktligt: PBS behandlar ID:t som en <em>grupp</em>, och varje senare säkerhetskopia blir en ny post i gruppen med gemensam deduplicering med tidigare körningar.",
"pxarTitle": "Varför källan är hela staging roten",
"pxarBody": "<code>.pxar</code>-källan är hela <code>staging_root</code> - <code>rootfs/</code>, <code>metadata/</code> och <code>manifest.json</code> tillsammans. Tidigare versioner passerade <code>$staging_root/rootfs</code> som källa; som lämnade <code>metadata/</code> ur arkivet och återställningens kompatibilitetskontroll hade ingenting att läsa, försämrade att korsa värd varningar även på samma värd återställningar. Gamla säkerhetskopior som skapats med rootfs-bara källan återställs fortfarande korrekt via <code>_rs_check_layout</code>: s fall-3 gren, som lindrar en platt <code>etc/var/root/usr</code> träd tillbaka till en <code>rootfs/</code> hierarki."
},
"encryption": {
"heading": "Klient-side kryptering",
"glossaryHint": "Avsnittet använder termerna <em>nyckelfil</em>, <em>lösenfras</em> och <em>återställningskuvert</em>. <glosarioLink>Ordlistan</glosarioLink> sammanfattar skillnaderna med en mening per term.",
"intro": "PBS klientkryptering med nyckelfil krypterar blocken på källvärden före uppladdning. Kryptering är valfri i ProxMenux. När den aktiveras väljer operatören uttryckligen ja eller nej till att även lagra en återställningskopia av nyckelfilen, skyddad med lösenfras, på PBS. Valet kan ändras senare i Monitor. Själva nyckelfilen finns alltid på den kanoniska sökvägen <code>/usr/local/share/proxmenux/pbs-key.conf</code> och återanvänds utan nya frågor vid varje senare krypterad säkerhetskopiering.",
"keyfileTitle": "Ställ in nyckelfilen",
"keyfileBody": "Krypteringsdialogen visas vid värdens första krypterade säkerhetskopiering. Först frågar den om säkerhetskopian ska krypteras: <em>Nej</em> fortsätter utan kryptering och <em>Ja</em> går till steg två. Det steget beror på om en nyckelfil redan finns på <code>/usr/local/share/proxmenux/pbs-key.conf</code>. I så fall återanvänds den utan frågor och säkerhetskopieringen fortsätter; inte heller senare säkerhetskopieringar frågar igen. Annars visar en meny två alternativ. <em>Skapa en ny nyckelfil</em> kör <code>proxmox-backup-client key create --kdf none</code>. <em>Använd en befintlig nyckelfil</em> identifierar automatiskt en PVE-hanterad nyckel: om det valda PBS-förvaret är registrerat i Proxmox med en krypteringsnyckel på <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, kopieras filen utan frågor till ProxMenux kanoniska sökväg. Om ingen PVE-hanterad nyckel matchar förvaret efterfrågas den absoluta sökväg där operatören redan har placerat nyckelfilen på värden. I båda fallen installeras filen på den kanoniska sökvägen med <code>chmod 600</code>.",
"modesTitle": "En nyckelfil per värd eller en gemensam nyckelfil",
"modesIntro": "Båda driftsmodellerna stöds och ingen är obligatorisk. Operatören väljer utifrån hur värdarna är organiserade.",
"modesPerHostTitle": "En nyckelfil per värd (standard)",
"modesPerHostBody": "Varje värd genererar sin egen nyckelfil första gången det möjliggör PBS-kryptering. Isolering är maximal: att kompromissa med nyckelfilen hos en värd exponerar inte någon annans säkerhetskopior. Rekommenderas för produktionsflottor och för miljöer där värdar har olika ägare eller överensstämmelse gränser.",
"modesSharedTitle": "Gemensam nyckelfil (importeras på varje värd)",
"modesSharedBody": "En huvudnyckelfil skapas en gång och installeras på varje värd via alternativet <em>Använd en befintlig nyckelfil</em>. Hanteringen blir enklare: en enda hemlighet att skydda, och varje värd kan dekryptera alla andra värdars arkiv. Det är användbart för konsolidering, återställningsövningar mellan värdar och central verifiering av säkerhetskopior. Nackdelen är att en läcka av den gemensamma nyckeln exponerar alla värdar samtidigt. Rekommenderas för hemlabb och miljöer där alla värdar har samma ägare och ingår i samma tillitsområde.",
"recoveryTitle": "Ladda upp nyckeln till PBS – operatören bestämmer",
"recoveryBody": "Direkt efter valet av nyckelfil ställer ProxMenux den uttryckliga frågan <em>Ladda upp nyckeln till PBS?</em> med två svar. <strong>Ingen återställningsfil laddas upp till PBS förrän operatören svarar Ja.</strong> Standardvalet är <em>Nej, behåll endast lokalt</em>: nyckelfilen ligger kvar på den kanoniska lokala sökvägen, ProxMenux laddar inte upp någon återställningsfil till PBS och operatören ansvarar själv för kopian utanför värden. Knappen <em>Ladda ner nyckelfil</em> på PBS-målets rad i Monitor ger en kopia vid behov. Valet <em>Ja, ladda upp</em> efterfrågar en återställningslösenfras två gånger och kontrollerar att svaren matchar. ProxMenux skyddar nyckelfilen med AES-256-CBC och PBKDF2 (600 000 iterationer, slumpmässigt salt) och skapar <code>pbs-key.recovery.enc</code>. Varje senare krypterad säkerhetskopia laddar upp detta kuvert till PBS som en tillhörande säkerhetskopieringsgrupp. Dessa uppladdningar skickar varken lösenfrasen eller nyckelfilen i klartext till PBS. Valet kan ändras när som helst i Monitor: kontrollen på PBS-målets rad växlar Ja/Nej och tillämpar omedelbart Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras beroende på aktuellt tillstånd.",
"blobUploadTitle": "Tillhörande säkerhetskopieringsgrupp på PBS",
"blobUploadBody1": "När läget är <em>Ja, ladda upp</em> laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra tillhörande grupp. Den har samma namn som värdens grupp med suffixet <code>-keyrecovery</code>. Grupperna visas bredvid varandra i datalagrets lista: en för värdsäkerhetskopior och en för återställningskuvert. <strong>Kuvertet lämnar aldrig värden i klartext</strong>: krypteringen sker på värden med AES-256-CBC och PBKDF2 innan några data överförs (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS tar endast emot det redan krypterade kuvertet.",
"envelopeSecurityTitle": "Överför nyckelåterhämtningsfilen till PBS en säkerhetsrisk?",
"envelopeSecurityBody": "Keyrecovery-filen krypteras i transit och i vila. Återhämtningspassfrasen lämnar aldrig värden: kryptering sker lokalt före uppladdningen, och PBS ser bara det redan krypterade resultatet. En PBS-administratör - eller någon med tillgång till databutiken - kan ladda ner nyckelrecovery-filen, men utan återställningspassfrasen kan de inte läsa nyckelfilen inuti: det är ogenomskinlig chiffertext. Rekonstruera nyckelfilen kräver båda bitarna samtidigt, nyckelrecovery-filen och passfrasen, och endast operatören håller båda.",
"blobUploadConstraintTitle": "Varför två grupper istället för en enda krypterad",
"blobUploadConstraintBody": "Ett enda anrop till <code>proxmox-backup-client backup</code> krypterar antingen alla sina arkiv med samma nyckelfil eller inget av dem. Värdsäkerhetskopian måste krypteras med värdens nyckelfil, men återställningskuvertet kan inte skickas med i samma uppladdning: då skulle det krypteras med just den nyckelfil som det innehåller. På en nyinstallerad värd skulle det inte gå att öppna, eftersom nyckelfilen skulle behövas för att dekryptera sig själv. Därför laddas de två filerna upp separat och visas som två grupper. PBS-klienten krypterar värdsäkerhetskopian med nyckelfilen, medan ProxMenux krypterar kuvertet med lösenfrasen före uppladdning. Två olika krypteringslager skyddar två olika innehåll.",
"blobUploadImageAlt": "PBS-gränssnittet visar säkerhetskopieringsgrupperna hostcfg-HOSTNAME och hostcfg-HOSTNAME-keyrecovery bredvid varandra i datalagrets lista.",
"blobUploadImageCaption": "PBS-gränssnittet — de tillhörande säkerhetskopieringsgrupperna. Huvudgruppen innehåller värdsäkerhetskopiorna; gruppen -keyrecovery innehåller nyckelfilen skyddad med lösenfras.",
"recoverTitle": "Återhämtning på en ny värd",
"recoverBody": "Om nyckelfilen saknas på den kanoniska sökvägen, efter en ominstallation eller uttrycklig borttagning, provar återställningen tre källor i ordning och stannar vid den första användbara nyckeln. Först kopieras en matchande PVE-hanterad nyckel från <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code> utan frågor till den kanoniska sökvägen, om den finns för det valda PBS-förvaret. Om det finns en <code>-keyrecovery</code>-grupp på PBS laddas sedan den senaste ögonblicksbilden ner och operatören anger återställningslösenfrasen för att dekryptera den. Om båda alternativen misslyckas eller avböjs efterfrågas till sist den absoluta sökvägen till nyckelfilen på värden, och filen kopieras till den kanoniska sökvägen. Monitor visar samma importflöde i säkerhetskopians detaljdialog. En gul panel visas överst när Återställ, Ladda ner eller Visa innehåll behöver en nyckel som saknas. Om en installerad nyckel inte matchar säkerhetskopian returnerar PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Samma tre åtgärder visar då en strukturerad panel med manifestets nödvändiga nyckelfingeravtryck tydligt utmärkt, så att operatören kan identifiera rätt nyckelfil att importera för säkerhetskopian.",
"monitorManagementTitle": "Hantera nyckelfilen från Monitor",
"monitorManagementBody": "Monitor visar nyckelfilens kontroller direkt på varje PBS-målrad i säkerhetskopieringskonfigurationen. Tre åtgärder finns: <em>Ladda ner</em> exporterar den aktuella filen till webbläsaren; <em>Ladda upp</em> ersätter den installerade filen med operatörens fil, och den gamla skrivs över först när den nya har installerats på den kanoniska sökvägen; <em>Ta bort</em> tar bort filen från värden. Bredvid finns kontrollen för återställningskopian: ett Ja/Nej-val för <em>Ladda upp nyckeln till PBS?</em>, ett lösenfrasfält när Ja väljs och en knapp som beroende på tillstånd tillämpar <em>Börja ladda upp</em>, <em>Sluta ladda upp</em> eller <em>Uppdatera lösenfras</em>. Alla åtgärder använder samma Flask-slutpunkter som terminalgränssnittet, så effekten på disk och tillståndet på PBS blir identiska från båda gränssnitten."
},
"restoreAccess": {
"heading": "Hämta vid återställning",
"body": "Återställningen hittar ProxMenux värdsäkerhetskopior på PBS genom att lista grupperna i det konfigurerade förvaret och filtrera efter ID-mönster. Fliken Säkerhetskopior i Monitor visar samma lista. När en säkerhetskopia väljs körs <code>proxmox-backup-client restore</code> med samma förvar, lösenord och fingeravtryck, samt <code>--keyfile</code> om kopian är krypterad. Arkivet <code>.pxar</code> packas upp i en förberedelsekatalog som <code>_rs_check_layout</code> lämnar vidare till den vanliga återställningen. Utanför ProxMenux kan samma kommando packa upp arkivet till valfri sökväg för att granska trädet eller återställa manuellt."
},
"references": {
"heading": "Referenser",
"intro": "Officiell Proxmox Backup Server-dokumentation för komponenterna ProxMenux är beroende av.",
"items": [
{
"label": "Proxmox Backup Server dokumentation",
"href": "https://pbs.proxmox.com/docs/",
"tail": " - huvudingångspunkt som täcker installation, administration, lagring, användare och roller."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — kommandoradsverktyget som ProxMenux använder för varje säkerhetskopiering och återställning. Beskriver säkerhetskopierings-ID, typer, arkiv, förvarssyntax och miljövariabler."
},
{
"label": "Kryptering på klientsidan",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — skapa nyckelfiler, --kdf-lägen och krypteringsmodellen som ProxMenux utökar med en återställningskopia skyddad med lösenfras."
},
{
"label": "Datalagerhantering",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": " - skapa och hantera datastorer som tar emot värdbackups, inklusive chunk-store layout och behörigheter."
},
{
"label": "Gallring och skräpinsamling",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — lagringsreglerna bakom --keep-last / --keep-daily / --keep-weekly som ProxMenux tillämpar per schemalagt jobb, samt hur PBS frigör oanvända block efter gallring."
}
]
}
}
web/messages/sv/docs/backup-restore/glossary.json
+230
View File
@@ -0,0 +1,230 @@
{
"meta": {
"title": "Ordlista - Backup & Restore | ProxMenux",
"description": "Termer i ProxMenux system för säkerhetskopiering och återställning: kryptering, nyckelfil, passfras, återställningskuvert, PBS, datablock, rootfs, manifest, körprocess och komplettering mellan kärnversioner.",
"ogTitle": "Backup & Återställ ordlista | ProxMenux",
"ogDescription": "Tydliga definitioner för ordförråd som används över ProxMenux backup och återställa dokumentation.",
"twitterTitle": "Backup & Återställ ordlista | ProxMenux",
"twitterDescription": "Passfras, keyfile, återhämtningskuvert, rootfs, manifest, PBS, bitar - alla definierade på ett ställe."
},
"header": {
"title": "Ordlista",
"description": "Termer i dokumentationen för säkerhetskopiering och återställning, med definitioner.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"body": "Termer grupperas efter tema. Varje post ger termen och en kort definition."
},
"groups": [
{
"title": "Kryptering och nyckelåterställning",
"intro": "Vocabulary för PBS kryptering block. Det handlar om två distinkta hemligheter: en binär nyckelfil och en skriftlig passfras.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Återställningslösenfras",
"def": "Text lösenord användaren väljer för att skydda <a href=\"#sobre-recuperacion\">återställningskuvertet</a>. Det uppmanas två gånger med en matchkontroll, och används endast för att kryptera kuvertet och för att dekryptera det om nyckelfilen någonsin behöver återställas. <strong>Det är inte passfrasen som låser upp nyckelfilen själv</strong>, och det skickas aldrig till PBS. Under en normal backup lämnar den aldrig värden."
},
{
"id": "clave-cifrado",
"term": "Keyfile (krypteringsnyckel)",
"def": "Nyckelfil som proxmox-backup-client använder för att kryptera <a href=\"#chunk\">datablock</a> före uppladdning till PBS. Utan rätt nyckel kan krypterade data inte läsas. ProxMenux sparar filen på <code>/usr/local/share/proxmenux/pbs-key.conf</code> med läge <code>600</code>. Skydda den: <a href=\"#sobre-recuperacion\">återställningskuvertet</a> finns för att återställa filen om den förloras."
},
{
"id": "contrasena-keyfile",
"term": "Keyfile passfras (KDF passfras)",
"def": "Valfri passfras som keyfilen själv kan bära, skiljer sig från <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a>. Det finns bara när nyckelfilen skapades med <code>--kdf scrypt</code> (vanligtvis en importerad nyckelfil). Utan det kan nyckelfilen inte låsas upp för användning. ProxMenux sparar den i krypterad form på värden så att schemalagda säkerhetskopior kan köras utan en interaktiv prompt."
},
{
"id": "sobre-recuperacion",
"term": "Återhämtningskuvert",
"def": "<a href=\"#clave-cifrado\">Nyckelfilen</a> är insvept i ett extra lager: det är krypterat med <a href=\"#passphrase-recuperacion\">Återhämtningspassfras</a> Använda <a href=\"#aes-256-cbc\">AES-256-CBC</a> och <a href=\"#pbkdf2\">PBKDF2</a> innan den någonsin lämnar värden. Det är det som laddas upp till PBS som den <code>-keyrecovery</code> grupp. Utan passfrasen är kuvertet ogenomskinligt: ladda ner det från PBS avslöjar inte keyfile."
},
{
"id": "cifrado-cliente",
"term": "Klient-side kryptering",
"def": "Krypteringsmodell där data krypteras på källvärden innan de laddas upp. PBS får bara och lagrar chiffertext; inte ens en PBS-administratör med databutiksåtkomst kan läsa den utan nyckelfilen. ProxMenux bygger på denna modell och lägger till <a href=\"#sobre-recuperacion\">återställningskuvertet</a> ovanpå."
},
{
"id": "kdf-none",
"term": "--kdf none",
"def": "Alternativ till <code>proxmox-backup-client key create</code> som producerar en nyckelfil utan bifogad passfras. Nyckelfilen kan användas direkt utan en prompt, vilket är viktigt för schemalagda jobb som körs obevakad. Detta är vad ProxMenux använder som standard när man skapar en ny nyckelfil."
},
{
"id": "kdf-scrypt",
"term": "--kdf scrypt",
"def": "Alternativ till <code>proxmox-backup-client key create</code> som producerar en nyckelfil skyddad av en <a href=\"#contrasena-keyfile\">nyckelfilspassfras</a>. Varje användning av nyckelfilen kräver att låsa upp den med den passfrasen. ProxMenux accepterar denna typ av nyckelfil på import och lagrar passfrasen krypterad så schemalagda säkerhetskopior kan fortfarande köras obevakad."
},
{
"id": "aes-256-cbc",
"term": "AES-256-CBC",
"def": "Standard symmetrisk chiffer. ProxMenux använder den (via <code>openssl enc -aes-256-cbc</code>) för att linda <a href=\"#clave-cifrado\">nyckelfilen</a> med <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a> och producera <a href=\"#sobre-recuperacion\">kuvertet</a>."
},
{
"id": "pbkdf2",
"term": "PBKDF2",
"def": "Kryptografisk funktion som förvandlar en mänskligt utformad passfras till en binär nyckel som är lämplig för kryptering. Det saktar ner brute-force försök genom att tillämpa många iterationer. ProxMenux använder den med 600 000 iterationer och ett slumpmässigt salt när man krypterar återhämtningskuvertet."
}
]
},
{
"title": "Backup struktur",
"intro": "Termer som beskriver vad som lever i en säkerhetskopia, oavsett destination.",
"entries": [
{
"id": "rootfs",
"term": "rootfs / rotfilsystem",
"def": "Filbaserad kopia av källvärdens filsystem skapad med <code>rsync</code> enligt <a href=\"#perfil-defecto\">standardprofilen</a> och <a href=\"#rutas-personalizadas\">egna sökvägar</a>. Det är ingen hel diskavbildning: endast sökvägar med konfiguration eller tillstånd som Proxmox inte kan återskapa självt kopieras."
},
{
"id": "manifiesto",
"term": "Manifest (manifest.json)",
"def": "Strukturerad JSON-dokument som beskriver källvärden vid backuptid: hårdvara, lagring, kärna, ProxMenux-installerade komponenter och inventering av VM och LXC. Den produceras av sex oberoende samlare. Återställningsflödet använder det för att jämföra källa och mål."
},
{
"id": "staging",
"term": "Staging katalog",
"def": "Tillfällig katalog där ProxMenux monterar de tre blocken (rootfs, metadata och manifest) innan du packar dem och laddar upp till destinationen. Det tas bort automatiskt när backupen slutar, även på abort."
},
{
"id": "perfil-defecto",
"term": "Standardprofil",
"def": "Utvalda sökvägar som ProxMenux kopierar som standard i varje säkerhetskopia. Omfattar PVE-konfiguration, nätverk, SSH, kärna, apt, ProxMenux-verktyg och mer. Definieras i koden och beskrivs på sidan <em>Hur det fungerar</em>."
},
{
"id": "rutas-personalizadas",
"term": "Anpassade vägar",
"def": "Extra vägar som användaren lägger till ovanpå <a href=\"#perfil-defecto\">default profil</a>. Antingen ihållande (lagras i <code>backup-extra-paths.txt</code>) eller per-run (plockad i anpassat läge)."
}
]
},
{
"title": "Destinationer och lagring",
"intro": "Villkor bundna till var backup landar - PBS server, lokal arkiv eller Borg repository - och hur PBS organiserar data.",
"entries": [
{
"id": "repositorio-pbs",
"term": "PBS-arkivet",
"def": "Kombination av Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + användare som tar emot backupen. Identifierad av strängen <code>user@realm@host:datastore</code>. En enda PBS-server kan vara värd för flera förråd."
},
{
"id": "datastore",
"term": "Datalager",
"def": "Ett visst lagringsutrymme på en PBS-server där säkerhetskopior och deras datablock finns. Varje datalager ligger på ett filsystem på PBS-servern och har egna behörigheter och regler."
},
{
"id": "chunk",
"term": "Datablock / deduplicering av datablock",
"def": "PBS delar varje backup i varierande storlek bitar, identifierar varje bit av sin hash och lagrar varje bit bara en gång, även om det visas i många olika säkerhetskopior. Detta innebär successiva säkerhetskopior av samma värd - eller över liknande värdar - ta mycket lite extra utrymme."
},
{
"id": "fingerprint",
"term": "Fingeravtryck",
"def": "Kryptografiskt fingeravtryck av PBS-serverns TLS-certifikat. Den låter kunden verifiera att den talar till den avsedda servern utan att förlita sig på en myndighet för offentlig certifikat. ProxMenux passerar den till <code>proxmox-backup-client</code> via <code>PBS_FINGERPRINT</code> miljövariabel."
},
{
"id": "grupo-copia",
"term": "Säkerhetskopia grupp",
"def": "Logisk container inuti PBS under vilken successiva säkerhetskopior av samma tillgång ackumuleras. Varje ny backup delar deduplicering med tidigare i samma grupp. ProxMenux använder två grupper per värd när kryptering är aktiverad: en för värdbackupen och en med ett <code>-keyrecovery</code>-suffix för <a href=\"#sobre-recuperacion\">återställningskuvertet</a>."
},
{
"id": "backup-id",
"term": "Säkerhetskopierings-ID",
"def": "Namnet på <a href=\"#grupo-copia\">backup grupp</a>. ProxMenux standarder till <code>hostcfg-HOSTNAME</code> och låter användaren redigera det innan uppladdning; ostödda tecken tas bort automatiskt."
},
{
"id": "pxar",
"term": ".pxar",
"def": "PBS-inhemska arkivformat för kataloger. Det beter sig som en tar-arkiv optimerad för chunk deduplicering: snarare än att lagra en ogenomskinlig fil bryter PBS innehållet i återanvändbara bitar."
}
]
},
{
"title": "Körning och schemaläggning",
"intro": "Termer i ProxMenux system för schemalagda jobb.",
"entries": [
{
"id": "runner",
"term": "Körprocess",
"def": "<code>run_scheduled_backup.sh</code>-skriptet som utför en schemalagd säkerhetskopia. Den läser jobbkonfigen, lanserar matchande backend (Local, PBS eller Borg), tillämpar lagring på framgång och skickar konfigurerade meddelanden."
},
{
"id": "trabajo-programado",
"term": "Schemalagt jobb",
"def": "Bestående konfiguration av en återkommande backup. Håller destination, referenser, kryptering, schema och lagring. Lever på <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
},
{
"id": "modo-adjunto",
"term": "Anslutet läge",
"def": "Jobb utan egen timer. En job-end-hook i PVE <code>vzdump</code> utlöser det efter gästsäkerhetskopior när mållagringen matchar. Det valda överordnade jobbet ger lagring och inledande lagringsregler, men hooken matchar lagring, inte jobb-ID. Även en annan uppgift med samma lagring kan utlösa det. Endast Local och PBS."
},
{
"id": "timer-systemd",
"term": "systemd-timer",
"def": "Standard systemd-mekanism som skjuter ett kommando i en kalender. ProxMenux skapar en timer per <em>oberoende</em> schemalagt jobb; <a href=\"#modo-adjunto\">attach-mode</a> jobb använder ingen timer, de körs via PVE script-hook."
},
{
"id": "retencion",
"term": "Lagringsregler (keep-last, keep-daily…)",
"def": "Policy som bestämmer vilka äldre säkerhetskopior som ska hållas och vilka som ska beskäras. Definieras per jobb med parametrar som <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Tillämpad av körprocessen efter varje framgångsrik backup."
}
]
},
{
"title": "Återställa",
"intro": "Termer från återställningsflödet.",
"entries": [
{
"id": "restauracion-universal",
"term": "Universell återställning",
"def": "ProxMenux-återställningsflödet extraherar inte bara filsystemet: det läser manifestet för att upptäcka skillnader mellan källa och mål, reproducerar systemkonfigurationen och kör om installatörerna för ProxMenux-hanterade komponenter. Målet är att reproducera källvärden, inte bara arkivet."
},
{
"id": "hidratacion",
"term": "Komplettering mellan kärnversioner",
"def": "Återställ pass som sammanfogar användarens egen konfiguration från källan (IOMMU-tokens, VFIO-enhets-ID, anpassade quirks, GRUB-nycklar) ovanpå målets färska startkonfiguration, utan att kopiera källans kärnbundna filer verbatim. Kör när målkärnan är nyare än backupen."
},
{
"id": "cross-kernel",
"term": "Återställning mellan kärnversioner",
"def": "Återställ var målets kärna skiljer sig från (vanligtvis är nyare än) källan. Kräver <a href=\"#hidratacion\">hydration</a> pass för att undvika att dra längs filer oförenliga med målets kärna."
},
{
"id": "instalador-postboot",
"term": "Installerare efter uppstart",
"def": "Komponenter installerade efter den första starten av den restaurerade värden (NVIDIA drivrutiner, Coral TPU drivrutiner, AMD GPU verktyg, Intel GPU verktyg). Varje installatör körs mot målets kärna, så den restaurerade värden beror inte på att källans kärna är närvarande."
},
{
"id": "compatibility-check",
"term": "Kompatibilitetskontroll",
"def": "Jämförelse mellan källans manifest och målets tillstånd som ProxMenux utför i början av återställningen. Det bestämmer vilka delar som kopieras verbatim, som behöver hydrering och som återskapas av en installatör."
},
{
"id": "equipo-recien-instalado",
"term": "Färsk installation",
"def": "Värd bara ominstallerad från början, utan lokal <a href=\"#clave-cifrado\">nyckelfil</a>. Återställa en krypterad säkerhetskopia kräver första återställning av nyckelfilen från <a href=\"#sobre-recuperacion\">återställningskuvertet</a> lagrad på PBS, med hjälp av <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a>."
}
]
}
],
"whereNext": {
"heading": "Nästa steg",
"items": [
{
"label": "Hur det fungerar",
"href": "/docs/backup-restore/how-it-works",
"tail": " — där rootfs, manifest och applikationsinventering passar in i en backup."
},
{
"label": "Proxmox Backup Server-mål",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " - där klient-side kryptering, keyfile, återställningspassfras och kuvert dokumenteras på djupet."
},
{
"label": "Återställande",
"href": "/docs/backup-restore/restoring",
"tail": " — Återställande flöde och manifest användning."
}
]
}
}
web/messages/sv/docs/backup-restore/how-it-works.json
+205
View File
@@ -0,0 +1,205 @@
{
"meta": {
"title": "Hur ProxMenux Backup fungerar internt - rootfs, manifest, applikationer",
"description": "Detaljerat innehåll i en ProxMenux-säkerhetskopia: rootfs kopierat med rsync enligt standardprofilens sökvägar, ett strukturerat manifest från sex oberoende insamlare och programinventeringen som styr automatisk ominstallation av paket och komponenter efter återställning.",
"ogTitle": "Hur ProxMenux Backup fungerar internt",
"ogDescription": "De tre nyttolasterna av en ProxMenux-backup förklarade: rootfs, manifest och applikationer.",
"twitterTitle": "Hur ProxMenux Backup fungerar | ProxMenux",
"twitterDescription": "De tre nyttolasterna av en ProxMenux-backup och hur återställningen reproducerar källvärden från dem."
},
"header": {
"title": "Hur det fungerar",
"description": "Den interna nedbrytningen av en ProxMenux-backup - filsystem, manifest och applikationsinventering - och hur återställningen förbrukar alla tre för att reproducera källvärden på ett mål som kanske inte delar samma kärna.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "Ett arkiv, tre delar",
"body": "Varje säkerhetskopia skapar tre tydliga delar under en gemensam förberedelsekatalog. Arkivet som laddas upp till målet (lokalt <code>.tar.zst</code>, PBS-säkerhetskopia eller Borg-arkiv) innehåller samma struktur. Återställningen använder alla tre: <strong>manifestet</strong> läses före ändringar för att upptäcka avvikelser och bestämma undantag; <strong>rootfs</strong> ger konfigurationsfiler som tillämpas direkt eller efter omstart; <strong>programinventeringen</strong> styr paketinstallation och ominstallation av komponenter efter start. Varje del kan granskas eller packas upp oberoende."
},
"layout": {
"heading": "Arkivlayout",
"intro": "Varje arkiv följer samma trädlayout oavsett destination. <code>metadata/</code> underkatalog håller de strukturerade nyttolasterna; <code>rootfs/</code> underkatalog håller filsystemet kopiera.",
"treeCaption": "Förberedelsekatalogen som skapas vid säkerhetskopiering. Alla mål får samma träd i sitt eget format: tar för lokala mål, PBS-block för PBS och Borg-segment för 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": "Innehållet i rootfs",
"intro": "Trädet <code>rootfs/</code> är en <strong>vanlig filsystemkopia</strong> som skapas med <code>rsync</code> från källvärden. Det innehåller en utvald <strong>standardprofil</strong> med sökvägar som behövs för Proxmox-återställning samt <strong>egna sökvägar</strong> som användaren lägger till i jobbet eller den interaktiva sessionen. Urvalet är avsiktligt begränsat till sökvägar som <em>innehåller konfiguration</em> eller <em>lagrar tillstånd som Proxmox inte kan återskapa själv</em>.",
"defaultProfileTitle": "Standardprofilen",
"defaultProfileBody": "Standardprofilen definieras av <code>hb_default_profile_paths</code> i <code>lib_host_backup_common.sh</code>. Den omfattar åtta fasta kategorier och vid behov ZFS-tillstånd, som tillsammans beskriver en fungerande Proxmox-värd:",
"categoriesTitle": "Sökvägskategorier",
"categoryRows": [
{
"category": "PVE-kärna",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
"why": "Cluster filsystem innehåll och vzdump standarder. Pmxcfs databas (<code>config.db</code>) fångas som en konsekvent ögonblicksbild via <code>sqlite3 .backup</code> utan att stoppa klustret, och <code>.db-wal</code> / <code>.db-shm</code> sidovagnar är uteslutna från rsync. När <code>sqlite3</code> inte är tillgänglig, skapas i stället <code>config.db.raw-fallback</code>, som automatiskt används som databas vid återställning."
},
{
"category": "Värd identitet och nätverk",
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
"why": "Det värden behöver för att komma upp i nätverket med samma identitet. Filerna <code>.link</code> under <code>/etc/systemd/network</code> kopplar nätverkskortens namn till deras MAC-adresser, så att namnen bevaras vid ominstallation och hårdvaruändringar."
},
{
"category": "Åtkomst och autentisering",
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
"why": "SSH-nycklar, sudoregler och PAM-konfiguration. Att förlora dessa låser användaren ur den restaurerade värden."
},
{
"category": "Kärna och uppstart",
"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-parametrar, svartlistor för moduler, VFIO-enhets-ID, monteringstabell och lagringskonfiguration."
},
{
"category": "Skal och språkinställningar",
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
"why": "Systemgemensam skalkonfiguration, miljövariabler och inställningar för generering av språkmiljöer."
},
{
"category": "Pakethantering och 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-källor för konsekvent paketlösning, schemalagda uppgifter som definieras av användaren."
},
{
"category": "ProxMenux tillstånd och verktyg",
"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": "Valfri men vanlig Proxmox verktyg. Saknade vägar noteras i <code>metadata/missing_paths.txt</code> utan att stoppa backupen."
},
{
"category": "ProxMenux-program och root-kontot",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (flyktiga subdirs exkluderade)",
"why": "ProxMenux-installerade binärer och per användare konfiguration under <code>/root</code>. Volatila vägar (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) utesluts från kopian. <code>/var/lib/proxmenux</code> håller de schemalagda backupjobben och värdens tillstånd som hålls av ProxMenux; återställningsstagningen, återställningskopiorna och efteråtsmarkörerna är uteslutna, eftersom de tillhör värden som kör en återställning."
},
{
"category": "ZFS tillstånd (villkor)",
"paths": "/etc/zfs",
"why": "Det ingår endast när källvärden kör ZFS. innehåller <code>zpool.cache</code> och <code>hostid</code>."
}
],
"customTitle": "Utöka profilen med anpassade vägar",
"customBody": "Utöver standardprofilen erbjuder ProxMenux två sätt att inkludera ytterligare vägar i en säkerhetskopia. De komponerar utan konflikt och gäller både interaktiva säkerhetskopior och schemalagda jobb.",
"customExtrasTitle": "1. Persistenta extrafunktioner (per-host-fil)",
"customExtrasBody": "En textfil på <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> innehåller en lista över absoluta vägar som användaren har markerat som \"alltid inkluderar\" på denna värd. När en säkerhetskopia körs i <strong>Default</strong>-läge, appenderar ProxMenux dessa vägar till standardprofilen automatiskt utan att fråga. Filen redigeras från gränssnittet - ingen manuell redigering behövs - och kvarstår över omstart och uppdateringar. En absolut väg per rad; <code>#</code> kommentarer är tillåtna.",
"customModeTitle": "2. Anpassat läge (per körning)",
"customModeBody": "Att starta en säkerhetskopia i <strong>Custom</strong>-läge ersätter den automatiska tillämpningen av standardprofilen med en checklista som visar varje väg: standardprofilerade poster och de ihållande extrafunktionerna (prefixed med <code>[+]</code> och förmarkerade). Användaren markerar eller avmarkerar poster för den specifika körningen, och kan också trycka på <em>Lägg till anpassad sökväg</em> för att ange en ny väg - som sedan kvarstår till extrafilen för framtida säkerhetskopior.",
"customMissingTitle": "Vägar frånvarande från källan",
"customMissingBody": "Varje väg från profilen (standard eller tillägg) som inte finns på källvärden registreras i <code>metadata/missing_paths.txt</code> inuti arkivet. Säkerhetskopieringen misslyckas varken eller slutar - användaren ser en sammanfattning av arkiverade vägar och saknade vägar i slutet. I praktiken sker detta för valfria verktygsvägar som <code>/etc/wireguard</code> eller <code>/etc/prometheus</code> när dessa verktyg inte är installerade."
},
"manifest": {
"heading": "Manifestdelen",
"intro": "<code>manifest.json</code> är ett strukturerat JSON-dokument som beskriver källvärden vid backupen. Den produceras av <strong>sex oberoende insamlare</strong> orkestrerad av <code>build_manifest.sh</code>. Varje samlare läser endast data, producerar ett väldefinierat JSON-fragment och faller tillbaka till ett säkert tomt standard om det misslyckas - manifestet är fortfarande användbart om ett avsnitt är ofullständigt.",
"orchestratorCaption": "De sex samlarna komponerar manifestet. Varje samlare körs i sin egen underprocess; ett misslyckande i en faller tillbaka till en dokumenterad säker standard och varnar men inte avbryter backupen.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
"produces": "source_host",
"content": "Hostname, PVE version (<code>pveversion</code>), PBS version om värden kör backup-server roll, kärna (<code>uname -r</code>), startläge (efi/bios), root filsystem typ, CPU modell + arkitektur, minne i KB."
},
{
"collector": "collect_hardware.sh",
"produces": "hardware_inventory",
"content": "GPU (med leverantör och ProxMenux installer mapping), TPUs (Coral USB + M.2 med <code>lsusb</code> / <code>lspci</code> detektering), NICs (med MAC, PCI slot och bro medlemskap), trådlösa enheter. GPU-poster bär en <code>passthrough_eligible</code>-heuristisk."
},
{
"collector": "collect_storage.sh",
"produces": "storage_inventory",
"content": "ZFS-pooler (med pooltyp + medlemsdisker löste <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> eller rå <code>/dev/sdX</code>-vägar beroende på hur varje pool ursprungligen skapades), LVM-volymgrupper + tunna pooler, fysiska diskar med SMART-kapacitet, PVE <code>storage.cfg</code>-poster, externa monteringar."
},
{
"collector": "collect_kernel.sh",
"produces": "kernel_params",
"content": "Parametrar som operatören lagt till i <code>/proc/cmdline</code>, utan standardposter som <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> och <code>splash</code>; moduler som laddas vid start från <code>/etc/modules</code>; sökvägar till <code>/etc/modprobe.d/*.conf</code>-filer med faktiska direktiv (<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": "Läser <code>/usr/local/share/proxmenux/managed_installs.json</code> (registret över allt ProxMenux har installerat) och <code>installed_tools.json</code>. Varje post håller installationsbanan (<code>menu_script</code>) så att återställningen kan utlösa exakt samma installationsflöde."
},
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
"content": "Uppräknar VMs (<code>qm list</code>) och LXCs (<code>pct list</code>) närvarande vid backuptid - VMID, namn, aktuell status. Endast inventeringen: de faktiska gästdata är <code>vzdump</code>/PBS."
}
],
"schemaTitle": "Schema validering",
"schemaBody": "manifestet validerar mot <code>scripts/backup_restore/schema/manifest.schema.json</code>. Kör <code>build_manifest.sh --validate</code> utlöser en Python-side JSON Schema validering (kräver <code>python3</code> + <code>jsonschema</code>). Om modulen inte är närvarande, är kontrollen hoppad tyst - validering är i första hand ett utvecklarhjälp, inte ett drifttidsberoende."
},
"applications": {
"heading": "Applikationsinventeringen",
"intro": "Två inventeringar listar programvara utöver Proxmox VE:s baspaket: paketlistan under <code>metadata/</code> och komponentregistret i rootfs, som beskrivs nedan. Återställningen använder APT eller ProxMenux egna installationsprogram för att återskapa användarens programvara enligt det ursprungliga installationssättet.",
"packagesTitle": "packages.manual.list",
"packagesBody": "En alfabetisk textlista från <code>apt-mark showmanual</code> med alla APT-paket som <em>uttryckligen installerats</em> på källvärden. Beroenden till Proxmox VE:s bassystem ingår inte; målets APT installerar dem automatiskt. Under återställningen läser <code>_rs_run_complete_extras</code> listan och använder ett <em>filter mot borttagning i kaskad</em> i tre steg: <code>dpkg -s</code> hittar redan installerade paket, andra huvudversioner av bibliotek identifieras och <code>apt-get install --simulate</code> kontrollerar risken för följdborttagningar. Återstående paket installeras med <code>apt-get install -y</code>.",
"componentsTitle": "components_status.json (del av rootfs)",
"componentsBody": "En JSON registret under <code>/usr/local/share/proxmenux/</code> som registrerar varje komponent ProxMenux har installerat med sitt exakta tillstånd: version, ProxMenux-specifika flaggor (för NVIDIA: <code>patched</code> boolean; för Coral: DKMS version). Denna fil lever i rootfs - inte i <code>metadata/</code> - eftersom det är <em>läses efter</em> att rootfs har kopierats till målet. Post-boot dispatcher (<code>apply_cluster_postboot.sh</code>) itererar över sina poster och kör varje komponent <code>--auto-reinstall</code> krok, som läser det inspelade tillståndet och reproducerar installationen mot målets nuvarande kärna.",
"componentInstallersTitle": "Installationsprogram för komponenter",
"componentInstallersBody": "Fyra ProxMenux installatörer exponerar för närvarande en <code>--auto-reinstall</code> ingångspunkt:",
"installerRows": [
{
"component": "nvidia_driver",
"installer": "gpu_tpu/nvidia_installer.sh",
"action": "Läser <code>version</code> + <code>patched</code>. Ladda ner exakt samma NVIDIA runfil, bygger DKMS-moduler mot målets kärna, applicerar ProxMenux-patchen om källan hade den."
},
{
"component": "coral_driver",
"installer": "gpu_tpu/install_coral.sh",
"action": "Läser versionen av Coral-drivrutinen och kompilerar DKMS-modulen för målets kärna."
},
{
"component": "amdgpu_top",
"installer": "gpu_tpu/amd_gpu_tools.sh",
"action": "Läser den inspelade versionen. Laddar ner exakt <code>.deb</code> från GitHub release."
},
{
"component": "intel_gpu_tools",
"installer": "gpu_tpu/intel_gpu_tools.sh",
"action": "APT-installerar paketet. Idempotent om det redan finns från <code>packages.manual.list</code>."
}
]
},
"restoreFlow": {
"heading": "Hur återställningen förbrukar de tre nyttolasterna",
"intro": "Återställningen är en sexstegs pipeline. Varje steg läser en specifik delmängd av arkivet och uppdaterar målvärden. Inget stadium kräver att källvärden kan nås - arkivet är helt fristående.",
"stagesCaption": "Steg 1 använder manifestet för att bestämma vad du ska röra. Steg 2 kopierar rootfs vägar som är säkra att tillämpa på ett körsystem. Stadium 3 iscensätter de riskfyllda vägarna för nästa start. Steg 3b importerar icke-rot ZFS datapooler vars diskar är alla närvarande. Steg 4 hanterar paket. Stage 5 körs efter omstart och ominstallerar komponenter mot målets kärna.",
"stageRows": [
{
"stage": "1",
"name": "Kompatibilitetskontroll",
"reads": "manifest.json",
"action": "Kör <code>hb_compat_check</code>. Jämför källa vs mål hårdvara (NIC, lagrings-ID), PVE-version och stor kärnversion. Set <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> eller <code>bk_older</code>) och befolkar <code>RS_SKIP_PATHS</code> med hårdvara-drift och cross-kernel uteslutningar."
},
{
"stage": "2",
"name": "Tillämpning under drift",
"reads": "rootfs/ (endast säkra vägar)",
"action": "<code>_rs_apply … hot</code> kopierar <code>hb_classify_path</code>=<code>hot</code>-poster direkt till live-målet. Allt under <code>/etc/pve</code>, <code>/etc/network</code> eller vägar som klassificeras som <em>reboot</em>/<em>dangerous</em> uppskjuts."
},
{
"stage": "3",
"name": "Förbered uppskjutna ändringar",
"reads": "rootfs/ (omstart + farliga vägar)",
"action": "<code>_rs_prepare_pending_restore</code> förbereder riskfyllda sökvägar under <code>/var/lib/proxmenux/pending-restore/</code>, skriver <code>plan.env</code>, <code>apply-on-boot.list</code> och <code>rs-skip-paths.txt</code> och aktiverar <code>proxmenux-restore-onboot.service</code> för nästa start."
},
{
"stage": "3b",
"name": "Datapool import",
"reads": "manifest.storage_inventory + mål ZFS tillstånd",
"action": "<code>_rs_import_data_pools</code> försöker importera varje ZFS-pool utan rotfilsystem vars samtliga diskar finns på målet. Pooler med ett annat hostid provas igen med <code>zpool import -f</code>. Om någon disk saknas hoppas poolen över med en varning. Resultatet per pool loggas i <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
},
{
"stage": "4",
"name": "Paketinstallation",
"reads": "metadata/packages.manual.list",
"action": "<code>_rs_run_complete_extras</code> kör kaskadsäkert filter och kallar <code>apt-get install -y</code> med den överlevande paketlistan. Fullständig utdata går till <code>/var/log/proxmenux/restore-apt-*.log</code>."
},
{
"stage": "5",
"name": "Efter uppstart",
"reads": "rootfs (redan tillämpat) + components_status.json",
"action": "Efter omstart, <code>apply_pending_restore.sh</code> spelar tillbaka de uppskjutna banorna och <code>apply_cluster_postboot.sh</code> kör <code>update-initramfs</code>, <code>update-grub</code> (eller <code>proxmox-boot-tool refresh</code>) och itererar över <code>components_status.json</code> skjuter varje komponent <code>--auto-reinstall</code> krok."
}
]
},
"whyItWorks": {
"heading": "Varför säkerhetskopian delas i tre delar",
"body": "Uppdelningen följer uppgifternas <strong>livscykel</strong>. Filsystemet överförs med <code>rsync</code>: snabbt, öppet och atomärt per fil. Konfigurationstillstånd som måste tolkas före ändringar lagras som <strong>strukturerad JSON</strong>, läsbar för sig, versionshanterbar med schema och maskinellt jämförbar med målets tillstånd. Programvara som ska installeras om beskrivs i en <strong>inventering</strong> med namn och versioner; målets pakethanterare och ProxMenux installationsprogram väljer rätt binärer. Varje del fyller sin egen uppgift. Tillsammans eftersträvar de en sammanhängande återställning med feltolerans: ett skadat manifest lämnar rootfs återställbart, ett saknat paket hindrar inte komponentinstallation och ett fel för en post stoppar inte nästa."
}
}
web/messages/sv/docs/backup-restore/index.json
+93
View File
@@ -0,0 +1,93 @@
{
"meta": {
"title": "ProxMenux Säkerhetskopiering och återställning — Översikt | Fullständig säkerhetskopiering och återställning av värd för Proxmox VE",
"description": "ProxMenux Backup & Restore fångar det fullständiga tillståndet för en Proxmox-värd – filsystem, strukturerat konfigurationsmanifest och installerade paket/komponenter – och återskapar det på samma eller en annan värd. Säkerhetskopieringen och återställningen är fristående: inga externa beroenden, och återställningar över kärnor stöds genom ett riktningsmedvetet filter för säker delmängd och kärnagnostisk hydrering.",
"ogTitle": "ProxMenux Säkerhetskopiering och återställning — Översikt",
"ogDescription": "Fullständig säkerhetskopiering och återställning av värd för Proxmox VE med strukturerat manifest, paketlista och ominstallerare av komponenter.",
"twitterTitle": "ProxMenux Säkerhetskopiering och återställning | ProxMenux",
"twitterDescription": "Fullständig säkerhetskopiering och återställning av värd för Proxmox VE med strukturerat manifest, paketlista och ominstallerare av komponenter."
},
"header": {
"title": "Säkerhetskopiering och återställning",
"description": "Säkerhetskopiering av hela värden och återställning för Proxmox VE. Fångar filsystem, konfiguration och installerade komponenter i ett enda arkiv och återskapar värden på samma eller en annan Proxmox-installation utan externa beroenden.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "Vad det är, i ett stycke",
"body": "En ProxMenux-säkerhetskopia sparar hela tillståndet för en Proxmox-värd: <strong>filsystemet</strong>, med relevanta kataloger under <code>/etc</code>, <code>/root</code> och <code>/var/lib/pve-cluster</code> samt valfria egna sökvägar; <strong>ett strukturerat manifest</strong> i JSON med upptäckt maskinvara, kärnparametrar, nätverkskonfiguration, ZFS-status, användare och cron-poster; och <strong>en programinventering</strong> med paket som APT markerar som manuellt installerade samt komponenter som ProxMenux installerat, med exakta versioner. Alla tre mål som stöds – lokalt arkiv, Proxmox Backup Server (rekommenderas) och Borg – får samma fristående innehåll. Vart och ett kan användas för att återskapa målvärden utan att källvärden behöver vara nåbar under återställningen."
},
"video": {
"heading": "Videogenomgång",
"intro": "Föredrar du att titta på Backup & Restore i aktion innan du konfigurerar det? Den här genomgången täcker en fullständig demo av funktionen i ProxMenux.",
"title": "ProxMenux – genomgång för säkerhetskopiering och återställning",
"caption": "Extern video på YouTube. Spelas upp i integritetsförbättrat läge (inga cookies förrän du trycker på play)."
},
"whatItIsNot": {
"heading": "Vad det inte är",
"intro": "Det här avsnittet gäller säkerhetskopiering och återställning <strong>av värden</strong>: själva Proxmox-installationen, inte de program och gästsystem som körs på den.",
"items": [
"<strong>Det här är inget verktyg för säkerhetskopiering av VM:ar eller CT:er.</strong> Funktionen sparar varken gästernas diskar eller RAM-tillstånd; det sköts av <code>vzdump</code>. Gästernas <strong>konfigurationsfiler</strong> (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> och <code>lxc/*.conf</code>) <strong>ingår däremot</strong>. Efter återställning visas inventeringen igen, och diskarna kan återställas eller anslutas från en befintlig PBS- eller lokal säkerhetskopia.",
"<strong>Det här är ingen åtgärd för hela klustret.</strong> Varje nod säkerhetskopierar sig själv. Klustertillhörigheten sparas i <code>/etc/pve</code> så att en återställd nod kan anslutas igen, men återställning av hela klustret kräver samordning mellan noderna.",
"<strong>Det här är ingen fullständig diskavbildning.</strong> Kärnans binärfiler, initramfs och startpartitionen ingår inte. Vid återställning använder ProxMenux målvärdens egna startfiler, som återskapas automatiskt av <code>update-initramfs</code> och starthanterarens verktyg, och installerar drivrutiner som passar målets körande kärna."
]
},
"threePillars": {
"heading": "De tre pelarna i en säkerhetskopia",
"intro": "Ett ProxMenux arkiv är uppbyggt kring tre fristående nyttolaster. Återställningen använder alla tre tillsammans för att reproducera källvärden på ett mål som kanske inte ens har samma kärna installerad.",
"diagramCaption": "Varje säkerhetskopia innehåller samma tre datablock oavsett destination. Återställningen använder alla tre: rootfs för att återställa filerna, manifestet för att upptäcka avvikelser och skillnader mellan kärnversioner samt programinventeringen för att installera om paket och komponenter för målets egen kärna.",
"pillar1Label": "Filsystem",
"pillar1Detail": "rootfs/\n(rsync av /etc,\n/etc/systemd/network,\n/root, samt en\nsqlite3-ögonblicksbild\nav /var/lib/pve-cluster,\n+ valfria sökvägar)",
"pillar2Label": "Manifest",
"pillar2Detail": "manifest.json\n(maskinvara, kärn-\nparametrar, nätverk,\nZFS, användare, cron,\nZFS-pooler, lagring)",
"pillar3Label": "Applikationer",
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(manuella APT-paket + ProxMenux-\ninstallationsprogram med versioner)"
},
"restoreIsUniversal": {
"heading": "Återställningen återger källvärden, inte arkivet",
"body": "En återställning av en ProxMenux-säkerhetskopia packar inte bara upp filsystemet. Återställningen läser manifestet för att upptäcka avvikelser mellan källa och mål (maskinvaruskillnader, namnbyten på nätverkskort, kärnversion och ZFS-poolens identitet), återställer filsystemet och startar sedan rätt komponentinstallerare för varje tjänst som fanns på källan (NVIDIA-drivrutin, Coral TPU samt GPU-verktyg för AMD och Intel). Varje installerare körs för <strong>målets aktuella kärna</strong>, så den återställda värden är inte beroende av att källans kärna finns kvar. När målets kärna är nyare än säkerhetskopians sammanfogar en kärnoberoende <strong>hydrering</strong> användarens egna inställningar (IOMMU-token, VFIO-enhets-ID:n, särskilda anpassningar och GRUB-nycklar) med målets nya startkonfiguration utan att kopiera kärnbundna filer ordagrant."
},
"twoInterfaces": {
"heading": "Två gränssnitt, en backend",
"intro": "Varje steg i arbetsflödet för säkerhetskopiering och återställning är tillgängligt från två ingångspunkter. Båda anropar samma skalbibliotek, producerar identiska arkiv och läser samma jobbregister.",
"cliLabel": "ProxMenux Scripts (TUI)",
"cliDetail": "meny → Verktyg →\nVärdsäkerhetskopiering/återställning\n\nDialogbaserat flöde,\nSSH-vänlig, skriptbar\nför obevakad användning.",
"webLabel": "ProxMenux Monitor (Webb UI)",
"webDetail": "Backups-fliken i\nMonitors webbgränssnitt.\n\nÅterställning med ett klick,\nlöpande loggvisning, integrerat\nmed aviseringar och visning\nav skillnader vid återställning."
},
"whereNext": {
"heading": "Vart ska man gå härifrån",
"intro": "Varje underavsnitt nedan täcker en aspekt av arbetsflödet på djupet. Börja med <em>Hur det fungerar</em> om målet är att förstå vad arkivet innehåller och varför. Hoppa till <em>Destinationer</em> för att konfigurera målet för kopian. Läs <em>Återställning</em> och <em>Återställning mellan kärnversioner</em> för återställningssidan.",
"items": [
{
"label": "Så fungerar det",
"href": "/docs/backup-restore/how-it-works",
"tail": "— de tre nyttolasterna (rootfs, manifest, applikationer) i detalj, med de samlare som producerar dem och formatet för varje fil."
},
{
"label": "Destinationer",
"href": "/docs/backup-restore/destinations",
"tail": "— jämförelse av lokal, Proxmox Backup Server (rekommenderas) och Borg, och hur man konfigurerar var och en."
},
{
"label": "Skapa säkerhetskopior",
"href": "/docs/backup-restore/creating-backups",
"tail": "— engångssäkerhetskopior, standardsökvägsprofilen, lägga till anpassade sökvägar, kryptering för PBS."
},
{
"label": "Schemalagda jobb",
"href": "/docs/backup-restore/scheduled-jobs",
"tail": "— nya jobb kontra att koppla till ett befintligt PVE vzdump-jobb, schemaläggningsformat, jobbdetaljmodal."
},
{
"label": "Återställning",
"href": "/docs/backup-restore/restoring",
"tail": "— de tre åtgärderna i ett arkiv (visa, ladda ner, återställ), Komplett vs. anpassad återställning, post-boot-dispatcher och varför de sista tio minuterna är viktiga."
},
{
"label": "Återställning mellan kärnversioner",
"href": "/docs/backup-restore/cross-kernel",
"tail": " — beteende som tar hänsyn till riktningen på versionsbytet när målets kärna skiljer sig från säkerhetskopians, filtret för en säker delmängd och de fyra hydreringsfaserna."
}
]
}
}
web/messages/sv/docs/backup-restore/restoring.json
+282
View File
File diff suppressed because one or more lines are too long
web/messages/sv/docs/backup-restore/scheduled-jobs.json
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Schemalagda jobb — timers, kopplingsläge, bevarande | ProxMenux",
"description": "Schemalagda ProxMenux-jobb för säkerhetskopiering av värden. Två sätt att skapa jobb (egen systemd-timer eller koppling till ett befintligt PVE vzdump-jobb), bevaranderegler per jobb via proxmox-backup-client, Borg eller lokal rensning, filer under /var/lib/proxmenux/backup-jobs och körningsskriptet som skapar samma arkiv som det interaktiva flödet.",
"ogTitle": "ProxMenux Backup - schemalagda jobb",
"ogDescription": "Obevakade schemalagda värdsäkerhetskopior med kopplingsläge, bevaranderegler och samma tre destinationer som det interaktiva flödet.",
"twitterTitle": "Planerade jobb | ProxMenux",
"twitterDescription": "Obevakade schemalagda värdsäkerhetskopieringsjobb med kopplingsläge och bevaranderegler."
},
"header": {
"title": "Planerade jobb",
"description": "Obevakade jobb för säkerhetskopiering av värden. Två modeller: ett nytt oberoende jobb med eget schema eller ett jobb kopplat till ett befintligt PVE vzdump-jobb som ärver dess schema och bevaranderegler. Båda skapar samma arkiv som det interaktiva flödet.",
"section": "Säkerhetskopiering och återställning"
},
"intro": {
"title": "De två modellerna för schemalagda jobb",
"body": "Ett schemalagt jobb kan skapas efter en av två modeller:",
"modelsList": [
"<strong>Nytt oberoende jobb</strong> - ProxMenux definierar själva arbetsschemat med sin egen systemd timer, oberoende av någon annan uppgift på värden. Kompatibel med alla tre destinationer: Lokal, PBS och Borg.",
"<strong>Koppla till ett befintligt PVE vzdump-jobb</strong> — jobbet har inget eget schema; det körs automatiskt när det överordnade vzdump-jobbet säkerhetskopierar värdens VM:ar och LXC:er. Det ärver schemat och bevarandereglerna. Stöder lokalt mål och PBS (Borg stöds inte eftersom PVE saknar en inbyggd schemaläggare för Borg)."
]
},
"attachBadge": {
"title": "Kopplingsläge — rekommenderas när ett PVE vzdump-jobb redan finns",
"body": "Om ett PVE vzdump-jobb redan är konfigurerat för nodens VM:ar och LXC:er körs den kopplade värdsäkerhetskopieringen efter gästernas säkerhetskopiering, i <strong>samma säkerhetskopieringscykel</strong>. Vid återställning kommer gästkonfigurationerna från värdsäkerhetskopian (under <code>/etc/pve</code>) och gästdiskarna från cykelns vzdump-kopior. Detta underlättar samordnad återställning av hela noden men är ingen atomär ögonblicksbild: ändringar under cykeln kan ge skillnader mellan värdkonfiguration och gästernas disktillstånd."
},
"frequencyBadge": {
"title": "Rekommenderad frekvens",
"body": "Säkerhetskopiera värden ofta för att maximera kompatibiliteten med en framtida återställning. Ju närmare säkerhetskopian ligger värdens aktuella tillstånd, desto färre avvikelser i konfiguration, paket och komponenter måste återställningen hantera."
},
"modes": {
"heading": "De två lägena",
"rows": [
{
"mode": "Nytt schemalagt jobb",
"backends": "Lokalt, PBS, Borg",
"schedule": "Egen <code>OnCalendar</code> uttryck (systemd kalendersyntax - t.ex. <code>daily</code>, <code>Mon..Fri 03:00</code>).",
"retention": "Efterfrågas separat: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Tillämpad av körningsskriptet efter varje framgångsrik backup."
},
{
"mode": "Bifoga till ett PVE vzdump jobb",
"backends": "Lokal, PBS (Borg har ingen PVE-sida schemaläggning)",
"schedule": "Ärvd från föräldern PVE jobb. Ingen systemd-timer installeras på ProxMenux-sidan.",
"retention": "Ärvd från förälderns <code>prune-backups</code>-konfiguration (mappade en-till-en till körningsskriptets <code>KEEP_*</code>-variabler via <code>hb_pve_prune_to_keep_env</code>)."
}
]
},
"attachDetail": {
"heading": "Så fungerar kopplingsläget",
"intro": "PVE skriver <code>vzdump</code>-jobb till <code>/etc/pve/jobs.cfg</code>, med ett avsnitt per jobb som anger lagringen för VM- och LXC-kopiorna. Kopplingsläget kräver en backend som ProxMenux stöder (lokalt eller PBS). Värdsäkerhetskopieringen körs via job-end-hooken efter att gästernas säkerhetskopieringsjobb avslutats.",
"steps": [
{
"step": "1",
"detail": "Under jobbskapande listar ProxMenux kompatibla förälder PVE-uppgifter via <code>hb_pve_list_vzdump_jobs_for_backend</code>. Användaren väljer en."
},
{
"step": "2",
"detail": "Jobbets <code>.env</code> är skrivet med <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> och de ärvda <code>KEEP_*</code> värdena; ingen systemd timer skapas."
},
{
"step": "3",
"detail": "<code>hb_install_vzdump_hook</code> registrerar en skripthook i <code>/etc/vzdump.conf</code>. I job-end-fasen för varje vzdump-jobb jämförs mottaget <code>$STOREID</code> med <code>PVE_STORAGE</code> för varje aktiverat kopplat jobb, och körningsskriptet startas för matchande jobb. Matchningen görs efter lagring, inte efter det valda överordnade jobbets ID."
},
{
"step": "4",
"detail": "Arkivet sparas i samma lagring som vzdump-kopiorna: <code>path/dump/</code> för lokalt mål eller PBS-arkivlagret som konfigurerats i PVE-lagringsposten."
}
],
"outroBody": "Kopplingsläget har ingen egen timer. Om det valda överordnade PVE-jobbet inaktiveras eller tas bort stoppas dess utlösning, men ett annat vzdump-jobb med samma lagring kan fortfarande starta värdsäkerhetskopieringen. Inaktivera eller ta bort själva ProxMenux-jobbet för att förhindra det. Vid inaktivering ligger jobbposten kvar och kan senare aktiveras eller kopplas igen."
},
"storageLayout": {
"heading": "Filer som utgör ett jobb",
"intro": "Varje schemalagt jobb beskrivs fullständigt av tre eller fyra filer på disken. Att läsa dem ger hela konfigurationen av jobbet utan att förlita sig på gränssnittet.",
"rows": [
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
"content": "Backend, backup-ID eller destination, schema (nyt läge) eller PVE-förälder (Attach-läge), aktiverad flagga, lagring <code>KEEP_*</code>-värden, referenspekare."
},
{
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
"content": "En absolut sökväg per rad — valet från profilen fastställs när jobbet skapas. Om filen redigeras används det nya valet nästa gång timern löser ut."
},
{
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
"content": "Nytt läge bara. Tjänsten anropar <code>run_scheduled_backup.sh JOB_ID</code>. Timern schemalägger det med <code>Persistent=true</code> (missade körningar utförs vid nästa start) och en liten <code>RandomizedDelaySec=120</code> att sprida belastning när flera jobb delar samma OnCalendar uttryck."
},
{
"path": "/etc/vzdump.conf script-hook",
"content": "Fäst läge bara. Installerad en gång av <code>hb_install_vzdump_hook</code>; matchar varje bifogat jobb <code>PVE_STORAGE</code> mot <code>$STOREID</code> PVE passerar till krokskriptet."
}
]
},
"runner": {
"heading": "Vad ett jobb gör när det startar",
"intro": "Varje jobb – oavsett om det är nymodell eller bifogad – kör samma trestegssekvens:",
"steps": [
"<strong>Förbered säkerhetskopian.</strong> Läser jobbkonfigurationen (destination, profil, vägar) och monterar arkivträdet exakt på samma sätt som det interaktiva flödet gör. Resultatet är samma arkiv som en manuell säkerhetskopia med dessa inställningar skulle producera.",
"<strong>Skriv till destinationen.</strong> Laddar eller skriver arkivet till den konfigurerade destinationen - en lokal <code>.tar.zst</code> fil, en PBS backup, eller ett Borg-arkiv - med exakt samma verktyg och referenser en manuell säkerhetskopia till samma destination skulle använda.",
"<strong>Tillämpa bevaranderegler.</strong> Ta bort gamla säkerhetskopior från destinationen, hålla <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> räknas konfigurerade på jobbet. Pruning utförs av själva destinationen: PBS tillämpar sina egna bevaranderegler, Borg kör <code>borg prune</code>, och för Local ProxMenux raderar filerna som faller utanför <code>keep-last</code>-fönstret."
]
},
"management": {
"heading": "Hantera jobb",
"intro": "Schemaläggarmenyn (Scripts TUI) och fliken Monitor Backups avslöjar samma åtgärder på något jobb.",
"rows": [
{
"action": "Kör nu",
"detail": "Anropar körningsskriptet omedelbart utan att vänta på timern eller vzdump-hooken. Användbart för att verifiera konfigurationen utan att vänta till nästa schemalagda körning."
},
{
"action": "Aktivera / Inaktivera",
"detail": "Nytt läge: <code>systemctl enable/disable --now</code> timern. Bifoga läge: vänder <code>ENABLED</code> flaggan i jobbenv - krokskriptet respekterar den vid nästa PVE-körning."
},
{
"action": "Redigera",
"detail": "Öppnar åter dialogerna för destination, schema, profil och bevarande och skriver om jobbfilerna. Jobb-ID:t behålls."
},
{
"action": "Ta bort",
"detail": "Tar bort jobbets env-fil, sökvägsfilen och systemd-timern med tjänsten (nytt läge) samt inaktiverar hookkopplingen (kopplingsläge). Arkiv som redan finns på destinationen påverkas inte."
},
{
"action": "Visa logg",
"detail": "Strömmar <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — en loggfil per körning. Körningsskriptet sänder också ut en kompakt statusrad till journald under tjänsten systemd."
}
]
},
"notifications": {
"heading": "Aviseringar",
"body": "Varje schemalagd körning utlöser samma <code>hb_notify_lifecycle</code> händelser som det interaktiva flödet (<code>start</code>, <code>complete</code>, <code>fail</code>). Om meddelandekanaler är konfigurerade i Monitor, obevakade jobb visar sina resultat på samma sätt manuella säkerhetskopior gör - en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades."
},
"whereNext": {
"heading": "Nästa steg",
"items": [
{
"label": "Skapa backups",
"href": "/docs/backup-restore/creating-backups",
"tail": " - det interaktiva flödet som delar backend med schemaläggaren."
},
{
"label": "Destinationer",
"href": "/docs/backup-restore/destinations",
"tail": " — per-backend konfiguration som används av både det interaktiva flödet och schemaläggaren."
},
{
"label": "Återställande",
"href": "/docs/backup-restore/restoring",
"tail": " — flödet som använder de säkerhetskopior som jobben skapar."
}
]
}
}