docs: review backup and restore documentation in all seven translations

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 <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but not in the backup. The user opts in during the confirmation dialog to have these removed as part of the restore, so the target ends up matching the backup exactly."
+        "detail": "Computed by <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but absent from the backup. The confirmation dialog offers optional removal of the extra guests before reboot. Component removal remains manual, and guest deletion can fail, so this does not guarantee an exact match with the backup."
       }
     ],
     "reportBody": "The check also emits a structured report (<code>HB_COMPAT_RESULTS</code>) categorised as PASS / INFO / WARN / FAIL. WARN and FAIL entries surface in the pre-restore panel; the restore refuses to proceed only when a FAIL is present that the user cannot resolve by clicking Continue."
@@ -81,11 +81,11 @@
       },
       {
         "class": "reboot",
-        "detail": "Paths applied <strong>immediately</strong> as well, but whose actual effect only kicks in on the <strong>next boot</strong>: the kernel only reads <code>/etc/default/grub</code> when the bootloader starts, <code>/etc/fstab</code> when filesystems are mounted at boot, <code>/etc/modules</code> when modules are loaded, etc. The file is in place the moment it is applied but the system has to reboot to consume it. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
+        "detail": "Paths deferred to the <strong>next boot</strong>, rather than applied <strong>immediately</strong> by this restore flow. They affect boot-time configuration: bootloader generation reads <code>/etc/default/grub</code>, filesystem mounting uses <code>/etc/fstab</code>, and module loading uses <code>/etc/modules</code>. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
       },
       {
         "class": "dangerous",
-        "detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount; writing directly to it bypasses it), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
+        "detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount holding active cluster configuration), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
       }
     ]
   },
@@ -131,7 +131,7 @@
       },
       {
         "task": "Component auto-reinstall",
-        "detail": "Reads the restored <code>components_status.json</code> and iterates over the registered installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each installer runs in <code>--auto-reinstall</code> mode, reads its previously-recorded version from the state file, and rebuilds against the target's current kernel. The interactive flow does not do this — reinstalling drivers against a kernel that has not yet booted is meaningless."
+        "detail": "Reads the restored <code>components_status.json</code> and iterates over the registered supported installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each selected installer runs in <code>--auto-reinstall</code> mode, reads its recorded state and reinstalls for the target’s environment, rebuilding kernel modules when applicable. This is deferred until after reboot so the installers use the kernel then running on the target. Individual failures are recorded and do not stop the next component."
       },
       {
         "task": "Boot sanity check",
@@ -145,7 +145,7 @@
   },
   "liveProgress": {
     "heading": "Live progress in the Monitor's Backups tab",
-    "body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>apply_cluster_postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
+    "body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>proxmenux-apply-cluster-postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
     "fields": [
       {
         "name": "Status badge",
@@ -184,9 +184,9 @@
   },
   "postbootExample": {
     "heading": "What the post-boot looks like on the console",
-    "body": "On the host's physical console, a successful dispatcher run ends with a <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code> line. When that line appears — usually alongside the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code> — the restore is completely finished: components reinstalled, boot artifacts regenerated, cluster reconciled.",
+    "body": "On the host’s physical console, a dispatcher run that exits successfully ends with <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>, often near the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code>. This marks the end of the dispatcher process. Individual component failures or boot warnings can still have been recorded; check the Monitor’s component states and logs before treating the host as fully restored.",
     "imageAlt": "Proxmox physical console showing '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).' followed by the OK for multi-user.target and graphical.target, with the host login prompt above.",
-    "imageCaption": "Physical console after a successful post-boot. The 'Finished proxmenux-apply-cluster-postboot.service' line is the signal that the restore flow is fully complete — the same event the 'Host restore finished' notification surfaces in the Monitor."
+    "imageCaption": "Physical console after the dispatcher process finishes. 'Finished proxmenux-apply-cluster-postboot.service' marks process completion, also reported by 'Host restore finished' in the Monitor. Component results and warnings still need review."
   },
   "tenMinutes": {
     "heading": "Why the last ten minutes matter",
@@ -228,11 +228,11 @@
         "detail": "Cheap. The user learns the run completed the moment the notification fires."
       }
     ],
-    "outroBody": "The window matters because the user can log in during this time and see missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected). This is expected — the reinstall is still running in the background. The completion notification signals when everything is ready."
+    "outroBody": "During this window a login may show missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected) because reinstall work is still running in the background. The completion notification marks the end of that work; check component results, warnings and logs to distinguish success from individual failures."
   },
   "destructiveRollback": {
     "heading": "The optional destructive rollback",
-    "body": "A restore is additive by default: if the target has VMs, LXCs or components that are not in the backup, they survive. This preserves work but can leave stale hostpci entries, orphan components or VMs the user no longer wants. When drift is detected between target and backup, the confirmation dialog offers a second yes/no: <em>Execute destructive rollback?</em>. Accepting it triggers <code>_rs_execute_rollback</code>, which deletes the VMs, LXCs and components that exist on the target but not in the backup. The rollback runs BEFORE the reboot so that the pending restore machinery sees a clean state. This is opt-in — the default is No, and the user sees exactly what would be removed listed by name (VMID and CTID) before deciding."
+    "body": "A restore is additive by default: extra VMs, LXCs and components on the target remain. When differences are detected, the confirmation dialog offers <em>Execute destructive rollback?</em>, defaulting to No. Accepting calls <code>_rs_execute_rollback</code> before reboot to attempt deletion of listed extra VMs and LXCs. Components are flagged for manual uninstall because automatic uninstall is not implemented. Guest deletion failures are reported and processing continues, so an exact match with the backup is not guaranteed. Review the listed names and VMIDs/CTIDs before choosing this destructive option."
   },
   "logs": {
     "heading": "Where the logs live",