diff --git a/web/messages/de/docs/backup-restore/creating-backups.json b/web/messages/de/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..b33b1a24
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/creating-backups.json
@@ -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 genau dieselben Funktionen. Jedes Backup — manuell oder geplant — durchläuft dieselbe Auswahlmatrix (drei Ziele × zwei Profile) und ruft pro Zelle dieselbe Backend-Funktion auf (_bk_pbs, _bk_borg oder _bk_local). 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 backup_menu in backup_host.sh."
+ },
+ {
+ "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: manuell (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 geplant (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 run_scheduled_backup.sh; 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 .tar.zst-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 .tar.zst."
+ }
+ ]
+ },
+ "profiles": {
+ "heading": "Standardprofil und benutzerdefiniertes Profil",
+ "defaultTitle": "Standardprofil",
+ "defaultBody": "Das Standardprofil ist die kuratierte Liste aus hb_default_profile_paths (dokumentiert in Funktionsweise unter Pfadkategorien) sowie jeder Eintrag in der persistenten Extras-Datei /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). Der Benutzer markiert die Pfade für diesen Durchlauf und kann über Benutzerdefinierten Pfad hinzufügen einen neuen absoluten Pfad ergänzen. Jeder dabei hinzugefügte Pfad wird in backup-extra-paths.txt 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 Benutzerdefinierte Pfade verwalten.",
+ "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. hb_prepare_staging stellt den Archivbaum in /tmp/proxmenux-DESTINATION-stage.XXXXXX zusammen und füllt jede der drei Nutzlasten aus.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "rootfs zusammenstellen",
+ "detail": "Führt rsync -a für jeden ausgewählten Pfad in staging_root/rootfs/ aus. Die pmxcfs-Datenbank bei /var/lib/pve-cluster/config.db wird separat über sqlite3 .backup erfasst, um einen konsistenten Snapshot zu erstellen, ohne den Cluster zu stoppen, und die .db-wal / .db-shm Sidecars sind vom rsync ausgeschlossen; Wenn sqlite3 nicht verfügbar ist, wird stattdessen eine Datei config.db.raw-fallback abgelegt, die bei der Wiederherstellung während des Imports als Datenbank übernommen wird. Flüchtige Subpfade (Bash-Historie, Caches, Trash) sind von /root/ ausgeschlossen. Pfade, die in der Quelle fehlen, werden in metadata/missing_paths.txt aufgezeichnet, ohne das Backup zu stoppen."
+ },
+ {
+ "step": "2",
+ "name": "Manifest erstellen",
+ "detail": "build_manifest.sh steuert die sechs Datensammler und schreibt manifest.json 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": "apt-mark showmanual wird wortwörtlich in metadata/packages.manual.list erfasst. Der Komponentenzustand befindet sich bereits innerhalb der wiederhergestellten Rootfs (components_status.json), da /usr/local/share/proxmenux/ Teil des Standardprofils ist."
+ },
+ {
+ "step": "4",
+ "name": "Informationen zum Durchlauf",
+ "detail": "metadata/run_info.env 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": "hb_notify_lifecycle \"start\" wird ausgelöst. Sind im Monitor Benachrichtigungen konfiguriert, wird das Ereignis Host-Backup gestartet 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 rsync -aAXH --numeric-ids 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": [
+ "images/ — Image Dumps.",
+ "dump/ — Ausgaben von vzdump.",
+ "tmp/ — temporäre Dateien.",
+ "*.log — Protokolldateien."
+ ],
+ "rootTitle": "/root/ Ausschlüsse",
+ "rootBody": "/root/ ist Teil des Standardprofils, sodass Benutzerskripte und Konfigurationen im Archiv landen. Flüchtige Subpfade werden fallen gelassen:",
+ "rootItems": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "/usr/local/share/proxmenux/ Ausschlüsse",
+ "proxmenuxBody": "Dieses Verzeichnis liefert nur Benutzerstatus - components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Pfade außerhalb des Profils",
+ "notInProfileBody": "Alles, was nicht in hb_default_profile_paths aufgeführt ist und nicht als benutzerdefiniertes oder persistentes Extra hinzugefügt wurde, ist nicht Teil des Backups. Bemerkenswerte Beispiele:",
+ "notInProfileItems": [
+ "VM und LXC Festplatten — werden von vzdump behandelt, nicht von dieser Funktion. Gastkonfigurationsdateien unter /etc/pve/nodes/*/qemu-server/*.conf und lxc/*.conf werden erfasst (sie leben unter /etc/pve), so dass die Wiederherstellung das Inventar reproduziert; die Festplatten selbst werden von einem vorhandenen vzdump / PBS-Backup neu angehängt.",
+ "/boot und /boot/efi — Kernel-Binärdateien, Initramfs und die UEFI-ESP-Partition werden nach der Wiederherstellung durch die eigenen update-initramfs, update-grub oder proxmox-boot-tool refresh des Ziels regeneriert. Der Bootloader wird niemals wörtlich kopiert.",
+ "Kernel und Systemlaufzeit-Dateisysteme — /proc, /sys, /dev und /run sind Pseudo-Dateisysteme, die vom Kernel und von udev erzeugt werden; sie werden nirgendwo persistent.",
+ "Paket-Binärdateien unter /usr/bin, /usr/lib, /lib, /sbin — vom APT des Ziels aus packages.manual.list neu installiert.",
+ "/var/log/, /var/tmp/, /var/cache/ — Laufzeitzustand pro Host, nicht wiederhergestellt.",
+ "/home/USER — 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 backup-extra-paths.txt persistiert wurde, durchläuft dieselbe rsync-Pipeline wie Standardprofilpfade. Globale Ausschlüsse gelten. Wenn der benutzerdefinierte Pfad unter /root/ oder /usr/local/share/proxmenux/ liegt, gelten die oben genannten pfadspezifischen Ausschlüsse weiterhin. Jeder archivierte Pfad – standardmäßig oder benutzerdefiniert – wird in metadata/paths_archived.txt aufgezeichnet. Pfade, die in der Quelle nicht vorhanden sind, werden in metadata/missing_paths.txt 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 .pxar 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 trap-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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar legt einen *.proxmenux.json 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": "hb_notify_lifecycle \"complete\" oder \"fail\" 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/cross-kernel.json b/web/messages/de/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..fb78e27e
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve identifiziert. Die ersten beiden Zahlen (6.17 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 hb_compat_check den im Backup-Manifest aufgezeichneten Kernel mit dem aktuellen Kernel des Ziels (uname -r) und klassifiziert die Wiederherstellung in einen von drei Fällen, die in der internen Variable HB_COMPAT_KERNEL_DIRECTION 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 same. 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 älteren-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 uname -r 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 intel_iommu=on 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 hb_unsafe_paths_cross_version zu RS_SKIP_PATHS 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid), der den Pool als fremd sperren kann."
+ },
+ {
+ "category": "APT-Quellen",
+ "paths": "/etc/apt",
+ "reason": "APT-Source-Suiten können beim nächsten Upgrade ein Downgrade kritischer Pakete auslösen."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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 GRUB_TIMEOUT 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). _rs_hyd_grub führt jedes Token aus dem manifest.kernel_params.cmdline_extra des Backups in das GRUB_CMDLINE_LINUX_DEFAULT des Ziels ein und überspringt Token, deren Schlüssel das Ziel bereits trägt. Dann werden die GRUB_*-Schlüssel auf der weißen Liste (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) aus dem /etc/default/grub 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). _rs_hyd_kernel_cmdline verschmilzt Benutzer-Token von cmdline_extra in /etc/kernel/cmdline des Ziels, wobei die eigene root=, boot= und rootflags= Boilerplate des Ziels intakt bleibt."
+ },
+ {
+ "phase": "2 — /etc/modules-Merge",
+ "detail": "_rs_hyd_modules fügt Module aus manifest.kernel_params.modules_loaded_at_boot hinzu, die sich in der Whitelist befinden (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) UND nicht bereits im /etc/modules des Ziels vorhanden sind."
+ },
+ {
+ "phase": "3 — Kopie von Dateien auf der weißen Liste",
+ "detail": "_rs_hyd_files kopiert vom Benutzer verfasste Dateien von den Staging-Rootfs zum Live-Ziel, wenn sich der Inhalt unterscheidet. Whitelist umfasst VFIO/nvidia / Blacklist-Dateien unter /etc/modprobe.d, /etc/modules-load.d und die ProxMenux VFIO Binderegel + nvidia udev Regeln unter /etc/udev/rules.d. Distro-eigene Dateien (pve-blacklist.conf, mdadm.conf, nvme.conf) 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 HB_HYDRATION_APPLIED=1 durch plan.env bis apply_pending_restore.sh aus, was NEEDS_INITRAMFS=1 und NEEDS_GRUB=1 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 _rs_apply_bk_older_hydration im plan-Modus aus: Es berechnet genau, was zusammengeführt werden würde, füllt RS_HYDRATION_SUMMARY 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 commit-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 intel_iommu=on iommu=pt in der cmdline, vfio/vfio_pci/vfio_iommu_type1 in /etc/modules, ein /etc/modprobe.d/vfio.conf mit options vfio-pci ids=10de:2216 und ein /etc/modprobe.d/blacklist-nvidia.conf. Hydration führt die Cmdline-Token in die GRUB- oder Kernel-Cmdline des Ziels ein, fügt die vfio-Module an /etc/modules 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 GRUB_TIMEOUT=1 und GRUB_DISABLE_OS_PROBER=true. Hydration liest beide Schlüssel aus dem /etc/default/grub 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 GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Alles außerhalb dieses Sets - benutzerdefinierte Initramfs-Hooks unter /etc/initramfs-tools/hooks/, nicht auf der weißen Liste stehende Dateien unter /etc/modprobe.d/, vom Benutzer verfasste systemd-Unit-Overrides - bleibt ausgeschlossen. Der Grund dafür ist konkret: Diese Dateien können Kernel-interne Schnittstellen (Modul-APIs, /sys-Layout, udev-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": "hb_compat_check in lib_host_backup_common.sh. Setzt HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Liste sicherer Teilstrecken",
+ "location": "hb_unsafe_paths_cross_version in lib_host_backup_common.sh. Sendet path\\treason-Linien aus, die sowohl vom CLI-Filter als auch vom Web-Endpunkt /api/host-backups/restore/prepare verwendet werden."
+ },
+ {
+ "component": "Hydratationsphasen",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files in backup_host.sh. Orchestriert von _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Neubildung nach dem Booten erzwingen",
+ "location": "apply_pending_restore.sh liest HB_HYDRATION_APPLIED von plan.env und zwingt NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Web Preview",
+ "location": "/api/host-backups/restore/prepare in flask_server.py. Lädt die Hilfsbibliothek, führt _rs_apply_bk_older_hydration 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 kernel_params erzeugen."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/destinations/borg.json b/web/messages/de/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..1f4fea6f
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/destinations/borg.json
@@ -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 borg create zum Backup-Zeitpunkt und borg extract 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 hb_ensure_borg die Binärdatei in der Reihenfolge aus vier Quellen auf und gibt die erste zurück, die funktioniert:",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Systemweites borg",
+ "detail": "Wenn der Host bereits borg über APT installiert hat (which borg löst auf), wird diese Binärdatei verwendet."
+ },
+ {
+ "priority": "2",
+ "source": "State-Dir-Cache",
+ "detail": "/usr/local/share/proxmenux/borg — aus einem früheren GitHub-Download auf diesem Host aufbewahrt."
+ },
+ {
+ "priority": "3",
+ "source": "AppImage-Paket des Monitors",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — der AppImage bündelt einen signierten borg-linux64. Dies ist der offline-sichere Pfad: Ein Host ohne Internet hat immer noch einen funktionierenden borg."
+ },
+ {
+ "priority": "4",
+ "source": "GitHub Download",
+ "detail": "wget gegen die angepinnte borg-linux64-URL unter github.com/borgbackup/borg/releases/, verifiziert gegen eine Konstante SHA-256 in lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve 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 hb_prompt_mounted_path 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 remote 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 /usr/bin/borg",
+ "detail": "Die Zeile command=\"/usr/bin/borg serve ...\", die ProxMenux in authorized_keys einträgt, verwendet diesen festen Pfad. APT (apt install borgbackup) installiert das Programm dort. Für eine separat installierte Binärdatei ist ein symbolischer Link unter /usr/bin/borg nötig."
+ },
+ {
+ "requirement": "Ein dediziertes Benutzerkonto (normalerweise borg)",
+ "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. /backup/borgbackup) muss auf dem Server vorhanden sein und im Besitz des borg-Benutzers sein."
+ },
+ {
+ "requirement": "SSH Daemon akzeptiert den Borg-Benutzer",
+ "detail": "PubkeyAuthentication yes (Standard). Die Passwort-Authentifizierung wird nur für den One-Shot generate-auto-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 generate-auto den Schlüssel über ein Konto mit Schreibzugriff auf die authorized_keys-Datei des borg-Benutzers. Spätere Backups verwenden diesen auf borg serve 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 borg serve ausgeführt wird. Dieser Benutzer heißt normalerweise borg, 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, Port 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 ~/.ssh/borg_proxmenux_HOST_ed25519. Mit sshpass prüft es die Anmeldung und installiert den öffentlichen Schlüssel in ~borg/.ssh/authorized_keys. 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 authorized_keys-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 pct exec vom PVE-Host - root auf dem PVE-Host schreibt in den ~borg/.ssh/authorized_keys des LXC, ohne dass SSH selbst in den LXC benötigt wird."
+ },
+ {
+ "mode": "existing",
+ "label": "Verwenden Sie einen vorhandenen Schlüssel",
+ "detail": "ProxMenux scannt /root/.ssh/ und $HOME/.ssh/ 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 ~/.ssh/id_rsa 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 authorized_keys-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 command= zwingt jede SSH-Sitzung mit diesem Schlüssel, nur den Befehl borg-serve auszuführen; restrict 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: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. hb_collect_borg_configs liest sie ein, um das Zielauswahlmenü zu füllen."
+ },
+ {
+ "file": "borg-pass-NAME.txt",
+ "content": "Passphrase des oben mit NAME benannten Ziels (chmod 600). 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 hb_borg_init_if_needed initialisiert: das moderne borg repo-create -e MODE, wenn verfügbar, oder das alte borg init --encryption=MODE. ProxMenux zeigt zwei Modi: repokey (Standard) und none. Im repokey-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 borg-pass-NAME.txt 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 borg 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. Wird ein Ziel erstmals mit einem abweichenden Port hinzugefügt, ergänzt ProxMenux zusätzlich -p PORT; gespeicherte Ziele, geplante Aufträge und der Monitor verwenden stattdessen den Port aus der ssh://-URL. Ohne eigenen Schlüssel und bei einem neuen Ziel 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 repokey-Verschlüsselung verwendet. Erscheint nie in der Prozessargumentenliste."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Wird von hb_borg_init_if_needed bei der Initialisierung eines noch nicht vorhandenen Repositorys verwendet. Ignoriert von borg create 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 run_scheduled_backup.sh borg prune nach jedem erfolgreichen Backup mit den für den Auftrag konfigurierten Retentionswerten (--keep-last, --keep-daily, --keep-weekly) gegen das Repository aus. Interaktive Backups beschneiden nicht."
+ },
+ "restoreAccess": {
+ "heading": "Abruf auf der Wiederherstellungsseite",
+ "body": "Die Wiederherstellung listet Archive mit borg list REPO auf und entpackt das gewählte Archiv mit borg extract REPO::ARCHIVE-NAME in ein Vorbereitungsverzeichnis. _rs_check_layout übergibt dieses an den normalen Wiederherstellungsablauf. Dieselben Befehle funktionieren auch manuell außerhalb von ProxMenux. Der entpackte Verzeichnisbaum entspricht der in So funktioniert es 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/destinations/index.json b/web/messages/de/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..1654efab
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh - _bk_local, _bk_pbs, _bk_borg - implementiert, aber alle drei haben den gleichen Staging-Schritt (hb_prepare_staging) 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 .tar.zst-Datei (oder .tar.gz, wenn zstd fehlt).",
+ "pbs": "PBS Backup (.pxar Chunks im Datenspeicher).",
+ "borg": "Borg-Archiv in einem Borg-Repository (Segmentdateien)."
+ },
+ {
+ "feature": "Kompression",
+ "local": "zstd (Standardstufe) über tar --zstd. 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 KEEP_LAST 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Interaktive Backups führen keine Bereinigung aus.",
+ "borg": "Angewendet pro geplanten Auftrag über borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (standardmäßig auf Proxmox vorhanden).",
+ "pbs": "proxmox-backup-client Paket (gebündelt mit Proxmox VE 8+).",
+ "borg": "borg 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 proxmox-backup-client + PBS Anmeldeinformationen + die Schlüsseldatei (falls verschlüsselt).",
+ "borg": "Erfordert borg + 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 rootfs/ + metadata/ + manifest.json Layout vorhanden, das in Funktionsweise beschrieben wird. Ein aus einem lokalen Archiv extrahierter .tar.zst, ein aus PBS wiederhergestellter .pxar und ein mit borg extract extrahiertes Borg-Archiv ergeben alle einen identischen Verzeichnisbaum. Der Wiederherstellungscodepfad (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) liest die gleichen drei Nutzlasten, ohne zu wissen, von welchem Ziel sie kamen."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/destinations/local.json b/web/messages/de/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..eff0a73d
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst-Datei (oder .tar.gz, wenn zstd fehlt). Die Datei enthält den gesamten Archivbaum manifest.json, metadata/ und rootfs/ und kann auf jedem Proxmox-Host mit dem ProxMenux-Wiederherstellungsfluss wiederhergestellt oder manuell mit tar --zstd -xf 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 einziges dauerhaft gespeichertes Zielverzeichnis – keine Liste. ProxMenux speichert die Auswahl des Betreibers bei /usr/local/share/proxmenux/local-target.conf und liest sie bei jedem Backup. Wenn kein Ziel konfiguriert wurde, wird der Standard-HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump verwendet (das gleiche Verzeichnis, das Proxmox für seine eigenen vzdump-Ausgänge verwendet). Das Ziel wird unter Backup-Ziele konfigurieren → Lokale Ziele konfiguriert:",
+ "options": [
+ "Standard verwenden (/var/lib/vz/dump). 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.",
+ "Benutzerdefinierten Pfad eingeben. Jeder absolute Dateisystempfad kann verwendet werden: ein NFS-Mount, eine über fstab 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.",
+ "Wählen Sie ein USB-Laufwerk. Ö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 lsblk 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 hb_mount_usb_partition aus: erstellt /mnt/backup-LABEL (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 den exakten Gerätepfad eingeben (z. B. /dev/sdb), 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 _bk_local, dass das Zielverzeichnis nicht ein Unterpfad eines zu sichernden Verzeichnisses ist. Ein häufiger Fehler wäre das Hinzufügen von /root zum Profil und die Auswahl von /root/backups 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 readlink -m 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 tar --zstd -cf - eine Single-Command-Pipeline, die auf dem Standardniveau von zstd komprimiert wird. Wenn zstd nicht in der Quelle vorhanden ist (selten bei Proxmox, aber bei minimalen Installationen möglich), fällt ProxMenux auf gzip zurück. Im Fallback-Pfad wird, wenn pv verfügbar ist, ein Fortschrittsbalken zur Pipeline hinzugefügt, so dass der Betreiber die Archivgröße in Echtzeit wachsen sieht; ohne pv wird tar -czf still verwendet.",
+ "sourceTitle": "Was geht ins Archiv",
+ "sourceBody": "Der tar-Befehl wird mit -C \"$staging_root\" . aufgerufen und archiviert dadurch das gesamte Staging-Hauptverzeichnis: rootfs/, metadata/ und manifest.json. 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: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, geschrieben neben dem Archiv von hb_write_archive_sidecar. 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 (kind) stammt, die Job-ID für geplante Läufe, den verwendeten Profilmodus (default oder custom), 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 *.proxmenux.json-Begleitdateien - nicht für *.tar.zst-Dateien -, da ein .tar.zst 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 _rs_check_layout 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 tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg den gleichen Baum, den der Wiederherstellungscode verbraucht."
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/destinations/pbs.json b/web/messages/de/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..2beffaef
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client - 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, .pxar-Archive, --backup-id, 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 host/hostcfg-HOSTNAME/BACKUP-TIME gruppiert ist. Die Nutzlast ist ein .pxar-Archiv, das das gleiche dreiblockige Layout enthält, das in How it works 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 — run_scheduled_backup.sh führt proxmox-backup-client prune mit --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET und HB_PBS_FINGERPRINT für den Lauf.",
+ "sourceRows": [
+ {
+ "source": "Proxmox storage.cfg (automatisch erkannt)",
+ "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
+ "content": "Jede pbs: 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 Backup-Ziele konfigurieren → PBS Ziele → PBS hinzufügen. Prompts für einen Namen, Benutzernamen (root@pam oder user@pbs!token), 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 ([proxmox] oder [manual]). Einträge, deren Passwort nicht aufgelöst werden konnte, werden mit einer ⚠ no password-Warnung versehen – die Auswahl einer löst einen erneuten Passworteintrag aus, bevor das Backup startet. Der Fingerabdruck wird über die PBS_FINGERPRINT-Umgebungsvariable an proxmox-backup-client ü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 proxmox-backup-client backup. ProxMenux übergibt Passwort, Verschlüsselungspasswort und Fingerabdruck mit env 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 hostcfg-HOSTNAME. Vor dem Upload wird sie bestätigt oder bearbeitet. Zeichen außerhalb von [A-Za-z0-9_-] sowie abschließende Bindestriche werden entfernt. Die Wiederverwendung derselben ID bei weiteren Läufen ist beabsichtigt: PBS behandelt die ID als Gruppe. Jedes weitere Backup erscheint als neuer Eintrag in dieser Gruppe und nutzt die Deduplizierung mit früheren Backups.",
+ "pxarTitle": "Warum die Quelle die vollständige Staging-Wurzel ist",
+ "pxarBody": "Die .pxar-Quelle ist die gesamte staging_root - rootfs/, metadata/ und manifest.json zusammen. Frühere Versionen bestanden $staging_root/rootfs als Quelle; Das ließ metadata/ aus dem Archiv und die Kompatibilitätsprüfung der Wiederherstellung hatte nichts zu lesen, was selbst bei Wiederherstellungen des gleichen Hosts zu Cross-Host-Warnungen führte. Alte Backups, die mit der Rootfs-only-Quelle erstellt wurden, werden immer noch korrekt über den _rs_check_layout-Fall-3-Zweig wiederhergestellt, der einen flachen etc/var/root/usr-Baum zurück in eine rootfs/-Hierarchie wickelt."
+ },
+ "encryption": {
+ "heading": "Clientseitige Verschlüsselung",
+ "glossaryHint": "Dieser Abschnitt verwendet die Begriffe Schlüsseldatei, Passphrase und Wiederherstellungshülle. Das Glossar 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 /usr/local/share/proxmenux/pbs-key.conf 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: Nein fährt ohne Verschlüsselung fort, Ja führt zum zweiten Schritt. Dieser hängt davon ab, ob bereits eine Schlüsseldatei unter /usr/local/share/proxmenux/pbs-key.conf 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. Neue Schlüsseldatei erzeugen führt proxmox-backup-client key create --kdf none aus. Vorhandene Schlüsseldatei verwenden erkennt eine von PVE verwaltete Datei automatisch: Ist das gewählte PBS-Repository in Proxmox mit einem Verschlüsselungsschlüssel unter /etc/pve/priv/storage/<NAME>.enc 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 chmod 600.",
+ "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 Vorhandene Schlüsseldatei verwenden 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 Schlüssel auf PBS hochladen? und bietet zwei Antworten. Erst wenn der Betreiber Ja wählt, wird ein Wiederherstellungsartefakt auf PBS hochgeladen. Vorgabe ist Nein, nur lokal behalten: Die Schlüsseldatei bleibt am kanonischen lokalen Pfad, ProxMenux lädt kein Wiederherstellungsartefakt auf PBS hoch und der Betreiber sorgt selbst für eine externe Kopie. Die Schaltfläche Schlüsseldatei herunterladen in der PBS-Zielzeile des Monitors stellt sie bei Bedarf bereit. Bei Ja, hochladen wird zweimal eine Wiederherstellungspassphrase abgefragt und auf Übereinstimmung geprüft. ProxMenux schützt die Schlüsseldatei damit mittels AES-256-CBC und PBKDF2 (600.000 Iterationen, zufälliges Salt) und erzeugt pbs-key.recovery.enc. Jedes weitere verschlüsselte Backup lädt diese Hülle als zugehörige Backup-Gruppe auf PBS hoch. Dabei werden weder die Passphrase noch die Schlüsseldatei im Klartext an PBS gesendet. Die Entscheidung lässt sich jederzeit im Monitor ändern: Der Schalter in der PBS-Zielzeile wählt Ja oder Nein und übernimmt je nach Zustand sofort Upload starten, Upload stoppen oder Passphrase aktualisieren.",
+ "blobUploadTitle": "Gepaarte Backup-Gruppe auf PBS",
+ "blobUploadBody1": "Ist die Hinterlegung auf Ja, hochladen gesetzt, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie heißt wie die Host-Gruppe, ergänzt um -keyrecovery. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. Die Hülle verlässt den Host niemals im Klartext: Noch vor der Übertragung verschlüsselt der Host sie mit AES-256-CBC und PBKDF2 (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
+ "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 proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe -keyrecovery vorhanden ist, deren neuester Snapshot heruntergeladen und die Wiederherstellungspassphrase zum Entschlüsseln abgefragt. Funktioniert beides nicht oder lehnt der Betreiber die Optionen ab, fragt der dritte Schritt nach dem absoluten Pfad der Schlüsseldatei auf diesem Host und kopiert sie an den kanonischen Pfad. Der Monitor bietet denselben Importablauf im Backup-Detaildialog. Oben erscheint ein gelbes Feld, wenn Wiederherstellen, Herunterladen oder Inhalt anzeigen eine nicht installierte Schlüsseldatei benötigen. Ist eine Datei installiert, passt aber nicht zum Backup, meldet PBS wrong key — manifest's key XX does not match provided key YY. Dieselben drei Aktionen zeigen dann ein strukturiertes gelbes Feld mit dem erforderlichen Manifest-Fingerabdruck an, damit der Betreiber die passende Schlüsseldatei für dieses Backup erkennen und importieren kann.",
+ "monitorManagementTitle": "Schlüsseldatei im Monitor verwalten",
+ "monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung direkt in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Es gibt drei Aktionen: Herunterladen exportiert die aktuelle Datei in den Browser des Betreibers; Hochladen ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; Löschen entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für Schlüssel auf PBS hochladen?, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit Upload starten, Upload stoppen oder Passphrase aktualisieren. Jede Aktion nutzt dieselben Flask-Endpunkte wie die Terminaloberfläche. Die Wirkung auf Dateien und den PBS-Zustand ist deshalb bei beiden Oberflächen identisch."
+ },
+ "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 proxmox-backup-client restore mit demselben Repository + Passwort + Fingerabdruck (und --keyfile, als das Backup verschlüsselt wurde) ausgelöst, wodurch das .pxar in ein Staging-Verzeichnis extrahiert wird, das _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/glossary.json b/web/messages/de/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..32a4be40
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/glossary.json
@@ -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 Wiederherstellungsumschlag 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. Es ist nicht die Passphrase, die die Schlüsseldatei selbst entsperrt 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 Chunks vor dem Hochladen zu PBS verschlüsselt. Ohne passenden Schlüssel sind verschlüsselte Daten nicht lesbar. ProxMenux speichert sie unter /usr/local/share/proxmenux/pbs-key.conf mit Modus 600. Schützen Sie sie; der Wiederherstellungsumschlag 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 Recovery Passphrase. Es existiert nur, wenn die Keyfile mit --kdf scrypt 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 keyfile ist in eine zusätzliche Schicht eingewickelt: Es ist mit der Wiederherstellungspassphrase unter Verwendung von AES-256-CBC und PBKDF2 verschlüsselt, bevor es den Host verlässt. Es wird auf PBS als -keyrecovery-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 Wiederherstellungsumschlag hinzu."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Option auf proxmox-backup-client key create, 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 proxmox-backup-client key create, die eine Schlüsseldatei erzeugt, die durch eine keyfile-Passphrase 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 openssl enc -aes-256-cbc), um die Schlüsseldatei mit der Wiederherstellungspassphrase zu wickeln und die Umschlag 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 rsync nach dem Standardprofil und zusätzlichen eigenen Pfaden. 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 Wie es funktioniert dokumentiert."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Benutzerdefinierte Pfade",
+ "def": "Zusätzliche Pfade, die der Benutzer zusätzlich zum default-Profil hinzufügt. Entweder persistent (gespeichert in backup-extra-paths.txt) 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 + datastore + Benutzer, der das Backup erhält. Identifiziert durch den String user@realm@host:datastore. 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 PBS_FINGERPRINT an proxmox-backup-client 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 -keyrecovery-Suffix für den Wiederherstellungsumschlag."
+ },
+ {
+ "id": "backup-id",
+ "term": "Backup-ID",
+ "def": "Name der backup-Gruppe. ProxMenux ist standardmäßig hostcfg-HOSTNAME 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 run_scheduled_backup.sh-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 /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Anhängemodus",
+ "def": "Auftrag ohne eigenen Timer. Ein job-end-Hook von PVE-vzdump startet ihn nach Gastsicherungen bei passendem Zielspeicher. Der gewählte Elternauftrag liefert Speicher und Aufbewahrung, die bei jedem Lauf erneut aus dem Elternauftrag gelesen wird; 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 unabhängigem geplanten Job; attach-mode 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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 Ergänzungsschritt 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 Schlüsseldatei. Um ein verschlüsseltes Backup wiederherzustellen, muss zunächst die Schlüsseldatei aus der Wiederherstellungsumschlag, die auf PBS gespeichert ist, mit der Wiederherstellungspassphrase 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/how-it-works.json b/web/messages/de/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..6a8320b1
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/how-it-works.json
@@ -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 .tar.zst, PBS-Backup oder Borg-Archiv) enthält genau diese Struktur. Die Wiederherstellung nutzt alle drei: Das Manifest wird vor Änderungen ausgewertet, um Abweichungen zu erkennen und Ausschlüsse festzulegen; rootfs liefert die Konfigurationsdateien, die direkt oder nach einem Neustart angewendet werden; das Anwendungsinventar 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 metadata/-Unterverzeichnis enthält die strukturierten Nutzlasten; das rootfs/-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 rootfs/ ist eine einfache Dateisystemkopie, die rsync vom Quellhost erstellt. Er enthält ein ausgewähltes Standardprofil der für eine Proxmox-Wiederherstellung wichtigen Pfade sowie eigene Pfade, die der Benutzer zum Backup-Auftrag oder zur interaktiven Sitzung hinzufügt. Die Auswahl ist bewusst eng: nur Pfade, die Konfiguration enthalten oder Zustand speichern, den Proxmox nicht selbst wiederherstellen kann.",
+ "defaultProfileTitle": "Das Standardprofil",
+ "defaultProfileBody": "Das Standardprofil wird durch hb_default_profile_paths in lib_host_backup_common.sh 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 (config.db) wird als konsistenter Snapshot über sqlite3 .backup erfasst, ohne den Cluster zu stoppen, und die .db-wal / .db-shm Sidecars sind vom rsync ausgeschlossen. Wenn sqlite3 nicht verfügbar ist, wird stattdessen config.db.raw-fallback 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 .link-Dateien unter /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. Flüchtige Pfade (.bash_history, .cache/, tmp/, .local/share/Trash/) sind von der Kopie ausgeschlossen. /var/lib/proxmenux 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 zpool.cache und hostid."
+ }
+ ],
+ "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 /usr/local/share/proxmenux/backup-extra-paths.txt enthält eine Liste absoluter Pfade, die der Benutzer auf diesem Host als \"immer einschließen\" markiert hat. Wenn ein Backup im Default-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; #-Kommentare sind zulässig.",
+ "customModeTitle": "2. Benutzerdefinierter Modus (per Lauf)",
+ "customModeBody": "Das Starten eines Backups im Custom-Modus ersetzt die automatische Anwendung des Standardprofils durch eine Checkliste, die jeden Pfad anzeigt: die Standardprofileinträge und die persistenten Extras (vorangestellt mit [+] und bereits ausgewählt). Der Benutzer aktiviert oder deaktiviert Einträge für diesen bestimmten Lauf und kann auch Eigenen Pfad hinzufügen 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 metadata/missing_paths.txt 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 /etc/wireguard oder /etc/prometheus, wenn diese Werkzeuge nicht installiert sind."
+ },
+ "manifest": {
+ "heading": "Der Manifest-Datenblock",
+ "intro": "manifest.json ist ein strukturiertes JSON-Dokument, das den Quellhost zum Zeitpunkt des Backups beschreibt. Es wird von sechs unabhängigen Erfassungsskripten orchestriert von build_manifest.sh 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 (pveversion), PBS-Version, wenn der Host die Backup-Server-Rolle ausführt, Kernel (uname -r), 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 lsusb/lspci-Erkennung), NICs (mit MAC-, PCI-Slot- und Bridge-Mitgliedschaft), drahtlose Geräte. GPU-Einträge tragen eine passthrough_eligible-Heuristik."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "ZFS-Pools (mit Pooltyp + Mitglieds-Festplatten, die nach /dev/disk/by-id/*, /dev/disk/by-partuuid/* oder rohen /dev/sdX-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 storage.cfg-Einträge, externe Mounts."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Vom Betreiber hinzugefügte Parameter aus /proc/cmdline, ohne übliche Standardwerte wie BOOT_IMAGE=, root=, ro/rw, quiet und splash; beim Start geladene Module aus /etc/modules; sowie Pfade der Dateien /etc/modprobe.d/*.conf mit tatsächlichen Direktiven (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Lesen Sie /usr/local/share/proxmenux/managed_installs.json (Registrierung von allem, was ProxMenux installiert hat) und installed_tools.json. Jeder Eintrag behält den Installationspfad (menu_script) 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 (qm list) und LXCs (pct list) auf, die zum Backup-Zeitpunkt vorhanden sind — VMID, Name, aktueller Status. Nur das Inventar: Die eigentlichen Gästedaten liegen in der Verantwortung von vzdump / PBS."
+ }
+ ],
+ "schemaTitle": "Validierung des Schemas",
+ "schemaBody": "Das Manifest bestätigt gegen scripts/backup_restore/schema/manifest.schema.json. Das Ausführen von build_manifest.sh --validate löst eine Python-seitige JSON-Schemavalidierung aus (erfordert python3 + jsonschema). Wenn das Modul nicht vorhanden ist, wird die Überprüfung still übersprungen - die Validierung ist in erster Linie eine Entwicklerhilfe, keine Laufzeitabhängigkeit."
+ },
+ "applications": {
+ "heading": "Das Anwendungsinventar",
+ "intro": "Zwei Inventare erfassen die zusätzlich zu den Proxmox-VE-Basispaketen installierte Software: die Paketliste unter metadata/ 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 apt-mark showmanual mit allen auf dem Quellhost ausdrücklich installierten 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 _rs_run_complete_extras die Liste und wendet einen dreistufigen Filter gegen Kaskadenentfernung an: dpkg -s erkennt bereits installierte Pakete, für Bibliotheken werden vorhandene andere Hauptversionen erkannt und apt-get install --simulate prüft das Risiko von Folgeentfernungen. Danach folgt apt-get install -y.",
+ "componentsTitle": "components_status.json (Teil des rootfs)",
+ "componentsBody": "Ein JSON-Verzeichnis unter /usr/local/share/proxmenux/ erfasst jede von ProxMenux installierte Komponente mit ihrem genauen Zustand: Version und ProxMenux-spezifische Merkmale (bei NVIDIA der boolesche Wert patched, bei Coral die DKMS-Version). Die Datei liegt im rootfs und nicht unter metadata/, weil sie erst gelesen wird, nachdem das rootfs auf das Ziel kopiert wurde. Der nach dem Start ausgeführte Dispatcher (apply_cluster_postboot.sh) geht alle Einträge durch und ruft den --auto-reinstall-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 --auto-reinstall-Einstiegspunkt frei:",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Lesen Sie version + patched. 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 .deb 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 packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check aus. Vergleicht Quelle und Zielhardware (NICs, Storage IDs), PVE-Version und Hauptkernel-Version. Setzt HB_COMPAT_KERNEL_DIRECTION (same, bk_newer oder bk_older) ein und füllt RS_SKIP_PATHS mit Hardware-Drift- und Cross-Kernel-Ausschlüssen."
+ },
+ {
+ "stage": "2",
+ "name": "Anwenden im laufenden Betrieb",
+ "reads": "rootfs/ (nur sichere Pfade)",
+ "action": "_rs_apply … hot kopiert hb_classify_path=hot-Einträge direkt auf das Live-Ziel. Alles, was unter /etc/pve, /etc/network oder als reboot/dangerous klassifiziert ist, wird verschoben."
+ },
+ {
+ "stage": "3",
+ "name": "Ausstehende Vorbereitung",
+ "reads": "rootfs/ (Reboot + gefährliche Pfade)",
+ "action": "_rs_prepare_pending_restore bereitet riskante Pfade unter /var/lib/proxmenux/pending-restore/ vor, schreibt plan.env, apply-on-boot.list und rs-skip-paths.txt und aktiviert proxmenux-restore-onboot.service für den nächsten Start."
+ },
+ {
+ "stage": "3b",
+ "name": "Import von Datenpools",
+ "reads": "manifest.storage_inventory + ZFS-Zustand des Ziels",
+ "action": "_rs_import_data_pools importiert jeden Nicht-Root-ZFS-Pool, dessen vollständiger Satz von Festplatten auf dem Ziel vorhanden ist. Pools mit einem fremden Hostid werden mit zpool import -f getestet. Pools, denen eine Festplatte fehlt, werden mit einer Warnung übersprungen. Das Ergebnis pro Pool wird in /var/log/proxmenux/restore-datapools-<timestamp>.log aufgezeichnet."
+ },
+ {
+ "stage": "4",
+ "name": "Paketinstallation",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras führt den kaskadensicheren Filter aus und ruft apt-get install -y mit der Paketliste auf. Die volle Ausgabe geht an /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Postboot",
+ "reads": "rootfs (bereits angewendet) + components_status.json",
+ "action": "Nach dem Neustart spielt apply_pending_restore.sh die zurückgestellten Pfade ab und apply_cluster_postboot.sh läuft update-initramfs, update-grub (oder proxmox-boot-tool refresh) und iteriert über components_status.json und feuert den --auto-reinstall-Hook jeder Komponente."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Warum der Drei-Payload-Split verwendet wird",
+ "body": "Die Aufteilung richtet sich nach dem Lebenszyklus der Daten. Dateisysteminhalte werden mit rsync übertragen: schnell, nachvollziehbar und atomar je Datei. Der vor Änderungen auszuwertende Konfigurationszustand liegt als strukturiertes JSON vor: unabhängig lesbar, per Schema versionierbar und maschinell mit dem Zielzustand vergleichbar. Neu zu installierende Software wird als Inventar 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."
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/index.json b/web/messages/de/docs/backup-restore/index.json
new file mode 100644
index 00000000..fa7bac95
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/index.json
@@ -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: das Dateisystem mit den relevanten Verzeichnissen unter /etc, /root und /var/lib/pve-cluster sowie optionalen eigenen Pfaden; ein strukturiertes Manifest im JSON-Format mit erkannter Hardware, Kernel-Parametern, Netzwerkkonfiguration, ZFS-Zustand, Benutzern und Cron-Einträgen; und ein Anwendungsinventar 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 auf Host-Ebene: die Proxmox-Installation selbst, nicht die darauf ausgeführten Anwendungen und Gastsysteme.",
+ "items": [
+ "Dies ist kein Sicherungswerkzeug für VMs oder CTs. Gastfestplatten und RAM-Zustand werden nicht erfasst; dafür ist vzdump zuständig. Die Konfigurationsdateien der Gäste (/etc/pve/nodes/<node>/qemu-server/*.conf und lxc/*.conf) werden jedoch gesichert. Nach der Wiederherstellung erscheint das Gastinventar erneut, und die Festplatten können aus einer vorhandenen PBS- oder lokalen Sicherung wiederhergestellt und zugeordnet werden.",
+ "Dies ist kein clusterweiter Vorgang. Jeder Knoten sichert sich selbst. Die Clusterzugehörigkeit wird mit /etc/pve erfasst, sodass ein wiederhergestellter Knoten erneut aufgenommen werden kann. Die Wiederherstellung eines ganzen Clusters erfordert jedoch die Abstimmung zwischen den einzelnen Knoten.",
+ "Dies ist kein vollständiges Festplattenabbild. Kernel-Binärdateien, initramfs und Boot-Partition werden nicht gesichert. Bei der Wiederherstellung nutzt ProxMenux die Boot-Dateien des Zielhosts, die mit update-initramfs 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 Ziels 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 Hydration-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 Wie es funktioniert, wenn das Ziel darin besteht, zu verstehen, was das Archiv enthält und warum. Wechseln Sie zu Ziele, um das Ziel für die Kopie zu konfigurieren. Lesen Sie Wiederherstellung und Cross-Kernel-Wiederherstellung 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/restoring.json b/web/messages/de/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..0804b2dd
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Wiederherstellen eines Backups – vollständige und benutzerdefinierte Abläufe | ProxMenux",
+ "description": "Der komplette Wiederherstellungsworkflow. Dokumentiert die drei Aktionen, die für jedes Backup verfügbar sind (Ansicht, Download, Wiederherstellung), die Kompatibilitätsprüfung und ihre Ergebnisse, die vollständigen und benutzerdefinierten Wiederherstellungsmodi, die Pfadklassifizierung, die entscheidet, was live gilt und was auf den nächsten Start wartet, den On-Boot-Dispatcher und den Post-Boot-Komponentenneuinstallationspass.",
+ "ogTitle": "ProxMenux Backup — Wiederherstellung",
+ "ogDescription": "Vollständige und benutzerdefinierte Wiederherstellungsflüsse mit Kompatibilitätsprüfung, Pfadklassifizierung, On-Boot-Dispatcher und Post-Boot-Neuinstallation.",
+ "twitterTitle": "Wiederherstellen eines Backups | ProxMenux",
+ "twitterDescription": "Wie ein ProxMenux-Host-Backup wieder in einen funktionierenden Proxmox-Host umgewandelt wird."
+ },
+ "header": {
+ "title": "Wiederherstellen eines Backups",
+ "description": "Der vollständige Wiederherstellungsworkflow: vom Auswählen eines Archivs bis zum Arbeitshost. Dokumentiert die Kompatibilitätsprüfung, die beiden Wiederherstellungsmodi, den On-Boot-Dispatcher, den Post-Boot-Reinstallationspass und die Mechanismen, die Cross-Host- und Cross-Kernel-Wiederherstellungen vorhersehbar machen.",
+ "section": "Sicherung und Wiederherstellung"
+ },
+ "intro": {
+ "title": "Die Wiederherstellung reproduziert die Quelle, nicht nur die Dateien",
+ "body": "Ein ProxMenux-Backup wiederherzustellen umfasst mehr als das Entpacken von Dateien. Vor Änderungen wertet die Wiederherstellung das Manifest aus, erkennt Unterschiede zwischen Quelle und Ziel, schließt möglicherweise startgefährdende Pfade aus und passt Benutzereinstellungen an, die nicht unverändert kopiert werden können. Nach dem erforderlichen Neustart versucht sie, die erfassten unterstützten Komponenten (NVIDIA-Treiber, Coral-TPU und GPU-Werkzeuge) für den laufenden Zielkernel neu zu installieren. Ein ausgewähltes Archiv steuert Kompatibilitätsprüfung, Pfadklassifizierung und die Arbeiten beim und nach dem Start. Prüfen Sie die Komponentenergebnisse und Protokolle."
+ },
+ "threeActions": {
+ "heading": "Drei Aktionen auf einem Backup",
+ "intro": "Durch Auswählen eines Backups aus der Liste wird ein Menü mit drei Aktionen geöffnet.",
+ "actionRows": [
+ {
+ "action": "Ansicht",
+ "detail": "Öffnet eine schreibgeschützte Ansicht des Archivs: manifest.json-Inhalte (Quellhostname, PVE-Version, Kernel, Hardware, installierte Komponenten), die Liste der Pfade innerhalb von rootfs/ und ein Vergleich dessen, was sich auf dem aktuellen Host ändern würde, wenn das Backup angewendet würde."
+ },
+ {
+ "action": "Herunterladen",
+ "detail": "Exportiert das Archiv als tragbare .tar.zst-Datei (tar komprimiert mit zstd). Es kann auf jedem Linux-System mit tar --zstd -xf FILE.tar.zst extrahiert werden, oder auf macOS / Windows mit jedem Tool, das zstd unterstützt (7-Zip, PeaZip, Keka ...). Der extrahierte Baum enthält manifest.json, metadata/ und rootfs/ - genau das gleiche Layout, das die Wiederherstellung verbraucht. Nützlich für die Offline-Inspektion oder für die Wiederherstellung auf einem Host ohne Zugriff auf das ursprüngliche Ziel (PBS, Borg)."
+ },
+ {
+ "action": "Wiederherstellen",
+ "detail": "Der Schreibpfad. Extrahiert das Archiv in ein Staging-Verzeichnis, führt die Kompatibilitätsprüfung aus und präsentiert den Moduswähler (Full oder Custom)."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Die Vereinbarkeitsprüfung",
+ "intro": "Bevor eine Datei geschrieben wird, vergleicht hb_compat_check den im Manifest beschriebenen Zustand mit dem Zielhost. Der Check läuft schreibgeschützt und erzeugt vier unabhängige Ausgänge, die den Rest der Wiederherstellung steuern.",
+ "outputRows": [
+ {
+ "output": "Kernel-Richtungskennzeichen",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION — eines von same, bk_newer oder bk_older. Vergleicht die Hauptkernelversion des Backups mit der des Ziels. Steuert den Cross-Kernel-Safe-Subset-Filter (feuert nur auf bk_older) und den Hydratationspass, der auf der Cross-Kernel-Seite dokumentiert ist."
+ },
+ {
+ "output": "Liste der Skip Paths",
+ "detail": "RS_SKIP_PATHS - jeder Pfad, den die Wiederherstellung NICHT anwenden darf. Bevölkert durch zwei Mechanismen: Hardware-Drift (fehlende NIC, fehlende Speicher-ID, ausländischer ZFS-Pool) und - wenn die Richtung bk_older ist - die kernübergreifende Liste der unsicheren Pfade."
+ },
+ {
+ "output": "NIC-Remapplan",
+ "detail": "Wenn ein NIC auf dem Ziel den gleichen MAC wie auf der Quelle, aber einen anderen Namen hat (typischerweise nach einem Motherboard-Swap), registriert die Kompatibilitätsprüfung einen Umbenennungsplan (HB_NIC_REMAP), der /etc/network/interfaces während der Wiederherstellung umschreibt."
+ },
+ {
+ "output": "Rollback-Plan",
+ "detail": "Berechnet durch compute_rollback_plan.sh. Listet VMs, LXCs und Komponenten auf, die auf dem Ziel, aber nicht im Backup vorhanden sind. Im Bestätigungsdialog kann das Entfernen zusätzlicher Gäste vor dem Neustart gewählt werden. Komponenten müssen manuell entfernt werden; auch das Löschen von Gästen kann scheitern. Eine exakte Übereinstimmung wird daher nicht garantiert."
+ }
+ ],
+ "reportBody": "Der Check sendet auch einen strukturierten Bericht (HB_COMPAT_RESULTS) aus, der als PASS / INFO / WARN / FAIL kategorisiert ist. WARN- und FAIL-Einträge tauchen im Pre-Restore-Bereich auf; die Wiederherstellung weigert sich, nur dann fortzufahren, wenn ein FAIL vorhanden ist, den der Benutzer nicht durch Klicken auf Weiter beheben kann."
+ },
+ "twoModes": {
+ "heading": "Vollständige Wiederherstellung vs Custom Wiederherstellung",
+ "intro": "Nach der Kompatibilitätsprüfung erscheint die Modusauswahl. Sie bestimmt, was angewendet wird und nicht, wie: Beide Modi verwenden denselben Ablauf.",
+ "modeRows": [
+ {
+ "mode": "Vollständige Wiederherstellung",
+ "detail": "Wendet jeden Pfad im Archiv an, der die Drift- und Kreuzkernfilter überlebt. Führt auch die Paketinstallation und den automatischen Komponentenneuinstallationspass aus. Dies ist der Standard und die empfohlene Wahl - das Ziel ist es, die Quelle zu reproduzieren, nicht Stücke auszuwählen."
+ },
+ {
+ "mode": "Benutzerdefinierte Wiederherstellung",
+ "detail": "Öffnet eine Checkliste, die jeden Pfad zeigt, den das Archiv führt. Der Benutzer tickt eine Teilmenge. Durch den Kreuzkernfilter blockierte Pfade erscheinen ausgegraut und können nicht ausgewählt werden. Paketinstallation und automatische Neuinstallation von Komponenten werden standardmäßig im benutzerdefinierten Modus übersprungen - der Benutzer signalisiert, dass er eine teilweise Anwendung und keine vollständige Reproduktion wünscht."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Wie Pfade klassifiziert werden",
+ "intro": "Jeder für die Wiederherstellung ausgewählte Pfad wird von hb_classify_path in eine von drei Kategorien eingestuft. Die Kategorie bestimmt, wann der Pfad auf das System angewendet wird und warum.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Pfade angewendet sofort auf das laufende System. Der Dienst, der sie verbraucht, nimmt die Änderung selbst oder beim nächsten Neuladen auf - kein Neustart erforderlich. Dies ist der Hauptteil eines Backups: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, allgemeine Servicekonfigurationsdateien usw."
+ },
+ {
+ "class": "reboot",
+ "detail": "Pfade, die dieser Ablauf für den nächsten Start zurückstellt, statt sie sofort anzuwenden. Sie betreffen die Startkonfiguration: Die Bootloader-Erzeugung liest /etc/default/grub, das Einhängen nutzt /etc/fstab und das Laden von Modulen /etc/modules. Nach dem Neustart werden die vorgemerkten Dateien angewendet und die nötigen Startartefakte neu erzeugt. Beispiele: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Pfade, die NICHT im laufenden System angewendet werden: Ein Schreibzugriff zur Laufzeit könnte den Zustand beschädigen oder die aktive Verbindung trennen. Sie werden vorgemerkt: /etc/network wird früh beim nächsten Start geschrieben, bevor das Netzwerk startet, und /etc/pve schreibt der Post-Boot-Dispatcher, sobald das Cluster-Dateisystem bereit ist. Beispiele: /etc/pve (pmxcfs ist ein aktiver FUSE-Mount mit laufender Clusterkonfiguration), /var/lib/pve-cluster (aktive Clusterdaten, nur zur manuellen Wiederherstellung im Wiederherstellungsverzeichnis abgelegt), /etc/network (könnte die für die SSH-Verbindung genutzte Schnittstelle neu konfigurieren und die Sitzung trennen)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "Der vollständige Wiederherstellungsworkflow",
+ "intro": "Die komplette Pipeline von der Archivauswahl bis zu einem funktionierenden wiederhergestellten Host. Jede Stufe füttert die nächste; der von früheren Stufen geschriebene Zustand wird von späteren verbraucht.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "Die Mechanik der vorgemerkten Wiederherstellung",
+ "intro": "Pfade, die als reboot oder dangerous klassifiziert sind, und Hydratationsschreiben, werden für den nächsten Boot inszeniert, anstatt live angewendet zu werden. Dies geschieht durch einen kleinen, in sich geschlossenen Satz von Dateien unter /var/lib/proxmenux/pending-restore/:",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "Ein relativer Pfad je Zeile: die genauen Pfade, die apply_pending_restore.sh aus dem vorbereiteten rootfs anwendet. Diese Datei zeigt, was beim nächsten Start geändert wird."
+ },
+ {
+ "file": "plan.env",
+ "content": "Umgebungsvariablen, die über das On-Boot-Skript bezogen werden: Wiederherstellungs-ID, Kompatibilitätskennzeichen (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), Rollback-Opt-in-Flag, Clusteroptionen."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "Die endgültige RS_SKIP_PATHS-Liste blieb bestehen, so dass apply_pending_restore.sh nach dem Neustart die gleichen Ausschlüsse anwendet, die während des interaktiven Schritts berechnet wurden. Verhindert, dass driftbeeinflusste oder kernübergreifend unsichere Pfade beim Booten wiederhergestellt werden."
+ },
+ {
+ "file": "rootfs/",
+ "content": "Die inszenierten Dateien selbst - die genauen Bytes, die festgelegt werden. Behielt auf dem gleichen Dateisystem wie /, so dass der On-Boot rsync schnell ist und nicht davon abhängt, dass externer Speicher beim Booten noch erreichbar ist."
+ }
+ ],
+ "unitBody": "Die systemd-Einheit proxmenux-restore-onboot.service wird am Ende des interaktiven Schritts aktiviert. Der einmalige Dienst startet früh beim nächsten Boot, ruft apply_pending_restore.sh auf und deaktiviert sich anschließend. Die Bedingung ConditionPathExists=/var/lib/proxmenux/pending-restore/state sorgt dafür, dass er bei Starts ohne vorgemerkte Wiederherstellung nichts ausführt."
+ },
+ "postbootDispatcher": {
+ "heading": "Der Postboot-Dispatcher — apply_cluster_postboot.sh",
+ "intro": "Wo der interaktive Schritt endet und wo die eigentliche Host-Reproduktion stattfindet. apply_cluster_postboot.sh wird als zweites One-Shot-systemd-Dienst (proxmenux-apply-cluster-postboot.service) installiert, dessen After=/Wants=-Ziele sicherstellen, dass es nur nach dem Ausführen von Pve-Cluster und Netzwerk-Online ausgeführt wird. Hier landen die host-visiblen Wiederherstellungsaktionen.",
+ "tasks": [
+ {
+ "task": "Anwendung von /etc/pve",
+ "detail": "/etc/pve ist ein Live-Pmxcfs FUSE-Mount - es kann nicht beim frühen Booten geschrieben werden. Der Dispatcher kopiert Dateien von den ausstehenden Rootfs in das Live-/etc/pve, sobald das Cluster-Dateisystem aktiviert ist, eine Datei nach der anderen, ohne den pve-Cluster neu zu starten. Das erfasste /var/lib/pve-cluster/config.db aus dem Backup (oder das geförderte config.db.raw-fallback) wird mit dem systemctl stop pve-cluster → Atomdateikopie → systemctl start pve-cluster Muster materialisiert, so dass pmxcfs den wiederhergestellten Zustand auf dem Weg zurück nach oben erneut liest."
+ },
+ {
+ "task": "Rebuild Initramfs und Bootloader",
+ "detail": "Führt update-initramfs -u -k all über jeden installierten Kernel aus, dann entweder update-grub (GRUB-Installationen) oder proxmox-boot-tool refresh (systemd-Boot / ZFS-Installationen). Überspringt, wenn der interaktive Schritt feststellte, dass sich nichts an den Pfaden geändert hat, die sich auf diese Werkzeuge auswirken."
+ },
+ {
+ "task": "Auto-Reinstallation der Komponente",
+ "detail": "Liest die wiederhergestellte components_status.json und durchläuft die unterstützten Installationsskripte (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Jedes ausgewählte Skript läuft mit --auto-reinstall, liest den erfassten Zustand und installiert für die Zielumgebung neu, einschließlich nötiger Kernelmodule. Dies erfolgt nach dem Neustart, damit der dann laufende Zielkernel verwendet wird. Einzelfehler werden protokolliert und stoppen die nächste Komponente nicht."
+ },
+ {
+ "task": "Prüfung der Startkonfiguration",
+ "detail": "Bevor Sie die Abschlussbenachrichtigung starten, überprüfen Sie, ob proxmox-boot-tool status ein konfiguriertes ESP anzeigt, jedes /boot/vmlinuz-* ein passendes /lib/modules/<ver>-Verzeichnis hat und /vmlinuz auflöst. Jede inkonsistenz wird in der benachrichtigung aufgetaucht, anstatt versteckt zu werden."
+ },
+ {
+ "task": "Abschlussmeldung",
+ "detail": "Sendet das Host restore finished-Event über hb_notify_lifecycle. Enthält die Gesamtdauer, die Anzahl der angewandten Pfade, gegebenenfalls Warnungen vor der Sanitätsprüfung und einen Link zum Protokoll bei /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Wenn Benachrichtigungen nicht konfiguriert sind, ist das Ereignis still – das Protokoll zeichnet immer noch alles auf."
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Live-Fortschritt auf der Registerkarte Backups des Monitors",
+ "body": "Nach dem Neustart wird auf der Registerkarte Backups von ProxMenux Monitor eine Live-Post-Restore-Karte angezeigt, die den Status von proxmenux-apply-cluster-postboot.service während der Ausführung widerspiegelt. Die Karte wird von /var/lib/proxmenux/restore-state.json gesteuert, die der Dispatcher bei jedem Meilenstein aktualisiert (Cluster-Konfiguration anwenden, Initramfs neu erstellen, Bootloader aktualisieren, pro Komponente neu installieren, Boot-Sanity-Check, finalisieren).",
+ "fields": [
+ {
+ "name": "Statusabzeichen",
+ "detail": "Einer der Zustände Wiederherstellung läuft, Wiederherstellung abgeschlossen oder Wiederherstellung fehlgeschlagen. Die Karte fragt die Statusdatei während der Ausführung alle 2 Sekunden und danach alle 30 Sekunden ab."
+ },
+ {
+ "name": "Fortschrittsbalken + Schrittzähler",
+ "detail": "Zeigt N/M steps mit dem Label des aktuellen Schritts an. Während die Wiederherstellung ausgeführt wird, wird eine geschätzte Zeit aus abgeschlossenen Schritten und verstrichener Zeit abgeleitet."
+ },
+ {
+ "name": "Komponentenliste",
+ "detail": "Eine Zeile pro Treiber wird neu installiert (NVIDIA, Intel GPU tools, AMD tools, Coral TPU) mit installing / ok / failed plus einem Link zum Pro-Komponenten-Log bei /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Import von Datenpools",
+ "detail": "Der Block data_pools_import zeigt fünf farbige Zeilen: Importiert, Erzwungen (mit -f wegen fremdem hostid), Unvollständig übersprungen (nur einige Datenträger vorhanden), Fehlend übersprungen (keine Datenträger vorhanden) und Fehlgeschlagen. Der Zustand liegt in /var/lib/proxmenux/restore-state.json, das vollständige Laufprotokoll in /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Warnungen zur Boot-Sicherheit",
+ "detail": "Der Dispatcher prüft auf fehlende /lib/modules/<kernel>, fehlende ESP-Konfiguration und baumelnde /vmlinuz-Symlinks. Jede Warnung taucht hier als farbiges Banner auf."
+ },
+ {
+ "name": "Rollback-Delta",
+ "detail": "Listen Sie VMs, LXCs und Komponenten auf, die auf dem Ziel vorhanden sind, aber nicht im wiederhergestellten Backup waren - die gleichen Einträge tauchten im destruktiven Rollback-Dialog vor der Wiederherstellung auf. Jede Zeile trägt den manuellen Bereinigungsbefehl."
+ },
+ {
+ "name": "Letzte Protokollzeilen",
+ "detail": "Die letzten 600-Zeilen von proxmenux-cluster-postboot-<ts>.log, mit einem Nur Probleme Filter, der nur Zeilen hält, die mit error, warning, failed, ✗ oder traceback übereinstimmen."
+ }
+ ],
+ "dismissBody": "Ist die Wiederherstellung abgeschlossen oder fehlgeschlagen, klappt Ausblenden die Karte zu. Die Statusdatei bleibt erhalten; Verlauf öffnet sie und frühere Wiederherstellungen erneut. Die letzten 20 Läufe liegen unter /var/lib/proxmenux/restore-history/.",
+ "imageAlt": "Detaildialog des Wiederherstellungsfortschritts im ProxMenux Monitor während einer laufenden Wiederherstellung: blaues Statuszeichen, aktueller Schritt „Initramfs neu erstellen“, geschätzte Restzeit, teilweise gefüllter Fortschrittsbalken und aktuelle Protokollzeilen.",
+ "imageCaption": "Die Details modal, während der Post-Boot-Dispatcher noch läuft - Abzeichen, aktueller Schritt, verbleibende Zeit und Live-Log-Tail.",
+ "detailsImageAlt": "Die gleichen Details modal, nachdem die Wiederherstellung abgeschlossen ist, mit dem grünen Wiederherstellungsabzeichen, der Gesamtlaufdauer (0m53s), einem vollständig gefüllten 6 / 6-Fortschrittsbalken, dem leeren Rollback-Delta und dem archivierten Postboot-Protokoll.",
+ "detailsImageCaption": "Das gleiche Modal, wenn der Lauf beendet ist - Abzeichen, Gesamtdauer, gefüllter Fortschrittsbalken und das archivierte Postboot-Protokoll."
+ },
+ "postbootExample": {
+ "heading": "Wie der Post-Boot auf der Konsole aussieht",
+ "body": "Auf der physischen Host-Konsole endet ein erfolgreich beendeter Dispatcher-Prozess mit [ OK ] Finished proxmenux-apply-cluster-postboot.service, oft neben den OK-Meldungen für multi-user.target und graphical.target. Dies markiert das Prozessende. Einzelne Komponentenfehler oder Startwarnungen können trotzdem vorliegen. Prüfen Sie daher Komponentenstatus und Protokolle im Monitor, bevor Sie den Host als vollständig wiederhergestellt betrachten.",
+ "imageAlt": "Physische Proxmox-Konsole mit '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', gefolgt von OK für multi-user.target und graphical.target; darüber die Host-Anmeldeaufforderung.",
+ "imageCaption": "Physische Konsole nach Prozessende. 'Finished proxmenux-apply-cluster-postboot.service' markiert den Abschluss, den auch 'Host restore finished' im Monitor meldet. Komponentenergebnisse und Warnungen müssen weiterhin geprüft werden."
+ },
+ "tenMinutes": {
+ "heading": "Warum die letzten zehn Minuten wichtig sind",
+ "intro": "Der Neustart selbst dauert Sekunden, aber der Post-Boot-Dispatcher verbringt etwa zehn Minuten damit, die Wiederherstellung abzuschließen. Während dieses Fensters ist der Host erreichbar und die Anmeldung funktioniert, aber einige Dienste (hauptsächlich von GPU-Treibern abhängige) sind noch nicht verfügbar. Zeitaufschlüsselung für einen typischen Proxmox-Host mit NVIDIA + Coral installiert:",
+ "rows": [
+ {
+ "stage": "Boot + pve-Cluster bereit",
+ "time": "~30 s",
+ "detail": "Standard Proxmox Boot. SSH, Web-UI und Login sind am Ende dieser Phase verfügbar."
+ },
+ {
+ "stage": "/etc/pve auf pmxcfs anwenden",
+ "time": "~10 s",
+ "detail": "Schnell – kleine Konfigurationsdateien, die nacheinander in das Live-Cluster-Dateisystem kopiert wurden."
+ },
+ {
+ "stage": "Initramfs über Kernel hinweg neu aufbauen",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all stellt pro installiertem Kernel ein Initramfs-Image wieder her. Masse des Wartens."
+ },
+ {
+ "stage": "Neuaufbau der Bootloader-Konfiguration",
+ "time": "10–30 s",
+ "detail": "update-grub oder proxmox-boot-tool refresh. Schnell sogar auf ZFS."
+ },
+ {
+ "stage": "NVIDIA-Treiber neu installieren (falls zutreffend)",
+ "time": "5–10 min",
+ "detail": "Laden Sie die aufgezeichnete Treiberversion herunter, kompilieren Sie die DKMS-Module mit dem aktuellen Kernel und wenden Sie den ProxMenux-Patch an, wenn die Quelle ihn hatte. Längste Einzelaufgabe."
+ },
+ {
+ "stage": "Neuinstallation von Coral und anderen Komponenten",
+ "time": "3–5 min",
+ "detail": "DKMS-Kompilierung für Coral, apt install für intel-gpu-tools und .deb-Download mit Installation für amdgpu_top."
+ },
+ {
+ "stage": "Startprüfung und Benachrichtigung",
+ "time": "~2 s",
+ "detail": "Geringer Aufwand. Die Benachrichtigung meldet dem Benutzer unmittelbar den Abschluss des Laufs."
+ }
+ ],
+ "outroBody": "Während dieser Zeit können nach der Anmeldung Werkzeuge fehlen (nvidia-smi nicht gefunden, coral nicht erkannt), weil die Neuinstallation im Hintergrund läuft. Die Abschlussmeldung markiert ihr Ende. Prüfen Sie Komponentenergebnisse, Warnungen und Protokolle auf einzelne Fehler."
+ },
+ "destructiveRollback": {
+ "heading": "Der optionale destruktive Rollback",
+ "body": "Die Wiederherstellung ist standardmäßig additiv: Zusätzliche VMs, LXCs und Komponenten bleiben erhalten. Bei Unterschieden bietet der Dialog Destruktiven Rollback ausführen? mit Nein als Vorgabe an. Zustimmung ruft vor dem Neustart _rs_execute_rollback auf, um die aufgelisteten zusätzlichen VMs und LXCs zu löschen. Komponenten werden zur manuellen Deinstallation markiert, da automatische Deinstallation nicht implementiert ist. Fehler beim Löschen von Gästen werden gemeldet; die Verarbeitung läuft weiter. Eine exakte Übereinstimmung mit dem Backup wird nicht garantiert. Prüfen Sie vor dieser destruktiven Wahl Namen und VMIDs/CTIDs."
+ },
+ "logs": {
+ "heading": "Speicherorte der Protokolle",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Vom interaktiven Schritt geschrieben. Enthält Kompatibilitätsergebnisse, Filter für Abweichungen, Anpassungsplan, Ausgabe der direkten Anwendung und Vorbereitung vorgemerkter Änderungen sowie Paketinstallation."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Von apply_pending_restore.sh beim frühen Start geschrieben. Enthält das Einlesen von plan.env, das Abarbeiten von apply-on-boot und die Pfadausschlüsse."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Geschrieben von apply_cluster_postboot.sh. Enthält: pve-cluster apply, Initramfs und Bootloader-Ausgabe, Ausgabe pro Komponente Installateur, Sanity-Check, Benachrichtigung Nutzlast."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "Ein Protokoll pro Komponenteninstallationsprogramm (nvidia, coral usw.), das im Post-Boot-Durchlauf ausgeführt wurde. Nützlich, wenn die Neuinstallation einer bestimmten Komponente fehlgeschlagen ist und der Benutzer die eigene Ausgabe des Tools benötigt."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Geschrieben von _rs_import_data_pools. Enthält: Aufzählung von Nicht-Root-Pools aus dem Manifest, Pro-Pool-Ergebnis (sauber importiert, mit -f für ausländische Hostids importiert, aufgrund fehlender Festplatten übersprungen oder fehlgeschlagen) und die Rohausgabe jedes zpool import-Aufrufs."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Wohin Sie als nächstes gehen",
+ "items": [
+ {
+ "label": "Kernübergreifende Wiederherstellung",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": "- der richtungsbewusste Safe-Subset-Filter und der Hydratationspass, der aufgerufen wird, wenn sich der Zielkernel vom Backup unterscheidet."
+ },
+ {
+ "label": "Wie es funktioniert",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": "- das Archivlayout, Manifest und Anwendungsinventar, das die Wiederherstellung verbraucht."
+ },
+ {
+ "label": "Geplante Aufträge",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": "— der unbeaufsichtigte Fluss, der die Archive produziert, die diese Seite verbraucht."
+ }
+ ]
+ }
+}
diff --git a/web/messages/de/docs/backup-restore/scheduled-jobs.json b/web/messages/de/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..dbe92ef5
--- /dev/null
+++ b/web/messages/de/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Neuer unabhängiger job — 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.",
+ "An eine bestehende PVE vzdump-Task anhängen – 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 selben Sicherungszyklus ausgeführt. Bei der Wiederherstellung stammen die Gastkonfigurationen aus dem Host-Backup (unter /etc/pve) 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 OnCalendar-Ausdruck (systemd-Kalendersyntax, z. B. daily oder Mon..Fri 03:00).",
+ "retention": "Separat abgefragt: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups-Konfiguration des übergeordneten Auftrags übernommen (über hb_pve_prune_to_keep_env eins zu eins den KEEP_*-Variablen des Ausführungsskripts zugeordnet)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Wie Attach Mode funktioniert",
+ "intro": "PVE speichert vzdump-Aufträge in /etc/pve/jobs.cfg — 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 hb_pve_list_vzdump_jobs_for_backend auf. Der Benutzer wählt einen aus."
+ },
+ {
+ "step": "2",
+ "detail": "Der .env des Jobs wird mit PVE_PARENT_JOB, PVE_STORAGE und den geerbten KEEP_*-Werten geschrieben; es wird kein systemd-Timer erstellt."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook registriert einen Skript-Hook in /etc/vzdump.conf. In der job-end-Phase jedes vzdump-Auftrags vergleicht er den übergebenen $STOREID mit PVE_STORAGE 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: path/dump/ 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 KEEP_* 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 run_scheduled_backup.sh JOB_ID auf. Der Timer plant es mit Persistent=true (verpasste Ausführungen werden beim nächsten Boot nachgeholt) und einem kleinen RandomizedDelaySec=120, 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 hb_install_vzdump_hook installiert; vergleicht PVE_STORAGE jedes angehängten Auftrags mit $STOREID, 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": [
+ "Backup vorbereiten. 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.",
+ "An das Ziel schreiben. Überträgt oder schreibt das Archiv in das konfigurierte Ziel – eine lokale .tar.zst-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.",
+ "Aufbewahrungsregeln anwenden. Entfernt alte Backups vom Zielort, wobei die Anzahl der keep-last / keep-daily / keep-weekly für den Auftrag konfiguriert bleibt. Das Beschneiden wird vom Zielort selbst durchgeführt: PBS wendet seine eigene Aufbewahrung an, Borg führt borg prune aus und bei Lokal löscht ProxMenux die Dateien, die außerhalb des keep-last-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: systemctl enable/disable --now der Timer. Attach-Modus: Dreht das ENABLED-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: /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log – 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 hb_notify_lifecycle-Ereignisse ab wie der interaktive Fluss (start, complete, fail). Wenn Benachrichtigungskanäle im Monitor konfiguriert sind, tauchen unbeaufsichtigte Jobs auf die gleiche Weise wie manuelle Backups auf - ein Benutzer muss das Protokoll nicht überprüfen, um zu wissen, ob ein Job erfolgreich war."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/en/docs/backup-restore/cross-kernel.json b/web/messages/en/docs/backup-restore/cross-kernel.json
index e774df5e..7d003ddd 100644
--- a/web/messages/en/docs/backup-restore/cross-kernel.json
+++ b/web/messages/en/docs/backup-restore/cross-kernel.json
@@ -20,9 +20,21 @@
"heading": "The direction check",
"intro": "During the compatibility check, hb_compat_check compares the kernel recorded in the backup's manifest against the target's current kernel (uname -r) and classifies the restore into one of three cases, stored in the internal variable HB_COMPAT_KERNEL_DIRECTION:",
"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 same. 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 same. 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 hb_unsafe_paths_cross_version to RS_SKIP_PATHS. 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 hb_unsafe_paths_cross_version to RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel", "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools", "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs", "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 (zpool.cache + hostid) that can lock the pool as foreign." },
- { "category": "APT sources", "paths": "/etc/apt", "reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade." },
- { "category": "systemd", "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf", "reason": "Unit overrides and .wants tied to the older systemd major; configuration keys that may not parse on a newer systemd." }
+ {
+ "category": "Bootloader",
+ "paths": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) that can lock the pool as foreign."
+ },
+ {
+ "category": "APT sources",
+ "paths": "/etc/apt",
+ "reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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 GRUB_TIMEOUT, 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 GRUB_TIMEOUT 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). _rs_hyd_grub merges every token from the backup's manifest.kernel_params.cmdline_extra into the target's live GRUB_CMDLINE_LINUX_DEFAULT, skipping tokens whose key the target already carries. Then merges whitelisted GRUB_* keys (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) from the backup's /etc/default/grub if they differ from the target's." },
- { "phase": "1b — systemd-boot / ZFS path", "detail": "For hosts using systemd-boot (typically ZFS-on-root). _rs_hyd_kernel_cmdline merges user tokens from cmdline_extra into the target's /etc/kernel/cmdline, keeping the target's own root=, boot= and rootflags= boilerplate intact." },
- { "phase": "2 — /etc/modules merge", "detail": "_rs_hyd_modules appends modules from manifest.kernel_params.modules_loaded_at_boot that are in the whitelist (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) AND not already present in the target's /etc/modules." },
- { "phase": "3 — Whitelisted files copy", "detail": "_rs_hyd_files copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under /etc/modprobe.d, /etc/modules-load.d, and the ProxMenux VFIO bind rule + nvidia udev rules under /etc/udev/rules.d. Distro-owned files (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 propagates through plan.env to apply_pending_restore.sh, which forces NEEDS_INITRAMFS=1 and NEEDS_GRUB=1 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). _rs_hyd_grub merges every token from the backup's manifest.kernel_params.cmdline_extra into the target's live GRUB_CMDLINE_LINUX_DEFAULT, skipping tokens whose key the target already carries. Then merges whitelisted GRUB_* keys (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) from the backup's /etc/default/grub if they differ from the target's."
+ },
+ {
+ "phase": "1b — systemd-boot / ZFS path",
+ "detail": "For hosts using systemd-boot (typically ZFS-on-root). _rs_hyd_kernel_cmdline merges user tokens from cmdline_extra into the target's /etc/kernel/cmdline, keeping the target's own root=, boot= and rootflags= boilerplate intact."
+ },
+ {
+ "phase": "2 — /etc/modules merge",
+ "detail": "_rs_hyd_modules appends modules from manifest.kernel_params.modules_loaded_at_boot that are in the whitelist (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) AND not already present in the target's /etc/modules."
+ },
+ {
+ "phase": "3 — Whitelisted files copy",
+ "detail": "_rs_hyd_files copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under /etc/modprobe.d, /etc/modules-load.d, and the ProxMenux VFIO bind rule + nvidia udev rules under /etc/udev/rules.d. Distro-owned files (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 propagates through plan.env to apply_pending_restore.sh, which forces NEEDS_INITRAMFS=1 and NEEDS_GRUB=1 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 intel_iommu=on iommu=pt in the cmdline, vfio/vfio_pci/vfio_iommu_type1 in /etc/modules, an /etc/modprobe.d/vfio.conf with options vfio-pci ids=10de:2216, and a /etc/modprobe.d/blacklist-nvidia.conf. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to /etc/modules, 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 GRUB_TIMEOUT=1 and GRUB_DISABLE_OS_PROBER=true. Hydration reads both keys from the backup's /etc/default/grub, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including GRUB_DISTRIBUTOR, untouched)." }
+ {
+ "scenario": "GPU passthrough (VFIO)",
+ "detail": "Source had intel_iommu=on iommu=pt in the cmdline, vfio/vfio_pci/vfio_iommu_type1 in /etc/modules, an /etc/modprobe.d/vfio.conf with options vfio-pci ids=10de:2216, and a /etc/modprobe.d/blacklist-nvidia.conf. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to /etc/modules, 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 GRUB_TIMEOUT=1 and GRUB_DISABLE_OS_PROBER=true. Hydration reads both keys from the backup's /etc/default/grub, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including GRUB_DISTRIBUTOR, 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": "hb_compat_check in lib_host_backup_common.sh. Sets HB_COMPAT_KERNEL_DIRECTION." },
- { "component": "Safe-subset path list", "location": "hb_unsafe_paths_cross_version in lib_host_backup_common.sh. Emits path\\treason lines used by both the CLI filter and the Web endpoint /api/host-backups/restore/prepare." },
- { "component": "Hydration phases", "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files in backup_host.sh. Orchestrated by _rs_apply_bk_older_hydration." },
- { "component": "Post-boot reflow forcing", "location": "apply_pending_restore.sh reads HB_HYDRATION_APPLIED from plan.env and forces NEEDS_INITRAMFS=1/NEEDS_GRUB=1." },
- { "component": "Web preview", "location": "/api/host-backups/restore/prepare in flask_server.py. Sources the helper library, runs _rs_apply_bk_older_hydration in plan mode, returns the actions to the Web modal." }
+ {
+ "component": "Direction detection",
+ "location": "hb_compat_check in lib_host_backup_common.sh. Sets HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Safe-subset path list",
+ "location": "hb_unsafe_paths_cross_version in lib_host_backup_common.sh. Emits path\\treason lines used by both the CLI filter and the Web endpoint /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Hydration phases",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files in backup_host.sh. Orchestrated by _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Post-boot reflow forcing",
+ "location": "apply_pending_restore.sh reads HB_HYDRATION_APPLIED from plan.env and forces NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Web preview",
+ "location": "/api/host-backups/restore/prepare in flask_server.py. Sources the helper library, runs _rs_apply_bk_older_hydration 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 kernel_params 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 kernel_params block hydration reads from."
+ }
]
}
}
diff --git a/web/messages/en/docs/backup-restore/destinations/borg.json b/web/messages/en/docs/backup-restore/destinations/borg.json
index 78d5a3ec..bebe8813 100644
--- a/web/messages/en/docs/backup-restore/destinations/borg.json
+++ b/web/messages/en/docs/backup-restore/destinations/borg.json
@@ -24,19 +24,47 @@
"heading": "The borg binary",
"intro": "Borg is not a base dependency of the ProxMenux installer. When a backup runs, hb_ensure_borg resolves the binary from four sources in order and returns the first that works:",
"rows": [
- { "priority": "1", "source": "System borg", "detail": "If the host already has borg installed via APT (which borg resolves), that binary is used." },
- { "priority": "2", "source": "State-dir cache", "detail": "/usr/local/share/proxmenux/borg — kept from a prior GitHub download on this host." },
- { "priority": "3", "source": "Monitor AppImage bundle", "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working borg." },
- { "priority": "4", "source": "GitHub download", "detail": "wget against the pinned borg-linux64 URL under github.com/borgbackup/borg/releases/, verified against a constant SHA-256 in lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg",
+ "detail": "If the host already has borg installed via APT (which borg resolves), that binary is used."
+ },
+ {
+ "priority": "2",
+ "source": "State-dir cache",
+ "detail": "/usr/local/share/proxmenux/borg — kept from a prior GitHub download on this host."
+ },
+ {
+ "priority": "3",
+ "source": "Monitor AppImage bundle",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working borg."
+ },
+ {
+ "priority": "4",
+ "source": "GitHub download",
+ "detail": "wget against the pinned borg-linux64 URL under github.com/borgbackup/borg/releases/, verified against a constant SHA-256 in lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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 borg serve. 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 hb_prompt_mounted_path, 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 /usr/bin/borg", "detail": "The command=\"/usr/bin/borg serve ...\" line ProxMenux writes into authorized_keys hard-codes that path. Installing via APT (apt install borgbackup) puts it there. A standalone binary must be symlinked to /usr/bin/borg." },
- { "requirement": "A dedicated user account (typically borg)", "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 /backup/borgbackup) must exist on the server and be owned by the borg user." },
- { "requirement": "SSH daemon accepting the borg user", "detail": "PubkeyAuthentication yes (default). Password authentication is only needed for the one-shot generate-auto flow — after the key is installed, the server can disable password auth entirely." }
+ {
+ "requirement": "borg binary at /usr/bin/borg",
+ "detail": "The command=\"/usr/bin/borg serve ...\" line ProxMenux writes into authorized_keys hard-codes that path. Installing via APT (apt install borgbackup) puts it there. A standalone binary must be symlinked to /usr/bin/borg."
+ },
+ {
+ "requirement": "A dedicated user account (typically borg)",
+ "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 /backup/borgbackup) must exist on the server and be owned by the borg user."
+ },
+ {
+ "requirement": "SSH daemon accepting the borg user",
+ "detail": "PubkeyAuthentication yes (default). Password authentication is only needed for the one-shot generate-auto 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 generate-auto 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 borg serve on that path."
+ "minimalSetupNote": "With the server prepared and SSH password authentication available, ProxMenux’s generate-auto 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 borg serve 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 borg serve. This user is typically named borg, 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, port 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 ~/.ssh/borg_proxmenux_HOST_ed25519, then uses sshpass to log in ONCE to the server with the admin password and append the public key to ~borg/.ssh/authorized_keys. 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 authorized_keys line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for." },
- { "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 pct exec from the PVE host — root on the PVE host writes into the LXC's ~borg/.ssh/authorized_keys without needing SSH into the LXC itself." },
- { "mode": "existing", "label": "Use an existing key", "detail": "ProxMenux scans /root/.ssh/ and $HOME/.ssh/ for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path." },
- { "mode": "none", "label": "Default SSH config", "detail": "No custom key — Borg relies on the host's default SSH configuration (typically ~/.ssh/id_rsa or an SSH agent)." }
+ {
+ "mode": "generate-auto",
+ "label": "Recommended",
+ "detail": "ProxMenux generates or reuses an ed25519 keypair at ~/.ssh/borg_proxmenux_HOST_ed25519, then uses sshpass for a login probe and installation of the public key in ~borg/.ssh/authorized_keys. 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 authorized_keys line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for."
+ },
+ {
+ "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 pct exec from the PVE host — root on the PVE host writes into the LXC's ~borg/.ssh/authorized_keys without needing SSH into the LXC itself."
+ },
+ {
+ "mode": "existing",
+ "label": "Use an existing key",
+ "detail": "ProxMenux scans /root/.ssh/ and $HOME/.ssh/ for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path."
+ },
+ {
+ "mode": "none",
+ "label": "Default SSH config",
+ "detail": "No custom key — Borg relies on the host's default SSH configuration (typically ~/.ssh/id_rsa or an SSH agent)."
+ }
],
"restrictTitle": "The authorized_keys line",
"restrictBody": "For every generated key, the authorized_keys 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: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. Read by hb_collect_borg_configs to populate the target-selection menu." },
- { "file": "borg-pass-NAME.txt", "content": "Passphrase for the target NAMEd above (chmod 600). Only present when the operator chose repokey encryption." }
+ {
+ "file": "borg-targets.txt",
+ "content": "One line per target: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. Read by hb_collect_borg_configs to populate the target-selection menu."
+ },
+ {
+ "file": "borg-pass-NAME.txt",
+ "content": "Passphrase for the target NAMEd above (chmod 600). 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 hb_borg_init_if_needed: the modern borg repo-create -e MODE when available, or the legacy borg init --encryption=MODE. ProxMenux exposes two modes: repokey (default) and none. In repokey 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 borg-pass-NAME.txt. 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 hb_borg_init_if_needed: the modern borg repo-create -e MODE when available, or the legacy borg init --encryption=MODE. ProxMenux exposes two modes: repokey (default) and none. In repokey 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 borg-pass-NAME.txt 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 borg. 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 repokey encryption. Never appears in the process argument list." },
- { "var": "BORG_ENCRYPT_MODE", "value": "repokey | none", "purpose": "Used by hb_borg_init_if_needed when initialising a repository that does not yet exist. Ignored by borg create 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. When a target is first added with a non-default port, ProxMenux also appends -p PORT; saved targets, scheduled jobs and the Monitor rely on the port in the ssh:// URL instead. Without a custom key, and for a newly added target with 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 repokey encryption. Never appears in the process argument list."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Used by hb_borg_init_if_needed when initialising a repository that does not yet exist. Ignored by borg create 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": {
diff --git a/web/messages/en/docs/backup-restore/destinations/index.json b/web/messages/en/docs/backup-restore/destinations/index.json
index a1d262a2..5f0f8ff2 100644
--- a/web/messages/en/docs/backup-restore/destinations/index.json
+++ b/web/messages/en/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — but all four share the same staging step (hb_prepare_staging) 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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — but all three share the same staging step (hb_prepare_staging) 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 tar --zstd. 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",
diff --git a/web/messages/en/docs/backup-restore/destinations/pbs.json b/web/messages/en/docs/backup-restore/destinations/pbs.json
index 270f1b02..e5aac4e6 100644
--- a/web/messages/en/docs/backup-restore/destinations/pbs.json
+++ b/web/messages/en/docs/backup-restore/destinations/pbs.json
@@ -41,7 +41,7 @@
},
"backupCommand": {
"heading": "The backup command",
- "intro": "The upload is a single invocation of proxmox-backup-client backup. ProxMenux runs it inside an env wrapper so credentials never appear in the process argument list.",
+ "intro": "The upload is a single invocation of proxmox-backup-client backup. ProxMenux uses env to pass the password, encryption password and fingerprint to the client as environment variables.",
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
"backupIdTitle": "Backup ID naming",
"backupIdBody": "The default backup ID is hostcfg-HOSTNAME. The operator is asked to confirm or edit it before the upload; any characters outside [A-Za-z0-9_-] are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a group, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.",
@@ -61,13 +61,13 @@
"modesSharedTitle": "Shared keyfile (import on every host)",
"modesSharedBody": "One master keyfile generated once and installed on every host via the Use an existing keyfile option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.",
"recoveryTitle": "Upload key to PBS — the operator decides",
- "recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — Upload key to PBS? — with two answers. Nothing gets uploaded to PBS until the operator answers Yes. The default is No, keep local only: 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 Download keyfile button in the PBS destination row provides one on demand). Choosing Yes, upload prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce pbs-key.recovery.enc. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile 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 — Upload key to PBS? — with two answers. No recovery artifact is uploaded to PBS until the operator answers Yes. The default is No, keep local only: the keyfile stays at the canonical local path, ProxMenux uploads no recovery artifact to PBS, and the operator handles the offsite copy themselves (the Monitor’s Download keyfile button in the PBS destination row provides one on demand). Choosing Yes, upload prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce pbs-key.recovery.enc. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile is sent to PBS during these uploads. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
"blobUploadTitle": "Paired backup group on PBS",
"blobUploadBody1": "When the escrow mode is Yes, upload, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in -keyrecovery. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. The envelope never leaves the host in plaintext: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS receives only the already-encrypted envelope.",
"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 proxmox-backup-client backup invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by 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 proxmox-backup-client backup invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by the PBS client with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
"blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.",
"blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.",
"recoverTitle": "Recovery on a fresh host",
diff --git a/web/messages/en/docs/backup-restore/glossary.json b/web/messages/en/docs/backup-restore/glossary.json
index e750271d..35974d12 100644
--- a/web/messages/en/docs/backup-restore/glossary.json
+++ b/web/messages/en/docs/backup-restore/glossary.json
@@ -28,7 +28,7 @@
{
"id": "clave-cifrado",
"term": "Keyfile (encryption key)",
- "def": "Binary file that Proxmox Backup Server uses to encrypt the chunks of each backup before uploading them. Without this file, no encrypted backup can be read. ProxMenux stores it at /usr/local/share/proxmenux/pbs-key.conf with mode 600. This is the asset that has to be protected; the recovery envelope exists precisely so that this file can be rescued if it is lost."
+ "def": "Key file used by proxmox-backup-client to encrypt the chunks before uploading them to PBS. Without the matching key, encrypted backup data cannot be read. ProxMenux stores the file at /usr/local/share/proxmenux/pbs-key.conf with mode 600. Protect it: the recovery envelope 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 vzdump 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 vzdump job-end hook triggers it after guest backups when the destination storage matches. The selected parent supplies the storage and the retention, which is re-read from the parent job on every run, 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",
diff --git a/web/messages/en/docs/backup-restore/how-it-works.json b/web/messages/en/docs/backup-restore/how-it-works.json
index dc68cee6..5651f7ef 100644
--- a/web/messages/en/docs/backup-restore/how-it-works.json
+++ b/web/messages/en/docs/backup-restore/how-it-works.json
@@ -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 .tar.zst, PBS backup or Borg archive) contains this exact layout. The restore reads the three payloads independently, in a specific order that guarantees correctness: rootfs is copied first to lay down configuration, the manifest is consulted to detect drift and decide what to skip, and the application inventory 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 .tar.zst, PBS backup or Borg archive) contains this exact layout. The restore uses all three: the manifest is consulted before applying changes to detect drift and decide what to skip; rootfs supplies the configuration files, applied live or deferred until reboot; and the application inventory 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 rootfs/ tree is a plain filesystem copy produced by rsync from the source host. It contains a curated default profile of paths that matter for a Proxmox restore, plus any custom paths added by the user to the backup job or interactive session. The set is deliberately narrow: only paths that either hold configuration or hold state that Proxmox cannot regenerate on its own.",
"defaultProfileTitle": "The default profile",
- "defaultProfileBody": "The default profile is defined by hb_default_profile_paths in lib_host_backup_common.sh. It covers eight categories that together describe a working Proxmox host:",
+ "defaultProfileBody": "The default profile is defined by hb_default_profile_paths in lib_host_backup_common.sh. 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 metadata/ 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 metadata/ 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 apt-mark showmanual: every APT package that was explicitly installed 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 _rs_run_complete_extras during restore, filtered through a three-pass cascade-safe filter (dpkg -s for already-installed, sibling-major detection for library packages, apt-get install --simulate for cascade-remove risk), then installed with apt-get install -y.",
"componentsTitle": "components_status.json (part of the rootfs)",
diff --git a/web/messages/en/docs/backup-restore/restoring.json b/web/messages/en/docs/backup-restore/restoring.json
index 51c2ce22..cd16d81a 100644
--- a/web/messages/en/docs/backup-restore/restoring.json
+++ b/web/messages/en/docs/backup-restore/restoring.json
@@ -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 compute_rollback_plan.sh. 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 compute_rollback_plan.sh. 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 (HB_COMPAT_RESULTS) 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 immediately as well, but whose actual effect only kicks in on the next boot: the kernel only reads /etc/default/grub when the bootloader starts, /etc/fstab when filesystems are mounted at boot, /etc/modules 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: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/initramfs-tools."
+ "detail": "Paths deferred to the next boot, rather than applied immediately by this restore flow. They affect boot-time configuration: bootloader generation reads /etc/default/grub, filesystem mounting uses /etc/fstab, and module loading uses /etc/modules. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
},
{
"class": "dangerous",
- "detail": "Paths that are NOT applied on the running system — 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: /etc/pve (pmxcfs is a live FUSE mount; writing directly to it bypasses it), /var/lib/pve-cluster (live cluster data), /etc/network (could reconfigure the very interface the user is connected on over SSH and drop the session)."
+ "detail": "Paths that are NOT applied on the running system — a live write could corrupt state or drop the active connection. These are staged in the pending set: /etc/network is written early in the next boot, before networking starts, and /etc/pve is written by the post-boot dispatcher once the cluster filesystem is up. Examples: /etc/pve (pmxcfs is a live FUSE mount holding active cluster configuration), /var/lib/pve-cluster (live cluster data, kept in the recovery directory for manual recovery only), /etc/network (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 components_status.json and iterates over the registered installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each installer runs in --auto-reinstall 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 components_status.json and iterates over the registered supported installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each selected installer runs in --auto-reinstall 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 apply_cluster_postboot.service as it runs. The card is driven by /var/lib/proxmenux/restore-state.json, 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 proxmenux-apply-cluster-postboot.service as it runs. The card is driven by /var/lib/proxmenux/restore-state.json, 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 [ OK ] Finished proxmenux-apply-cluster-postboot.service line. When that line appears — usually alongside the OKs for multi-user.target and graphical.target — 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 [ OK ] Finished proxmenux-apply-cluster-postboot.service, often near the OKs for multi-user.target and graphical.target. 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 (nvidia-smi not found, coral 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 (nvidia-smi not found, coral 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: Execute destructive rollback?. Accepting it triggers _rs_execute_rollback, 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 Execute destructive rollback?, defaulting to No. Accepting calls _rs_execute_rollback 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",
diff --git a/web/messages/en/docs/backup-restore/scheduled-jobs.json b/web/messages/en/docs/backup-restore/scheduled-jobs.json
index 5357ec6a..b5a3acf2 100644
--- a/web/messages/en/docs/backup-restore/scheduled-jobs.json
+++ b/web/messages/en/docs/backup-restore/scheduled-jobs.json
@@ -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 same window as the guests. On restore, the guest configs come from the host backup (they live under /etc/pve), 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 same backup cycle. On restore, guest configurations come from the host backup (under /etc/pve) 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 OnCalendar expression (systemd calendar syntax — e.g. daily, Mon..Fri 03:00).", "retention": "Prompted separately: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups configuration (mapped one-to-one to the runner's KEEP_* variables via hb_pve_prune_to_keep_env)." }
+ {
+ "mode": "New scheduled job",
+ "backends": "Local, PBS, Borg",
+ "schedule": "Own OnCalendar expression (systemd calendar syntax — e.g. daily, Mon..Fri 03:00).",
+ "retention": "Prompted separately: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups configuration (mapped one-to-one to the runner's KEEP_* variables via hb_pve_prune_to_keep_env)."
+ }
]
},
"attachDetail": {
"heading": "How attach mode works",
- "intro": "PVE writes vzdump tasks to /etc/pve/jobs.cfg — 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 vzdump tasks to /etc/pve/jobs.cfg — 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 hb_pve_list_vzdump_jobs_for_backend. The user picks one." },
- { "step": "2", "detail": "The job's .env is written with PVE_PARENT_JOB, PVE_STORAGE and the inherited KEEP_* values; no systemd timer is created." },
- { "step": "3", "detail": "hb_install_vzdump_hook registers a script-hook in /etc/vzdump.conf. When PVE runs any vzdump task, the hook script fires; if the $STOREID passed to it matches an attached job's PVE_STORAGE, the runner is invoked for that job." },
- { "step": "4", "detail": "The archive lands in the same storage the vzdump dumps just wrote to: path/dump/ 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 hb_pve_list_vzdump_jobs_for_backend. The user picks one."
+ },
+ {
+ "step": "2",
+ "detail": "The job's .env is written with PVE_PARENT_JOB, PVE_STORAGE and the inherited KEEP_* values; no systemd timer is created."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook registers a script-hook in /etc/vzdump.conf. In the job-end phase of any vzdump task, it compares the supplied $STOREID with each enabled attached job’s PVE_STORAGE 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: path/dump/ 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 KEEP_* 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 run_scheduled_backup.sh JOB_ID. The timer schedules it with Persistent=true (missed fires run at next boot) and a small RandomizedDelaySec=120 to spread load when multiple jobs share the same OnCalendar expression." },
- { "path": "/etc/vzdump.conf script-hook", "content": "Attach mode only. Installed once by hb_install_vzdump_hook; matches every attached job's PVE_STORAGE against the $STOREID 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 KEEP_* 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 run_scheduled_backup.sh JOB_ID. The timer schedules it with Persistent=true (missed fires run at next boot) and a small RandomizedDelaySec=120 to spread load when multiple jobs share the same OnCalendar expression."
+ },
+ {
+ "path": "/etc/vzdump.conf script-hook",
+ "content": "Attach mode only. Installed once by hb_install_vzdump_hook; matches every attached job's PVE_STORAGE against the $STOREID 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: systemctl enable/disable --now the timer. Attach mode: flips the ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — 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: systemctl enable/disable --now the timer. Attach mode: flips the ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — 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."
+ }
]
}
}
diff --git a/web/messages/es/docs/backup-restore/creating-backups.json b/web/messages/es/docs/backup-restore/creating-backups.json
index 8bca0e53..b3805757 100644
--- a/web/messages/es/docs/backup-restore/creating-backups.json
+++ b/web/messages/es/docs/backup-restore/creating-backups.json
@@ -1,20 +1,20 @@
{
"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.",
- "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",
- "twitterDescription": "Flujo interactivo de copia con tres destinos y dos modos de perfil."
+ "title": "Crear backups — flujo interactivo de backup | ProxMenux",
+ "description": "El flujo interactivo de backup 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 un backup y ver el archivo aterrizando en el destino.",
+ "ogTitle": "ProxMenux Backup — crear backups",
+ "ogDescription": "El flujo interactivo de backup con tres destinos, dos perfiles y un paso común de staging.",
+ "twitterTitle": "Crear backups | ProxMenux",
+ "twitterDescription": "Flujo interactivo de backup con tres destinos y dos modos de perfil."
},
"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.",
+ "title": "Crear backups",
+ "description": "El flujo interactivo de backup: 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"
},
"intro": {
"title": "Dos puntos de entrada, funcionalidad idéntica",
- "body": "El TUI de Scripts y la UI Web del Monitor exponen exactamente la misma funcionalidad. 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 (_bk_pbs, _bk_borg o _bk_local). 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 UI Web del Monitor exponen exactamente la misma funcionalidad. Cada backup — manual o programado — pasa por la misma matriz de elección (tres destinos × dos perfiles) e invoca la misma función backend por celda (_bk_pbs, _bk_borg o _bk_local). 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."
},
"entryPoints": {
"heading": "Los dos puntos de entrada",
@@ -32,11 +32,11 @@
]
},
"modes": {
- "heading": "Copias manuales vs programadas",
- "body": "Las copias se pueden producir en dos modos: manuales (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 programadas (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 run_scheduled_backup.sh; los archivos producidos son indistinguibles.",
+ "heading": "Backups manuales vs programados",
+ "body": "Los backups se pueden producir en dos modos: manuales (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 programadas (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 run_scheduled_backup.sh; 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."
+ "monitorCaption": "Backup programado — Monitor de ProxMenux. El mismo diálogo estilo asistente que crea un backup manual lleva los campos de horario y retención al final para la ruta desatendida."
},
"matrix": {
"heading": "La matriz de seis opciones",
@@ -83,13 +83,13 @@
"profiles": {
"heading": "Perfil Default vs Custom",
"defaultTitle": "Perfil Default",
- "defaultBody": "El perfil por defecto es la lista curada de hb_default_profile_paths (documentada en Cómo funciona bajo Categorías de rutas) más cada entrada del fichero de extras persistentes /usr/local/share/proxmenux/backup-extra-paths.txt. El usuario confirma el destino y las opciones de cifrado y la copia continúa sin más selección de rutas.",
+ "defaultBody": "El perfil por defecto es la lista curada de hb_default_profile_paths (documentada en Cómo funciona bajo Categorías de rutas) más cada entrada del fichero de extras persistentes /usr/local/share/proxmenux/backup-extra-paths.txt. El usuario confirma el destino y las opciones de cifrado y el backup continúa sin más selección de rutas.",
"customTitle": "Perfil Custom",
- "customBody": "El perfil Custom abre un checklist mostrando cada ruta del perfil por defecto (sin marcar) y cada extra persistente (premarcado, prefijado con [+]). El usuario marca el conjunto para esa ejecución y puede pulsar Add custom path para añadir una nueva ruta absoluta. Cualquier ruta añadida en línea se persiste en backup-extra-paths.txt 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 Manage custom paths separada, fuera del flujo de copia.",
+ "customBody": "El perfil Custom abre un checklist mostrando cada ruta del perfil por defecto (sin marcar) y cada extra persistente (premarcado, prefijado con [+]). El usuario marca el conjunto para esa ejecución y puede pulsar Add custom path para añadir una nueva ruta absoluta. Cualquier ruta añadida en línea se persiste en backup-extra-paths.txt para que futuros backups 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 Manage custom paths separada, fuera del flujo de backup.",
"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.",
"manageCustomAlt": "Menú Manage custom paths mostrando la lista de extras persistentes y opciones para añadirlos, eliminarlos o editarlos.",
- "manageCustomCaption": "Manage custom paths — el punto de entrada donde se añaden o eliminan los extras persistentes. Cada ruta listada aquí se incluye automáticamente en las copias en modo Default sin necesidad de abrir el picker Custom."
+ "manageCustomCaption": "Manage custom paths — el punto de entrada donde se añaden o eliminan los extras persistentes. Cada ruta listada aquí se incluye automáticamente en los backups en modo Default sin necesidad de abrir el picker Custom."
},
"commonPipeline": {
"heading": "Qué se ejecuta con independencia del destino",
@@ -98,7 +98,7 @@
{
"step": "1",
"name": "Ensamblado del rootfs",
- "detail": "Ejecuta rsync -a por cada ruta seleccionada hacia staging_root/rootfs/. La base pmxcfs en /var/lib/pve-cluster/config.db se captura aparte con sqlite3 .backup para obtener un snapshot consistente sin parar el clúster, y los sidecars .db-wal / .db-shm se excluyen del rsync; si sqlite3 no está disponible, se deposita un config.db.raw-fallback que la restauración promociona al importar. Excluye subrutas volátiles (historial de bash, cachés, papelera) de /root/. Las rutas ausentes en el origen se registran en metadata/missing_paths.txt sin detener la copia."
+ "detail": "Ejecuta rsync -a por cada ruta seleccionada hacia staging_root/rootfs/. La base pmxcfs en /var/lib/pve-cluster/config.db se captura aparte con sqlite3 .backup para obtener un snapshot consistente sin parar el clúster, y los sidecars .db-wal / .db-shm se excluyen del rsync; si sqlite3 no está disponible, se deposita un config.db.raw-fallback que la restauración promociona al importar. Excluye subrutas volátiles (historial de bash, cachés, papelera) de /root/. Las rutas ausentes en el origen se registran en metadata/missing_paths.txt sin detener el backup."
},
{
"step": "2",
@@ -113,7 +113,7 @@
{
"step": "4",
"name": "Info de la ejecución",
- "detail": "metadata/run_info.env registra la identidad de la ejecución de copia — hostname, timestamp, versión del kernel — usada por el chequeo de compatibilidad de la restauración para determinar la dirección cross-kernel."
+ "detail": "metadata/run_info.env registra la identidad de la ejecución de backup — hostname, timestamp, versión del kernel — usada por el chequeo de compatibilidad de la restauración para determinar la dirección cross-kernel."
},
{
"step": "5",
@@ -150,9 +150,9 @@
"ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
],
"notInProfileTitle": "Rutas fuera del perfil",
- "notInProfileBody": "Todo lo que no esté listado en hb_default_profile_paths y no se haya añadido como ruta custom o extra persistente no forma parte de la copia. Ejemplos notables:",
+ "notInProfileBody": "Todo lo que no esté listado en hb_default_profile_paths y no se haya añadido como ruta custom o extra persistente no forma parte del backup. Ejemplos notables:",
"notInProfileItems": [
- "Discos de VMs y LXCs — los gestiona vzdump, no esta funcionalidad. Los ficheros de configuración de los invitados bajo /etc/pve/nodes/*/qemu-server/*.conf y lxc/*.conf sí se capturan (viven bajo /etc/pve) para que la restauración reproduzca el inventario; los discos se re-adjuntan desde una copia existente de vzdump/PBS.",
+ "Discos de VMs y LXCs — los gestiona vzdump, no esta funcionalidad. Los ficheros de configuración de los invitados bajo /etc/pve/nodes/*/qemu-server/*.conf y lxc/*.conf sí se capturan (viven bajo /etc/pve) para que la restauración reproduzca el inventario; los discos se re-adjuntan desde un backup existente de vzdump/PBS.",
"/boot y /boot/efi — los binarios del kernel, el initramfs y la partición ESP UEFI los regenera el propio destino con update-initramfs, update-grub o proxmox-boot-tool refresh tras la restauración. El bootloader nunca se copia verbatim.",
"Filesystems runtime del kernel y sistema — /proc, /sys, /dev y /run son pseudo-filesystems que produce el kernel y udev; no se persisten en ningún sitio.",
"Binarios de paquetes bajo /usr/bin, /usr/lib, /lib, /sbin — los reinstala el APT del destino a partir de packages.manual.list.",
@@ -160,7 +160,7 @@
"/home/USER — 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 backup-extra-paths.txt pasa por el mismo pipeline de rsync que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo /root/ o /usr/local/share/proxmenux/, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en metadata/paths_archived.txt. Las rutas que no existen en el origen se registran en metadata/missing_paths.txt sin detener la copia."
+ "customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en backup-extra-paths.txt pasa por el mismo pipeline de rsync que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo /root/ o /usr/local/share/proxmenux/, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en metadata/paths_archived.txt. Las rutas que no existen en el origen se registran en metadata/missing_paths.txt sin detener el backup."
},
"archiveStructure": {
"heading": "Estructura del archivo",
@@ -169,7 +169,7 @@
},
"confirmation": {
"heading": "Resumen de confirmación",
- "body": "Antes de que el backend escriba nada en el destino, ProxMenux muestra un diálogo resumen con el destino, el backup ID o nombre del archivo, el estado del cifrado y la lista de rutas que se copian. Cancelar aquí aborta la copia limpiamente — el directorio de staging se elimina por el hook trap definido en la función backend y ningún dato parcial llega al destino."
+ "body": "Antes de que el backend escriba nada en el destino, ProxMenux muestra un diálogo resumen con el destino, el backup ID o nombre del archivo, el estado del cifrado y la lista de rutas que se copian. Cancelar aquí aborta el backup limpiamente — el directorio de staging se elimina por el hook trap definido en la función backend y ningún dato parcial llega al destino."
},
"writing": {
"heading": "Escritura en el destino",
@@ -181,7 +181,7 @@
},
{
"topic": "Sidecar (sólo local)",
- "detail": "hb_write_archive_sidecar deposita un *.proxmenux.json junto al archivo local para que el Monitor lo identifique como copia de host de ProxMenux incluso tras movimientos o renombrados."
+ "detail": "hb_write_archive_sidecar deposita un *.proxmenux.json junto al archivo local para que el Monitor lo identifique como backup de host de ProxMenux incluso tras movimientos o renombrados."
},
{
"topic": "Notificación (complete/fail)",
@@ -190,12 +190,12 @@
]
},
"finishedScreens": {
- "heading": "Cómo se ve una copia finalizada",
+ "heading": "Cómo se ve un backup finalizado",
"intro": "El mismo evento de finalización lo exponen los dos puntos de entrada. El TUI escribe un bloque resumen en el terminal; la pestaña Backups del Monitor muestra la ejecución en la lista de archivos con badges de tamaño, duración y estado.",
- "scriptsAlt": "TUI de ProxMenux Scripts mostrando una copia de host finalizada — destino, backup ID, ruta del snapshot, tamaño de datos, duración y estado de cifrado.",
- "scriptsCaption": "Copia finalizada — ProxMenux Scripts (TUI). El bloque de finalización imprime el destino, backup ID, nombre del snapshot o archivo resultante, tamaño de datos, duración y estado de cifrado.",
- "monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando una entrada de copia de host finalizada con tamaño, duración, badge del método y indicador de cifrado.",
- "monitorCaption": "Copia finalizada — pestaña Backups del Monitor de ProxMenux. La nueva copia aparece en la lista de archivos con el badge del método del destino, tamaño, duración y — cuando aplica — el indicador de cifrado."
+ "scriptsAlt": "TUI de ProxMenux Scripts mostrando un backup de host finalizado — destino, backup ID, ruta del snapshot, tamaño de datos, duración y estado de cifrado.",
+ "scriptsCaption": "Backup finalizado — ProxMenux Scripts (TUI). El bloque de finalización imprime el destino, backup ID, nombre del snapshot o archivo resultante, tamaño de datos, duración y estado de cifrado.",
+ "monitorAlt": "Pestaña Backups del Monitor de ProxMenux mostrando una entrada de backup de host finalizado con tamaño, duración, badge del método y indicador de cifrado.",
+ "monitorCaption": "Backup finalizado — pestaña Backups del Monitor de ProxMenux. El nuevo backup aparece en la lista de archivos con el badge del método del destino, tamaño, duración y — cuando aplica — el indicador de cifrado."
},
"whereNext": {
"heading": "A dónde seguir",
@@ -208,7 +208,7 @@
{
"label": "Trabajos programados",
"href": "/docs/backup-restore/scheduled-jobs",
- "tail": " — ejecutar la misma copia desatendida en un horario en lugar de interactivamente."
+ "tail": " — ejecutar el mismo backup desatendido en un horario en lugar de interactivamente."
},
{
"label": "Restauración",
diff --git a/web/messages/es/docs/backup-restore/cross-kernel.json b/web/messages/es/docs/backup-restore/cross-kernel.json
index ced544ff..9dfe82c4 100644
--- a/web/messages/es/docs/backup-restore/cross-kernel.json
+++ b/web/messages/es/docs/backup-restore/cross-kernel.json
@@ -1,55 +1,102 @@
{
"meta": {
"title": "Restauración cross-kernel — detección de dirección, filtro de subconjunto seguro, hidratación | ProxMenux",
- "description": "Cómo restaura ProxMenux una copia de host sobre un destino con un kernel de versión mayor distinta. Documenta cómo se detecta la dirección del salto, el filtro de subconjunto seguro que salta rutas críticas del arranque cuando el destino corre un kernel más reciente que la copia, y la hidratación independiente del kernel de cuatro fases que reaplica la configuración del usuario como IOMMU, IDs VFIO y tokens custom del cmdline sin copiar verbatim los ficheros ligados al kernel.",
+ "description": "Cómo restaura ProxMenux un backup de host sobre un destino con un kernel de versión mayor distinta. Documenta cómo se detecta la dirección del salto, el filtro de subconjunto seguro que salta rutas críticas del arranque cuando el destino corre un kernel más reciente que el backup, y la hidratación independiente del kernel de cuatro fases que reaplica la configuración del usuario como IOMMU, IDs VFIO y tokens custom del cmdline sin copiar verbatim los ficheros ligados al kernel.",
"ogTitle": "ProxMenux Backup — restauración cross-kernel e hidratación",
"ogDescription": "Restauración cross-kernel direccional con filtro de subconjunto seguro e hidratación independiente del kernel.",
"twitterTitle": "Restauración cross-kernel | ProxMenux",
- "twitterDescription": "Cómo maneja ProxMenux una restauración cuando el kernel del destino difiere del de la copia."
+ "twitterDescription": "Cómo maneja ProxMenux una restauración cuando el kernel del destino difiere del del backup."
},
"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.",
+ "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 del backup — 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"
},
"intro": {
"title": "Cada salto de kernel se maneja de forma distinta",
- "body": "El kernel de un host Proxmox se identifica mediante una versión como 6.17.13-2-pve. Los dos primeros números (6.17 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."
+ "body": "El kernel de un host Proxmox se identifica con una cadena de versión como 6.17.13-2-pve. Los dos primeros números (6.17 en este ejemplo) definen la versión mayor: cuando cambian, algunos ficheros de configuración escritos para el kernel anterior pueden no ser válidos en el nuevo. Cuando la restauración detecta que el backup y el destino tienen versiones mayores de kernel distintas, el flujo se ramifica según la dirección del salto —si el backup es más antiguo o más reciente que el destino— porque los dos casos tienen modos de fallo opuestos. Los backups más recientes que el destino se restauran limpiamente tal cual (verificado en banco de pruebas con varios saltos de kernel). Los backups más antiguos que el destino necesitan un filtro para no romper el arranque del destino con configuración escrita para un kernel que desde entonces ha cambiado."
},
"directionCheck": {
"heading": "La comprobación de dirección",
- "intro": "Durante la comprobación de compatibilidad, hb_compat_check compara el kernel registrado en el manifiesto de la copia contra el kernel actual del destino (uname -r) y clasifica la restauración en uno de tres casos, guardado en la variable interna HB_COMPAT_KERNEL_DIRECTION:",
+ "intro": "Durante la comprobación de compatibilidad, hb_compat_check compara el kernel registrado en el manifiesto del backup contra el kernel actual del destino (uname -r) y clasifica la restauración en uno de tres casos, guardado en la variable interna HB_COMPAT_KERNEL_DIRECTION:",
"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 same. 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 el backup 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 del backup es más RECIENTE que el del destino (por ejemplo: el backup 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 same. 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 del backup es más ANTIGUO que el del destino (por ejemplo: el backup 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": {
- "heading": "Por qué una copia con kernel más reciente que el destino se restaura sin cambios",
- "body": "Cuando la restauración corre contra un destino con un kernel más antiguo que el registrado en la copia, todos los mecanismos de los que depende la restauración son independientes de la versión del kernel. Los instaladores de controladores de GPU y otros dispositivos PCI detectan el kernel en ejecución con uname -r y compilan DKMS contra lo que tenga el destino. La instalación de paquetes por APT trae binarios construidos para la distribución del destino. Los tokens IOMMU del cmdline como intel_iommu=on son estables entre versiones mayores de kernel. La copia lleva rutas escritas bajo un kernel más reciente, pero esas rutas (blacklists de módulos, defaults de GRUB, configuración de initramfs) siguen siendo sintaxis válida en el más antiguo — los kernels ignoran los tokens que no reconocen en lugar de fallar. Este caso es equivalente en la práctica a una restauración con el mismo kernel, y ProxMenux lo trata como tal."
+ "heading": "Por qué un backup con kernel más reciente que el destino se restaura sin cambios",
+ "body": "Cuando la restauración corre contra un destino con un kernel más antiguo que el registrado en el backup, todos los mecanismos de los que depende la restauración son independientes de la versión del kernel. Los instaladores de controladores de GPU y otros dispositivos PCI detectan el kernel en ejecución con uname -r y compilan DKMS contra lo que tenga el destino. La instalación de paquetes por APT trae binarios construidos para la distribución del destino. Los tokens IOMMU del cmdline como intel_iommu=on son estables entre versiones mayores de kernel. El backup lleva rutas escritas bajo un kernel más reciente, pero esas rutas (blacklists de módulos, defaults de GRUB, configuración de initramfs) siguen siendo sintaxis válida en el más antiguo — los kernels ignoran los tokens que no reconocen en lugar de fallar. Este caso es equivalente en la práctica a una restauración con el mismo kernel, y ProxMenux lo trata como tal."
},
"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 hb_unsafe_paths_cross_version a RS_SKIP_PATHS. 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 del backup, la comprobación de compatibilidad añade 16 rutas críticas del arranque de hb_unsafe_paths_cross_version a RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel", "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools", "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs", "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 (zpool.cache + hostid) que puede bloquear el pool como si no perteneciera al host." },
- { "category": "Fuentes APT", "paths": "/etc/apt", "reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización." },
- { "category": "systemd", "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf", "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": "Bootloader",
+ "paths": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) que puede bloquear el pool como si no perteneciera al host."
+ },
+ {
+ "category": "Fuentes APT",
+ "paths": "/etc/apt",
+ "reason": "Las suites de fuentes APT pueden disparar un downgrade de paquetes críticos en la próxima actualización."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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, GRUB_TIMEOUT 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, GRUB_TIMEOUT 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). _rs_hyd_grub mergea cada token de manifest.kernel_params.cmdline_extra de la copia en el GRUB_CMDLINE_LINUX_DEFAULT vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) del /etc/default/grub 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). _rs_hyd_kernel_cmdline mergea los tokens del usuario de cmdline_extra en el /etc/kernel/cmdline del destino, manteniendo intacto el boilerplate propio del destino: root=, boot= y rootflags=." },
- { "phase": "2 — Merge en /etc/modules", "detail": "_rs_hyd_modules añade los módulos de manifest.kernel_params.modules_loaded_at_boot que estén en la whitelist (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) Y que aún no estén presentes en /etc/modules del destino." },
- { "phase": "3 — Copia de ficheros whitelisted", "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo /etc/udev/rules.d. Los ficheros propiedad de la distro (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 se propaga a través de plan.env a apply_pending_restore.sh, que fuerza NEEDS_INITRAMFS=1 y NEEDS_GRUB=1 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). _rs_hyd_grub mergea cada token de manifest.kernel_params.cmdline_extra del backup en el GRUB_CMDLINE_LINUX_DEFAULT vivo del destino, saltando los tokens cuya clave el destino ya lleva. Después mergea claves whitelisted GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) del /etc/default/grub del backup si difieren de las del destino."
+ },
+ {
+ "phase": "1b — Ruta systemd-boot / ZFS",
+ "detail": "Para hosts que usan systemd-boot (típicamente ZFS-on-root). _rs_hyd_kernel_cmdline mergea los tokens del usuario de cmdline_extra en el /etc/kernel/cmdline del destino, manteniendo intacto el boilerplate propio del destino: root=, boot= y rootflags=."
+ },
+ {
+ "phase": "2 — Merge en /etc/modules",
+ "detail": "_rs_hyd_modules añade los módulos de manifest.kernel_params.modules_loaded_at_boot que estén en la whitelist (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) Y que aún no estén presentes en /etc/modules del destino."
+ },
+ {
+ "phase": "3 — Copia de ficheros whitelisted",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d, y la regla VFIO bind + reglas udev de nvidia de ProxMenux bajo /etc/udev/rules.d. Los ficheros propiedad de la distro (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 se propaga a través de plan.env a apply_pending_restore.sh, que fuerza NEEDS_INITRAMFS=1 y NEEDS_GRUB=1 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": {
@@ -57,7 +104,7 @@
"body": "La hidratación corre en dos modos. Antes del diálogo de confirmación, ProxMenux ejecuta _rs_apply_bk_older_hydration en modo plan: calcula exactamente lo que se mergearía, rellena RS_HYDRATION_SUMMARY con un bloque verde que lista cada acción, y retorna sin escribir nada. El diálogo de confirmación muestra ese bloque verde junto a la lista ámbar de rutas saltadas por el subconjunto seguro, para que el usuario vea POR ADELANTADO qué se reaplicará automáticamente. Tras la confirmación del usuario, ProxMenux vuelve a ejecutar el mismo helper en modo commit — mismas fases, misma lógica, pero esta vez cada fase escribe en el destino vivo. Cancelar el diálogo de confirmación deja el destino intacto."
},
"flowDiagram": {
- "heading": "El flujo cuando el kernel del destino es más reciente que el de la copia",
+ "heading": "El flujo cuando el kernel del destino es más reciente que el del backup",
"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 └────────────────────────────────────────────────────────────┘"
},
@@ -65,30 +112,59 @@
"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 intel_iommu=on iommu=pt en el cmdline, vfio/vfio_pci/vfio_iommu_type1 en /etc/modules, un /etc/modprobe.d/vfio.conf con options vfio-pci ids=10de:2216, y un /etc/modprobe.d/blacklist-nvidia.conf. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a /etc/modules, 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 GRUB_TIMEOUT=1 y GRUB_DISABLE_OS_PROBER=true. La hidratación lee ambas claves del /etc/default/grub 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 GRUB_DISTRIBUTOR, intacto)." }
+ {
+ "scenario": "GPU passthrough (VFIO)",
+ "detail": "El origen tenía intel_iommu=on iommu=pt en el cmdline, vfio/vfio_pci/vfio_iommu_type1 en /etc/modules, un /etc/modprobe.d/vfio.conf con options vfio-pci ids=10de:2216, y un /etc/modprobe.d/blacklist-nvidia.conf. La hidratación mergea los tokens del cmdline en el GRUB o kernel cmdline del destino, añade los módulos vfio a /etc/modules, 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 GRUB_TIMEOUT=1 y GRUB_DISABLE_OS_PROBER=true. La hidratación lee ambas claves del /etc/default/grub del backup, 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 GRUB_DISTRIBUTOR, intacto)."
+ }
]
},
"callout": {
"warningTitle": "Qué no reaplica la hidratación cuando el kernel del destino es más reciente",
- "warningBody": "La hidratación reaplica sólo la configuración que ProxMenux sabe que es segura entre versiones del kernel: tokens IOMMU, IDs VFIO, claves whitelisted de GRUB y módulos de una lista fija (vfio*, nvidia*, i915, xe, kvm*). Todo lo que quede fuera de ese conjunto — hooks custom de initramfs bajo /etc/initramfs-tools/hooks/, ficheros no whitelisted bajo /etc/modprobe.d/, overrides de unit de systemd escritos por el usuario — permanece excluido. El motivo es concreto: esos ficheros pueden invocar interfaces internas del kernel (APIs de módulos, layout de /sys, hooks de udev) que cambian entre versiones mayores, y aplicarlos verbatim sobre el kernel más reciente puede impedir que el destino arranque. Cuando se necesita reproducción exacta de la cadena de arranque, la restauración debe correr sobre un host con la misma versión mayor de kernel que la copia."
+ "warningBody": "La hidratación reaplica sólo la configuración que ProxMenux sabe que es segura entre versiones del kernel: tokens IOMMU, IDs VFIO, claves whitelisted de GRUB y módulos de una lista fija (vfio*, nvidia*, i915, xe, kvm*). Todo lo que quede fuera de ese conjunto — hooks custom de initramfs bajo /etc/initramfs-tools/hooks/, ficheros no whitelisted bajo /etc/modprobe.d/, overrides de unit de systemd escritos por el usuario — permanece excluido. El motivo es concreto: esos ficheros pueden invocar interfaces internas del kernel (APIs de módulos, layout de /sys, hooks de udev) que cambian entre versiones mayores, y aplicarlos verbatim sobre el kernel más reciente puede impedir que el destino arranque. Cuando se necesita reproducción exacta de la cadena de arranque, la restauración debe correr sobre un host con la misma versión mayor de kernel que el backup."
},
"codeReference": {
"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": "hb_compat_check en lib_host_backup_common.sh. Fija HB_COMPAT_KERNEL_DIRECTION." },
- { "component": "Lista de rutas del subconjunto seguro", "location": "hb_unsafe_paths_cross_version en lib_host_backup_common.sh. Emite líneas path\\treason usadas tanto por el filtro CLI como por el endpoint Web /api/host-backups/restore/prepare." },
- { "component": "Fases de hidratación", "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files en backup_host.sh. Orquestados por _rs_apply_bk_older_hydration." },
- { "component": "Forzado de reflow post-arranque", "location": "apply_pending_restore.sh lee HB_HYDRATION_APPLIED de plan.env y fuerza NEEDS_INITRAMFS=1/NEEDS_GRUB=1." },
- { "component": "Preview Web", "location": "/api/host-backups/restore/prepare en flask_server.py. Fuentea la librería helper, ejecuta _rs_apply_bk_older_hydration en modo plan, devuelve las acciones al modal Web." }
+ {
+ "component": "Detección de dirección",
+ "location": "hb_compat_check en lib_host_backup_common.sh. Fija HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Lista de rutas del subconjunto seguro",
+ "location": "hb_unsafe_paths_cross_version en lib_host_backup_common.sh. Emite líneas path\\treason usadas tanto por el filtro CLI como por el endpoint Web /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Fases de hidratación",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files en backup_host.sh. Orquestados por _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Forzado de reflow post-arranque",
+ "location": "apply_pending_restore.sh lee HB_HYDRATION_APPLIED de plan.env y fuerza NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Preview Web",
+ "location": "/api/host-backups/restore/prepare en flask_server.py. Fuentea la librería helper, ejecuta _rs_apply_bk_older_hydration 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 kernel_params 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 kernel_params del que lee la hidratación."
+ }
]
}
}
diff --git a/web/messages/es/docs/backup-restore/destinations/borg.json b/web/messages/es/docs/backup-restore/destinations/borg.json
index 860788e8..317e8387 100644
--- a/web/messages/es/docs/backup-restore/destinations/borg.json
+++ b/web/messages/es/docs/backup-restore/destinations/borg.json
@@ -1,28 +1,28 @@
{
"meta": {
"title": "Destino Borg — tipos de repositorio, autenticación SSH, cifrado | ProxMenux",
- "description": "El destino Borg escribe las copias de host de ProxMenux en un repositorio Borg — local, en un disco externo montado, o en un servidor remoto accedido por SSH. Cubre la cadena de resolución del binario borg, las cuatro estrategias de clave SSH, el cifrado repokey, la configuración de destinos guardados y la retención por trabajo programado.",
+ "description": "El destino Borg escribe los backups de host de ProxMenux en un repositorio Borg — local, en un disco externo montado, o en un servidor remoto accedido por SSH. Cubre la cadena de resolución del binario borg, las cuatro estrategias de clave SSH, el cifrado repokey, la configuración de destinos guardados y la retención por trabajo programado.",
"ogTitle": "ProxMenux Backup — destino Borg",
- "ogDescription": "Cómo escribe ProxMenux las copias de host en repositorios Borg, con estrategias de autenticación SSH y cifrado repokey.",
- "twitterTitle": "Destino Borg de copia | ProxMenux",
- "twitterDescription": "Repositorios Borg local, USB y servidos por SSH para copias del host."
+ "ogDescription": "Cómo escribe ProxMenux los backups de host en repositorios Borg, con estrategias de autenticación SSH y cifrado repokey.",
+ "twitterTitle": "Destino Borg de backup | ProxMenux",
+ "twitterDescription": "Repositorios Borg local, USB y servidos por SSH para backups del host."
},
"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.",
+ "description": "El destino Borg escribe los backups 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"
},
"aboutBorg": {
"heading": "Qué es Borg",
- "body": "Borg (también escrito BorgBackup) es una herramienta de copia de seguridad open-source con deduplicación, mantenida por la comunidad Borg Backup. Almacena cada archivo como un conjunto de chunks de longitud variable dentro de un repositorio; los chunks se comparten entre archivos, por lo que volver a copiar datos que no han cambiado tiene un coste de almacenamiento prácticamente nulo. Borg no está atado a Proxmox — es una herramienta de copia de uso general utilizada en muchos entornos. ProxMenux la usa como uno de los tres destinos para copias del host; cada mecanismo específico de Borg descrito en esta página (tipos de repositorio, borg-serve por SSH, cifrado repokey, prune) es comportamiento estándar de Borg."
+ "body": "Borg (también escrito BorgBackup) es una herramienta de backup open-source con deduplicación, mantenida por la comunidad Borg Backup. Almacena cada archivo como un conjunto de chunks de longitud variable dentro de un repositorio; los chunks se comparten entre archivos, por lo que volver a copiar datos que no han cambiado tiene un coste de almacenamiento prácticamente nulo. Borg no está atado a Proxmox — es una herramienta de backup de uso general utilizada en muchos entornos. ProxMenux la usa como uno de los tres destinos para backups del host; cada mecanismo específico de Borg descrito en esta página (tipos de repositorio, borg-serve por SSH, cifrado repokey, prune) es comportamiento estándar de Borg."
},
"intro": {
"title": "Deduplicación por chunks con repositorios locales o servidos por SSH",
- "body": "Un repositorio Borg almacena chunks que se comparten entre cada archivo que contiene, por lo que volver a copiar un fichero que no ha cambiado no transfiere ni almacena nada nuevo. ProxMenux invoca borg create contra el repositorio en el momento de la copia y borg extract en la restauración. El repositorio puede vivir en el mismo sistema de ficheros que el origen, en un disco externo montado, o en un host remoto accedido por SSH."
+ "body": "Un repositorio Borg almacena chunks que se comparten entre cada archivo que contiene, por lo que volver a copiar un fichero que no ha cambiado no transfiere ni almacena nada nuevo. ProxMenux invoca borg create contra el repositorio en el momento del backup y borg extract en la restauración. El repositorio puede vivir en el mismo sistema de ficheros que el origen, en un disco externo montado, o en un host remoto accedido por SSH."
},
"binarySourcing": {
"heading": "El binario borg",
- "intro": "Borg no es una dependencia base del instalador de ProxMenux. Cuando se ejecuta una copia, hb_ensure_borg resuelve el binario desde cuatro fuentes por orden y devuelve la primera que funciona:",
+ "intro": "Borg no es una dependencia base del instalador de ProxMenux. Cuando se ejecuta un backup, hb_ensure_borg resuelve el binario desde cuatro fuentes por orden y devuelve la primera que funciona:",
"rows": [
{
"priority": "1",
@@ -42,7 +42,7 @@
{
"priority": "4",
"source": "Descarga desde GitHub",
- "detail": "wget contra la URL fijada de borg-linux64 bajo github.com/borgbackup/borg/releases/, verificado contra un SHA-256 constante en lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). Si el checksum no coincide, el binario se descarta y la copia se aborta. El fichero descargado se cachea en el state-dir para que las copias posteriores usen el camino 2."
+ "detail": "wget contra la URL fijada de borg-linux64 bajo github.com/borgbackup/borg/releases/, verificado contra un SHA-256 constante en lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). Si el checksum no coincide, el binario se descarta y el backup se aborta. El fichero descargado se cachea en el state-dir para que los backups posteriores usen el camino 2."
}
]
},
@@ -74,11 +74,11 @@
"hostChoicesBody": "Cualquier host Linux con acceso SSH cumple. Setups habituales:",
"hostChoicesItems": [
"Un NAS dedicado o caja de backup (Debian, Ubuntu, TrueNAS SCALE con shell).",
- "Un contenedor LXC dentro de un nodo Proxmox. Huella pequeña, aislado del host que ejecuta las copias.",
+ "Un contenedor LXC dentro de un nodo Proxmox. Huella pequeña, aislado del host que ejecuta los backups.",
"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 generate-auto 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 borg serve sobre esa ruta."
+ "minimalSetupNote": "Con el servidor preparado y la autenticación SSH por contraseña disponible, generate-auto instala la clave mediante una cuenta que pueda escribir en authorized_keys del usuario borg. Los backups posteriores usan esa clave, restringida a borg serve 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 borg serve. Ese usuario se llama típicamente borg, 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, el puerto 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 ~/.ssh/borg_proxmenux_HOST_ed25519, y a continuación usa sshpass para hacer login UNA VEZ en el servidor con la contraseña de admin y añadir la clave pública a ~borg/.ssh/authorized_keys. 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 ~/.ssh/borg_proxmenux_HOST_ed25519 y usa sshpass para probar el acceso e instalar la clave pública en ~borg/.ssh/authorized_keys. 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 (chmod 600). 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 hb_borg_init_if_needed: borg repo-create -e MODE en versiones modernas, o el legacy borg init --encryption=MODE. ProxMenux expone dos modos: repokey (por defecto) y none. En modo repokey, 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 borg-pass-NAME.txt. 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 hb_borg_init_if_needed: borg repo-create -e MODE en versiones modernas, o el legacy borg init --encryption=MODE. ProxMenux expone dos modos: repokey (por defecto) y none. En modo repokey, 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 borg-pass-NAME.txt 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. Al añadir un destino con un puerto distinto del predeterminado, ProxMenux añade además -p PORT; los destinos guardados, los trabajos programados y el Monitor usan el puerto de la URL ssh://. Sin clave personalizada, y en un destino nuevo con el puerto predeterminado, la variable queda sin definir y Borg usa la configuración SSH del host."
},
{
"var": "BORG_PASSPHRASE",
@@ -192,9 +192,9 @@
},
"archiveFormat": {
"heading": "Nombrado de archivos y retención",
- "intro": "Cada copia crea un archivo nuevo dentro del repositorio.",
+ "intro": "Cada backup crea un archivo nuevo dentro del repositorio.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
- "retentionBody": "Para trabajos programados, run_scheduled_backup.sh ejecuta borg prune contra el repositorio tras cada copia exitosa con los valores de retención configurados en el trabajo (--keep-last, --keep-daily, --keep-weekly). Las copias interactivas no aplican poda."
+ "retentionBody": "Para trabajos programados, run_scheduled_backup.sh ejecuta borg prune contra el repositorio tras cada backup exitoso con los valores de retención configurados en el trabajo (--keep-last, --keep-daily, --keep-weekly). Los backups interactivos no aplican poda."
},
"restoreAccess": {
"heading": "Recuperación del lado de la restauración",
@@ -212,7 +212,7 @@
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
- "tail": " — el comando que ProxMenux invoca en cada copia, con todas las flags soportadas."
+ "tail": " — el comando que ProxMenux invoca en cada backup, con todas las flags soportadas."
},
{
"label": "Cifrado del repositorio",
diff --git a/web/messages/es/docs/backup-restore/destinations/index.json b/web/messages/es/docs/backup-restore/destinations/index.json
index efb1e349..1f6eca83 100644
--- a/web/messages/es/docs/backup-restore/destinations/index.json
+++ b/web/messages/es/docs/backup-restore/destinations/index.json
@@ -1,11 +1,11 @@
{
"meta": {
- "title": "Destinos de copia — Local, Proxmox Backup Server, Borg | ProxMenux",
- "description": "Tres backends de almacenamiento reciben el mismo contenido de una copia de ProxMenux: un archivo local .tar.zst en cualquier sistema de ficheros escribible, un backup en un datastore de Proxmox Backup Server o un archivo en un repositorio local o remoto de Borg. Cada backend tiene sus propias características de compresión, deduplicación, cifrado y red.",
+ "title": "Destinos de backup — Local, Proxmox Backup Server, Borg | ProxMenux",
+ "description": "Tres backends de almacenamiento reciben el mismo contenido de un backup de ProxMenux: un archivo local .tar.zst en cualquier sistema de ficheros escribible, un backup en un datastore de Proxmox Backup Server o un archivo en un repositorio local o remoto de Borg. Cada backend tiene sus propias características de compresión, deduplicación, cifrado y red.",
"ogTitle": "Destinos de ProxMenux Backup",
- "ogDescription": "Local, Proxmox Backup Server y Borg — tres backends de almacenamiento para el mismo contenido de copia del host.",
+ "ogDescription": "Local, Proxmox Backup Server y Borg — tres backends de almacenamiento para el mismo contenido de backup del host.",
"twitterTitle": "Destinos de ProxMenux Backup | ProxMenux",
- "twitterDescription": "Archivo local, Proxmox Backup Server y Borg como backends para copias del host."
+ "twitterDescription": "Archivo local, Proxmox Backup Server y Borg como backends para backups del host."
},
"header": {
"title": "Destinos",
@@ -14,7 +14,7 @@
},
"intro": {
"title": "El mismo contenido, tres backends",
- "body": "Cada copia produce los mismos tres bloques (rootfs, manifiesto, aplicaciones). Lo que cambia entre destinos es cómo se almacenan esos bloques y cómo el usuario los recupera para una restauración. Cada backend está implementado como una función independiente en backup_host.sh — _bk_local, _bk_pbs, _bk_borg — pero los tres comparten el mismo paso de staging (hb_prepare_staging) y el mismo camino de restauración. La elección del destino sólo afecta a la escritura y la recuperación; no cambia lo que hace una restauración ni cómo consume el archivo."
+ "body": "Cada backup produce los mismos tres bloques (rootfs, manifiesto, aplicaciones). Lo que cambia entre destinos es cómo se almacenan esos bloques y cómo el usuario los recupera para una restauración. Cada backend está implementado como una función independiente en backup_host.sh — _bk_local, _bk_pbs, _bk_borg — pero los tres comparten el mismo paso de staging (hb_prepare_staging) y el mismo camino de restauración. La elección del destino sólo afecta a la escritura y la recuperación; no cambia lo que hace una restauración ni cómo consume el archivo."
},
"comparison": {
"heading": "Comparativa de características",
@@ -29,12 +29,12 @@
{
"feature": "Compresión",
"local": "zstd (nivel por defecto) mediante tar --zstd. 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",
- "local": "Ninguna. Cada copia es un archivo completo independiente.",
+ "local": "Ninguna. Cada backup es un archivo completo independiente.",
"pbs": "Deduplicación completa a nivel de chunk entre todas las backups del datastore.",
"borg": "Deduplicación completa a nivel de chunk entre todos los archivos del repositorio."
},
@@ -46,9 +46,9 @@
},
{
"feature": "Retención / poda",
- "local": "Aplicada por trabajo programado vía KEEP_LAST. Los archivos antiguos (y sus sidecars + logs del runner) se eliminan de forma simétrica. Las copias interactivas no aplican poda.",
- "pbs": "Aplicada por trabajo programado vía proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Las copias interactivas no aplican poda.",
- "borg": "Aplicada por trabajo programado vía borg prune --keep-last / --keep-daily / --keep-weekly. Las copias interactivas no aplican poda."
+ "local": "Aplicada por trabajo programado vía KEEP_LAST. Los archivos antiguos (y sus sidecars + logs del runner) se eliminan de forma simétrica. Los backups interactivos no aplican poda.",
+ "pbs": "Aplicada por trabajo programado vía proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Los backups interactivos no aplican poda.",
+ "borg": "Aplicada por trabajo programado vía borg prune --keep-last / --keep-daily / --keep-weekly. Los backups interactivos no aplican poda."
},
{
"feature": "Red",
@@ -75,11 +75,11 @@
"captionBorg": "Borg"
},
"sameArchive": {
- "heading": "El contenido interno de la copia es el mismo en cualquier destino",
+ "heading": "El contenido interno del backup es el mismo en cualquier destino",
"body": "Los tres destinos contienen la misma estructura rootfs/ + metadata/ + manifest.json descrita en Cómo funciona. Extraer un .tar.zst de un archivo local, restaurar un .pxar desde PBS o extraer un archivo de Borg con borg extract produce el mismo árbol de directorios. El proceso de restauración (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lee los mismos tres componentes sin necesitar saber de qué destino proceden."
},
"extractStandalone": {
- "heading": "Extraer una copia fuera de ProxMenux",
+ "heading": "Extraer un backup 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.",
diff --git a/web/messages/es/docs/backup-restore/destinations/local.json b/web/messages/es/docs/backup-restore/destinations/local.json
index e99f5190..79d75136 100644
--- a/web/messages/es/docs/backup-restore/destinations/local.json
+++ b/web/messages/es/docs/backup-restore/destinations/local.json
@@ -1,11 +1,11 @@
{
"meta": {
"title": "Destino de archivo local — tar.zst en filesystem o unidad USB | ProxMenux",
- "description": "El destino local de la copia escribe un único archivo .tar.zst en cualquier directorio escribible: un disco interno, un punto de montaje de Proxmox, un share NFS o una unidad USB. Documenta el flujo de configuración, la lógica de detección y montaje USB, el chequeo de seguridad contra escribir el archivo dentro de una ruta que se está copiando, y el sidecar JSON que identifica el fichero.",
+ "description": "El destino local del backup escribe un único archivo .tar.zst en cualquier directorio escribible: un disco interno, un punto de montaje de Proxmox, un share NFS o una unidad USB. Documenta el flujo de configuración, la lógica de detección y montaje USB, el chequeo de seguridad contra escribir el archivo dentro de una ruta que se está copiando, y el sidecar JSON que identifica el fichero.",
"ogTitle": "ProxMenux Backup — Destino local",
- "ogDescription": "Cómo escribe ProxMenux las copias locales como archivos .tar.zst y cómo configurar el directorio de destino o la unidad USB.",
- "twitterTitle": "Destino local de copia | ProxMenux",
- "twitterDescription": "Cómo escribe ProxMenux las copias locales como archivos .tar.zst en filesystem o USB."
+ "ogDescription": "Cómo escribe ProxMenux los backups locales como archivos .tar.zst y cómo configurar el directorio de destino o la unidad USB.",
+ "twitterTitle": "Destino local de backup | ProxMenux",
+ "twitterDescription": "Cómo escribe ProxMenux los backups locales como archivos .tar.zst en filesystem o USB."
},
"header": {
"title": "Archivo local",
@@ -14,11 +14,11 @@
},
"intro": {
"title": "Un solo fichero, autocontenido",
- "body": "Una copia local produce un único fichero hostcfg-HOST-TIMESTAMP.tar.zst (o .tar.gz cuando zstd no está presente). El fichero contiene el árbol completo del archivo — manifest.json, metadata/ y rootfs/ — y puede restaurarse en cualquier host Proxmox con el flujo de restauración de ProxMenux, o extraerse a mano con tar --zstd -xf en cualquier sistema Linux. Sin servidor, sin inicialización de repositorio, sin dependencia externa. Es el destino con el camino de recuperación más corto cuando ni PBS ni Borg están disponibles."
+ "body": "Un backup local produce un único fichero hostcfg-HOST-TIMESTAMP.tar.zst (o .tar.gz cuando zstd no está presente). El fichero contiene el árbol completo del archivo — manifest.json, metadata/ y rootfs/ — y puede restaurarse en cualquier host Proxmox con el flujo de restauración de ProxMenux, o extraerse a mano con tar --zstd -xf en cualquier sistema Linux. Sin servidor, sin inicialización de repositorio, sin dependencia externa. Es el destino con el camino de recuperación más corto cuando ni PBS ni Borg están disponibles."
},
"targetConfig": {
"heading": "Configurar el directorio de destino",
- "intro": "El destino local es un único directorio de destino persistido — no una lista. ProxMenux guarda la elección del usuario en /usr/local/share/proxmenux/local-target.conf y la lee en cada copia. Cuando no hay ningún destino configurado, se usa el valor por defecto HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump (el mismo directorio que Proxmox utiliza para las salidas de vzdump). El destino se configura desde Configure backup destinations → Local destinations:",
+ "intro": "El destino local es un único directorio de destino persistido — no una lista. ProxMenux guarda la elección del usuario en /usr/local/share/proxmenux/local-target.conf y la lee en cada backup. Cuando no hay ningún destino configurado, se usa el valor por defecto HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump (el mismo directorio que Proxmox utiliza para las salidas de vzdump). El destino se configura desde Configure backup destinations → Local destinations:",
"options": [
"Usar el valor por defecto (/var/lib/vz/dump). El almacenamiento local de Proxmox. Está presente en cualquier instalación de Proxmox; el archivo queda junto a las salidas de vzdump y lo detecta automáticamente la pestaña Backups del Monitor.",
"Introducir una ruta personalizada. Cualquier ruta absoluta del sistema de ficheros vale: un montaje NFS, un share SMB montado por fstab, un dataset ZFS dedicado, un segundo disco interno. ProxMenux valida que la ruta existe y es un directorio antes de persistirla.",
@@ -32,7 +32,7 @@
"stateRows": [
{
"state": "mounted",
- "shown": "Tamaño · label · [fstype] · → /punto/de/montaje",
+ "shown": "Tamaño · label · [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."
},
{
@@ -50,11 +50,11 @@
},
"safetyCheck": {
"heading": "Chequeo de seguridad — destino dentro de una ruta copiada",
- "body": "Antes de escribir el archivo, _bk_local verifica que el directorio de destino no sea un subcamino de ninguno de los directorios que se están copiando. Un footgun habitual sería añadir /root al perfil y elegir /root/backups 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 readlink -m, 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, _bk_local verifica que el directorio de destino no sea un subcamino de ninguno de los directorios que se están copiando. Un footgun habitual sería añadir /root al perfil y elegir /root/backups 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 readlink -m, los compara y, si hay conflicto, aborta el backup 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",
- "intro": "El nombre del fichero de salida incorpora el hostname del origen y el timestamp de la copia para que un directorio con varios archivos se ordene cronológicamente y cada fichero se identifique por sí mismo.",
+ "intro": "El nombre del fichero de salida incorpora el hostname del origen y el timestamp del backup para que un directorio con varios archivos se ordene cronológicamente y cada fichero se identifique por sí mismo.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Compresión",
"compressionBody": "El camino principal usa tar --zstd -cf — un pipeline de un solo comando que comprime al nivel por defecto de zstd. Cuando zstd no está presente en el origen (raro en Proxmox pero posible en instalaciones minimalistas), ProxMenux cae en gzip. En el camino de fallback, si pv está disponible, se añade una barra de progreso al pipeline para que el usuario vea crecer el tamaño del archivo en tiempo real; sin pv, se usa tar -czf plano en silencio.",
@@ -63,13 +63,13 @@
},
"sidecar": {
"heading": "El sidecar JSON",
- "intro": "Cada copia local con éxito produce un fichero compañero: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, escrito junto al archivo por hb_write_archive_sidecar. Este pequeño fichero JSON permite al Monitor de ProxMenux identificar el archivo como una copia de host de ProxMenux incluso si posteriormente se mueve, renombra o archiva en otro lugar.",
+ "intro": "Cada backup local con éxito produce un fichero compañero: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, escrito junto al archivo por hb_write_archive_sidecar. Este pequeño fichero JSON permite al Monitor de ProxMenux identificar el archivo como un backup de host de ProxMenux incluso si posteriormente se mueve, renombra o archiva en otro lugar.",
"contentTitle": "Contenido del sidecar",
- "contentBody": "El sidecar almacena la versión de schema, si la copia viene de una ejecución interactiva o de un trabajo programado (kind), el ID de trabajo para las ejecuciones programadas, el modo de perfil usado (default o custom), el hostname del origen, el basename original del archivo, un timestamp de creación en ISO-8601 y el tamaño del archivo en bytes.",
- "whyBody": "La pestaña Backups del Monitor escanea los directorios locales configurados buscando sidecars *.proxmenux.json — no ficheros *.tar.zst — porque un .tar.zst sin sidecar podría no ser una copia de ProxMenux en absoluto. El escaneo es rápido (los JSON son diminutos) y el emparejamiento es estable frente a renombrados del archivo mientras el sidecar se renombre en paralelo."
+ "contentBody": "El sidecar almacena la versión de schema, si el backup viene de una ejecución interactiva o de un trabajo programado (kind), el ID de trabajo para las ejecuciones programadas, el modo de perfil usado (default o custom), el hostname del origen, el basename original del archivo, un timestamp de creación en ISO-8601 y el tamaño del archivo en bytes.",
+ "whyBody": "La pestaña Backups del Monitor escanea los directorios locales configurados buscando sidecars *.proxmenux.json — no ficheros *.tar.zst — porque un .tar.zst sin sidecar podría no ser un backup de ProxMenux en absoluto. El escaneo es rápido (los JSON son diminutos) y el emparejamiento es estable frente a renombrados del archivo mientras el sidecar se renombre en paralelo."
},
"restoreAccess": {
"heading": "Restaurar desde un archivo local",
- "body": "El flujo de restauración de ProxMenux descubre los archivos locales escaneando el destino local configurado buscando sidecars y mostrándolos en la lista de copias disponibles. Seleccionar uno dispara _rs_check_layout, que extrae el tarball en un directorio de staging y confirma el layout de tres bloques antes de continuar. Para una extracción manual fuera de ProxMenux, tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg produce el mismo árbol que consume el código de restauración."
+ "body": "El flujo de restauración de ProxMenux descubre los archivos locales escaneando el destino local configurado buscando sidecars y mostrándolos en la lista de backups disponibles. Seleccionar uno dispara _rs_check_layout, que extrae el tarball en un directorio de staging y confirma el layout de tres bloques antes de continuar. Para una extracción manual fuera de ProxMenux, tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg produce el mismo árbol que consume el código de restauración."
}
}
diff --git a/web/messages/es/docs/backup-restore/destinations/pbs.json b/web/messages/es/docs/backup-restore/destinations/pbs.json
index 354ad987..d92ff2ef 100644
--- a/web/messages/es/docs/backup-restore/destinations/pbs.json
+++ b/web/messages/es/docs/backup-restore/destinations/pbs.json
@@ -1,10 +1,10 @@
{
"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 escribe los backups 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.",
"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",
+ "ogDescription": "Cómo escribe ProxMenux los backups de host en Proxmox Backup Server con cifrado por keyfile del lado del cliente y escrow de recuperación.",
+ "twitterTitle": "Destino PBS de backup | ProxMenux",
"twitterDescription": "Destino Proxmox Backup Server con cifrado por keyfile y escrow de passphrase de recuperación."
},
"header": {
@@ -15,15 +15,15 @@
"recommendedBadge": "Destino recomendado",
"aboutPbs": {
"heading": "Qué es Proxmox Backup Server",
- "body": "Proxmox Backup Server (PBS) es el producto de servidor de copias propio de Proxmox, desarrollado y mantenido por el mismo equipo que autora Proxmox VE. Es un servidor dedicado diseñado para recibir copias desde hosts Proxmox VE (VMs, LXCs y — vía proxmox-backup-client — directorios arbitrarios del host) con deduplicación a nivel de chunk, cifrado del lado del cliente y políticas de retención aplicadas del lado del servidor. ProxMenux usa PBS como uno de los tres destinos para copias del host; cada mecanismo específico de PBS descrito en esta página (grupos de copia, archivos .pxar, --backup-id, cifrado por keyfile) es comportamiento estándar de PBS."
+ "body": "Proxmox Backup Server (PBS) es el producto de servidor de backups propio de Proxmox, desarrollado y mantenido por el mismo equipo que autora Proxmox VE. Es un servidor dedicado diseñado para recibir backups desde hosts Proxmox VE (VMs, LXCs y — vía proxmox-backup-client — directorios arbitrarios del host) con deduplicación a nivel de chunk, cifrado del lado del cliente y políticas de retención aplicadas del lado del servidor. ProxMenux usa PBS como uno de los tres destinos para backups del host; cada mecanismo específico de PBS descrito en esta página (grupos de backup, archivos .pxar, --backup-id, cifrado por keyfile) es comportamiento estándar de PBS."
},
"intro": {
"title": "Un backup por ejecución, deduplicación a nivel de chunk",
- "body": "Una copia PBS produce una única entrada en el datastore, agrupada bajo el backup ID host/hostcfg-HOSTNAME/BACKUP-TIME. El contenido es un archivo .pxar con el mismo layout de tres bloques descrito en Cómo funciona. PBS deduplica a nivel de chunk en todas las copias del datastore, por lo que las copias siguientes del mismo host transfieren y almacenan sólo los chunks que hayan cambiado. La retención la aplica el propio ProxMenux para los trabajos programados — run_scheduled_backup.sh ejecuta proxmox-backup-client prune con --keep-last / --keep-daily / --keep-weekly tras cada ejecución exitosa usando los valores configurados en el trabajo."
+ "body": "Un backup PBS produce una única entrada en el datastore, agrupada bajo el backup ID host/hostcfg-HOSTNAME/BACKUP-TIME. El contenido es un archivo .pxar con el mismo layout de tres bloques descrito en Cómo funciona. PBS deduplica a nivel de chunk en todos los backups del datastore, por lo que los backups siguientes del mismo host transfieren y almacenan sólo los chunks que hayan cambiado. La retención la aplica el propio ProxMenux para los trabajos programados — run_scheduled_backup.sh ejecuta proxmox-backup-client prune con --keep-last / --keep-daily / --keep-weekly tras cada ejecución exitosa usando los valores configurados en el trabajo."
},
"repoSelection": {
"heading": "Selección del repositorio",
- "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 HB_PBS_REPOSITORY, HB_PBS_SECRET y HB_PBS_FINGERPRINT para esa ejecución.",
+ "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; esa elección determina los valores de HB_PBS_REPOSITORY, HB_PBS_SECRET y HB_PBS_FINGERPRINT para esa ejecución.",
"sourceRows": [
{
"source": "storage.cfg de Proxmox (auto-descubierto)",
@@ -33,51 +33,51 @@
{
"source": "Configuración manual de ProxMenux",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
- "content": "Se añade desde Configure backup destinations → PBS destinations → Add PBS. Pregunta por un nombre, usuario (root@pam o user@pbs!token), host o IP, datastore y contraseña. La contraseña se re-pregunta ante entrada vacía — un guardado vacío persistiría silenciosamente y cada copia posterior fallaría con un error de autenticación opaco. Este camino se usa cuando el PBS objetivo no está registrado como storage de Proxmox."
+ "content": "Se añade desde Configure backup destinations → PBS destinations → Add PBS. Pregunta por un nombre, usuario (root@pam o user@pbs!token), host o IP, datastore y contraseña. La contraseña se re-pregunta ante entrada vacía — un guardado vacío persistiría silenciosamente y cada backup posterior fallaría con un error de autenticación opaco. Este camino se usa cuando el PBS objetivo no está registrado como storage de Proxmox."
}
],
"menuTitle": "Menú de selección",
- "menuBody": "Ambas fuentes se muestran en un único menú, cada fila etiquetada con su origen ([proxmox] o [manual]). Las entradas cuya contraseña no se pudo resolver se marcan con un aviso ⚠ no password — seleccionarlas dispara una re-introducción de contraseña antes de iniciar la copia. El fingerprint se pasa a proxmox-backup-client vía la variable de entorno PBS_FINGERPRINT; cuando no está presente, el cliente pide al usuario aceptar el certificado del servidor de forma interactiva en la primera copia."
+ "menuBody": "Ambas fuentes se muestran en un único menú, cada fila etiquetada con su origen ([proxmox] o [manual]). Las entradas cuya contraseña no se pudo resolver se marcan con un aviso ⚠ no password — seleccionarlas dispara una re-introducción de contraseña antes de iniciar el backup. El fingerprint se pasa a proxmox-backup-client vía la variable de entorno PBS_FINGERPRINT; cuando no está presente, el cliente pide al usuario aceptar el certificado del servidor de forma interactiva en el primer backup."
},
"backupCommand": {
- "heading": "El comando de copia",
- "intro": "La subida es una única invocación de proxmox-backup-client backup. ProxMenux la ejecuta dentro de un envoltorio env para que las credenciales nunca aparezcan en la lista de argumentos del proceso.",
+ "heading": "El comando de backup",
+ "intro": "La subida se realiza con una única invocación de proxmox-backup-client backup. ProxMenux utiliza env 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 hostcfg-HOSTNAME. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de [A-Za-z0-9_-] se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un grupo, y cada copia posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
+ "backupIdBody": "El backup ID por defecto es hostcfg-HOSTNAME. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de [A-Za-z0-9_-] se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un grupo, y cada backup posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
"pxarTitle": "Qué se incluye dentro del archivo .pxar",
- "pxarBody": "El origen del .pxar es todo el directorio staging_root, con rootfs/, metadata/ y manifest.json juntos. Las versiones anteriores utilizaban $staging_root/rootfs como origen; esto dejaba metadata/ fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Las copias antiguas creadas solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de _rs_check_layout, que vuelve a colocar el árbol plano etc/var/root/usr dentro de una estructura rootfs/."
+ "pxarBody": "El origen del .pxar es todo el directorio staging_root, con rootfs/, metadata/ y manifest.json juntos. Las versiones anteriores utilizaban $staging_root/rootfs como origen; esto dejaba metadata/ fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Los backups antiguos creados solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de _rs_check_layout, que vuelve a colocar el árbol plano etc/var/root/usr dentro de una estructura rootfs/."
},
"encryption": {
"heading": "Cifrado del lado del cliente",
"glossaryHint": "En esta sección aparecen los términos clave, passphrase y sobre de recuperación. El glosario resume las diferencias en una frase por término.",
- "intro": "PBS puede cifrar las copias con una clave que vive solo en el host. Los datos se cifran en el host antes de subirse; en PBS llegan ya cifrados. En ProxMenux este cifrado es opcional. Al activarlo, el usuario decide aparte, con una pregunta sí/no, si quiere subir a PBS también una copia de esa clave envuelta con una passphrase (el sobre de recuperación) como red de seguridad. La respuesta se puede cambiar después desde el Monitor. La clave siempre queda en una única ruta del host — /usr/local/share/proxmenux/pbs-key.conf — y se reutiliza sin volver a preguntar en las copias siguientes.",
+ "intro": "PBS puede cifrar los backups con una clave que vive solo en el host. Los datos se cifran en el host antes de subirse; en PBS llegan ya cifrados. En ProxMenux este cifrado es opcional. Al activarlo, el usuario decide aparte, con una pregunta sí/no, si quiere subir a PBS también una copia de esa clave envuelta con una passphrase (el sobre de recuperación) como red de seguridad. La respuesta se puede cambiar después desde el Monitor. La clave siempre queda en una única ruta del host — /usr/local/share/proxmenux/pbs-key.conf — y se reutiliza sin volver a preguntar en los backups siguientes.",
"keyfileTitle": "Configuración inicial de la clave",
- "keyfileBody": "El diálogo aparece en la primera copia cifrada del host y hace dos preguntas. Primero, si se quiere cifrar la copia: No sigue sin cifrado; Sí pasa al segundo paso. Segundo, qué clave usar. Si ya hay una instalada en /usr/local/share/proxmenux/pbs-key.conf, se reutiliza sin preguntar más y las copias posteriores tampoco vuelven a preguntar. Si no la hay, aparecen dos opciones: Generar una clave nueva crea una con proxmox-backup-client key create --kdf none. Usar una clave existente busca primero una gestionada por PVE: si el repositorio PBS elegido tiene una en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia solo a la ruta canónica. Si no hay ninguna que coincida, el diálogo pide la ruta absoluta donde el usuario ha dejado la clave en este host. En cualquier caso, el fichero termina en la ruta canónica con chmod 600.",
+ "keyfileBody": "El diálogo aparece en el primer backup cifrado del host y hace dos preguntas. Primero, si se quiere cifrar el backup: No sigue sin cifrado; Sí pasa al segundo paso. Segundo, qué clave usar. Si ya hay una instalada en /usr/local/share/proxmenux/pbs-key.conf, se reutiliza sin preguntar más y los backups posteriores tampoco vuelven a preguntar. Si no la hay, aparecen dos opciones: Generar una clave nueva crea una con proxmox-backup-client key create --kdf none. Usar una clave existente busca primero una gestionada por PVE: si el repositorio PBS elegido tiene una en /etc/pve/priv/storage/<NAME>.enc, ese fichero se copia solo a la ruta canónica. Si no hay ninguna que coincida, el diálogo pide la ruta absoluta donde el usuario ha dejado la clave en este host. En cualquier caso, el fichero termina en la ruta canónica con chmod 600.",
"modesTitle": "Clave por host o compartida",
"modesIntro": "Los dos modos están soportados y ninguno se impone — el usuario elige según cómo tenga organizados sus hosts.",
"modesPerHostTitle": "Clave por host (por defecto)",
- "modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
+ "modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a los backups de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
"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 Usar una clave existente. 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.",
+ "modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción Usar una clave existente. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer los backups 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 hace una única pregunta explícita — ¿Subir clave a PBS? — con dos respuestas. No se sube nada a PBS hasta que el usuario responde Sí. La opción por defecto es No, mantener solo local: la clave se queda solo en su ruta local, ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, el botón Descargar archivo clave de la fila del destino PBS la exporta en el acto). Al elegir Sí, subir se pide una passphrase de recuperación —dos veces, para comprobar que coincidan— y ProxMenux envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) en un fichero pbs-key.recovery.enc. A partir de ese momento, cada backup cifrado sube también ese fichero envuelto a PBS como un grupo de backup asociado. 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 de la fila del destino PBS cambia entre Sí y No y se aplica al momento (empezar a subir, dejar de subir o cambiar la passphrase, según el estado).",
+ "recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta ¿Subir clave a PBS?, con dos respuestas. No se sube ningún artefacto de recuperación a PBS hasta que el usuario responde Sí. Por defecto se elige No, mantener solo local: 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 Descargar archivo clave del Monitor, en la fila del destino PBS, permite obtenerla cuando se necesite. Al elegir Sí, subir, 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 pbs-key.recovery.enc. Cada backup cifrado posterior sube esa envoltura a PBS como un grupo de backup 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 la custodia está configurada como Sí, subir, 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 -keyrecovery. 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. El archivo de recuperación nunca sale del host en texto plano: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar ningún dato (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS solo recibe el archivo ya cifrado.",
+ "blobUploadBody1": "Cuando la respuesta es Sí, subir, ProxMenux sube el sobre de recuperación a PBS después de cada backup cifrado como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en -keyrecovery. Los dos grupos aparecen juntos en el listado del datastore: uno con los backups del host, otro con los sobres de recuperación. El sobre nunca sale del host en claro: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar un solo byte (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS solo recibe el sobre 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 proxmox-backup-client backup 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 proxmox-backup-client backup cifra todos sus archivos con la misma clave o no cifra ninguno; no permite mezclar ambos casos. El backup 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 el backup 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.",
+ "blobUploadImageCaption": "Interfaz de PBS — los grupos de backup emparejados. El grupo principal contiene los backups 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 /etc/pve/priv/storage/<NAME>.enc, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo -keyrecovery, 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 wrong key — manifest's key XX does not match provided key YY 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.",
+ "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 /etc/pve/priv/storage/<NAME>.enc, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo -keyrecovery, se descarga el backup 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 del backup. 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 ese backup, PBS devuelve un error de tipo wrong key — manifest's key XX does not match provided key YY y el modal muestra un panel estructurado con el fingerprint que PBS espera (el que quedó grabado en el manifest del backup), para que el usuario sepa qué clave concreta necesita importar.",
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
- "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: Descargar envía el archivo de clave actual al navegador del usuario; Subir 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 Eliminar 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 ¿Subir la clave a PBS?, un campo para la frase de contraseña al elegir Sí y un botón contextual para aplicar el cambio, con el texto Iniciar subida, Detener subida o Actualizar frase de contraseña 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."
+ "monitorManagementBody": "En la página de configuración de backups, la fila de cada destino PBS incluye los controles de la clave. Tiene tres acciones: Descargar exporta la clave actual al navegador del usuario, Subir reemplaza la clave instalada por otra que aporta el usuario (la anterior solo se sobrescribe cuando la nueva ha llegado correctamente a su ruta) y Eliminar retira la clave del host. Justo al lado está el interruptor del sobre de recuperación: un Sí/No para ¿Subir 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 Actualizar 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 el que se use."
},
"restoreAccess": {
"heading": "Recuperación del lado de la restauración",
- "body": "El flujo de restauración descubre las copias de host de ProxMenux en PBS listando los grupos de backups bajo el repositorio configurado y filtrando por patrón de backup ID. La pestaña Backups del Monitor renderiza la misma lista. Seleccionar un backup dispara proxmox-backup-client restore con el mismo repositorio + contraseña + fingerprint (y --keyfile cuando el backup iba cifrado), extrayendo el .pxar a un directorio de staging que _rs_check_layout alimenta al pipeline estándar de restauración. Para recuperación manual fuera de ProxMenux, el mismo comando extrae el archivo a cualquier ruta — el árbol resultante puede inspeccionarse o alimentar una restauración a mano."
+ "body": "El flujo de restauración descubre los backups de host de ProxMenux en PBS listando los grupos de backups bajo el repositorio configurado y filtrando por patrón de backup ID. La pestaña Backups del Monitor renderiza la misma lista. Seleccionar un backup dispara proxmox-backup-client restore con el mismo repositorio + contraseña + fingerprint (y --keyfile cuando el backup iba cifrado), extrayendo el .pxar a un directorio de staging que _rs_check_layout alimenta al pipeline estándar de restauración. Para recuperación manual fuera de ProxMenux, el mismo comando extrae el archivo a cualquier ruta — el árbol resultante puede inspeccionarse o alimentar una restauración a mano."
},
"references": {
"heading": "Referencias",
@@ -91,7 +91,7 @@
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
- "tail": " — la herramienta de línea de comandos que ProxMenux invoca en cada copia y restauración. Cubre backup IDs, tipos de backup, archivos, sintaxis del repositorio y variables de entorno."
+ "tail": " — la herramienta de línea de comandos que ProxMenux invoca en cada backup y restauración. Cubre backup IDs, tipos de backup, archivos, sintaxis del repositorio y variables de entorno."
},
{
"label": "Cifrado del lado del cliente",
@@ -101,7 +101,7 @@
{
"label": "Gestión de datastores",
"href": "https://pbs.proxmox.com/docs/storage.html",
- "tail": " — creación y administración de los datastores que reciben las copias de host, incluyendo el layout del chunk-store y permisos."
+ "tail": " — creación y administración de los datastores que reciben los backups de host, incluyendo el layout del chunk-store y permisos."
},
{
"label": "Poda y recolección de basura",
diff --git a/web/messages/es/docs/backup-restore/glossary.json b/web/messages/es/docs/backup-restore/glossary.json
index a4f35780..6cb1d2d1 100644
--- a/web/messages/es/docs/backup-restore/glossary.json
+++ b/web/messages/es/docs/backup-restore/glossary.json
@@ -1,15 +1,15 @@
{
"meta": {
"title": "Glosario de términos — Backup & Restore | ProxMenux",
- "description": "Glosario de términos y definiciones en español para el sistema de copia y restauración de ProxMenux: cifrado, clave, passphrase, sobre de recuperación, PBS, chunks, rootfs, manifiesto, runner y hidratación cross-kernel.",
+ "description": "Glosario de términos y definiciones en español para el sistema de backup y restauración de ProxMenux: cifrado, clave, passphrase, sobre de recuperación, PBS, chunks, rootfs, manifiesto, runner y hidratación cross-kernel.",
"ogTitle": "Glosario de Backup & Restore | ProxMenux",
- "ogDescription": "Definiciones claras en español para los términos que aparecen en la documentación de copia y restauración de ProxMenux.",
+ "ogDescription": "Definiciones claras en español para los términos que aparecen en la documentación de backup y restauración de ProxMenux.",
"twitterTitle": "Glosario Backup & Restore | ProxMenux",
"twitterDescription": "Passphrase, keyfile, sobre de recuperación, rootfs, manifiesto, PBS, chunks — todo definido en español."
},
"header": {
"title": "Glosario",
- "description": "Términos que aparecen a lo largo de la documentación de copia y restauración, con su definición.",
+ "description": "Términos que aparecen a lo largo de la documentación de backup y restauración, con su definición.",
"section": "Backup & Restore"
},
"intro": {
@@ -18,49 +18,42 @@
"groups": [
{
"title": "Cifrado y recuperación de clave",
- "intro": "Terminología del bloque de cifrado de copias en PBS. Incluye dos secretos distintos: una clave binaria y una passphrase escrita.",
+ "intro": "Terminología del bloque de cifrado de backups en PBS. Incluye dos secretos distintos: una clave binaria y una passphrase escrita.",
"entries": [
{
"id": "passphrase-recuperacion",
"term": "Passphrase de recuperación",
- "also": "recovery passphrase",
- "def": "Contraseña de texto que elige el usuario para proteger el sobre de recuperación. 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. No sirve para desbloquear la clave del keyfile ni se envía nunca a PBS. Nunca sale del host durante una copia normal."
+ "def": "Contraseña de texto que elige el usuario para proteger el sobre de recuperación. 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. No sirve para desbloquear la clave del keyfile ni se envía nunca a PBS. Nunca sale del host durante un backup 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 chunks de la copia antes de subirlos. Sin ese fichero, ninguna copia cifrada puede leerse. ProxMenux lo guarda en /usr/local/share/proxmenux/pbs-key.conf con permisos 600. Es el activo que hay que proteger; el sobre de recuperación existe precisamente para poder rescatar este fichero si se pierde."
+ "def": "Archivo de clave que proxmox-backup-client usa para cifrar los chunks antes de subirlos a PBS. Sin la clave correspondiente no se leen los datos cifrados. ProxMenux lo guarda en /usr/local/share/proxmenux/pbs-key.conf con modo 600. Protégelo: el sobre de recuperación 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 passphrase de recuperación. Solo aparece si la clave se creó con --kdf scrypt (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."
+ "def": "Contraseña opcional que puede llevar la propia clave, distinta de la passphrase de recuperación. Solo aparece si la clave se creó con --kdf scrypt (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 los backups programados 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 clave de cifrado envuelta en una capa adicional: se cifra con la passphrase de recuperación mediante AES-256-CBC y PBKDF2 antes de salir del host. Es lo que se sube a PBS en el grupo -keyrecovery. 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 sobre de recuperación encima."
},
{
"id": "kdf-none",
"term": "--kdf none",
- "also": "clave sin contraseña",
"def": "Opción de proxmox-backup-client key create 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 proxmox-backup-client key create que genera una clave protegida con una contraseña de la clave. 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."
+ "def": "Opción de proxmox-backup-client key create que genera una clave protegida con una contraseña de la clave. 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 los backups programados puedan correr sin intervención."
},
{
"id": "aes-256-cbc",
@@ -75,8 +68,8 @@
]
},
{
- "title": "Estructura de la copia",
- "intro": "Términos que describen lo que hay dentro de una copia, sea cual sea el destino.",
+ "title": "Estructura del backup",
+ "intro": "Términos que describen lo que hay dentro de un backup, sea cual sea el destino.",
"entries": [
{
"id": "rootfs",
@@ -86,17 +79,17 @@
{
"id": "manifiesto",
"term": "Manifiesto (manifest.json)",
- "def": "Documento JSON estructurado que describe el host de origen en el momento de la copia: hardware, almacenamiento, kernel, componentes instalados por ProxMenux e inventario de VMs y LXCs. Lo genera ProxMenux con seis colectores independientes. La restauración lo utiliza para comparar origen y destino."
+ "def": "Documento JSON estructurado que describe el host de origen en el momento del backup: hardware, almacenamiento, kernel, componentes instalados por ProxMenux e inventario de VMs y LXCs. Lo genera ProxMenux con seis colectores independientes. La restauración lo utiliza para comparar origen y destino."
},
{
"id": "staging",
"term": "Directorio de staging",
- "def": "Directorio temporal donde ProxMenux ensambla los tres bloques (rootfs, metadata y manifiesto) antes de empaquetarlos y subirlos al destino. Se elimina automáticamente al terminar la copia, incluso si se aborta."
+ "def": "Directorio temporal donde ProxMenux ensambla los tres bloques (rootfs, metadata y manifiesto) antes de empaquetarlos y subirlos al destino. Se elimina automáticamente al terminar el backup, incluso si se aborta."
},
{
"id": "perfil-defecto",
"term": "Perfil por defecto",
- "def": "Conjunto curado de rutas que ProxMenux copia por defecto en toda copia. Cubre configuración de PVE, red, SSH, kernel, apt, herramientas ProxMenux y otras. Está definido en el código y se documenta en la página Cómo funciona."
+ "def": "Conjunto curado de rutas que ProxMenux copia por defecto en todo backup. Cubre configuración de PVE, red, SSH, kernel, apt, herramientas ProxMenux y otras. Está definido en el código y se documenta en la página Cómo funciona."
},
{
"id": "rutas-personalizadas",
@@ -107,22 +100,22 @@
},
{
"title": "Destinos y almacenamiento",
- "intro": "Términos ligados al lugar donde acaba la copia — servidor PBS, archivo local o repositorio Borg — y a la forma en que PBS organiza los datos.",
+ "intro": "Términos ligados al lugar donde acaba el backup — servidor PBS, archivo local o repositorio Borg — y a la forma en que PBS organiza los datos.",
"entries": [
{
"id": "repositorio-pbs",
"term": "Repositorio PBS",
- "def": "Combinación de servidor Proxmox Backup Server + datastore + usuario al que se suben las copias. Se identifica con el formato user@realm@host:datastore. Un mismo servidor PBS puede alojar varios repositorios."
+ "def": "Combinación de servidor Proxmox Backup Server + datastore + usuario al que se suben los backups. Se identifica con el formato user@realm@host:datastore. Un mismo servidor PBS puede alojar varios repositorios."
},
{
"id": "datastore",
"term": "Datastore",
- "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."
+ "def": "Almacén concreto dentro de un servidor PBS donde se guardan los backups y sus chunks. Cada datastore vive sobre un sistema de ficheros del servidor PBS y tiene sus propios permisos y políticas."
},
{
"id": "chunk",
"term": "Chunk / deduplicación por chunks",
- "def": "PBS divide cada copia en trozos (chunks) de tamaño variable, identifica cada trozo por su hash y solo guarda cada trozo una vez, aunque aparezca en muchas copias distintas. Esto hace que copias sucesivas del mismo host o entre hosts similares consuman muy poco espacio adicional."
+ "def": "PBS divide cada backup en trozos (chunks) de tamaño variable, identifica cada trozo por su hash y solo guarda cada trozo una vez, aunque aparezca en muchos backups distintos. Esto hace que backups sucesivos del mismo host o entre hosts similares consuman muy poco espacio adicional."
},
{
"id": "fingerprint",
@@ -131,13 +124,13 @@
},
{
"id": "grupo-copia",
- "term": "Grupo de copia (backup group)",
- "def": "Contenedor lógico dentro de PBS bajo el cual se acumulan todas las copias sucesivas del mismo activo. Cada nueva copia comparte deduplicación con las anteriores del mismo grupo. ProxMenux utiliza dos grupos por host cuando hay cifrado: uno para la copia del host y otro con sufijo -keyrecovery para el sobre de recuperación."
+ "term": "Grupo de backup (backup group)",
+ "def": "Contenedor lógico dentro de PBS bajo el cual se acumulan todos los backups sucesivos del mismo activo. Cada nuevo backup comparte deduplicación con los anteriores del mismo grupo. ProxMenux utiliza dos grupos por host cuando hay cifrado: uno para el backup del host y otro con sufijo -keyrecovery para el sobre de recuperación."
},
{
"id": "backup-id",
"term": "Backup ID",
- "def": "Nombre del grupo de copia. ProxMenux propone por defecto hostcfg-HOSTNAME y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
+ "def": "Nombre del grupo de backup. ProxMenux propone por defecto hostcfg-HOSTNAME y permite editarlo antes de la subida; los caracteres no admitidos se limpian automáticamente."
},
{
"id": "pxar",
@@ -153,17 +146,17 @@
{
"id": "runner",
"term": "Runner",
- "def": "Script run_scheduled_backup.sh 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."
+ "def": "Script run_scheduled_backup.sh que ejecuta un backup programado. 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."
},
{
"id": "trabajo-programado",
"term": "Trabajo programado",
- "def": "Configuración persistida de una copia recurrente. Incluye destino, credenciales, cifrado, horario y retención. Se guarda en /var/lib/proxmenux/backup-jobs/<id>.env."
+ "def": "Configuración persistida de un backup recurrente. Incluye destino, credenciales, cifrado, horario y retención. Se guarda en /var/lib/proxmenux/backup-jobs/<id>.env."
},
{
"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 vzdump 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 vzdump lo ejecuta después de los backups de invitados cuando coincide el almacenamiento. El padre seleccionado aporta el destino y la retención, que se vuelve a leer de la tarea padre en cada ejecución, 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",
@@ -173,7 +166,7 @@
{
"id": "retencion",
"term": "Retención (keep-last, keep-daily…)",
- "def": "Política que decide qué copias antiguas se conservan y cuáles se eliminan. Se define por trabajo con parámetros como keep-last, keep-daily, keep-weekly, keep-monthly. El runner la aplica después de cada copia exitosa."
+ "def": "Política que decide qué backups antiguos se conservan y cuáles se eliminan. Se define por trabajo con parámetros como keep-last, keep-daily, keep-weekly, keep-monthly. El runner la aplica después de cada backup exitoso."
}
]
},
@@ -189,7 +182,7 @@
{
"id": "hidratacion",
"term": "Hidratación (cross-kernel)",
- "def": "Pasada de restauración que funde la configuración propia del usuario del origen (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel del origen. Se ejecuta cuando el kernel del destino es más reciente que el de la copia."
+ "def": "Pasada de restauración que funde la configuración propia del usuario del origen (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel del origen. Se ejecuta cuando el kernel del destino es más reciente que el del backup."
},
{
"id": "cross-kernel",
@@ -209,8 +202,7 @@
{
"id": "equipo-recien-instalado",
"term": "Equipo recién instalado",
- "also": "fresh install",
- "def": "Host acabado de reinstalar desde cero, sin la clave de cifrado local. Para restaurar copias cifradas hace falta primero recuperar la clave desde el sobre almacenado en PBS, con la passphrase de recuperación."
+ "def": "Host acabado de reinstalar desde cero, sin la clave de cifrado local. Para restaurar backups cifrados hace falta primero recuperar la clave desde el sobre almacenado en PBS, con la passphrase de recuperación."
}
]
}
@@ -221,7 +213,7 @@
{
"label": "Cómo funciona",
"href": "/docs/backup-restore/how-it-works",
- "tail": " — dónde encajan el rootfs, el manifiesto y el inventario de aplicaciones en cada copia."
+ "tail": " — dónde encajan el rootfs, el manifiesto y el inventario de aplicaciones en cada backup."
},
{
"label": "Destino Proxmox Backup Server",
diff --git a/web/messages/es/docs/backup-restore/how-it-works.json b/web/messages/es/docs/backup-restore/how-it-works.json
index 51c91934..9240775f 100644
--- a/web/messages/es/docs/backup-restore/how-it-works.json
+++ b/web/messages/es/docs/backup-restore/how-it-works.json
@@ -1,38 +1,38 @@
{
"meta": {
"title": "Cómo funciona ProxMenux Backup por dentro — rootfs, manifiesto, aplicaciones",
- "description": "Desglose detallado del contenido de una copia de ProxMenux: el rootfs producido por rsync del perfil de rutas por defecto, el manifiesto estructurado construido por seis colectores independientes, y el inventario de aplicaciones que dirige la reinstalación automática de paquetes y componentes tras una restauración.",
+ "description": "Desglose detallado del contenido de un backup de ProxMenux: el rootfs producido por rsync del perfil de rutas por defecto, el manifiesto estructurado construido por seis colectores independientes, y el inventario de aplicaciones que dirige la reinstalación automática de paquetes y componentes tras una restauración.",
"ogTitle": "Cómo funciona ProxMenux Backup por dentro",
- "ogDescription": "Los tres bloques de una copia de ProxMenux explicados: rootfs, manifiesto y aplicaciones.",
+ "ogDescription": "Los tres bloques de un backup de ProxMenux explicados: rootfs, manifiesto y aplicaciones.",
"twitterTitle": "Cómo funciona ProxMenux Backup | ProxMenux",
- "twitterDescription": "Los tres bloques de una copia de ProxMenux y cómo la restauración reproduce el host de origen a partir de ellos."
+ "twitterDescription": "Los tres bloques de un backup de ProxMenux y cómo la restauración reproduce el host de origen a partir de ellos."
},
"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.",
+ "description": "Desglose interno de un backup creado 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"
},
"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 .tar.zst, 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 rootfs —el sistema de archivos raíz del host— para colocar la configuración, después se consulta el manifiesto para detectar drift y decidir qué omitir, y finalmente el inventario de aplicaciones dirige la pasada de reinstalación post-arranque. No hay dependencias entre bloques — cada uno puede inspeccionarse o extraerse de forma independiente."
+ "body": "Cada backup produce una estructura con tres bloques definidos bajo un único directorio de preparación. El archivo subido al destino (.tar.zst local, backup PBS o archivo Borg) contiene esa misma estructura. La restauración utiliza los tres: consulta el manifiesto antes de aplicar cambios para detectar diferencias y decidir qué omitir; rootfs aporta los archivos de configuración, que se aplican en vivo o tras el reinicio; y el inventario de aplicaciones 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 metadata/ contiene los bloques estructurados; el subdirectorio rootfs/ 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).",
+ "intro": "Cada archivo respeta el mismo layout con independencia del destino. El subdirectorio metadata/ contiene los bloques estructurados; el subdirectorio rootfs/ contiene el backup del sistema de ficheros.",
+ "treeCaption": "El directorio de staging generado durante un backup. 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/…"
},
"rootfs": {
"heading": "El bloque rootfs",
- "intro": "El árbol rootfs/ es una copia plana del sistema de ficheros producida por rsync desde el host de origen. Contiene un perfil por defecto curado de rutas que importan para una restauración de Proxmox, más cualquier ruta personalizada añadida por el usuario al trabajo de copia o a la sesión interactiva. El conjunto es intencionadamente estrecho: solamente rutas que contienen configuración o contienen estado que Proxmox no puede regenerar por sí solo.",
+ "intro": "El árbol rootfs/ es una copia plana del sistema de ficheros producida por rsync desde el host de origen. Contiene un perfil por defecto curado de rutas que importan para una restauración de Proxmox, más cualquier ruta personalizada añadida por el usuario al trabajo de backup o a la sesión interactiva. El conjunto es intencionadamente estrecho: solamente rutas que contienen configuración o contienen estado que Proxmox no puede regenerar por sí solo.",
"defaultProfileTitle": "El perfil por defecto",
- "defaultProfileBody": "El perfil por defecto está definido por hb_default_profile_paths en lib_host_backup_common.sh. Cubre ocho categorías que en conjunto describen un host Proxmox operativo:",
+ "defaultProfileBody": "El perfil por defecto se define en hb_default_profile_paths de lib_host_backup_common.sh. Incluye ocho categorías fijas y, si corresponde, el estado ZFS, que juntas describen un host Proxmox operativo:",
"categoriesTitle": "Categorías de rutas",
"categoryRows": [
{
"category": "Núcleo PVE",
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
- "why": "Contenido del filesystem del clúster y valores por defecto de vzdump. La base pmxcfs (config.db) se captura con un snapshot consistente vía sqlite3 .backup sin parar el clúster, y los sidecars .db-wal y .db-shm quedan excluidos del rsync. Si sqlite3 no está disponible, la copia deposita un config.db.raw-fallback que la restauración promociona automáticamente."
+ "why": "Contenido del filesystem del clúster y valores por defecto de vzdump. La base pmxcfs (config.db) se captura con un snapshot consistente vía sqlite3 .backup sin parar el clúster, y los sidecars .db-wal y .db-shm quedan excluidos del rsync. Si sqlite3 no está disponible, el backup deposita un config.db.raw-fallback que la restauración promociona automáticamente."
},
{
"category": "Identidad del host y red",
@@ -62,12 +62,12 @@
{
"category": "Estado ProxMenux y herramientas",
"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": "Herramientas opcionales pero habituales de Proxmox. Las rutas ausentes se registran en metadata/missing_paths.txt sin detener la copia."
+ "why": "Herramientas opcionales pero habituales de Proxmox. Las rutas ausentes se registran en metadata/missing_paths.txt sin detener el backup."
},
{
"category": "Binarios ProxMenux y root",
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (subdirs volátiles excluidos)",
- "why": "Binarios instalados por ProxMenux y configuración por usuario bajo /root. Las rutas volátiles (.bash_history, .cache/, tmp/, .local/share/Trash/) quedan fuera de la copia. /var/lib/proxmenux guarda los trabajos de backup programados y el estado del host que mantiene ProxMenux; quedan fuera la preparación de una restauración, las copias de rollback y las marcas posteriores a la restauración, porque pertenecen al host que la ejecuta."
+ "why": "Binarios instalados por ProxMenux y configuración por usuario bajo /root. Las rutas volátiles (.bash_history, .cache/, tmp/, .local/share/Trash/) quedan fuera del backup. /var/lib/proxmenux guarda los trabajos de backup programados y el estado del host que mantiene ProxMenux; quedan fuera la preparación de una restauración, los backups de rollback y las marcas posteriores a la restauración, porque pertenecen al host que la ejecuta."
},
{
"category": "Estado ZFS (condicional)",
@@ -76,18 +76,18 @@
}
],
"customTitle": "Ampliar el perfil con rutas propias",
- "customBody": "Además del perfil por defecto, ProxMenux ofrece dos maneras de incluir rutas adicionales en una copia. Se combinan sin conflicto y ambas se aplican tanto a copias interactivas como a trabajos programados.",
+ "customBody": "Además del perfil por defecto, ProxMenux ofrece dos maneras de incluir rutas adicionales en un backup. Se combinan sin conflicto y ambas se aplican tanto a backups interactivos como a trabajos programados.",
"customExtrasTitle": "1. Extras persistentes (fichero por-host)",
- "customExtrasBody": "Un fichero de texto en /usr/local/share/proxmenux/backup-extra-paths.txt guarda una lista de rutas absolutas que el usuario ha marcado como \"incluir siempre\" en este host. Cuando una copia se ejecuta en modo Default, ProxMenux añade automáticamente estas rutas al perfil por defecto sin preguntar. El fichero se edita desde la interfaz — no hay que tocarlo a mano — y persiste entre reinicios y actualizaciones. Cada línea es una ruta absoluta; se admiten comentarios con #.",
+ "customExtrasBody": "Un fichero de texto en /usr/local/share/proxmenux/backup-extra-paths.txt guarda una lista de rutas absolutas que el usuario ha marcado como \"incluir siempre\" en este host. Cuando un backup se ejecuta en modo Default, ProxMenux añade automáticamente estas rutas al perfil por defecto sin preguntar. El fichero se edita desde la interfaz — no hay que tocarlo a mano — y persiste entre reinicios y actualizaciones. Cada línea es una ruta absoluta; se admiten comentarios con #.",
"customModeTitle": "2. Modo Custom (por ejecución)",
- "customModeBody": "Al lanzar una copia en modo Custom, en lugar de aplicar el perfil por defecto directamente, se muestra un checklist con todas las rutas: las del perfil por defecto y las de extras persistentes (estas últimas premarcadas con [+]). El usuario marca o desmarca lo que quiera para esa ejecución concreta, y puede además pulsar Add custom path para introducir una ruta nueva — que queda registrada en el fichero de extras persistentes para futuras copias.",
+ "customModeBody": "Al lanzar un backup en modo Custom, en lugar de aplicar el perfil por defecto directamente, se muestra un checklist con todas las rutas: las del perfil por defecto y las de extras persistentes (estas últimas premarcadas con [+]). El usuario marca o desmarca lo que quiera para esa ejecución concreta, y puede además pulsar Add custom path para introducir una ruta nueva — que queda registrada en el fichero de extras persistentes para futuros backups.",
"customMissingTitle": "Rutas ausentes en el origen",
- "customMissingBody": "Cualquier ruta del perfil (por defecto o añadida) que no exista en el host de origen se registra en metadata/missing_paths.txt dentro del archivo. La copia no falla ni interrumpe — el usuario ve el resumen de rutas archivadas y rutas ausentes al terminar. En la práctica esto ocurre con las rutas de herramientas opcionales como /etc/wireguard o /etc/prometheus cuando esas herramientas no están instaladas."
+ "customMissingBody": "Cualquier ruta del perfil (por defecto o añadida) que no exista en el host de origen se registra en metadata/missing_paths.txt dentro del archivo. El backup no falla ni interrumpe — el usuario ve el resumen de rutas archivadas y rutas ausentes al terminar. En la práctica esto ocurre con las rutas de herramientas opcionales como /etc/wireguard o /etc/prometheus cuando esas herramientas no están instaladas."
},
"manifest": {
"heading": "El bloque manifiesto",
- "intro": "manifest.json es un documento JSON estructurado que describe el host de origen en el momento de la copia. Se produce mediante seis colectores independientes orquestados por build_manifest.sh. Cada colector es de sólo lectura, produce un fragmento JSON bien definido y hace fallback a un valor vacío seguro si falla — el manifiesto sigue siendo utilizable aunque una sección quede incompleta.",
- "orchestratorCaption": "Los seis colectores componen el manifiesto. Cada uno corre en su propio subproceso; un fallo en uno hace fallback al valor por defecto documentado y advierte, pero no aborta la copia.",
+ "intro": "manifest.json es un documento JSON estructurado que describe el host de origen en el momento del backup. Se produce mediante seis colectores independientes orquestados por build_manifest.sh. Cada colector es de sólo lectura, produce un fragmento JSON bien definido y hace fallback a un valor vacío seguro si falla — el manifiesto sigue siendo utilizable aunque una sección quede incompleta.",
+ "orchestratorCaption": "Los seis colectores componen el manifiesto. Cada uno corre en su propio subproceso; un fallo en uno hace fallback al valor por defecto documentado y advierte, pero no aborta el backup.",
"collectorRows": [
{
"collector": "collect_source_host.sh",
@@ -117,7 +117,7 @@
{
"collector": "collect_guests.sh",
"produces": "vms_lxcs_at_backup",
- "content": "Enumera VMs (qm list) y LXCs (pct list) presentes en el momento de la copia — VMID, nombre, estado actual. Sólo el inventario: los datos reales del invitado son responsabilidad de vzdump / PBS."
+ "content": "Enumera VMs (qm list) y LXCs (pct list) presentes en el momento del backup — VMID, nombre, estado actual. Sólo el inventario: los datos reales del invitado son responsabilidad de vzdump / PBS."
}
],
"schemaTitle": "Validación por esquema",
@@ -125,7 +125,7 @@
},
"applications": {
"heading": "El inventario de aplicaciones",
- "intro": "Dos ficheros bajo metadata/ 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 metadata/ 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 apt-mark showmanual: todos los paquetes APT que fueron instalados explícitamente 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 _rs_run_complete_extras durante la restauración, filtrada por un filtro cascade-safe de tres pases (dpkg -s para lo ya instalado, detección de sibling-major para librerías, apt-get install --simulate para riesgo de cascade-remove) y después instalada con apt-get install -y.",
"componentsTitle": "components_status.json (parte del rootfs)",
diff --git a/web/messages/es/docs/backup-restore/index.json b/web/messages/es/docs/backup-restore/index.json
index 7625af0c..dc1c3451 100644
--- a/web/messages/es/docs/backup-restore/index.json
+++ b/web/messages/es/docs/backup-restore/index.json
@@ -1,20 +1,20 @@
{
"meta": {
- "title": "ProxMenux Backup & Restore — Descripción general | Copia y restauración completa del host Proxmox VE",
- "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.",
+ "title": "ProxMenux Backup & Restore — Descripción general | Backup y restauración completa del host Proxmox VE",
+ "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. El backup y la restauración son autocontenidos: 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.",
+ "ogDescription": "Backup y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes.",
"twitterTitle": "ProxMenux Backup & Restore | ProxMenux",
- "twitterDescription": "Copia y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes."
+ "twitterDescription": "Backup y restauración completa del host Proxmox VE con manifiesto estructurado, lista de paquetes y reinstaladores de componentes."
},
"header": {
"title": "Backup & Restore",
- "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.",
+ "description": "Backup 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"
},
"intro": {
"title": "Qué es, en un párrafo",
- "body": "Una copia de ProxMenux captura el estado completo de un host Proxmox: el sistema de ficheros (directorios relevantes bajo /etc, /root, /var/lib/pve-cluster, más rutas personalizadas opcionales), un manifiesto estructurado (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 un inventario de aplicaciones (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": "Un backup de ProxMenux captura el estado completo de un host Proxmox: el sistema de ficheros (directorios relevantes bajo /etc, /root, /var/lib/pve-cluster, más rutas personalizadas opcionales), un manifiesto estructurado (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 un inventario de aplicaciones (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."
},
"video": {
"heading": "Vídeo demostración",
@@ -24,17 +24,17 @@
},
"whatItIsNot": {
"heading": "Qué no es",
- "intro": "La sección cubre copia y restauración a nivel de host: la instalación de Proxmox en sí, no las cargas de trabajo que se ejecutan sobre ella.",
+ "intro": "La sección cubre backup y restauración a nivel de host: la instalación de Proxmox en sí, no las cargas de trabajo que se ejecutan sobre ella.",
"items": [
- "No es una herramienta de copia de VMs/CTs. Los discos de los invitados y su estado de RAM no se capturan en esta función; para eso está vzdump. Los ficheros de configuración de los invitados (/etc/pve/nodes/<node>/qemu-server/*.conf y lxc/*.conf) sí 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.",
+ "No es una herramienta de backup de VMs/CTs. Los discos de los invitados y su estado de RAM no se capturan en esta función; para eso está vzdump. Los ficheros de configuración de los invitados (/etc/pve/nodes/<node>/qemu-server/*.conf y lxc/*.conf) sí se capturan, de modo que tras la restauración el inventario de invitados reaparece y sus discos pueden re-adjuntarse desde un backup existente de PBS o local.",
"No es una operación a nivel de clúster. Cada nodo se copia a sí mismo. La pertenencia al clúster se captura como parte de /etc/pve para que un nodo restaurado pueda re-incorporarse al clúster, pero restaurar un clúster completo requiere coordinación por nodo.",
"No es una imagen completa del disco. 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 update-initramfs y la herramienta de bootloader) e instala los controladores adecuados contra el kernel que el destino tenga en ejecución."
]
},
"threePillars": {
- "heading": "Los tres pilares de una copia",
+ "heading": "Los tres pilares de un backup",
"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.",
+ "diagramCaption": "Cada backup 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",
"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",
@@ -44,11 +44,11 @@
},
"restoreIsUniversal": {
"heading": "La restauración reproduce el host de origen, no el archivo",
- "body": "Restaurar una copia de seguridad no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el kernel actual del destino, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el de la copia, una pasada de hidratación kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
+ "body": "Restaurar un backup no consiste solamente en extraer el sistema de ficheros. El flujo de restauración lee el manifiesto para detectar diferencias entre origen y destino (variaciones de hardware, renombrado de NICs, versión de kernel, identidad de la pool ZFS), reproduce el sistema de ficheros y lanza el instalador correspondiente a cada servicio que estuviera instalado en el origen (controlador NVIDIA, Coral TPU, herramientas AMD GPU, herramientas Intel GPU). Cada instalador se ejecuta contra el kernel actual del destino, por lo que el host restaurado no depende de que el kernel del origen esté presente. Cuando el kernel del destino es más reciente que el del backup, una pasada de hidratación kernel-agnóstica funde la configuración propia del usuario (tokens IOMMU, IDs de dispositivos VFIO, quirks personalizadas, claves de GRUB) sobre la configuración de arranque fresca del destino, sin copiar verbatim los ficheros ligados al kernel."
},
"twoInterfaces": {
"heading": "Dos interfaces, un único backend",
- "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.",
+ "intro": "Cada paso del flujo de backup 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)",
@@ -56,7 +56,7 @@
},
"whereNext": {
"heading": "A dónde seguir desde aquí",
- "intro": "Cada subsección posterior desarrolla en detalle un aspecto del flujo. Se recomienda empezar por Cómo funciona para entender qué contiene el archivo y por qué. Consultar Destinos para configurar el destino de la copia. Leer Restauración y Restauración cross-kernel para el lado de recuperación.",
+ "intro": "Cada subsección posterior desarrolla en detalle un aspecto del flujo. Se recomienda empezar por Cómo funciona para entender qué contiene el archivo y por qué. Consultar Destinos para configurar el destino del backup. Leer Restauración y Restauración cross-kernel para el lado de recuperación.",
"items": [
{
"label": "Cómo funciona",
@@ -69,9 +69,9 @@
"tail": " — comparativa entre archivo local, Proxmox Backup Server (recomendado) y Borg, y cómo configurar cada uno."
},
{
- "label": "Crear copias",
+ "label": "Crear backups",
"href": "/docs/backup-restore/creating-backups",
- "tail": " — copias puntuales, perfil de rutas por defecto, adición de rutas personalizadas, cifrado en PBS."
+ "tail": " — backups puntuales, perfil de rutas por defecto, adición de rutas personalizadas, cifrado en PBS."
},
{
"label": "Trabajos programados",
@@ -86,7 +86,7 @@
{
"label": "Restauración cross-kernel",
"href": "/docs/backup-restore/cross-kernel",
- "tail": " — comportamiento direccional cuando el kernel del destino difiere del de la copia, el filtro de subconjunto seguro y las cuatro fases de hidratación."
+ "tail": " — comportamiento direccional cuando el kernel del destino difiere del del backup, el filtro de subconjunto seguro y las cuatro fases de hidratación."
}
]
}
diff --git a/web/messages/es/docs/backup-restore/restoring.json b/web/messages/es/docs/backup-restore/restoring.json
index 732fa278..5f3ea69c 100644
--- a/web/messages/es/docs/backup-restore/restoring.json
+++ b/web/messages/es/docs/backup-restore/restoring.json
@@ -1,28 +1,28 @@
{
"meta": {
- "title": "Restaurar una copia — flujos Completo y Personalizado | ProxMenux",
- "description": "El flujo completo de restauración. Documenta las tres acciones disponibles sobre cualquier copia (ver, descargar, restaurar), la comprobación de compatibilidad y sus resultados, los modos Completo y Personalizado, la clasificación de rutas que decide qué se aplica en vivo y qué espera al siguiente arranque, el dispatcher de arranque y la pasada de reinstalación post-arranque de componentes.",
+ "title": "Restaurar un backup — flujos Completo y Personalizado | ProxMenux",
+ "description": "El flujo completo de restauración. Documenta las tres acciones disponibles sobre cualquier backup (ver, descargar, restaurar), la comprobación de compatibilidad y sus resultados, los modos Completo y Personalizado, la clasificación de rutas que decide qué se aplica en vivo y qué espera al siguiente arranque, el dispatcher de arranque y la pasada de reinstalación post-arranque de componentes.",
"ogTitle": "ProxMenux Backup — restaurar",
"ogDescription": "Flujos de restauración completo y personalizado con la comprobación de compatibilidad, la clasificación de rutas, el dispatcher post-arranque y la reinstalación de componentes.",
- "twitterTitle": "Restaurar una copia | ProxMenux",
- "twitterDescription": "Cómo se convierte una copia de host de ProxMenux en un host Proxmox operativo."
+ "twitterTitle": "Restaurar un backup | ProxMenux",
+ "twitterDescription": "Cómo se convierte un backup de host de ProxMenux en un host Proxmox operativo."
},
"header": {
- "title": "Restaurar una copia",
- "description": "El flujo completo de restauración: desde elegir una copia hasta un host operativo. Documenta la comprobación de compatibilidad, los dos modos de restauración, el dispatcher post-arranque, la pasada de reinstalación de componentes, y los mecanismos que hacen predecibles las restauraciones cross-host y cross-kernel.",
+ "title": "Restaurar un backup",
+ "description": "El flujo completo de restauración: desde elegir un backup hasta un host operativo. Documenta la comprobación de compatibilidad, los dos modos de restauración, el dispatcher post-arranque, la pasada de reinstalación de componentes, y los mecanismos que hacen predecibles las restauraciones cross-host y cross-kernel.",
"section": "Backup & Restore"
},
"intro": {
"title": "La restauración reproduce el origen, no sólo los ficheros",
- "body": "Restaurar una copia de ProxMenux no es una extracción. Los ficheros son sólo el primer paso: una vez colocado el sistema de ficheros, la restauración lee el manifiesto para detectar diferencias entre origen y destino, filtra rutas que romperían el arranque del destino, hidrata configuración propia del usuario que no puede copiarse verbatim, y — tras el reinicio obligatorio — reinstala cada componente que tuviera el origen (controlador NVIDIA, Coral TPU, herramientas GPU) contra el kernel actual del destino. Lo que el usuario elige del menú es una única copia; lo que realmente sucede involucra a la comprobación de compatibilidad, la clasificación de rutas, el dispatcher post-arranque y la pasada de reinstalación trabajando juntos para producir un host que se comporta como el origen."
+ "body": "Restaurar un backup de ProxMenux requiere más que extraer archivos. Antes de aplicar cambios, se consulta el manifiesto para detectar diferencias entre origen y destino, se filtran rutas que podrían impedir el arranque y se adapta la configuración del usuario que no puede copiarse literalmente. Tras el reinicio necesario, se intenta reinstalar los componentes compatibles registrados (controlador NVIDIA, Coral TPU y herramientas GPU) para el kernel que ejecuta el destino. Un único backup dirige la comprobación de compatibilidad, la clasificación de rutas y los procesos de arranque y posteriores. Revisa los resultados de cada componente y los logs para confirmar el resultado."
},
"threeActions": {
- "heading": "Tres acciones sobre una copia",
- "intro": "Seleccionar una copia de la lista abre un menú con tres acciones.",
+ "heading": "Tres acciones sobre un backup",
+ "intro": "Seleccionar un backup de la lista abre un menú con tres acciones.",
"actionRows": [
{
"action": "Ver",
- "detail": "Abre una vista de sólo lectura del archivo: contenido de manifest.json (hostname de origen, versión de PVE, kernel, hardware, componentes instalados), la lista de rutas dentro de rootfs/, y un diff de qué cambiaría en el host actual si se aplicara la copia."
+ "detail": "Abre una vista de sólo lectura del archivo: contenido de manifest.json (hostname de origen, versión de PVE, kernel, hardware, componentes instalados), la lista de rutas dentro de rootfs/, y un diff de qué cambiaría en el host actual si se aplicara el backup."
},
{
"action": "Descargar",
@@ -40,7 +40,7 @@
"outputRows": [
{
"output": "Flag de dirección",
- "detail": "HB_COMPAT_KERNEL_DIRECTION — uno de same, bk_newer o bk_older. Compara la versión mayor del kernel de la copia contra la del destino. Dirige el filtro cross-kernel de subconjunto seguro (sólo dispara en bk_older) y la pasada de hidratación documentada en la página cross-kernel."
+ "detail": "HB_COMPAT_KERNEL_DIRECTION — uno de same, bk_newer o bk_older. Compara la versión mayor del kernel del backup contra la del destino. Dirige el filtro cross-kernel de subconjunto seguro (sólo dispara en bk_older) y la pasada de hidratación documentada en la página cross-kernel."
},
{
"output": "Lista de rutas a saltar",
@@ -52,7 +52,7 @@
},
{
"output": "Plan de rollback",
- "detail": "Lo calcula compute_rollback_plan.sh. Lista las VMs, LXCs y componentes presentes en el destino pero no en la copia. El usuario puede optar durante el diálogo de confirmación por eliminarlos como parte de la restauración, de modo que el destino termine casando exactamente con la copia."
+ "detail": "Lo calcula compute_rollback_plan.sh. Lista las VMs, LXCs y componentes presentes en el destino pero ausentes del backup. La confirmación permite optar por eliminar los invitados adicionales antes del reinicio. Los componentes deben desinstalarse manualmente y la eliminación de invitados puede fallar; no garantiza que el destino coincida exactamente con el backup."
}
],
"reportBody": "La comprobación también emite un informe estructurado (HB_COMPAT_RESULTS) categorizado como PASS / INFO / WARN / FAIL. Las entradas WARN y FAIL aparecen en el panel previo a la restauración; la restauración se niega a continuar sólo cuando hay un FAIL que el usuario no puede resolver pulsando Continuar."
@@ -77,15 +77,15 @@
"rows": [
{
"class": "hot",
- "detail": "Rutas que se aplican de inmediato sobre el sistema en ejecución. El servicio que las consume detecta el cambio por sí mismo o al siguiente reload, sin necesidad de reiniciar. Son la mayoría del contenido de una copia: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, ficheros de configuración de servicios generales, etc."
+ "detail": "Rutas que se aplican de inmediato sobre el sistema en ejecución. El servicio que las consume detecta el cambio por sí mismo o al siguiente reload, sin necesidad de reiniciar. Son la mayoría del contenido de un backup: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, ficheros de configuración de servicios generales, etc."
},
{
"class": "reboot",
- "detail": "Rutas que se aplican de inmediato también, pero cuyo efecto real sólo se manifiesta en el siguiente arranque: el kernel sólo lee /etc/default/grub al iniciar el bootloader, /etc/fstab al montar los filesystems, /etc/modules al cargar módulos, etc. El fichero está en su sitio nada más aplicarse, pero el sistema tiene que reiniciar para consumirlo. Ejemplos: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/initramfs-tools."
+ "detail": "Rutas que este flujo difiere al siguiente arranque en lugar de aplicar de inmediato. Afectan a la configuración de arranque: la generación del bootloader lee /etc/default/grub, los montajes usan /etc/fstab y la carga de módulos usa /etc/modules. Los archivos pendientes se aplican tras reiniciar y después se regeneran los artefactos de arranque necesarios. Ejemplos: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
},
{
"class": "dangerous",
- "detail": "Rutas que NO se aplican en el sistema en ejecución — la escritura viva podría corromper estado o cortar la conexión activa. Estas rutas se preparan en el conjunto pendiente y las escribe el dispatcher post-arranque después del reinicio, cuando el clúster está arriba pero antes de que el sistema esté completamente en uso. Ejemplos: /etc/pve (pmxcfs es un FUSE vivo; escribir directo en él lo saltea), /var/lib/pve-cluster (datos vivos del clúster), /etc/network (podría reconfigurar la misma interfaz por la que el usuario está conectado por SSH y cortar la sesión)."
+ "detail": "Rutas que NO se aplican en el sistema en ejecución: escribirlas en caliente podría corromper el estado o cortar la conexión activa. Se preparan en el conjunto pendiente: /etc/network se escribe al principio del siguiente arranque, antes de que se levante la red, y /etc/pve lo escribe el dispatcher post-arranque cuando el sistema de archivos del clúster ya está activo. Ejemplos: /etc/pve (pmxcfs es un montaje FUSE con la configuración activa del clúster), /var/lib/pve-cluster (datos vivos del clúster; se guardan en el directorio de recuperación solo para recuperarlos a mano), /etc/network (podría reconfigurar la misma interfaz por la que el usuario está conectado por SSH y cortar la sesión)."
}
]
},
@@ -131,7 +131,7 @@
},
{
"task": "Reinstalación de componentes",
- "detail": "Lee el components_status.json restaurado e itera sobre los instaladores registrados (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Cada instalador corre en modo --auto-reinstall, lee su versión previamente registrada del state file, y recompila contra el kernel actual del destino. El flujo interactivo no hace esto — reinstalar drivers contra un kernel que aún no ha arrancado carece de sentido."
+ "detail": "Lee el components_status.json restaurado y recorre los instaladores compatibles registrados (nvidia_driver, coral_driver, amdgpu_top e intel_gpu_tools). Cada uno se ejecuta en modo --auto-reinstall, lee su estado guardado y reinstala para el entorno del destino, recompilando módulos cuando corresponde. Se difiere hasta después del reinicio para utilizar el kernel que ejecute entonces el destino. Los fallos individuales se registran y no detienen el siguiente componente."
},
{
"task": "Comprobación de sanidad del arranque",
@@ -145,7 +145,7 @@
},
"liveProgress": {
"heading": "Progreso en vivo en la pestaña Backups del Monitor",
- "body": "Tras el reboot, la pestaña Backups del Monitor de ProxMenux muestra una tarjeta de progreso en vivo que refleja el estado de apply_cluster_postboot.service a medida que avanza. La tarjeta lee /var/lib/proxmenux/restore-state.json, que el dispatcher actualiza en cada hito (aplicar configuración del cluster, reconstruir initramfs, actualizar bootloader, reinstalación por componente, verificación de arranque, finalización).",
+ "body": "Tras el reboot, la pestaña Backups del Monitor de ProxMenux muestra una tarjeta de progreso en vivo que refleja el estado de proxmenux-apply-cluster-postboot.service a medida que avanza. La tarjeta lee /var/lib/proxmenux/restore-state.json, que el dispatcher actualiza en cada hito (aplicar configuración del cluster, reconstruir initramfs, actualizar bootloader, reinstalación por componente, verificación de arranque, finalización).",
"fields": [
{
"name": "Insignia de estado",
@@ -184,9 +184,9 @@
},
"postbootExample": {
"heading": "Cómo se ve el post-boot en la consola",
- "body": "En la consola física del host la ejecución exitosa del dispatcher termina con una línea [ OK ] Finished proxmenux-apply-cluster-postboot.service. Cuando esa línea aparece — normalmente acompañada de los OK del multi-user.target y del graphical.target — la restauración ha terminado por completo: componentes reinstalados, boot artifacts regenerados, cluster reconciliado.",
+ "body": "En la consola física del host, una ejecución del dispatcher que termina correctamente muestra [ OK ] Finished proxmenux-apply-cluster-postboot.service, a menudo junto a los OK de multi-user.target y graphical.target. Esto señala el final del proceso. Puede haber fallos individuales o avisos de arranque registrados; comprueba los estados de componentes y los logs del Monitor antes de dar el host por totalmente restaurado.",
"imageAlt": "Consola física de Proxmox mostrando el mensaje '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).' seguido del OK de multi-user.target y graphical.target, con el prompt de login del host encima.",
- "imageCaption": "Consola física tras un post-boot exitoso. La línea 'Finished proxmenux-apply-cluster-postboot.service' es la señal de que el flujo de restauración ha terminado por completo — el mismo evento que la notificación 'Host restore finished' expone en el Monitor."
+ "imageCaption": "Consola física al terminar el proceso. 'Finished proxmenux-apply-cluster-postboot.service' señala su finalización, que también comunica 'Host restore finished' en el Monitor. Hay que revisar los resultados de componentes y los avisos."
},
"tenMinutes": {
"heading": "Por qué importan los últimos diez minutos",
@@ -228,11 +228,11 @@
"detail": "Barata. El usuario se entera de que la ejecución ha terminado en el momento en que dispara la notificación."
}
],
- "outroBody": "La ventana importa porque el usuario puede hacer login durante este tiempo y ver herramientas ausentes (nvidia-smi no encontrado, coral no detectado). Es esperado — la reinstalación sigue corriendo en background. La notificación de finalización señala cuando todo está listo."
+ "outroBody": "Durante este intervalo puede que falten herramientas al iniciar sesión (nvidia-smi no encontrado, coral no detectado) porque la reinstalación sigue en segundo plano. La notificación marca el final del proceso; revisa los resultados de componentes, avisos y logs para distinguir los éxitos de los fallos individuales."
},
"destructiveRollback": {
"heading": "El rollback destructivo opcional",
- "body": "Una restauración es aditiva por defecto: si el destino tiene VMs, LXCs o componentes que no están en la copia, sobreviven. Esto preserva el trabajo pero puede dejar entradas hostpci obsoletas, componentes huérfanos o VMs que el usuario ya no quiere. Cuando se detecta drift entre destino y copia, el diálogo de confirmación ofrece un segundo yes/no: ¿Ejecutar rollback destructivo?. Aceptar dispara _rs_execute_rollback, que elimina las VMs, LXCs y componentes que existen en el destino pero no en la copia. El rollback corre ANTES del reinicio para que la maquinaria de pending-restore vea un estado limpio. Es opt-in — el default es No, y el usuario ve exactamente qué se eliminaría listado por nombre (VMID y CTID) antes de decidir."
+ "body": "La restauración es aditiva por defecto: se conservan las VMs, LXCs y componentes adicionales del destino. Si hay diferencias, la confirmación ofrece ¿Ejecutar el rollback destructivo?, con No por defecto. Aceptar llama a _rs_execute_rollback antes del reinicio para intentar eliminar las VMs y LXCs adicionales indicados. Los componentes se señalan para desinstalación manual porque la automática no está implementada. Los fallos al eliminar invitados se registran y el proceso continúa; no se garantiza una coincidencia exacta con el backup. Revisa nombres y VMID/CTID antes de elegir esta opción destructiva."
},
"logs": {
"heading": "Dónde viven los logs",
@@ -265,7 +265,7 @@
{
"label": "Restauración cross-kernel",
"href": "/docs/backup-restore/cross-kernel",
- "tail": " — el filtro direccional de subconjunto seguro y la pasada de hidratación que se invocan cuando el kernel del destino difiere del de la copia."
+ "tail": " — el filtro direccional de subconjunto seguro y la pasada de hidratación que se invocan cuando el kernel del destino difiere del del backup."
},
{
"label": "Cómo funciona",
diff --git a/web/messages/es/docs/backup-restore/scheduled-jobs.json b/web/messages/es/docs/backup-restore/scheduled-jobs.json
index d38ef39e..692d60dc 100644
--- a/web/messages/es/docs/backup-restore/scheduled-jobs.json
+++ b/web/messages/es/docs/backup-restore/scheduled-jobs.json
@@ -1,15 +1,15 @@
{
"meta": {
"title": "Trabajos programados — timers, modo adjunto, retención | ProxMenux",
- "description": "Trabajos de copia de host programados en ProxMenux. Dos modos de creación (timer systemd propio o adjuntarse a un trabajo vzdump de PVE existente), valores de retención aplicados por trabajo vía proxmox-backup-client/borg/local prune, layout de almacenamiento bajo /var/lib/proxmenux/backup-jobs, y el script runner que produce archivos idénticos al flujo interactivo.",
+ "description": "Trabajos de backup de host programados en ProxMenux. Dos modos de creación (timer systemd propio o adjuntarse a un trabajo vzdump de PVE existente), valores de retención aplicados por trabajo vía proxmox-backup-client/borg/local prune, layout de almacenamiento bajo /var/lib/proxmenux/backup-jobs, y el script runner que produce archivos idénticos al flujo interactivo.",
"ogTitle": "ProxMenux Backup — trabajos programados",
- "ogDescription": "Copias de host desatendidas programadas con modo adjunto, retención, y los mismos tres destinos que el flujo interactivo.",
+ "ogDescription": "Backups de host desatendidos programados con modo adjunto, retención, y los mismos tres destinos que el flujo interactivo.",
"twitterTitle": "Trabajos programados | ProxMenux",
- "twitterDescription": "Trabajos de copia de host desatendidos con modo adjunto y retención."
+ "twitterDescription": "Trabajos de backup de host desatendidos con modo adjunto y retención."
},
"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.",
+ "description": "Trabajos de backup 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"
},
"intro": {
@@ -22,11 +22,11 @@
},
"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 misma ventana que los invitados. En la restauración, las configuraciones de los invitados vienen de la copia de host (viven bajo /etc/pve), 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 el backup del host hace que se ejecute después del backup de los invitados, en el mismo ciclo de backup. Al restaurar, las configuraciones de los invitados proceden del backup del host (bajo /etc/pve) y sus discos de los backups vzdump de ese ciclo. Esto facilita coordinar la recuperación de todo el nodo, pero no es un snapshot atómico: 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",
- "body": "Para garantizar la máxima compatibilidad entre la copia y su posterior restauración se recomienda hacer copias de seguridad del host con frecuencia. Cuanto más reciente sea la copia respecto al estado actual del host, menor será la desviación de configuración, paquetes y componentes que la restauración tendrá que reconciliar."
+ "body": "Para garantizar la máxima compatibilidad entre el backup y su posterior restauración se recomienda hacer backups del host con frecuencia. Cuanto más reciente sea el backup respecto al estado actual del host, menor será la desviación de configuración, paquetes y componentes que la restauración tendrá que reconciliar."
},
"modes": {
"heading": "Los dos modos",
@@ -35,7 +35,7 @@
"mode": "Nuevo trabajo programado",
"backends": "Local, PBS, Borg",
"schedule": "Expresión OnCalendar propia (sintaxis de calendario systemd — por ejemplo daily, Mon..Fri 03:00).",
- "retention": "Se pregunta por separado: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. La aplica el runner tras cada copia exitosa."
+ "retention": "Se pregunta por separado: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. La aplica el runner tras cada backup exitoso."
},
{
"mode": "Adjuntar a un trabajo vzdump de PVE",
@@ -47,7 +47,7 @@
},
"attachDetail": {
"heading": "Cómo funciona el modo adjunto",
- "intro": "PVE escribe las tareas vzdump en /etc/pve/jobs.cfg — 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 vzdump en /etc/pve/jobs.cfg: una sección por tarea, con el almacenamiento de los backups de VM y LXC. El modo adjunto requiere un backend compatible con ProxMenux (Local o PBS). El backup del host se ejecuta desde el hook job-end cuando termina la tarea de backup de los invitados.",
"steps": [
{
"step": "1",
@@ -59,14 +59,14 @@
},
{
"step": "3",
- "detail": "hb_install_vzdump_hook registra un script-hook en /etc/vzdump.conf. Cuando PVE ejecuta cualquier tarea vzdump, el script-hook dispara; si el $STOREID que se le pasa coincide con el PVE_STORAGE de un trabajo adjuntado, el runner se invoca para ese trabajo."
+ "detail": "hb_install_vzdump_hook registra un hook en /etc/vzdump.conf. En la fase job-end de cualquier tarea vzdump, compara el $STOREID recibido con el PVE_STORAGE 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: path/dump/ 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 el backup 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",
@@ -94,9 +94,9 @@
"heading": "Qué hace un trabajo cuando se dispara",
"intro": "Cada trabajo — sea del modelo nuevo o adjunto — ejecuta la misma secuencia de tres pasos:",
"steps": [
- "Preparar la copia. Lee la configuración del trabajo (destino, perfil, rutas) y ensambla el árbol de la copia siguiendo exactamente el mismo procedimiento que el flujo interactivo. El resultado es el mismo archivo que produciría una copia manual con esos ajustes.",
- "Escribir en el destino. Sube o escribe la copia al destino configurado — un archivo local .tar.zst, un backup PBS o un archivo Borg — usando exactamente las mismas herramientas y credenciales que utilizaría una copia manual al mismo destino.",
- "Aplicar retención. Elimina las copias antiguas del destino conservando los valores keep-last / keep-daily / keep-weekly configurados en el trabajo. La poda la realiza el propio destino: PBS mantiene la cuenta en su lado, Borg ejecuta borg prune, y en Local ProxMenux borra los archivos que quedan fuera del keep-last."
+ "Preparar el backup. Lee la configuración del trabajo (destino, perfil, rutas) y ensambla el árbol del backup siguiendo exactamente el mismo procedimiento que el flujo interactivo. El resultado es el mismo archivo que produciría un backup manual con esos ajustes.",
+ "Escribir en el destino. Sube o escribe el backup al destino configurado — un archivo local .tar.zst, un backup PBS o un archivo Borg — usando exactamente las mismas herramientas y credenciales que utilizaría un backup manual al mismo destino.",
+ "Aplicar retención. Elimina los backups antiguos del destino conservando los valores keep-last / keep-daily / keep-weekly configurados en el trabajo. La poda la realiza el propio destino: PBS mantiene la cuenta en su lado, Borg ejecuta borg prune, y en Local ProxMenux borra los archivos que quedan fuera del keep-last."
]
},
"management": {
@@ -127,13 +127,13 @@
},
"notifications": {
"heading": "Notificaciones",
- "body": "Cada ejecución programada dispara los mismos eventos hb_notify_lifecycle que el flujo interactivo (start, complete, fail). Si hay canales de notificación configurados en el Monitor, los trabajos desatendidos exponen sus resultados igual que las copias manuales — un usuario no necesita revisar el log para saber si un trabajo tuvo éxito."
+ "body": "Cada ejecución programada dispara los mismos eventos hb_notify_lifecycle que el flujo interactivo (start, complete, fail). Si hay canales de notificación configurados en el Monitor, los trabajos desatendidos exponen sus resultados igual que los backups manuales — un usuario no necesita revisar el log para saber si un trabajo tuvo éxito."
},
"whereNext": {
"heading": "A dónde seguir",
"items": [
{
- "label": "Crear copias",
+ "label": "Crear backups",
"href": "/docs/backup-restore/creating-backups",
"tail": " — el flujo interactivo que comparte backend con el scheduler."
},
diff --git a/web/messages/fr/docs/backup-restore/creating-backups.json b/web/messages/fr/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..8fcdb1fe
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/creating-backups.json
@@ -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 exactement les mêmes fonctions. 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 (_bk_pbs, _bk_borg ou _bk_local). 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 backup_menu dans backup_host.sh."
+ },
+ {
+ "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 : manuel (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 programmé (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 run_scheduled_backup.sh ; 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 .tar.zst 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 .tar.zst 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 hb_default_profile_paths (documentée dans Comment ça marche sous Catégories de chemins) plus chaque entrée dans le fichier supplémentaire persistant /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). L’utilisateur coche les chemins pour cette exécution et peut cliquer sur Ajouter un chemin personnalisé pour ajouter un chemin absolu. Tout chemin ainsi ajouté est enregistré dans backup-extra-paths.txt 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 Gérer les chemins personnalisés, 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. hb_prepare_staging assemble l’arborescence de l’archive dans /tmp/proxmenux-DESTINATION-stage.XXXXXX et remplit chacun des trois blocs de données.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "Assemblage du rootfs",
+ "detail": "Exécute rsync -a pour chaque chemin sélectionné dans staging_root/rootfs/. La base de données pmxcfs de /var/lib/pve-cluster/config.db est capturée séparément via sqlite3 .backup pour produire un instantané cohérent sans arrêter le cluster, et les sidecars .db-wal / .db-shm sont exclus du rsync; lorsque sqlite3 n'est pas disponible, un fichier config.db.raw-fallback est créé puis utilisé comme base de données lors de l’importation. Les sous-chemins volatils (historique bash, caches, poubelles) sont exclus du /root/. Les chemins absents de la source sont enregistrés dans metadata/missing_paths.txt sans arrêter la sauvegarde."
+ },
+ {
+ "step": "2",
+ "name": "Génération de manifestes",
+ "detail": "build_manifest.sh coordonne les six collecteurs et écrit manifest.json à 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": "apt-mark showmanual est capté mot à mot dans metadata/packages.manual.list. L'état des composants est déjà à l'intérieur des rootfs restauré (components_status.json) car /usr/local/share/proxmenux/ fait partie du profil par défaut."
+ },
+ {
+ "step": "4",
+ "name": "Informations sur l’exécution",
+ "detail": "metadata/run_info.env 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": "hb_notify_lifecycle \"start\" est déclenché. Si les notifications sont configurées dans Monitor, un événement Sauvegarde de l’hôte démarrée 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 rsync -aAXH --numeric-ids. 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": [
+ "images/ — images de disque exportées.",
+ "dump/ — sorties vzdump.",
+ "tmp/ — fichiers temporaires.",
+ "*.log — fichiers journaux."
+ ],
+ "rootTitle": "Exclusions de /root/",
+ "rootBody": "/root/ 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": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "Exclusions de /usr/local/share/proxmenux/",
+ "proxmenuxBody": "Ce répertoire ne livre que l'état utilisateur — components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Chemins en dehors du profil",
+ "notInProfileBody": "Tout ce qui n'est pas listé dans hb_default_profile_paths et qui n'est pas ajouté en tant qu'extra personnalisé ou persistant ne fait pas partie de la sauvegarde. Exemples notables:",
+ "notInProfileItems": [
+ "Disques des VM et des LXC — manipulés par vzdump, pas par cette fonctionnalité. Les fichiers de configuration invités sous /etc/pve/nodes/*/qemu-server/*.conf et lxc/*.conf sont capturés (ils vivent sous /etc/pve) de sorte que la restauration reproduit l'inventaire; les disques eux-mêmes sont ré-attachés à partir d'une sauvegarde existante vzdump/PBS.",
+ "/boot et /boot/efi — les binaires du noyau, les initramfs et la partition ESP UEFI sont régénérés par les propres update-initramfs, update-grub ou proxmox-boot-tool refresh après la restauration. Le chargeur de démarrage n’est jamais recopié à l’identique.",
+ "Les systèmes de fichiers de noyau et d'exécution du système — /proc, /sys, /dev et /run sont des pseudo-systèmes de fichiers produits par le noyau et l'udev; ils ne persistent nulle part.",
+ "Binaires des paquets sous /usr/bin, /usr/lib, /lib, /sbin — réinstallés par APT sur la cible à partir de packages.manual.list.",
+ "/var/log/, /var/tmp/, /var/cache/ — état d'exécution par hôte, non restauré.",
+ "/home/USER — 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 backup-extra-paths.txt passe par le même pipeline rsync que les chemins de profil par défaut. Les exclusions globales s'appliquent. Si le chemin personnalisé se trouve sous /root/ ou /usr/local/share/proxmenux/, les exclusions spécifiques au chemin ci-dessus s'appliquent toujours. Chaque chemin archivé — par défaut ou personnalisé — est enregistré dans metadata/paths_archived.txt. Les chemins qui n'existent pas sur la source sont enregistrés dans metadata/missing_paths.txt 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 .pxar 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 trap 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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar dépose un *.proxmenux.json à 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": "hb_notify_lifecycle \"complete\" ou \"fail\" 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/cross-kernel.json b/web/messages/fr/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..135e0424
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve. Les deux premiers nombres (6.17 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é, hb_compat_check compare le noyau enregistré dans le manifeste de sauvegarde au noyau courant de la cible (uname -r) et classifie la restauration dans l'un des trois cas, stockés dans la variable interne HB_COMPAT_KERNEL_DIRECTION:",
+ "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 same, 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 plus ancien 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 uname -r 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 intel_iommu=on 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 hb_unsafe_paths_cross_version à RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) qui peuvent verrouiller le pool comme étranger."
+ },
+ {
+ "category": "Sources APT",
+ "paths": "/etc/apt",
+ "reason": "Les suites sources APT peuvent déclencher une dégradation des paquets critiques lors de la prochaine mise à jour."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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, GRUB_TIMEOUT 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). _rs_hyd_grub fusionne les paramètres de manifest.kernel_params.cmdline_extra de la sauvegarde dans GRUB_CMDLINE_LINUX_DEFAULT de la cible, en ignorant les clés déjà présentes. Il reprend ensuite les clés autorisées GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) depuis /etc/default/grub de la sauvegarde si leurs valeurs diffèrent de la cible."
+ },
+ {
+ "phase": "1b — systemd-boot / ZFS",
+ "detail": "Pour systemd-boot (souvent ZFS à la racine). _rs_hyd_kernel_cmdline fusionne les paramètres utilisateur de cmdline_extra dans /etc/kernel/cmdline de la cible tout en préservant ses paramètres de démarrage root=, boot= et rootflags=."
+ },
+ {
+ "phase": "2 — Fusion /etc/modules",
+ "detail": "_rs_hyd_modules ajoute des modules de manifest.kernel_params.modules_loaded_at_boot qui sont dans la liste blanche (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) ET n'est pas déjà présent dans la cible /etc/modules."
+ },
+ {
+ "phase": "3 — Copie des fichiers figurant sur la liste blanche",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d, et la règle de liaison ProxMenux VFIO + règles nvidia udev sous /etc/udev/rules.d. Les fichiers appartenant à des Distro (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 se propage via plan.env vers apply_pending_restore.sh, ce qui force NEEDS_INITRAMFS=1 et NEEDS_GRUB=1 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 _rs_apply_bk_older_hydration en mode plan : il calcule exactement ce qui serait fusionné, peuple RS_HYDRATION_SUMMARY 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 commit — 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 intel_iommu=on iommu=pt dans la ligne cmd, le vfio/vfio_pci/vfio_iommu_type1 dans le /etc/modules, un /etc/modprobe.d/vfio.conf avec le options vfio-pci ids=10de:2216 et un /etc/modprobe.d/blacklist-nvidia.conf. L'hydratation fusionne les jetons cmdline dans le GRUB de la cible ou le noyau cmdline, ajoute les modules vfio au /etc/modules, 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 : GRUB_TIMEOUT=1 et GRUB_DISABLE_OS_PROBER=true. L'hydratation lit les deux clés de la sauvegarde /etc/default/grub, 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 GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Tout ce qui se trouve à l'extérieur de cet ensemble — les crochets initramfs personnalisés sous /etc/initramfs-tools/hooks/, les fichiers non inscrits sur la liste blanche sous /etc/modprobe.d/, 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 /sys, crochets udev) 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": "hb_compat_check dans lib_host_backup_common.sh. Définit HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Liste des chemins de sous-ensembles sécurisés",
+ "location": "hb_unsafe_paths_cross_version dans lib_host_backup_common.sh. Émet path\\treason lignes utilisées à la fois par le filtre CLI et le point de terminaison Web /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Phases d'hydratation",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files dans backup_host.sh. Ordonné par _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Régénération forcée après démarrage",
+ "location": "apply_pending_restore.sh lit HB_HYDRATION_APPLIED de plan.env et force NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Aperçu du Web",
+ "location": "/api/host-backups/restore/prepare dans flask_server.py. Charge la bibliothèque d'aide, exécute _rs_apply_bk_older_hydration 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 kernel_params lu par l’adaptation."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/destinations/borg.json b/web/messages/fr/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..8658819a
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/destinations/borg.json
@@ -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 borg create pour sauvegarder et borg extract 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, hb_ensure_borg résout le binaire à partir de quatre sources dans l'ordre et retourne le premier qui fonctionne :",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Système borg",
+ "detail": "Si l'hôte a déjà borg installé via APT (which borg résout), ce binaire est utilisé."
+ },
+ {
+ "priority": "2",
+ "source": "Cache du répertoire d’état",
+ "detail": "/usr/local/share/proxmenux/borg — conservé d'un téléchargement préalable de GitHub sur cet hôte."
+ },
+ {
+ "priority": "3",
+ "source": "Paquet AppImage du moniteur",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — le AppImage regroupe un borg-linux64 signé. C'est le chemin hors ligne sécurisé : un hôte sans internet a toujours un borg fonctionnant."
+ },
+ {
+ "priority": "4",
+ "source": "Téléchargement GitHub",
+ "detail": "wget contre l'URL borg-linux64 épinglée sous github.com/borgbackup/borg/releases/, vérifiée contre une constante SHA-256 dans lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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 remote 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 /usr/bin/borg",
+ "detail": "La ligne command=\"/usr/bin/borg serve ...\" écrite par ProxMenux dans authorized_keys utilise ce chemin fixe. L’installation APT (apt install borgbackup) y place l’exécutable. Pour un binaire autonome, créez un lien symbolique à /usr/bin/borg."
+ },
+ {
+ "requirement": "Un compte utilisateur dédié (généralement borg)",
+ "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 /backup/borgbackup) doit exister sur le serveur et être la propriété de l'utilisateur borg."
+ },
+ {
+ "requirement": "SSH démon acceptant l'utilisateur borg",
+ "detail": "PubkeyAuthentication yes (par défaut). L'authentification par mot de passe n'est nécessaire que pour le flux generate-auto, 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, generate-auto installe la clé via un compte pouvant écrire dans authorized_keys de l’utilisateur borg. Les sauvegardes suivantes utilisent cette clé, limitée à borg serve 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 borg serve. Cet utilisateur s'appelle généralement borg, 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, le port 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 ~/.ssh/borg_proxmenux_HOST_ed25519, puis utilise sshpass pour tester la connexion et installer la clé publique dans ~borg/.ssh/authorized_keys. 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 authorized_keys 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 pct exec de l'hôte PVE — root sur l'hôte PVE écrit dans le LXC de ~borg/.ssh/authorized_keys sans avoir besoin de SSH dans le LXC lui-même."
+ },
+ {
+ "mode": "existing",
+ "label": "Utiliser une clé existante",
+ "detail": "ProxMenux recherche dans /root/.ssh/ et $HOME/.ssh/ 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 ~/.ssh/id_rsa ou un agent SSH)."
+ }
+ ],
+ "restrictTitle": "La ligne authorized_keys",
+ "restrictBody": "Pour chaque clé générée, la ligne authorized_keys é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 command= force chaque session SSH en utilisant cette clé pour exécuter seulement la commande borg-serve; restrict 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 : NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. hb_collect_borg_configs 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 (chmod 600). 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 hb_borg_init_if_needed: le borg repo-create -e MODE moderne quand disponible, ou le borg init --encryption=MODE hérité. ProxMenux expose deux modes : repokey (par défaut) et none. En mode repokey 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 borg-pass-NAME.txt 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 borg. 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é. Quand une destination est ajoutée avec un port non standard, ProxMenux ajoute aussi -p PORT ; les destinations enregistrées, les tâches planifiées et le Monitor utilisent plutôt le port de l’URL ssh://. Sans clé personnalisée, et pour une nouvelle destination 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 repokey. N'apparaît jamais dans la liste des arguments du processus."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Utilisé par hb_borg_init_if_needed lors de l'initialisation d'un dépôt qui n'existe pas encore. Ignoré par borg create 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, run_scheduled_backup.sh exécute borg prune contre le dépôt après chaque sauvegarde réussie avec les valeurs de conservation configurées sur le travail (--keep-last, --keep-daily, --keep-weekly). 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 borg list REPO et extrait celui sélectionné avec borg extract REPO::ARCHIVE-NAME dans un répertoire de mise en scène que _rs_check_layout 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 Comment ça marche."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/destinations/index.json b/web/messages/fr/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..ff0d8970
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — mais les trois partagent la même étape de préparation temporaire (hb_prepare_staging) 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 .tar.zst (ou .tar.gz si zstd est absent).",
+ "pbs": "Sauvegarde PBS (blocs .pxar 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 tar --zstd. 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 KEEP_LAST. 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Les sauvegardes interactives ne font pas de purge.",
+ "borg": "Appliquée par tâche programmée via borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (présent sur Proxmox par défaut).",
+ "pbs": "Paquet proxmox-backup-client (fourni avec Proxmox VE 8+).",
+ "borg": "borg 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 proxmox-backup-client, les identifiants PBS et le fichier de clé (si la sauvegarde est chiffrée).",
+ "borg": "Nécessite borg + 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 rootfs/ + metadata/ + manifest.json décrite dans Comment ça marche est présente. Un .tar.zst extrait d'une archive locale, un .pxar restauré de PBS et une archive Borg extraite de borg extract donnent tous un arbre de répertoire identique. Le chemin du code de restauration (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/destinations/local.json b/web/messages/fr/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..0a89acf8
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst (ou .tar.gz lorsque zstd est absent). Le fichier contient l'arborescence entière de l'archive — manifest.json, metadata/ et rootfs/ — et peut être restauré sur n'importe quel hôte Proxmox avec le flux de restauration ProxMenux ou extrait manuellement avec tar --zstd -xf 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 unique répertoire cible enregistré durablement — pas une liste. ProxMenux stocke le choix de l'opérateur chez /usr/local/share/proxmenux/local-target.conf et le lit sur chaque sauvegarde. Lorsqu'aucune cible n'a été configurée, le HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump par défaut est utilisé (le même répertoire que Proxmox utilise pour ses propres sorties vzdump). La cible est configurée à partir de Configurer les destinations de sauvegarde → Destinations locales:",
+ "options": [
+ "Utilisez par défaut (/var/lib/vz/dump). 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.",
+ "Entrez un chemin personnalisé. Tout chemin absolu du système de fichiers peut être utilisé : un montage NFS, un partage SMB monté via fstab, 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.",
+ "Choisissez un lecteur USB. 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 lsblk. 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 hb_mount_usb_partition : crée /mnt/backup-LABEL (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 saisir le chemin exact du périphérique (par exemple /dev/sdb) 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, _bk_local vérifie que le répertoire de destination n'est pas un sous-chemin d'un répertoire en cours de sauvegarde. Une erreur courante consisterait à ajouter /root au profil et à choisir /root/backups 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 readlink -m, 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 tar --zstd -cf — un pipeline à commande unique qui compresse au niveau par défaut de zstd. Lorsque zstd n'est pas présent sur la source (rare sur Proxmox mais possible sur des installations minimales), ProxMenux revient à gzip. Dans le chemin de repli, si pv 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 pv, tar -czf est utilisé en silence.",
+ "sourceTitle": "Ce qui va dans l'archive",
+ "sourceBody": "La commande tar est appelée avec -C \"$staging_root\" ., ce qui archive toute la racine du répertoire temporaire : rootfs/, metadata/ et manifest.json. 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 : HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, écrit à côté de l'archive par hb_write_archive_sidecar. 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é (kind), l'ID de travail pour les opérations programmées, le mode de profil utilisé (default ou custom), 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 *.proxmenux.json — pas pour les fichiers *.tar.zst — parce qu'un .tar.zst 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 _rs_check_layout, 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, tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg donne le même arbre que le code de restauration consommé."
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/destinations/pbs.json b/web/messages/fr/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..ef0daf61
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client — 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 .pxar, --backup-id, 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 host/hostcfg-HOSTNAME/BACKUP-TIME. Les données sont une archive .pxar contenant la même structure en trois blocs que celle décrite dans Fonctionnement. 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, run_scheduled_backup.sh lance proxmox-backup-client prune avec --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET et HB_PBS_FINGERPRINT 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 pbs: 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 Configurer les destinations de sauvegarde → PBS destinations → Ajouter PBS. Prompts pour un nom, nom d'utilisateur (root@pam ou user@pbs!token), 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 ([proxmox] ou [manual]). Les entrées dont le mot de passe n'a pas pu être résolu sont marquées d'un avertissement ⚠ no password – 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 à proxmox-backup-client via la variable d'environnement PBS_FINGERPRINT; 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 à proxmox-backup-client backup. ProxMenux utilise env 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 hostcfg-HOSTNAME. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de [A-Za-z0-9_-] et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un groupe. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
+ "pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
+ "pxarBody": "La source .pxar est la totalité du staging_root — rootfs/, metadata/ et manifest.json ensemble. Les versions antérieures ont passé le $staging_root/rootfs comme source; cela a laissé le metadata/ hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-_rs_check_layout de 3, qui enveloppe un arbre plat etc/var/root/usr dans une hiérarchie rootfs/."
+ },
+ "encryption": {
+ "heading": "Chiffrement côté client",
+ "glossaryHint": "Cette section emploie les termes fichier clé, phrase secrète et enveloppe de récupération. Le glossaire 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 /usr/local/share/proxmenux/pbs-key.conf 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 : Non poursuit sans chiffrement, Oui passe à la deuxième étape. Celle-ci dépend de la présence d’un fichier clé dans /usr/local/share/proxmenux/pbs-key.conf. 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. Générer un nouveau fichier clé exécute proxmox-backup-client key create --kdf none. Utiliser un fichier clé existant 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 /etc/pve/priv/storage/<NAME>.enc, 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 chmod 600.",
+ "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 Utiliser un fichier clé existant. 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, Déposer la clé sur PBS ?, avec deux réponses. Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui. Le choix par défaut est Non, conserver uniquement en local : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton Télécharger le fichier clé du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir Oui, envoyer demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant pbs-key.recovery.enc. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
+ "blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
+ "blobUploadBody1": "Lorsque le mode de dépôt est Oui, envoyer, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe -keyrecovery. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. L’enveloppe ne quitte jamais l’hôte en clair : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS ne reçoit que l’enveloppe déjà chiffrée.",
+ "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 à proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe -keyrecovery existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie wrong key — manifest's key XX does not match provided key YY. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
+ "monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
+ "monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : Télécharger exporte le fichier actuel vers le navigateur ; Envoyer remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; Supprimer retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour Déposer la clé sur PBS ?, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
+ },
+ "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 proxmox-backup-client restore avec le même dépôt, mot de passe et empreinte, ainsi que --keyfile si elle est chiffrée. L’archive .pxar est extraite dans un répertoire de préparation que _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/glossary.json b/web/messages/fr/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..f99080d9
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/glossary.json
@@ -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’enveloppe de récupération. 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é. Ce n'est pas la phrase de passe qui déverrouille le fichier clé lui-même, 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 blocs avant leur envoi à PBS. Sans la clé correspondante, les données chiffrées sont illisibles. ProxMenux le stocke dans /usr/local/share/proxmenux/pbs-key.conf avec le mode 600. Protégez-le : l’enveloppe de récupération 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 phrase de passe de récupération. Il n'existe que lorsque le fichier clé a été créé avec --kdf scrypt (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 keyfile enveloppé dans une couche supplémentaire: il est crypté avec la phrase de passe de récupération utilisant AES-256-CBC et PBKDF2 avant de quitter l'hôte. C'est ce qui est téléchargé sur PBS en tant que groupe -keyrecovery. 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’enveloppe de récupération sur le dessus."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Option de proxmox-backup-client key create 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 proxmox-backup-client key create qui produit un fichier clé protégé par une phrase de passe du fichier de clé. 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 openssl enc -aes-256-cbc pour protéger le fichier de clé avec la phrase de passe de récupération et produire l’enveloppe."
+ },
+ {
+ "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 rsync selon le profil par défaut et les chemins personnalisés. 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 Comment ça marche."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Chemins personnalisés",
+ "def": "Les chemins supplémentaires que l'utilisateur ajoute au dessus du profil par défaut. Soit persistante (conservée en backup-extra-paths.txt) 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 + datastore + utilisateur qui reçoit la sauvegarde. Identifié par la chaîne user@realm@host:datastore. 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 à proxmox-backup-client via la variable d'environnement PBS_FINGERPRINT."
+ },
+ {
+ "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 -keyrecovery pour l’enveloppe de récupération."
+ },
+ {
+ "id": "backup-id",
+ "term": "ID de sauvegarde",
+ "def": "Nom du groupe backup. ProxMenux par défaut sur hostcfg-HOSTNAME 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 run_scheduled_backup.sh 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 à /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Mode rattaché",
+ "def": "Tâche sans timer propre. Un hook job-end de PVE vzdump la déclenche après les sauvegardes des invités si le stockage correspond. La tâche parent fournit la destination et la conservation, relue depuis la tâche parent à chaque exécution, 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 indépendant emploi programmé; mode rattaché 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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 hydration 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 key. La restauration d'une sauvegarde chiffrée nécessite d'abord la récupération du fichier clé à partir de l’enveloppe stockée sur PBS, en utilisant la phrase de passe de récupération."
+ }
+ ]
+ }
+ ],
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/how-it-works.json b/web/messages/fr/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..aba3a5f8
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/how-it-works.json
@@ -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 (.tar.zst local, sauvegarde PBS ou archive Borg) conserve cette structure. La restauration utilise les trois : le manifeste est consulté avant toute modification pour détecter les différences et déterminer les exclusions ; rootfs fournit les fichiers de configuration, appliqués à chaud ou après redémarrage ; l’inventaire des applications 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 metadata/ détient les charges utiles structurées; le sous-répertoire rootfs/ 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 rootfs/ est une simple copie du système de fichiers, créée par rsync depuis l’hôte source. Elle contient un profil par défaut sélectionnant les chemins nécessaires à une restauration Proxmox, ainsi que les chemins personnalisés ajoutés à la tâche ou à la session interactive. La sélection est volontairement limitée aux chemins qui contiennent de la configuration ou conservent un état que Proxmox ne peut pas recréer seul.",
+ "defaultProfileTitle": "Le profil par défaut",
+ "defaultProfileBody": "Le profil par défaut est défini par hb_default_profile_paths dans lib_host_backup_common.sh. 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 (config.db) est capturée comme un instantané cohérent via sqlite3 .backup sans arrêter le cluster, et les sidecars .db-wal / .db-shm sont exclus du rsync. Lorsque sqlite3 n'est pas disponible, un fichier config.db.raw-fallback 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 .link dans /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. Les chemins volatils (.bash_history, .cache/, tmp/, .local/share/Trash/) sont exclus de la copie. /var/lib/proxmenux 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 zpool.cache et hostid."
+ }
+ ],
+ "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 à /usr/local/share/proxmenux/backup-extra-paths.txt 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 Default, 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 # sont autorisés.",
+ "customModeTitle": "2. Mode personnalisé (par exécution)",
+ "customModeBody": "Lancer une sauvegarde en mode Custom 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 [+] et pré-cochés). L'utilisateur coche ou désactive les entrées pour cette exécution spécifique, et peut également appuyer sur Ajouter un chemin personnalisé 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 metadata/missing_paths.txt à 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 /etc/wireguard ou /etc/prometheus lorsque ces outils ne sont pas installés."
+ },
+ "manifest": {
+ "heading": "La partie manifeste",
+ "intro": "manifest.json est un document structuré JSON qui décrit l'hôte source au moment de la sauvegarde. Il est produit par six modules de collecte indépendants orchestrés par build_manifest.sh. 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 (pveversion), version PBS si l'hôte exécute le rôle de serveur de sauvegarde, noyau (uname -r), 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 lsusb/lspci ; interfaces réseau avec MAC, emplacement PCI et appartenance à un pont ; périphériques sans fil. Les entrées GPU comprennent l’heuristique passthrough_eligible."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "ZFS pools (avec pool type + disques membres résolus à /dev/disk/by-id/*, /dev/disk/by-partuuid/* ou crus /dev/sdX 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 storage.cfg entrées, montages externes."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Paramètres ajoutés par l’opérateur dans /proc/cmdline, sans les éléments standard comme BOOT_IMAGE=, root=, ro/rw, quiet et splash ; modules chargés au démarrage depuis /etc/modules ; chemins des fichiers /etc/modprobe.d/*.conf contenant des directives effectives (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Lire /usr/local/share/proxmenux/managed_installs.json (enregistrement de tout ce que ProxMenux a installé) et installed_tools.json. Chaque entrée conserve le chemin d'installation (menu_script) 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 (qm list) et les LXC (pct list) 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 vzdump / PBS."
+ }
+ ],
+ "schemaTitle": "Validation du schéma",
+ "schemaBody": "Le manifeste valide contre scripts/backup_restore/schema/manifest.schema.json. L'exécution du build_manifest.sh --validate déclenche une validation de schéma côté Python JSON (exige python3 + jsonschema). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
+ },
+ "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 metadata/ 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 apt-mark showmanual, avec les paquets APT explicitement installés 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, _rs_run_complete_extras lit la liste et applique un filtre contre les suppressions en cascade en trois passes : dpkg -s repère les paquets déjà installés, la détection des autres versions majeures vise les bibliothèques, et apt-get install --simulate vérifie le risque de suppression en cascade. Les paquets retenus sont installés avec apt-get install -y.",
+ "componentsTitle": "components_status.json (dans rootfs)",
+ "componentsBody": "Un registre JSON sous /usr/local/share/proxmenux/ qui enregistre chaque composant ProxMenux a installé avec son état exact : version, drapeaux spécifiques ProxMenux (pour NVIDIA : patched booléen ; pour Coral : DKMS version). Ce fichier vit à l'intérieur des rootfs — pas dans metadata/ — parce que c'est lu après la copie de rootfs vers la cible. Le répartiteur post-démarrage (apply_cluster_postboot.sh) itère ses entrées et exécute le crochet --auto-reinstall 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 --auto-reinstall :",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Lire version + patched. 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 .deb 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 packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check. 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 HB_COMPAT_KERNEL_DIRECTION (same, bk_newer ou bk_older) et peuple RS_SKIP_PATHS 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": "_rs_apply … hot copie les entrées de hb_classify_path=hot directement à la cible en direct. Tout ce qui est sous /etc/pve, /etc/network ou des chemins classés comme reboot/dangerous est reporté."
+ },
+ {
+ "stage": "3",
+ "name": "En attente de préparation",
+ "reads": "rootfs/ (redémarrage + chemins dangereux)",
+ "action": "_rs_prepare_pending_restore prépare les chemins à risque dans /var/lib/proxmenux/pending-restore/, écrit plan.env, apply-on-boot.list et rs-skip-paths.txt, puis active proxmenux-restore-onboot.service pour le prochain démarrage."
+ },
+ {
+ "stage": "3b",
+ "name": "Importation des pools de données",
+ "reads": "manifest.storage_inventory + état ZFS de la destination",
+ "action": "_rs_import_data_pools 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 zpool import -f. Si un disque manque, le pool est ignoré avec un avertissement. Le résultat par pool est enregistré dans /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "stage": "4",
+ "name": "Installation du paquet",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras exécute le filtre sans risque de cascade et appelle apt-get install -y avec la liste des paquets survivants. La sortie complète va à /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Après le démarrage",
+ "reads": "rootfs (déjà appliqué) + components_status.json",
+ "action": "Après le redémarrage, apply_pending_restore.sh rejoue les chemins différés et apply_cluster_postboot.sh exécute update-initramfs, update-grub (ou proxmox-boot-tool refresh) et itère sur components_status.json en tirant le crochet --auto-reinstall de chaque composant."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Pourquoi séparer la sauvegarde en trois parties",
+ "body": "La séparation suit le cycle de vie des données. Le système de fichiers est transféré avec rsync : rapidement, de façon transparente et atomique par fichier. L’état de configuration à interpréter avant toute modification est du JSON structuré, lisible indépendamment, versionnable par schéma et comparable automatiquement à l’état de la destination. Les logiciels à réinstaller sont décrits dans un inventaire 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."
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/index.json b/web/messages/fr/docs/backup-restore/index.json
new file mode 100644
index 00000000..2b40cfc2
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/index.json
@@ -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 : le système de fichiers, avec les répertoires pertinents sous /etc, /root et /var/lib/pve-cluster, ainsi que les chemins personnalisés facultatifs ; un manifeste structuré 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 un inventaire des applications, 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 de l’hôte : l’installation Proxmox elle-même, et non les applications ou systèmes invités qui y fonctionnent.",
+ "items": [
+ "Ce n’est pas un outil de sauvegarde des VM/CT. Cette fonction ne capture ni les disques ni l’état de la RAM des invités ; c’est le rôle de vzdump. Les fichiers de configuration des invités (/etc/pve/nodes/<node>/qemu-server/*.conf et lxc/*.conf) sont bien 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.",
+ "Ce n’est pas une opération à l’échelle du cluster. Chaque nœud se sauvegarde lui-même. L’appartenance au cluster est enregistrée dans /etc/pve 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.",
+ "Ce n’est pas une image complète du disque. 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 update-initramfs 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 noyau actuel de la cible, 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'hydratation 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 Comment ça marche si l'objectif est de comprendre ce que contient l'archive et pourquoi. Accédez à Destinations pour configurer la cible de la copie. Lisez Restauration et Restauration inter-noyaux 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/restoring.json b/web/messages/fr/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..fcd555cf
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Restaurer une sauvegarde — flux complets et personnalisés ProxMenux",
+ "description": "Le processus complet de restauration : consulter, télécharger ou restaurer une sauvegarde, vérifier la compatibilité, choisir le mode complet ou personnalisé, classer les chemins appliqués à chaud ou après redémarrage, puis réinstaller les composants après le démarrage.",
+ "ogTitle": "Sauvegarde ProxMenux — restauration",
+ "ogDescription": "Restauration complète ou personnalisée avec contrôle de compatibilité, classification des chemins, traitement au démarrage et réinstallation après démarrage.",
+ "twitterTitle": "Restaurer une sauvegarde ProxMenux",
+ "twitterDescription": "Comment une sauvegarde d'hôte ProxMenux est transformée en un hôte Proxmox fonctionnant."
+ },
+ "header": {
+ "title": "Restaurer une sauvegarde",
+ "description": "Le workflow complet de restauration : de la sélection d'une archive à un hôte de travail. Documente la vérification de compatibilité, les deux modes de restauration, le répartiteur sur le démarrage, le passe de réinstallation post-démarrage, et les mécanismes qui rendent prévisible la restauration cross-host et cross-kernel.",
+ "section": "Sauvegarde et restauration"
+ },
+ "intro": {
+ "title": "La restauration reproduit la source, pas seulement les fichiers",
+ "body": "Restaurer une sauvegarde ProxMenux va au-delà de l’extraction des fichiers. Avant les modifications, la restauration consulte le manifeste pour détecter les différences, écarte les chemins pouvant compromettre le démarrage et adapte les réglages de l’utilisateur qui ne peuvent pas être copiés tels quels. Après le redémarrage nécessaire, elle tente de réinstaller les composants pris en charge enregistrés (pilote NVIDIA, Coral TPU, outils GPU) pour le noyau actif de la destination. Une seule archive pilote le contrôle de compatibilité, la classification des chemins et les traitements au démarrage puis après démarrage. Consultez les résultats par composant et les journaux pour vérifier le résultat."
+ },
+ "threeActions": {
+ "heading": "Trois actions sur une sauvegarde",
+ "intro": "La sélection d'une sauvegarde dans la liste ouvre un menu avec trois actions.",
+ "actionRows": [
+ {
+ "action": "Affichage",
+ "detail": "Ouvre une vue en lecture seule de l'archive : le contenu de manifest.json (nom d'hôte source, version PVE, noyau, matériel, composants installés), la liste des chemins à l'intérieur de rootfs/, et un diff de ce qui changerait sur l'hôte actuel si la sauvegarde était appliquée."
+ },
+ {
+ "action": "Télécharger",
+ "detail": "Exporte l'archive comme un fichier portable .tar.zst (tar compressé avec zstd). Il peut être extrait sur n'importe quel système Linux avec tar --zstd -xf FILE.tar.zst, ou sur macOS/Windows avec n'importe quel outil qui supporte zstd (7-Zip, PeaZip, Keka...). L'arbre extrait contient manifest.json, metadata/ et rootfs/ — exactement la même disposition que la restauration consomme. Utile pour une inspection hors ligne ou pour la restauration sur un hôte sans accès à la destination originale (PBS, Borg)."
+ },
+ {
+ "action": "Restaurer",
+ "detail": "Le chemin de l'écriture. Extrait l'archive dans un répertoire de mise en scène, effectue la vérification de compatibilité et présente le mode de sélection (complète ou personnalisée)."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Le contrôle de compatibilité",
+ "intro": "Avant d'écrire un fichier, hb_compat_check compare l'état décrit dans le manifeste avec l'hôte cible. La vérification fonctionne en lecture seule et produit quatre sorties indépendantes qui conduisent le reste de la restauration.",
+ "outputRows": [
+ {
+ "output": "Drapeau de direction",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION vaut same, bk_newer ou bk_older selon la comparaison des versions majeures du noyau de la sauvegarde et de la destination. Il pilote le filtre de chemins compatibles entre noyaux, actif uniquement pour bk_older, et l’adaptation des réglages décrite sur la page correspondante."
+ },
+ {
+ "output": "Liste des chemins exclus",
+ "detail": "RS_SKIP_PATHS — chaque chemin de restauration ne doit PAS s'appliquer. Populé par deux mécanismes : la dérive matérielle (manque de NIC, défaut d'identification de stockage, pool étranger ZFS) et — lorsque la direction est bk_older — la liste des sentiers dangereux à travers le noyau."
+ },
+ {
+ "output": "Plan de réaffectation des interfaces réseau",
+ "detail": "Lorsqu'un NIC sur la cible a le même MAC que celui sur la source mais un nom différent (typique après un swap de carte mère), la vérification de compatibilité enregistre un plan de renommer (HB_NIC_REMAP) qui réécrirea /etc/network/interfaces pendant la restauration."
+ },
+ {
+ "output": "Plan de restauration",
+ "detail": "Calculé par compute_rollback_plan.sh. Liste les VM, LXC et composants présents sur la destination mais absents de la sauvegarde. Le dialogue propose de supprimer les invités supplémentaires avant redémarrage. La suppression des composants reste manuelle et celle des invités peut échouer ; une correspondance exacte n’est donc pas garantie."
+ }
+ ],
+ "reportBody": "Le contrôle émet également un rapport structuré (HB_COMPAT_RESULTS) classé PASS / INFO / WARN / FAIL. Les entrées WARN et FAIL sont présentes dans le panneau pré-restauration ; la restauration refuse de procéder seulement lorsqu'une FAIL est présente et que l'utilisateur ne peut pas résoudre en cliquant sur Continuer."
+ },
+ "twoModes": {
+ "heading": "Restauration complète vs restauration personnalisée",
+ "intro": "Après le contrôle de compatibilité, le menu de mode apparaît. Le choix détermine ce qui est appliqué, pas comment : les deux modes utilisent le même processus.",
+ "modeRows": [
+ {
+ "mode": "Restauration complète",
+ "detail": "Applique tous les chemins de l'archive qui survivent à la dérive et aux filtres de cross-kernel. Exécute également l'installation du paquet et le passe de réinstallation automatique du composant. C'est le choix par défaut et le choix recommandé — le but est de reproduire la source, pas de choisir des morceaux."
+ },
+ {
+ "mode": "Restauration personnalisée",
+ "detail": "Ouvre une liste de contrôle montrant chaque chemin que porte l'archive. L'utilisateur coche un sous-ensemble. Les chemins bloqués par le filtre croisé apparaissent grisés et ne peuvent être sélectionnés. L'installation du paquet et l'auto-réinstallation du composant sont ignorées par défaut en mode Custom — l'utilisateur indique qu'il veut une application partielle, pas une reproduction complète."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Comment les chemins sont classés",
+ "intro": "Chaque chemin sélectionné pour la restauration est classé par hb_classify_path dans l'une des trois catégories. La catégorie détermine quand le chemin est appliqué au système et pourquoi.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Voies appliquées immédiatement au système d'exécution. Le service qui les consomme ramasse le changement seul ou au prochain rechargement — aucun redémarrage n'est nécessaire. Ce sont l'essentiel d'une sauvegarde: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, fichiers de configuration de service général, etc."
+ },
+ {
+ "class": "reboot",
+ "detail": "Chemins reportés au prochain démarrage, au lieu d’être appliqués immédiatement par ce processus. Ils concernent la configuration de démarrage : la génération du chargeur lit /etc/default/grub, les montages utilisent /etc/fstab et le chargement des modules utilise /etc/modules. Les fichiers en attente sont appliqués après redémarrage, puis les éléments de démarrage nécessaires sont régénérés. Exemples : /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Chemins NON appliqués sur le système en cours d’exécution : une écriture à chaud pourrait corrompre l’état ou couper la connexion active. Ils sont placés dans l’ensemble en attente : /etc/network est écrit tôt au démarrage suivant, avant le démarrage du réseau, et /etc/pve est écrit par le répartiteur post-démarrage une fois le système de fichiers du cluster disponible. Exemples : /etc/pve (pmxcfs est un montage FUSE contenant la configuration active du cluster), /var/lib/pve-cluster (données actives du cluster, conservées dans le répertoire de récupération pour une récupération manuelle uniquement), /etc/network (pourrait reconfigurer l’interface même par laquelle l’utilisateur est connecté en SSH et couper la session)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "Le workflow complet de restauration",
+ "intro": "Le pipeline complet de la sélection des archives à un hôte opérationnel restauré. Chaque étape alimente la suivante; l'état écrit par les étapes précédentes est consommé par les suivantes.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "Mécanisme de restauration différée",
+ "intro": "Les chemins classés comme reboot ou dangerous, et l'hydratation écrit, sont mis en scène pour le prochain démarrage au lieu d'être appliqués en direct. Cela se fait par le biais d'un petit ensemble autonome de fichiers sous /var/lib/proxmenux/pending-restore/ :",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "Un chemin relatif par ligne : les chemins exacts que apply_pending_restore.sh appliquera depuis rootfs préparé. Le fichier permet de voir les changements prévus au prochain démarrage."
+ },
+ {
+ "file": "plan.env",
+ "content": "Variables d’environnement chargées par le script de démarrage : identifiant de restauration, indicateurs de compatibilité (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), accord pour le rollback et options du cluster."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "La liste finale RS_SKIP_PATHS, enregistrée pour que apply_pending_restore.sh conserve après redémarrage les exclusions calculées lors de l’étape interactive. Elle empêche de restaurer au démarrage les chemins incompatibles avec le matériel ou le noyau."
+ },
+ {
+ "file": "rootfs/",
+ "content": "Les fichiers mis en scène eux-mêmes — les octets exacts qui seront établis. Conservé sur le même système de fichiers que / de sorte que le rsync on-boot est rapide et ne dépend pas du stockage externe encore accessible au démarrage."
+ }
+ ],
+ "unitBody": "L’unité systemd proxmenux-restore-onboot.service est activée à la fin de l’étape interactive. Ce service ponctuel démarre tôt au prochain démarrage, appelle apply_pending_restore.sh puis se désactive. La condition ConditionPathExists=/var/lib/proxmenux/pending-restore/state empêche toute exécution lorsqu’aucune restauration n’est en attente."
+ },
+ "postbootDispatcher": {
+ "heading": "Le répartiteur après démarrage — apply_cluster_postboot.sh",
+ "intro": "Où l'étape interactive se termine et où se produit la reproduction réelle de l'hôte. apply_cluster_postboot.sh est installé sous la forme d'une seconde unité systemd (proxmenux-apply-cluster-postboot.service) dont les cibles After=/Wants= s'assurent qu'elle ne fonctionne qu'après la mise en place du pve-cluster et de network-online. C'est là que les actions de restauration visible de l'hôte atterrissent.",
+ "tasks": [
+ {
+ "task": "Appliquer /etc/pve",
+ "detail": "/etc/pve est un montage en direct pmxcfs FUSE — il ne peut pas être écrit sur le démarrage précoce. Le répartiteur copie les fichiers des rootfs en attente vers le /etc/pve en direct une fois le système de fichiers cluster mis en place, un fichier à la fois, sans redémarrer pve-cluster. Le /var/lib/pve-cluster/config.db capturé de la sauvegarde (ou le config.db.raw-fallback) promu est matérialisé avec le systemctl stop pve-cluster → copie de fichier atomique → modèle systemctl start pve-cluster, de sorte que pmxcfs relise l'état restauré sur le chemin du retour."
+ },
+ {
+ "task": "Reconstruction initramfs et bootloader",
+ "detail": "Exécute update-initramfs -u -k all dans chaque noyau installé, puis soit update-grub (installations GRUB) soit proxmox-boot-tool refresh (installations systemd-boot / ZFS). Passé si l'étape interactive n'a rien déterminé dans les chemins qui affectent ces outils."
+ },
+ {
+ "task": "Réinstallation automatique du composant",
+ "detail": "Lit components_status.json restauré et parcourt les installateurs pris en charge (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Chacun est lancé en mode --auto-reinstall, lit l’état enregistré et réinstalle pour l’environnement de destination, en recompilant les modules si nécessaire. L’opération attend le redémarrage pour utiliser le noyau alors actif. Les échecs individuels sont enregistrés sans arrêter le composant suivant."
+ },
+ {
+ "task": "Vérification du démarrage",
+ "detail": "Avant de lancer la notification d'achèvement, vérifie que proxmox-boot-tool status affiche un ESP configuré, chaque /boot/vmlinuz-* possède un répertoire /lib/modules/<ver> correspondant, et /vmlinuz résout. Toute incohérence apparaît dans la notification au lieu d'être cachée."
+ },
+ {
+ "task": "Avis d'achèvement",
+ "detail": "Envoie l'événement Host restore finished via hb_notify_lifecycle. Comprend la durée totale, le nombre de chemins appliqués, les avertissements de vérification de la santé, le cas échéant, et un lien vers le journal à /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Si les notifications ne sont pas configurées, l'événement est silencieux — le journal enregistre toujours tout."
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Progrès en direct dans l'onglet Sauvegardes du moniteur",
+ "body": "Après le redémarrage, l’onglet Sauvegardes de ProxMenux Monitor affiche une carte de progression reflétant l’état de proxmenux-apply-cluster-postboot.service. Elle lit /var/lib/proxmenux/restore-state.json, mis à jour à chaque étape : configuration du cluster, initramfs, chargeur de démarrage, réinstallation de chaque composant, contrôle du démarrage et finalisation.",
+ "fields": [
+ {
+ "name": "Insigne d'état",
+ "detail": "Un des Restaurer en cours, Restaurer complet ou Restaurer échoué. La carte permet de vérifier le fichier d'état toutes les 2 secondes en cours d'exécution et toutes les 30 secondes après la fin."
+ },
+ {
+ "name": "Barre de progression + compteur de pas",
+ "detail": "Affiche N/M steps avec l'étiquette de l'étape actuelle. Pendant que la restauration exécute un temps estimé est dérivé des étapes terminées et du temps écoulé."
+ },
+ {
+ "name": "Liste des composants",
+ "detail": "Une ligne par pilote étant réinstallée (NVIDIA, outils Intel GPU, outils AMD, Coral TPU) avec installing / ok / failed plus un lien vers le journal par composant à /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Importation des pools de données",
+ "detail": "Le bloc data_pools_import montre cinq lignes colorées : Importés, Forcés (avec -f pour un hostid étranger), Ignorés, disques partiels (seuls certains disques sont présents), Ignorés, disques absents (aucun disque présent) et Échecs. L’état est conservé dans /var/lib/proxmenux/restore-state.json et le journal brut de l’exécution dans /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Avertissements relatifs au bon fonctionnement du démarrage",
+ "detail": "Le traitement vérifie les répertoires /lib/modules/<kernel> manquants, l’absence de configuration ESP et les liens symboliques /vmlinuz pointant vers une cible absente. Les avertissements apparaissent ici dans une bannière colorée."
+ },
+ {
+ "name": "Delta de restauration",
+ "detail": "Listes VMs, LXCs et composants qui existent sur la cible mais n'étaient pas dans la sauvegarde restaurée — les mêmes entrées sont apparues dans la boîte de dialogue de rappel destructive pré-restauration. Chaque ligne porte la commande de nettoyage manuel."
+ },
+ {
+ "name": "Fin du journal",
+ "detail": "Les dernières lignes 600 de proxmenux-cluster-postboot-<ts>.log, avec un filtre Problèmes uniquement qui maintient juste des lignes correspondant à error, warning, failed, ✗ ou traceback."
+ }
+ ],
+ "dismissBody": "Une fois la restauration terminée ou en échec, le bouton Masquer replie la carte. Le fichier d’état est conservé ; Historique rouvre cette restauration et les précédentes. Les 20 dernières exécutions sont archivées dans /var/lib/proxmenux/restore-history/.",
+ "imageAlt": "Fenêtre Détails du suivi de restauration dans ProxMenux Monitor pendant l’exécution : badge bleu, étape « Reconstruction initramfs », temps restant estimé, barre partiellement remplie et dernières lignes du journal en direct.",
+ "imageCaption": "Le mode Détails pendant que le répartiteur post-démarrage est toujours en marche — badge, étape actuelle, temps restant et queue de log en direct.",
+ "detailsImageAlt": "Le même détail modal après la restauration a terminé, avec le badge vert Restore complet, la durée totale d'exécution (0m53s), une barre de progression 6/6, le delta Rollback vide et le journal de post-démarrage archivé.",
+ "detailsImageCaption": "Le même modal une fois la exécution terminée — badge, durée totale, barre de progression remplie et le journal de post-démarrage archivé."
+ },
+ "postbootExample": {
+ "heading": "A quoi ressemble le post-boot sur la console",
+ "body": "Sur la console physique, un traitement qui se termine sans erreur de processus affiche [ OK ] Finished proxmenux-apply-cluster-postboot.service, souvent près des OK de multi-user.target et graphical.target. Cela marque la fin du processus. Des échecs de composants ou avertissements de démarrage peuvent néanmoins avoir été enregistrés ; vérifiez leurs états et les journaux du moniteur avant de considérer l’hôte comme entièrement restauré.",
+ "imageAlt": "Console physique Proxmox affichant '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', puis OK pour multi-user.target et graphical.target, avec l’invite de connexion au-dessus.",
+ "imageCaption": "Console physique à la fin du processus. 'Finished proxmenux-apply-cluster-postboot.service' marque sa fin, également signalée par 'Host restore finished' dans le moniteur. Les résultats des composants et les avertissements restent à vérifier."
+ },
+ "tenMinutes": {
+ "heading": "Pourquoi les dix dernières minutes comptent",
+ "intro": "Le redémarrage lui-même prend des secondes, mais le répartiteur post-démarrage passe environ dix minutes à terminer la restauration. Pendant cette fenêtre, l'hôte est accessible et la connexion fonctionne, mais certains services (principalement dépendants des pilotes GPU) ne sont pas encore disponibles. Répartition du temps d'un hôte Proxmox typique avec NVIDIA + Coral installé:",
+ "rows": [
+ {
+ "stage": "Boot + pve-cluster prêt",
+ "time": "~30 s",
+ "detail": "Démarrage standard de Proxmox. SSH, interface web et connexion sont disponibles à la fin de cette étape."
+ },
+ {
+ "stage": "Appliquer /etc/pve à pmxcfs",
+ "time": "~10 s",
+ "detail": "Rapide — petits fichiers de configuration copiés un par un dans le système de fichiers cluster live."
+ },
+ {
+ "stage": "Reconstruire les initramfs à travers les noyaux",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all reconstruit une image initramfs par noyau installé. Le gros de l'attente."
+ },
+ {
+ "stage": "Reconstruire la configuration du chargeur de démarrage",
+ "time": "10–30 s",
+ "detail": "update-grub ou proxmox-boot-tool refresh. Rapide même sur ZFS."
+ },
+ {
+ "stage": "Réinstallation du pilote NVIDIA (le cas échéant)",
+ "time": "5–10 min",
+ "detail": "Télécharger la version du pilote enregistrée, compiler les modules DKMS contre le noyau actuel, applique le correctif ProxMenux si la source l'avait. La tâche la plus longue."
+ },
+ {
+ "stage": "Réinstallation de Coral et des autres composants",
+ "time": "3–5 min",
+ "detail": "DKMS compile pour Coral, apt install pour intel-gpu-tools, .deb download + install pour amdgpu_top."
+ },
+ {
+ "stage": "Vérification du démarrage et notification",
+ "time": "~2 s",
+ "detail": "Très rapide. La notification informe l’utilisateur dès la fin de l’exécution."
+ }
+ ],
+ "outroBody": "Pendant cette période, certains outils peuvent manquer après connexion (nvidia-smi introuvable, coral non détecté), car la réinstallation continue en arrière-plan. La notification marque la fin du traitement ; vérifiez résultats des composants, avertissements et journaux pour distinguer succès et échecs individuels."
+ },
+ "destructiveRollback": {
+ "heading": "Le renversement destructeur facultatif",
+ "body": "La restauration est additive par défaut : VM, LXC et composants supplémentaires restent présents. En cas de différences, le dialogue propose Exécuter le rollback destructif ?, avec Non par défaut. Accepter appelle _rs_execute_rollback avant redémarrage pour tenter de supprimer les VM et LXC supplémentaires listés. Les composants sont signalés pour désinstallation manuelle, faute de désinstallation automatique. Les échecs de suppression sont rapportés sans arrêter la suite ; une correspondance exacte n’est pas garantie. Vérifiez noms et VMID/CTID avant ce choix destructif."
+ },
+ "logs": {
+ "heading": "Emplacement des journaux",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Écrit lors de l’étape interactive : résultats de compatibilité, filtre des différences, plan d’adaptation, sorties de l’application à chaud et de la préparation différée, installation des paquets."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Écrit par apply_pending_restore.sh au début du démarrage : chargement de plan.env, parcours de apply-on-boot et filtrage des chemins exclus."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Écrit par apply_cluster_postboot.sh. Contient: pve-cluster appliquer, initramfs et sortie de chargeur d'amorçage, sortie d'installation par composant, vérification de la santé, charge utile de notification."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "Un journal par programme d'installation de composant (nvidia, coral, etc.) exécuté lors de la passe post-démarrage. Utile lorsque la réinstallation d'un composant spécifique a échoué et que l'utilisateur a besoin de la propre sortie de l'outil."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Écrit par _rs_import_data_pools. Contient : le dénombrement de pools non-racines à partir du manifeste, le résultat par pool (importé proprement, importé avec -f pour un hôte étranger, ignoré en raison de disques absents, ou échoué), et la sortie brute de chaque appel zpool import."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Où aller ensuite?",
+ "items": [
+ {
+ "label": "Restauration entre versions du noyau",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": " — le filtre de chemins sûrs tenant compte du sens du changement de noyau et l’adaptation des réglages lorsque le noyau de destination diffère de celui de la sauvegarde."
+ },
+ {
+ "label": "Comment ça marche",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": "— la mise en page des archives, le manifeste et l'inventaire des applications que la restauration consomme."
+ },
+ {
+ "label": "Tâches planifiées",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": "— le flux sans surveillance qui produit les archives que cette page consomme."
+ }
+ ]
+ }
+}
diff --git a/web/messages/fr/docs/backup-restore/scheduled-jobs.json b/web/messages/fr/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..8f8ac95c
--- /dev/null
+++ b/web/messages/fr/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Nouveau travail indépendant — 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.",
+ "Associer à une tâche vzdump PVE existante — 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 même cycle de sauvegarde. À la restauration, les configurations des invités viennent de la sauvegarde hôte (sous /etc/pve) 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 OnCalendar (syntaxe du calendrier systemd — par exemple daily, Mon..Fri 03:00).",
+ "retention": "Demandée séparément: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups de la tâche parente (associée une à une aux variables KEEP_* du script d’exécution via hb_pve_prune_to_keep_env)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Comment fonctionne le mode de fixation",
+ "intro": "PVE écrit les tâches vzdump dans /etc/pve/jobs.cfg, 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 hb_pve_list_vzdump_jobs_for_backend. L'utilisateur en choisit un."
+ },
+ {
+ "step": "2",
+ "detail": "Le .env de l'emploi est écrit avec PVE_PARENT_JOB, PVE_STORAGE et les valeurs de KEEP_* héritées; aucun minuteur systemd n'est créé."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook enregistre un hook dans /etc/vzdump.conf. À la phase job-end de toute tâche vzdump, il compare le $STOREID reçu au PVE_STORAGE 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 : path/dump/ 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 KEEP_* 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 run_scheduled_backup.sh JOB_ID. Le minuteur le planifie avec Persistent=true (exécutions manquées rattrapées au prochain démarrage) et un petit RandomizedDelaySec=120 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 hb_install_vzdump_hook ; compare le PVE_STORAGE de chaque tâche associée au $STOREID 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": [
+ "Prépare la sauvegarde. 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.",
+ "Écrire à la destination. Charge ou écrit l'archive vers la destination configurée — un fichier local .tar.zst, 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.",
+ "Appliquer la rétention. Supprime les anciennes sauvegardes de la destination, en maintenant les nombres keep-last / keep-daily / keep-weekly configurés sur le travail. La purge est effectuée par la destination elle-même: PBS applique sa propre conservation, Borg exécute borg prune, et pour Local ProxMenux supprime les fichiers qui tombent en dehors de la fenêtre keep-last."
+ ]
+ },
+ "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 : systemctl enable/disable --now la minuterie. Attache le mode : retourne le drapeau ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log : 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 hb_notify_lifecycle que le flux interactif (start, complete, fail). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/creating-backups.json b/web/messages/it/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..a7fd47c4
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/creating-backups.json
@@ -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 esattamente le stesse funzionalità. Ogni backup — manuale o pianificato — usa la stessa matrice di scelta (tre destinazioni × due profili) e richiama la stessa funzione backend per ogni cella (_bk_pbs, _bk_borg o _bk_local). 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 backup_menu in backup_host.sh."
+ },
+ {
+ "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: manuale (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 pianificato (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 run_scheduled_backup.sh; 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 .tar.zst 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 .tar.zst locale."
+ }
+ ]
+ },
+ "profiles": {
+ "heading": "Profilo predefinito e personalizzato",
+ "defaultTitle": "Profilo predefinito",
+ "defaultBody": "Il profilo predefinito è l'elenco curato da hb_default_profile_paths (documentato in Come funziona sotto Categorie di percorsi) più ogni voce nel file extra persistente /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). L’utente seleziona i percorsi per questa esecuzione e può premere Aggiungi percorso personalizzato per aggiungere un nuovo percorso assoluto. I percorsi aggiunti vengono salvati in backup-extra-paths.txt, 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 Gestisci percorsi personalizzati, 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. hb_prepare_staging assembla l’albero dell’archivio in /tmp/proxmenux-DESTINATION-stage.XXXXXX e compila ciascuno dei tre blocchi di dati.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "Assemblaggio del rootfs",
+ "detail": "Esegue rsync -a per ogni percorso selezionato verso staging_root/rootfs/. Il database pmxcfs in /var/lib/pve-cluster/config.db viene acquisito separatamente tramite sqlite3 .backup per ottenere un’istantanea coerente senza arrestare il cluster; i file ausiliari .db-wal / .db-shm sono esclusi da rsync. Se sqlite3 non è disponibile, viene invece salvato un file config.db.raw-fallback, che il ripristino adotta come database durante l’importazione. Da /root/ sono esclusi i sottopercorsi volatili (cronologia bash, cache, cestino). I percorsi assenti nell’origine vengono registrati in metadata/missing_paths.txt senza interrompere il backup."
+ },
+ {
+ "step": "2",
+ "name": "Generazione manifesto",
+ "detail": "build_manifest.sh coordina i sei moduli di raccolta e scrive manifest.json 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": "apt-mark showmanual viene catturato verbatim in metadata/packages.manual.list. Lo stato dei componenti è già all'interno del rootfs ripristinato (components_status.json) perché /usr/local/share/proxmenux/ fa parte del profilo predefinito."
+ },
+ {
+ "step": "4",
+ "name": "Informazioni sull’esecuzione",
+ "detail": "metadata/run_info.env 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 hb_notify_lifecycle \"start\". Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento Backup dell’host avviato. Non viene inviato nulla se non sono configurati canali."
+ }
+ ]
+ },
+ "included": {
+ "heading": "Cosa entra e cosa rimane fuori",
+ "intro": "Ogni percorso nel profilo risolto (predefinito + extra persistenti + selezione personalizzata) viene copiato con rsync -aAXH --numeric-ids. 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": [
+ "images/ — dump immagine.",
+ "dump/ — output di vzdump.",
+ "tmp/ — file temporanei.",
+ "*.log — file di registro."
+ ],
+ "rootTitle": "/root/ esclusioni",
+ "rootBody": "/root/ fa parte del profilo predefinito per includere nell’archivio gli script e la configurazione dell’utente. Sono esclusi i sottopercorsi volatili:",
+ "rootItems": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "/usr/local/share/proxmenux/ esclusioni",
+ "proxmenuxBody": "Questa directory spedisce solo stato utente — components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Percorsi fuori dal profilo",
+ "notInProfileBody": "Qualsiasi cosa non elencata in hb_default_profile_paths e non aggiunta come un extra personalizzato o persistente non fa parte del backup. Esempi notevoli:",
+ "notInProfileItems": [
+ "VM e dischi LXC — gestiti da vzdump, non da questa funzione. I file di configurazione degli ospiti sotto /etc/pve/nodes/*/qemu-server/*.conf e lxc/*.conf vengono catturati (vivono sotto /etc/pve) in modo che il ripristino riproduca l'inventario; i dischi stessi vengono riattaccati da un backup vzdump/PBS esistente.",
+ "/boot e /boot/efi — binari del kernel, initramfs e la partizione UEFI ESP sono rigenerati dal proprio update-initramfs, update-grub o proxmox-boot-tool refresh dopo il ripristino. Il bootloader non è mai copiato verbatim.",
+ "Filesystem del kernel e dello stato di esecuzione del sistema — /proc, /sys, /dev e /run sono pseudo-filesystem generati dal kernel e da udev; non vengono salvati in modo persistente.",
+ "Binari dei pacchetti in /usr/bin, /usr/lib, /lib, /sbin — reinstallati da APT sul sistema di destinazione a partire da packages.manual.list.",
+ "/var/log/, /var/tmp/, /var/cache/ — stato runtime per host, non restaurato.",
+ "/home/USER — 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 backup-extra-paths.txt passa attraverso la stessa pipeline rsync come percorsi di default-profile. Si applicano esclusioni globali. Se il percorso personalizzato avviene sotto /root/ o /usr/local/share/proxmenux/, si applicano ancora le esclusioni specifiche del percorso. Ogni percorso archiviato — predefinito o personalizzato — viene registrato in metadata/paths_archived.txt. I percorsi che non esistono sulla sorgente sono registrati in metadata/missing_paths.txt 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 .pxar 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 trap 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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar scrive un *.proxmenux.json 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 hb_notify_lifecycle \"complete\" o \"fail\" 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/cross-kernel.json b/web/messages/it/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..b784fc2f
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve. I primi due numeri (6.17 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à, hb_compat_check confronta il kernel registrato nel manifesto del backup contro il kernel corrente dell'obiettivo (uname -r) e classifica il ripristino in uno dei tre casi, memorizzato nella variabile interna HB_COMPAT_KERNEL_DIRECTION:",
+ "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 same. 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 più vecchio 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 uname -r 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 intel_iommu=on 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 hb_unsafe_paths_cross_version a RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) che può bloccare pool come straniero."
+ },
+ {
+ "category": "Fonti APT",
+ "paths": "/etc/apt",
+ "reason": "Le suite sorgente APT possono attivare un downgrade di pacchetti critici sul prossimo aggiornamento."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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, GRUB_TIMEOUT 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). _rs_hyd_grub unisce i parametri di manifest.kernel_params.cmdline_extra del backup in GRUB_CMDLINE_LINUX_DEFAULT del target, saltando le chiavi già presenti. Ripristina poi le chiavi consentite GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) da /etc/default/grub del backup se i valori differiscono dal target."
+ },
+ {
+ "phase": "1b — systemd-boot / ZFS",
+ "detail": "Per systemd-boot (tipicamente ZFS alla radice). _rs_hyd_kernel_cmdline unisce i parametri utente di cmdline_extra in /etc/kernel/cmdline del target, mantenendo intatti i parametri di avvio root=, boot= e rootflags= del target."
+ },
+ {
+ "phase": "2 — fusione /etc/modules",
+ "detail": "_rs_hyd_modules aggiunge moduli da manifest.kernel_params.modules_loaded_at_boot che sono nella lista bianca (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) E non già presente nell'obiettivo /etc/modules."
+ },
+ {
+ "phase": "3 — Copia di file whitelist",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d, e la regola di legatura ProxMenux VFIO + le regole nvidia udev sotto le regole /etc/udev/rules.d. I file distribuiti (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 si propaga attraverso plan.env a apply_pending_restore.sh, che forza NEEDS_INITRAMFS=1 e NEEDS_GRUB=1 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 _rs_apply_bk_older_hydration in modalità plan: calcola esattamente ciò che sarebbe stato unito, popola RS_HYDRATION_SUMMARY 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à commit — 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 intel_iommu=on iommu=pt nel cmdline, vfio/vfio_pci/vfio_iommu_type1 in /etc/modules, un /etc/modprobe.d/vfio.conf con options vfio-pci ids=10de:2216, e un /etc/modprobe.d/blacklist-nvidia.conf. L'idratazione fonde i token cmdline nel GRUB o nella cmdline del kernel, aggiunge i moduli vfio a /etc/modules 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 GRUB_TIMEOUT=1 e GRUB_DISABLE_OS_PROBER=true. Hydration legge entrambe le chiavi del backup /etc/default/grub, vede che differiscono dalle impostazioni di installazione fresche, e riscrive quelle due linee nel file del bersaglio (lasciando tutto il resto, incluso GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Qualsiasi cosa al di fuori di quel set — initramfs personalizzato ganci sotto /etc/initramfs-tools/hooks/, file non whitelist sotto /etc/modprobe.d/, override unità systemd scritte dall’utente — rimane esclusa. Il motivo è concreto: questi file possono chiamare interfacce kernel-internal (module APIs, /sys layout, udev 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": "hb_compat_check in lib_host_backup_common.sh. Imposta HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Elenco dei percorsi Safe-subset",
+ "location": "hb_unsafe_paths_cross_version in lib_host_backup_common.sh. Emette linee path\\treason utilizzate sia dal filtro CLI che dal endpoint Web /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Fasi di idratazione",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files in backup_host.sh. Orchestrata da _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Rigenerazione forzata dopo l’avvio",
+ "location": "apply_pending_restore.sh legge HB_HYDRATION_APPLIED da plan.env e forza NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Anteprima web",
+ "location": "/api/host-backups/restore/prepare in flask_server.py. Carica la libreria helper, esegue _rs_apply_bk_older_hydration 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 kernel_params letto dall’idratazione."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/destinations/borg.json b/web/messages/it/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..61f341ae
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/destinations/borg.json
@@ -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 borg create per il backup e borg extract 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, hb_ensure_borg risolve il binario da quattro fonti in ordine e restituisce il primo che funziona:",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Sistema borg",
+ "detail": "Se l'host ha già installato borg tramite APT (which borg risolve), questo binario viene utilizzato."
+ },
+ {
+ "priority": "2",
+ "source": "cache di stato",
+ "detail": "/usr/local/share/proxmenux/borg — tenuto da un precedente download GitHub su questo host."
+ },
+ {
+ "priority": "3",
+ "source": "Pacchetto AppImage del Monitor",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — il AppImage fa un borg-linux64 firmato. Questo è il percorso offline: un host senza internet ha ancora un borg funzionante."
+ },
+ {
+ "priority": "4",
+ "source": "Scarica GitHub",
+ "detail": "wget contro l'URL pinned borg-linux64 sotto github.com/borgbackup/borg/releases/, verificatosi contro una costante SHA-256 in lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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 remote 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 /usr/bin/borg",
+ "detail": "La riga command=\"/usr/bin/borg serve ...\" scritta da ProxMenux in authorized_keys usa questo percorso fisso. APT (apt install borgbackup) installa lì l’eseguibile. Per un binario autonomo occorre un collegamento simbolico in /usr/bin/borg."
+ },
+ {
+ "requirement": "Un account utente dedicato (tipicamente borg)",
+ "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 /backup/borgbackup) deve esistere sul server ed essere di proprietà dell'utente borg."
+ },
+ {
+ "requirement": "SSH daemon accetta l'utente borg",
+ "detail": "PubkeyAuthentication yes (default). L'autenticazione della password è necessaria solo per il flusso generate-auto 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, generate-auto installa la chiave tramite un account che possa scrivere in authorized_keys dell’utente borg. I backup successivi usano questa chiave, limitata a borg serve 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 borg serve. Questo utente è tipicamente chiamato borg, 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, porta 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 ~/.ssh/borg_proxmenux_HOST_ed25519, poi usa sshpass per verificare l’accesso e installare la chiave pubblica in ~borg/.ssh/authorized_keys. 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 authorized_keys 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 pct exec dall'host PVE — root sull'host PVE scrive nel LXC ~borg/.ssh/authorized_keys senza bisogno di SSH nel LXC stesso."
+ },
+ {
+ "mode": "existing",
+ "label": "Utilizzare una chiave esistente",
+ "detail": "ProxMenux scansiona /root/.ssh/ e $HOME/.ssh/ 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 ~/.ssh/id_rsa o un agente SSH)."
+ }
+ ],
+ "restrictTitle": "La linea authorized_keys",
+ "restrictBody": "Per ogni chiave generata, la riga authorized_keys 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 command= costringe ogni sessione SSH utilizzando questa chiave per eseguire solo il comando borg-serve; restrict 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: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. hb_collect_borg_configs la legge per compilare il menu di selezione delle destinazioni."
+ },
+ {
+ "file": "borg-pass-NAME.txt",
+ "content": "Passphrase della destinazione indicata sopra come NAME (chmod 600). 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 hb_borg_init_if_needed: il moderno borg repo-create -e MODE quando disponibile, o il borg init --encryption=MODE legacy. ProxMenux espone due modalità: repokey (default) e none. In modalità repokey 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 borg-pass-NAME.txt 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 borg. 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à. Quando una destinazione viene aggiunta con una porta non standard, ProxMenux aggiunge anche -p PORT; le destinazioni salvate, i processi pianificati e il Monitor usano invece la porta dell’URL ssh://. Senza chiave personalizzata, e per una nuova destinazione 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 repokey. Non compare mai nell'elenco degli argomenti di processo."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Utilizzato da hb_borg_init_if_needed quando inizializza un repository che non esiste ancora. Ignorato da borg create 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, run_scheduled_backup.sh esegue borg prune contro il repository dopo ogni backup di successo con i valori di ritenzione configurati sul lavoro (--keep-last, --keep-daily, --keep-weekly). I backup interattivi non eliminano le vecchie copie."
+ },
+ "restoreAccess": {
+ "heading": "Recuperare sul lato del ripristino",
+ "body": "Il flusso di ripristino elenca gli archivi con borg list REPO ed estrae quello selezionato con borg extract REPO::ARCHIVE-NAME in una directory di staging che _rs_check_layout 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 Come funziona ."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/destinations/index.json b/web/messages/it/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..3e80c055
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — ma tutti e tre condividono lo stesso passo di staging (hb_prepare_staging) 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 .tar.zst singolo (o .tar.gz se zstd è assente).",
+ "pbs": "Backup PBS (blocchi .pxar nel datastore).",
+ "borg": "Archivio Borg all'interno di un repository Borg (file di segmento)."
+ },
+ {
+ "feature": "Compressione",
+ "local": "zstd (livello predefinito) tramite tar --zstd. 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 KEEP_LAST. 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. I backup interattivi non eliminano le vecchie copie.",
+ "borg": "Applicato per lavoro programmato tramite borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (presente su Proxmox per impostazione predefinita).",
+ "pbs": "Pacchetto proxmox-backup-client (incluso in Proxmox VE 8+).",
+ "borg": "binario borg. 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 proxmox-backup-client, le credenziali PBS e il file di chiave (se il backup è crittografato).",
+ "borg": "Richiede borg + 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 rootfs/ + metadata/ + manifest.json descritto in Come funziona è presente. Un .tar.zst estratto da un archivio locale, un .pxar restaurato da PBS, e un archivio Borg estratto con borg extract producono tutti un albero di directory identico. Il percorso del codice di ripristino (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/destinations/local.json b/web/messages/it/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..0bf1d672
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst (o .tar.gz quando zstd è assente). Il file contiene l'intero albero di archivio — manifest.json, metadata/ e rootfs/ — e può essere ripristinato su qualsiasi host Proxmox con il flusso di ripristino ProxMenux o estratto manualmente con tar --zstd -xf 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 unica directory di destinazione salvata in modo persistente — non un elenco. ProxMenux memorizza la scelta dell'operatore su /usr/local/share/proxmenux/local-target.conf e la legge su ogni backup. Quando non è stato configurato alcun obiettivo, viene utilizzato il HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump predefinito (la stessa directory Proxmox utilizza per le proprie uscite vzdump). L'obiettivo è configurato da Configura destinazioni di backup → Destinazioni locali:",
+ "options": [
+ "Utilizzo predefinito (/var/lib/vz/dump). 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.",
+ "Inserisci un percorso personalizzato. Puoi usare qualsiasi percorso assoluto del filesystem: un montaggio NFS, una condivisione SMB montata tramite fstab, un dataset ZFS dedicato o un secondo disco interno. Prima di salvarlo, ProxMenux verifica che il percorso esista e sia una directory.",
+ "Scegli un’unità USB. 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 lsblk. 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 hb_mount_usb_partition: crea /mnt/backup-LABEL (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 digitare il percorso esatto del dispositivo (ad esempio /dev/sdb) 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, _bk_local verifica che la directory di destinazione sia non un sottopercorso di qualsiasi directory di cui viene eseguito il backup. Un errore comune sarebbe aggiungere /root al profilo e scegliere /root/backups 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 readlink -m, 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 tar --zstd -cf: un singolo comando che comprime al livello predefinito di zstd. Se zstd non è presente sull’origine (raro su Proxmox, ma possibile nelle installazioni minime), ProxMenux ripiega su gzip. In questo caso, se pv è disponibile, viene aggiunta una barra di avanzamento per mostrare la crescita dell’archivio in tempo reale; senza pv, viene usato il semplice tar -czf senza output di avanzamento.",
+ "sourceTitle": "Cosa viene incluso nell’archivio",
+ "sourceBody": "Il comando tar viene richiamato con -C \"$staging_root\" . e archivia l’intera radice della directory temporanea: rootfs/, metadata/ e manifest.json. 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: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, scritto accanto all'archivio da hb_write_archive_sidecar. 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 (kind), l'ID di lavoro per le esecuzioni pianificate, la modalità profilo utilizzata (default o custom), 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 *.proxmenux.json nelle directory locali configurate, non i file *.tar.zst, perché un .tar.zst 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 _rs_check_layout, 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, tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg produce lo stesso albero che il codice di ripristino consuma."
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/destinations/pbs.json b/web/messages/it/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..6cc1e51e
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client - 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 .pxar, --backup-id, 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 host/hostcfg-HOSTNAME/BACKUP-TIME. I dati sono un archivio .pxar con la stessa struttura in tre blocchi descritta in Come funziona. 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, run_scheduled_backup.sh esegue proxmox-backup-client prune con --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET e HB_PBS_FINGERPRINT 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 pbs: 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 Configure destinazioni di backup → PBS destinazioni → Aggiungi PBS. Prompts per un nome, nome utente (root@pam o user@pbs!token), 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 ([proxmox] o [manual]). Le voci di cui la password non poteva essere risolta sono contrassegnate con un avviso ⚠ no password — selezionando uno attiva un rientro password prima dell'avvio del backup. L'impronta digitale viene passata a proxmox-backup-client tramite la variabile di ambiente PBS_FINGERPRINT; 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 proxmox-backup-client backup. ProxMenux usa env 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 è hostcfg-HOSTNAME. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in [A-Za-z0-9_-] e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un gruppo e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.",
+ "pxarTitle": "Perché la fonte è la radice di staging completa",
+ "pxarBody": "La sorgente .pxar è l'intero staging_root — rootfs/, metadata/ e manifest.json insieme. Le versioni precedenti hanno superato $staging_root/rootfs come fonte; che ha lasciato metadata/ fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-_rs_check_layout di 3, che avvolge un albero etc/var/root/usr piatto di nuovo in una gerarchia rootfs/."
+ },
+ "encryption": {
+ "heading": "Crittografia lato cliente",
+ "glossaryHint": "Questa sezione usa i termini file di chiave, passphrase e involucro di recupero. Il glossario 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 /usr/local/share/proxmenux/pbs-key.conf 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: No prosegue senza crittografia, Sì passa alla seconda fase. Questa dipende dalla presenza di un file di chiave in /usr/local/share/proxmenux/pbs-key.conf. Se esiste, viene riutilizzato senza altre domande e il backup prosegue; i backup successivi non lo chiedono più. Altrimenti, un menu offre due opzioni. Genera un nuovo file di chiave esegue proxmox-backup-client key create --kdf none. Usa un file di chiave esistente rileva automaticamente una chiave gestita da PVE: se il repository PBS scelto è registrato in Proxmox con una chiave di crittografia in /etc/pve/priv/storage/<NAME>.enc, 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 chmod 600.",
+ "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 Usa un file di chiave esistente. 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 Caricare la chiave su PBS?, con due risposte. Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì. L’opzione predefinita è No, conserva solo in locale: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante Scarica il file di chiave del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo Sì, carica, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo pbs-key.recovery.enc. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.",
+ "blobUploadTitle": "Gruppo di backup abbinato su PBS",
+ "blobUploadBody1": "Quando la modalità escrow è Sì, carica, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in -keyrecovery. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. La busta non lascia mai l'host in plaintext: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS riceve solo la busta già crittografata.",
+ "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 proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo -keyrecovery, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce wrong key — manifest's key XX does not match provided key YY. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.",
+ "monitorManagementTitle": "Gestione del keyfile dal Monitor",
+ "monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: Scarica esporta il file attuale nel browser; Carica sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; Elimina rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per Caricare la chiave su PBS?, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con Avvia caricamento, Interrompi caricamento o Aggiorna passphrase. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce."
+ },
+ "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 proxmox-backup-client restore con gli stessi repository, password e impronta, oltre a --keyfile se il backup è crittografato. L’archivio .pxar viene estratto in una directory di preparazione che _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/glossary.json b/web/messages/it/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..40a59b8d
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/glossary.json
@@ -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 busta di recupero. 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. Non è la passphrase che sblocca il keyfile stesso, 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 blocchi prima dell’invio a PBS. Senza la chiave corrispondente i dati cifrati non sono leggibili. ProxMenux lo salva in /usr/local/share/proxmenux/pbs-key.conf con modalità 600. Proteggilo: la busta di recupero 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 passphrase di recupero. Esiste solo quando il keyfile è stato creato con --kdf scrypt (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 keyfile avvolto in uno strato aggiuntivo: viene crittografato con il passphrase di recupero utilizzando AES-256-CBC e PBKDF2 prima che lasci l'host. È ciò che viene caricato su PBS come gruppo -keyrecovery. 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 busta di recupero in cima."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Opzione a proxmox-backup-client key create 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 proxmox-backup-client key create che produce un keyfile protetto da un passphrase del file di chiave. 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 openssl enc -aes-256-cbc) per avvolgere il keyfile con il passphrase di recupero e produrre il busta."
+ },
+ {
+ "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 rsync secondo il profilo predefinito e i percorsi personalizzati. 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 Come funziona pagina."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Percorsi personalizzati",
+ "def": "Percorsi extra l'utente aggiunge in cima al profilo default. O persistente (conservato in backup-extra-paths.txt) 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 + datastore + utente che riceve il backup. Identificata dalla stringa user@realm@host:datastore. 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 proxmox-backup-client tramite la variabile ambiente PBS_FINGERPRINT."
+ },
+ {
+ "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 -keyrecovery per la busta di recupero."
+ },
+ {
+ "id": "backup-id",
+ "term": "ID backup",
+ "def": "Nome del gruppo backup. ProxMenux predefinisce hostcfg-HOSTNAME 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 run_scheduled_backup.sh 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 /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Modalità allegato",
+ "def": "Processo senza timer proprio. Un hook job-end PVE di vzdump lo avvia dopo i backup dei guest se lo storage corrisponde. Il processo padre fornisce destinazione e conservazione, riletta dal processo padre a ogni esecuzione, 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 indipendente lavoro programmato; attach-mode 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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 idratazione 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 keyfile locale. Ripristino di un backup crittografato richiede prima di recuperare il file chiave dal busta memorizzato su PBS, utilizzando il passphrase di recupero."
+ }
+ ]
+ }
+ ],
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/how-it-works.json b/web/messages/it/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..78a4d54c
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/how-it-works.json
@@ -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 (.tar.zst locale, backup PBS o archivio Borg) conserva questa struttura. Il ripristino usa tutte e tre: il manifesto viene consultato prima delle modifiche per rilevare differenze e decidere cosa escludere; rootfs fornisce i file di configurazione, applicati subito o dopo il riavvio; l’inventario delle applicazioni 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 metadata/ contiene i dati strutturati; la sottodirectory rootfs/ 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 rootfs/ è una semplice copia del filesystem prodotta da rsync dall’host di origine. Contiene un profilo predefinito di percorsi scelti per il ripristino Proxmox e gli eventuali percorsi personalizzati aggiunti all’attività o alla sessione interattiva. La selezione è volutamente limitata ai percorsi che contengono configurazione o conservano uno stato che Proxmox non può rigenerare da solo.",
+ "defaultProfileTitle": "Il profilo predefinito",
+ "defaultProfileBody": "Il profilo predefinito è definito da hb_default_profile_paths in lib_host_backup_common.sh. 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 (config.db) viene catturato come un'istantanea coerente tramite sqlite3 .backup senza interrompere il cluster, e i sidecar .db-wal / .db-shm sono esclusi dal rsync. Quando sqlite3 non è disponibile, viene creato config.db.raw-fallback, 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 .link in /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. I percorsi volatili (.bash_history, .cache/, tmp/, .local/share/Trash/) sono esclusi dalla copia. /var/lib/proxmenux 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 zpool.cache e hostid."
+ }
+ ],
+ "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 /usr/local/share/proxmenux/backup-extra-paths.txt contiene un elenco di percorsi assoluti che l'utente ha contrassegnato come \"sempre includere\" su questo host. Quando un backup viene eseguito in modalità Default, 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 #.",
+ "customModeTitle": "2. Modalità personalizzata (per-run)",
+ "customModeBody": "Avviare un backup in modalità Custom 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 [+] e già selezionati). L'utente seleziona o deseleziona le voci per tale esecuzione specifica, e può anche premere Aggiungi percorso personalizzato 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 metadata/missing_paths.txt 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 /etc/wireguard o /etc/prometheus quando questi strumenti non sono installati."
+ },
+ "manifest": {
+ "heading": "La parte manifesto",
+ "intro": "manifest.json è un documento strutturato JSON che descrive l'host sorgente al momento del backup. È prodotto da sei moduli di raccolta indipendenti orchestrati da build_manifest.sh. 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 (pveversion), versione PBS se l'host esegue il ruolo di backup-server, kernel (uname -r), 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 lsusb/lspci), NIC (con MAC, slot PCI e ponti), dispositivi wireless. Le voci GPU portano un'euristica passthrough_eligible."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "Pool ZFS con relativo tipo e dischi membri identificati tramite /dev/disk/by-id/*, /dev/disk/by-partuuid/* o percorsi diretti /dev/sdX, a seconda di come il pool è stato creato; gruppi di volumi e thin pool LVM; dischi fisici con supporto SMART; voci PVE di storage.cfg; montaggi esterni."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Parametri aggiunti dall’operatore in /proc/cmdline, esclusi quelli standard come BOOT_IMAGE=, root=, ro/rw, quiet e splash; moduli caricati all’avvio da /etc/modules; percorsi dei file /etc/modprobe.d/*.conf con direttive effettive (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Leggi /usr/local/share/proxmenux/managed_installs.json (registry di tutto ciò che ProxMenux ha installato) e installed_tools.json. Ogni voce mantiene il percorso di installazione (menu_script) 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 (qm list) e i container LXC (pct list) presenti al momento del backup: VMID, nome e stato. È soltanto l’inventario; il backup dei dati effettivi dei guest spetta a vzdump / PBS."
+ }
+ ],
+ "schemaTitle": "Validazione schema",
+ "schemaBody": "Il manifesto convalida contro scripts/backup_restore/schema/manifest.schema.json. L'esecuzione di build_manifest.sh --validate attiva una validazione dello schema JSON (richiede python3 + jsonschema). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime."
+ },
+ "applications": {
+ "heading": "inventario delle applicazioni",
+ "intro": "Due inventari elencano il software aggiunto ai pacchetti base di Proxmox VE: la lista dei pacchetti in metadata/ 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 apt-mark showmanual con tutti i pacchetti APT installati esplicitamente sull’host di origine. Sono escluse le dipendenze del sistema Proxmox VE di base, che APT installa automaticamente sul destinatario. Durante il ripristino, _rs_run_complete_extras legge la lista e applica un filtro contro le rimozioni a cascata in tre passaggi: dpkg -s rileva i pacchetti già installati, vengono rilevate altre versioni principali delle librerie e apt-get install --simulate verifica il rischio di rimozioni a cascata. Infine usa apt-get install -y per i pacchetti rimasti.",
+ "componentsTitle": "components_status.json (parte di rootfs)",
+ "componentsBody": "Un registro JSON sotto /usr/local/share/proxmenux/ che registra ogni componente ProxMenux installato con il suo stato esatto: versione, bandiere ProxMenux-specifiche (per NVIDIA: patched boolean; per Coral: versione DKMS). Questo file vive all'interno dei rootfs — non in metadata/ — perché è letto dopo la copia di rootfs al bersaglio. Il distaccatore post-boot (apply_cluster_postboot.sh) itera sulle sue voci ed esegue il gancio --auto-reinstall 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 --auto-reinstall:",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Leggi version + patched. 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 .deb dalla versione GitHub."
+ },
+ {
+ "component": "intel_gpu_tools",
+ "installer": "gpu_tpu/intel_gpu_tools.sh",
+ "action": "APT-installa il pacchetto. Idemponte se già presente da packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check. Confronta sorgente vs. hardware target (NIC, ID di archiviazione), versione PVE e versione kernel principale. Imposta HB_COMPAT_KERNEL_DIRECTION (same, bk_newer o bk_older) e popola RS_SKIP_PATHS con esclusione hardware-drift e cross-kernel."
+ },
+ {
+ "stage": "2",
+ "name": "Applicazione a sistema avviato",
+ "reads": "rootfs/ (solo percorsi sicuri)",
+ "action": "_rs_apply … hot copia le voci hb_classify_path=hot direttamente al target live. Qualsiasi cosa sotto /etc/pve, /etc/network o percorsi classificati come reboot/dangerous è differita."
+ },
+ {
+ "stage": "3",
+ "name": "Preparazione delle modifiche differite",
+ "reads": "rootfs/ (riavvio + percorsi pericolosi)",
+ "action": "_rs_prepare_pending_restore prepara i percorsi rischiosi in /var/lib/proxmenux/pending-restore/, scrive plan.env, apply-on-boot.list e rs-skip-paths.txt e abilita proxmenux-restore-onboot.service per il prossimo avvio."
+ },
+ {
+ "stage": "3b",
+ "name": "Importazione dei pool di dati",
+ "reads": "manifest.storage_inventory + target ZFS stato",
+ "action": "_rs_import_data_pools 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 zpool import -f. Se manca un disco, il pool viene saltato con un avviso. Il risultato per pool è registrato in /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "stage": "4",
+ "name": "Installazione del pacchetto",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras gestisce il filtro a cascata e chiama apt-get install -y con l'elenco dei pacchetti sopravvissuti. L'uscita completa va a /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Dopo l'avvio",
+ "reads": "rootfs (già applicato) + components_status.json",
+ "action": "Dopo il riavvio, apply_pending_restore.sh riprende i percorsi differiti e apply_cluster_postboot.sh corre update-initramfs, update-grub (o proxmox-boot-tool refresh) e itera oltre components_status.json sparando il gancio --auto-reinstall di ogni componente."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Perché suddividere il backup in tre parti",
+ "body": "La suddivisione segue il ciclo di vita dei dati. Il filesystem viene trasferito con rsync: rapidamente, in modo trasparente e atomico per file. Lo stato di configurazione da interpretare prima delle modifiche è JSON strutturato, leggibile separatamente, versionabile tramite schema e confrontabile automaticamente con lo stato di destinazione. Il software da reinstallare è descritto in un inventario 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."
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/index.json b/web/messages/it/docs/backup-restore/index.json
new file mode 100644
index 00000000..0e1015af
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/index.json
@@ -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: il filesystem, con le directory pertinenti in /etc, /root e /var/lib/pve-cluster e gli eventuali percorsi personalizzati; un manifesto strutturato in JSON con hardware rilevato, parametri del kernel, configurazione di rete, stato di ZFS, utenti e voci cron; e un inventario delle applicazioni, 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 dell’host: l’installazione di Proxmox, non le applicazioni e i sistemi guest che vi vengono eseguiti.",
+ "items": [
+ "Non è uno strumento di backup delle VM/CT. Questa funzione non acquisisce i dischi o lo stato della RAM dei guest: a questo serve vzdump. I file di configurazione dei guest (/etc/pve/nodes/<node>/qemu-server/*.conf e lxc/*.conf) vengono invece salvati. Dopo il ripristino ricompare l’inventario e i dischi possono essere ripristinati o ricollegati da un backup esistente su PBS o in locale.",
+ "Non è un’operazione sull’intero cluster. Ogni nodo salva il proprio backup. L’appartenenza al cluster è inclusa in /etc/pve, così un nodo ripristinato può esservi reintegrato; il ripristino di tutto il cluster richiede però il coordinamento dei singoli nodi.",
+ "Non è un’immagine completa del disco. 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 update-initramfs 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 kernel corrente della destinazione, 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 idratazione 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 Come funziona se l'obiettivo è capire cosa contiene l'archivio e perché. Vai a Destinazioni per configurare la destinazione per la copia. Leggi Ripristino e Ripristino cross-kernel 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/restoring.json b/web/messages/it/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..2f53b1e3
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Ripristino di un backup — flussi completi e personalizzati | ProxMenux",
+ "description": "Il flusso di lavoro completo di ripristino. Documenta le tre azioni disponibili su qualsiasi backup (visualizzazione, download, ripristino), il controllo di compatibilità e i suoi risultati, le modalità di ripristino completo e personalizzato, la classificazione del percorso che decide cosa si applica dal vivo e cosa aspetta per il prossimo avvio, il dispacciatore di avvio, e il passaggio di reinstallazione del componente post-boot.",
+ "ogTitle": "ProxMenux Backup — ripristino",
+ "ogDescription": "Flussi di ripristino completi e personalizzati con il controllo di compatibilità, la classificazione del percorso, il dispacciatore on-boot e la reinstallazione post-boot.",
+ "twitterTitle": "Ripristino di un backup | ProxMenux",
+ "twitterDescription": "Come un backup host ProxMenux viene trasformato in un host Proxmox funzionante."
+ },
+ "header": {
+ "title": "Ripristino di un backup",
+ "description": "L’intero ripristino, dalla scelta dell’archivio a un host operativo: controllo della compatibilità, due modalità di ripristino, elaborazione all’avvio e reinstallazione dei componenti dopo l’avvio, con i meccanismi per ripristinare su host e kernel diversi.",
+ "section": "Backup e ripristino"
+ },
+ "intro": {
+ "title": "Il ripristino riproduce la fonte, non solo i file",
+ "body": "Ripristinare un backup ProxMenux richiede più della semplice estrazione. Prima delle modifiche, il manifesto rileva le differenze tra origine e destinazione, vengono esclusi i percorsi che potrebbero impedire l’avvio e adattate le impostazioni dell’utente non copiabili alla lettera. Dopo il riavvio necessario, viene tentata la reinstallazione dei componenti supportati registrati (driver NVIDIA, Coral TPU, strumenti GPU) per il kernel attivo della destinazione. Un solo archivio guida controllo della compatibilità, classificazione dei percorsi e operazioni all’avvio e successive. Verifica risultati dei componenti e log per confermare l’esito."
+ },
+ "threeActions": {
+ "heading": "Tre azioni su un backup",
+ "intro": "Selezionando un backup dall'elenco si apre un menu con tre azioni.",
+ "actionRows": [
+ {
+ "action": "Vista",
+ "detail": "Consente di visualizzare in sola lettura l'archivio: contenuti manifest.json (nome host sorgente, versione PVE, kernel, hardware, componenti installati), l'elenco dei percorsi all'interno di rootfs/ e un diff di ciò che cambierebbe sull'host corrente se il backup fosse applicato."
+ },
+ {
+ "action": "Scarica",
+ "detail": "Esporta l'archivio come file portatile .tar.zst (tar compresso con zstd). Può essere estratto su qualsiasi sistema Linux con tar --zstd -xf FILE.tar.zst, o su macOS/Windows con qualsiasi strumento che supporta zstd (7-Zip, PeaZip, Keka...). L'albero estratto contiene manifest.json, metadata/ e rootfs/ — esattamente lo stesso layout che il ripristino consuma. Utile per l'ispezione offline o per il ripristino su un host senza accesso alla destinazione originale (PBS, Borg)."
+ },
+ {
+ "action": "Ripristina",
+ "detail": "Il percorso di scrittura. Estrae l'archivio in una directory di staging, esegue il controllo di compatibilità e presenta il raccoglitore di modalità (Full o Custom)."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Il controllo della compatibilità",
+ "intro": "Prima che qualsiasi file sia scritto, hb_compat_check confronta lo stato descritto nel manifesto contro l'host di destinazione. Il controllo viene eseguito in sola lettura e produce quattro uscite indipendenti che guidano il resto del ripristino.",
+ "outputRows": [
+ {
+ "output": "Indicatore della direzione",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION vale same, bk_newer o bk_older in base al confronto delle versioni principali del kernel del backup e della destinazione. Guida il filtro dei percorsi compatibili, attivo solo per bk_older, e l’adattamento delle impostazioni descritto nella pagina sul ripristino tra kernel diversi."
+ },
+ {
+ "output": "Elenco dei percorsi Skip-paths",
+ "detail": "RS_SKIP_PATHS — ogni percorso che il ripristino non deve applicarsi. Populate da due meccanismi: deriva dell'hardware (mancando NIC, ID di archiviazione mancante, straniero ZFS pool) e — quando la direzione è bk_older — l'elenco dei percorsi non sicuri per il cross-kernel."
+ },
+ {
+ "output": "Piano di rimappatura delle schede di rete",
+ "detail": "Quando un NIC sul bersaglio ha lo stesso MAC come uno sulla fonte ma un nome diverso (tipico dopo uno scambio di schede madri), il controllo di compatibilità registra un piano di rinomina (HB_NIC_REMAP) che riscriverà /etc/network/interfaces durante il ripristino."
+ },
+ {
+ "output": "Piano di rollback",
+ "detail": "Calcolato da compute_rollback_plan.sh. Elenca VM, LXC e componenti presenti sulla destinazione ma assenti dal backup. La conferma offre la rimozione facoltativa dei guest aggiuntivi prima del riavvio. I componenti vanno rimossi manualmente e l’eliminazione dei guest può fallire: non è garantita una corrispondenza esatta."
+ }
+ ],
+ "reportBody": "Il controllo emette anche un rapporto strutturato (HB_COMPAT_RESULTS) classificato come PASS / INFO / WARN / FAIL. Le voci WARN e FAIL sono di superficie nel pannello pre-restore; il ripristino si rifiuta di procedere solo quando un FAIL è presente che l'utente non può risolvere facendo clic su Continua."
+ },
+ "twoModes": {
+ "heading": "Ripristino completo vs ripristino personalizzato",
+ "intro": "Dopo il controllo della compatibilità compare la scelta della modalità. Determina cosa applicare e non come: entrambe usano lo stesso processo.",
+ "modeRows": [
+ {
+ "mode": "Ripristino completo",
+ "detail": "Applica ogni percorso dell'archivio che sopravvive alla deriva e ai filtri cross-kernel. Esegue anche il pacchetto di installazione e il componente auto-reinstall pass. Questa è la scelta predefinita e raccomandata — l'obiettivo è quello di riprodurre la fonte, non selezionare i pezzi."
+ },
+ {
+ "mode": "Ripristino personalizzato",
+ "detail": "Apre una lista di controllo che mostra ogni percorso che l'archivio porta. L'utente segna un sottoinsieme. I percorsi bloccati dal filtro cross-kernel appaiono grigiati e non possono essere selezionati. L'installazione del pacchetto e la reinstallazione automatica del componente sono saltati per impostazione predefinita in modalità personalizzata — l'utente sta segnalando che vogliono applicazione parziale, non una riproduzione completa."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Come si classificano i percorsi",
+ "intro": "Ogni percorso selezionato per il ripristino è classificato da hb_classify_path in una delle tre categorie. La categoria determina quando il percorso viene applicato al sistema e perché.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Percorsi applicati immediatamente al sistema di esecuzione. Il servizio che li consuma raccoglie il cambiamento da solo o al successivo ricarico — nessun riavvio richiesto. Queste sono la maggior parte di un backup: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, file di configurazione di servizio generale, ecc."
+ },
+ {
+ "class": "reboot",
+ "detail": "Percorsi rimandati al prossimo avvio anziché applicati immediatamente da questo processo. Riguardano la configurazione di avvio: la generazione del bootloader legge /etc/default/grub, i montaggi usano /etc/fstab e il caricamento dei moduli usa /etc/modules. I file differiti vengono applicati dopo il riavvio, poi vengono rigenerati gli elementi di avvio necessari. Esempi: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Percorsi NON applicati sul sistema in esecuzione: una scrittura a caldo potrebbe corrompere lo stato o interrompere la connessione attiva. Vengono messi nell’insieme in attesa: /etc/network viene scritto all’inizio del riavvio successivo, prima dell’avvio della rete, e /etc/pve viene scritto dal dispatcher post-avvio quando il file system del cluster è disponibile. Esempi: /etc/pve (pmxcfs è un montaggio FUSE con la configurazione attiva del cluster), /var/lib/pve-cluster (dati attivi del cluster, conservati nella directory di ripristino solo per il recupero manuale), /etc/network (potrebbe riconfigurare proprio l’interfaccia usata dalla connessione SSH e interrompere la sessione)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "Il flusso di lavoro di ripristino completo",
+ "intro": "La pipeline completa dalla selezione di archivi a un host restaurato funzionante. Ogni fase alimenta il successivo; lo stato scritto da fasi precedenti è consumato da quelli successivi.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "Il meccanismo di ripristino differito",
+ "intro": "I percorsi classificati come reboot o dangerous, e le scritture di idratazione, sono in scena per il prossimo avvio invece di essere applicati in diretta. Questo viene fatto attraverso un piccolo set autocontenuto di file sotto /var/lib/proxmenux/pending-restore/:",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "Un percorso relativo per linea — l'esatto insieme di percorsi apply_pending_restore.sh si applicherà dai rootfs in fase. Leggere questo file dice all'utente esattamente ciò che cambierà sul boot successivo."
+ },
+ {
+ "file": "plan.env",
+ "content": "Variabili d’ambiente caricate dallo script di avvio: ID del ripristino, indicatori di compatibilità (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), consenso al rollback e opzioni del cluster."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "La lista finale RS_SKIP_PATHS, salvata affinché apply_pending_restore.sh mantenga dopo il riavvio le esclusioni calcolate nella fase interattiva. Impedisce di ripristinare all’avvio percorsi incompatibili con l’hardware o il kernel."
+ },
+ {
+ "file": "rootfs/",
+ "content": "I file in scena stessi — i byte esatti che saranno stabiliti. Tenuto sullo stesso filesystem di / così il rsync on-boot è veloce e non dipende dallo storage esterno ancora raggiungibile al boot."
+ }
+ ],
+ "unitBody": "L’unità systemd proxmenux-restore-onboot.service viene abilitata alla fine della fase interattiva. Il servizio viene eseguito una sola volta, all’inizio del prossimo avvio, richiama apply_pending_restore.sh e poi si disabilita. La condizione ConditionPathExists=/var/lib/proxmenux/pending-restore/state evita l’esecuzione quando non esiste un ripristino in sospeso."
+ },
+ "postbootDispatcher": {
+ "heading": "Il processo dopo l’avvio — apply_cluster_postboot.sh",
+ "intro": "Dove finisce il passo interattivo e dove avviene la riproduzione reale dell'ospite. apply_cluster_postboot.sh è installato come una seconda unità systemd (proxmenux-apply-cluster-postboot.service) la cui destinazione After=/Wants= assicura che funzioni solo dopo l'apertura di pve-cluster e network-online. Questo è dove le azioni di ripristino visibile dell'ospite atterrare.",
+ "tasks": [
+ {
+ "task": "Applicare /etc/pve",
+ "detail": "/etc/pve è un live pmxcfs FUSE mount — non può essere scritto su avvio precoce. Il dispacciatore copia i file dai rootf in sospeso al live /etc/pve una volta che il filesystem del cluster è in funzione, un file alla volta, senza riavviare pve-cluster. Il /var/lib/pve-cluster/config.db catturato dal backup (o il config.db.raw-fallback) promosso è materializzato con il systemctl stop pve-cluster → copia di file atomico → modello systemctl start pve-cluster, quindi pmxcfs rilegge lo stato ripristinato sulla via del ritorno."
+ },
+ {
+ "task": "Ricostruire initramfs e bootloader",
+ "detail": "Esegue update-initramfs -u -k all per tutti i kernel installati, poi update-grub per GRUB oppure proxmox-boot-tool refresh per systemd-boot/ZFS. Il passaggio viene saltato se la fase interattiva ha rilevato che nessun percorso pertinente è cambiato."
+ },
+ {
+ "task": "Reinstallazione automatica dei componenti",
+ "detail": "Legge components_status.json ripristinato e scorre gli installatori supportati (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Ogni installatore selezionato usa --auto-reinstall, legge lo stato registrato e reinstalla per l’ambiente di destinazione, ricompilando i moduli se necessario. Attende il riavvio per usare il kernel allora attivo. Gli errori individuali vengono registrati senza fermare il componente successivo."
+ },
+ {
+ "task": "Controllo preliminare dell'avvio",
+ "detail": "Prima di eseguire la notifica di completamento, verifica che proxmox-boot-tool status mostra un ESP configurato, ogni /boot/vmlinuz-* ha una directory corrispondente /lib/modules/<ver> e risolve /vmlinuz. Qualsiasi incoerenza viene visualizzata nella notifica invece di essere nascosta."
+ },
+ {
+ "task": "Notifica di completamento",
+ "detail": "Invia l'evento Host restore finished tramite hb_notify_lifecycle. Include la durata totale, il conteggio del percorso applicato, le avvertenze di controllo della sanità se presenti, e un collegamento al registro a /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Se le notifiche non sono configurate, l'evento è silenzioso — il registro registra tutto."
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Avanzamento in tempo reale nella scheda Backup del Monitor",
+ "body": "Dopo il riavvio, la scheda Backup di ProxMenux Monitor mostra l’avanzamento di proxmenux-apply-cluster-postboot.service. Legge /var/lib/proxmenux/restore-state.json, aggiornato a ogni fase: configurazione del cluster, initramfs, bootloader, reinstallazione di ciascun componente, verifica dell’avvio e conclusione.",
+ "fields": [
+ {
+ "name": "Indicatore di stato",
+ "detail": "Uno degli stati Ripristino in corso, Ripristino completato o Ripristino non riuscito. La scheda legge lo stato ogni 2 secondi durante l’esecuzione e ogni 30 secondi dopo la fine."
+ },
+ {
+ "name": "Barra di avanzamento e contatore dei passaggi",
+ "detail": "Mostra N/M steps e il nome della fase corrente. Durante il ripristino, il tempo stimato viene calcolato dai passaggi completati e dal tempo trascorso."
+ },
+ {
+ "name": "Elenco dei componenti",
+ "detail": "Viene reinstallata una riga per driver (NVIDIA, strumenti Intel GPU, strumenti AMD, Coral TPU) con installing / ok / failed più un collegamento al log per-component a /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Importazione dei pool di dati",
+ "detail": "Il blocco data_pools_import mostra cinque righe colorate: Importati, Forzati (con -f per un hostid estraneo), Saltati, dischi parziali (solo alcuni dischi presenti), Saltati, dischi assenti (nessun disco presente) ed Errori. Lo stato è salvato in /var/lib/proxmenux/restore-state.json e il log completo dell’esecuzione in /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Avvisi controllo avvio",
+ "detail": "Il processo controlla le directory /lib/modules/<kernel> mancanti, la configurazione ESP assente e i collegamenti simbolici /vmlinuz senza destinazione. Gli avvisi appaiono qui in un riquadro colorato."
+ },
+ {
+ "name": "Delta di rollback",
+ "detail": "Elenca VM, LXC e componenti che esistono sul bersaglio, ma non sono stati nel backup ripristinato — le stesse voci sono emerse nella finestra di dialogo di rollback distruttivo pre-restore. Ogni riga porta il comando di pulizia manuale."
+ },
+ {
+ "name": "coda di log",
+ "detail": "Le ultime linee 600 di proxmenux-cluster-postboot-<ts>.log, con un filtro Solo problemi che mantiene solo le linee corrispondenti a error, warning, failed, ✗ o traceback."
+ }
+ ],
+ "dismissBody": "Quando il ripristino è completato o non riuscito, il pulsante Nascondi chiude la scheda. Il file di stato resta disponibile e Cronologia riapre questo ripristino e quelli precedenti. Le ultime 20 esecuzioni sono archiviate in /var/lib/proxmenux/restore-history/.",
+ "imageAlt": "Finestra Dettagli del ripristino in ProxMenux Monitor durante l’esecuzione: indicatore blu, fase Ricostruzione initramfs, tempo residuo stimato, barra parzialmente piena e ultime righe del log in tempo reale.",
+ "imageCaption": "Finestra Dettagli mentre il processo dopo l’avvio è ancora attivo: stato, fase corrente, tempo residuo e ultime righe del log in tempo reale.",
+ "detailsImageAlt": "La stessa finestra Dettagli al termine del ripristino, con indicatore verde Ripristino completato, durata totale 0m53s, barra piena 6/6, sezione delle differenze di rollback vuota e log dopo l’avvio archiviato.",
+ "detailsImageCaption": "Lo stesso modale una volta che l’esecuzione è terminata — il distintivo, la durata totale, la barra di avanzamento riempita e il registro postboot archiviato."
+ },
+ "postbootExample": {
+ "heading": "Che aspetto ha il post-boot sulla console",
+ "body": "Sulla console fisica, un processo terminato correttamente mostra [ OK ] Finished proxmenux-apply-cluster-postboot.service, spesso vicino agli OK di multi-user.target e graphical.target. La riga indica la fine del processo. Possono comunque essere stati registrati errori di singoli componenti o avvisi di avvio: verifica stati e log nel Monitor prima di considerare l’host completamente ripristinato.",
+ "imageAlt": "Console fisica Proxmox con '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', seguito da OK per multi-user.target e graphical.target e dal prompt di accesso in alto.",
+ "imageCaption": "Console fisica al termine del processo. 'Finished proxmenux-apply-cluster-postboot.service' ne indica la conclusione, segnalata anche da 'Host restore finished' nel Monitor. Occorre comunque verificare risultati dei componenti e avvisi."
+ },
+ "tenMinutes": {
+ "heading": "Perché gli ultimi dieci minuti sono importanti",
+ "intro": "Il riavvio stesso richiede secondi, ma il processo dopo l’avvio passa circa dieci minuti terminando il ripristino. Durante questa finestra l'host è raggiungibile e funziona di login, ma alcuni servizi (principalmente GPU-driver-dipendenti) non sono ancora disponibili. Ripartizione del tempo per un tipico host Proxmox con NVIDIA + Coral installato:",
+ "rows": [
+ {
+ "stage": "Boot + pve-cluster pronto",
+ "time": "~30 s",
+ "detail": "Avvio standard di Proxmox. SSH, interfaccia web e accesso sono disponibili al termine della fase."
+ },
+ {
+ "stage": "Applicare /etc/pve a PMxcfs",
+ "time": "~10 s",
+ "detail": "Veloce — piccoli file di configurazione copiati uno per uno al filesystem live cluster."
+ },
+ {
+ "stage": "Ricostruire initramfs attraverso i kernel",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all ricostruisce un'immagine initramfs per kernel installato. La maggior parte dell’attesa."
+ },
+ {
+ "stage": "Ricostruisci la configurazione del bootloader",
+ "time": "10–30 s",
+ "detail": "update-grub o proxmox-boot-tool refresh. Veloce anche su ZFS."
+ },
+ {
+ "stage": "Reinstallazione del driver NVIDIA (se applicabile)",
+ "time": "5–10 min",
+ "detail": "Scarica la versione del driver registrato, compila i moduli DKMS contro il kernel corrente, applica la patch ProxMenux se la sorgente lo avesse. Il compito più lungo."
+ },
+ {
+ "stage": "Reinstallazione di Coral e degli altri componenti",
+ "time": "3–5 min",
+ "detail": "Compilazioni DKMS per Coral, apt install per intel-gpu-tools, .deb download + install per amdgpu_top."
+ },
+ {
+ "stage": "Controllo di sicurezza + notifica",
+ "time": "~2 s",
+ "detail": "Richiede poche risorse. La notifica informa l’utente appena l’esecuzione termina."
+ }
+ ],
+ "outroBody": "In questo intervallo possono mancare strumenti dopo l’accesso (nvidia-smi non trovato, coral non rilevato), perché la reinstallazione continua in background. La notifica segna la fine del processo: controlla risultati dei componenti, avvisi e log per distinguere successi ed errori individuali."
+ },
+ "destructiveRollback": {
+ "heading": "Il rollback distruttivo opzionale",
+ "body": "Il ripristino è additivo per impostazione predefinita: VM, LXC e componenti aggiuntivi restano presenti. In caso di differenze, il dialogo offre Eseguire il rollback distruttivo?, con No predefinito. Accettare richiama _rs_execute_rollback prima del riavvio per tentare di eliminare le VM e gli LXC aggiuntivi elencati. I componenti vengono segnalati per la disinstallazione manuale, perché quella automatica non è implementata. Gli errori di eliminazione vengono riportati e il processo continua: non è garantita una corrispondenza esatta. Verifica nomi e VMID/CTID prima di questa scelta distruttiva."
+ },
+ "logs": {
+ "heading": "Dove vivono i registri",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Scritto nella fase interattiva: risultati di compatibilità, filtro delle differenze, piano di adattamento, output dell’applicazione diretta e della preparazione differita, installazione dei pacchetti."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Scritto da apply_pending_restore.sh all’inizio dell’avvio: caricamento di plan.env, elaborazione di apply-on-boot e filtro dei percorsi esclusi."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Scritto da apply_cluster_postboot.sh: applicazione della configurazione pve-cluster, output di initramfs e bootloader, output degli installatori dei componenti, verifica dell’avvio e contenuto della notifica."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "Un log per componente installer (nvidia, coral, ecc.) che ha eseguito nel passaggio post-boot. Utile quando la reinstallazione di un componente specifico è fallita e l'utente ha bisogno dell'output dello strumento."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Scritto da _rs_import_data_pools. Contiene: enumerazione di non-root pools dal manifesto, per-pool esito (importato in modo pulito, importato con -f per hostid straniero, saltato a causa di dischi mancanti, o fallito), e l'uscita grezza di ogni zpool import Chiama."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Dove andare dopo",
+ "items": [
+ {
+ "label": "Ripristino tra kernel diversi",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": "— il filtro safe-subset direzionale e il passaggio di idratazione invocato quando il kernel di destinazione differisce dal backup."
+ },
+ {
+ "label": "Come funziona",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": "— il layout dell'archivio, l'inventario manifesto e dell'applicazione che il ripristino consuma."
+ },
+ {
+ "label": "Lavori programmati",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": " — il processo automatico che produce gli archivi usati da questo ripristino."
+ }
+ ]
+ }
+}
diff --git a/web/messages/it/docs/backup-restore/scheduled-jobs.json b/web/messages/it/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..6a851dc3
--- /dev/null
+++ b/web/messages/it/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Nuovo lavoro indipendente — 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.",
+ "Collega a un’attività vzdump PVE esistente — 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 stesso ciclo di backup. Nel ripristino, le configurazioni dei guest provengono dal backup dell’host (in /etc/pve) 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 OnCalendar propria (sintassi del calendario systemd, ad esempio daily o Mon..Fri 03:00).",
+ "retention": "Richiesti separatamente: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups dell’attività principale (mappata uno a uno alle variabili KEEP_* dello script di esecuzione tramite hb_pve_prune_to_keep_env)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Come funziona la modalità di collegamento",
+ "intro": "PVE scrive le attività vzdump in /etc/pve/jobs.cfg, 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 hb_pve_list_vzdump_jobs_for_backend. L'utente ne sceglie uno."
+ },
+ {
+ "step": "2",
+ "detail": "Il file .env dell’attività è scritto con PVE_PARENT_JOB, PVE_STORAGE e i valori ereditati KEEP_*; non viene creato alcun timer systemd."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook registra un hook in /etc/vzdump.conf. Nella fase job-end di qualsiasi attività vzdump confronta il $STOREID ricevuto con il PVE_STORAGE 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: path/dump/ 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 KEEP_*, 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 run_scheduled_backup.sh JOB_ID. Il timer lo programma con Persistent=true (esecuzioni saltate recuperate al prossimo avvio) e un piccolo RandomizedDelaySec=120 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 hb_install_vzdump_hook; confronta PVE_STORAGE di ogni attività collegata con $STOREID, 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": [
+ "Prepara il backup. 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.",
+ "Scrivi nella destinazione. Carica o scrive l'archivio alla destinazione configurata — un file .tar.zst 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.",
+ "Applica la conservazione. Rimuove i vecchi backup dalla destinazione, mantenendo i conti keep-last / keep-daily / keep-weekly configurati sul lavoro. La potatura viene eseguita dalla destinazione stessa: PBS applica la propria ritenzione, Borg esegue borg prune, e per Local ProxMenux elimina i file che cadono fuori dalla finestra keep-last."
+ ]
+ },
+ "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à: systemctl enable/disable --now il timer. Modalità di aggancio: cambia il flag ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log: 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 hb_notify_lifecycle del flusso interattivo (start, complete, fail). 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à."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/creating-backups.json b/web/messages/pt/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..99ed48c1
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/creating-backups.json
@@ -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 exatamente as mesmas funções. 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 (_bk_pbs, _bk_borg ou _bk_local). 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 backup_menu em backup_host.sh."
+ },
+ {
+ "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: manual (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 agendado (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 run_scheduled_backup.sh; 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 .tar.zst 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 .tar.zst local."
+ }
+ ]
+ },
+ "profiles": {
+ "heading": "Perfil padrão vs personalizado",
+ "defaultTitle": "Perfil padrão",
+ "defaultBody": "O perfil padrão é a lista com curadoria de hb_default_profile_paths (documentada em Como funciona sob Categorias de caminho) além de cada entrada no arquivo de extras persistente /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). O usuário marca os caminhos para esta execução e pode pressionar Adicionar caminho personalizado para incluir um novo caminho absoluto. Todo caminho adicionado durante esse processo é salvo em backup-extra-paths.txt, 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 Gerenciar caminhos personalizados, 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. hb_prepare_staging monta a árvore do arquivo em /tmp/proxmenux-DESTINATION-stage.XXXXXX e preenche cada um dos três blocos de dados.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "Montagem do rootfs",
+ "detail": "Executa rsync -a para cada caminho selecionado em staging_root/rootfs/. O banco de dados pmxcfs em /var/lib/pve-cluster/config.db é capturado separadamente via sqlite3 .backup para produzir um instantâneo consistente sem parar o cluster, e os sidecars .db-wal / .db-shm são excluídos do rsync; quando o sqlite3 não está disponível é salvo um arquivo config.db.raw-fallback, 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 /root/. Caminhos ausentes da fonte são registrados em metadata/missing_paths.txt sem parar o backup."
+ },
+ {
+ "step": "2",
+ "name": "Geração do manifesto",
+ "detail": "build_manifest.sh coordena os seis coletores e grava manifest.json 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": "apt-mark showmanual é capturada literalmente em metadata/packages.manual.list. O estado do componente já está dentro do rootfs restaurado (components_status.json) porque o /usr/local/share/proxmenux/ faz parte do perfil padrão."
+ },
+ {
+ "step": "4",
+ "name": "Informações da execução",
+ "detail": "metadata/run_info.env 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": "hb_notify_lifecycle \"start\" é acionado. Se as notificações estiverem configuradas no Monitor, um evento Backup do host iniciado é enviado ao usuário. Nada é enviado se não houver canais configurados."
+ }
+ ]
+ },
+ "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 rsync -aAXH --numeric-ids. 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": [
+ "images/ — dumps de imagens.",
+ "dump/ — saídas vzdump.",
+ "tmp/ — ficheiros temporários.",
+ "*.log — ficheiros de registo."
+ ],
+ "rootTitle": "Exclusões /root/",
+ "rootBody": "/root/ 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": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "Exclusões /usr/local/share/proxmenux/",
+ "proxmenuxBody": "Este diretório envia apenas o estado do usuário — components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Caminhos fora do perfil",
+ "notInProfileBody": "Qualquer coisa não listada no hb_default_profile_paths e não adicionada como um extra personalizado ou persistente não faz parte do backup. Exemplos notáveis:",
+ "notInProfileItems": [
+ "Discos de VMs e LXC — manipulado por vzdump, não por esta característica. Os arquivos de configuração de hóspedes sob /etc/pve/nodes/*/qemu-server/*.conf e lxc/*.conf são capturados (eles vivem sob /etc/pve) 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.",
+ "/boot e /boot/efi — binários do kernel, initramfs e a partição UEFI ESP são regeneradas pelo próprio alvo update-initramfs, update-grub ou proxmox-boot-tool refresh após a restauração. O carregador de arranque nunca é copiado na íntegra.",
+ "Sistemas de arquivos de tempo de execução e sistema — /proc, /sys, /dev e /run são pseudo-sistemas de arquivos produzidos pelo kernel e udev; eles não são persistidos em nenhum lugar.",
+ "Binários dos pacotes em /usr/bin, /usr/lib, /lib, /sbin — reinstalados pelo APT do destino a partir de packages.manual.list.",
+ "/var/log/, /var/tmp/, /var/cache/ — estado de execução por host, não restaurado.",
+ "/home/USER — 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 backup-extra-paths.txt passa pelo mesmo pipeline rsync como caminhos de perfil padrão. Exclusões globais aplicam-se. Se o caminho personalizado estiver sob /root/ ou /usr/local/share/proxmenux/, as exclusões específicas do caminho acima ainda se aplicam. Cada caminho arquivado — padrão ou personalizado — é gravado em metadata/paths_archived.txt. Caminhos que não existem na fonte são gravados em metadata/missing_paths.txt 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 .pxar 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 trap 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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar solta um *.proxmenux.json 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": "hb_notify_lifecycle \"complete\" ou \"fail\" é 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/cross-kernel.json b/web/messages/pt/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..e20f608e
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve. Os dois primeiros números (6.17 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, hb_compat_check compara o kernel registrado no manifesto do backup com o kernel atual do alvo (uname -r) e classifica a restauração em um dos três casos, armazenados na variável interna HB_COMPAT_KERNEL_DIRECTION:",
+ "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 same, 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 mais antigo 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 uname -r 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 intel_iommu=on 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 hb_unsafe_paths_cross_version para RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) que podem bloquear o pool como estrangeiro."
+ },
+ {
+ "category": "Fontes APT",
+ "paths": "/etc/apt",
+ "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": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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, GRUB_TIMEOUT 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). _rs_hyd_grub mescla os parâmetros de manifest.kernel_params.cmdline_extra do backup em GRUB_CMDLINE_LINUX_DEFAULT do destino, ignorando chaves já presentes. Depois restaura as chaves permitidas GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) de /etc/default/grub do backup se seus valores diferirem do destino."
+ },
+ {
+ "phase": "1b — systemd-boot / ZFS",
+ "detail": "Para systemd-boot (normalmente ZFS na raiz). _rs_hyd_kernel_cmdline mescla parâmetros do usuário de cmdline_extra em /etc/kernel/cmdline do destino, preservando os parâmetros de inicialização root=, boot= e rootflags= do destino."
+ },
+ {
+ "phase": "2 — fusão /etc/modules",
+ "detail": "_rs_hyd_modules adiciona os módulos de manifest.kernel_params.modules_loaded_at_boot que estão na lista branca (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) E ainda não está presente no objectivo /etc/modules."
+ },
+ {
+ "phase": "3 — Cópia de ficheiros na lista branca",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d, e a regra de ligação ProxMenux VFIO + nvidia regras udev sob /etc/udev/rules.d. Arquivos distro-proprietários (pve-blacklist.conf, mdadm.conf, nvme.conf) 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 HB_HYDRATION_APPLIED=1 propaga-se através do plan.env ao apply_pending_restore.sh, que força o NEEDS_INITRAMFS=1 e o NEEDS_GRUB=1 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 _rs_apply_bk_older_hydration no modo plan: calcula exatamente o que seria mesclado, povoa o RS_HYDRATION_SUMMARY 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 commit — 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: intel_iommu=on iommu=pt no cmdline, vfio/vfio_pci/vfio_iommu_type1 no /etc/modules, um /etc/modprobe.d/vfio.conf com options vfio-pci ids=10de:2216, e um /etc/modprobe.d/blacklist-nvidia.conf. A hidração funde os tokens cmdline com o GRUB ou o kernel cmdline do alvo, adiciona os módulos vfio ao /etc/modules 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: GRUB_TIMEOUT=1 e GRUB_DISABLE_OS_PROBER=true. Hydration lê ambas as chaves do /etc/default/grub, vê que elas diferem dos padrões da instalação recente, e reescreve essas duas linhas no arquivo do alvo (deixando tudo, incluindo o GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Qualquer coisa fora desse conjunto — ganchos de initramfs personalizados sob /etc/initramfs-tools/hooks/, arquivos não listados em /etc/modprobe.d/, 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 /sys, ganchos udev) 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": "hb_compat_check em lib_host_backup_common.sh. Define HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Lista de caminhos do filtro seguro",
+ "location": "hb_unsafe_paths_cross_version em lib_host_backup_common.sh. Emite path\\treason linhas usadas tanto pelo filtro CLI como pelo endpoint da Web /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Fases de hidratação",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files em backup_host.sh. Orquestrado por _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Regeneração forçada após a inicialização",
+ "location": "apply_pending_restore.sh lê HB_HYDRATION_APPLIED de plan.env e força NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Visualização da Web",
+ "location": "/api/host-backups/restore/prepare em flask_server.py. Carrega a biblioteca auxiliar, executa _rs_apply_bk_older_hydration 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 kernel_params lido pela hidratação."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/destinations/borg.json b/web/messages/pt/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..fe9ae079
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/destinations/borg.json
@@ -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 borg create para o backup e borg extract 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 hb_ensure_borg resolve o binário de quatro fontes em ordem e retorna o primeiro que funciona:",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Sistema borg",
+ "detail": "Se o host já tem borg instalado via APT (which borg resolve), esse binário é usado."
+ },
+ {
+ "priority": "2",
+ "source": "Cache 'State-dir'",
+ "detail": "/usr/local/share/proxmenux/borg — mantido de um anterior download GitHub neste host."
+ },
+ {
+ "priority": "3",
+ "source": "Pacote AppImage do Monitor",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — o AppImage agrupa um borg-linux64 assinado. Este é o caminho offline: um host sem internet ainda tem um borg funcionando."
+ },
+ {
+ "priority": "4",
+ "source": "Transferência do GitHub",
+ "detail": "wget contra a URL borg-linux64 fixada em github.com/borgbackup/borg/releases/, verificada contra uma constante SHA-256 em lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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 remote 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 /usr/bin/borg",
+ "detail": "A linha command=\"/usr/bin/borg serve ...\" gravada pelo ProxMenux em authorized_keys usa esse caminho fixo. A instalação via APT (apt install borgbackup) coloca o executável ali. Um binário independente precisa de um link simbólico em /usr/bin/borg."
+ },
+ {
+ "requirement": "Uma conta de usuário dedicada (tipicamente borg)",
+ "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 /backup/borgbackup) deve existir no servidor e ser propriedade do usuário borg."
+ },
+ {
+ "requirement": "O servidor SSH aceita o usuário borg",
+ "detail": "PubkeyAuthentication yes (padrão). A autenticação por senha só é necessária para instalar a chave pelo fluxo generate-auto. 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, generate-auto instala a chave por uma conta que possa gravar em authorized_keys do usuário borg. Os backups seguintes usam essa chave, restrita a borg serve 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 borg serve. Este usuário é tipicamente chamado borg, 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, porta 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 ~/.ssh/borg_proxmenux_HOST_ed25519 e usa sshpass para testar o acesso e instalar a chave pública em ~borg/.ssh/authorized_keys. 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 authorized_keys 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 pct exec do host PVE — root no host PVE escreve no LXC ~borg/.ssh/authorized_keys sem precisar de SSH no próprio LXC."
+ },
+ {
+ "mode": "existing",
+ "label": "Usar uma chave existente",
+ "detail": "O ProxMenux procura em /root/.ssh/ e $HOME/.ssh/ 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 ~/.ssh/id_rsa ou um agente SSH)."
+ }
+ ],
+ "restrictTitle": "A linha authorized_keys",
+ "restrictBody": "Para cada chave gerada, a linha authorized_keys 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 command= força cada sessão de SSH usando esta chave para executar apenas o comando borg-serve; restrict 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: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. hb_collect_borg_configs 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 (chmod 600). 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 hb_borg_init_if_needed: o moderno borg repo-create -e MODE quando disponível, ou o legado borg init --encryption=MODE. ProxMenux expõe dois modos: repokey (padrão) e none. No modo repokey 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 borg-pass-NAME.txt 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 borg. 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. Quando um destino é adicionado com uma porta diferente da padrão, o ProxMenux acrescenta também -p PORT; os destinos guardados, as tarefas agendadas e o Monitor usam antes a porta do URL ssh://. Sem chave personalizada, e num destino novo 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 repokey. Nunca aparece na lista de argumentos do processo."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Usado pelo hb_borg_init_if_needed ao inicializar um repositório que ainda não existe. Ignorado pelo borg create 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 run_scheduled_backup.sh executa borg prune contra o repositório após cada backup bem sucedido com os valores de retenção configurados no trabalho (--keep-last, --keep-daily, --keep-weekly). 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 borg list REPO e extrai o selecionado com borg extract REPO::ARCHIVE-NAME em um diretório de preparação. _rs_check_layout 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 Como funciona."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/destinations/index.json b/web/messages/pt/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..0f92be36
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — mas todos os três compartilham a mesma etapa de preparação temporária (hb_prepare_staging) 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 .tar.zst (ou .tar.gz se o zstd estiver ausente).",
+ "pbs": "Backup PBS (blocos .pxar no datastore).",
+ "borg": "Arquivo Borg dentro de um repositório Borg (arquivos de segmentos)."
+ },
+ {
+ "feature": "Compressão",
+ "local": "zstd (nível padrão) via tar --zstd. 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 KEEP_LAST. 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Os backups interativos não fazem limpeza.",
+ "borg": "Aplicado por trabalho programado via borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (presente no Proxmox por padrão).",
+ "pbs": "Pacote proxmox-backup-client (incluído no Proxmox VE 8+).",
+ "borg": "binário borg. 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 proxmox-backup-client, credenciais PBS e o arquivo de chave (se o backup estiver criptografado).",
+ "borg": "Requer borg + 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 rootfs/ + metadata/ + manifest.json layout descrito em Como funciona está presente. Um .tar.zst extraído de um arquivo local, um .pxar restaurado de PBS, e um arquivo Borg extraído com borg extract todos produzem uma árvore de diretórios idêntica. O caminho do código de restauração (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) lê as mesmas três cargas úteis sem saber de que destino vieram."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/destinations/local.json b/web/messages/pt/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..01c392f8
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst (ou .tar.gz quando zstd está ausente). O arquivo contém toda a árvore de arquivos — manifest.json, metadata/ e rootfs/ — e pode ser restaurado em qualquer host Proxmox com o fluxo de restauração ProxMenux, ou extraído manualmente com tar --zstd -xf 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 único diretório de destino salvo de forma persistente — não uma lista. ProxMenux armazena a escolha do operador em /usr/local/share/proxmenux/local-target.conf e lê essa escolha em cada backup. Quando nenhum alvo foi configurado, o HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump padrão é usado (o mesmo diretório que o Proxmox usa para suas próprias saídas vzdump). O alvo está configurado a partir de Configure destinos de backup → Destinos locais:",
+ "options": [
+ "Use o padrão (/var/lib/vz/dump). 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.",
+ "Insira um caminho personalizado. Qualquer caminho absoluto do sistema de arquivos pode ser usado: uma montagem NFS, uma partilha SMB montada via fstab, um conjunto de dados dedicado ZFS, um segundo disco interno. ProxMenux valida que o caminho existe e é um diretório antes de persisti-lo.",
+ "Escolha uma unidade USB. 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 lsblk. 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 hb_mount_usb_partition: cria o /mnt/backup-LABEL (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 digite o caminho exato do dispositivo (por exemplo /dev/sdb) 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, _bk_local verifica se o diretório de destino não é um subcaminho de qualquer diretório cujo backup está sendo feito. Um erro comum seria adicionar /root ao perfil e escolher /root/backups 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 readlink -m, 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 tar --zstd -cf — um pipeline de um único comando que comprime ao nível padrão do zstd. Quando zstd não está presente na fonte (raro em Proxmox, mas possível em instalações mínimas), ProxMenux cai de volta para gzip. No caminho de retorno, se o pv 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 pv, o tar -czf simples é usado silenciosamente.",
+ "sourceTitle": "O que vai para o arquivo",
+ "sourceBody": "O comando tar é chamado com -C \"$staging_root\" ., incluindo toda a raiz da área de preparação: rootfs/, metadata/ e manifest.json. 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: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, escrito ao lado do arquivo por hb_write_archive_sidecar. 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 (kind), o ID do trabalho para as execuções agendadas, o modo de perfil usado (default ou custom), 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 *.proxmenux.json nos diretórios locais configurados, e não arquivos *.tar.zst, pois um .tar.zst 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 _rs_check_layout, 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, tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg produz a mesma árvore que o código de restauração consome."
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/destinations/pbs.json b/web/messages/pt/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..1164a2ae
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client — 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 .pxar, criptografia de arquivos de chaves --backup-id) é 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 host/hostcfg-HOSTNAME/BACKUP-TIME. Os dados formam um arquivo .pxar com a estrutura de três blocos descrita em Como funciona. 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, run_scheduled_backup.sh executa proxmox-backup-client prune com --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET e HB_PBS_FINGERPRINT 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 pbs: 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 Configure destinos de backup → destinos de PBS → Adicione PBS. Pede um nome, nome de usuário (root@pam ou user@pbs!token), 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 ([proxmox] ou [manual]). As entradas cuja senha não pôde ser resolvida são marcadas com um aviso ⚠ no password — selecionando-se um aciona uma reentrada de senha antes do backup começar. A impressão digital é passada para proxmox-backup-client através da variável de ambiente PBS_FINGERPRINT; 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 proxmox-backup-client backup. O ProxMenux usa env 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 é hostcfg-HOSTNAME. Pede-se ao operador que o confirme ou edite antes do envio; quaisquer caracteres fora do [A-Za-z0-9_-] são despojados e os traços são aparados. Reutilizar o mesmo ID entre as execuções é intencional — o PBS trata o ID como um group, e cada backup subsequente aparece como um novo backup dentro desse grupo, compartilhando dedup com execuções anteriores.",
+ "pxarTitle": "Por que a fonte é a raiz de estadiamento completa",
+ "pxarBody": "A origem do arquivo .pxar é todo o staging_root: rootfs/, metadata/ e manifest.json em conjunto. Versões anteriores usavam $staging_root/rootfs como origem, deixando metadata/ fora do arquivo. Sem esses dados, a verificação de compatibilidade emitia avisos de mudança de host mesmo ao restaurar no mesmo host. As cópias antigas continuam a ser restauradas pelo caso 3 de _rs_check_layout, que volta a colocar a árvore simples etc/var/root/usr dentro de uma hierarquia rootfs/."
+ },
+ "encryption": {
+ "heading": "Criptografia do lado do cliente",
+ "glossaryHint": "Esta seção usa os termos arquivo de chave, frase secreta e envelope de recuperação. O glossário 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 /usr/local/share/proxmenux/pbs-key.conf 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: Não continua sem criptografia, e Sim passa à segunda etapa. Esta depende da existência de um arquivo de chave em /usr/local/share/proxmenux/pbs-key.conf. 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. Gerar um novo arquivo de chave executa proxmox-backup-client key create --kdf none. Usar um arquivo de chave existente detecta automaticamente uma chave gerenciada pelo PVE: se o repositório PBS selecionado estiver registrado no Proxmox com uma chave de criptografia em /etc/pve/priv/storage/<NAME>.enc, 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 chmod 600.",
+ "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 Usar um arquivo-chave existente. 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 Enviar a chave para o PBS?, com duas respostas. Nenhum artefato de recuperação é enviado ao PBS até o operador responder Sim. O padrão é Não, manter apenas localmente: a chave fica no caminho canônico local, o ProxMenux não envia artefatos de recuperação ao PBS e o operador cuida da cópia externa. O botão Baixar arquivo de chave do Monitor, na linha do destino PBS, fornece essa cópia quando necessário. Ao escolher Sim, enviar, é solicitada duas vezes uma frase secreta de recuperação, verificando se as duas entradas coincidem. O ProxMenux protege o arquivo com AES-256-CBC e PBKDF2 (600.000 iterações, salt aleatório), produzindo pbs-key.recovery.enc. Cada backup criptografado posterior envia esse envelope ao PBS como um grupo de backup associado. Esses envios não transmitem ao PBS a frase secreta nem o arquivo de chave em texto claro. A escolha pode ser alterada a qualquer momento no Monitor: o controle na linha PBS permite Sim ou Não e aplica imediatamente Iniciar envio, Parar envio ou Atualizar frase secreta, conforme o estado atual.",
+ "blobUploadTitle": "Grupo de backup emparelhado no PBS",
+ "blobUploadBody1": "Quando o modo de garantia é Sim, fazer upload, ProxMenux carrega o envelope de recuperação para PBS após cada backup criptografado como um segundo grupo de backup emparelhado com o mesmo nome do grupo host, mas terminando em -keyrecovery. Os dois grupos ficam próximos um do outro na listagem do armazenamento de dados – um para backups de host e outro para envelopes de recuperação. O envelope nunca sai do host em texto simples: a criptografia acontece no próprio host com AES-256-CBC e PBKDF2 antes que qualquer byte seja transmitido (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS recebe apenas o envelope já criptografado.",
+ "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 proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc, ela será copiada sem perguntas para o caminho canônico. Segundo, se houver um grupo -keyrecovery no PBS, será baixado o instantâneo mais recente e solicitada a frase secreta de recuperação para descriptografá-lo. Terceiro, se as opções anteriores falharem ou forem recusadas, o diálogo pedirá o caminho absoluto do arquivo de chave neste host e o copiará para o caminho canônico. O Monitor oferece o mesmo fluxo de importação na janela de detalhes do backup. Um painel âmbar aparece no topo quando Restaurar, Baixar ou Ver conteúdo exige uma chave ausente. Se a chave instalada não corresponde à usada no backup, o PBS retorna wrong key — manifest's key XX does not match provided key YY. As mesmas três ações exibem então um painel estruturado com a impressão digital exigida pelo manifesto em destaque, permitindo identificar qual chave importar para abrir o backup.",
+ "monitorManagementTitle": "Gerenciando o arquivo de chaves do Monitor",
+ "monitorManagementBody": "O Monitor mostra os controles do arquivo de chave diretamente em cada linha de destino PBS na configuração dos backups. Há três ações: Baixar exporta o arquivo atual para o navegador; Enviar substitui o arquivo instalado pelo fornecido pelo operador, sobrescrevendo o anterior somente após a instalação bem-sucedida do novo no caminho canônico; Excluir remove o arquivo do host. Ao lado fica o controle da cópia de recuperação: uma opção Sim/Não para Enviar a chave para o PBS?, um campo de frase secreta quando Sim é escolhido e um botão contextual para aplicar Iniciar envio, Parar envio ou Atualizar frase secreta. Todas as ações usam os mesmos endpoints Flask da interface de terminal; portanto, o efeito em disco e o estado no PBS são idênticos nas duas interfaces."
+ },
+ "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 proxmox-backup-client restore com os mesmos repositório, senha e impressão digital, além de --keyfile se estiver criptografado. O arquivo .pxar é extraído em um diretório de preparação que _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/glossary.json b/web/messages/pt/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..cbb802b5
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/glossary.json
@@ -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 envelope de recuperação. 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. Não é a frase-passe que desbloqueia o próprio arquivo de chaves, 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 blocos antes do envio ao PBS. Sem a chave correspondente, os dados criptografados não podem ser lidos. O ProxMenux o salva em /usr/local/share/proxmenux/pbs-key.conf com modo 600. Proteja-o: o envelope de recuperação 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 de recuperação. Ele só existe quando o arquivo de chaves foi criado com --kdf scrypt (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 ficheiro de chaves protegido por uma camada adicional: é encriptado com a frase-passe de recuperação através de AES-256-CBC e PBKDF2 antes de sair do host. É esta versão protegida que é enviada para o PBS no grupo -keyrecovery. 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 envelope de recuperação no topo."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Opção para proxmox-backup-client key create 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 proxmox-backup-client key create que produz um arquivo de chaves protegido por uma frase-senha do arquivo de chave. 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 openssl enc -aes-256-cbc) para embrulhar o keyfile com a frase-senha de recuperação e produzir o envelope."
+ },
+ {
+ "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 rsync sobre o perfil default mais qualquer caminho custom. 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 Como funciona."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Caminhos personalizados",
+ "def": "Caminhos extras que o usuário adiciona no topo do perfil default. Persistente (armazenada em backup-extra-paths.txt) 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 + datastore + usuário que recebe o backup. Identificado pela string user@realm@host:datastore. 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 proxmox-backup-client através da variável de ambiente PBS_FINGERPRINT."
+ },
+ {
+ "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 -keyrecovery para o envelope de recuperação."
+ },
+ {
+ "id": "backup-id",
+ "term": "ID de backup",
+ "def": "Nome do grupo de backup. ProxMenux padrão para hostcfg-HOSTNAME 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 run_scheduled_backup.sh 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 /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Anexar modo",
+ "def": "Tarefa sem temporizador próprio. Um hook job-end PVE de vzdump a executa após os backups dos convidados quando o armazenamento coincide. A tarefa pai fornece o destino e a retenção, relida da tarefa pai em cada execução, 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 independente trabalho programado; attach-mode 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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 hydration 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 arquivo de chave local. Para restaurar um backup criptografado, primeiro recupere a chave do envelope armazenado no PBS usando a frase-senha de recuperação."
+ }
+ ]
+ }
+ ],
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/how-it-works.json b/web/messages/pt/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..8f8f7845
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/how-it-works.json
@@ -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 (.tar.zst local, backup PBS ou arquivo Borg) mantém essa estrutura. A restauração usa os três: o manifesto é consultado antes das alterações para detectar diferenças e decidir o que excluir; rootfs fornece os arquivos de configuração, aplicados em execução ou após reiniciar; o inventário de aplicativos 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 metadata/ contém as cargas estruturadas; o subdiretório rootfs/ 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 rootfs/ é uma cópia simples do sistema de arquivos criada pelo rsync a partir do host de origem. Contém um perfil padrão de caminhos selecionados para restaurar o Proxmox e os caminhos personalizados adicionados à tarefa ou sessão interativa. A seleção é intencionalmente restrita a caminhos que guardam configuração ou guardam um estado que o Proxmox não consegue recriar sozinho.",
+ "defaultProfileTitle": "O perfil por omissão",
+ "defaultProfileBody": "O perfil padrão é definido por hb_default_profile_paths em lib_host_backup_common.sh. 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 (config.db) é capturado como um instantâneo consistente via sqlite3 .backup sem parar o cluster, e os sidecars .db-wal / .db-shm são excluídos do rsync. Quando o sqlite3 não está disponível, é criado config.db.raw-fallback, 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 .link em /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. Os caminhos voláteis (.bash_history, .cache/, tmp/, .local/share/Trash/) são excluídos da cópia. O /var/lib/proxmenux 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 zpool.cache e hostid."
+ }
+ ],
+ "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 /usr/local/share/proxmenux/backup-extra-paths.txt contém uma lista de caminhos absolutos que o usuário marcou como \"incluir sempre\" nesta máquina. Quando um backup é executado no modo Default, 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; # comentários são permitidos.",
+ "customModeTitle": "2. Modo personalizado (por execução)",
+ "customModeBody": "O lançamento de um backup no modo Custom 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 [+] e pré-selecionados). O usuário seleciona ou desmarca entradas para essa execução específica, e também pode pressionar Adicionar caminho personalizado 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 metadata/missing_paths.txt 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 /etc/wireguard ou /etc/prometheus quando essas ferramentas não estão instaladas."
+ },
+ "manifest": {
+ "heading": "O bloco do manifesto",
+ "intro": "manifest.json é um documento JSON estruturado que descreve o host de origem no momento do backup. É produzido por seis coletores independentes orquestrados por build_manifest.sh. 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 (pveversion), versão PBS se o host executar o papel do servidor de backup, kernel (uname -r), 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 lsusb/lspci), NICs (com a associação MAC, slot PCI e ponte), dispositivos sem fio. As entradas GPU têm uma heurística passthrough_eligible."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "ZFS pools (com pool disco do tipo + membro resolvido para /dev/disk/by-id/*, /dev/disk/by-partuuid/* ou em bruto /dev/sdX caminhos dependendo de como cada pool foi originalmente criado), LVM grupos de volume + finos pools, discos físicos com SMART capacidade, PVE storage.cfg entradas, montagens externas."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Parâmetros adicionados pelo operador em /proc/cmdline, sem os itens padrão como BOOT_IMAGE=, root=, ro/rw, quiet e splash; módulos carregados na inicialização de /etc/modules; caminhos dos arquivos /etc/modprobe.d/*.conf com diretivas efetivas (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Lê /usr/local/share/proxmenux/managed_installs.json (registo de tudo que ProxMenux instalou) e installed_tools.json. Cada entrada mantém o caminho do instalador (menu_script) 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 (qm list) e LXCs (pct list) presentes na hora de backup — VMID, nome, estado atual. Apenas o inventário: os dados reais dos hóspedes são da responsabilidade do vzdump / PBS."
+ }
+ ],
+ "schemaTitle": "Validação do esquema",
+ "schemaBody": "O manifesto valida contra scripts/backup_restore/schema/manifest.schema.json. Executar o build_manifest.sh --validate desencadeia uma validação do esquema JSON do lado Python (exige o python3 + jsonschema). Se o módulo não estiver presente, a verificação é ignorada silenciosamente — a validação é principalmente um auxílio ao desenvolvedor, não uma dependência de execução."
+ },
+ "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 metadata/ 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 apt-mark showmanual com os pacotes APT instalados explicitamente 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, _rs_run_complete_extras lê a lista e aplica um filtro contra remoções em cascata em três etapas: dpkg -s identifica pacotes já instalados, outras versões principais de bibliotecas são detectadas e apt-get install --simulate verifica o risco de remoções em cascata. Os pacotes restantes são instalados com apt-get install -y.",
+ "componentsTitle": "components_status.json (parte dos rootfs)",
+ "componentsBody": "Um registro JSON sob /usr/local/share/proxmenux/ que registra cada componente ProxMenux instalou com seu estado exato: versão, bandeiras ProxMenux específicas (para NVIDIA: patched booleano; para Coral: versão DKMS). Este arquivo vive dentro dos rootfs — não em metadata/ — porque é lido depois que rootfs foi copiado para o alvo. O expedidor pós-boot (apply_cluster_postboot.sh) itera sobre suas entradas e executa o gancho --auto-reinstall 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 --auto-reinstall:",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Lê-se version + patched. 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 .deb 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 packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check. Compara hardware fonte vs. alvo (NICs, IDs de armazenamento), versão PVE e versão principal do kernel. Define HB_COMPAT_KERNEL_DIRECTION (same, bk_newer ou bk_older) e povoa RS_SKIP_PATHS com exclusões de hardware-drift e cross-kernel."
+ },
+ {
+ "stage": "2",
+ "name": "Aplicação em execução",
+ "reads": "rootfs/ (somente caminhos seguros)",
+ "action": "_rs_apply … hot copia entradas hb_classify_path=hot diretamente para o alvo ao vivo. Qualquer coisa sob /etc/pve, /etc/network ou caminhos classificados como reboot/dangerous é adiada."
+ },
+ {
+ "stage": "3",
+ "name": "Preparações pendentes",
+ "reads": "rootfs/ (reboot + caminhos perigosos)",
+ "action": "_rs_prepare_pending_restore prepara os caminhos de risco em /var/lib/proxmenux/pending-restore/, grava plan.env, apply-on-boot.list e rs-skip-paths.txt e ativa proxmenux-restore-onboot.service para a próxima inicialização."
+ },
+ {
+ "stage": "3b",
+ "name": "Importação de pools de dados",
+ "reads": "manifest.storage_inventory + estado ZFS do destino",
+ "action": "_rs_import_data_pools 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 zpool import -f. Se faltar um disco, o pool é ignorado com aviso. O resultado por pool é registrado em /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "stage": "4",
+ "name": "Instalar pacote",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras executa o filtro de segurança em cascata e chama apt-get install -y com a lista de pacotes sobreviventes. Saída completa vai para /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Após o arranque",
+ "reads": "rootfs (já aplicado) + components_status.json",
+ "action": "Após reiniciar, apply_pending_restore.sh reproduz os caminhos diferidos e apply_cluster_postboot.sh executa update-initramfs, update-grub (ou proxmox-boot-tool refresh) e itera sobre components_status.json disparando o gancho --auto-reinstall de cada componente."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Por que dividir o backup em três blocos",
+ "body": "A divisão segue o ciclo de vida dos dados. O sistema de arquivos é transferido com rsync: rápido, transparente e atômico por arquivo. O estado de configuração a interpretar antes das alterações é JSON estruturado, legível separadamente, versionável por esquema e comparável automaticamente com o estado do destino. O software a reinstalar é descrito em um inventário 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."
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/index.json b/web/messages/pt/docs/backup-restore/index.json
new file mode 100644
index 00000000..950b34e2
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/index.json
@@ -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: o sistema de ficheiros, com os diretórios relevantes em /etc, /root e /var/lib/pve-cluster e os caminhos personalizados opcionais; um manifesto estruturado em JSON com o hardware detetado, parâmetros do kernel, configuração de rede, estado do ZFS, utilizadores e entradas cron; e um inventário de aplicações, 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 do host: a instalação do Proxmox, não as aplicações e os sistemas convidados que nela são executados.",
+ "items": [
+ "Não é uma ferramenta de backup de VM/CT. Esta funcionalidade não guarda os discos nem o estado da RAM dos sistemas convidados; essa é a função do vzdump. Os ficheiros de configuração dos convidados (/etc/pve/nodes/<node>/qemu-server/*.conf e lxc/*.conf) são 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.",
+ "Não é uma operação sobre todo o cluster. Cada nó cria a sua própria cópia. A pertença ao cluster é guardada em /etc/pve para permitir reintegrar um nó restaurado, mas recuperar todo o cluster exige coordenar o restauro dos vários nós.",
+ "Não é uma imagem completa do disco. 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 update-initramfs 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 kernel atual do destino, 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 hidratação 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 Como funciona se o objetivo é entender o que o arquivo contém e por quê. Vá para Destinos para configurar o destino da cópia. Leia Restauração e Restauração entre kernels 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/restoring.json b/web/messages/pt/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..44ab6673
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Restaurando um backup — fluxos completos e personalizados ProxMenux",
+ "description": "O fluxo de trabalho completo de restauração. Documenta as três ações disponíveis em qualquer backup (ver, baixar, restaurar), a verificação de compatibilidade e seus resultados, os modos de restauração Full e Custom, a classificação do caminho que decide o que se aplica ao vivo e o que espera pela próxima inicialização, o expedidor on-boot e o passe de reinstalação do componente pós-boot.",
+ "ogTitle": "Cópia de segurança ProxMenux — restauração",
+ "ogDescription": "Fluxos de restauração completos e personalizados com a verificação de compatibilidade, classificação de caminho, despacho on-boot e reinstalação pós-boot.",
+ "twitterTitle": "Restaurando uma cópia de segurança de ProxMenux",
+ "twitterDescription": "Como um backup de host ProxMenux é transformado de volta em um host Proxmox funcionando."
+ },
+ "header": {
+ "title": "Restaurar uma cópia de segurança",
+ "description": "O fluxo de trabalho completo de restauração: de escolher um arquivo para uma máquina de trabalho. Documenta a verificação de compatibilidade, os dois modos de restauração, o expedidor on-boot, o passe de reinstalação pós-boot, e os mecanismos que tornam previsível o cross-host e o cross-kernel.",
+ "section": "Cópias de segurança e restauro"
+ },
+ "intro": {
+ "title": "A restauração reproduz a fonte, não apenas os arquivos",
+ "body": "Restaurar um backup ProxMenux exige mais que extrair arquivos. Antes das alterações, o manifesto é consultado para detectar diferenças entre origem e destino, caminhos que poderiam impedir o boot são excluídos e ajustes do usuário que não podem ser copiados literalmente são adaptados. Após a reinicialização necessária, tenta-se reinstalar os componentes compatíveis registrados (driver NVIDIA, Coral TPU e ferramentas GPU) para o kernel em execução no destino. Um único arquivo orienta a compatibilidade, a classificação dos caminhos e o trabalho durante e após o boot. Verifique os resultados dos componentes e os logs para confirmar o resultado."
+ },
+ "threeActions": {
+ "heading": "Três ações em um backup",
+ "intro": "A seleção de uma cópia de segurança da lista abre um menu com três ações.",
+ "actionRows": [
+ {
+ "action": "Ver",
+ "detail": "Abre uma visão somente de leitura do arquivo: conteúdo manifest.json (nome do host de origem, versão PVE, kernel, hardware, componentes instalados), a lista de caminhos dentro do rootfs/, e uma diff do que mudaria no host atual se o backup fosse aplicado."
+ },
+ {
+ "action": "Transferir",
+ "detail": "Exporta o arquivo como um arquivo portátil .tar.zst (tar comprimido com zstd). Pode ser extraído em qualquer sistema Linux com tar --zstd -xf FILE.tar.zst, ou em macOS/Windows com qualquer ferramenta que suporte zstd (7-Zip, PeaZip, Keka...). A árvore extraída contém manifest.json, metadata/ e rootfs/ — exatamente o mesmo layout que a restauração consome. Útil para inspeção offline ou para restauração em um host sem acesso ao destino original (PBS, Borg)."
+ },
+ {
+ "action": "Restaurar",
+ "detail": "O caminho de escrita. Extrai o arquivo em um diretório de encenação, executa a verificação de compatibilidade e apresenta o seletor de modo (Full ou Custom)."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Verificação da compatibilidade",
+ "intro": "Antes de qualquer arquivo ser escrito, hb_compat_check compara o estado descrito no manifesto contra o host alvo. A verificação executa somente leitura e produz quatro saídas independentes que impulsionam o resto da restauração.",
+ "outputRows": [
+ {
+ "output": "Marca da direcção",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION assume same, bk_newer ou bk_older ao comparar as versões principais do kernel do backup e do destino. Orienta o filtro de caminhos seguros entre kernels, ativo apenas em bk_older, e a adaptação de ajustes descrita na página correspondente."
+ },
+ {
+ "output": "Lista de caminhos excluídos",
+ "detail": "RS_SKIP_PATHS — cada caminho que a restauração não deve aplicar-se. Populado por dois mecanismos: deriva de hardware (falta de NIC, falta de ID de armazenamento, estrangeiro ZFS pool) e — quando a direcção é bk_older — a lista dos caminhos insegura."
+ },
+ {
+ "output": "Plano de remapeamento da NIC",
+ "detail": "Quando um NIC no alvo tem o mesmo MAC que um na fonte, mas um nome diferente (típico após uma troca de placa-mãe), a verificação de compatibilidade registra um plano de renome (HB_NIC_REMAP) que irá reescrever /etc/network/interfaces durante a restauração."
+ },
+ {
+ "output": "Plano de reversão",
+ "detail": "Calculado por compute_rollback_plan.sh. Lista VMs, LXCs e componentes presentes no destino e ausentes do backup. A confirmação permite remover os hóspedes adicionais antes de reiniciar. A remoção dos componentes continua manual e a exclusão dos hóspedes pode falhar, sem garantia de correspondência exata."
+ }
+ ],
+ "reportBody": "A verificação também emite um relatório estruturado (HB_COMPAT_RESULTS) classificado como PASS / INFO / WARN / FAIL. AVISO e entradas de FAIL superfície no painel pré-restaurar; a restauração se recusa a prosseguir apenas quando um FAIL está presente que o usuário não pode resolver clicando em Continuar."
+ },
+ "twoModes": {
+ "heading": "Restauração completa vs Restauração personalizada",
+ "intro": "Após a verificação de compatibilidade, aparece a escolha do modo. Ela determina o que aplicar e não como: os dois modos usam o mesmo processo.",
+ "modeRows": [
+ {
+ "mode": "Restauração completa",
+ "detail": "Aplica cada caminho no arquivo que sobrevive aos filtros de deriva e cross-kernel. Também executa a instalação do pacote e o componente auto-reinstalar passe. Este é o padrão e a escolha recomendada — o objetivo é reproduzir a fonte, não pegar peças."
+ },
+ {
+ "mode": "Restauração personalizada",
+ "detail": "Abre uma lista de verificação mostrando cada caminho que o arquivo carrega. O usuário marca um subconjunto. Os caminhos bloqueados pelo filtro do kernel cruzado aparecem acinzentados e não podem ser selecionados. A instalação do pacote e a auto-reinstalação do componente são ignoradas por padrão no modo Personalizado — o usuário está sinalizando que deseja uma aplicação parcial, não uma reprodução completa."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Como os caminhos são classificados",
+ "intro": "Cada caminho selecionado para a restauração é classificado por hb_classify_path em uma das três categorias. A categoria determina quando o caminho é aplicado ao sistema e porquê.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Caminhos aplicados imediatamente para o sistema de execução. O serviço que os consome capta a mudança por conta própria ou na próxima recarga — não é necessário reiniciar. Estes são a maior parte de um backup: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, arquivos de configuração de serviço geral, etc."
+ },
+ {
+ "class": "reboot",
+ "detail": "Caminhos adiados para a próxima inicialização, em vez de aplicados imediatamente por este processo. Afetam a configuração de boot: a geração do carregador lê /etc/default/grub, as montagens usam /etc/fstab e a carga de módulos usa /etc/modules. Os arquivos pendentes são aplicados após reiniciar e os artefatos de boot necessários são então regenerados. Exemplos: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Caminhos NÃO aplicados no sistema em execução: uma escrita a quente poderia corromper o estado ou cortar a ligação ativa. Ficam no conjunto pendente: /etc/network é escrito no início do arranque seguinte, antes de a rede arrancar, e /etc/pve é escrito pelo dispatcher pós-arranque quando o sistema de ficheiros do cluster está disponível. Exemplos: /etc/pve (pmxcfs é uma montagem FUSE com a configuração ativa do cluster), /var/lib/pve-cluster (dados ativos do cluster, guardados no diretório de recuperação apenas para recuperação manual), /etc/network (poderia reconfigurar a própria interface usada pela ligação SSH e cortar a sessão)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "O fluxo de trabalho completo de restauração",
+ "intro": "O pipeline completo da seleção de arquivos para uma máquina de trabalho restaurada. Cada etapa alimenta a seguinte; o estado escrito por fases anteriores é consumido por fases posteriores.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "A máquina de restauro pendente",
+ "intro": "Os caminhos classificados como reboot ou dangerous, e a hidratação escreve, são encenados para o próximo boot em vez de serem aplicados ao vivo. Isto é feito através de um pequeno conjunto de arquivos auto-suficientes sob /var/lib/proxmenux/pending-restore/:",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "Um caminho relativo por linha — o conjunto exato de caminhos apply_pending_restore.sh será aplicado a partir dos rootfs encenados. A leitura deste ficheiro diz ao utilizador exactamente o que irá mudar na próxima inicialização."
+ },
+ {
+ "file": "plan.env",
+ "content": "Variáveis de ambiente carregadas pelo script de inicialização: ID da restauração, indicadores de compatibilidade (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), consentimento para reversão e opções do cluster."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "A lista final RS_SKIP_PATHS, persistiu assim que apply_pending_restore.sh aplica as mesmas exclusões após reinicialização que foram computadas durante a etapa interativa. Impedi que caminhos inseguros sejam restaurados no momento do arranque."
+ },
+ {
+ "file": "rootfs/",
+ "content": "Os próprios arquivos encenados — os bytes exatos que serão estabelecidos. Mantido no mesmo sistema de arquivos que / para que o rsync on-boot é rápido e não depende de armazenamento externo ainda sendo acessível no arranque."
+ }
+ ],
+ "unitBody": "A unidade systemd proxmenux-restore-onboot.service é ativada ao fim da etapa interativa. Esse serviço executa uma vez no início do próximo boot, chama apply_pending_restore.sh e depois se desativa. A condição ConditionPathExists=/var/lib/proxmenux/pending-restore/state impede qualquer ação quando não há restauração pendente."
+ },
+ "postbootDispatcher": {
+ "heading": "O expedidor pós-boot — apply_cluster_postboot.sh",
+ "intro": "Onde termina o passo interativo e onde acontece a reprodução real do hospedeiro. O apply_cluster_postboot.sh é instalado como uma segunda unidade systemd de um tiro (proxmenux-apply-cluster-postboot.service) cujos alvos After=/Wants= garantem que ele seja executado apenas após pve-cluster e network-online estão em cima. Aqui é onde o hospedeiro-visível restaurar ações terra.",
+ "tasks": [
+ {
+ "task": "Aplicar /etc/pve",
+ "detail": "/etc/pve é uma montagem FUSE ao vivo pmxcfs — não pode ser escrita no arranque inicial. O expedidor copia arquivos dos rootfs pendentes para o /etc/pve ao vivo uma vez que o sistema de arquivos de cluster está acima, um arquivo de cada vez, sem reiniciar pve-cluster. O /var/lib/pve-cluster/config.db capturado do backup (ou o config.db.raw-fallback) é materializado com o systemctl stop pve-cluster → cópia de arquivo atômico → systemctl start pve-cluster padrão, então pmxcfs re-ler o estado restaurado no caminho de volta."
+ },
+ {
+ "task": "Reconstruir initramfs e bootloader",
+ "detail": "Executa update-initramfs -u -k all através de cada kernel instalado, em seguida, update-grub (GRUB instala) ou proxmox-boot-tool refresh (systemd-boot / ZFS instala). Pulou se o passo interativo determinou que nada mudou nos caminhos que afetam essas ferramentas."
+ },
+ {
+ "task": "Reinstalar automaticamente o componente",
+ "detail": "Lê components_status.json restaurado e percorre os instaladores compatíveis (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Cada instalador selecionado usa --auto-reinstall, lê o estado registrado e reinstala para o ambiente de destino, recompilando módulos quando necessário. A operação espera o reboot para usar o kernel então ativo. Falhas individuais são registradas e não interrompem o próximo componente."
+ },
+ {
+ "task": "Verificação da inicialização",
+ "detail": "Antes de iniciar a notificação de conclusão, verifica que proxmox-boot-tool status mostra um ESP configurado, cada /boot/vmlinuz-* tem um diretório /lib/modules/<ver> correspondente, e /vmlinuz resolve. Qualquer inconsistência aparece na notificação em vez de ser escondida."
+ },
+ {
+ "task": "Notificação de conclusão",
+ "detail": "Envia o evento Host restore finished através de hb_notify_lifecycle. Inclui duração total, contagem de caminhos aplicados, avisos de verificação de sanidade, se houver, e um link para o log em /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Se as notificações não forem configuradas, o evento é silencioso — o registro ainda registra tudo."
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Progresso ao vivo na aba Backups do Monitor",
+ "body": "Após a reinicialização da guia Backups do ProxMenux Monitor, um cartão pós-restore ao vivo reflete o estado do proxmenux-apply-cluster-postboot.service enquanto ele é executado. O cartão é conduzido pelo /var/lib/proxmenux/restore-state.json, que o expedidor atualiza em cada marco (aplicar configuração de cluster, reconstruir initramfs, atualizar carregador de boot, reinstalar por componente, verificar sanidade de inicialização, finalizar).",
+ "fields": [
+ {
+ "name": "Emblema de estado",
+ "detail": "Um dos estados Restauração em andamento, Restauração concluída ou Restauração falhou. O cartão consulta o arquivo a cada 2 segundos durante a execução e a cada 30 segundos depois."
+ },
+ {
+ "name": "Barra de progresso + contador de passos",
+ "detail": "Mostra N/M steps e o nome da etapa atual. Durante a restauração, o tempo estimado é calculado com base nas etapas concluídas e no tempo decorrido."
+ },
+ {
+ "name": "Lista de componentes",
+ "detail": "Uma linha por driver sendo reinstalado (NVIDIA, ferramentas Intel GPU, ferramentas AMD, Coral TPU) com installing / ok / failed mais um link para o log por componente em /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Importação de pools de dados",
+ "detail": "O bloco data_pools_import mostra cinco linhas coloridas: Importados, Forçados (com -f por hostid de outro host), Ignorados, discos parciais (apenas alguns discos presentes), Ignorados, discos ausentes (nenhum disco presente) e Falhas. O estado fica em /var/lib/proxmenux/restore-state.json e o log bruto da execução em /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Avisos de integridade de inicialização",
+ "detail": "O processo verifica diretórios /lib/modules/<kernel> ausentes, falta de configuração ESP e links simbólicos /vmlinuz com destino inexistente. Os avisos aparecem em uma faixa colorida."
+ },
+ {
+ "name": "Delta de reversão",
+ "detail": "Lista VMs, LXCs e componentes que existem no alvo, mas não estavam na cópia de segurança restaurada — as mesmas entradas surgiram na janela de rollback destrutivo pré-restore. Cada linha carrega o comando de limpeza manual."
+ },
+ {
+ "name": "Cauda de log",
+ "detail": "A última 600 linhas de proxmenux-cluster-postboot-<ts>.log, com Apenas questões filtro que mantém apenas linhas correspondentes error, warning, failed, ✗ ou traceback."
+ }
+ ],
+ "dismissBody": "Uma vez que a restauração é completo ou falhado, um botão de Dispensa colapsa o cartão. O arquivo de estado está preservado e o botão Histórico reabre-o mais qualquer restauração anterior (as últimas execuções 20 são arquivadas sob /var/lib/proxmenux/restore-history/).",
+ "imageAlt": "Janela Detalhes do progresso da restauração no ProxMenux Monitor durante a execução: indicador azul, etapa Reconstruindo initramfs, tempo restante estimado, barra parcialmente preenchida e últimas linhas do log em tempo real.",
+ "imageCaption": "O modal Detalhes enquanto o expedidor pós-boot ainda está em execução — emblema, passo atual, tempo restante e cauda de log ao vivo.",
+ "detailsImageAlt": "O mesmo modo Detalhes após a restauração ter terminado, com o emblema verde Restaurar completo, a duração total de execução (0m53s), uma barra de progresso 6/6, o delta de Rollback vazio e o log de postboot arquivado.",
+ "detailsImageCaption": "O mesmo modal uma vez que a execução tenha terminado — emblema, duração total, barra de progresso preenchida e o log de postboot arquivado."
+ },
+ "postbootExample": {
+ "heading": "Como é o post-boot na consola",
+ "body": "No console físico, um processo encerrado com sucesso mostra [ OK ] Finished proxmenux-apply-cluster-postboot.service, geralmente perto dos OK de multi-user.target e graphical.target. Isso marca o fim do processo. Ainda podem existir falhas de componentes ou avisos de boot registrados; confira os estados e logs no Monitor antes de considerar o host totalmente restaurado.",
+ "imageAlt": "Console físico Proxmox com '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', seguido de OK para multi-user.target e graphical.target, com a solicitação de login acima.",
+ "imageCaption": "Console físico ao fim do processo. 'Finished proxmenux-apply-cluster-postboot.service' marca a conclusão, também indicada por 'Host restore finished' no Monitor. Os resultados dos componentes e os avisos ainda precisam ser verificados."
+ },
+ "tenMinutes": {
+ "heading": "Por que os últimos dez minutos importam",
+ "intro": "A reinicialização em si leva segundos, mas o expedidor pós-boot passa cerca de dez minutos terminando a restauração. Durante esta janela, o host é acessível e o login funciona, mas alguns serviços (principalmente GPU-driver-dependentes) ainda não estão disponíveis. Discriminação de tempo para um host Proxmox típico com NVIDIA + Coral instalado:",
+ "rows": [
+ {
+ "stage": "Boot + pve-cluster pronto",
+ "time": "~30 s",
+ "detail": "Inicialização padrão do Proxmox. SSH, interface web e login ficam disponíveis ao fim desta etapa."
+ },
+ {
+ "stage": "Aplicar /etc/pve aos pmxcfs",
+ "time": "~10 s",
+ "detail": "Rápido — pequenos arquivos de configuração copiados um por um para o sistema de arquivos de cluster ao vivo."
+ },
+ {
+ "stage": "Reconstruir initramfs entre kernels",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all reconstrói uma imagem initramfs por kernel instalado. O volume da espera."
+ },
+ {
+ "stage": "Reconstruir a configuração do carregador de arranque",
+ "time": "10–30 s",
+ "detail": "update-grub ou proxmox-boot-tool refresh. Rápido mesmo em ZFS."
+ },
+ {
+ "stage": "Reinstalação do controlador NVIDIA (se aplicável)",
+ "time": "5–10 min",
+ "detail": "Baixa a versão gravada do driver, compila os módulos DKMS contra o kernel atual, aplica o patch ProxMenux se a fonte o tiver. Uma tarefa mais longa."
+ },
+ {
+ "stage": "Reinstalação do Coral e de outros componentes",
+ "time": "3–5 min",
+ "detail": "Compilação DKMS para Coral, apt install para intel-gpu-tools e download e instalação do .deb para amdgpu_top."
+ },
+ {
+ "stage": "Verificação de inicialização e notificação",
+ "time": "~2 s",
+ "detail": "Exige poucos recursos. A notificação informa o usuário assim que a execução termina."
+ }
+ ],
+ "outroBody": "Nesse intervalo, ferramentas podem faltar após o login (nvidia-smi não encontrado, coral não detectado) porque a reinstalação continua em segundo plano. A notificação marca o fim do processo; confira resultados dos componentes, avisos e logs para distinguir sucessos de falhas individuais."
+ },
+ "destructiveRollback": {
+ "heading": "O retrocesso destrutivo opcional",
+ "body": "A restauração é aditiva por padrão: VMs, LXCs e componentes adicionais permanecem. Se houver diferenças, a confirmação oferece Executar reversão destrutiva?, com Não por padrão. Aceitar chama _rs_execute_rollback antes do reboot para tentar excluir as VMs e os LXCs adicionais listados. Componentes são indicados para desinstalação manual, pois a automática não foi implementada. Falhas de exclusão são informadas e o processo continua, sem garantia de correspondência exata. Confira nomes e VMIDs/CTIDs antes dessa opção destrutiva."
+ },
+ "logs": {
+ "heading": "Onde ficam os logs",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Gravado na etapa interativa: resultados de compatibilidade, filtro de diferenças, plano de adaptação, saídas da aplicação em execução e da preparação pendente, instalação de pacotes."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Gravado por apply_pending_restore.sh no início do boot: carregamento de plan.env, processamento de apply-on-boot e filtro dos caminhos excluídos."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Escrito por apply_cluster_postboot.sh. Contém: pve-cluster aplicar, initramfs e saída bootloader, por componente saída instalador, verificação de sanidade, carga útil de notificação."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "Um log por componente instalador (nvidia, coral, etc.) que correu na passagem pós-boot. Útil quando a reinstalação de um componente específico falhou e o usuário precisa da própria saída da ferramenta."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Escrito por _rs_import_data_pools. Contém: enumeração de pools não-root do manifesto, resultado por pool (importado de forma limpa, importado com -f para hostida estrangeira, ignorado devido à falta de discos, ou falhou), e a saída bruta de cada chamada zpool import."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Para onde ir a seguir",
+ "items": [
+ {
+ "label": "Restauração do kernel cruzado",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": " — o filtro seguro de direcção e o passe de hidratação invocado quando o núcleo alvo difere do do backup."
+ },
+ {
+ "label": "Como funciona",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": " — a estrutura do arquivo, o manifesto e o inventário de aplicativos usados pela restauração."
+ },
+ {
+ "label": "Trabalhos agendados",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": " — o fluxo não acompanhado que produz os arquivos que esta página consome."
+ }
+ ]
+ }
+}
diff --git a/web/messages/pt/docs/backup-restore/scheduled-jobs.json b/web/messages/pt/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..44f8fe5a
--- /dev/null
+++ b/web/messages/pt/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Novo trabalho independente — 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.",
+ "Anexar a uma tarefa existente PVE vzdump — 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 mesmo ciclo de backup. Na restauração, as configurações dos convidados vêm do backup do host (em /etc/pve) 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 OnCalendar própria (sintaxe de calendário systemd, por exemplo daily ou Mon..Fri 03:00).",
+ "retention": "Solicitado separadamente: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups da tarefa principal (mapeada um a um para as variáveis KEEP_* do script de execução via hb_pve_prune_to_keep_env)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Como funciona o modo de anexação",
+ "intro": "O PVE grava as tarefas vzdump em /etc/pve/jobs.cfg, 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 hb_pve_list_vzdump_jobs_for_backend. O utilizador escolhe uma."
+ },
+ {
+ "step": "2",
+ "detail": "O .env do trabalho é escrito com PVE_PARENT_JOB, PVE_STORAGE e os valores herdados KEEP_*; nenhum temporizador systemd é criado."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook registra um hook em /etc/vzdump.conf. Na fase job-end de qualquer tarefa vzdump, compara o $STOREID recebido com o PVE_STORAGE 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: path/dump/ 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 KEEP_*, 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 run_scheduled_backup.sh JOB_ID. O timer agenda-o com Persistent=true (execuções perdidas recuperadas na próxima inicialização) e um pequeno RandomizedDelaySec=120 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 hb_install_vzdump_hook; compara PVE_STORAGE de cada trabalho anexado com $STOREID, 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": [
+ "Prepare o backup. 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.",
+ "Escreva o destino. Envia ou escreve o arquivo para o destino configurado — um arquivo .tar.zst local, um backup PBS, ou um arquivo Borg — usando exatamente as mesmas ferramentas e credenciais que um backup manual para o mesmo destino usaria.",
+ "Aplicar retenção. Remove backups antigos do destino, mantendo as contagens keep-last / keep-daily / keep-weekly configuradas no trabalho. A poda é realizada pelo próprio destino: PBS aplica sua própria retenção, Borg executa borg prune, e para ProxMenux Local apaga os arquivos que caem fora da janela keep-last."
+ ]
+ },
+ "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: systemctl enable/disable --now o temporizador. Modo Anexar: altera o sinalizador ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — 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 hb_notify_lifecycle que o fluxo interativo (start, complete, fail). Se os canais de notificação estiverem configurados no Monitor, os trabalhos não vigiados mostram seus resultados da mesma forma que backups manuais – um usuário não precisa verificar o log para saber se um trabalho foi bem sucedido."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/creating-backups.json b/web/messages/sk/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..3fc89c76
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/creating-backups.json
@@ -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ú presne rovnaké funkcie. 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 (_bk_pbs, _bk_borg alebo _bk_local). 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 backup_menu v backup_host.sh."
+ },
+ {
+ "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: manuálne (interaktívny postup opísaný na tejto stránke — používateľ vyberie cieľ a profil z ponuky a sleduje uloženie archívu) alebo plánovane (ú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 run_scheduled_backup.sh 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 .tar.zst 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 .tar.zst otvorí výber ciest."
+ }
+ ]
+ },
+ "profiles": {
+ "heading": "Štandardný vs vlastný profil",
+ "defaultTitle": "Predvolený profil",
+ "defaultBody": "Predvolený profil je pripravený zoznam z hb_default_profile_paths (opísaný v časti Ako to funguje pod nadpisom Kategórie ciest) spolu so všetkými položkami zo súboru trvalých doplnkov /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). Používateľ zaškrtne cesty pre toto spustenie a cez Pridať vlastnú cestu môže doplniť novú absolútnu cestu. Takto pridaná cesta sa uloží do backup-extra-paths.txt, 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 Spravovať vlastné cesty 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. hb_prepare_staging zostaví strom archívu v /tmp/proxmenux-DESTINATION-stage.XXXXXX a naplní každý z troch blokov údajov.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "Zostava rootfs",
+ "detail": "Pre každú vybranú cestu spustí rsync -a do staging_root/rootfs/. Databáza pmxcfs v /var/lib/pve-cluster/config.db sa zachytí samostatne cez sqlite3 .backup, aby vznikla konzistentná snímka bez zastavenia klastra; pomocné súbory .db-wal / .db-shm sa z rsync vylúčia. Ak sqlite3 nie je dostupné, uloží sa namiesto toho súbor config.db.raw-fallback, ktorý obnova pri importe prevezme ako databázu. Z /root/ sa vylúčia dočasné podcesty (história bash, vyrovnávacie pamäte, kôš). Cesty chýbajúce v zdroji sa zapíšu do metadata/missing_paths.txt bez zastavenia zálohy."
+ },
+ {
+ "step": "2",
+ "name": "Vytvorenie manifestu",
+ "detail": "build_manifest.sh koordinuje šesť zberných modulov a zapíše manifest.json 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": "apt-mark showmanual je zachytený doslovne do metadata/packages.manual.list. Stav komponentu je už vnútri obnovených rootfs (components_status.json), pretože /usr/local/share/proxmenux/ je súčasťou štandardného profilu."
+ },
+ {
+ "step": "4",
+ "name": "Informácie o spustení",
+ "detail": "metadata/run_info.env 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 hb_notify_lifecycle \"start\". Ak sú v Monitore nastavené upozornenia, používateľ dostane udalosť Zálohovanie hostiteľa sa začalo. 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 rsync -aAXH --numeric-ids. 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": [
+ "images/ — výpisy obrazov.",
+ "dump/ — výstupy vzdump.",
+ "tmp/ - dočasné súbory.",
+ "*.log — súbory záznamov."
+ ],
+ "rootTitle": "Výnimky /root/",
+ "rootBody": "/root/ 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": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "Výnimky /usr/local/share/proxmenux/",
+ "proxmenuxBody": "Tento adresár obsahuje iba používateľský stav — components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Cesty mimo profilu",
+ "notInProfileBody": "Všetko, čo nie je uvedené v hb_default_profile_paths a nepridal ako vlastné alebo trvalé extra nie je súčasťou zálohy. Pozoruhodné príklady:",
+ "notInProfileItems": [
+ "Disky VM a LXC — zálohuje ich vzdump, nie táto funkcia. Konfiguračné súbory hostí v /etc/pve/nodes/*/qemu-server/*.conf a lxc/*.conf sa zachytia (nachádzajú sa v /etc/pve), aby obnova obnovila inventár; samotné disky sa znovu pripoja z existujúcej zálohy vzdump/PBS.",
+ "/boot a /boot/efi — binárne súbory jadra, initramfs a oddiel UEFI ESP po obnove znova vytvorí cieľový systém pomocou update-initramfs, update-grub alebo proxmox-boot-tool refresh. Zavádzač sa nikdy nekopíruje doslova.",
+ "Súborové systémy jadra a behu systému — /proc, /sys, /dev a /run sú pseudosúborové systémy vytvárané jadrom a udev; nikde sa trvalo neukladajú.",
+ "Binárne súbory balíkov v /usr/bin, /usr/lib, /lib, /sbin — APT na cieľovom systéme ich znova nainštaluje podľa packages.manual.list.",
+ "/var/log/, /var/tmp/, /var/cache/ — priebežný stav konkrétneho hostiteľa, ktorý sa neobnovuje.",
+ "/home/USER 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 backup-extra-paths.txt prechádza rovnakým postupom rsync ako cesty predvoleného profilu. Platia globálne vylúčenia. Ak sa vlastná cesta nachádza pod /root/ alebo /usr/local/share/proxmenux/, naďalej platia aj uvedené vylúčenia pre konkrétnu cestu. Každá archivovaná cesta — predvolená aj vlastná — sa zaznamená v metadata/paths_archived.txt. Cesty, ktoré v zdroji neexistujú, sa zapíšu do metadata/missing_paths.txt 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 .pxar 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 trap 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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar vytvorí *.proxmenux.json 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 hb_notify_lifecycle \"complete\" alebo \"fail\" 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/cross-kernel.json b/web/messages/sk/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..266aa51c
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve. Prvé dve čísla (6.17) 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 hb_compat_check porovnáva jadro zaznamenané v manifeste zálohy s aktuálnym jadrom cieľa (uname -r) a klasifikuje obnovenie do jedného z troch prípadov, uložené vo vnútornej premennej HB_COMPAT_KERNEL_DIRECTION:",
+ "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 same, 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 starším 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 uname -r a zostavia DKMS pre cieľ. APT použije binárne balíky cieľovej distribúcie. Parametre IOMMU, napríklad intel_iommu=on, 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 hb_unsafe_paths_cross_version do RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid), ktoré môžu uzamknúť pool ako cudzie."
+ },
+ {
+ "category": "APT zdroje",
+ "paths": "/etc/apt",
+ "reason": "Vydania v zdrojoch APT môžu pri ďalšej aktualizácii spôsobiť zníženie verzií kritických balíkov."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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ý GRUB_TIMEOUT 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). _rs_hyd_grub zlúči parametre z manifest.kernel_params.cmdline_extra zálohy do GRUB_CMDLINE_LINUX_DEFAULT cieľa a preskočí existujúce kľúče. Potom obnoví povolené kľúče GRUB_* (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) zo súboru /etc/default/grub 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). _rs_hyd_kernel_cmdline zlúči používateľské parametre z cmdline_extra do cieľového /etc/kernel/cmdline, pričom zachová jeho vlastné parametre štartu root=, boot= a rootflags=."
+ },
+ {
+ "phase": "2 — /etc/modules zlúčenie",
+ "detail": "_rs_hyd_modules dopĺňa moduly z manifest.kernel_params.modules_loaded_at_boot, ktoré sú na bielom zozname (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) a ešte nie sú prítomné v cieľovom /etc/modules."
+ },
+ {
+ "phase": "3 — Kopírovanie povolených súborov",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d a ProxMenux VFIO sa viaže na pravidlo + nvidia udev podľa pravidiel /etc/udev/rules.d. Distro-vlastnené súbory (pve-blacklist.conf, mdadm.conf, nvme.conf) 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, HB_HYDRATION_APPLIED=1 sa šíri cez plan.env na apply_pending_restore.sh, čo núti NEEDS_INITRAMFS=1 a NEEDS_GRUB=1 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í _rs_apply_bk_older_hydration v režime plan: vypočíta zmeny, naplní RS_HYDRATION_SUMMARY 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 commit: 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 intel_iommu=on iommu=pt v cmdline, vfio/vfio_pci/vfio_iommu_type1 v /etc/modules, /etc/modprobe.d/vfio.conf s options vfio-pci ids=10de:2216, a /etc/modprobe.d/blacklist-nvidia.conf. Hydratácia zlučuje žetóny cmdline do cieľovej GRUB alebo jadra cmdline, pridá vfio moduly do /etc/modules, 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 GRUB_TIMEOUT=1 a GRUB_DISABLE_OS_PROBER=true. Hydratácia číta oba kľúče z /etc/default/grub 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 GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Ostatné položky, ako vlastné hooky initramfs v /etc/initramfs-tools/hooks/, nepovolené súbory v /etc/modprobe.d/ a vlastné úpravy jednotiek systemd, zostanú vynechané. Môžu používať rozhrania jadra, rozloženie /sys a hooky udev, 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": "hb_compat_check v lib_host_backup_common.sh. Nastaví HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Zoznam ciest bezpečného filtra",
+ "location": "hb_unsafe_paths_cross_version v lib_host_backup_common.sh. Vypíše path\\treason riadky používané ako CLI filter a webový koncový ukazovateľ /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Hydratačné fázy",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files v backup_host.sh. Orchestrovaný _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Vynútenie obnovy po štarte",
+ "location": "apply_pending_restore.sh prečíta HB_HYDRATION_APPLIED z plan.env a vynúti NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Webový náhľad",
+ "location": "/api/host-backups/restore/prepare v flask_server.py. Načíta pomocnú knižnicu, spustí _rs_apply_bk_older_hydration 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 kernel_params, z ktorého doplnenie číta."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/destinations/borg.json b/web/messages/sk/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..bfa4be4a
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/destinations/borg.json
@@ -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í borg create a pri obnove borg extract. Ú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, hb_ensure_borg vyrieši binárny zo štyroch zdrojov v poradí a vráti prvý, ktorý funguje:",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Systém borg",
+ "detail": "Ak má hostiteľ už borg nainštalovaný cez APT (which borg), použije sa tento binárny kód."
+ },
+ {
+ "priority": "2",
+ "source": "Vyrovnávacia pamäť stavového adresára",
+ "detail": "/usr/local/share/proxmenux/borg — súbor uchovaný po predchádzajúcom stiahnutí z GitHubu na tomto hostiteľovi."
+ },
+ {
+ "priority": "3",
+ "source": "Balík AppImage Monitora",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg — AppImage obsahuje podpísaný borg-linux64. Táto možnosť funguje aj bez internetu: hostiteľ má stále použiteľný borg."
+ },
+ {
+ "priority": "4",
+ "source": "GitHub stiahnuť",
+ "detail": "Stiahnutie pomocou wget z pevne určenej URL súboru borg-linux64 v github.com/borgbackup/borg/releases/, overené oproti konštante SHA-256 v lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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 remote 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 /usr/bin/borg",
+ "detail": "Riadok command=\"/usr/bin/borg serve ...\", ktorý ProxMenux zapíše do authorized_keys, používa túto pevnú cestu. APT (apt install borgbackup) sem program nainštaluje. Samostatný binárny súbor musí mať symbolický odkaz na ceste /usr/bin/borg."
+ },
+ {
+ "requirement": "Dedikovaný užívateľský účet (zvyčajne borg)",
+ "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 /backup/borgbackup) 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": "PubkeyAuthentication yes (predvolené). Overenie heslom je potrebné iba pri inštalácii kľúča cez generate-auto. 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 generate-auto 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 borg serve 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ží borg serve. Tento užívateľ je zvyčajne pomenovaný borg, 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, port 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 ~/.ssh/borg_proxmenux_HOST_ed25519. Pomocou sshpass otestuje prihlásenie a nainštaluje verejný kľúč do ~borg/.ssh/authorized_keys. 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 authorized_keys 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 pct exec z PVE hostiteľa a root na hostiteľovi PVE píše do LXC's ~borg/.ssh/authorized_keys bez potreby SSH do LXC sama o sebe."
+ },
+ {
+ "mode": "existing",
+ "label": "Použiť existujúci kľúč",
+ "detail": "ProxMenux skenuje /root/.ssh/ a $HOME/.ssh/ 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 ~/.ssh/id_rsa alebo agenta SSH."
+ }
+ ],
+ "restrictTitle": "Čiara authorized_keys",
+ "restrictBody": "Pre každý vygenerovaný kľúč obmedzí riadok authorized_keys 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": "command= núti každé SSH sedenie pomocou tohto kľúča spustiť len to borg-serve príkaz; restrict 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ľ: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. Funkcia hb_collect_borg_configs ho načíta pri zostavovaní ponuky cieľov."
+ },
+ {
+ "file": "borg-pass-NAME.txt",
+ "content": "Passfráza pre cieľ uvedený vyššie (chmod 600). 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 hb_borg_init_if_needed: ak je dostupný novší príkaz borg repo-create -e MODE, použije sa ten, inak starší borg init --encryption=MODE. ProxMenux ponúka dva režimy: repokey (predvolený) a none. V režime repokey 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 borg-pass-NAME.txt, 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 borg. 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. Keď sa cieľ prvýkrát pridá s neštandardným portom, ProxMenux pridá aj -p PORT; uložené ciele, plánované úlohy a Monitor namiesto toho používajú port z URL ssh://. Bez vlastného kľúča a pri novom cieli 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 repokey. Nikdy sa neobjaví v zozname procesných argumentov."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Použité hb_borg_init_if_needed pri inicializácii úložiska, ktoré ešte neexistuje. Ignorované borg create 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, run_scheduled_backup.sh beží borg prune proti úložisku po každom úspešnom zálohovaní s retenčnými hodnotami nastavenými na úlohu (--keep-last, --keep-daily, --keep-weekly). Interaktívne zálohy neprerezávajú."
+ },
+ "restoreAccess": {
+ "heading": "Získavanie na strane obnovy",
+ "body": "Obnova vypíše archívy pomocou borg list REPO a vybraný archív rozbalí príkazom borg extract REPO::ARCHIVE-NAME do prípravného adresára. Funkcia _rs_check_layout 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 Ako to funguje."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/destinations/index.json b/web/messages/sk/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..6a89082e
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — všetky tri však zdieľajú rovnaký krok dočasnej prípravy (hb_prepare_staging) 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 .tar.zst (alebo .tar.gz, ak zstd chýba).",
+ "pbs": "Záloha PBS (bloky .pxar v dátovom úložisku).",
+ "borg": "Borg archív vnútri úložiska Borg (segment súbory)."
+ },
+ {
+ "feature": "Kompresia",
+ "local": "zstd (štandardná úroveň) cez tar --zstd. 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 KEEP_LAST. 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Interaktívne zálohy nevykonávajú čistenie.",
+ "borg": "Použité pre každú plánovanú úlohu cez borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (predvolene prítomné na Proxmoxe).",
+ "pbs": "Balík proxmox-backup-client (dodávaný s Proxmox VE 8+).",
+ "borg": "Binárny borg. 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 proxmox-backup-client, prihlasovacie údaje PBS a súbor kľúča (pri šifrovanej zálohe).",
+ "borg": "Vyžaduje borg + 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 rootfs/ + metadata/ + manifest.json opísaná v časti Ako to funguje. Rozbalenie lokálneho archívu .tar.zst, obnova .pxar z PBS aj rozbalenie archívu Borg cez borg extract vytvoria rovnaký adresárový strom. Vetva kódu obnovy (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) číta rovnaké tri bloky údajov bez potreby vedieť, z ktorého cieľa pochádzajú."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/destinations/local.json b/web/messages/sk/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..14df7a05
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst (alebo .tar.gz, ak zstd nie je dostupné). Súbor obsahuje celý strom archívu — manifest.json, metadata/ a rootfs/ — a možno ho obnoviť na ľubovoľnom hostiteľovi Proxmox postupom obnovy ProxMenux alebo ručne rozbaliť cez tar --zstd -xf 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 jeden trvalý cieľový adresár — nie zoznam. ProxMenux ukladá voľbu operátora na /usr/local/share/proxmenux/local-target.conf a číta ju pri každej zálohe. Ak nie je nakonfigurovaný žiadny cieľ, použije sa predvolený HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump (rovnaký adresár, ktorý Proxmox používa pre svoje vlastné výstupy vzdump). Cieľ sa konfiguruje z Konfigurovať ciele zálohovania → Lokálne ciele:",
+ "options": [
+ "Použiť predvolené (/var/lib/vz/dump). 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.",
+ "Zadajte vlastnú cestu. Môžete použiť akúkoľvek absolútnu cestu súborového systému: pripojenie NFS, zdieľanie SMB pripojené cez fstab, vyhradený súbor údajov ZFS, druhý interný disk. ProxMenux overí, že cesta existuje a je adresárom, pred jej uložením.",
+ "Vyberte jednotku USB. 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 lsblk. 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í hb_mount_usb_partition: vytvorí /mnt/backup-LABEL (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 zadať presnú cestu zariadenia (napr. /dev/sdb), 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 _bk_local overí, že cieľový adresár nie je podcestou žiadneho zálohovaného adresára. Bežnou chybou by bolo pridanie /root do profilu a výber /root/backups 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 readlink -m, 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 tar --zstd -cf — jediný príkaz komprimujúci na predvolenej úrovni zstd. Ak zstd v zdroji nie je dostupné (na Proxmoxe zriedkavé, ale možné pri minimálnych inštaláciách), ProxMenux použije gzip. V tomto náhradnom postupe sa pri dostupnom pv pridá ukazovateľ priebehu, takže používateľ vidí rast veľkosti archívu v reálnom čase; bez pv sa použije obyčajné tar -czf bez priebežného výpisu.",
+ "sourceTitle": "Čo ide do archívu",
+ "sourceBody": "Príkaz tar sa spustí s -C \"$staging_root\" ., čím archivuje celý koreň dočasného prípravného adresára: rootfs/, metadata/ a manifest.json. 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: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, zapísaný vedľa archívu funkciou hb_write_archive_sidecar. 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 (kind), ID úlohy pri plánovaných spusteniach, použitý režim profilu (default alebo custom), 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 *.proxmenux.json, nie súbory *.tar.zst, pretože .tar.zst 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í _rs_check_layout, 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 tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg vytvorí rovnaký strom, ktorý používa kód obnovy."
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/destinations/pbs.json b/web/messages/sk/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..8df7ad4d
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client 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 .pxar, --backup-id 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 host/hostcfg-HOSTNAME/BACKUP-TIME. Obsah tvorí archív .pxar s rovnakou trojblokovou štruktúrou ako v časti Ako to funguje. 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á run_scheduled_backup.sh príkaz proxmox-backup-client prune s voľbami --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET a HB_PBS_FINGERPRINT pre spustenie.",
+ "sourceRows": [
+ {
+ "source": "Proxmox storage.cfg (automaticky zistené)",
+ "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
+ "content": "Každá sekcia pbs: 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 Nastaviť ciele záloh → Ciele PBS → Pridať PBS. Zadáva sa názov, používateľské meno (root@pam alebo user@pbs!token), 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 ([proxmox] alebo [manual]). Položky bez zisteného hesla majú upozornenie ⚠ no password; pri ich výbere treba heslo zadať pred spustením zálohy. Odtlačok sa odovzdáva nástroju proxmox-backup-client cez premennú prostredia PBS_FINGERPRINT. 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 proxmox-backup-client backup. ProxMenux pomocou env 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 hostcfg-HOSTNAME. Pred odoslaním ho operátor potvrdí alebo upraví. Znaky mimo [A-Za-z0-9_-] aj pomlčky na konci sa odstránia. Opakované použitie rovnakého ID je zámerné: PBS ho chápe ako skupinu a každá ďalšia záloha pribudne do tejto skupiny ako nová položka so spoločnou deduplikáciou s predchádzajúcimi zálohami.",
+ "pxarTitle": "Prečo je zdrojom celý prípravný adresár",
+ "pxarBody": "Zdrojom archívu .pxar je celý staging_root: spolu rootfs/, metadata/ aj manifest.json. Staršie verzie používali ako zdroj $staging_root/rootfs, takže v archíve chýbal adresár metadata/. Kontrola kompatibility pri obnove nemala čo čítať a zobrazovala upozornenia na iného hostiteľa aj pri obnove na pôvodnom hostiteľovi. Staré zálohy obsahujúce iba rootfs sa stále obnovujú správne pomocou tretej vetvy _rs_check_layout, ktorá plochý strom etc/var/root/usr zabalí do hierarchie rootfs/."
+ },
+ "encryption": {
+ "heading": "Šifrovanie na strane klienta",
+ "glossaryHint": "Táto časť používa pojmy súbor kľúča, prístupová fráza a obnovovacia obálka. Slovník pojmov 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 /usr/local/share/proxmenux/pbs-key.conf 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ť: Nie pokračuje bez šifrovania, Áno prejde na druhý krok. Ten závisí od toho, či je na ceste /usr/local/share/proxmenux/pbs-key.conf 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. Vygenerovať nový súbor kľúča spustí proxmox-backup-client key create --kdf none. Použiť existujúci súbor kľúča automaticky zistí kľúč spravovaný PVE: ak je vybrané úložisko PBS v Proxmoxe zaregistrované so šifrovacím kľúčom na ceste /etc/pve/priv/storage/<NAME>.enc, 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 chmod 600.",
+ "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 Použiť existujúci súbor kľúča. 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 Odoslať kľúč na PBS? s dvoma odpoveďami. Kým operátor nezvolí Áno, na PBS sa neodošle žiadny obnovovací artefakt. Predvolená voľba je Nie, ponechať iba lokálne: kľúč zostane na kanonickej miestnej ceste, ProxMenux neodosiela na PBS žiadne obnovovacie artefakty a externú kópiu zabezpečí operátor. Tlačidlo Stiahnuť súbor kľúča v riadku cieľa PBS v Monitore ju poskytne na požiadanie. Voľba Áno, odoslať vyžiada dvakrát prístupovú frázu na obnovu a overí zhodu. ProxMenux ňou zašifruje súbor kľúča pomocou AES-256-CBC a PBKDF2 (600 000 iterácií, náhodná soľ) a vytvorí pbs-key.recovery.enc. Každá ďalšia šifrovaná záloha odošle túto obálku na PBS ako priradenú skupinu záloh. Pri týchto odoslaniach sa na PBS neposiela prístupová fráza ani súbor kľúča v otvorenom tvare. Voľbu možno kedykoľvek zmeniť v Monitore: ovládací prvok v riadku PBS prepína Áno/Nie a okamžite použije Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu podľa aktuálneho stavu.",
+ "blobUploadTitle": "Párovaná záložná skupina na PBS",
+ "blobUploadBody1": "Keď je režim úschovy Áno, nahrať, ProxMenux odošle obálku na obnovenie do PBS po každej zašifrovanej zálohe ako druhá, spárovaná skupina záloh s rovnakým názvom ako hostiteľská skupina, ale končiaca na -keyrecovery. Tieto dve skupiny sedia vedľa seba v zozname dátového skladu – jedna pre zálohy hostiteľa, druhá pre obálky na obnovenie. Obálka nikdy neopustí hostiteľa v obyčajnom texte: šifrovanie prebieha na samotnom hostiteľovi pomocou AES-256-CBC a PBKDF2 predtým, ako prejdú akékoľvek bajty na drôt (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS prijíma iba už zašifrovanú obálku.",
+ "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 proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc na kanonickú cestu, ak existuje pre vybrané úložisko PBS. Ak je na PBS dostupná skupina -keyrecovery, druhý krok stiahne jej najnovšiu snímku a vyžiada prístupovú frázu na dešifrovanie. Ak ani jedna možnosť nefunguje alebo ich operátor odmietne, tretí krok vyžiada absolútnu cestu k súboru kľúča na tomto hostiteľovi a skopíruje ho na kanonickú cestu. Monitor poskytuje rovnaký import v okne podrobností zálohy. Ak Obnoviť, Stiahnuť alebo Zobraziť obsah potrebuje chýbajúci kľúč, hore sa zobrazí jantárový panel. Ak je kľúč nainštalovaný, ale nezodpovedá šifrovaniu zálohy, PBS vráti chybu wrong key — manifest's key XX does not match provided key YY. Rovnaké tri akcie potom zobrazia štruktúrovaný panel so zvýrazneným odtlačkom kľúča požadovaným manifestom, aby operátor vedel, ktorý kľúč má pre túto zálohu importovať.",
+ "monitorManagementTitle": "Správa súboru kľúčov z monitora",
+ "monitorManagementBody": "Monitor zobrazuje ovládanie súboru kľúča priamo v každom riadku cieľa PBS na stránke konfigurácie záloh. Sú tam tri akcie: Stiahnuť exportuje aktuálny súbor do prehliadača operátora; Nahrať nahradí nainštalovaný súbor dodaným súborom, pričom pôvodný prepíše až po úspešnom uložení nového na kanonickú cestu; Odstrániť zmaže súbor z hostiteľa. Vedľa je ovládanie obnovovacej kópie: výber Áno/Nie pre Odoslať kľúč na PBS?, pole prístupovej frázy pri voľbe Áno a kontextové tlačidlo na použitie voľby Spustiť odosielanie, Zastaviť odosielanie alebo Aktualizovať prístupovú frázu. Všetky akcie používajú rovnaké koncové body Flask ako terminálové rozhranie, takže účinok na disku a stav na PBS sú z oboch rozhraní rovnaké."
+ },
+ "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í proxmox-backup-client restore s rovnakým úložiskom, heslom a odtlačkom, prípadne aj s --keyfile, ak bola záloha šifrovaná. Archív .pxar sa rozbalí do prípravného adresára, ktorý _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/glossary.json b/web/messages/sk/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..f883a15d
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/glossary.json
@@ -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 obnovenie . 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. Nie je to heslo, ktoré odomkne samotný súbor kľúčov 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 blokov pred odoslaním do PBS. Bez príslušného kľúča sa šifrované dáta nedajú čítať. ProxMenux ho uloží do /usr/local/share/proxmenux/pbs-key.conf s režimom 600. Chráňte ho; obálka obnovy 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 prístupovej frázy na obnovu. Existuje len vtedy, keď bol súbor s kľúčom vytvorený --kdf scrypt (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 súbor kľúčov zabalený do ďalšej vrstvy: je zašifrovaný prístupovou frázou na obnovu použitie AES-256-CBC a PBKDF2 predtým, než opustí hostiteľa. Nahrá sa do PBS ako -keyrecovery 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 obálku obnovy."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Možnosť proxmox-backup-client key create, 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ť proxmox-backup-client key create, ktorá vytvára súbor kľúčov chránený pomocou prístupovej frázy súboru kľúč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 openssl enc -aes-256-cbc) na zabalenie súboru kľúča s prístupovou frázou na obnovu a výrobu obálky."
+ },
+ {
+ "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 rsync podľa predvoleného profilu a vlastných ciest. 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 Ako to funguje."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Vlastné cesty",
+ "def": "Extra cesty, ktoré užívateľ pridáva na vrchol predvoleného profilu. Buď perzistentné (uložené v backup-extra-paths.txt) 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 + úložisko údajov + používateľ, ktorý prijíma zálohu. Identifikované podľa reťazca user@realm@host:datastore. 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 proxmox-backup-client prostredníctvom premennej prostredia PBS_FINGERPRINT."
+ },
+ {
+ "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 -keyrecovery pre obálku obnovy."
+ },
+ {
+ "id": "backup-id",
+ "term": "ID zálohy",
+ "def": "Názov skupiny backup. ProxMenux predvolený hostcfg-HOSTNAME 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 run_scheduled_backup.sh 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 /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Pripojený režim",
+ "def": "Úloha bez vlastného časovača. Hook job-end PVE vzdump ju spustí po zálohách hostí pri zhodnom úložisku. Vybraná nadradená úloha poskytne cieľ a uchovávanie, ktoré sa pri každom spustení znova načíta z nadradenej úlohy, 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ú nezávislú plánovanú úlohu. Úlohy v pripojenom režime č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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 hydratácia, 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 súboru kľúča. Obnova šifrovanej zálohy vyžaduje najprv získať kľúč z obálky uloženej v PBS pomocou prístupovej frázy na obnovu."
+ }
+ ]
+ }
+ ],
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/how-it-works.json b/web/messages/sk/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..76f3c680
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/how-it-works.json
@@ -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 .tar.zst, záloha PBS alebo archív Borg) obsahuje túto istú štruktúru. Obnova používa všetky tri: manifest pred zmenami určí rozdiely a výnimky; rootfs poskytne konfiguračné súbory, ktoré sa použijú za behu alebo po reštarte; inventár aplikácií 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 metadata/ má štruktúrované užitočné zaťaženie; podadresár rootfs/ 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 rootfs/ je obyčajná kópia súborového systému vytvorená pomocou rsync zo zdrojového hostiteľa. Obsahuje vybraný predvolený profil ciest dôležitých pre obnovu Proxmoxu a vlastné cesty, ktoré používateľ pridal do úlohy alebo interaktívnej relácie. Výber je zámerne úzky: iba cesty, ktoré obsahujú konfiguráciu alebo uchovávajú stav, ktorý Proxmox nedokáže sám znovu vytvoriť.",
+ "defaultProfileTitle": "Štandardný profil",
+ "defaultProfileBody": "Predvolený profil definuje hb_default_profile_paths v lib_host_backup_common.sh. 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 (config.db) sa zachytí ako konzistentná snímka cez sqlite3 .backup bez zastavenia klastra. Sprievodné súbory .db-wal / .db-shm sa z rsync vylúčia. Ak sqlite3 nie je dostupný, vytvorí sa config.db.raw-fallback, 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 .link v /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. Prchavé cesty (.bash_history, .cache/, tmp/, .local/share/Trash/) sú z kópie vylúčené. /var/lib/proxmenux 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 zpool.cache a hostid."
+ }
+ ],
+ "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 /usr/local/share/proxmenux/backup-extra-paths.txt obsahuje absolútne cesty, ktoré používateľ na tomto hostiteľovi označil ako „vždy zahrnúť“. Pri zálohe v režime Predvolené 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 # sú povolené.",
+ "customModeTitle": "2. Vlastný režim (na beh)",
+ "customModeBody": "Spustenie zálohy v režime Vlastný 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 [+] a vopred začiarknuté). Používateľ začiarkne alebo odznačí položky pre daný konkrétny chod a môže tiež stlačiť Pridať vlastnú cestu 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 metadata/missing_paths.txt 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 /etc/wireguard alebo /etc/prometheus, ak tieto nástroje nie sú nainštalované."
+ },
+ "manifest": {
+ "heading": "Časť s manifestom",
+ "intro": "manifest.json je štruktúrovaný dokument JSON opisujúci zdrojového hostiteľa v čase zálohy. Vytvára ho šesť nezávislých zberných skriptov riadených skriptom build_manifest.sh. 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 (pveversion), verzia PBS, ak hostiteľ plní úlohu zálohovacieho servera, jadro (uname -r), 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 lsusb/lspci; sieťové karty s MAC adresou, PCI slotom a priradením k mostu; bezdrôtové zariadenia. Záznamy GPU obsahujú heuristiku passthrough_eligible."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "ZFS pools (s pool typ + členské disky vyriešené na /dev/disk/by-id/*, /dev/disk/by-partuuid/* alebo surové /dev/sdX 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 storage.cfg vstupy, externé pripojenia."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Parametre pridané správcom do /proc/cmdline bez bežných predvolených položiek, ako sú BOOT_IMAGE=, root=, ro/rw, quiet a splash; moduly načítavané pri štarte z /etc/modules; a cesty súborov /etc/modprobe.d/*.conf, ktoré obsahujú skutočné direktívy (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Číta /usr/local/share/proxmenux/managed_installs.json (registrácia všetkého, čo ProxMenux nainštaloval) a installed_tools.json. Každý záznam udržuje inštalačnú dráhu (menu_script), 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 (qm list) a kontajnery LXC (pct list) prítomné v čase zálohy: VMID, názov a aktuálny stav. Ide iba o inventár; samotné údaje hostí zálohujú vzdump / PBS."
+ }
+ ],
+ "schemaTitle": "Potvrdenie schémy",
+ "schemaBody": "Manifest sa overuje podľa scripts/backup_restore/schema/manifest.schema.json. Príkaz build_manifest.sh --validate spustí validáciu JSON Schema v Pythone, ktorá vyžaduje python3 a jsonschema. Ak modul chýba, kontrola sa bez upozornenia preskočí. Validácia slúži najmä vývojárom, nie je závislosťou potrebnou pri bežnom behu."
+ },
+ "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 metadata/ 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 apt-mark showmanual obsahuje všetky balíky APT výslovne nainštalované 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 _rs_run_complete_extras a použije trojstupňový filter proti kaskádovému odstraňovaniu: dpkg -s zistí už nainštalované balíky, pri knižniciach sa zistia iné hlavné verzie a apt-get install --simulate overí riziko následného odstraňovania. Zvyšné balíky sa nainštalujú cez apt-get install -y.",
+ "componentsTitle": "components_status.json (súčasť rootfs)",
+ "componentsBody": "Register JSON v /usr/local/share/proxmenux/ eviduje každý komponent nainštalovaný cez ProxMenux s presným stavom: verziou a osobitnými príznakmi (pri NVIDIA logická hodnota patched, pri Coral verzia DKMS). Súbor je v rootfs, nie v metadata/, pretože sa číta až po skopírovaní rootfs na cieľ. Dispečer po štarte (apply_cluster_postboot.sh) prejde záznamy a spustí pre každý komponent jeho --auto-reinstall 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 --auto-reinstall:",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Číta version a patched. 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ý .deb 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 packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check. Porovnáva zdrojový a cieľový hardvér (NIC, identifikátory úložísk), verziu PVE a hlavnú verziu jadra. Nastavuje HB_COMPAT_KERNEL_DIRECTION (same, bk_newer alebo bk_older) a zaľudňuje RS_SKIP_PATHS s hardware-drift a cross-kernel s výnimkou."
+ },
+ {
+ "stage": "2",
+ "name": "Použitie za tepla",
+ "reads": "rootfs/ (len bezpečné cesty)",
+ "action": "_rs_apply … hot kopíruje hb_classify_path=hot položky priamo do živého cieľa. Všetko pod /etc/pve, /etc/network alebo cesty klasifikované ako reboot/dangerous je odložený."
+ },
+ {
+ "stage": "3",
+ "name": "Príprava odložených zmien",
+ "reads": "rootfs/ (reboot + nebezpečné cesty)",
+ "action": "_rs_prepare_pending_restore pripraví rizikové cesty v /var/lib/proxmenux/pending-restore/, zapíše plan.env, apply-on-boot.list a rs-skip-paths.txt a povolí spustenie proxmenux-restore-onboot.service pri ďalšom štarte."
+ },
+ {
+ "stage": "3b",
+ "name": "Import dátových poolov",
+ "reads": "manifest.storage_inventory + cieľový ZFS stav",
+ "action": "_rs_import_data_pools 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 zpool import -f. Pools chýbajúce disky sú preskočené s varovaním. Výsledok per-pool je zaznamenaný v /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "stage": "4",
+ "name": "Inštalácia balíka",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras spustí kaskádovo bezpečný filter a zavolá apt-get install -y so zoznamom prežitých balíkov. Celý výstup ide do /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Po štarte systému",
+ "reads": "rootfs (už použité) + components_status.json",
+ "action": "Po reštarte apply_pending_restore.sh použije odložené cesty a apply_cluster_postboot.sh spustí update-initramfs, update-grub alebo proxmox-boot-tool refresh. Potom prejde components_status.json a pre každý komponent spustí jeho --auto-reinstall hook."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Prečo je záloha rozdelená na tri časti",
+ "body": "Rozdelenie sleduje životný cyklus údajov. Súborový systém sa prenáša cez rsync: rýchlo, prehľadne a atómovo po súboroch. Konfiguračný stav, ktorý treba vyhodnotiť pred zmenami, je štruktúrovaný JSON, samostatne čitateľný, verzovateľný schémou a strojovo porovnateľný so stavom cieľa. Softvér na reinštaláciu opisuje inventár 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."
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/index.json b/web/messages/sk/docs/backup-restore/index.json
new file mode 100644
index 00000000..0ec15d1c
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/index.json
@@ -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: súborový systém, teda príslušné adresáre v /etc, /root a /var/lib/pve-cluster spolu s voliteľnými vlastnými cestami; štruktúrovaný manifest vo formáte JSON s detegovaným hardvérom, parametrami jadra, konfiguráciou siete, stavom ZFS, používateľmi a záznamami cron; a inventár aplikácií 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 hostiteľa: samotnej inštalácie Proxmoxu, nie aplikácií a virtuálnych systémov, ktoré na nej bežia.",
+ "items": [
+ "Nejde o nástroj na zálohovanie VM/CT. Táto funkcia nezachytáva disky ani stav RAM virtuálnych systémov; na to slúži vzdump. Ich konfiguračné súbory (/etc/pve/nodes/<node>/qemu-server/*.conf a lxc/*.conf) sa však zálohujú. 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.",
+ "Nejde o operáciu pre celý klaster. Každý uzol zálohuje sám seba. Členstvo v klastri sa zachytáva v /etc/pve, aby sa obnovený uzol mohol opäť pridať do klastra. Obnova celého klastra však vyžaduje koordináciu jednotlivých uzlov.",
+ "Nejde o úplný obraz disku. 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 update-initramfs 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 aktuálne jadro cieľa, 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 hydratácie 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 Ako to funguje, ak je cieľom pochopiť, čo archív obsahuje a prečo. Prejdite na Ciele a nakonfigurujte cieľ pre kópiu. Prečítajte si Obnovovanie a Obnova medzi jadrami 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/restoring.json b/web/messages/sk/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..8c5e01d0
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Obnovenie zálohy — úplný a vlastný postup | ProxMenux",
+ "description": "Úplný postup obnovy: tri akcie pri každej zálohe (zobraziť, stiahnuť, obnoviť), kontrola kompatibility a jej výsledky, úplný a vlastný režim, klasifikácia ciest na použitie za behu alebo po reštarte a dispečer so záverečnou reinštaláciou komponentov po štarte.",
+ "ogTitle": "ProxMenux Backup — obnova",
+ "ogDescription": "Úplná a vlastná obnova s kontrolou kompatibility, klasifikáciou ciest, dispečerom pri štarte a reinštaláciou po štarte.",
+ "twitterTitle": "Obnovenie zálohy ProxMenux",
+ "twitterDescription": "Ako ProxMenux zálohovanie hostiteľa je premenený späť do fungujúceho Proxmox hostiteľa."
+ },
+ "header": {
+ "title": "Obnovenie zálohy",
+ "description": "Úplný postup od výberu archívu po funkčného hostiteľa. Opisuje kontrolu kompatibility, dva režimy obnovy, dispečer pri štarte, reinštaláciu po štarte a mechanizmy predvídateľnej obnovy medzi rôznymi hostiteľmi a jadrami.",
+ "section": "Záloha a obnova"
+ },
+ "intro": {
+ "title": "Obnovenie reprodukuje zdroj, nielen súbory",
+ "body": "Obnova zálohy ProxMenux znamená viac než rozbalenie súborov. Pred zmenami prečíta manifest, zistí rozdiely medzi zdrojom a cieľom, vylúči cesty ohrozujúce štart a prispôsobí nastavenia používateľa, ktoré nemožno skopírovať doslova. Po potrebnom reštarte sa pokúsi preinštalovať zaznamenané podporované komponenty (ovládač NVIDIA, Coral TPU a nástroje GPU) pre bežiace jadro cieľa. Jeden archív riadi kontrolu kompatibility, klasifikáciu ciest a prácu pri štarte aj po ňom. Výsledok overte v stavoch jednotlivých komponentov a protokoloch."
+ },
+ "threeActions": {
+ "heading": "Tri akcie na zálohe",
+ "intro": "Výberom zálohy zo zoznamu sa otvorí menu s tromi akciami.",
+ "actionRows": [
+ {
+ "action": "Zobraziť",
+ "detail": "Otvorí zobrazenie archívu len na čítanie: obsah manifest.json (source hostname, PVE verzia, jadra, hardvér, nainštalované komponenty), zoznam ciest vnútri rootfs/ a rozlíšenie toho, čo by sa zmenilo na aktuálnom hostiteľovi, ak by bola použitá záloha."
+ },
+ {
+ "action": "Stiahnuť",
+ "detail": "Exportuje archív ako prenosný súbor .tar.zst (tar skomprimovaný zstd). Je možné extrahovať na ľubovoľnom systéme Linux s tar --zstd -xf FILE.tar.zst, alebo na macOS/Windows s akýmkoľvek nástrojom, ktorý podporuje zstd (7-Zip, PeaZip, Keka...). Extrahovaný strom obsahuje manifest.json, metadata/ a rootfs/, teda rovnakú štruktúru, akú používa obnova. Užitočné pre offline kontrolu alebo obnovenie na hostiteľa bez prístupu k pôvodnému cieľu (PBS, Borg)."
+ },
+ {
+ "action": "Obnoviť",
+ "detail": "Akcia zapisujúca do systému: rozbalí archív do prípravného adresára, spustí kontrolu kompatibility a ponúkne výber úplného alebo vlastného režimu."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Kontrola zlučiteľnosti",
+ "intro": "Pred napísaním akéhokoľvek súboru hb_compat_check porovnáva stav opísaný v manifeste s cieľovým hostiteľom. Kontrola beží iba na čítanie a vytvára štyri nezávislé výstupy, ktoré poháňajú zvyšok obnovy.",
+ "outputRows": [
+ {
+ "output": "Príznak smeru",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION má hodnotu same, bk_newer alebo bk_older podľa porovnania hlavných verzií jadra zálohy a cieľa. Riadi filter bezpečných ciest medzi jadrami, ktorý sa zapne iba pri bk_older, a prispôsobenie nastavení opísané na príslušnej stránke."
+ },
+ {
+ "output": "Zoznam preskočených ciest",
+ "detail": "RS_SKIP_PATHS obsahuje cesty, ktoré obnova NESMIE použiť. Plnia ho dva mechanizmy: rozdiely hardvéru (chýbajúca sieťová karta, ID úložiska alebo cudzí pool ZFS) a pri smere bk_older zoznam ciest nebezpečných medzi rôznymi jadrami."
+ },
+ {
+ "output": "Plán premapovania sieťových kariet",
+ "detail": "Ak má sieťová karta na cieľovom hostiteľovi rovnakú MAC adresu ako na zdrojovom, ale iný názov (bežné po výmene základnej dosky), kontrola kompatibility zaznamená plán premenovania (HB_NIC_REMAP). Ten počas obnovy upraví /etc/network/interfaces."
+ },
+ {
+ "output": "Plán vrátenia zmien",
+ "detail": "Vypočíta ho compute_rollback_plan.sh. Vypíše VM, LXC a komponenty, ktoré sú na cieli, ale nie v zálohe. Potvrdenie ponúkne voliteľné odstránenie dodatočných hostí pred reštartom. Komponenty treba odstrániť ručne a zmazanie hostí môže zlyhať, takže presná zhoda so zálohou nie je zaručená."
+ }
+ ],
+ "reportBody": "Kontrola tiež vydáva štruktúrované správy (HB_COMPAT_RESULTS) kategorizované ako PASS / INFO / WARN / FAIL. WARN a FAIL vstupy povrch v paneli pre-restore; obnovenie odmieta pokračovať len vtedy, keď je prítomný FAIL, že užívateľ nemôže vyriešiť kliknutím Pokračovať."
+ },
+ "twoModes": {
+ "heading": "Úplné obnovenie vs Vlastné obnovenie",
+ "intro": "Po kontrole kompatibility sa zobrazí výber režimu. Určuje, čo sa použije, nie ako: oba režimy používajú rovnaký postup.",
+ "modeRows": [
+ {
+ "mode": "Úplná obnova",
+ "detail": "Použije každú cestu v archíve, ktorá prežije filtre drift a cross-kernel. Tiež spustí inštaláciu balíka a automatickú reinštaláciu komponentov. Toto je predvolená a odporúčaná voľba – cieľom je reprodukovať zdroj, nie vyberať kúsky."
+ },
+ {
+ "mode": "Vlastné obnovenie",
+ "detail": "Otvorí zoznam všetkých ciest v archíve, z ktorých používateľ vyberie požadovanú časť. Cesty blokované filtrom medzi jadrami sú sivé a nemožno ich vybrať. Vlastný režim predvolene preskočí inštaláciu balíkov a automatickú reinštaláciu komponentov: používateľ požaduje čiastočnú obnovu, nie úplné zopakovanie zdroja."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Ako sú cesty klasifikované",
+ "intro": "Každá cesta vybraná pre obnovenie je zaradená hb_classify_path do jednej z troch kategórií. Kategória určuje, kedy sa cesta aplikuje na systém a prečo.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Cesta aplikovaná okamžite do bežiaceho systému. Služba, ktorá ich konzumuje, vyzdvihne zmenu na vlastnú päsť alebo na ďalšiu reload Jedná sa o väčšinu zálohy: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, všeobecné konfiguračné súbory služieb, atď."
+ },
+ {
+ "class": "reboot",
+ "detail": "Cesty odložené na ďalší štart, nie použité okamžite týmto postupom. Ovplyvňujú konfiguráciu štartu: tvorba zavádzača číta /etc/default/grub, pripájanie systémov používa /etc/fstab a načítanie modulov /etc/modules. Odložené súbory sa použijú po reštarte a potom sa znovu vytvoria potrebné zavádzacie súbory. Príklady: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Cesty, ktoré sa NEPOUŽIJÚ na bežiacom systéme, pretože zápis za behu by mohol poškodiť stav alebo prerušiť aktívne spojenie. Pripravia sa medzi odloženými súbormi: /etc/network sa zapíše na začiatku ďalšieho štartu, ešte pred spustením siete, a /etc/pve zapíše dispečer po štarte, keď je klastrový súborový systém dostupný. Príklady: /etc/pve (pmxcfs je pripojenie FUSE s aktívnou konfiguráciou klastra), /var/lib/pve-cluster (aktívne údaje klastra, uložené v adresári obnovy len na ručnú obnovu), /etc/network (zmena môže prekonfigurovať rozhranie používané na SSH a prerušiť reláciu)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "Úplné obnovenie pracovného postupu",
+ "intro": "Celý postup od výberu archívu po obnoveného funkčného hostiteľa. Každá fáza pripraví vstup ďalšej: stav zapísaný skoršími fázami používajú neskoršie.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "Mechanizmus odloženej obnovy",
+ "intro": "Cesty klasifikované ako reboot alebo dangerous, a hydratačné zápisy, sú fázované pre ďalšie boot miesto aplikácie naživo. To sa vykonáva prostredníctvom malého, samostatného súboru súborov v /var/lib/proxmenux/pending-restore/:",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "Jedna relatívna cesta na riadok: presná množina ciest, ktoré apply_pending_restore.sh použije z pripraveného rootfs. Súbor ukazuje, čo sa zmení pri ďalšom štarte."
+ },
+ {
+ "file": "plan.env",
+ "content": "Premenné prostredia načítané skriptom pri štarte: ID obnovy, príznaky kompatibility (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), súhlas s vrátením stavu a voľby klastra."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "Konečný zoznam RS_SKIP_PATHS, uložený pre apply_pending_restore.sh, aby po reštarte zachoval výnimky vypočítané v interaktívnej fáze. Bráni obnoveniu ciest nevhodných pre hardvér alebo rozdielne jadro pri štarte."
+ },
+ {
+ "file": "rootfs/",
+ "content": "Samotné pripravené súbory – presné bajty, ktoré sa zapíšu. Zostávajú na rovnakom súborovom systéme ako /, aby bol rsync pri štarte rýchly a nezávisel od dostupnosti externého úložiska počas štartu."
+ }
+ ],
+ "unitBody": "Jednotka systemd proxmenux-restore-onboot.service sa povolí na konci interaktívnej fázy. Táto jednorazová služba sa spustí na začiatku ďalšieho štartu, zavolá apply_pending_restore.sh a potom sa zakáže. Podmienka ConditionPathExists=/var/lib/proxmenux/pending-restore/state zabezpečí, že bez čakajúcej obnovy nevykoná nič."
+ },
+ "postbootDispatcher": {
+ "heading": "Post-boot dispečer apply_cluster_postboot.sh",
+ "intro": "Kde sa končí interaktívny krok a kde dochádza k skutočnej reprodukcii hostiteľa. apply_cluster_postboot.sh je nainštalovaný ako druhá jednorázová jednotka systemd (proxmenux-apply-cluster-postboot.service), ktorej ciele After=/Wants= zabezpečujú, že beží až po pve-cluster a network-online sú hore. To je miesto, kde hostiteľ-viditeľné obnoviť akcie pozemky.",
+ "tasks": [
+ {
+ "task": "Použiť /etc/pve",
+ "detail": "/etc/pve je aktívne pripojenie FUSE systému pmxcfs, do ktorého nemožno zapisovať v skorej fáze štartu. Dispečer po spustení klastrového systému kopíruje súbory z pripraveného rootfs do živého /etc/pve, po jednom a bez reštartu pve-cluster. Zachytený /var/lib/pve-cluster/config.db alebo náhradný config.db.raw-fallback sa obnoví postupom systemctl stop pve-cluster → atómové kopírovanie súboru → systemctl start pve-cluster, aby pmxcfs po spustení načítal obnovený stav."
+ },
+ {
+ "task": "Znovu vytvoriť initramfs a zavádzač",
+ "detail": "Spustí update-initramfs -u -k all cez každé nainštalované jadro, potom buď update-grub (GRUB inštaluje) alebo proxmox-boot-tool refresh (systemd-boot / ZFS inštaluje). Preskočené, ak interaktívny krok určiť nič sa nezmenilo v chodníkoch, ktoré ovplyvňujú tieto nástroje."
+ },
+ {
+ "task": "Automatická inštalácia komponentov",
+ "detail": "Číta obnovený components_status.json a prejde podporované inštalátory (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Každý vybraný inštalátor použije --auto-reinstall, načíta uložený stav a zopakuje inštaláciu pre cieľové prostredie, prípadne zostaví moduly jadra. Čaká sa na reštart, aby sa použilo potom bežiace jadro cieľa. Jednotlivé chyby sa zaznamenajú a nezastavia ďalší komponent."
+ },
+ {
+ "task": "Kontrola štartu systému",
+ "detail": "Pred spustením oznámenia o dokončení overíte, či proxmox-boot-tool status zobrazuje nakonfigurovaný ESP, každý /boot/vmlinuz-* má zodpovedajúci /lib/modules/<ver> adresár a /vmlinuz rieši. Akýkoľvek nesúlad sa vynorí v oznámení namiesto toho, aby bol skrytý."
+ },
+ {
+ "task": "Oznámenie o dokončení",
+ "detail": "Posiela udalosť Host restore finished prostredníctvom hb_notify_lifecycle. Zahŕňa celkovú dĺžku trvania, použitý počet ciest, prípadné upozornenia na kontrolu zdravotného stavu a odkaz na log pri /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Ak notifikácie nie sú konfigurované, udalosť sa neodošle; protokol aj tak zaznamená všetko"
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Živý priebeh na karte Zálohy v Monitore",
+ "body": "Po reštarte zobrazuje karta Zálohy v ProxMenux Monitor živý priebeh služby proxmenux-apply-cluster-postboot.service. Číta /var/lib/proxmenux/restore-state.json, ktorý sa aktualizuje pri každej fáze: konfigurácia klastra, initramfs, zavádzač, reinštalácia jednotlivých komponentov, kontrola štartu a dokončenie.",
+ "fields": [
+ {
+ "name": "Označenie stavu",
+ "detail": "Jeden zo stavov Prebieha obnova, Obnova dokončená alebo Obnova zlyhala. Karta číta stavový súbor každé 2 sekundy počas behu a každých 30 sekúnd po skončení."
+ },
+ {
+ "name": "Panel pokroku + počítadlo krokov",
+ "detail": "Zobrazí N/M steps a názov aktuálneho kroku. Počas obnovy sa odhadovaný čas vypočíta z dokončených krokov a uplynutého času."
+ },
+ {
+ "name": "Zoznam komponentov",
+ "detail": "Jeden riadok na jedného ovládača, ktorý bol preinštalovaný (NVIDIA, nástroje Intel GPU, nástroje AMD, Coral TPU) s installing / ok / failed plus odkaz na jednotlivé komponenty pri /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Import dátových poolov",
+ "detail": "Blok data_pools_import má päť farebných riadkov: Importované, Vynútené (s -f pre cudzí hostid), Preskočené, neúplné disky (prítomné iba niektoré disky), Preskočené, chýbajúce disky (žiadny disk prítomný) a Zlyhané. Stav sa ukladá do /var/lib/proxmenux/restore-state.json a úplný protokol behu do /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Upozornenia pri kontrole štartu",
+ "detail": "Dispečer kontroluje chýbajúce adresáre /lib/modules/<kernel>, chýbajúcu konfiguráciu ESP a symbolické odkazy /vmlinuz bez existujúceho cieľa. Upozornenia sa zobrazia vo farebnom paneli."
+ },
+ {
+ "name": "Rozdiely po obnove",
+ "detail": "Vypíše VM, LXC a komponenty prítomné na cieli, ale nie v obnovenej zálohe: tie isté položky ako v dialógu deštruktívneho vrátenia stavu pred obnovou. Každý riadok obsahuje príkaz na ručné odstránenie."
+ },
+ {
+ "name": "Koniec záznamu",
+ "detail": "Posledné línie 600 proxmenux-cluster-postboot-<ts>.log, s Iba problémy, ktorý udržuje len línie zodpovedajúce error, warning, failed, ✗ alebo traceback."
+ }
+ ],
+ "dismissBody": "Keď je obnova dokončená alebo zlyhá, tlačidlo Skryť zbalí kartu. Stavový súbor zostane uložený a História znovu otvorí túto aj predošlé obnovy. Posledných 20 behov je archivovaných v /var/lib/proxmenux/restore-history/.",
+ "imageAlt": "Okno Podrobnosti priebehu po obnove v ProxMenux Monitor otvorené počas obnovy. Zobrazuje modrý odznak Prebieha obnova, aktuálny krok Obnovenie initramfs, odhad zostávajúceho času, čiastočne vyplnený ukazovateľ priebehu a živý koniec záznamu po štarte systému.",
+ "imageCaption": "Okno Podrobnosti počas spracovania po štarte: stav, aktuálny krok, zostávajúci čas a živý výpis posledných riadkov protokolu.",
+ "detailsImageAlt": "Rovnaké okno Podrobnosti po skončení obnovy: zelený stav Obnova dokončená, celkový čas 0m53s, plný ukazovateľ 6/6, prázdna časť rozdielov vrátenia stavu a archivovaný protokol po štarte.",
+ "detailsImageCaption": "Rovnaké okno po skončení: stav, celkový čas, plný ukazovateľ priebehu a archivovaný protokol po štarte."
+ },
+ "postbootExample": {
+ "heading": "Ako vyzerá post-boot na konzole",
+ "body": "Na fyzickej konzole skončí úspešne ukončený proces riadkom [ OK ] Finished proxmenux-apply-cluster-postboot.service, často pri hláseniach OK pre multi-user.target a graphical.target. Označuje koniec procesu. Napriek tomu môžu byť zaznamenané chyby komponentov alebo upozornenia na štart. Pred vyhlásením hostiteľa za úplne obnoveného skontrolujte stavy komponentov a protokoly v Monitore.",
+ "imageAlt": "Fyzická konzola Proxmox s hlásením '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', za ktorým nasleduje OK pre multi-user.target a graphical.target; vyššie je výzva na prihlásenie.",
+ "imageCaption": "Fyzická konzola po skončení procesu. 'Finished proxmenux-apply-cluster-postboot.service' označuje jeho koniec, ktorý Monitor hlási aj ako 'Host restore finished'. Výsledky komponentov a upozornenia treba ešte skontrolovať."
+ },
+ "tenMinutes": {
+ "heading": "Prečo na posledných 10 minútach záleží",
+ "intro": "Reštart sám trvá sekundy, ale post-boot dispečer strávi asi desať minút dokončenie obnovy. Počas tohto okna je hostiteľ dosiahnuteľný a prihlásenie funguje, ale niektoré služby (najmä služby závislé od ovládača GPU) ešte nie sú k dispozícii. Časový rozpis typického hostiteľa Proxmoxu s NVIDIA + nainštalovaným Coralom:",
+ "rows": [
+ {
+ "stage": "Boot + pve-cluster pripravený",
+ "time": "~30 s",
+ "detail": "Standard Proxmox boot. SSH, web UI a login sú k dispozícii na konci tejto etapy."
+ },
+ {
+ "stage": "Použiť /etc/pve na pmxcfs",
+ "time": "~10 s",
+ "detail": "Rýchle: malé konfiguračné súbory sa kopírujú po jednom do aktívneho klastrového súborového systému."
+ },
+ {
+ "stage": "Znovu vytvoriť initramfs pre všetky jadrá",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all prestavuje jeden obrázok initramfs na nainštalované jadro. Veľa čakania."
+ },
+ {
+ "stage": "Znovu vytvoriť bootloader konfigur",
+ "time": "10–30 s",
+ "detail": "update-grub alebo proxmox-boot-tool refresh. Rýchle aj na ZFS."
+ },
+ {
+ "stage": "Preinštalovať ovládač NVIDIA (ak je to vhodné)",
+ "time": "5–10 min",
+ "detail": "Stiahne nahranú verziu ovládača, kompiluje moduly DKMS oproti aktuálnemu jadru, použije opravu ProxMenux ak ju mal zdroj. Najdlhšia jediná úloha."
+ },
+ {
+ "stage": "Opätovná inštalácia Coral a ďalších komponentov",
+ "time": "3–5 min",
+ "detail": "Kompilácia DKMS pre Coral, apt install pre intel-gpu-tools a stiahnutie a inštalácia .deb pre amdgpu_top."
+ },
+ {
+ "stage": "Kontrola štartu a oznámenie",
+ "time": "~2 s",
+ "detail": "Nenáročné. Oznámenie informuje používateľa hneď po skončení behu."
+ }
+ ],
+ "outroBody": "Počas tohto času môžu po prihlásení chýbať nástroje (nvidia-smi sa nenašiel, coral sa nezistil), pretože reinštalácia stále beží na pozadí. Oznámenie označuje jej koniec. Výsledky komponentov, upozornenia a protokoly odlíšia úspech od jednotlivých zlyhaní."
+ },
+ "destructiveRollback": {
+ "heading": "Voliteľný deštruktívny spätný chod",
+ "body": "Obnova je predvolene aditívna: dodatočné VM, LXC a komponenty zostanú zachované. Pri rozdieloch ponúkne potvrdenie Vykonať deštruktívne vrátenie stavu? s predvoleným Nie. Súhlas pred reštartom zavolá _rs_execute_rollback a pokúsi sa odstrániť vypísané dodatočné VM a LXC. Komponenty sa označia na ručné odinštalovanie, pretože automatické nie je implementované. Chyby odstránenia sa oznámia a spracovanie pokračuje, takže presná zhoda nie je zaručená. Pred touto deštruktívnou voľbou skontrolujte názvy a VMID/CTID."
+ },
+ "logs": {
+ "heading": "Kde záznamy žijú",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Zapisuje sa v interaktívnej fáze: výsledky kompatibility, filter rozdielov, plán prispôsobenia, výstup použitia za behu a prípravy odložených zmien, inštalácia balíkov."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Zapisuje ho apply_pending_restore.sh na začiatku štartu: načítanie plan.env, spracovanie apply-on-boot a filtrovanie vylúčených ciest."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Zapisuje ho apply_cluster_postboot.sh: použitie konfigurácie pve-cluster, výstup initramfs a zavádzača, výstup inštalátorov komponentov, kontrola štartu a obsah oznámenia."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "Jeden protokol na inštalačný program komponentu (nvidia, coral, atď.), ktorý bol spustený v prechode po spustení. Užitočné, keď preinštalovanie konkrétneho komponentu zlyhalo a používateľ potrebuje vlastný výstup nástroja."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Napísal _rs_import_data_pools. Obsahuje: sčítanie nekoreňových poolov z manifestu, na-pool výsledok (dovážané čisto, importované s -f pre zahraničné hostid, preskočené kvôli chýbajúce disky, alebo zlyhal), a surový výstup každého zpool import hovoru."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Kam ísť ďalej",
+ "items": [
+ {
+ "label": "Obnova medzi kernelmi",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": "— filter bezpečnej podmnožiny zohľadňujúci smer a prechod na hydratáciu vyvolaný, keď sa cieľové jadro líši od záložného."
+ },
+ {
+ "label": "Ako to funguje",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": " — štruktúra archívu, manifest a inventár aplikácií, ktoré používa obnova."
+ },
+ {
+ "label": "Plánované úlohy",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": " — bezobslužný postup, ktorý vytvára archívy používané pri tejto obnove."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sk/docs/backup-restore/scheduled-jobs.json b/web/messages/sk/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..03e011e3
--- /dev/null
+++ b/web/messages/sk/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Nová nezávislá úloha — 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.",
+ "Pripojenie k existujúcej úlohe vzdump PVE — ú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 rovnakom zálohovacom cykle. Pri obnove pochádzajú konfigurácie hostí zo zálohy hostiteľa (v /etc/pve) 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 OnCalendar (syntax kalendára systemd, napr. daily alebo Mon..Fri 03:00).",
+ "retention": "Zadáva sa samostatne: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups nadradenej úlohy (pomocou hb_pve_prune_to_keep_env mapovanej jedna k jednej na premenné KEEP_* spúšťacieho skriptu)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Ako funguje režim pripojenia",
+ "intro": "PVE zapisuje úlohy vzdump do /etc/pve/jobs.cfg — 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 hb_pve_list_vzdump_jobs_for_backend. Užívateľ si vyberie jednu."
+ },
+ {
+ "step": "2",
+ "detail": "Súbor .env úlohy sa zapíše s PVE_PARENT_JOB, PVE_STORAGE a prevzatými hodnotami KEEP_*; časovač systemd sa nevytvorí."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook zaregistruje hook v /etc/vzdump.conf. Vo fáze job-end ľubovoľnej úlohy vzdump porovná prijaté $STOREID s PVE_STORAGE 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: path/dump/ 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 KEEP_* 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 run_scheduled_backup.sh JOB_ID. Časovač ho naplánuje s Persistent=true (zmeškané spustenia sa vykonajú pri ďalšom štarte) a malým RandomizedDelaySec=120 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 hb_install_vzdump_hook; porovnáva PVE_STORAGE každej pripojenej úlohy s $STOREID, 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": [
+ "Pripraví zálohu. 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.",
+ "Zapíše do cieľa. Odošle alebo zapíše archív do nastaveného cieľa — lokálny súbor .tar.zst, 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.",
+ "Použije pravidlá uchovávania. Odstráni staré zálohy z cieľa a ponechá počty nastavené v úlohe cez keep-last / keep-daily / keep-weekly. Čistenie vykonáva príslušný backend: PBS používa svoje pravidlá uchovávania, Borg spustí borg prune a pri lokálnom cieli ProxMenux odstráni súbory mimo rozsahu keep-last."
+ ]
+ },
+ "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 systemctl enable/disable --now. Režim pripojenia: zmení príznak ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — 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 hb_notify_lifecycle ako interaktívny postup (start, complete, fail). 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/creating-backups.json b/web/messages/sv/docs/backup-restore/creating-backups.json
new file mode 100644
index 00000000..f11c2a6d
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/creating-backups.json
@@ -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 exakt samma funktioner. Varje säkerhetskopia — manuell eller schemalagd — går genom samma valmatris (tre destinationer × två profiler) och anropar samma backendfunktion per cell (_bk_pbs, _bk_borg eller _bk_local). 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 backup_menu i backup_host.sh."
+ },
+ {
+ "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: manuellt (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 schemalagt (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 run_scheduled_backup.sh; 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 .tar.zst-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 .tar.zst-arkivet skrivs."
+ }
+ ]
+ },
+ "profiles": {
+ "heading": "Standard vs anpassad profil",
+ "defaultTitle": "Standardprofil",
+ "defaultBody": "Standardprofilen är den kurerade listan från hb_default_profile_paths (dokumenterad i Hur det fungerar under Sökvägskategorier) plus varje post i den filen med beständiga tillägg /usr/local/share/proxmenux/backup-extra-paths.txt. 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 [+]). Användaren markerar sökvägarna för denna körning och kan trycka på Lägg till anpassad sökväg för att lägga till en ny absolut sökväg. Sökvägar som läggs till här sparas i backup-extra-paths.txt 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 Hantera anpassade sökvägar, 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. hb_prepare_staging bygger arkivträdet i /tmp/proxmenux-DESTINATION-stage.XXXXXX och fyller vart och ett av de tre datablocken.",
+ "steps": [
+ {
+ "step": "1",
+ "name": "Sammanställning av rootfs",
+ "detail": "Kör rsync -a för varje vald sökväg till staging_root/rootfs/. Databasen pmxcfs i /var/lib/pve-cluster/config.db sparas separat via sqlite3 .backup för att få en konsekvent ögonblicksbild utan att stoppa klustret; hjälpfilerna .db-wal / .db-shm utesluts från rsync. Om sqlite3 saknas sparas i stället en fil config.db.raw-fallback, som återställningen använder som databas vid importen. Flyktiga undersökvägar (bash-historik, cache, papperskorg) utesluts från /root/. Sökvägar som saknas i källan registreras i metadata/missing_paths.txt utan att säkerhetskopieringen avbryts."
+ },
+ {
+ "step": "2",
+ "name": "Manifestgenerering",
+ "detail": "build_manifest.sh samordnar de sex insamlingsmodulerna och skriver manifest.json 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": "apt-mark showmanual fångas verbatim i metadata/packages.manual.list. Komponentstatus är redan inne i det återställda rootfs (components_status.json) eftersom /usr/local/share/proxmenux/ är en del av standardprofilen."
+ },
+ {
+ "step": "4",
+ "name": "Information om körningen",
+ "detail": "metadata/run_info.env 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": "hb_notify_lifecycle \"start\" utlöses. Om aviseringar är konfigurerade i Monitor skickas händelsen Säkerhetskopiering av värden startad 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 rsync -aAXH --numeric-ids. 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": [
+ "images/ - bilddumpar.",
+ "dump/ — utdata från vzdump.",
+ "tmp/ - tillfälliga filer.",
+ "*.log loggfiler."
+ ],
+ "rootTitle": "/root/-uteslutningar",
+ "rootBody": "/root/ ingår i standardprofilen så att användarens skript och konfiguration sparas i arkivet. Flyktiga undersökvägar utesluts:",
+ "rootItems": [
+ ".bash_history",
+ ".cache/",
+ "tmp/",
+ ".local/share/Trash/"
+ ],
+ "proxmenuxTitle": "/usr/local/share/proxmenux/-uteslutningar",
+ "proxmenuxBody": "Denna katalog skickar användarstatus endast - components_status.json, 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": [
+ "restore-pending/, scripts/, web/",
+ "monitor-app/, monitor-app.*/, AppImage/",
+ "images/, json/",
+ "utils.sh, helpers_cache.json",
+ "ProxMenux-Monitor.AppImage*, install_proxmenux*.sh"
+ ],
+ "notInProfileTitle": "Vägar utanför profilen",
+ "notInProfileBody": "Allt som inte anges i hb_default_profile_paths och inte läggs till som en anpassad eller ihållande extra är inte en del av backupen. Anmärkningsvärda exempel:",
+ "notInProfileItems": [
+ "VM- och LXC-diskar - hanteras av vzdump, inte av denna funktion. Gästkonfigurationsfiler under /etc/pve/nodes/*/qemu-server/*.conf och lxc/*.conf fångas (de lever under /etc/pve) så återställningen reproducerar inventeringen; diskarna själva är återanslutna från en befintlig vzdump / PBS backup.",
+ "/boot och /boot/efi - kärnbinärer, initramfs och UEFI ESP-partitionen regenereras av målets egen update-initramfs, update-grub eller proxmox-boot-tool refresh efter återställningen. Starthanteraren kopieras aldrig ordagrant.",
+ "Filsystem för kärnan och systemets körning — /proc, /sys, /dev och /run är pseudofilsystem som skapas av kärnan och udev; de lagras inte beständigt någonstans.",
+ "Paketbinärer under /usr/bin, /usr/lib, /lib, /sbin - ominstallerad av målets APT från packages.manual.list.",
+ "/var/log/, /var/tmp/, /var/cache/ - per-värd runtime tillstånd, inte återställd.",
+ "/home/USER - 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 backup-extra-paths.txt går igenom samma rsync-pipeline som standardprofilvägar. Globala uteslutningar gäller. Om den anpassade vägen råkar vara under /root/ eller /usr/local/share/proxmenux/ gäller fortfarande de vägspecifika uteslutningarna ovan. Varje arkiverad väg - standard eller anpassad - registreras i metadata/paths_archived.txt. Sökvägar som inte finns på källan registreras i metadata/missing_paths.txt 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 .pxar 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 trap 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 /tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log 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": "hb_write_archive_sidecar släpper en *.proxmenux.json 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": "hb_notify_lifecycle \"complete\" eller \"fail\" 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/cross-kernel.json b/web/messages/sv/docs/backup-restore/cross-kernel.json
new file mode 100644
index 00000000..2c7ade68
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/cross-kernel.json
@@ -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 6.17.13-2-pve. De två första siffrorna (6.17 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 hb_compat_check kärnan registrerad i backupens manifest mot målets nuvarande kärna (uname -r) och klassificerar återställningen i ett av tre fall, lagrad i den interna variabla HB_COMPAT_KERNEL_DIRECTION:",
+ "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 same, 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 äldre-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 uname -r och sammanställer DKMS mot vad målet har. APT-paketet installerar binärer byggda för målets distribution. IOMMU cmdline tokens som intel_iommu=on ä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 hb_unsafe_paths_cross_version till RS_SKIP_PATHS. 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": "/etc/default/grub, /etc/kernel",
+ "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": "/etc/modules-load.d, /etc/modprobe.d, /etc/initramfs-tools",
+ "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": "/etc/fstab, /etc/multipath, /etc/iscsi, /etc/udev/rules.d, /etc/zfs",
+ "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 (zpool.cache + hostid) som kan låsa poolen som främmande."
+ },
+ {
+ "category": "APT-källor",
+ "paths": "/etc/apt",
+ "reason": "APT-källor kan utlösa en nedgradering av kritiska paket på nästa uppgradering."
+ },
+ {
+ "category": "systemd",
+ "paths": "/etc/systemd/system, /etc/systemd/journald.conf, /etc/systemd/logind.conf, /etc/systemd/system.conf, /etc/systemd/user.conf",
+ "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 GRUB_TIMEOUT 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). _rs_hyd_grub sammanfogar parametrar från säkerhetskopians manifest.kernel_params.cmdline_extra i målets GRUB_CMDLINE_LINUX_DEFAULT och hoppar över nycklar som redan finns. Därefter återställs tillåtna GRUB_*-nycklar (GRUB_TIMEOUT, GRUB_TIMEOUT_STYLE, GRUB_DEFAULT, GRUB_TERMINAL, GRUB_DISABLE_OS_PROBER, GRUB_SERIAL_COMMAND, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX) från säkerhetskopians /etc/default/grub när värdena skiljer sig från målets."
+ },
+ {
+ "phase": "1b — systemd-boot / ZFS",
+ "detail": "För systemd-boot (vanligen ZFS på roten). _rs_hyd_kernel_cmdline sammanfogar användarparametrar från cmdline_extra i målets /etc/kernel/cmdline och bevarar målets startparametrar root=, boot= och rootflags=."
+ },
+ {
+ "phase": "2 — /etc/modules Sammanslagning",
+ "detail": "_rs_hyd_modules Lägger till moduler från manifest.kernel_params.modules_loaded_at_boot som finns i den vita listan (vfio, vfio_pci, vfio_iommu_type1, vfio_virqfd, kvm, kvm_intel, kvm_amd, nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm, i915, xe) och inte redan närvarande i målets mål /etc/modules."
+ },
+ {
+ "phase": "3 — Kopiera tillåtna filer",
+ "detail": "_rs_hyd_files 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 /etc/modprobe.d, /etc/modules-load.d och ProxMenux VFIO bind regel + nvidia udev regler under /etc/udev/rules.d. Distro-ägda filer (pve-blacklist.conf, mdadm.conf, nvme.conf) ä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, HB_HYDRATION_APPLIED=1 förökar genom plan.env för att apply_pending_restore.sh, som tvingar NEEDS_INITRAMFS=1 och NEEDS_GRUB=1 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 _rs_apply_bk_older_hydration i plan-läge: det beräknar exakt vad som skulle slås samman, fyller RS_HYDRATION_SUMMARY 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 commit 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 intel_iommu=on iommu=pt i cmdline, vfio/vfio_pci/vfio_iommu_type1 i /etc/modules, en /etc/modprobe.d/vfio.conf med options vfio-pci ids=10de:2216 och en /etc/modprobe.d/blacklist-nvidia.conf. Hydration sammanfogar cmdline-tokens i målets GRUB eller kernel cmdline, appends vfio-modulerna till /etc/modules 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 GRUB_TIMEOUT=1 och GRUB_DISABLE_OS_PROBER=true. Hydration läser båda nycklarna från säkerhetskopieringens /etc/default/grub, 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 GRUB_DISTRIBUTOR, 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 (vfio*, nvidia*, i915, xe, kvm*). Allt utanför den uppsättningen - anpassade initramfs krokar under /etc/initramfs-tools/hooks/, icke-vitlistade filer under /etc/modprobe.d/, användarskrivna systemd-enhetsåsidosättningar - förblir uteslutna. Anledningen är konkret: dessa filer kan ringa kärnintern gränssnitt (modul API, /sys layout, udev 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": "hb_compat_check i lib_host_backup_common.sh. Sätter HB_COMPAT_KERNEL_DIRECTION."
+ },
+ {
+ "component": "Sökvägslista för säkert urval",
+ "location": "hb_unsafe_paths_cross_version i lib_host_backup_common.sh. Ger path\\treason-linjer som används av både CLI-filtret och Web endpoint /api/host-backups/restore/prepare."
+ },
+ {
+ "component": "Hydrationsfaser",
+ "location": "_rs_hyd_grub, _rs_hyd_kernel_cmdline, _rs_hyd_modules, _rs_hyd_files i backup_host.sh. Orkestrerad av _rs_apply_bk_older_hydration."
+ },
+ {
+ "component": "Framtvingad ombyggnad efter uppstart",
+ "location": "apply_pending_restore.sh läser HB_HYDRATION_APPLIED från plan.env och tvingar NEEDS_INITRAMFS=1/NEEDS_GRUB=1."
+ },
+ {
+ "component": "Web Preview",
+ "location": "/api/host-backups/restore/prepare i flask_server.py. Läser in hjälpbiblioteket, kör _rs_apply_bk_older_hydration 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 kernel_params som kompletteringen läser."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/destinations/borg.json b/web/messages/sv/docs/backup-restore/destinations/borg.json
new file mode 100644
index 00000000..d5ee7167
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/destinations/borg.json
@@ -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 borg create vid säkerhetskopiering och borg extract 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, hb_ensure_borg löser binären från fyra källor i ordning och returnerar den första som fungerar:",
+ "rows": [
+ {
+ "priority": "1",
+ "source": "Systemets borg",
+ "detail": "Om värden redan har borg installerat via APT (which borg löser), den binära används."
+ },
+ {
+ "priority": "2",
+ "source": "Cache för tillståndskatalogen",
+ "detail": "/usr/local/share/proxmenux/borg — sparat från en tidigare GitHub-nedladdning på värden."
+ },
+ {
+ "priority": "3",
+ "source": "Monitors AppImage-paket",
+ "detail": "/usr/local/share/proxmenux/monitor-app/usr/bin/borg - den AppImage buntar en signerad borg-linux64. Detta är offline-säker väg: en värd utan internet har fortfarande en fungerande borg."
+ },
+ {
+ "priority": "4",
+ "source": "GitHub nedladdning",
+ "detail": "wget mot borg-linux64 URL under github.com/borgbackup/borg/releases/, verifierad mot en konstant SHA-256 i lib_host_backup_common.sh (HB_BORG_LINUX64_SHA256). 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 borg serve. 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 hb_prompt_mounted_path, 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": "remote 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å /usr/bin/borg",
+ "detail": "command=\"/usr/bin/borg serve ...\"-linjen ProxMenux skriver i authorized_keys hårdkoder som väg. Installera via APT (apt install borgbackup) sätter den där. En fristående binär måste symlinkeras till /usr/bin/borg."
+ },
+ {
+ "requirement": "Ett dedikerat användarkonto (vanligtvis borg)",
+ "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 /backup/borgbackup) måste finnas på servern och ägas av borganvändaren."
+ },
+ {
+ "requirement": "SSH daemon accepterar borganvändaren",
+ "detail": "PubkeyAuthentication yes (standard). Lösenordsautentisering behövs endast för en-shot generate-auto-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 generate-auto installera nyckeln via ett konto som får skriva i borg-användarens authorized_keys. Senare säkerhetskopior använder nyckeln, begränsad till borg serve 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 borg serve. Den här användaren heter vanligtvis borg, 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, port 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å ~/.ssh/borg_proxmenux_HOST_ed25519 och använder sshpass för att testa inloggningen och installera den offentliga nyckeln i ~borg/.ssh/authorized_keys. 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 authorized_keys-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 pct exec från PVE-värden - root på PVE-värden skriver in i LXC ~borg/.ssh/authorized_keys utan att behöva SSH i LXC själv."
+ },
+ {
+ "mode": "existing",
+ "label": "Använd en befintlig nyckel",
+ "detail": "ProxMenux skannar /root/.ssh/ och $HOME/.ssh/ 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 ~/.ssh/id_rsa eller en SSH-agent)."
+ }
+ ],
+ "restrictTitle": "authorized_keys-linjen",
+ "restrictBody": "För varje skapad nyckel begränsar raden authorized_keys 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": "command= tvingar varje SSH-session med hjälp av den här nyckeln för att bara köra borg-serve-kommandot; restrict 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: NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE. Läs av hb_collect_borg_configs för att befolka målvalsmenyn."
+ },
+ {
+ "file": "borg-pass-NAME.txt",
+ "content": "Lösenfras för målet som anges som NAME ovan (chmod 600). 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 hb_borg_init_if_needed: den moderna borg repo-create -e MODE när den är tillgänglig, eller arvet borg init --encryption=MODE. ProxMenux avslöjar två lägen: repokey (standard) och none. I repokey-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 borg-pass-NAME.txt 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 borg. 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. När ett mål läggs till med en annan port än standard lägger ProxMenux även till -p PORT; sparade mål, schemalagda jobb och Monitor använder i stället porten i ssh://-URL:en. Utan egen nyckel, och för ett nytt mål 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 repokey-kryptering. Aldrig visas i processargumentlistan."
+ },
+ {
+ "var": "BORG_ENCRYPT_MODE",
+ "value": "repokey | none",
+ "purpose": "Används av hb_borg_init_if_needed när du startar ett förvar som ännu inte existerar. Ignorerad av borg create 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 run_scheduled_backup.sh borg prune mot förvaret efter varje framgångsrik backup med lagringsvärdena konfigurerade på jobbet (--keep-last, --keep-daily, --keep-weekly). Interaktiva säkerhetskopior inte beskär."
+ },
+ "restoreAccess": {
+ "heading": "Hämta vid återställning",
+ "body": "Återställningsflödet listar arkiv med borg list REPO och extraherar den valda med borg extract REPO::ARCHIVE-NAME i en staging katalog som _rs_check_layout 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 Hur det fungerar."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/destinations/index.json b/web/messages/sv/docs/backup-restore/destinations/index.json
new file mode 100644
index 00000000..793321f9
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/destinations/index.json
@@ -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 backup_host.sh — _bk_local, _bk_pbs, _bk_borg — men alla tre använder samma tillfälliga förberedelsesteg (hb_prepare_staging) 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 .tar.zst-fil (eller .tar.gz om zstd är frånvarande).",
+ "pbs": "PBS-säkerhetskopia (.pxar-block i datastoren).",
+ "borg": "Borg arkiv inuti ett Borg-förvar (segmentfiler)."
+ },
+ {
+ "feature": "Kompression",
+ "local": "zstd (standardnivå) via tar --zstd. 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 KEEP_LAST. 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 proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly. Interaktiva säkerhetskopior utför ingen rensning.",
+ "borg": "Tillämpas per schemalagt jobb via borg prune --keep-last / --keep-daily / --keep-weekly. 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": "tar, zstd (på Proxmox som standard).",
+ "pbs": "Paketet proxmox-backup-client (medföljer Proxmox VE 8+).",
+ "borg": "borg 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 proxmox-backup-client, PBS-inloggningsuppgifter och nyckelfilen (om säkerhetskopian är krypterad).",
+ "borg": "Kräver borg + 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 rootfs/ + metadata/ + manifest.json som beskrivs i Så fungerar det. Ett uppackat lokalt .tar.zst-arkiv, ett .pxar-arkiv återställt från PBS och ett Borg-arkiv uppackat med borg extract ger samma katalogträd. Återställningskoden (_rs_check_layout, _rs_apply, _rs_prepare_pending_restore) läser samma tre datablock utan att behöva veta vilken destination de kommer från."
+ },
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/destinations/local.json b/web/messages/sv/docs/backup-restore/destinations/local.json
new file mode 100644
index 00000000..858d0b06
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/destinations/local.json
@@ -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 hostcfg-HOST-TIMESTAMP.tar.zst-fil (eller .tar.gz när zstd är frånvarande). Filen innehåller hela arkivträdet - manifest.json, metadata/ och rootfs/ - och kan återställas på någon Proxmox värd med ProxMenux återställningsflöde, eller extraheras manuellt med tar --zstd -xf 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 enda sparad målkatalog — inte en lista. ProxMenux sparar användarens val i /usr/local/share/proxmenux/local-target.conf och läser det vid varje säkerhetskopiering. Om inget mål har konfigurerats används standardvärdet HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump (samma katalog som Proxmox använder för sina egna vzdump-utdata). Målet konfigureras via Konfigurera säkerhetskopieringsmål → Lokala mål:",
+ "options": [
+ "Använd standard (/var/lib/vz/dump). Proxmox lokal lagring. Finns på varje Proxmox-installation; arkivet sitter bredvid vzdump-utdata och hämtas av fliken Monitor's Backups automatiskt.",
+ "Ange en anpassad sökväg. Alla absoluta filsystemsökvägar kan användas: en NFS-montering, en SMB-delning monterad via fstab, ett särskilt ZFS-dataset eller en andra intern disk. ProxMenux kontrollerar att sökvägen finns och är en katalog innan valet sparas.",
+ "Välj en USB-enhet. Ö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 lsblk. 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 hb_mount_usb_partition: skapar /mnt/backup-LABEL (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 skriva den exakta enhetssökvägen (t.ex. /dev/sdb) 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 _bk_local att destinationskatalogen inte är en undersökväg till någon katalog som säkerhetskopieras. Ett vanligt misstag skulle vara att lägga till /root till profilen och välja /root/backups 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 readlink -m, 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 tar --zstd -cf — ett enda kommando som komprimerar med zstd:s standardnivå. Om zstd saknas på källan (ovanligt på Proxmox, men möjligt på minimala installationer) används gzip. Om pv finns vid denna reservmetod läggs en förloppsindikator till så att användaren ser arkivstorleken växa i realtid; utan pv används vanlig tar -czf utan förloppsutdata.",
+ "sourceTitle": "Vad går in i arkivet",
+ "sourceBody": "Kommandot tar anropas med -C \"$staging_root\" . och arkiverar därmed hela roten i den tillfälliga katalogen: rootfs/, metadata/ och manifest.json. 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: HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json, skriven bredvid arkivet av hb_write_archive_sidecar. 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 (kind), jobb-ID för schemalagda körningar, det profilläge som används (default eller custom), 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 *.proxmenux.json-sidofiler, inte efter *.tar.zst-filer, eftersom en .tar.zst 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 _rs_check_layout, 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 tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg samma träd som återställningskoden förbrukar."
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/destinations/pbs.json b/web/messages/sv/docs/backup-restore/destinations/pbs.json
new file mode 100644
index 00000000..2fe4d02b
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/destinations/pbs.json
@@ -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 proxmox-backup-client - 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, .pxar arkiv, --backup-id, 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 host/hostcfg-HOSTNAME/BACKUP-TIME. Innehållet är ett .pxar-arkiv med samma struktur i tre delar som beskrivs i Så fungerar det. 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 run_scheduled_backup.sh kommandot proxmox-backup-client prune med --keep-last / --keep-daily / --keep-weekly 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 HB_PBS_REPOSITORY, HB_PBS_SECRET och HB_PBS_FINGERPRINT för körningen.",
+ "sourceRows": [
+ {
+ "source": "Proxmox storage.cfg (identifierad automatiskt)",
+ "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
+ "content": "Varje pbs:-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 Konfigurera säkerhetskopieringsmål → PBS-mål → Lägg till PBS. Du anger namn, användarnamn (root@pam eller user@pbs!token), 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 ([proxmox] eller [manual]). Anteckningar vars lösenord inte kunde lösas är taggade med en ⚠ no password-varning - välja en utlöser ett lösenord återinträde innan backupen startar. Fingeravtrycket överförs till proxmox-backup-client via PBS_FINGERPRINT-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 proxmox-backup-client backup. ProxMenux använder env 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 hostcfg-HOSTNAME. Operatören bekräftar eller redigerar det före uppladdning; tecken utanför [A-Za-z0-9_-] och avslutande bindestreck tas bort. Att återanvända samma ID är avsiktligt: PBS behandlar ID:t som en grupp, och varje senare säkerhetskopia blir en ny post i gruppen med gemensam deduplicering med tidigare körningar.",
+ "pxarTitle": "Varför källan är hela staging roten",
+ "pxarBody": ".pxar-källan är hela staging_root - rootfs/, metadata/ och manifest.json tillsammans. Tidigare versioner passerade $staging_root/rootfs som källa; som lämnade metadata/ ur arkivet och återställningens kompatibilitetskontroll hade ingenting att läsa, försämrade att korsa värd varningar även på samma värd återställningar. Gamla säkerhetskopior som skapats med rootfs-bara källan återställs fortfarande korrekt via _rs_check_layout: s fall-3 gren, som lindrar en platt etc/var/root/usr träd tillbaka till en rootfs/ hierarki."
+ },
+ "encryption": {
+ "heading": "Klient-side kryptering",
+ "glossaryHint": "Avsnittet använder termerna nyckelfil, lösenfras och återställningskuvert. Ordlistan 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 /usr/local/share/proxmenux/pbs-key.conf 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: Nej fortsätter utan kryptering och Ja går till steg två. Det steget beror på om en nyckelfil redan finns på /usr/local/share/proxmenux/pbs-key.conf. 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. Skapa en ny nyckelfil kör proxmox-backup-client key create --kdf none. Använd en befintlig nyckelfil identifierar automatiskt en PVE-hanterad nyckel: om det valda PBS-förvaret är registrerat i Proxmox med en krypteringsnyckel på /etc/pve/priv/storage/<NAME>.enc, 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 chmod 600.",
+ "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 Använd en befintlig nyckelfil. 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 Ladda upp nyckeln till PBS? med två svar. Ingen återställningsfil laddas upp till PBS förrän operatören svarar Ja. Standardvalet är Nej, behåll endast lokalt: nyckelfilen ligger kvar på den kanoniska lokala sökvägen, ProxMenux laddar inte upp någon återställningsfil till PBS och operatören ansvarar själv för kopian utanför värden. Knappen Ladda ner nyckelfil på PBS-målets rad i Monitor ger en kopia vid behov. Valet Ja, ladda upp efterfrågar en återställningslösenfras två gånger och kontrollerar att svaren matchar. ProxMenux skyddar nyckelfilen med AES-256-CBC och PBKDF2 (600 000 iterationer, slumpmässigt salt) och skapar pbs-key.recovery.enc. Varje senare krypterad säkerhetskopia laddar upp detta kuvert till PBS som en tillhörande säkerhetskopieringsgrupp. Dessa uppladdningar skickar varken lösenfrasen eller nyckelfilen i klartext till PBS. Valet kan ändras när som helst i Monitor: kontrollen på PBS-målets rad växlar Ja/Nej och tillämpar omedelbart Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras beroende på aktuellt tillstånd.",
+ "blobUploadTitle": "Tillhörande säkerhetskopieringsgrupp på PBS",
+ "blobUploadBody1": "När läget är Ja, ladda upp laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra tillhörande grupp. Den har samma namn som värdens grupp med suffixet -keyrecovery. Grupperna visas bredvid varandra i datalagrets lista: en för värdsäkerhetskopior och en för återställningskuvert. Kuvertet lämnar aldrig värden i klartext: krypteringen sker på värden med AES-256-CBC och PBKDF2 innan några data överförs (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt). PBS tar endast emot det redan krypterade kuvertet.",
+ "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 proxmox-backup-client backup 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 /etc/pve/priv/storage/<NAME>.enc utan frågor till den kanoniska sökvägen, om den finns för det valda PBS-förvaret. Om det finns en -keyrecovery-grupp på PBS laddas sedan den senaste ögonblicksbilden ner och operatören anger återställningslösenfrasen för att dekryptera den. Om båda alternativen misslyckas eller avböjs efterfrågas till sist den absoluta sökvägen till nyckelfilen på värden, och filen kopieras till den kanoniska sökvägen. Monitor visar samma importflöde i säkerhetskopians detaljdialog. En gul panel visas överst när Återställ, Ladda ner eller Visa innehåll behöver en nyckel som saknas. Om en installerad nyckel inte matchar säkerhetskopian returnerar PBS wrong key — manifest's key XX does not match provided key YY. Samma tre åtgärder visar då en strukturerad panel med manifestets nödvändiga nyckelfingeravtryck tydligt utmärkt, så att operatören kan identifiera rätt nyckelfil att importera för säkerhetskopian.",
+ "monitorManagementTitle": "Hantera nyckelfilen från Monitor",
+ "monitorManagementBody": "Monitor visar nyckelfilens kontroller direkt på varje PBS-målrad i säkerhetskopieringskonfigurationen. Tre åtgärder finns: Ladda ner exporterar den aktuella filen till webbläsaren; Ladda upp ersätter den installerade filen med operatörens fil, och den gamla skrivs över först när den nya har installerats på den kanoniska sökvägen; Ta bort tar bort filen från värden. Bredvid finns kontrollen för återställningskopian: ett Ja/Nej-val för Ladda upp nyckeln till PBS?, ett lösenfrasfält när Ja väljs och en knapp som beroende på tillstånd tillämpar Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras. Alla åtgärder använder samma Flask-slutpunkter som terminalgränssnittet, så effekten på disk och tillståndet på PBS blir identiska från båda gränssnitten."
+ },
+ "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 proxmox-backup-client restore med samma förvar, lösenord och fingeravtryck, samt --keyfile om kopian är krypterad. Arkivet .pxar packas upp i en förberedelsekatalog som _rs_check_layout 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/glossary.json b/web/messages/sv/docs/backup-restore/glossary.json
new file mode 100644
index 00000000..613cf074
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/glossary.json
@@ -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 återställningskuvertet. 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. Det är inte passfrasen som låser upp nyckelfilen själv, 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 datablock före uppladdning till PBS. Utan rätt nyckel kan krypterade data inte läsas. ProxMenux sparar filen på /usr/local/share/proxmenux/pbs-key.conf med läge 600. Skydda den: återställningskuvertet 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 återställningspassfrasen. Det finns bara när nyckelfilen skapades med --kdf scrypt (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": "Nyckelfilen är insvept i ett extra lager: det är krypterat med Återhämtningspassfras Använda AES-256-CBC och PBKDF2 innan den någonsin lämnar värden. Det är det som laddas upp till PBS som den -keyrecovery 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 återställningskuvertet ovanpå."
+ },
+ {
+ "id": "kdf-none",
+ "term": "--kdf none",
+ "def": "Alternativ till proxmox-backup-client key create 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 proxmox-backup-client key create som producerar en nyckelfil skyddad av en nyckelfilspassfras. 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 openssl enc -aes-256-cbc) för att linda nyckelfilen med återställningspassfrasen och producera kuvertet."
+ },
+ {
+ "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 rsync enligt standardprofilen och egna sökvägar. 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 Hur det fungerar."
+ },
+ {
+ "id": "rutas-personalizadas",
+ "term": "Anpassade vägar",
+ "def": "Extra vägar som användaren lägger till ovanpå default profil. Antingen ihållande (lagras i backup-extra-paths.txt) 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 + datastore + användare som tar emot backupen. Identifierad av strängen user@realm@host:datastore. 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 proxmox-backup-client via PBS_FINGERPRINT 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 -keyrecovery-suffix för återställningskuvertet."
+ },
+ {
+ "id": "backup-id",
+ "term": "Säkerhetskopierings-ID",
+ "def": "Namnet på backup grupp. ProxMenux standarder till hostcfg-HOSTNAME 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": "run_scheduled_backup.sh-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å /var/lib/proxmenux/backup-jobs/<id>.env."
+ },
+ {
+ "id": "modo-adjunto",
+ "term": "Anslutet läge",
+ "def": "Jobb utan egen timer. En job-end-hook i PVE vzdump utlöser det efter gästsäkerhetskopior när mållagringen matchar. Det valda överordnade jobbet ger lagring och lagringsregler, som läses om från det överordnade jobbet vid varje körning, 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 oberoende schemalagt jobb; attach-mode 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 keep-last, keep-daily, keep-weekly, keep-monthly. 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 hydration 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 nyckelfil. Återställa en krypterad säkerhetskopia kräver första återställning av nyckelfilen från återställningskuvertet lagrad på PBS, med hjälp av återställningspassfrasen."
+ }
+ ]
+ }
+ ],
+ "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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/how-it-works.json b/web/messages/sv/docs/backup-restore/how-it-works.json
new file mode 100644
index 00000000..b50bb742
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/how-it-works.json
@@ -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 .tar.zst, PBS-säkerhetskopia eller Borg-arkiv) innehåller samma struktur. Återställningen använder alla tre: manifestet läses före ändringar för att upptäcka avvikelser och bestämma undantag; rootfs ger konfigurationsfiler som tillämpas direkt eller efter omstart; programinventeringen 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. metadata/ underkatalog håller de strukturerade nyttolasterna; rootfs/ 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 rootfs/ är en vanlig filsystemkopia som skapas med rsync från källvärden. Det innehåller en utvald standardprofil med sökvägar som behövs för Proxmox-återställning samt egna sökvägar som användaren lägger till i jobbet eller den interaktiva sessionen. Urvalet är avsiktligt begränsat till sökvägar som innehåller konfiguration eller lagrar tillstånd som Proxmox inte kan återskapa själv.",
+ "defaultProfileTitle": "Standardprofilen",
+ "defaultProfileBody": "Standardprofilen definieras av hb_default_profile_paths i lib_host_backup_common.sh. 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 (config.db) fångas som en konsekvent ögonblicksbild via sqlite3 .backup utan att stoppa klustret, och .db-wal / .db-shm sidovagnar är uteslutna från rsync. När sqlite3 inte är tillgänglig, skapas i stället config.db.raw-fallback, 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 .link under /etc/systemd/network 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 metadata/missing_paths.txt 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 /root. Volatila vägar (.bash_history, .cache/, tmp/, .local/share/Trash/) utesluts från kopian. /var/lib/proxmenux 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 zpool.cache och hostid."
+ }
+ ],
+ "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å /usr/local/share/proxmenux/backup-extra-paths.txt 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 Default-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; # kommentarer är tillåtna.",
+ "customModeTitle": "2. Anpassat läge (per körning)",
+ "customModeBody": "Att starta en säkerhetskopia i Custom-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 [+] och förmarkerade). Användaren markerar eller avmarkerar poster för den specifika körningen, och kan också trycka på Lägg till anpassad sökväg 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 metadata/missing_paths.txt 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 /etc/wireguard eller /etc/prometheus när dessa verktyg inte är installerade."
+ },
+ "manifest": {
+ "heading": "Manifestdelen",
+ "intro": "manifest.json är ett strukturerat JSON-dokument som beskriver källvärden vid backupen. Den produceras av sex oberoende insamlare orkestrerad av build_manifest.sh. 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 (pveversion), PBS version om värden kör backup-server roll, kärna (uname -r), 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 lsusb / lspci detektering), NICs (med MAC, PCI slot och bro medlemskap), trådlösa enheter. GPU-poster bär en passthrough_eligible-heuristisk."
+ },
+ {
+ "collector": "collect_storage.sh",
+ "produces": "storage_inventory",
+ "content": "ZFS-pooler (med pooltyp + medlemsdisker löste /dev/disk/by-id/*, /dev/disk/by-partuuid/* eller rå /dev/sdX-vägar beroende på hur varje pool ursprungligen skapades), LVM-volymgrupper + tunna pooler, fysiska diskar med SMART-kapacitet, PVE storage.cfg-poster, externa monteringar."
+ },
+ {
+ "collector": "collect_kernel.sh",
+ "produces": "kernel_params",
+ "content": "Parametrar som operatören lagt till i /proc/cmdline, utan standardposter som BOOT_IMAGE=, root=, ro/rw, quiet och splash; moduler som laddas vid start från /etc/modules; sökvägar till /etc/modprobe.d/*.conf-filer med faktiska direktiv (options, blacklist, install, alias, softdep)."
+ },
+ {
+ "collector": "collect_proxmenux_state.sh",
+ "produces": "proxmenux_installed_components",
+ "content": "Läser /usr/local/share/proxmenux/managed_installs.json (registret över allt ProxMenux har installerat) och installed_tools.json. Varje post håller installationsbanan (menu_script) så att återställningen kan utlösa exakt samma installationsflöde."
+ },
+ {
+ "collector": "collect_guests.sh",
+ "produces": "vms_lxcs_at_backup",
+ "content": "Uppräknar VMs (qm list) och LXCs (pct list) närvarande vid backuptid - VMID, namn, aktuell status. Endast inventeringen: de faktiska gästdata är vzdump/PBS."
+ }
+ ],
+ "schemaTitle": "Schema validering",
+ "schemaBody": "manifestet validerar mot scripts/backup_restore/schema/manifest.schema.json. Kör build_manifest.sh --validate utlöser en Python-side JSON Schema validering (kräver python3 + jsonschema). Om modulen inte är närvarande, är kontrollen hoppad tyst - validering är i första hand ett utvecklarhjälp, inte ett drifttidsberoende."
+ },
+ "applications": {
+ "heading": "Applikationsinventeringen",
+ "intro": "Två inventeringar listar programvara utöver Proxmox VE:s baspaket: paketlistan under metadata/ 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 apt-mark showmanual med alla APT-paket som uttryckligen installerats på källvärden. Beroenden till Proxmox VE:s bassystem ingår inte; målets APT installerar dem automatiskt. Under återställningen läser _rs_run_complete_extras listan och använder ett filter mot borttagning i kaskad i tre steg: dpkg -s hittar redan installerade paket, andra huvudversioner av bibliotek identifieras och apt-get install --simulate kontrollerar risken för följdborttagningar. Återstående paket installeras med apt-get install -y.",
+ "componentsTitle": "components_status.json (del av rootfs)",
+ "componentsBody": "En JSON registret under /usr/local/share/proxmenux/ som registrerar varje komponent ProxMenux har installerat med sitt exakta tillstånd: version, ProxMenux-specifika flaggor (för NVIDIA: patched boolean; för Coral: DKMS version). Denna fil lever i rootfs - inte i metadata/ - eftersom det är läses efter att rootfs har kopierats till målet. Post-boot dispatcher (apply_cluster_postboot.sh) itererar över sina poster och kör varje komponent --auto-reinstall 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 --auto-reinstall ingångspunkt:",
+ "installerRows": [
+ {
+ "component": "nvidia_driver",
+ "installer": "gpu_tpu/nvidia_installer.sh",
+ "action": "Läser version + patched. 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 .deb 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 packages.manual.list."
+ }
+ ]
+ },
+ "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 hb_compat_check. Jämför källa vs mål hårdvara (NIC, lagrings-ID), PVE-version och stor kärnversion. Set HB_COMPAT_KERNEL_DIRECTION (same, bk_newer eller bk_older) och befolkar RS_SKIP_PATHS med hårdvara-drift och cross-kernel uteslutningar."
+ },
+ {
+ "stage": "2",
+ "name": "Tillämpning under drift",
+ "reads": "rootfs/ (endast säkra vägar)",
+ "action": "_rs_apply … hot kopierar hb_classify_path=hot-poster direkt till live-målet. Allt under /etc/pve, /etc/network eller vägar som klassificeras som reboot/dangerous uppskjuts."
+ },
+ {
+ "stage": "3",
+ "name": "Förbered uppskjutna ändringar",
+ "reads": "rootfs/ (omstart + farliga vägar)",
+ "action": "_rs_prepare_pending_restore förbereder riskfyllda sökvägar under /var/lib/proxmenux/pending-restore/, skriver plan.env, apply-on-boot.list och rs-skip-paths.txt och aktiverar proxmenux-restore-onboot.service för nästa start."
+ },
+ {
+ "stage": "3b",
+ "name": "Datapool import",
+ "reads": "manifest.storage_inventory + mål ZFS tillstånd",
+ "action": "_rs_import_data_pools försöker importera varje ZFS-pool utan rotfilsystem vars samtliga diskar finns på målet. Pooler med ett annat hostid provas igen med zpool import -f. Om någon disk saknas hoppas poolen över med en varning. Resultatet per pool loggas i /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "stage": "4",
+ "name": "Paketinstallation",
+ "reads": "metadata/packages.manual.list",
+ "action": "_rs_run_complete_extras kör kaskadsäkert filter och kallar apt-get install -y med den överlevande paketlistan. Fullständig utdata går till /var/log/proxmenux/restore-apt-*.log."
+ },
+ {
+ "stage": "5",
+ "name": "Efter uppstart",
+ "reads": "rootfs (redan tillämpat) + components_status.json",
+ "action": "Efter omstart, apply_pending_restore.sh spelar tillbaka de uppskjutna banorna och apply_cluster_postboot.sh kör update-initramfs, update-grub (eller proxmox-boot-tool refresh) och itererar över components_status.json skjuter varje komponent --auto-reinstall krok."
+ }
+ ]
+ },
+ "whyItWorks": {
+ "heading": "Varför säkerhetskopian delas i tre delar",
+ "body": "Uppdelningen följer uppgifternas livscykel. Filsystemet överförs med rsync: snabbt, öppet och atomärt per fil. Konfigurationstillstånd som måste tolkas före ändringar lagras som strukturerad JSON, 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 inventering 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."
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/index.json b/web/messages/sv/docs/backup-restore/index.json
new file mode 100644
index 00000000..0c60947e
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/index.json
@@ -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: filsystemet, med relevanta kataloger under /etc, /root och /var/lib/pve-cluster samt valfria egna sökvägar; ett strukturerat manifest i JSON med upptäckt maskinvara, kärnparametrar, nätverkskonfiguration, ZFS-status, användare och cron-poster; och en programinventering 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 av värden: själva Proxmox-installationen, inte de program och gästsystem som körs på den.",
+ "items": [
+ "Det här är inget verktyg för säkerhetskopiering av VM:ar eller CT:er. Funktionen sparar varken gästernas diskar eller RAM-tillstånd; det sköts av vzdump. Gästernas konfigurationsfiler (/etc/pve/nodes/<node>/qemu-server/*.conf och lxc/*.conf) ingår däremot. Efter återställning visas inventeringen igen, och diskarna kan återställas eller anslutas från en befintlig PBS- eller lokal säkerhetskopia.",
+ "Det här är ingen åtgärd för hela klustret. Varje nod säkerhetskopierar sig själv. Klustertillhörigheten sparas i /etc/pve så att en återställd nod kan anslutas igen, men återställning av hela klustret kräver samordning mellan noderna.",
+ "Det här är ingen fullständig diskavbildning. 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 update-initramfs 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 målets aktuella kärna, 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 hydrering 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 Hur det fungerar om målet är att förstå vad arkivet innehåller och varför. Hoppa till Destinationer för att konfigurera målet för kopian. Läs Återställning och Återställning mellan kärnversioner 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."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/restoring.json b/web/messages/sv/docs/backup-restore/restoring.json
new file mode 100644
index 00000000..2d86fed6
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/restoring.json
@@ -0,0 +1,282 @@
+{
+ "meta": {
+ "title": "Återställ en backup - full och anpassade flöden | ProxMenux",
+ "description": "Hela återställningsflödet: visa, ladda ner eller återställa en säkerhetskopia, kompatibilitetskontroll och resultat, fullständigt eller anpassat läge, sökvägar som tillämpas direkt eller efter omstart samt startskriptet och ominstallation av komponenter efter start.",
+ "ogTitle": "ProxMenux Backup - återställande",
+ "ogDescription": "Fullständiga och anpassade återställningsflöden med kompatibilitetskontrollen, banklassificering, on-boot dispatcher och post-boot ominstallation.",
+ "twitterTitle": "Återställ en backup | ProxMenux",
+ "twitterDescription": "Hur en ProxMenux värd backup förvandlas tillbaka till en fungerande Proxmox värd."
+ },
+ "header": {
+ "title": "Återställ en backup",
+ "description": "Det fullständiga återställningsflödet: från att välja ett arkiv till en fungerande värd. Dokument kompatibilitetskontrollen, de två återställningslägena, on-boot-avsändaren, post-boot-ominstallationspasset och de mekanismer som gör cross-host och cross-kernel-återställningar förutsägbara.",
+ "section": "Säkerhetskopiering och återställning"
+ },
+ "intro": {
+ "title": "Återställningen reproducerar källan, inte bara filerna",
+ "body": "Att återställa en ProxMenux-säkerhetskopia innebär mer än att packa upp filer. Före ändringar läses manifestet för att hitta skillnader mellan källa och mål, sökvägar som kan hindra starten utesluts och användarinställningar som inte kan kopieras direkt anpassas. Efter den nödvändiga omstarten försöker processen installera om de registrerade komponenter som stöds (NVIDIA-drivrutin, Coral TPU och GPU-verktyg) för målets aktiva kärna. Ett enda arkiv styr kompatibilitetskontroll, sökvägsklassificering och arbetet under och efter start. Kontrollera resultaten per komponent och loggarna för att bekräfta utfallet."
+ },
+ "threeActions": {
+ "heading": "Tre åtgärder på en backup",
+ "intro": "Välja en säkerhetskopia från listan öppnar en meny med tre åtgärder.",
+ "actionRows": [
+ {
+ "action": "Visa",
+ "detail": "Öppnar en skrivskyddad vy av arkivet: manifest.json-innehåll (källvärdnamn, PVE-version, kärna, hårdvara, installerade komponenter), listan över vägar inuti rootfs/ och en diff av vad som skulle förändras på den aktuella värden om säkerhetskopieringen tillämpades."
+ },
+ {
+ "action": "Ladda ner",
+ "detail": "Exporterar arkivet som en bärbar .tar.zst-fil (tar komprimerad med zstd). Det kan extraheras på alla Linux-system med tar --zstd -xf FILE.tar.zst, eller på macOS / Windows med något verktyg som stöder zstd (7-Zip, PeaZip, Keka ...). Det extraherade trädet innehåller manifest.json, metadata/ och rootfs/ - exakt samma layout som återställningen förbrukar. Användbar för offline inspektion eller för att återställa på en värd utan tillgång till den ursprungliga destinationen (PBS, Borg)."
+ },
+ {
+ "action": "Återställa",
+ "detail": "Åtgärden som skriver till systemet. Packar upp arkivet i en förberedelsekatalog, kör kompatibilitetskontrollen och visar valet mellan fullständig och anpassad återställning."
+ }
+ ]
+ },
+ "compatibilityCheck": {
+ "heading": "Kompatibilitetskontrollen",
+ "intro": "Innan någon fil skrivs jämför hb_compat_check det tillstånd som beskrivs i manifestet mot målvärden. Kontrollen läser endast data och producerar fyra oberoende utgångar som driver resten av återställningen.",
+ "outputRows": [
+ {
+ "output": "Riktningsflaggan",
+ "detail": "HB_COMPAT_KERNEL_DIRECTION är same, bk_newer eller bk_older efter jämförelse av kärnans huvudversion i säkerhetskopian och på målet. Det styr filtret för säkra sökvägar mellan kärnor, som bara används vid bk_older, och anpassningen av inställningar som beskrivs på sidan om återställning mellan kärnversioner."
+ },
+ {
+ "output": "Lista över undantagna sökvägar",
+ "detail": "RS_SKIP_PATHS varje väg som restaureringen inte får tillämpa. Befolkad av två mekanismer: hårdvarudrift (saknas NIC, saknas lagrings-ID, utländsk ZFS pool) och — när riktningen är bk_older - cross-kernel unsafe-paths lista."
+ },
+ {
+ "output": "Plan för ommappning av nätverkskort",
+ "detail": "När en NIC på målet har samma MAC som en på källan men ett annat namn (typiskt efter en moderkortsbyte), registrerar kompatibilitetskontrollen en bytesplan (HB_NIC_REMAP) som kommer att skriva om /etc/network/interfaces under återställningen."
+ },
+ {
+ "output": "Återställningsplan",
+ "detail": "Beräknas av compute_rollback_plan.sh. Listar VM, LXC och komponenter som finns på målet men saknas i säkerhetskopian. Bekräftelsen erbjuder valfri borttagning av extra gäster före omstart. Komponenter tas bort manuellt och gästborttagning kan misslyckas; en exakt matchning garanteras därför inte."
+ }
+ ],
+ "reportBody": "Kontrollen avger också en strukturerad rapport (HB_COMPAT_RESULTS) som kategoriseras som PASS / INFO / WARN / FAIL. WARN och FAIL-poster dyker upp i panelen före återställningen; återställningen vägrar att fortsätta först när en FAIL är närvarande att användaren inte kan lösa genom att klicka på Fortsätt."
+ },
+ "twoModes": {
+ "heading": "Full återställning vs Anpassad återställning",
+ "intro": "Efter kompatibilitetskontrollen visas lägesvalet. Det avgör vad som tillämpas och inte hur: båda lägena använder samma process.",
+ "modeRows": [
+ {
+ "mode": "Full återställning",
+ "detail": "Gäller varje väg i arkivet som överlever drift och cross-kernel filter. Kör också paketet installera och komponenten auto-reinstall pass. Detta är standarden och det rekommenderade valet - målet är att reproducera källan, inte plocka bitar."
+ },
+ {
+ "mode": "Anpassad återställning",
+ "detail": "Öppnar en checklista med alla sökvägar i arkivet. Användaren väljer en delmängd. Sökvägar som blockeras av filtret mellan kärnor är grå och kan inte väljas. Paketinstallation och automatisk ominstallation av komponenter hoppas över som standard i anpassat läge, eftersom användaren begär en partiell återställning."
+ }
+ ]
+ },
+ "pathClassification": {
+ "heading": "Hur vägar klassificeras",
+ "intro": "Varje väg som valts för återställningen klassificeras av hb_classify_path i en av tre kategorier. Kategorin bestämmer när vägen tillämpas på systemet och varför.",
+ "rows": [
+ {
+ "class": "hot",
+ "detail": "Paths tillämpade omedelbart till körsystemet. Tjänsten som förbrukar dem plockar upp förändringen på egen hand eller vid nästa reload - ingen omstart krävs. Dessa är huvuddelen av en säkerhetskopia: /etc/ssh, /etc/apt, /etc/cron.*, /root, /usr/local/bin, allmänna servicekonfigurationsfiler etc."
+ },
+ {
+ "class": "reboot",
+ "detail": "Sökvägar som skjuts upp till nästa start i stället för att tillämpas omedelbart av återställningen. De påverkar startkonfigurationen: genereringen av starthanteraren läser /etc/default/grub, monteringar använder /etc/fstab och modulladdning /etc/modules. De väntande filerna tillämpas efter omstart och nödvändiga startfiler genereras sedan om. Exempel: /etc/default/grub, /etc/kernel, /etc/modules, /etc/fstab, /etc/zfs, /etc/modprobe.d."
+ },
+ {
+ "class": "dangerous",
+ "detail": "Sökvägar som INTE tillämpas på det körande systemet: en skrivning under drift kan förstöra tillståndet eller bryta den aktiva anslutningen. De läggs i den väntande uppsättningen: /etc/network skrivs tidigt vid nästa start, innan nätverket startar, och /etc/pve skrivs av efterstartsdistributören när klusterfilsystemet är uppe. Exempel: /etc/pve (pmxcfs är en aktiv FUSE-montering med klustrets konfiguration), /var/lib/pve-cluster (aktiva klusterdata, sparade i återställningskatalogen endast för manuell återställning), /etc/network (kan konfigurera om just det gränssnitt som SSH-anslutningen använder och bryta sessionen)."
+ }
+ ]
+ },
+ "fullFlow": {
+ "heading": "Fullständig återställning arbetsflöde",
+ "intro": "Den kompletta pipeline från arkivval till en återställd arbetsvärd. Varje steg matar nästa, staten skriven av tidigare stadier konsumeras av senare.",
+ "diagram": "┌─────────────────────────────────────────────────────────────────┐\n│ Archive → staging_root/ │\n│ manifest.json metadata/ rootfs/ │\n└──────────────────────────────┬──────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 1. hb_compat_check │\n │ · hardware drift → RS_SKIP_PATHS │\n │ · kernel direction → same / bk_newer / bk_older │\n │ · NIC remap plan │\n │ · hydration plan (bk_older only) │\n │ · rollback plan │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 2. Confirmation dialog │\n │ Shows: hot count, pending count, drift, hydration, │\n │ NIC remap, cross-kernel note, reinstalls preview │\n └──────────────────────────────┬──────────────────────────┘\n │ (accepted)\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 3. Apply hot paths → LIVE │\n │ _rs_apply rsyncs each hot path │\n │ from staging_root/rootfs to / │\n │ (skips paths in RS_SKIP_PATHS) │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4. _rs_prepare_pending_restore │\n │ /var/lib/proxmenux/pending-restore/ │\n │ ├── apply-on-boot.list │\n │ ├── plan.env │\n │ ├── rs-skip-paths.txt │\n │ └── rootfs/ (deferred paths) │\n │ Enable proxmenux-restore-onboot.service │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 4b. _rs_import_data_pools │\n │ Imports non-root ZFS pools whose disks are all │\n │ present; retries with -f on foreign hostid; │\n │ skips with a warning when disks are missing. │\n │ Log: /var/log/proxmenux/restore-datapools-*.log │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 5. _rs_run_complete_extras │\n │ packages.manual.list │\n │ → cascade-safe filter │\n │ → apt-get install │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 6. REBOOT │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 7. apply_pending_restore.sh (on early boot) │\n │ Reads plan.env │\n │ Applies apply-on-boot.list (filtered) │\n │ Installs the postboot systemd unit │\n └──────────────────────────────┬──────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ 8. apply_cluster_postboot.sh (~10 minutes) │\n │ Runs after pve-cluster is up │\n │ · Applies /etc/pve entries to pmxcfs │\n │ · update-initramfs -u -k all │\n │ · update-grub / proxmox-boot-tool refresh │\n │ · component --auto-reinstall (nvidia, coral, ...) │\n │ · Boot sanity check │\n │ · Notification: \"Host restore finished\" │\n └─────────────────────────────────────────────────────────┘"
+ },
+ "pendingMachinery": {
+ "heading": "Mekanismen för uppskjuten återställning",
+ "intro": "Paths som klassificeras som reboot eller dangerous, och hydrering skriver, iscensätts för nästa start istället för att appliceras live. Detta görs genom en liten, självinnehållen uppsättning filer under /var/lib/proxmenux/pending-restore/:",
+ "rows": [
+ {
+ "file": "apply-on-boot.list",
+ "content": "En relativ sökväg per rad: exakt de sökvägar som apply_pending_restore.sh tillämpar från förberett rootfs. Filen visar vad som ändras vid nästa start."
+ },
+ {
+ "file": "plan.env",
+ "content": "Miljövariabler som hämtats från on-boot script: restaurera ID, kompatibilitetsflaggor (HB_COMPAT_CROSS_VERSION, HB_COMPAT_KERNEL_DIRECTION, HB_HYDRATION_APPLIED), Rollback opt-in flagga, kluster alternativ."
+ },
+ {
+ "file": "rs-skip-paths.txt",
+ "content": "Den slutliga RS_SKIP_PATHS-listan, kvarstår så apply_pending_restore.sh tillämpar samma uteslutningar efter omstart som beräknades under det interaktiva steget. Förhindrar driftdrabbade eller kors-kernel-osäkra vägar från att återställas vid starttid."
+ },
+ {
+ "file": "rootfs/",
+ "content": "Själva förberedda filerna: exakt de byte som ska skrivas. De lagras på samma filsystem som / så att rsync vid start går snabbt och inte kräver åtkomst till extern lagring."
+ }
+ ],
+ "unitBody": "Systemd-enheten proxmenux-restore-onboot.service aktiveras i slutet av det interaktiva steget. Engångstjänsten körs tidigt vid nästa start, anropar apply_pending_restore.sh och inaktiverar sedan sig själv. Villkoret ConditionPathExists=/var/lib/proxmenux/pending-restore/state gör att inget körs vid starter utan väntande återställning."
+ },
+ "postbootDispatcher": {
+ "heading": "Post-boot dispatcher - apply_cluster_postboot.sh",
+ "intro": "Där det interaktiva steget slutar och där den faktiska värdreproduktionen sker. apply_cluster_postboot.sh installeras som en andra one-shot systemd-enhet (proxmenux-apply-cluster-postboot.service) vars After=/Wants=-mål säkerställer att det körs först efter att pve-cluster och nätverk-online är uppe. Det är här värdsynliga återställningsåtgärder landar.",
+ "tasks": [
+ {
+ "task": "Applicera /etc/pve",
+ "detail": "/etc/pve är ett levande pmxcfs FUSE-fäste - det kan inte skrivas till på tidig start. Dispatcher kopierar filer från de förberedda rootfs till live /etc/pve när klusterfilsystemet är upp, en fil i taget, utan att starta om pve-kluster. Den fångade /var/lib/pve-cluster/config.db från backupen (eller den befordrade config.db.raw-fallback) materialiseras med systemctl stop pve-cluster → atomfilkopia → systemctl start pve-cluster mönster, så pmxcfs återläser det återställda tillståndet på vägen tillbaka upp."
+ },
+ {
+ "task": "Rebuild initramfs och bootloader",
+ "detail": "Kör update-initramfs -u -k all över varje installerad kärna, sedan antingen update-grub (GRUB-installationer) eller proxmox-boot-tool refresh (systemd-start / ZFS-installationer). Skippades om det interaktiva steget fastställde ingenting förändrades i de vägar som påverkar dessa verktyg."
+ },
+ {
+ "task": "Komponent auto-reinstallation",
+ "detail": "Läser återställd components_status.json och går igenom de installationsprogram som stöds (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Varje valt program körs med --auto-reinstall, läser registrerat tillstånd och installerar för målmiljön, med ombyggnad av kärnmoduler där det behövs. Arbetet väntar till efter omstart för att använda målets då aktiva kärna. Enskilda fel loggas och stoppar inte nästa komponent."
+ },
+ {
+ "task": "Rimlighetskontroll vid uppstart",
+ "detail": "Innan du skjuter slutförandet av meddelandet, verifierar att proxmox-boot-tool status visar en konfigurerad ESP, har varje /boot/vmlinuz-* en matchande /lib/modules/<ver>-katalog och /vmlinuz löser. Varje inkonsistens dyker upp i meddelandet istället för att vara dold."
+ },
+ {
+ "task": "Slutförande anmälan",
+ "detail": "Skickar Host restore finished-eventet genom hb_notify_lifecycle. Inkluderar total varaktighet, tillämpad vägräkning, sanity-check varningar om någon, och en länk till loggen på /var/log/proxmenux/proxmenux-cluster-postboot-*.log. Om meddelanden inte är konfigurerade är händelsen tyst - loggen registrerar fortfarande allt."
+ }
+ ]
+ },
+ "liveProgress": {
+ "heading": "Aktuellt förlopp på fliken Säkerhetskopior i Monitor",
+ "body": "Efter omstarten av Backups-fliken ProxMenux Monitor gör ett live post-restore-kort som återspeglar tillståndet proxmenux-apply-cluster-postboot.service som det körs. Kortet drivs av /var/lib/proxmenux/restore-state.json, som avsändaren uppdaterar på varje milstolpe (tillämplig klusterkonfig, återuppbygga initramfs, uppdatera bootloader, per-component ominstallera, start sanity check, slutföra).",
+ "fields": [
+ {
+ "name": "Statusmärke",
+ "detail": "Något av tillstånden Återställning pågår, Återställning klar eller Återställning misslyckades. Kortet läser tillståndsfilen varannan sekund under körning och var 30:e sekund efter avslut."
+ },
+ {
+ "name": "Förloppsindikator och stegräknare",
+ "detail": "Visar N/M steps med namnet på det aktuella steget. Under återställningen beräknas en uppskattad tid från slutförda steg och förfluten tid."
+ },
+ {
+ "name": "Komponentlista",
+ "detail": "En rad per drivrutin installeras om (NVIDIA, Intel GPU verktyg, AMD verktyg, Coral TPU) med installing / ok / failed plus en länk till per-komponent logga på /var/log/proxmenux/component-*.log."
+ },
+ {
+ "name": "Datapool import",
+ "detail": "Blocket data_pools_import visar fem färgade rader: Importerade, Tvingade (med -f för ett annat hostid), Överhoppade, delvis närvarande (bara vissa diskar finns), Överhoppade, saknade (inga diskar finns) och Misslyckade. Tillståndet sparas i /var/lib/proxmenux/restore-state.json och hela körningsloggen i /var/log/proxmenux/restore-datapools-<timestamp>.log."
+ },
+ {
+ "name": "Varningar om startkonfigurationen",
+ "detail": "Processen kontrollerar saknade /lib/modules/<kernel>-kataloger, saknad ESP-konfiguration och /vmlinuz-länkar utan giltigt mål. Varningar visas här i en färgad ruta."
+ },
+ {
+ "name": "Återställningsdelta",
+ "detail": "Listor VMs, LXCs och komponenter som finns på målet men inte var i den återställda backupen - samma poster som uppstod i förväg destruktiv återgångsdialog. Varje rad bär manuell rensning kommandot."
+ },
+ {
+ "name": "Loggens slut",
+ "detail": "De sista 600-linjerna i proxmenux-cluster-postboot-<ts>.log, med ett Endast problem-filter som håller bara linjer som matchar error, warning, failed, ✗ eller traceback."
+ }
+ ],
+ "dismissBody": "När återställningen är klar eller misslyckad fäller knappen Dölj ihop kortet. Tillståndsfilen bevaras och Historik öppnar denna och tidigare återställningar igen. De senaste 20 körningarna arkiveras under /var/lib/proxmenux/restore-history/.",
+ "imageAlt": "Detaljdialogen för återställning i ProxMenux Monitor under körning: blå statusmarkering, aktuellt steg Bygger om initramfs, uppskattad återstående tid, delvis fylld förloppsindikator och aktuella loggrader.",
+ "imageCaption": "Detaljerna modal medan post-boot-avsändaren fortfarande kör - emblem, aktuellt steg, tid kvar och levande loggsvans.",
+ "detailsImageAlt": "Samma detaljer modal efter återställningen har avslutats, med den gröna återställningen fullständiga märket, den totala löptiden (0m53s), en fullt fylld 6 / 6 framstegsfältet, den tomma Rollback delta och den arkiverade postboot log.",
+ "detailsImageCaption": "Samma modal när körningen har avslutats - emblem, total varaktighet, fylld progress bar och arkiverad postboot logg."
+ },
+ "postbootExample": {
+ "heading": "Hur post-boot ser ut på konsolen",
+ "body": "På den fysiska konsolen avslutas en process som lyckas med [ OK ] Finished proxmenux-apply-cluster-postboot.service, ofta nära OK för multi-user.target och graphical.target. Detta markerar att processen har avslutats. Enskilda komponentfel eller startvarningar kan ändå ha registrerats. Kontrollera komponenternas tillstånd och loggarna i Monitor innan värden betraktas som helt återställd.",
+ "imageAlt": "Proxmox fysiska konsol med '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).', följt av OK för multi-user.target och graphical.target och med inloggningsraden ovanför.",
+ "imageCaption": "Fysisk konsol när processen avslutats. 'Finished proxmenux-apply-cluster-postboot.service' markerar slutet, vilket även 'Host restore finished' visar i Monitor. Komponentresultat och varningar behöver fortfarande granskas."
+ },
+ "tenMinutes": {
+ "heading": "Varför de senaste tio minuterna är viktigt",
+ "intro": "Omstarten själv tar sekunder, men post-boot-avsändaren spenderar cirka tio minuter efter återställningen. Under detta fönster är värden nåbara och inloggningsarbeten, men vissa tjänster (främst GPU-drivrutinberoende) är ännu inte tillgängliga. Tidsuppdelning för en typisk Proxmox-värd med NVIDIA + Coral installerad:",
+ "rows": [
+ {
+ "stage": "Boot + pve-cluster redo",
+ "time": "~30 s",
+ "detail": "Standard Proxmox boot. SSH, webb-UI och inloggning är tillgängliga i slutet av detta skede."
+ },
+ {
+ "stage": "Applicera /etc/pve till pmxcfs",
+ "time": "~10 s",
+ "detail": "Snabba - små konfigfiler kopierade en efter en till live klusterfilsystemet."
+ },
+ {
+ "stage": "Rebuild initramfs över kärnor",
+ "time": "3–5 min",
+ "detail": "update-initramfs -u -k all bygger en initramfs avbildning per installerad kärna. Större delen av väntetiden."
+ },
+ {
+ "stage": "Bygg om starthanterarens konfiguration",
+ "time": "10–30 s",
+ "detail": "update-grub eller proxmox-boot-tool refresh. Snabbt även på ZFS."
+ },
+ {
+ "stage": "NVIDIA ominstallation av drivrutin (om tillämpligt)",
+ "time": "5–10 min",
+ "detail": "Ladda ner den inspelade drivrutinsversionen, sammanställer DKMS-modulerna mot den nuvarande kärnan, tillämpar ProxMenux-patchen om källan hade den. Längsta enskilda uppgift."
+ },
+ {
+ "stage": "Ominstallation av Coral och andra komponenter",
+ "time": "3–5 min",
+ "detail": "DKMS-kompilering för Coral, apt install för intel-gpu-tools samt nedladdning och installation av .deb för amdgpu_top."
+ },
+ {
+ "stage": "Startkontroll och meddelande",
+ "time": "~2 s",
+ "detail": "Kräver få resurser. Meddelandet informerar användaren så snart körningen har avslutats."
+ }
+ ],
+ "outroBody": "Under denna tid kan verktyg saknas efter inloggning (nvidia-smi hittas inte, coral identifieras inte), eftersom ominstallationen fortfarande körs i bakgrunden. Slutmeddelandet markerar arbetets slut; kontrollera komponentresultat, varningar och loggar för att skilja lyckade åtgärder från enskilda fel."
+ },
+ "destructiveRollback": {
+ "heading": "Den valfria destruktiva rollback",
+ "body": "Återställningen är additiv som standard: extra VM, LXC och komponenter blir kvar. Vid skillnader erbjuder bekräftelsen Kör destruktiv återställning?, med Nej som standard. Ja anropar _rs_execute_rollback före omstart för att försöka ta bort de listade extra VM:erna och LXC:erna. Komponenter markeras för manuell avinstallation eftersom automatisk avinstallation saknas. Fel vid borttagning rapporteras och processen fortsätter, så en exakt matchning garanteras inte. Granska namn och VMID/CTID före detta destruktiva val."
+ },
+ "logs": {
+ "heading": "Var loggarna finns",
+ "rows": [
+ {
+ "log": "/var/log/proxmenux/restore-YYYYMMDD_HHMMSS.log",
+ "detail": "Skrivs under det interaktiva steget: kompatibilitetsresultat, avvikelsefilter, anpassningsplan, utdata från direkt tillämpning och förberedelse av uppskjutna ändringar samt paketinstallation."
+ },
+ {
+ "log": "/var/log/proxmenux/apply-pending-YYYYMMDD_HHMMSS.log",
+ "detail": "Skrivs av apply_pending_restore.sh tidigt vid start: inläsning av plan.env, genomgång av apply-on-boot och filtrering av undantagna sökvägar."
+ },
+ {
+ "log": "/var/log/proxmenux/proxmenux-cluster-postboot-YYYYMMDD_HHMMSS.log",
+ "detail": "Skrivs av apply_cluster_postboot.sh: tillämpning av pve-cluster-konfiguration, utdata från initramfs och starthanterare, komponenternas installationsutdata, startkontroll och meddelandeinnehåll."
+ },
+ {
+ "log": "/var/log/proxmenux/component--YYYYMMDD_HHMMSS.log",
+ "detail": "En logg per komponentinstallationsprogram (nvidia, coral, etc.) som kördes i post-boot-passet. Användbart när en specifik komponents ominstallation misslyckades och användaren behöver verktygets egen utdata."
+ },
+ {
+ "log": "/var/log/proxmenux/restore-datapools-YYYYMMDD_HHMMSS.log",
+ "detail": "Skriven av _rs_import_data_pools. Innehåller: uppräkning av icke-rotpooler från det manifesterade, perpoolresultatet (importerad rent, importerad med -f för ett annat hostid, hoppad på grund av saknade diskar eller misslyckades), och råutdata av varje zpool import samtal."
+ }
+ ]
+ },
+ "whereNext": {
+ "heading": "Vart ska man gå nästa",
+ "items": [
+ {
+ "label": "Återställning mellan kärnversioner",
+ "href": "/docs/backup-restore/cross-kernel",
+ "tail": " - det riktningsmedvetna säkra filtret och det hydreringspass som åberopats när målkärnan skiljer sig från säkerhetskopieringen."
+ },
+ {
+ "label": "Hur det fungerar",
+ "href": "/docs/backup-restore/how-it-works",
+ "tail": " - arkivlayouten, manifestet och appliceringsinventeringen som återställningen förbrukar."
+ },
+ {
+ "label": "Planerade jobb",
+ "href": "/docs/backup-restore/scheduled-jobs",
+ "tail": " - det obevakade flödet som producerar arkiven denna sida förbrukar."
+ }
+ ]
+ }
+}
diff --git a/web/messages/sv/docs/backup-restore/scheduled-jobs.json b/web/messages/sv/docs/backup-restore/scheduled-jobs.json
new file mode 100644
index 00000000..ae00c752
--- /dev/null
+++ b/web/messages/sv/docs/backup-restore/scheduled-jobs.json
@@ -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": [
+ "Nytt oberoende jobb - 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.",
+ "Koppla till ett befintligt PVE vzdump-jobb — 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 samma säkerhetskopieringscykel. Vid återställning kommer gästkonfigurationerna från värdsäkerhetskopian (under /etc/pve) 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 OnCalendar uttryck (systemd kalendersyntax - t.ex. daily, Mon..Fri 03:00).",
+ "retention": "Efterfrågas separat: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. 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 prune-backups-konfiguration (mappade en-till-en till körningsskriptets KEEP_*-variabler via hb_pve_prune_to_keep_env)."
+ }
+ ]
+ },
+ "attachDetail": {
+ "heading": "Så fungerar kopplingsläget",
+ "intro": "PVE skriver vzdump-jobb till /etc/pve/jobs.cfg, 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 hb_pve_list_vzdump_jobs_for_backend. Användaren väljer en."
+ },
+ {
+ "step": "2",
+ "detail": "Jobbets .env är skrivet med PVE_PARENT_JOB, PVE_STORAGE och de ärvda KEEP_* värdena; ingen systemd timer skapas."
+ },
+ {
+ "step": "3",
+ "detail": "hb_install_vzdump_hook registrerar en skripthook i /etc/vzdump.conf. I job-end-fasen för varje vzdump-jobb jämförs mottaget $STOREID med PVE_STORAGE 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: path/dump/ 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 KEEP_*-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 run_scheduled_backup.sh JOB_ID. Timern schemalägger det med Persistent=true (missade körningar utförs vid nästa start) och en liten RandomizedDelaySec=120 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 hb_install_vzdump_hook; matchar varje bifogat jobb PVE_STORAGE mot $STOREID 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": [
+ "Förbered säkerhetskopian. 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.",
+ "Skriv till destinationen. Laddar eller skriver arkivet till den konfigurerade destinationen - en lokal .tar.zst fil, en PBS backup, eller ett Borg-arkiv - med exakt samma verktyg och referenser en manuell säkerhetskopia till samma destination skulle använda.",
+ "Tillämpa bevaranderegler. Ta bort gamla säkerhetskopior från destinationen, hålla keep-last / keep-daily / keep-weekly räknas konfigurerade på jobbet. Pruning utförs av själva destinationen: PBS tillämpar sina egna bevaranderegler, Borg kör borg prune, och för Local ProxMenux raderar filerna som faller utanför keep-last-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: systemctl enable/disable --now timern. Bifoga läge: vänder ENABLED 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 /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — 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 hb_notify_lifecycle händelser som det interaktiva flödet (start, complete, fail). Om meddelandekanaler är konfigurerade i Monitor, obevakade jobb visar sina resultat på samma sätt manuella säkerhetskopior gör - en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades."
+ },
+ "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."
+ }
+ ]
+ }
+}