mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +00:00
docs: review backup and restore documentation in all seven translations
This commit is contained in:
Jonatan
@@ -0,0 +1,220 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Creazione di backup — flusso di backup interattivo | ProxMenux",
|
||||
"description": "Il flusso di backup interattivo di ProxMenux: due punti di accesso (il menu TUI di Scripts e l’interfaccia web di Monitor), tre destinazioni, due modalità di profilo, una fase di preparazione temporanea e una finestra di conferma. La pagina descrive la matrice con sei opzioni, i profili predefinito e personalizzato e ciò che vede l’utente dalla scelta del backup fino al salvataggio dell’archivio a destinazione.",
|
||||
"ogTitle": "ProxMenux Backup — creazione di backup",
|
||||
"ogDescription": "Il flusso di backup interattivo con tre destinazioni, due profili e una fase di staging comune.",
|
||||
"twitterTitle": "Creazione di backup | ProxMenux",
|
||||
"twitterDescription": "Flusso di backup interattivo con tre destinazioni e due modalità di profilo."
|
||||
},
|
||||
"header": {
|
||||
"title": "Creazione di backup",
|
||||
"description": "Il flusso di backup interattivo: scegli una destinazione e un profilo, controlla il riepilogo di conferma e segui il salvataggio dell’archivio. I due punti di accesso condividono lo stesso backend e producono archivi identici.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Due punti di ingresso, funzionalità identiche",
|
||||
"body": "La TUI di Scripts e l’interfaccia web di Monitor offrono <strong>esattamente le stesse funzionalità</strong>. Ogni backup — manuale o pianificato — usa la stessa matrice di scelta (tre destinazioni × due profili) e richiama la stessa funzione backend per ogni cella (<code>_bk_pbs</code>, <code>_bk_borg</code> o <code>_bk_local</code>). Gli archivi prodotti dai due punti di accesso sono indistinguibili. La scelta dipende dalle preferenze: la TUI è adatta a SSH e agli script; Monitor offre il controllo con il mouse insieme alle viste delle notifiche e del monitoraggio dei log."
|
||||
},
|
||||
"entryPoints": {
|
||||
"heading": "I due punti di ingresso",
|
||||
"rows": [
|
||||
{
|
||||
"entry": "ProxMenux Scripts (TUI)",
|
||||
"path": "menu → Utilities → Host Config Backup",
|
||||
"detail": "Flusso basato sul dialogo, SSH-friendly. Il menu principale presenta le sei opzioni direttamente. Utilizza <code>backup_menu</code> in <code>backup_host.sh</code>."
|
||||
},
|
||||
{
|
||||
"entry": "ProxMenux Monitor (interfaccia web)",
|
||||
"path": "Backups tab → Create backup",
|
||||
"detail": "Flusso guidato da una procedura assistita. Le stesse sei opzioni sono presentate in un modulo in due passaggi (destinazione → profilo). Le stesse funzioni backend vengono richiamate tramite l’API Flask."
|
||||
}
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Backup manuali e pianificati",
|
||||
"body": "I backup possono essere prodotti in due modi: <strong>manuale</strong> (il flusso interattivo descritto in questa pagina - l'utente sceglie una destinazione e un profilo da un menu e segue il salvataggio dell’archivio) o <strong>pianificato</strong> (un lavoro non assistito che funziona su un timer in stile cron e applica la ritenzione configurata sul lavoro). Entrambe le modalità supportano le stesse tre destinazioni e gli stessi due profili, ed entrambe sono disponibili da entrambi i punti di ingresso — il menu Script TUI e la scheda Monitor Backups. I lavori programmati utilizzano le stesse funzioni backend del flusso manuale attraverso <code>run_scheduled_backup.sh</code>; gli archivi prodotti sono indistinguibili.",
|
||||
"seeAlso": "La pagina dei lavori programmati copre il flusso completo, incluso come creare un lavoro, collegarlo a un timer PVE vzdump esistente e configurare i valori di ritenzione.",
|
||||
"monitorAlt": "Scheda di backup ProxMenux Monitor che mostra la Nuova finestra di dialogo di backup programmata con i campi di destinazione, profilo, pianificazione e ritenzione.",
|
||||
"monitorCaption": "Backup pianificato — ProxMenux Monitor. La stessa finestra guidata che crea un backup manuale contiene in basso i campi di pianificazione e conservazione per l’esecuzione senza intervento."
|
||||
},
|
||||
"matrix": {
|
||||
"heading": "La matrice con sei opzioni",
|
||||
"intro": "La scelta determina sia il backend eseguito sia la strategia di selezione dei percorsi. Consulta le pagine delle singole destinazioni per i dettagli di configurazione di ogni cella.",
|
||||
"rows": [
|
||||
{
|
||||
"combo": "1",
|
||||
"destination": "PBS",
|
||||
"profile": "Predefinito",
|
||||
"action": "Carica il profilo predefinito e gli extra persistenti su un repository PBS configurato."
|
||||
},
|
||||
{
|
||||
"combo": "2",
|
||||
"destination": "Borg",
|
||||
"profile": "Predefinito",
|
||||
"action": "Crea un archivio con il profilo predefinito più extra persistenti nel repository Borg selezionato."
|
||||
},
|
||||
{
|
||||
"combo": "3",
|
||||
"destination": "Locale",
|
||||
"profile": "Predefinito",
|
||||
"action": "Scrive un archivio <code>.tar.zst</code> con il profilo predefinito più extra persistenti al target locale configurato."
|
||||
},
|
||||
{
|
||||
"combo": "4",
|
||||
"destination": "PBS",
|
||||
"profile": "Personalizzato",
|
||||
"action": "Apre il selettore dei percorsi prima del caricamento su PBS; l’utente seleziona i percorsi e può aggiungerne di nuovi."
|
||||
},
|
||||
{
|
||||
"combo": "5",
|
||||
"destination": "Borg",
|
||||
"profile": "Personalizzato",
|
||||
"action": "Apre il selettore dei percorsi prima di creare l’archivio Borg."
|
||||
},
|
||||
{
|
||||
"combo": "6",
|
||||
"destination": "Locale",
|
||||
"profile": "Personalizzato",
|
||||
"action": "Apre il selettore dei percorsi prima di scrivere il file <code>.tar.zst</code> locale."
|
||||
}
|
||||
]
|
||||
},
|
||||
"profiles": {
|
||||
"heading": "Profilo predefinito e personalizzato",
|
||||
"defaultTitle": "Profilo predefinito",
|
||||
"defaultBody": "Il profilo predefinito è l'elenco curato da <code>hb_default_profile_paths</code> (documentato in <em>Come funziona</em> sotto <em>Categorie di percorsi</em>) più ogni voce nel file extra persistente <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. L'utente conferma le opzioni di destinazione e crittografia e il backup procede senza ulteriori selezioni dei percorsi.",
|
||||
"customTitle": "Profilo personalizzato",
|
||||
"customBody": "Il profilo personalizzato apre un elenco con tutti i percorsi del profilo predefinito (non selezionati) e tutti gli extra persistenti (già selezionati, con il prefisso <code>[+]</code>). L’utente seleziona i percorsi per questa esecuzione e può premere <em>Aggiungi percorso personalizzato</em> per aggiungere un nuovo percorso assoluto. I percorsi aggiunti vengono salvati in <code>backup-extra-paths.txt</code>, così i backup futuri li includono automaticamente senza doverli aggiungere di nuovo. Deselezionare un extra persistente lo esclude da questa esecuzione ma non lo elimina dal file — l’eliminazione avviene con l’azione separata <em>Gestisci percorsi personalizzati</em>, al di fuori del flusso di backup.",
|
||||
"customPickerAlt": "Elenco di controllo del profilo personalizzato che mostra i percorsi di predefinito (non selezionati) e gli extra persistenti (già selezionati con un prefisso [+]), più pulsanti per aggiungere un nuovo percorso o confermare la selezione.",
|
||||
"customPickerCaption": "Profilo personalizzato — il selettore dei percorsi. I percorsi del profilo predefinito non sono selezionati; gli extra persistenti sono già selezionati con il prefisso [+]. L’utente seleziona i percorsi per questa esecuzione.",
|
||||
"manageCustomAlt": "Menu di gestione dei percorsi personalizzati con l’elenco degli extra persistenti e le opzioni per aggiungerli, rimuoverli o modificarli.",
|
||||
"manageCustomCaption": "Gestisci percorsi personalizzati — il punto di ingresso dove vengono aggiunti o rimossi gli extra persistenti. Ogni percorso elencato qui è incluso automaticamente nei backup in modalità predefinita senza dover aprire il selettore personalizzato."
|
||||
},
|
||||
"commonPipeline": {
|
||||
"heading": "Cosa funziona indipendentemente dalla destinazione",
|
||||
"intro": "Una volta definito il profilo, ogni backend esegue la stessa procedura di preparazione temporanea prima di passare al proprio metodo di caricamento. <code>hb_prepare_staging</code> assembla l’albero dell’archivio in <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> e compila ciascuno dei tre blocchi di dati.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"name": "Assemblaggio del rootfs",
|
||||
"detail": "Esegue <code>rsync -a</code> per ogni percorso selezionato verso <code>staging_root/rootfs/</code>. Il database pmxcfs in <code>/var/lib/pve-cluster/config.db</code> viene acquisito separatamente tramite <code>sqlite3 .backup</code> per ottenere un’istantanea coerente senza arrestare il cluster; i file ausiliari <code>.db-wal</code> / <code>.db-shm</code> sono esclusi da rsync. Se <code>sqlite3</code> non è disponibile, viene invece salvato un file <code>config.db.raw-fallback</code>, che il ripristino adotta come database durante l’importazione. Da <code>/root/</code> sono esclusi i sottopercorsi volatili (cronologia bash, cache, cestino). I percorsi assenti nell’origine vengono registrati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"name": "Generazione manifesto",
|
||||
"detail": "<code>build_manifest.sh</code> coordina i sei moduli di raccolta e scrive <code>manifest.json</code> nella radice della directory temporanea. Se un modulo non riesce, la sezione interessata assume un valore predefinito vuoto documentato; il manifest resta valido."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"name": "Inventario dei pacchetti",
|
||||
"detail": "<code>apt-mark showmanual</code> viene catturato verbatim in <code>metadata/packages.manual.list</code>. Lo stato dei componenti è già all'interno del rootfs ripristinato (<code>components_status.json</code>) perché <code>/usr/local/share/proxmenux/</code> fa parte del profilo predefinito."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"name": "Informazioni sull’esecuzione",
|
||||
"detail": "<code>metadata/run_info.env</code> registra l'identità di esecuzione di backup — hostname, timestamp, versione del kernel — utilizzata dal controllo di compatibilità del ripristino per determinare la direzione del cross-kernel."
|
||||
},
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Notifica (start)",
|
||||
"detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
|
||||
}
|
||||
]
|
||||
},
|
||||
"included": {
|
||||
"heading": "Cosa entra e cosa rimane fuori",
|
||||
"intro": "Ogni percorso nel profilo risolto (predefinito + extra persistenti + selezione personalizzata) viene copiato con <code>rsync -aAXH --numeric-ids</code>. Un elenco di esclusione condiviso si applica a ogni percorso, e due directory portano ulteriori esclusioni specifiche del percorso.",
|
||||
"globalTitle": "Esclusioni globali (applicate ad ogni percorso)",
|
||||
"globalItems": [
|
||||
"<code>images/</code> — dump immagine.",
|
||||
"<code>dump/</code> — output di vzdump.",
|
||||
"<code>tmp/</code> — file temporanei.",
|
||||
"<code>*.log</code> — file di registro."
|
||||
],
|
||||
"rootTitle": "<code>/root/</code> esclusioni",
|
||||
"rootBody": "<code>/root/</code> fa parte del profilo predefinito per includere nell’archivio gli script e la configurazione dell’utente. Sono esclusi i sottopercorsi volatili:",
|
||||
"rootItems": [
|
||||
"<code>.bash_history</code>",
|
||||
"<code>.cache/</code>",
|
||||
"<code>tmp/</code>",
|
||||
"<code>.local/share/Trash/</code>"
|
||||
],
|
||||
"proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code> esclusioni",
|
||||
"proxmenuxBody": "Questa directory spedisce solo stato utente — <code>components_status.json</code>, preferenze, cache post-installazione. Codice che la destinazione avrà già dalla propria installazione ProxMenux è escluso quindi un ripristino non sovrascrive i binari attuali dell'obiettivo con quelli più vecchi:",
|
||||
"proxmenuxItems": [
|
||||
"<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
|
||||
"<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
|
||||
"<code>images/</code>, <code>json/</code>",
|
||||
"<code>utils.sh</code>, <code>helpers_cache.json</code>",
|
||||
"<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
|
||||
],
|
||||
"notInProfileTitle": "Percorsi fuori dal profilo",
|
||||
"notInProfileBody": "Qualsiasi cosa non elencata in <code>hb_default_profile_paths</code> e non aggiunta come un extra personalizzato o persistente non fa parte del backup. Esempi notevoli:",
|
||||
"notInProfileItems": [
|
||||
"<strong>VM e dischi LXC</strong> — gestiti da <code>vzdump</code>, non da questa funzione. I file di configurazione degli ospiti sotto <code>/etc/pve/nodes/*/qemu-server/*.conf</code> e <code>lxc/*.conf</code> vengono catturati (vivono sotto <code>/etc/pve</code>) in modo che il ripristino riproduca l'inventario; i dischi stessi vengono riattaccati da un backup vzdump/PBS esistente.",
|
||||
"<strong><code>/boot</code> e <code>/boot/efi</code></strong> — binari del kernel, initramfs e la partizione UEFI ESP sono rigenerati dal proprio <code>update-initramfs</code>, <code>update-grub</code> o <code>proxmox-boot-tool refresh</code> dopo il ripristino. Il bootloader non è mai copiato verbatim.",
|
||||
"<strong>Filesystem del kernel e dello stato di esecuzione del sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> e <code>/run</code> sono pseudo-filesystem generati dal kernel e da udev; non vengono salvati in modo persistente.",
|
||||
"<strong>Binari dei pacchetti in <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — reinstallati da APT sul sistema di destinazione a partire da <code>packages.manual.list</code>.",
|
||||
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — stato runtime per host, non restaurato.",
|
||||
"<strong><code>/home/USER</code></strong> — non nel profilo predefinito. Aggiungilo come un percorso personalizzato quando un sistema porta directory home degli utenti che devono sopravvivere a un ripristino."
|
||||
],
|
||||
"customPathsTitle": "Come vengono gestiti i percorsi personalizzati",
|
||||
"customPathsBody": "Un percorso personalizzato aggiunto in linea in modalità personalizzata o persistito in <code>backup-extra-paths.txt</code> passa attraverso la stessa pipeline <code>rsync</code> come percorsi di default-profile. Si applicano esclusioni globali. Se il percorso personalizzato avviene sotto <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, si applicano ancora le esclusioni specifiche del percorso. Ogni percorso archiviato — predefinito o personalizzato — viene registrato in <code>metadata/paths_archived.txt</code>. I percorsi che non esistono sulla sorgente sono registrati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
|
||||
},
|
||||
"archiveStructure": {
|
||||
"heading": "Struttura dell'archivio",
|
||||
"intro": "La directory di staging prodotta da ogni backend segue lo stesso layout indipendentemente dalla destinazione. Il tarball, PBS <code>.pxar</code> o Borg archivio memorizza questo albero verbatim.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│ ├── packages.manual.list # output of apt-mark showmanual\n│ ├── run_info.env # hostname, timestamp, kernel version, pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n ├── root/ # /root without volatile subpaths\n ├── usr/local/ # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
|
||||
},
|
||||
"confirmation": {
|
||||
"heading": "Riepilogo conferma",
|
||||
"body": "Prima che il backend scriva qualcosa alla destinazione, ProxMenux mostra una finestra di dialogo sommaria con la destinazione, l'ID di backup o il nome dell'archivio, lo stato di crittografia e l'elenco dei percorsi da copiare. Cancellando qui interrompe il backup in modo pulito — la directory di staging viene rimossa dal gancio <code>trap</code> impostato sulla funzione backend e nessun dato parziale raggiunge la destinazione."
|
||||
},
|
||||
"writing": {
|
||||
"heading": "Scrivere alla destinazione",
|
||||
"intro": "Dopo la conferma, ogni backend esegue la propria fase di scrittura. Le pagine delle destinazioni ne descrivono il funzionamento; gli elementi comuni sono il log, il file ausiliario e la notifica di completamento.",
|
||||
"rows": [
|
||||
{
|
||||
"topic": "File di registro",
|
||||
"detail": "Ogni backend scrive il suo output completo a <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> e, in caso di guasto, offre di aprirlo in una finestra di dialogo scorrevole. Il percorso di log è stampato nel sommario di completamento solo quando il file ha contenuto."
|
||||
},
|
||||
{
|
||||
"topic": "Sidecar (solo locale)",
|
||||
"detail": "<code>hb_write_archive_sidecar</code> scrive un <code>*.proxmenux.json</code> accanto all'archivio locale, quindi il Monitor lo identifica come backup host ProxMenux anche dopo mosse o rinominazioni."
|
||||
},
|
||||
{
|
||||
"topic": "Notifica (completamento/errore)",
|
||||
"detail": "Viene eseguito <code>hb_notify_lifecycle \"complete\"</code> o <code>\"fail\"</code> con durata, dimensione dell’archivio e — in caso di errore — l’ultima riga del log che sembra indicare un errore."
|
||||
}
|
||||
]
|
||||
},
|
||||
"finishedScreens": {
|
||||
"heading": "Che aspetto ha un backup finito",
|
||||
"intro": "Lo stesso evento di completamento viene mostrato da entrambi i punti di accesso. La TUI scrive un riepilogo nel terminale; la scheda Backups di Monitor mostra l’esecuzione nell’elenco degli archivi con dimensione, durata e indicatori di stato.",
|
||||
"scriptsAlt": "ProxMenux Scripts TUI che mostra un backup host finito — destinazione, ID di backup, percorso snapshot, dimensione dei dati, durata e stato di crittografia.",
|
||||
"scriptsCaption": "Backup finito — ProxMenux Scripts (TUI). Il blocco di completamento stampa la destinazione, l'ID di backup, il nome dell'istantanea o dell'archivio risultante, la dimensione dei dati, la durata e lo stato di crittografia.",
|
||||
"monitorAlt": "Scheda di backup ProxMenux Monitor che mostra una voce di backup host finita con dimensioni, durata, indicatore del metodo e indicatore di crittografia.",
|
||||
"monitorCaption": "Backup finito — scheda di backup ProxMenux Monitor. Il nuovo backup appare nell'elenco di archivio con il badge metodo di destinazione, dimensione, durata e - quando applicabile - l'indicatore di blocco di crittografia."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Dove andare dopo",
|
||||
"items": [
|
||||
{
|
||||
"label": "Destinazioni",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— dettagli di configurazione per Local, PBS e Borg."
|
||||
},
|
||||
{
|
||||
"label": "Lavori programmati",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "— eseguire lo stesso backup incustodito su un programma invece di interattivamente."
|
||||
},
|
||||
{
|
||||
"label": "Ripristino",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— il flusso che consuma ciò che questa pagina produce."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Ripristino tra versioni del kernel — direzione, filtro sicuro e idratazione | ProxMenux",
|
||||
"description": "Come ProxMenux ripristina un backup host con una versione principale diversa del kernel. Rileva la direzione della differenza, esclude percorsi critici per l’avvio se il kernel di destinazione è più recente e riapplica in quattro fasi IOMMU, ID VFIO e parametri personalizzati senza ricopiare i file legati al kernel.",
|
||||
"ogTitle": "ProxMenux Backup — ripristino tra versioni del kernel e idratazione",
|
||||
"ogDescription": "Ripristino tra versioni del kernel che considera la direzione del cambiamento, con filtro sicuro e idratazione indipendente dal kernel.",
|
||||
"twitterTitle": "Ripristino tra versioni del kernel | ProxMenux",
|
||||
"twitterDescription": "Come ProxMenux gestisce un ripristino quando il kernel di destinazione differisce dal backup."
|
||||
},
|
||||
"header": {
|
||||
"title": "Ripristino tra versioni del kernel",
|
||||
"description": "Come ProxMenux gestisce un ripristino quando l'host di destinazione esegue un kernel diverso da quello registrato nel backup — soprattutto quando il target esegue un kernel più recente. Spiega come viene rilevata la differenza, come i percorsi boot-critical che potrebbero rompere il bersaglio sono filtrati e come la configurazione dell'utente viene riapplicata senza copiare i file legati al kernel verbatim.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ogni salto del kernel viene gestito in modo diverso",
|
||||
"body": "Il kernel di un host Proxmox è identificato da una stringa di versione come <code>6.17.13-2-pve</code>. I primi due numeri (<strong>6.17</strong> in questo esempio) definiscono la versione principale: quando cambiano, alcuni file di configurazione scritti per il kernel precedente potrebbero non essere validi sul nuovo. Quando il ripristino rileva che il backup e l'obiettivo hanno diverse versioni principali del kernel, i rami di flusso in base alla direzione del salto — se il backup è più vecchio o più recente del bersaglio — perché i due casi hanno modalità di guasto opposte. I backup più recenti rispetto al target ripristinano in modo pulito come-è (bench-verified attraverso salti multipli del kernel). I backup più vecchi del target hanno bisogno di un filtro per evitare di rompere il boot del target con la configurazione scritta per un kernel che è cambiato da allora."
|
||||
},
|
||||
"directionCheck": {
|
||||
"heading": "Il controllo della direzione",
|
||||
"intro": "Durante la verifica della compatibilità, <code>hb_compat_check</code> confronta il kernel registrato nel manifesto del backup contro il kernel corrente dell'obiettivo (<code>uname -r</code>) e classifica il ripristino in uno dei tre casi, memorizzato nella variabile interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
|
||||
"rows": [
|
||||
{
|
||||
"direction": "same",
|
||||
"condition": "La versione principale del kernel corrisponde tra backup e target.",
|
||||
"behavior": "Il flusso di ripristino completo scorre invariato. Nessun filtro extra, nessuna idratazione, nessun avviso speciale nell'interfaccia utente."
|
||||
},
|
||||
{
|
||||
"direction": "bk_newer",
|
||||
"condition": "Il kernel del backup è PIÙ RECENTE di quello di destinazione (ad esempio: backup su 7.0, destinazione su 6.17).",
|
||||
"behavior": "Il flusso di ripristino completo scorre invariato, esattamente come <code>same</code>. Nessun filtro viene applicato. Verificato empiricamente: i driver auto-reinstallano contro il kernel del target, IOMMU config si applica in modo pulito, le VM con passthrough GPU arrivano senza problemi."
|
||||
},
|
||||
{
|
||||
"direction": "bk_older",
|
||||
"condition": "Il kernel del backup è PIÙ VECCHIO di quello di destinazione (ad esempio: backup su 6.17, destinazione su 7.0).",
|
||||
"behavior": "Il filtro sicuro-sottoset e l'idratazione di quattro fasi qui sotto sono attivati. Il ripristino prosegue — il bersaglio riproduce la fonte, ma i file boot-critical non sono copiati verbatim."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyBkNewerIsSafe": {
|
||||
"heading": "Perché un backup con un kernel più recente rispetto al target ripristina invariato",
|
||||
"body": "Quando il ripristino viene eseguito contro un obiettivo con un kernel <em>più vecchio</em> rispetto a quello registrato nel backup, ogni meccanismo che il ripristino dipende è indipendente dalla versione del kernel. Gli installatori di driver GPU e altri installatori PCI-device rilevano il kernel in esecuzione con <code>uname -r</code> e compilano DKMS contro qualunque sia l'obiettivo. Il pacchetto APT install tira binari costruiti per la distribuzione del bersaglio. I gettoni cmdline IOMMU come <code>intel_iommu=on</code> sono stabili nelle principali versioni del kernel. Il backup trasporta i percorsi scritti sotto un kernel più recente, ma quei percorsi (module blacklists, GRUB defaults, initramfs config) sono ancora validi sintassi sul vecchio — i kernel ignorano i token che non riconoscono invece di fallire. Questo caso è equivalente in pratica a un ripristino dello stesso kernel, e ProxMenux lo tratta come tale."
|
||||
},
|
||||
"safeSubsetFilter": {
|
||||
"heading": "Il filtro safe-subset (solo quando il kernel di destinazione è più recente)",
|
||||
"intro": "Quando il kernel di destinazione è più recente di quello del backup, il controllo di compatibilità aggiunge percorsi critici di avvio 16 da <code>hb_unsafe_paths_cross_version</code> a <code>RS_SKIP_PATHS</code>. Questi percorsi sono esclusi dal ripristino perché la scrittura di una versione di loro da un kernel più vecchio su un obiettivo che esegue un nuovo ha causato il panico del kernel nei test di panca. I percorsi coprono cinque categorie:",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Caricatore di avvio",
|
||||
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
|
||||
"reason": "GRUB default legati all'ordine del kernel precedente e allo stato proxmox-boot-tool (cmdline, UUID ESP, ganci) che richiama i percorsi e gli identificatori dall'installazione precedente."
|
||||
},
|
||||
{
|
||||
"category": "Moduli del kernel e artefatti del boot",
|
||||
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
|
||||
"reason": "Le liste di carico automatico che possono riferire i moduli rinominati tra le major del kernel, le opzioni del modulo che potrebbero non essere applicate, initramfs hooks scritto per il kernel più vecchio."
|
||||
},
|
||||
{
|
||||
"category": "Identità dello stack di stoccaggio e del filesystem",
|
||||
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
|
||||
"reason": "UUID che potrebbero non esistere su questa installazione, driver multipath che cambiano tra i kernel, iSCSI parametri che si evolvono, regole udev che possono legare a sottosistemi non esistenti, ZFS Stato (<code>zpool.cache</code> + <code>hostid</code>) che può bloccare pool come straniero."
|
||||
},
|
||||
{
|
||||
"category": "Fonti APT",
|
||||
"paths": "<code>/etc/apt</code>",
|
||||
"reason": "Le suite sorgente APT possono attivare un downgrade di pacchetti critici sul prossimo aggiornamento."
|
||||
},
|
||||
{
|
||||
"category": "systemd",
|
||||
"paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
|
||||
"reason": "Override delle unità e collegamenti .wants legati alla precedente versione principale di systemd; chiavi di configurazione che potrebbero non essere valide in una versione più recente."
|
||||
}
|
||||
],
|
||||
"outroBody": "Il filtro viene eseguito PRIMA della finestra di dialogo di conferma in modo che l'utente veda l'elenco esatto dei percorsi che verranno saltati, categorizzati per ragione. Il ripristino continua — tutto il resto (configurazione VM/LXC, rete, /etc/pve, utenti, cron, stato ProxMenux, pacchetti, driver, /root) viene ripristinato normalmente."
|
||||
},
|
||||
"hydration": {
|
||||
"heading": "Idratazione Kernel-agnostic",
|
||||
"intro": "Il filtro omette file critici; l’idratazione riapplica impostazioni selezionate: cmdline IOMMU, ID VFIO, <code>GRUB_TIMEOUT</code> personalizzato e blacklist nvidia. Si esegue se il kernel di destinazione è più recente. La fusione cmdline conserva le chiavi di destinazione e i moduli mancanti vengono aggiunti. Valori GRUB e file consentiti possono sostituire contenuti diversi sul target. Ripetere gli stessi input è idempotente.",
|
||||
"phaseRows": [
|
||||
{
|
||||
"phase": "1a — Via GRUB",
|
||||
"detail": "Per host GRUB (installazioni ext4/lvm). <code>_rs_hyd_grub</code> unisce i parametri di <code>manifest.kernel_params.cmdline_extra</code> del backup in <code>GRUB_CMDLINE_LINUX_DEFAULT</code> del target, saltando le chiavi già presenti. Ripristina poi le chiavi consentite <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) da <code>/etc/default/grub</code> del backup se i valori differiscono dal target."
|
||||
},
|
||||
{
|
||||
"phase": "1b — systemd-boot / ZFS",
|
||||
"detail": "Per systemd-boot (tipicamente ZFS alla radice). <code>_rs_hyd_kernel_cmdline</code> unisce i parametri utente di <code>cmdline_extra</code> in <code>/etc/kernel/cmdline</code> del target, mantenendo intatti i parametri di avvio <code>root=</code>, <code>boot=</code> e <code>rootflags=</code> del target."
|
||||
},
|
||||
{
|
||||
"phase": "2 — fusione /etc/modules",
|
||||
"detail": "<code>_rs_hyd_modules</code> aggiunge moduli da <code>manifest.kernel_params.modules_loaded_at_boot</code> che sono nella lista bianca (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) E non già presente nell'obiettivo <code>/etc/modules</code>."
|
||||
},
|
||||
{
|
||||
"phase": "3 — Copia di file whitelist",
|
||||
"detail": "<code>_rs_hyd_files</code> copia i file scritti dall’utente dai rootf di staging al target live quando il contenuto differisce. La whitelist copre i file VFIO/nvidia/blacklist sotto le regole <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, e la regola di legatura ProxMenux VFIO + le regole nvidia udev sotto le regole <code>/etc/udev/rules.d</code>. I file distribuiti (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sono intenzionalmente esclusi: i loro contenuti si evolvono tra le versioni."
|
||||
},
|
||||
{
|
||||
"phase": "4 — Forza rigenerazione dopo l’avvio",
|
||||
"detail": "Le quattro fasi scrivono direttamente sul target attivo AL DI FUORI DEL il normale processo di ripristino. Per rendere i gettoni/moduli/file fusi effetto sul prossimo avvio, <code>HB_HYDRATION_APPLIED=1</code> si propaga attraverso <code>plan.env</code> a <code>apply_pending_restore.sh</code>, che forza <code>NEEDS_INITRAMFS=1</code> e <code>NEEDS_GRUB=1</code> indipendentemente da quello che era nell'elenco di applicazione. Il dispatcher post-avvio poi rigenera initramfs e rinfresca il bootloader."
|
||||
}
|
||||
]
|
||||
},
|
||||
"planCommit": {
|
||||
"heading": "Plan vs commit — l'utente vede prima un'anteprima",
|
||||
"body": "L'idratazione scorre in due modi. Prima della finestra di dialogo di conferma, ProxMenux funziona <code>_rs_apply_bk_older_hydration</code> in modalità <code>plan</code>: calcola esattamente ciò che sarebbe stato unito, popola <code>RS_HYDRATION_SUMMARY</code> con un blocco verde che elenca ogni azione, e restituisce senza scrivere. La finestra di dialogo di conferma mostra che il blocco verde accanto all'elenco arancione dei percorsi esclusi, così l'utente vede IN ANTICIPO ciò che verrà riapplicato automaticamente. Dopo la conferma dell'utente, ProxMenux replica lo stesso helper in modalità <code>commit</code> — stesse fasi, stessa logica, ma questa volta ogni fase scrive al target live. Cancellare la finestra di dialogo di conferma lascia il bersaglio intatto."
|
||||
},
|
||||
"flowDiagram": {
|
||||
"heading": "Il flusso quando il kernel di destinazione è più recente di quello del backup",
|
||||
"intro": "I passaggi aggiunti quando il kernel di destinazione è più recente siedono all'interno del normale flusso di ripristino. Tutto il resto — caldo applicare, in attesa di preparare, pacchetto di installazione, post-boot speditore — funziona identicamente a un ripristino dello stesso-kernel.",
|
||||
"diagram": " ┌────────────────────────────────────────────────────────────┐\n │ hb_compat_check │\n │ HB_COMPAT_KERNEL_DIRECTION = bk_older │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Add 16 boot-critical paths to RS_SKIP_PATHS │\n │ /etc/default/grub, /etc/kernel, /etc/modules-load.d, ... │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"plan\" │\n │ Compute what would be merged │\n │ Populate RS_HYDRATION_SUMMARY (green block) │\n │ No writes │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Confirmation dialog │\n │ Amber: paths skipped by safe-subset filter │\n │ Green: tokens/files reapplied by hydration │\n │ User accepts or cancels │\n └───────────────────────────┬────────────────────────────────┘\n │ (accepted)\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"commit\" │\n │ Phase 1a/1b: merge cmdline tokens + GRUB keys │\n │ Phase 2: append modules to /etc/modules │\n │ Phase 3: copy whitelisted vfio/nvidia files │\n │ Set HB_HYDRATION_APPLIED=1 │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Rest of the restore runs normally │\n │ _rs_apply hot (skips RS_SKIP_PATHS) │\n │ _rs_prepare_pending_restore (writes plan.env with │\n │ HB_HYDRATION_APPLIED=1) │\n │ packages.manual.list install │\n │ Reboot │\n │ apply_pending_restore.sh (forces NEEDS_INITRAMFS=1, │\n │ NEEDS_GRUB=1 because of the hydration flag) │\n │ apply_cluster_postboot.sh │\n │ update-initramfs -u -k all │\n │ update-grub / proxmox-boot-tool refresh │\n │ component --auto-reinstall │\n └────────────────────────────────────────────────────────────┘"
|
||||
},
|
||||
"concreteExamples": {
|
||||
"heading": "Esempi concreti",
|
||||
"intro": "Il passaggio di idratazione non è astratto — produce risultati osservabili, corretti per scenari comuni. Due esempi che l'idratazione gestisce automaticamente:",
|
||||
"rows": [
|
||||
{
|
||||
"scenario": "GPU passante (VFIO)",
|
||||
"detail": "Fonte aveva <code>intel_iommu=on iommu=pt</code> nel cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> con <code>options vfio-pci ids=10de:2216</code>, e un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. L'idratazione fonde i token cmdline nel GRUB o nella cmdline del kernel, aggiunge i moduli vfio a <code>/etc/modules</code> e copia i due file modprobe scritti dall’utente. Sul prossimo avvio, IOMMU è attivo, modulo VFIO carico, il GPU è legato a vfio-pci e il VM viene fornito con il funzionamento passante."
|
||||
},
|
||||
{
|
||||
"scenario": "Predefinizioni personalizzate GRUB",
|
||||
"detail": "Fonte aveva <code>GRUB_TIMEOUT=1</code> e <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration legge entrambe le chiavi del backup <code>/etc/default/grub</code>, vede che differiscono dalle impostazioni di installazione fresche, e riscrive quelle due linee nel file del bersaglio (lasciando tutto il resto, incluso <code>GRUB_DISTRIBUTOR</code>, intatto)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"warningTitle": "Ciò che l'idratazione non riapplica quando il kernel di destinazione è più recente",
|
||||
"warningBody": "L'idratazione si applica solo alla configurazione ProxMenux sa essere sicura nelle versioni del kernel: IOMMU tokens, VFIO IDs, whitelist GRUB chiavi, e moduli da un elenco fisso (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Qualsiasi cosa al di fuori di quel set — initramfs personalizzato ganci sotto <code>/etc/initramfs-tools/hooks/</code>, file non whitelist sotto <code>/etc/modprobe.d/</code>, override unità systemd scritte dall’utente — rimane esclusa. Il motivo è concreto: questi file possono chiamare interfacce kernel-internal (module APIs, <code>/sys</code> layout, <code>udev</code> hooks) che cambiano tra le principali versioni, e applicandoli verbatim sopra il kernel più recente può impedire al bersaglio di avviare. Quando è richiesta la riproduzione esatta della catena di avvio, il ripristino deve essere eseguito su un host con la stessa versione del kernel principale del backup."
|
||||
},
|
||||
"codeReference": {
|
||||
"heading": "Dove vivono i meccanismi",
|
||||
"intro": "Per gli sviluppatori che cercano di tracciare o estendere il comportamento cross-kernel:",
|
||||
"rows": [
|
||||
{
|
||||
"component": "Rilevamento della direzione",
|
||||
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Imposta <code>HB_COMPAT_KERNEL_DIRECTION</code>."
|
||||
},
|
||||
{
|
||||
"component": "Elenco dei percorsi Safe-subset",
|
||||
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emette linee <code>path\\treason</code> utilizzate sia dal filtro CLI che dal endpoint Web <code>/api/host-backups/restore/prepare</code>."
|
||||
},
|
||||
{
|
||||
"component": "Fasi di idratazione",
|
||||
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> in <code>backup_host.sh</code>. Orchestrata da <code>_rs_apply_bk_older_hydration</code>."
|
||||
},
|
||||
{
|
||||
"component": "Rigenerazione forzata dopo l’avvio",
|
||||
"location": "<code>apply_pending_restore.sh</code> legge <code>HB_HYDRATION_APPLIED</code> da <code>plan.env</code> e forza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
|
||||
},
|
||||
{
|
||||
"component": "Anteprima web",
|
||||
"location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Carica la libreria helper, esegue <code>_rs_apply_bk_older_hydration</code> in modalità piano, restituisce le azioni al Web modal."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Dove andare dopo",
|
||||
"items": [
|
||||
{
|
||||
"label": "Ripristino",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — il processo completo di ripristino che integra i meccanismi di questa pagina."
|
||||
},
|
||||
{
|
||||
"label": "Come funziona",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — manifesto e raccoglitori che producono il blocco <code>kernel_params</code> letto dall’idratazione."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,234 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destinazione Borg — tipi di repository, autenticazione SSH, crittografia | ProxMenux",
|
||||
"description": "La destinazione Borg salva i backup host ProxMenux in un repository locale, su un disco esterno montato o su un server remoto via SSH. Descrive la ricerca dell’eseguibile borg, le quattro opzioni iniziali per le chiavi SSH, la crittografia repokey, le destinazioni salvate e la conservazione per attività pianificata.",
|
||||
"ogTitle": "ProxMenux Backup — Destinazione Borg",
|
||||
"ogDescription": "Come ProxMenux salva i backup host nei repository Borg con autenticazione SSH e crittografia repokey.",
|
||||
"twitterTitle": "Destinazione di backup Borg | ProxMenux",
|
||||
"twitterDescription": "Repository Borg locali, su USB e accessibili via SSH per i backup host."
|
||||
},
|
||||
"header": {
|
||||
"title": "Borg",
|
||||
"description": "La destinazione Borg scrive i backup host a un repository Borg. Sono supportati tre tipi di repository: percorso filesystem locale, disco esterno montato o server remoto tramite SSH. Deduplicazione a livello di Chunk in tutti gli archivi del repository e crittografia repokey opzionale.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"aboutBorg": {
|
||||
"heading": "Quello che Borg è",
|
||||
"body": "Borg (anche scritto BorgBackup) è uno strumento di backup deduplicante open source mantenuto dalla comunità di Borg Backup. Memorizza ogni archivio come un insieme di blocchi di lunghezza variabile all'interno di un repository; i pezzi sono condivisi in archivi in modo da ri-back up dati invariati ha un costo di archiviazione quasi zero. Borg non è legato a Proxmox — è uno strumento di backup generale utilizzato in molti ambienti. ProxMenux lo utilizza come una delle tre destinazioni per i backup host; ogni meccanismo specifico Borg descritto in questa pagina (tipo di repository, borg-serve su SSH, crittografia di repokey, prune) è il comportamento standard Borg."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Deduplicazione per blocchi con repository locali o accessibili via SSH",
|
||||
"body": "Un repository Borg conserva blocchi condivisi tra tutti i suoi archivi: ripetere il backup di un file invariato non trasferisce né memorizza nuovi dati. ProxMenux usa <code>borg create</code> per il backup e <code>borg extract</code> per il ripristino. Il repository può trovarsi sullo stesso filesystem dell’origine, su un disco esterno montato o su un host remoto accessibile via SSH."
|
||||
},
|
||||
"binarySourcing": {
|
||||
"heading": "Il binario di borg",
|
||||
"intro": "Borg non è una dipendenza di base dell'installatore ProxMenux. Quando un backup viene eseguito, <code>hb_ensure_borg</code> risolve il binario da quattro fonti in ordine e restituisce il primo che funziona:",
|
||||
"rows": [
|
||||
{
|
||||
"priority": "1",
|
||||
"source": "Sistema <code>borg</code>",
|
||||
"detail": "Se l'host ha già installato <code>borg</code> tramite APT (<code>which borg</code> risolve), questo binario viene utilizzato."
|
||||
},
|
||||
{
|
||||
"priority": "2",
|
||||
"source": "cache di stato",
|
||||
"detail": "<code>/usr/local/share/proxmenux/borg</code> — tenuto da un precedente download GitHub su questo host."
|
||||
},
|
||||
{
|
||||
"priority": "3",
|
||||
"source": "Pacchetto AppImage del Monitor",
|
||||
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — il AppImage fa un borg-linux64 firmato. Questo è il percorso offline: un host senza internet ha ancora un <code>borg</code> funzionante."
|
||||
},
|
||||
{
|
||||
"priority": "4",
|
||||
"source": "Scarica GitHub",
|
||||
"detail": "<code>wget</code> contro l'URL pinned <code>borg-linux64</code> sotto <code>github.com/borgbackup/borg/releases/</code>, verificatosi contro una costante SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Su checksum sbagliato il binario viene scartato e il backup si interrompe. Il file scaricato viene memorizzato nella cache dello stato, quindi i backup successivi utilizzano il percorso 2."
|
||||
}
|
||||
]
|
||||
},
|
||||
"repoTypes": {
|
||||
"heading": "Tipi di repository",
|
||||
"intro": "Il tipo di repository viene scelto quando viene aggiunto un obiettivo. Ogni tipo si risolve in un altro URL di repository che Borg capisce.",
|
||||
"rows": [
|
||||
{
|
||||
"type": "remote",
|
||||
"url": "ssh://USER@HOST/RPATH",
|
||||
"detail": "Repository vive su un server remoto che esegue <code>borg serve</code>. Richiede una connessione SSH a quel server."
|
||||
},
|
||||
{
|
||||
"type": "usb",
|
||||
"url": "/mnt/MOUNTPOINT/borgbackup",
|
||||
"detail": "Il repository vive su un disco esterno montato (tipicamente USB). Il montaggio viene risolto tramite <code>hb_prompt_mounted_path</code>, che rileva, monta o formatta le partizioni USB come necessario."
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "Repository vive su una directory locale. Significativo solo quando la directory di destinazione è su un disco fisico separato — un repository sullo stesso disco della fonte protegge dall'errore dell'operatore, ma non dall'errore del disco."
|
||||
}
|
||||
]
|
||||
},
|
||||
"serverSetup": {
|
||||
"heading": "Preparazione del server Borg (lato server)",
|
||||
"intro": "Il tipo di repository <code>remote</code> richiede un server Borg funzionante e accessibile via SSH. ProxMenux non configura il server: autorizza soltanto una chiave per un account esistente. Questa sezione descrive i requisiti del server prima della connessione.",
|
||||
"hostChoicesTitle": "Dove il server può vivere",
|
||||
"hostChoicesBody": "Qualsiasi host Linux con accesso SSH si qualifica. Configurazioni comuni:",
|
||||
"hostChoicesItems": [
|
||||
"Un NAS dedicato o una scatola di backup (Debian, Ubuntu, TrueNAS SCALE con una shell).",
|
||||
"Un contenitore LXC all'interno di un nodo Proxmox. Piccola impronta, isolata dall'host che esegue i backup.",
|
||||
"Un altro host Proxmox sulla stessa LAN, o un VM ovunque raggiungibile tramite SSH."
|
||||
],
|
||||
"lxcWarningTitle": "LXC come server Borg",
|
||||
"lxcWarningBody": "Se il server Borg è in un LXC, generate-auto richiede un account che accetti l’autenticazione SSH con password per installare la chiave. In alternativa, usa l’installazione manuale o generate-pct tramite l’host PVE.",
|
||||
"requirementsTitle": "Requisiti sul server",
|
||||
"requirementsRows": [
|
||||
{
|
||||
"requirement": "Eseguibile borg in <code>/usr/bin/borg</code>",
|
||||
"detail": "La riga <code>command=\"/usr/bin/borg serve ...\"</code> scritta da ProxMenux in <code>authorized_keys</code> usa questo percorso fisso. APT (<code>apt install borgbackup</code>) installa lì l’eseguibile. Per un binario autonomo occorre un collegamento simbolico in <code>/usr/bin/borg</code>."
|
||||
},
|
||||
{
|
||||
"requirement": "Un account utente dedicato (tipicamente <code>borg</code>)",
|
||||
"detail": "Possiede la directory del repository e riceve connessioni SSH in arrivo. Non ha bisogno di sudo o di accesso alla shell — la linea authorized_keys disabilita comunque le shell interattive."
|
||||
},
|
||||
{
|
||||
"requirement": "Una directory di repository writable",
|
||||
"detail": "Il percorso che l'operatore dà a ProxMenux (ad esempio <code>/backup/borgbackup</code>) deve esistere sul server ed essere di proprietà dell'utente borg."
|
||||
},
|
||||
{
|
||||
"requirement": "SSH daemon accetta l'utente borg",
|
||||
"detail": "<code>PubkeyAuthentication yes</code> (default). L'autenticazione della password è necessaria solo per il flusso <em>generate-auto</em> di un colpo — dopo l'installazione della chiave, il server può disabilitare completamente la password."
|
||||
}
|
||||
],
|
||||
"minimalSetupTitle": "Configurazione server Minimal",
|
||||
"minimalSetupBody": "Su un server Debian o Ubuntu Borg, una linea base di lavoro è quattro comandi come root:",
|
||||
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
|
||||
"minimalSetupNote": "Con il server pronto e l’autenticazione SSH con password disponibile, <code>generate-auto</code> installa la chiave tramite un account che possa scrivere in authorized_keys dell’utente borg. I backup successivi usano questa chiave, limitata a <code>borg serve</code> sul percorso configurato. Senza accesso con password, installala manualmente o tramite l’host PVE."
|
||||
},
|
||||
"sshAuth": {
|
||||
"heading": "Autenticazione SSH (lato cliente)",
|
||||
"intro": "I repository Borg remoti sono accessibili su SSH. La connessione viene eseguita dall'host ProxMenux a un account utente sul server Borg che esegue <code>borg serve</code>. Questo utente è tipicamente chiamato <code>borg</code>, NON l'utente admin/root del server — la linea di comando borg-serve blocca la connessione a quel percorso di repository specifico (vedere le strategie chiave qui sotto).",
|
||||
"strategiesTitle": "Strategie per le chiavi SSH",
|
||||
"strategiesIntro": "Aggiungendo una destinazione remota, ProxMenux chiede utente SSH, host e percorso remoto, poi offre quattro opzioni di autenticazione. Se l’accesso con password viene rifiutato, propone anche generate-pct. Le modalità sono descritte di seguito:",
|
||||
"strategyRows": [
|
||||
{
|
||||
"mode": "generate-auto",
|
||||
"label": "Consigliato",
|
||||
"detail": "ProxMenux genera o riutilizza una coppia di chiavi ed25519 in <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, poi usa <code>sshpass</code> per verificare l’accesso e installare la chiave pubblica in <code>~borg/.ssh/authorized_keys</code>. La password appartiene a un account che possa scrivere il file, solitamente root o borg. Serve durante la configurazione e non viene salvata."
|
||||
},
|
||||
{
|
||||
"mode": "generate-manual",
|
||||
"label": "Nessuna password di amministratore su questo host",
|
||||
"detail": "ProxMenux genera il keypair come sopra ma visualizza la linea completa <code>authorized_keys</code> per l'operatore di incollare manualmente nel server. La password di amministratore non lascia mai l'host ProxMenux perché non viene mai chiesto."
|
||||
},
|
||||
{
|
||||
"mode": "generate-pct",
|
||||
"label": "Il server Borg è un PVE LXC",
|
||||
"detail": "Il server Borg viene eseguito all'interno di un LXC su un nodo PVE. ProxMenux autorizza la chiave tramite <code>pct exec</code> dall'host PVE — root sull'host PVE scrive nel LXC <code>~borg/.ssh/authorized_keys</code> senza bisogno di SSH nel LXC stesso."
|
||||
},
|
||||
{
|
||||
"mode": "existing",
|
||||
"label": "Utilizzare una chiave esistente",
|
||||
"detail": "ProxMenux scansiona <code>/root/.ssh/</code> e <code>$HOME/.ssh/</code> per le chiavi private parseable ed25519/RSA e le elenca. L'operatore sceglie uno o naviga manualmente su un percorso non standard."
|
||||
},
|
||||
{
|
||||
"mode": "none",
|
||||
"label": "Configurazione predefinita SSH",
|
||||
"detail": "Nessuna chiave personalizzata — Borg si basa sulla configurazione predefinita SSH dell'host (tipicamente <code>~/.ssh/id_rsa</code> o un agente SSH)."
|
||||
}
|
||||
],
|
||||
"restrictTitle": "La linea authorized_keys",
|
||||
"restrictBody": "Per ogni chiave generata, la riga <code>authorized_keys</code> scritta da ProxMenux sul server limita la chiave a questa invocazione di borg-serve sul percorso configurato del repository:",
|
||||
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
|
||||
"restrictNote": "Il <code>command=</code> costringe ogni sessione SSH utilizzando questa chiave per eseguire solo il comando borg-serve; <code>restrict</code> disabilita l'inoltro della porta, l'inoltro dell'agente, l'inoltro di X11 e l'allocazione di PTY. La chiave non può essere utilizzata per aprire una shell interattiva sul server o per accedere a qualsiasi altro percorso di repository, anche se l'account ha privilegi più ampi."
|
||||
},
|
||||
"savedTargets": {
|
||||
"heading": "Obiettivi salvati",
|
||||
"intro": "Una destinazione salvata conserva la configurazione del repository con un nome riconoscibile, evitando di reinserire i dati. File nella directory di stato di ProxMenux:",
|
||||
"rows": [
|
||||
{
|
||||
"file": "borg-targets.txt",
|
||||
"content": "Una riga per destinazione: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> la legge per compilare il menu di selezione delle destinazioni."
|
||||
},
|
||||
{
|
||||
"file": "borg-pass-NAME.txt",
|
||||
"content": "Passphrase della destinazione indicata sopra come NAME (<code>chmod 600</code>). Presente soltanto se è stata scelta la crittografia repokey."
|
||||
}
|
||||
],
|
||||
"outro": "Salvare la destinazione è facoltativo. Rifiutando non si salva la configurazione con nome, ma una chiave SSH generata non viene eliminata. Se si attiva repokey senza salvare la destinazione, ProxMenux conserva comunque la passphrase nel file preesistente borg-pass.txt."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Crittografia",
|
||||
"body": "I repository sono inizializzati con una modalità di crittografia tramite <code>hb_borg_init_if_needed</code>: il moderno <code>borg repo-create -e MODE</code> quando disponibile, o il <code>borg init --encryption=MODE</code> legacy. ProxMenux espone due modalità: <code>repokey</code> (default) e <code>none</code>. In modalità <code>repokey</code> Borg memorizza la chiave di cifratura all'interno del repository stesso; l'accesso richiede una passphrase, che ProxMenux richiede due volte con verifica della corrispondenza e salva in <code>borg-pass-NAME.txt</code> per le destinazioni salvate, altrimenti nel file precedente descritto sopra. Una finestra di dialogo di riconoscimento obbligatoria viene mostrata dopo che il passphrase viene salvato: il passphrase è l'unico modo per accedere agli archivi crittografati, e perderlo rende ogni archivio nel repository non recuperabile."
|
||||
},
|
||||
"runtimeEnv": {
|
||||
"heading": "Ambiente runtime",
|
||||
"intro": "ProxMenux esporta le seguenti variabili ambientali prima di invocare <code>borg</code>. Configurano la connessione e sbloccano il repository senza inserire segreti nella riga di comando.",
|
||||
"rows": [
|
||||
{
|
||||
"var": "BORG_RSH",
|
||||
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
|
||||
"purpose": "Comando remoto usato da Borg per i repository SSH. Una chiave selezionata aggiunge le opzioni di identità; una porta non standard aggiunge -p PORT. Senza chiave personalizzata e con la porta predefinita, la variabile resta non impostata e Borg usa la configurazione SSH dell’host."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
"value": "(passphrase da borg-pass-NAME.txt)",
|
||||
"purpose": "Sblocca il repokey. Impostare solo quando il target utilizza la crittografia <code>repokey</code>. Non compare mai nell'elenco degli argomenti di processo."
|
||||
},
|
||||
{
|
||||
"var": "BORG_ENCRYPT_MODE",
|
||||
"value": "repokey | none",
|
||||
"purpose": "Utilizzato da <code>hb_borg_init_if_needed</code> quando inizializza un repository che non esiste ancora. Ignorato da <code>borg create</code> su repository esistenti."
|
||||
},
|
||||
{
|
||||
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Supprime il prompt interattivo Borg solleva quando l'URL del repository differisce dall'URL che originariamente è stato raggiunto da (comune dopo un rinominamento del punto di montaggio o SSH-host raggiungibile tramite nuovo indirizzo)."
|
||||
},
|
||||
{
|
||||
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Suppresse il prompt interattivo Borg solleva la prima volta che un repository non crittografato è accessibile da un nuovo client."
|
||||
}
|
||||
]
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Archivio denominazione e ritenzione",
|
||||
"intro": "Ogni backup crea un nuovo archivio all'interno del repository.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
|
||||
"retentionBody": "Per i lavori programmati, <code>run_scheduled_backup.sh</code> esegue <code>borg prune</code> contro il repository dopo ogni backup di successo con i valori di ritenzione configurati sul lavoro (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). I backup interattivi non eliminano le vecchie copie."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperare sul lato del ripristino",
|
||||
"body": "Il flusso di ripristino elenca gli archivi con <code>borg list REPO</code> ed estrae quello selezionato con <code>borg extract REPO::ARCHIVE-NAME</code> in una directory di staging che <code>_rs_check_layout</code> si alimenta alla pipeline di ripristino standard. Per il recupero manuale al di fuori di ProxMenux gli stessi comandi funzionano; l'albero estratto è il layout standard a tre payload descritto in <em>Come funziona </em>."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenze",
|
||||
"intro": "Documentazione ufficiale di Borg per i componenti usati da ProxMenux.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Documentazione del Borg",
|
||||
"href": "https://borgbackup.readthedocs.io/",
|
||||
"tail": "— punto di ingresso principale che copre concetti, distribuzione, avvio rapido e ogni comando."
|
||||
},
|
||||
{
|
||||
"label": "borg create",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
|
||||
"tail": " — il comando usato da ProxMenux per ogni backup, con tutte le opzioni supportate."
|
||||
},
|
||||
{
|
||||
"label": "Crittografia del repository",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
|
||||
"tail": "— le modalità di crittografia Borg supporta, incluso il repokey che ProxMenux utilizza per impostazione predefinita."
|
||||
},
|
||||
{
|
||||
"label": "borg serve e configurazione tramite SSH",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
|
||||
"tail": " — configurazione di un server Borg centrale accessibile via SSH, con il comando borg-serve e l’opzione restrict-to-path che ProxMenux scrive in authorized_keys."
|
||||
},
|
||||
{
|
||||
"label": "borg prune",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
|
||||
"tail": " — il modello di conservazione di --keep-last / --keep-daily / --keep-weekly che ProxMenux applica a ogni attività pianificata."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destinazioni di backup — Locale, Proxmox Backup Server, Borg | ProxMenux",
|
||||
"description": "Tre backend di storage ricevono lo stesso payload di backup ProxMenux: un archivio locale .tar.zst su qualsiasi filesystem scrivibile, un backup PBS in un datastore Proxmox Backup Server o un archivio Borg in un repository Borg locale o remoto. Ogni backend ha le proprie caratteristiche di compressione, deduplicazione, crittografia e rete.",
|
||||
"ogTitle": "Destinazioni di backup ProxMenux",
|
||||
"ogDescription": "Locale, Proxmox Backup Server e Borg — tre backend di archiviazione per lo stesso carico di backup host.",
|
||||
"twitterTitle": "Destinazioni di backup ProxMenux | ProxMenux",
|
||||
"twitterDescription": "Archivio locale, backend Proxmox Backup Server e Borg per i backup host."
|
||||
},
|
||||
"header": {
|
||||
"title": "Destinazioni",
|
||||
"description": "Tre backend di storage supportati da ProxMenux Backup: archivio locale, Proxmox Backup Server (consigliato) e Borg. Ognuno riceve lo stesso archivio con tre blocchi di dati; differiscono in formato di archiviazione, deduplicazione, modello di crittografia e requisiti di rete.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Stesso contenuto, tre backend",
|
||||
"body": "Ogni backup produce gli stessi tre payload (rootfs, manifest, applicazioni). Ciò che cambia tra le destinazioni è il modo in cui questi carichi sono memorizzati e come l'operatore li recupera per un ripristino. Ogni backend viene implementato come funzione separata in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — ma tutti e tre condividono lo stesso passo di staging (<code>hb_prepare_staging</code>) e lo stesso percorso del codice di ripristino. La scelta della destinazione colpisce solo la scrittura e il recupero; non cambia ciò che un ripristino fa o come consuma l'archivio."
|
||||
},
|
||||
"comparison": {
|
||||
"heading": "Confronto delle caratteristiche",
|
||||
"intro": "La tabella seguente elenca le differenze concrete tra i tre backend come si comportano oggi in ProxMenux. Tutti i valori descrivono il comportamento osservato del backend stesso, non raccomandazioni editoriali.",
|
||||
"rows": [
|
||||
{
|
||||
"feature": "Formato di archiviazione",
|
||||
"local": "File <code>.tar.zst</code> singolo (o <code>.tar.gz</code> se <code>zstd</code> è assente).",
|
||||
"pbs": "Backup PBS (blocchi <code>.pxar</code> nel datastore).",
|
||||
"borg": "Archivio Borg all'interno di un repository Borg (file di segmento)."
|
||||
},
|
||||
{
|
||||
"feature": "Compressione",
|
||||
"local": "zstd (livello predefinito) tramite <code>tar --zstd</code>. gzip fallback.",
|
||||
"pbs": "Gestita da proxmox-backup-client. ProxMenux non modifica le impostazioni di compressione.",
|
||||
"borg": "Compressione integrata di Borg. ProxMenux richiama borg create senza modificare le impostazioni di compressione."
|
||||
},
|
||||
{
|
||||
"feature": "Deduplicazione",
|
||||
"local": "Nessuno. Ogni backup è un archivio completamente indipendente.",
|
||||
"pbs": "Deduplicazione completa a livello di blocchi tra tutti i backup nel datastore.",
|
||||
"borg": "Deduplicazione completa a livello di blocchi tra tutti gli archivi del repository."
|
||||
},
|
||||
{
|
||||
"feature": "Crittografia a riposo",
|
||||
"local": "Nessuno (si basa sulla protezione a livello di filesystem).",
|
||||
"pbs": "Crittografia opzionale lato client mediante un file di chiave. Se abilitata, il blob di recupero viene caricato in un gruppo di backup separato.",
|
||||
"borg": "Crittografia repokey opzionale (chiave memorizzata nel repo, sbloccata da una passphrase)."
|
||||
},
|
||||
{
|
||||
"feature": "Conservazione / eliminazione delle vecchie copie",
|
||||
"local": "Applicata a ogni attività pianificata tramite <code>KEEP_LAST</code>. I vecchi archivi vengono eliminati insieme ai file ausiliari e ai log di esecuzione. I backup interattivi non eliminano le vecchie copie.",
|
||||
"pbs": "Applicato per lavoro programmato tramite <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. I backup interattivi non eliminano le vecchie copie.",
|
||||
"borg": "Applicato per lavoro programmato tramite <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. I backup interattivi non eliminano le vecchie copie."
|
||||
},
|
||||
{
|
||||
"feature": "Rete",
|
||||
"local": "Nessuno. Scrive a un punto di montaggio locale (tipicamente un disco interno o un'unità USB).",
|
||||
"pbs": "TCP al server PBS (porta di default 8007). Richiede credenziali PBS + impronta digitale.",
|
||||
"borg": "percorso filesystem locale o tunnel SSH a un host Borg remoto."
|
||||
},
|
||||
{
|
||||
"feature": "Dipendenze",
|
||||
"local": "<code>tar</code>, <code>zstd</code> (presente su Proxmox per impostazione predefinita).",
|
||||
"pbs": "Pacchetto <code>proxmox-backup-client</code> (incluso in Proxmox VE 8+).",
|
||||
"borg": "binario <code>borg</code>. Auto-provisionato da ProxMenux dal pacchetto Monitor AppImage quando manca."
|
||||
},
|
||||
{
|
||||
"feature": "Accesso per il ripristino",
|
||||
"local": "Qualsiasi host con tar+zstd può estrarre l'archivio. Non è necessario PBS/Borg.",
|
||||
"pbs": "Richiede <code>proxmox-backup-client</code>, le credenziali PBS e il file di chiave (se il backup è crittografato).",
|
||||
"borg": "Richiede <code>borg</code> + il percorso del repository + la passphrase (se crittografato)."
|
||||
}
|
||||
],
|
||||
"captionCode": "feature",
|
||||
"captionLocal": "Locale",
|
||||
"captionPbs": "Proxmox Backup Server (consigliato)",
|
||||
"captionBorg": "Borg"
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "Il layout dell'archivio non cambia con la destinazione",
|
||||
"body": "All'interno di una delle tre destinazioni, lo stesso layout <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descritto in <em>Come funziona</em> è presente. Un <code>.tar.zst</code> estratto da un archivio locale, un <code>.pxar</code> restaurato da PBS, e un archivio Borg estratto con <code>borg extract</code> producono tutti un albero di directory identico. Il percorso del codice di ripristino (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Estrazione di un backup al di fuori di ProxMenux",
|
||||
"intro": "Tutti i tre formati di archivio possono essere letti con strumenti standard senza ProxMenux installati sull'host di lettura. I comandi sottostanti producono lo stesso albero di directory che un ripristino consuma internamente.",
|
||||
"localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
|
||||
"pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n --repository USER@REALM@HOST:DATASTORE \\\n host/hostcfg-HOST/BACKUP-TIME \\\n hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
|
||||
"borgCmd": "# Da un archivio Borg (richiede borg e la passphrase per i repository crittografati):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Su un repository remoto accessibile via SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
|
||||
"note": "L'albero estratto può quindi essere ispezionato manualmente o alimentato a un ripristino manuale. Vedere le singole pagine di destinazione per l'esatto flusso di recupero ProxMenux utilizza sotto il cofano."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Dettagli per destinazione",
|
||||
"intro": "Ogni destinazione ha una propria pagina che copre il flusso di configurazione, il formato on-disk e il comando di recupero utilizzato dal ripristino.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Archivio locale",
|
||||
"href": "/docs/backup-restore/destinations/local",
|
||||
"tail": "— preconfigurazione di un target locale, montaggio dell'unità USB, controllo di sicurezza contro la scrittura dell'archivio in sé, la sidecar JSON che consente al Monitor di identificare il file."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox Backup Server (consigliato)",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "— selezione di datastore, credenziali e impronte digitali, ciclo di vita del keyfile di crittografia, passphrase di recupero, caricando il blob di recupero a PBS per il recupero di installazione fresca."
|
||||
},
|
||||
{
|
||||
"label": "Borg",
|
||||
"href": "/docs/backup-restore/destinations/borg",
|
||||
"tail": " — repository locali o accessibili via SSH, provenienza del binario Borg (sistema / cache / pacchetto AppImage di Monitor / download GitHub), inizializzazione del repository, gestione delle passphrase e configurazione delle chiavi SSH per i repository remoti."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,75 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destinazione dell'archivio locale — tar.zst su un filesystem o unità USB | ProxMenux",
|
||||
"description": "La destinazione di backup locale scrive un singolo archivio .tar.zst a qualsiasi directory scrivibile: un disco interno, un punto di montaggio Proxmox, una condivisione NFS o un'unità USB. Documenta il flusso di configurazione, la logica di rilevamento e montaggio USB, il controllo di sicurezza contro la scrittura dell'archivio in un percorso incluso nel backup, e il file ausiliario JSON che identifica il file.",
|
||||
"ogTitle": "ProxMenux Backup — Destinazione dell'archivio locale",
|
||||
"ogDescription": "Come ProxMenux scrive i backup locali come archivi .tar.zst e come configurare la directory di destinazione o unità USB.",
|
||||
"twitterTitle": "Destinazione di backup locale | ProxMenux",
|
||||
"twitterDescription": "Come ProxMenux scrive i backup locali come archivi .tar.zst su un filesystem o unità USB."
|
||||
},
|
||||
"header": {
|
||||
"title": "Archivio locale",
|
||||
"description": "La destinazione locale scrive un unico archivio tar compresso in una directory scrivibile sull’host: su un disco interno, un filesystem NFS o SMB montato oppure un’unità USB.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un file, autocontenuto",
|
||||
"body": "Un backup locale produce un singolo file <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (o <code>.tar.gz</code> quando <code>zstd</code> è assente). Il file contiene l'intero albero di archivio — <code>manifest.json</code>, <code>metadata/</code> e <code>rootfs/</code> — e può essere ripristinato su qualsiasi host Proxmox con il flusso di ripristino ProxMenux o estratto manualmente con <code>tar --zstd -xf</code> su qualsiasi sistema Linux. Nessun server, nessuna inizializzazione del repository, nessuna dipendenza esterna. Questa è la destinazione con il percorso di recupero più breve quando non è disponibile né PBS né Borg."
|
||||
},
|
||||
"targetConfig": {
|
||||
"heading": "Configurazione della directory target",
|
||||
"intro": "La destinazione locale è una <strong>unica directory di destinazione salvata in modo persistente</strong> — non un elenco. ProxMenux memorizza la scelta dell'operatore su <code>/usr/local/share/proxmenux/local-target.conf</code> e la legge su ogni backup. Quando non è stato configurato alcun obiettivo, viene utilizzato il <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> predefinito (la stessa directory Proxmox utilizza per le proprie uscite <code>vzdump</code>). L'obiettivo è configurato da <em>Configura destinazioni di backup → Destinazioni locali</em>:",
|
||||
"options": [
|
||||
"<strong>Utilizzo predefinito (<code>/var/lib/vz/dump</code>).</strong> Lo storage locale Proxmox. Presente su ogni installazione Proxmox; l'archivio si trova accanto alle uscite vzdump e viene ritirato dalla scheda Monitor Backups automaticamente.",
|
||||
"<strong>Inserisci un percorso personalizzato.</strong> Puoi usare qualsiasi percorso assoluto del filesystem: un montaggio NFS, una condivisione SMB montata tramite <code>fstab</code>, un dataset ZFS dedicato o un secondo disco interno. Prima di salvarlo, ProxMenux verifica che il percorso esista e sia una directory.",
|
||||
"<strong>Scegli un’unità USB.</strong> Apre il sottomenu USB (sotto), che rileva dispositivi rimovibili e offre di montare o formattarne uno."
|
||||
]
|
||||
},
|
||||
"usbFlow": {
|
||||
"heading": "Rilevamento dell'unità USB e montaggio",
|
||||
"intro": "Il sottomenu USB elenca le partizioni su dispositivi rimovibili segnalate da <code>lsblk</code>. Ogni partizione è presentata con la sua dimensione, l'etichetta del filesystem e lo stato corrente. Lo stato determina l’azione proposta da ProxMenux.",
|
||||
"statesTitle": "I tre stati del dispositivo",
|
||||
"stateRows": [
|
||||
{
|
||||
"state": "montato",
|
||||
"shown": "Dimensione · etichetta · [fstype] · → /mount/point",
|
||||
"action": "La partizione è già montata da qualche parte. La selezione salva il punto di montaggio corrente come obiettivo locale. Nessun montaggio viene eseguito."
|
||||
},
|
||||
{
|
||||
"state": "non montato",
|
||||
"shown": "Dimensione · etichetta · [fstype] · (non montato — sarà montato)",
|
||||
"action": "Un filesystem è presente ma non montato. A conferma, ProxMenux gestisce <code>hb_mount_usb_partition</code>: crea <code>/mnt/backup-LABEL</code> (o un percorso basato su UUID se non c'è etichetta), monta la partizione e persiste il punto di montaggio come obiettivo locale."
|
||||
},
|
||||
{
|
||||
"state": "vuoto",
|
||||
"shown": "Dimensione · disco USB grezzo — nessun filesystem (verrà FORMATTATO)",
|
||||
"action": "Il dispositivo non ha un filesystem. Questa operazione distruttiva è protetta da due conferme. Prima una finestra Sì/No spiega che il disco verrà cancellato. Poi una casella di input richiede di <strong>digitare il percorso esatto del dispositivo</strong> (ad esempio <code>/dev/sdb</code>) prima che ProxMenux crei una nuova tabella GPT con una partizione ext4 e la monti."
|
||||
}
|
||||
],
|
||||
"notMountedFallback": "Quando non viene rilevato alcun dispositivo USB, il submenu rientra in una semplice casella di input. L'operatore può immettere un percorso di mount point arbitrario; se il percorso non è un punto di montaggio registrato, una finestra di dialogo di conferma avvisa prima di procedere."
|
||||
},
|
||||
"safetyCheck": {
|
||||
"heading": "Controllo di sicurezza — destinazione all'interno di un percorso di backup",
|
||||
"body": "Prima di scrivere l'archivio, <code>_bk_local</code> verifica che la directory di destinazione sia <strong>non</strong> un sottopercorso di qualsiasi directory di cui viene eseguito il backup. Un errore comune sarebbe aggiungere <code>/root</code> al profilo e scegliere <code>/root/backups</code> come destinazione: l'archivio quindi includerebbe se stesso, producendo un archivio corrotto o crescendo senza limiti finché il disco non si riempie. Il controllo risolve entrambi i percorsi con <code>readlink -m</code>, li confronta e, in caso di conflitto, interrompe il backup con una finestra di dialogo che nomina il percorso in conflitto ed elenca tre modi per risolverlo: scegliere una destinazione al di fuori del percorso in conflitto, rimuovere la voce personalizzata che contiene la destinazione o utilizzare la modalità personalizzata per deselezionare il percorso in conflitto per questa esecuzione."
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Formato archivio e compressione",
|
||||
"intro": "Il nome del file di output include il nome host di origine e la data e ora del backup, per consentire l’ordinamento cronologico delle varie copie nella directory e identificare ogni file.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
|
||||
"compressionTitle": "Compressione",
|
||||
"compressionBody": "Il metodo principale usa <code>tar --zstd -cf</code>: un singolo comando che comprime al livello predefinito di zstd. Se <code>zstd</code> non è presente sull’origine (raro su Proxmox, ma possibile nelle installazioni minime), ProxMenux ripiega su <code>gzip</code>. In questo caso, se <code>pv</code> è disponibile, viene aggiunta una barra di avanzamento per mostrare la crescita dell’archivio in tempo reale; senza <code>pv</code>, viene usato il semplice <code>tar -czf</code> senza output di avanzamento.",
|
||||
"sourceTitle": "Cosa viene incluso nell’archivio",
|
||||
"sourceBody": "Il comando tar viene richiamato con <code>-C \"$staging_root\" .</code> e archivia <strong>l’intera radice della directory temporanea</strong>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code>. I tre blocchi di dati si trovano affiancati al livello superiore dell’archivio tar. L’estrazione produce esattamente lo stesso albero utilizzato dal codice di ripristino."
|
||||
},
|
||||
"sidecar": {
|
||||
"heading": "Il sidecar JSON",
|
||||
"intro": "Ogni backup locale di successo produce un file compagno: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, scritto accanto all'archivio da <code>hb_write_archive_sidecar</code>. Questo piccolo file JSON consente a ProxMenux Monitor di identificare l'archivio come ProxMenux backup host anche se in seguito viene spostato, rinominato o archiviato altrove.",
|
||||
"contentTitle": "Contenuto del sidecar",
|
||||
"contentBody": "Il sidecar memorizza la versione schema, se il backup proveniva da un run interattivo o da un lavoro programmato (<code>kind</code>), l'ID di lavoro per le esecuzioni pianificate, la modalità profilo utilizzata (<code>default</code> o <code>custom</code>), il nome host sorgente, il nome base originale dell'archivio, un timestamp di creazione ISO-8601 e la dimensione dell'archivio in byte.",
|
||||
"whyBody": "La scheda Backups di Monitor cerca i file ausiliari <code>*.proxmenux.json</code> nelle directory locali configurate, non i file <code>*.tar.zst</code>, perché un <code>.tar.zst</code> senza file ausiliario potrebbe non essere un backup ProxMenux. La scansione è veloce (i file JSON sono piccoli) e l’associazione resta valida quando l’archivio viene rinominato, purché anche il file ausiliario venga rinominato di conseguenza."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Ripristino da un archivio locale",
|
||||
"body": "Il flusso di ripristino ProxMenux scopre gli archivi locali scansionando l'obiettivo locale configurato per sidecars e visualizzandoli nell'elenco Archivi. Selezionando uno si attiva <code>_rs_check_layout</code>, che estrae il tarball in una directory di staging e conferma il layout a tre payload prima di procedere. Per estrazione manuale al di fuori di ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produce lo stesso albero che il codice di ripristino consuma."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "destinazione Proxmox Backup Server — repository, crittografia, ripristino | ProxMenux",
|
||||
"description": "La destinazione PBS salva i backup host di ProxMenux come backup PBS. Descrive il rilevamento dei repository da /etc/pve/storage.cfg, la configurazione manuale, il caricamento .pxar, la crittografia lato client con file di chiave e la sua copia di recupero facoltativa protetta da passphrase, e il recupero della chiave da più fonti su un host appena installato.",
|
||||
"ogTitle": "ProxMenux Backup — destinazione Proxmox Backup Server",
|
||||
"ogDescription": "Come ProxMenux scrive i backup host a Proxmox Backup Server con la crittografia del keyfile lato client e l'escrow di recupero.",
|
||||
"twitterTitle": "Destinazione di backup PBS | ProxMenux",
|
||||
"twitterDescription": "Destinazione Proxmox Backup Server con crittografia tramite file di chiave e copia di recupero protetta da passphrase."
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "La destinazione PBS carica l’intera directory di preparazione come un unico backup .pxar in un datastore Proxmox Backup Server, con crittografia facoltativa lato client tramite file di chiave. Facoltativamente, accanto a ogni backup viene caricata anche una copia della chiave protetta da passphrase per il recupero.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"recommendedBadge": "Destinazione consigliata",
|
||||
"aboutPbs": {
|
||||
"heading": "Ciò che Proxmox Backup Server è",
|
||||
"body": "Proxmox Backup Server (PBS) è il prodotto server di backup di Proxmox, sviluppato e mantenuto dallo stesso team che gli autori Proxmox VE. È un server di backup dedicato progettato per ricevere i backup da host Proxmox VE (VMs, LXCs e - via <code>proxmox-backup-client</code> - directory host arbitrari) con deduplicazione basata su blocchi, crittografia lato client e politiche di conservazione applicate lato server. ProxMenux utilizza PBS come una delle tre destinazioni per i backup host; ogni meccanismo specifico PBS descritto in questa pagina (gruppi di backup, archivi <code>.pxar</code>, <code>--backup-id</code>, crittografia keyfile) è un comportamento standard PBS."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un backup per esecuzione, deduplicazione a livello di blocchi",
|
||||
"body": "Un backup PBS crea una sola voce nel datastore, sotto l’ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. I dati sono un archivio <code>.pxar</code> con la stessa struttura in tre blocchi descritta in <em>Come funziona</em>. PBS deduplica i blocchi tra tutti i backup del datastore: i backup successivi dello stesso host trasferiscono e memorizzano soltanto i blocchi modificati. Per le attività pianificate, ProxMenux applica direttamente la conservazione: dopo ogni esecuzione riuscita, <code>run_scheduled_backup.sh</code> esegue <code>proxmox-backup-client prune</code> con <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> usando i valori configurati nell’attività."
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Selezione dei repository",
|
||||
"intro": "ProxMenux scopre i repository PBS da due fonti su ogni backup. L'operatore sceglie uno da un menu unificato; la scelta determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> per l'esecuzione.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg di Proxmox (rilevamento automatico)",
|
||||
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
|
||||
"content": "Ogni strofa <code>pbs:</code> nella configurazione di storage di Proxmox viene rilevata automaticamente. Server, datastore, nome utente e impronta digitale provengono dalla stanza. La password viene letta dalla directory delle credenziali di Proxmox. Nessun rientro necessario sul lato ProxMenux — il repository è disponibile non appena è configurato in Proxmox."
|
||||
},
|
||||
{
|
||||
"source": "Configurazione manuale ProxMenux",
|
||||
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
|
||||
"content": "Aggiunto da <em>Configure destinazioni di backup → PBS destinazioni → Aggiungi PBS</em>. Prompts per un nome, nome utente (<code>root@pam</code> o <code>user@pbs!token</code>), host o IP, datastore e password. I re-prompt password su input vuoto — un salvataggio vuoto altrimenti persisterebbe silenziosamente e ogni backup successivo fallirebbe con un errore di autenticazione opaco. Questo percorso viene utilizzato quando il target PBS non è registrato come storage Proxmox."
|
||||
}
|
||||
],
|
||||
"menuTitle": "Menu di selezione",
|
||||
"menuBody": "Entrambe le fonti sono mostrate in un unico menu, ciascuna riga contrassegnata con la sua origine (<code>[proxmox]</code> o <code>[manual]</code>). Le voci di cui la password non poteva essere risolta sono contrassegnate con un avviso <code>⚠ no password</code> — selezionando uno attiva un rientro password prima dell'avvio del backup. L'impronta digitale viene passata a <code>proxmox-backup-client</code> tramite la variabile di ambiente <code>PBS_FINGERPRINT</code>; quando assente, il client chiede all'operatore di accettare il certificato del server in modo interattivo sul primo backup."
|
||||
},
|
||||
"backupCommand": {
|
||||
"heading": "Il comando di backup",
|
||||
"intro": "Il caricamento avviene con una sola invocazione di <code>proxmox-backup-client backup</code>. ProxMenux usa <code>env</code> per passare al client password, password di crittografia e impronta digitale come variabili d’ambiente.",
|
||||
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
|
||||
"backupIdTitle": "Nome ID di backup",
|
||||
"backupIdBody": "L’ID di backup predefinito è <code>hostcfg-HOSTNAME</code>. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in <code>[A-Za-z0-9_-]</code> e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un <em>gruppo</em> e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.",
|
||||
"pxarTitle": "Perché la fonte è la radice di staging completa",
|
||||
"pxarBody": "La sorgente <code>.pxar</code> è l'intero <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> insieme. Le versioni precedenti hanno superato <code>$staging_root/rootfs</code> come fonte; che ha lasciato <code>metadata/</code> fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-<code>_rs_check_layout</code> di 3, che avvolge un albero <code>etc/var/root/usr</code> piatto di nuovo in una gerarchia <code>rootfs/</code>."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Crittografia lato cliente",
|
||||
"glossaryHint": "Questa sezione usa i termini <em>file di chiave</em>, <em>passphrase</em> e <em>involucro di recupero</em>. Il <glosarioLink>glossario</glosarioLink> ne riassume le differenze con una frase per termine.",
|
||||
"intro": "La crittografia PBS lato client con file di chiave cifra i blocchi sull’host di origine prima del caricamento. In ProxMenux è facoltativa. Se attivata, durante la configurazione l’operatore sceglie esplicitamente sì o no se caricare su PBS anche una copia di recupero del file di chiave protetta da passphrase; la scelta è modificabile in seguito dal Monitor. Il file di chiave risiede sempre nel percorso canonico <code>/usr/local/share/proxmenux/pbs-key.conf</code> e viene riutilizzato senza nuove richieste per ogni backup crittografato successivo.",
|
||||
"keyfileTitle": "Impostazione del keyfile",
|
||||
"keyfileBody": "Il dialogo di crittografia compare al primo backup crittografato dell’host. Prima chiede se crittografare il backup: <em>No</em> prosegue senza crittografia, <em>Sì</em> passa alla seconda fase. Questa dipende dalla presenza di un file di chiave in <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Se esiste, viene riutilizzato senza altre domande e il backup prosegue; i backup successivi non lo chiedono più. Altrimenti, un menu offre due opzioni. <em>Genera un nuovo file di chiave</em> esegue <code>proxmox-backup-client key create --kdf none</code>. <em>Usa un file di chiave esistente</em> rileva automaticamente una chiave gestita da PVE: se il repository PBS scelto è registrato in Proxmox con una chiave di crittografia in <code>/etc/pve/priv/storage/<NAME>.enc</code>, il file viene copiato senza altre domande nel percorso canonico di ProxMenux. Se nessuna chiave PVE corrisponde al repository, viene richiesto il percorso assoluto dove l’operatore ha già collocato il file sull’host. In entrambi i casi, il file viene installato nel percorso canonico con <code>chmod 600</code>.",
|
||||
"modesTitle": "Per-host o keyfile condiviso",
|
||||
"modesIntro": "Entrambi i modelli sono supportati e nessuno è obbligatorio: l’operatore sceglie in base all’organizzazione dei propri host.",
|
||||
"modesPerHostTitle": "File di chiave per host (predefinito)",
|
||||
"modesPerHostBody": "Ogni host genera un proprio keyfile la prima volta che consente la crittografia PBS. L'isolamento è il massimo: compromettere il keyfile di un host non espone i backup di qualsiasi altro. Consigliato per flotte di produzione e per ambienti in cui gli host hanno diversi proprietari o confini di conformità.",
|
||||
"modesSharedTitle": "Keyfile condiviso (importa su ogni host)",
|
||||
"modesSharedBody": "Un master keyfile generato una volta e installato su ogni host tramite l’opzione <em>Usa un file di chiave esistente</em>. La gestione è più semplice: un singolo segreto per salvaguardare, e qualsiasi host può decifrare gli archivi di qualsiasi altro (utile per il consolidamento, le esercitazioni di ripristino cross-host o la verifica centralizzata di backup). Il trade-off è che una perdita del keyfile condiviso espone ogni host contemporaneamente. Raccomandato per homelabs e per flotte dove tutti gli host hanno lo stesso proprietario e il limite di fiducia.",
|
||||
"recoveryTitle": "Caricare la chiave su PBS: decide l’operatore",
|
||||
"recoveryBody": "Subito dopo la scelta del file di chiave, ProxMenux pone la domanda esplicita <em>Caricare la chiave su PBS?</em>, con due risposte. <strong>Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì.</strong> L’opzione predefinita è <em>No, conserva solo in locale</em>: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante <em>Scarica il file di chiave</em> del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo <em>Sì, carica</em>, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo <code>pbs-key.recovery.enc</code>. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.",
|
||||
"blobUploadTitle": "Gruppo di backup abbinato su PBS",
|
||||
"blobUploadBody1": "Quando la modalità escrow è <em>Sì, carica</em>, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in <code>-keyrecovery</code>. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. <strong>La busta non lascia mai l'host in plaintext</strong>: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
|
||||
"envelopeSecurityTitle": "Caricare il file keyrecovery a PBS è un rischio di sicurezza?",
|
||||
"envelopeSecurityBody": "Il file keyrecovery è crittografato in transito e a riposo. Il passphrase di recupero non lascia mai l'host: la crittografia avviene localmente prima del caricamento, e PBS vede solo il risultato già crittografato. Un amministratore PBS — o chiunque abbia accesso al datastore — può scaricare il file di keyrecovery, ma senza la passphrase di recupero non può leggere il keyfile all'interno: è un codice opaco. Ricostruire il keyfile richiede entrambi i pezzi contemporaneamente, il file keyrecovery e la passphrase, e solo l'operatore tiene entrambi.",
|
||||
"blobUploadConstraintTitle": "Perché servono due gruppi anziché un unico gruppo crittografato",
|
||||
"blobUploadConstraintBody": "Una singola invocazione di <code>proxmox-backup-client backup</code> cifra tutti i suoi archivi con lo stesso file di chiave oppure nessuno: non è possibile mescolare i due casi. Il backup host deve essere cifrato con la chiave dell’host, ma l’involucro di recupero non può accompagnarlo nello stesso caricamento, perché verrebbe cifrato con la chiave che contiene. Su un host appena reinstallato non sarebbe possibile aprirlo: servirebbe la chiave per decifrare la chiave stessa. Per questo i due elementi vengono caricati indipendentemente e appaiono in due gruppi. Il client PBS cifra il backup host con il file di chiave, mentre ProxMenux cifra l’involucro con la passphrase prima del caricamento. Due livelli di crittografia diversi proteggono due elementi distinti.",
|
||||
"blobUploadImageAlt": "PBS UI che mostra i gruppi di backup hostcfg-HOSTNAME e hostcfg-HOSTNAME-keyrecovery adiacenti nell'elenco dei datastore.",
|
||||
"blobUploadImageCaption": "PBS UI — i gruppi di backup accoppiati. Il gruppo principale contiene i backup host; il gruppo -keyrecovery detiene il keyfile passphrase-wrapped.",
|
||||
"recoverTitle": "Recupero su un host fresco",
|
||||
"recoverBody": "Quando il file di chiave manca nel percorso canonico, dopo una reinstallazione o una rimozione esplicita, il ripristino prova tre fonti in ordine e si ferma alla prima che fornisce una chiave utilizzabile. Prima, se il repository PBS selezionato ha una chiave corrispondente gestita da PVE in <code>/etc/pve/priv/storage/<NAME>.enc</code>, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo <code>-keyrecovery</code>, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce <code>wrong key — manifest's key XX does not match provided key YY</code>. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.",
|
||||
"monitorManagementTitle": "Gestione del keyfile dal Monitor",
|
||||
"monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: <em>Scarica</em> esporta il file attuale nel browser; <em>Carica</em> sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; <em>Elimina</em> rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperare sul lato del ripristino",
|
||||
"body": "Il ripristino individua i backup host ProxMenux su PBS elencando i gruppi del repository configurato e filtrandoli per modello dell’ID. La scheda Backup del Monitor mostra lo stesso elenco. Scegliere un backup esegue <code>proxmox-backup-client restore</code> con gli stessi repository, password e impronta, oltre a <code>--keyfile</code> se il backup è crittografato. L’archivio <code>.pxar</code> viene estratto in una directory di preparazione che <code>_rs_check_layout</code> passa al normale processo di ripristino. Fuori da ProxMenux, lo stesso comando estrae l’archivio nel percorso desiderato per esaminare l’albero o procedere a un ripristino manuale."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenze",
|
||||
"intro": "Documentazione ufficiale di Proxmox Backup Server per i componenti usati da ProxMenux.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Documentazione Proxmox Backup Server",
|
||||
"href": "https://pbs.proxmox.com/docs/",
|
||||
"tail": "— punto di ingresso principale che copre l'installazione, l'amministrazione, lo stoccaggio, gli utenti e i ruoli."
|
||||
},
|
||||
{
|
||||
"label": "proxmox-backup-client",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html",
|
||||
"tail": " — lo strumento da riga di comando che ProxMenux usa per ogni backup e ripristino. Descrive ID e tipi di backup, archivi, sintassi dei repository e variabili d’ambiente."
|
||||
},
|
||||
{
|
||||
"label": "Crittografia lato cliente",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
|
||||
"tail": " — creazione del file di chiave, modalità --kdf e modello di crittografia che ProxMenux estende con una copia di recupero protetta da passphrase."
|
||||
},
|
||||
{
|
||||
"label": "Gestione dei datastore",
|
||||
"href": "https://pbs.proxmox.com/docs/storage.html",
|
||||
"tail": "— la creazione e la gestione dei datastores che ricevono i backup degli host, incluso il layout di chunk-store e le autorizzazioni."
|
||||
},
|
||||
{
|
||||
"label": "Eliminazione delle vecchie copie e garbage collection",
|
||||
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
|
||||
"tail": " — il modello di conservazione di --keep-last / --keep-daily / --keep-weekly che ProxMenux applica a ogni attività pianificata, e il recupero dei blocchi inutilizzati da parte di PBS dopo l’eliminazione delle vecchie copie."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Glossario — Backup & Ripristino | ProxMenux",
|
||||
"description": "Glossario di termini e definizioni per lo stack di backup e ripristino ProxMenux: crittografia, keyfile, passphrase, busta di recupero, PBS, chunks, rootfs, manifesto, runner e cross-kernel idratazione.",
|
||||
"ogTitle": "Backup & ripristino glossario | ProxMenux",
|
||||
"ogDescription": "Definizioni chiare per il vocabolario utilizzato attraverso la documentazione di backup e ripristino ProxMenux.",
|
||||
"twitterTitle": "Backup & ripristino glossario | ProxMenux",
|
||||
"twitterDescription": "Passphrase, keyfile, busta di recupero, rootfs, manifesto, PBS, chunks — tutto definito in un unico luogo."
|
||||
},
|
||||
"header": {
|
||||
"title": "Glossario",
|
||||
"description": "Termini utilizzati attraverso la documentazione di backup e ripristino, con la loro definizione.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"body": "I termini sono raggruppati per tema. Ogni voce dà il termine e una breve definizione."
|
||||
},
|
||||
"groups": [
|
||||
{
|
||||
"title": "Crittografia e recupero chiave",
|
||||
"intro": "Vocabolario per il blocco di crittografia PBS. Si tratta di due segreti distinti: un keyfile binario e un passphrase scritto.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "passphrase-recuperacion",
|
||||
"term": "Passphrase di ripristino",
|
||||
"def": "Password di testo che l'utente sceglie per proteggere la <a href=\"#sobre-recuperacion\">busta di recupero</a>. Viene richiesto due volte con un controllo match, ed è utilizzato solo per crittografare la busta e decifrarla se il keyfile ha bisogno di essere recuperato. <strong>Non è la passphrase che sblocca il keyfile stesso</strong>, e non viene mai inviata a PBS. Durante un backup normale non lascia mai l'host."
|
||||
},
|
||||
{
|
||||
"id": "clave-cifrado",
|
||||
"term": "Keyfile (chiave di crittografia)",
|
||||
"def": "File di chiave usato da proxmox-backup-client per cifrare i <a href=\"#chunk\">blocchi</a> prima dell’invio a PBS. Senza la chiave corrispondente i dati cifrati non sono leggibili. ProxMenux lo salva in <code>/usr/local/share/proxmenux/pbs-key.conf</code> con modalità <code>600</code>. Proteggilo: la <a href=\"#sobre-recuperacion\">busta di recupero</a> serve a recuperarlo in caso di perdita."
|
||||
},
|
||||
{
|
||||
"id": "contrasena-keyfile",
|
||||
"term": "Passphrase Keyfile (KDF passphrase)",
|
||||
"def": "Passphrase opzionale che il keyfile stesso può trasportare, distinto dal <a href=\"#passphrase-recuperacion\">passphrase di recupero</a>. Esiste solo quando il keyfile è stato creato con <code>--kdf scrypt</code> (tipicamente un keyfile importato). Senza di esso, il keyfile non può essere sbloccato per l'uso. ProxMenux persiste in forma crittografata sull'host in modo che i backup programmati possano funzionare senza un prompt interattivo."
|
||||
},
|
||||
{
|
||||
"id": "sobre-recuperacion",
|
||||
"term": "Busta di recupero",
|
||||
"def": "Il <a href=\"#clave-cifrado\">keyfile</a> avvolto in uno strato aggiuntivo: viene crittografato con il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a> utilizzando <a href=\"#aes-256-cbc\">AES-256-CBC</a> e <a href=\"#pbkdf2\">PBKDF2</a> prima che lasci l'host. È ciò che viene caricato su PBS come gruppo <code>-keyrecovery</code>. Senza la passphrase, la busta è opaca: scaricarla da PBS non rivela il keyfile."
|
||||
},
|
||||
{
|
||||
"id": "cifrado-cliente",
|
||||
"term": "Crittografia lato cliente",
|
||||
"def": "Modello di crittografia in cui i dati vengono crittografati sull'host sorgente prima di essere caricati. PBS riceve solo e memorizza il testo cifrario; nemmeno un amministratore PBS con accesso al datastore può leggerlo senza il keyfile. ProxMenux si basa su questo modello e aggiunge la <a href=\"#sobre-recuperacion\">busta di recupero</a> in cima."
|
||||
},
|
||||
{
|
||||
"id": "kdf-none",
|
||||
"term": "--kdf none",
|
||||
"def": "Opzione a <code>proxmox-backup-client key create</code> che produce un keyfile senza passphrase allegato. Il keyfile può essere utilizzato direttamente senza un prompt, che è essenziale per i lavori programmati in esecuzione incustodito. Questo è ciò che ProxMenux utilizza per impostazione predefinita quando si genera un nuovo keyfile."
|
||||
},
|
||||
{
|
||||
"id": "kdf-scrypt",
|
||||
"term": "--kdf scrypt",
|
||||
"def": "Opzione a <code>proxmox-backup-client key create</code> che produce un keyfile protetto da un <a href=\"#contrasena-keyfile\">passphrase del file di chiave</a>. Ogni utilizzo del keyfile richiede di sbloccarlo con quel passphrase. ProxMenux accetta questo stile di keyfile sull'importazione e memorizza il passphrase crittografato in modo che i backup programmati possano ancora essere eseguiti incustoditi."
|
||||
},
|
||||
{
|
||||
"id": "aes-256-cbc",
|
||||
"term": "AES-256-CBC",
|
||||
"def": "Cifra simmetrica standard. ProxMenux lo utilizza (tramite <code>openssl enc -aes-256-cbc</code>) per avvolgere il <a href=\"#clave-cifrado\">keyfile</a> con il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a> e produrre il <a href=\"#sobre-recuperacion\">busta</a>."
|
||||
},
|
||||
{
|
||||
"id": "pbkdf2",
|
||||
"term": "PBKDF2",
|
||||
"def": "Funzione crittografica che trasforma un passphrase di tipo umano in una chiave binaria adatta alla crittografia. Rallenta i tentativi di forza bruta applicando molte iterazioni. ProxMenux lo utilizza con iterazioni 600 000 e un sale casuale durante la crittografia della busta di recupero."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Struttura di backup",
|
||||
"intro": "Termini che descrivono cosa vive all'interno di un backup, indipendentemente dalla destinazione.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "rootfs",
|
||||
"term": "rootfs / filesystem radice",
|
||||
"def": "Copia dei file dell’host sorgente prodotta da <code>rsync</code> secondo il <a href=\"#perfil-defecto\">profilo predefinito</a> e i <a href=\"#rutas-personalizadas\">percorsi personalizzati</a>. Non è un’immagine dell’intero disco: vengono copiati solo percorsi con configurazione o stato che Proxmox non può rigenerare da sé."
|
||||
},
|
||||
{
|
||||
"id": "manifiesto",
|
||||
"term": "Manifesto (manifest.json)",
|
||||
"def": "Documento strutturato JSON che descrive l'host sorgente in tempo di backup: hardware, storage, kernel, componenti ProxMenux installati e inventario di VM e LXC. È prodotto da sei raccoglitori di dati indipendenti. Il flusso di ripristino lo utilizza per confrontare sorgente e obiettivo."
|
||||
},
|
||||
{
|
||||
"id": "staging",
|
||||
"term": "Directory di preparazione",
|
||||
"def": "directory temporanea in cui ProxMenux assembla i tre blocchi (rootfs, metadati e manifest) prima di imballarli e caricare alla destinazione. Viene rimosso automaticamente quando il backup termina, anche abortito."
|
||||
},
|
||||
{
|
||||
"id": "perfil-defecto",
|
||||
"term": "Profilo predefinito",
|
||||
"def": "Set di percorsi che ProxMenux copia per impostazione predefinita in ogni backup. Copre PVE config, rete, SSH, kernel, apt, strumenti ProxMenux e altro ancora. È definito in codice e documentato sul <em>Come funziona</em> pagina."
|
||||
},
|
||||
{
|
||||
"id": "rutas-personalizadas",
|
||||
"term": "Percorsi personalizzati",
|
||||
"def": "Percorsi extra l'utente aggiunge in cima al profilo <a href=\"#perfil-defecto\">default</a>. O persistente (conservato in <code>backup-extra-paths.txt</code>) o per-run (in modalità personalizzata)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Destinazioni e stoccaggio",
|
||||
"intro": "Termini legati a dove il backup atterra — server PBS, archivio locale o repository Borg — e come PBS organizza i dati.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "repositorio-pbs",
|
||||
"term": "Repository PBS",
|
||||
"def": "Combinazione di Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + utente che riceve il backup. Identificata dalla stringa <code>user@realm@host:datastore</code>. Un singolo server PBS può ospitare diversi repository."
|
||||
},
|
||||
{
|
||||
"id": "datastore",
|
||||
"term": "Datastore",
|
||||
"def": "Spazio di archiviazione specifico su un server PBS che contiene backup e relativi blocchi. Ogni datastore risiede su un file system del server PBS con propri permessi e criteri."
|
||||
},
|
||||
{
|
||||
"id": "chunk",
|
||||
"term": "Blocco (chunk) / deduplicazione dei blocchi",
|
||||
"def": "PBS divide ogni backup in blocchi di dimensioni variabili, identifica ogni pezzo dal suo hash e memorizza ogni pezzo solo una volta, anche se appare in molti backup diversi. Ciò significa backup successivi dello stesso host — o attraverso host simili — prendere molto poco spazio aggiuntivo."
|
||||
},
|
||||
{
|
||||
"id": "fingerprint",
|
||||
"term": "Impronta digitale",
|
||||
"def": "Impronte crittografica del certificato PBS del server TLS. Consente al client di verificare che stia parlando con il server previsto senza affidarsi a un'autorità di certificazione pubblica. ProxMenux passa a <code>proxmox-backup-client</code> tramite la variabile ambiente <code>PBS_FINGERPRINT</code>."
|
||||
},
|
||||
{
|
||||
"id": "grupo-copia",
|
||||
"term": "Gruppo backup",
|
||||
"def": "Contenitore logico all'interno di PBS in cui si accumulano backup successivi dello stesso asset. Ogni nuovo backup condivide la deduplica con quelli precedenti nello stesso gruppo. ProxMenux utilizza due gruppi per host quando la crittografia è abilitata: uno per il backup host e uno con un suffisso <code>-keyrecovery</code> per la <a href=\"#sobre-recuperacion\">busta di recupero</a>."
|
||||
},
|
||||
{
|
||||
"id": "backup-id",
|
||||
"term": "ID backup",
|
||||
"def": "Nome del gruppo <a href=\"#grupo-copia\">backup</a>. ProxMenux predefinisce <code>hostcfg-HOSTNAME</code> e consente all'utente di modificarlo prima del caricamento; i caratteri non supportati vengono rimossi automaticamente."
|
||||
},
|
||||
{
|
||||
"id": "pxar",
|
||||
"term": ".pxar",
|
||||
"def": "Formato di archivio nativo di PBS per directory. Si comporta come un archivio tar ottimizzato per la deduplicazione del pezzo: piuttosto che memorizzare un file opaco, PBS rompe il suo contenuto in pezzi riutilizzabili."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Esecuzione e pianificazione",
|
||||
"intro": "Termini utilizzati dal sistema di lavoro programmato ProxMenux.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "runner",
|
||||
"term": "Processo di esecuzione",
|
||||
"def": "Lo script <code>run_scheduled_backup.sh</code> che esegue un backup programmato. Legge la configurazione del lavoro, lancia il backend corrispondente (Local, PBS o Borg), applica la ritenzione sul successo e invia le notifiche configurate."
|
||||
},
|
||||
{
|
||||
"id": "trabajo-programado",
|
||||
"term": "Lavoro programmato",
|
||||
"def": "Configurazione persistente di un backup ricorrente. Contiene destinazione, credenziali, crittografia, pianificazione e conservazione. È salvata in <code>/var/lib/proxmenux/backup-jobs/<id>.env</code>."
|
||||
},
|
||||
{
|
||||
"id": "modo-adjunto",
|
||||
"term": "Modalità allegato",
|
||||
"def": "Processo senza timer proprio. Un hook job-end PVE di <code>vzdump</code> lo avvia dopo i backup dei guest se lo storage corrisponde. Il processo padre fornisce destinazione e conservazione iniziale, ma il hook confronta lo storage, non l’ID padre. Anche un altro processo sullo stesso storage può attivarlo. Solo Local e PBS."
|
||||
},
|
||||
{
|
||||
"id": "timer-systemd",
|
||||
"term": "Timer di systemd",
|
||||
"def": "Meccanismo standard systemd che accende un comando su un calendario. ProxMenux crea un timer per <em>indipendente</em> lavoro programmato; <a href=\"#modo-adjunto\">attach-mode</a> posti di lavoro non utilizzano timer, vengono eseguiti tramite lo script-hook PVE."
|
||||
},
|
||||
{
|
||||
"id": "retencion",
|
||||
"term": "Retenzione (keep-last, keep-daily...)",
|
||||
"def": "Politica che decide quali backup più vecchi mantenere e quali prune. Definito per lavoro con parametri come <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Applicato dal processo di esecuzione dopo ogni backup di successo."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Ripristina",
|
||||
"intro": "Termini dal flusso di ripristino.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "restauracion-universal",
|
||||
"term": "Ripristino universale",
|
||||
"def": "Il flusso di ripristino ProxMenux non si limita a estrarre il filesystem: legge il manifesto per individuare le differenze tra sorgente e obiettivo, riproduce la configurazione del sistema e riattiva gli installatori per i componenti gestiti da ProxMenux. L'obiettivo è quello di riprodurre l'host sorgente, non solo l'archivio."
|
||||
},
|
||||
{
|
||||
"id": "hidratacion",
|
||||
"term": "Idratazione (cross-kernel)",
|
||||
"def": "Passo di ripristino che fonde la propria configurazione dell'utente dalla sorgente (token IOMMU, ID dispositivo VFIO, quirk personalizzati, chiavi GRUB) in cima alla configurazione di avvio fresco del bersaglio, senza copiare i file legati al kernel della fonte verbatim. Esegue quando il kernel di destinazione è più nuovo di quello del backup."
|
||||
},
|
||||
{
|
||||
"id": "cross-kernel",
|
||||
"term": "Ripristino tra versioni del kernel",
|
||||
"def": "Ripristino in cui il kernel di destinazione è diverso, di solito più recente, da quello sorgente. Il passaggio di <a href=\"#hidratacion\">idratazione</a> evita di trascinare file incompatibili con il kernel di destinazione."
|
||||
},
|
||||
{
|
||||
"id": "instalador-postboot",
|
||||
"term": "Installatore post-boot",
|
||||
"def": "Componenti reinstallati dopo il primo avvio dell'host ripristinato ( driver NVIDIA, driver Coral TPU, strumenti AMD GPU, strumenti Intel GPU). Ogni installatore viene eseguito contro il kernel del bersaglio, quindi l'host ripristinato non dipende dal kernel della sorgente presente."
|
||||
},
|
||||
{
|
||||
"id": "compatibility-check",
|
||||
"term": "Controllo di compatibilità",
|
||||
"def": "Confronto tra il manifesto sorgente e lo stato del bersaglio che ProxMenux esegue all'inizio del ripristino. Decide quali parti sono copiate verbatim, che hanno bisogno di idratazione e che sono ricreati da un installatore."
|
||||
},
|
||||
{
|
||||
"id": "equipo-recien-instalado",
|
||||
"term": "Installazione da zero",
|
||||
"def": "Host appena reinstallato da zero, senza <a href=\"#clave-cifrado\">keyfile</a> locale. Ripristino di un backup crittografato richiede prima di recuperare il file chiave dal <a href=\"#sobre-recuperacion\">busta</a> memorizzato su PBS, utilizzando il <a href=\"#passphrase-recuperacion\">passphrase di recupero</a>."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"whereNext": {
|
||||
"heading": "Dove proseguire",
|
||||
"items": [
|
||||
{
|
||||
"label": "Come funziona",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — come rootfs, manifesto e inventario applicazioni si inseriscono nel backup."
|
||||
},
|
||||
{
|
||||
"label": "Destinazione Proxmox Backup Server",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "— in cui la crittografia lato client, keyfile, passphrase di recupero e busta sono documentati in profondità."
|
||||
},
|
||||
{
|
||||
"label": "Ripristino",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — procedura di ripristino e uso del manifesto."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,205 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Come funziona il backup ProxMenux internamente — rootfs, manifesto, applicazioni",
|
||||
"description": "Contenuto dettagliato di un backup ProxMenux: il rootfs copiato con rsync secondo il profilo di percorsi predefinito, il manifesto strutturato creato da sei moduli di raccolta indipendenti e l’inventario delle applicazioni che guida la reinstallazione automatica di pacchetti e componenti dopo il ripristino.",
|
||||
"ogTitle": "Come funziona ProxMenux Backup internamente",
|
||||
"ogDescription": "Le tre parti di un backup ProxMenux: rootfs, manifesto e applicazioni.",
|
||||
"twitterTitle": "Come funziona ProxMenux Backup | ProxMenux",
|
||||
"twitterDescription": "I tre payload di un backup ProxMenux e come il ripristino riproduce l'host sorgente da loro."
|
||||
},
|
||||
"header": {
|
||||
"title": "Come funziona",
|
||||
"description": "La ripartizione interna di un backup ProxMenux — filesystem, inventario manifesto e di applicazione — e come il ripristino consuma tutti e tre per riprodurre l'host sorgente su un obiettivo che potrebbe non condividere lo stesso kernel.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un archivio, tre parti",
|
||||
"body": "Ogni backup crea tre parti definite sotto un’unica directory di preparazione. L’archivio caricato sulla destinazione (<code>.tar.zst</code> locale, backup PBS o archivio Borg) conserva questa struttura. Il ripristino usa tutte e tre: <strong>il manifesto</strong> viene consultato prima delle modifiche per rilevare differenze e decidere cosa escludere; <strong>rootfs</strong> fornisce i file di configurazione, applicati subito o dopo il riavvio; <strong>l’inventario delle applicazioni</strong> guida l’installazione dei pacchetti e la reinstallazione dei componenti dopo l’avvio. Ogni parte può essere esaminata o estratta indipendentemente."
|
||||
},
|
||||
"layout": {
|
||||
"heading": "Disposizione dell'archivio",
|
||||
"intro": "Ogni archivio segue lo stesso layout albero indipendentemente dalla destinazione. La sottodirectory <code>metadata/</code> contiene i dati strutturati; la sottodirectory <code>rootfs/</code> contiene la copia del filesystem.",
|
||||
"treeCaption": "La directory di preparazione creata durante il backup. Tutte le destinazioni ricevono lo stesso albero nel proprio formato nativo: tar per i backup locali, blocchi PBS per PBS e segmenti Borg per Borg.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state\n├── metadata/\n│ ├── packages.manual.list # apt-mark showmanual\n│ ├── run_info.env # backup run identity + kernel version + pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n ├── root/ # /root (with volatile subdirs excluded)\n ├── usr/local/ # /usr/local/bin, /usr/local/share/proxmenux, …\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
|
||||
},
|
||||
"rootfs": {
|
||||
"heading": "La parte rootfs",
|
||||
"intro": "L’albero <code>rootfs/</code> è una <strong>semplice copia del filesystem</strong> prodotta da <code>rsync</code> dall’host di origine. Contiene un <strong>profilo predefinito</strong> di percorsi scelti per il ripristino Proxmox e gli eventuali <strong>percorsi personalizzati</strong> aggiunti all’attività o alla sessione interattiva. La selezione è volutamente limitata ai percorsi che <em>contengono configurazione</em> o <em>conservano uno stato che Proxmox non può rigenerare da solo</em>.",
|
||||
"defaultProfileTitle": "Il profilo predefinito",
|
||||
"defaultProfileBody": "Il profilo predefinito è definito da <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. Copre otto categorie fisse e, se necessario, lo stato ZFS, che insieme descrivono un host Proxmox operativo:",
|
||||
"categoriesTitle": "Categorie dei percorsi",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Nucleo PVE",
|
||||
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
|
||||
"why": "Contenuto del filesystem Cluster e default vzdump. Il database PMxcfs (<code>config.db</code>) viene catturato come un'istantanea coerente tramite <code>sqlite3 .backup</code> senza interrompere il cluster, e i sidecar <code>.db-wal</code> / <code>.db-shm</code> sono esclusi dal rsync. Quando <code>sqlite3</code> non è disponibile, viene creato <code>config.db.raw-fallback</code>, che il ripristino usa automaticamente come database."
|
||||
},
|
||||
{
|
||||
"category": "Identità e rete host",
|
||||
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
|
||||
"why": "Tutto ciò che serve all’host per tornare in rete con la stessa identità. I file <code>.link</code> in <code>/etc/systemd/network</code> associano i nomi delle schede alle rispettive MAC, mantenendo i nomi durante reinstallazioni e modifiche hardware."
|
||||
},
|
||||
{
|
||||
"category": "Accesso e autenticazione",
|
||||
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
|
||||
"why": "Chiavi SSH, regole sudo e configurazione PAM. Perderle impedisce all’utente di accedere all’host ripristinato."
|
||||
},
|
||||
{
|
||||
"category": "Kernel e avvio",
|
||||
"paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
|
||||
"why": "Parametri IOMMU, blacklist dei moduli, ID dei dispositivi VFIO, tabella dei montaggi e configurazione dello stack di archiviazione."
|
||||
},
|
||||
{
|
||||
"category": "Shell e impostazioni locali",
|
||||
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
|
||||
"why": "Configurazione di shell a livello di sistema, variabili di ambiente, configurazione di generazione locale."
|
||||
},
|
||||
{
|
||||
"category": "Gestione pacchetti e cron",
|
||||
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
|
||||
"why": "Fonti APT per una risoluzione coerente dei pacchetti, attività pianificate definite dall'utente."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux stati e strumenti",
|
||||
"paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
|
||||
"why": "Utensili Proxmox opzionali ma comuni. I percorsi mancanti sono segnalati in <code>metadata/missing_paths.txt</code> senza interrompere il backup."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux binari e root",
|
||||
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (sottodiri volatili esclusi)",
|
||||
"why": "File binari ProxMenux e configurazione per utente sotto <code>/root</code>. I percorsi volatili (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sono esclusi dalla copia. <code>/var/lib/proxmenux</code> detiene i lavori di backup programmati e lo stato dell’host tenuto da ProxMenux; la messa in scena di ripristino, le copie rollback e i marcatori post-restore sono esclusi, perché appartengono all'host che gestisce un ripristino."
|
||||
},
|
||||
{
|
||||
"category": "Stato ZFS (condizionato)",
|
||||
"paths": "/etc/zfs",
|
||||
"why": "Solo incluso quando l'host sorgente esegue ZFS. Contiene <code>zpool.cache</code> e <code>hostid</code>."
|
||||
}
|
||||
],
|
||||
"customTitle": "Estendere il profilo con percorsi personalizzati",
|
||||
"customBody": "Oltre al profilo predefinito, ProxMenux offre due modi per includere ulteriori percorsi in un backup. Si compone senza conflitti ed entrambi si applicano a backup interattivi e lavori programmati.",
|
||||
"customExtrasTitle": "1. Extra persistenti (file per host)",
|
||||
"customExtrasBody": "Un file di testo a <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contiene un elenco di percorsi assoluti che l'utente ha contrassegnato come \"sempre includere\" su questo host. Quando un backup viene eseguito in modalità <strong>Default</strong>, ProxMenux aggiunge questi percorsi al profilo predefinito automaticamente senza chiedere. Il file viene modificato dall'interfaccia — nessuna modifica manuale necessaria — e persiste attraverso riavvimenti e aggiornamenti. Un percorso assoluto per linea; sono consentiti commenti <code>#</code>.",
|
||||
"customModeTitle": "2. Modalità personalizzata (per-run)",
|
||||
"customModeBody": "Avviare un backup in modalità <strong>Custom</strong> sostituisce l'applicazione automatica del profilo predefinito con una lista di controllo che mostra ogni percorso: le voci del profilo predefinito e gli extra persistenti (prefissati con <code>[+]</code> e già selezionati). L'utente seleziona o deseleziona le voci per tale esecuzione specifica, e può anche premere <em>Aggiungi percorso personalizzato</em> per inserire un nuovo percorso — che viene poi persistito al file extra per i backup futuri.",
|
||||
"customMissingTitle": "Sentieri assenti dalla fonte",
|
||||
"customMissingBody": "Qualsiasi percorso dal profilo (default o aggiunto) che non esiste sull'host sorgente viene registrato in <code>metadata/missing_paths.txt</code> all'interno dell'archivio. Il backup non fallisce né si ferma — l'utente vede un riassunto di percorsi archiviati e percorsi mancanti alla fine. In pratica questo accade per percorsi di utensile opzionali come <code>/etc/wireguard</code> o <code>/etc/prometheus</code> quando questi strumenti non sono installati."
|
||||
},
|
||||
"manifest": {
|
||||
"heading": "La parte manifesto",
|
||||
"intro": "<code>manifest.json</code> è un documento strutturato JSON che descrive l'host sorgente al momento del backup. È prodotto da <strong>sei moduli di raccolta indipendenti</strong> orchestrati da <code>build_manifest.sh</code>. Ogni collettore è in sola lettura, produce un frammento JSON ben definito, e rientra in un default vuoto sicuro se non riesce — il manifesto è ancora utilizzabile se una sezione è incompleta.",
|
||||
"orchestratorCaption": "I sei moduli di raccolta compongono il manifesto. Ogni collettore funziona nel proprio sottoprocesso; un guasto in uno rientra in un documento di default sicuro e avverte ma non interrompe il backup.",
|
||||
"collectorRows": [
|
||||
{
|
||||
"collector": "collect_source_host.sh",
|
||||
"produces": "source_host",
|
||||
"content": "Hostname, versione PVE (<code>pveversion</code>), versione PBS se l'host esegue il ruolo di backup-server, kernel (<code>uname -r</code>), modalità boot (efi/bios), tipo filesystem root, modello CPU + architettura, memoria in KB."
|
||||
},
|
||||
{
|
||||
"collector": "collect_hardware.sh",
|
||||
"produces": "hardware_inventory",
|
||||
"content": "GPU (con il fornitore e la mappatura dell'installatore ProxMenux), TPU (Coral USB + M.2 con il rilevamento di <code>lsusb</code>/<code>lspci</code>), NIC (con MAC, slot PCI e ponti), dispositivi wireless. Le voci GPU portano un'euristica <code>passthrough_eligible</code>."
|
||||
},
|
||||
{
|
||||
"collector": "collect_storage.sh",
|
||||
"produces": "storage_inventory",
|
||||
"content": "Pool ZFS con relativo tipo e dischi membri identificati tramite <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> o percorsi diretti <code>/dev/sdX</code>, a seconda di come il pool è stato creato; gruppi di volumi e thin pool LVM; dischi fisici con supporto SMART; voci PVE di <code>storage.cfg</code>; montaggi esterni."
|
||||
},
|
||||
{
|
||||
"collector": "collect_kernel.sh",
|
||||
"produces": "kernel_params",
|
||||
"content": "Parametri aggiunti dall’operatore in <code>/proc/cmdline</code>, esclusi quelli standard come <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> e <code>splash</code>; moduli caricati all’avvio da <code>/etc/modules</code>; percorsi dei file <code>/etc/modprobe.d/*.conf</code> con direttive effettive (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
|
||||
},
|
||||
{
|
||||
"collector": "collect_proxmenux_state.sh",
|
||||
"produces": "proxmenux_installed_components",
|
||||
"content": "Leggi <code>/usr/local/share/proxmenux/managed_installs.json</code> (registry di tutto ciò che ProxMenux ha installato) e <code>installed_tools.json</code>. Ogni voce mantiene il percorso di installazione (<code>menu_script</code>) in modo che il ripristino possa attivare lo stesso flusso di installazione."
|
||||
},
|
||||
{
|
||||
"collector": "collect_guests.sh",
|
||||
"produces": "vms_lxcs_at_backup",
|
||||
"content": "Elenca le VM (<code>qm list</code>) e i container LXC (<code>pct list</code>) presenti al momento del backup: VMID, nome e stato. È soltanto l’inventario; il backup dei dati effettivi dei guest spetta a <code>vzdump</code> / PBS."
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validazione schema",
|
||||
"schemaBody": "Il manifesto convalida contro <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'esecuzione di <code>build_manifest.sh --validate</code> attiva una validazione dello schema JSON (richiede <code>python3</code> + <code>jsonschema</code>). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "inventario delle applicazioni",
|
||||
"intro": "Due inventari elencano il software aggiunto ai pacchetti base di Proxmox VE: la lista dei pacchetti in <code>metadata/</code> e il registro dei componenti in rootfs, descritti di seguito. Il ripristino usa APT o gli installatori ProxMenux per riprodurre il software dell’utente secondo il metodo originale di installazione.",
|
||||
"packagesTitle": "packages.manual.list",
|
||||
"packagesBody": "Una lista alfabetica in testo semplice prodotta da <code>apt-mark showmanual</code> con tutti i pacchetti APT <em>installati esplicitamente</em> sull’host di origine. Sono escluse le dipendenze del sistema Proxmox VE di base, che APT installa automaticamente sul destinatario. Durante il ripristino, <code>_rs_run_complete_extras</code> legge la lista e applica un <em>filtro contro le rimozioni a cascata</em> in tre passaggi: <code>dpkg -s</code> rileva i pacchetti già installati, vengono rilevate altre versioni principali delle librerie e <code>apt-get install --simulate</code> verifica il rischio di rimozioni a cascata. Infine usa <code>apt-get install -y</code> per i pacchetti rimasti.",
|
||||
"componentsTitle": "components_status.json (parte di rootfs)",
|
||||
"componentsBody": "Un registro JSON sotto <code>/usr/local/share/proxmenux/</code> che registra ogni componente ProxMenux installato con il suo stato esatto: versione, bandiere ProxMenux-specifiche (per NVIDIA: <code>patched</code> boolean; per Coral: versione DKMS). Questo file vive all'interno dei rootfs — non in <code>metadata/</code> — perché è <em>letto dopo</em> la copia di rootfs al bersaglio. Il distaccatore post-boot (<code>apply_cluster_postboot.sh</code>) itera sulle sue voci ed esegue il gancio <code>--auto-reinstall</code> di ciascun componente, che legge lo stato registrato e riproduce l'installazione contro il kernel corrente dell'obiettivo.",
|
||||
"componentInstallersTitle": "Installatori di componenti",
|
||||
"componentInstallersBody": "Quattro installatori ProxMenux attualmente espongono un punto di ingresso <code>--auto-reinstall</code>:",
|
||||
"installerRows": [
|
||||
{
|
||||
"component": "nvidia_driver",
|
||||
"installer": "gpu_tpu/nvidia_installer.sh",
|
||||
"action": "Leggi <code>version</code> + <code>patched</code>. Scarica lo stesso runfile NVIDIA, costruisce moduli DKMS contro il kernel dell'obiettivo, riapplica la patch ProxMenux se la sorgente lo avesse."
|
||||
},
|
||||
{
|
||||
"component": "coral_driver",
|
||||
"installer": "gpu_tpu/install_coral.sh",
|
||||
"action": "Legge la versione del driver Coral. Compili il modulo DKMS contro il kernel dell'obiettivo."
|
||||
},
|
||||
{
|
||||
"component": "amdgpu_top",
|
||||
"installer": "gpu_tpu/amd_gpu_tools.sh",
|
||||
"action": "Legge la versione registrata. Ricarica l'esatta <code>.deb</code> dalla versione GitHub."
|
||||
},
|
||||
{
|
||||
"component": "intel_gpu_tools",
|
||||
"installer": "gpu_tpu/intel_gpu_tools.sh",
|
||||
"action": "APT-installa il pacchetto. Idemponte se già presente da <code>packages.manual.list</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"restoreFlow": {
|
||||
"heading": "Come il ripristino usa le tre parti",
|
||||
"intro": "Il restauro e' una pipeline di sei stadi. Ogni fase legge un sottoinsieme specifico dell'archivio e aggiorna l'host di destinazione. Nessuna fase richiede che l'host sorgente sia raggiungibile — l'archivio è completamente autonomo.",
|
||||
"stagesCaption": "La fase 1 usa il manifesto per decidere cosa modificare. La fase 2 copia i percorsi rootfs applicabili al sistema in esecuzione. La fase 3 prepara quelli rischiosi per il prossimo avvio. La fase 3b importa i pool ZFS di dati che non contengono la radice e hanno tutti i dischi presenti. La fase 4 gestisce i pacchetti. La fase 5 reinstalla i componenti dopo il riavvio per il kernel di destinazione.",
|
||||
"stageRows": [
|
||||
{
|
||||
"stage": "1",
|
||||
"name": "Controllo di compatibilità",
|
||||
"reads": "manifest.json",
|
||||
"action": "Esegue <code>hb_compat_check</code>. Confronta sorgente vs. hardware target (NIC, ID di archiviazione), versione PVE e versione kernel principale. Imposta <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> o <code>bk_older</code>) e popola <code>RS_SKIP_PATHS</code> con esclusione hardware-drift e cross-kernel."
|
||||
},
|
||||
{
|
||||
"stage": "2",
|
||||
"name": "Applicazione a sistema avviato",
|
||||
"reads": "rootfs/ (solo percorsi sicuri)",
|
||||
"action": "<code>_rs_apply … hot</code> copia le voci <code>hb_classify_path</code>=<code>hot</code> direttamente al target live. Qualsiasi cosa sotto <code>/etc/pve</code>, <code>/etc/network</code> o percorsi classificati come <em>reboot</em>/<em>dangerous</em> è differita."
|
||||
},
|
||||
{
|
||||
"stage": "3",
|
||||
"name": "Preparazione delle modifiche differite",
|
||||
"reads": "rootfs/ (riavvio + percorsi pericolosi)",
|
||||
"action": "<code>_rs_prepare_pending_restore</code> prepara i percorsi rischiosi in <code>/var/lib/proxmenux/pending-restore/</code>, scrive <code>plan.env</code>, <code>apply-on-boot.list</code> e <code>rs-skip-paths.txt</code> e abilita <code>proxmenux-restore-onboot.service</code> per il prossimo avvio."
|
||||
},
|
||||
{
|
||||
"stage": "3b",
|
||||
"name": "Importazione dei pool di dati",
|
||||
"reads": "manifest.storage_inventory + target ZFS stato",
|
||||
"action": "<code>_rs_import_data_pools</code> tenta di importare ogni pool ZFS che non contiene la radice e ha tutti i dischi presenti sul destinatario. Se il pool ha un hostid estraneo, riprova con <code>zpool import -f</code>. Se manca un disco, il pool viene saltato con un avviso. Il risultato per pool è registrato in <code>/var/log/proxmenux/restore-datapools-<timestamp>.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "4",
|
||||
"name": "Installazione del pacchetto",
|
||||
"reads": "metadata/packages.manual.list",
|
||||
"action": "<code>_rs_run_complete_extras</code> gestisce il filtro a cascata e chiama <code>apt-get install -y</code> con l'elenco dei pacchetti sopravvissuti. L'uscita completa va a <code>/var/log/proxmenux/restore-apt-*.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "5",
|
||||
"name": "Dopo l'avvio",
|
||||
"reads": "rootfs (già applicato) + components_status.json",
|
||||
"action": "Dopo il riavvio, <code>apply_pending_restore.sh</code> riprende i percorsi differiti e <code>apply_cluster_postboot.sh</code> corre <code>update-initramfs</code>, <code>update-grub</code> (o <code>proxmox-boot-tool refresh</code>) e itera oltre <code>components_status.json</code> sparando il gancio <code>--auto-reinstall</code> di ogni componente."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyItWorks": {
|
||||
"heading": "Perché suddividere il backup in tre parti",
|
||||
"body": "La suddivisione segue il <strong>ciclo di vita</strong> dei dati. Il filesystem viene trasferito con <code>rsync</code>: rapidamente, in modo trasparente e atomico per file. Lo stato di configurazione da interpretare prima delle modifiche è <strong>JSON strutturato</strong>, leggibile separatamente, versionabile tramite schema e confrontabile automaticamente con lo stato di destinazione. Il software da reinstallare è descritto in un <strong>inventario</strong> di nomi e versioni; il gestore dei pacchetti e gli installatori ProxMenux scelgono i binari adatti. Ogni parte svolge il proprio compito. Insieme mirano a un ripristino coerente ma tollerante agli errori: un manifesto corrotto lascia rootfs ripristinabile, un pacchetto mancante non impedisce l’installazione dei componenti e un errore su una voce non ferma l’installazione della successiva."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Backup e ripristino — Panoramica | Backup e ripristino completo dell'host per Proxmox VE",
|
||||
"description": "ProxMenux Backup e ripristino acquisisce lo stato completo di un host Proxmox (file system, manifest di configurazione strutturata e pacchetti/componenti installati) e lo riproduce sullo stesso host o su un host diverso. Il backup e il ripristino sono autonomi: nessuna dipendenza esterna e i ripristini tra kernel sono supportati tramite un filtro di sottoinsieme sicuro sensibile alla direzione e un'idratazione indipendente dal kernel.",
|
||||
"ogTitle": "ProxMenux Backup e ripristino - Panoramica",
|
||||
"ogDescription": "Backup e ripristino completo dell'host per Proxmox VE con manifest strutturato, elenco di pacchetti e programmi di reinstallazione dei componenti.",
|
||||
"twitterTitle": "ProxMenux Backup e ripristino | ProxMenux",
|
||||
"twitterDescription": "Backup e ripristino completo dell'host per Proxmox VE con manifest strutturato, elenco di pacchetti e programmi di reinstallazione dei componenti."
|
||||
},
|
||||
"header": {
|
||||
"title": "Backup e ripristino",
|
||||
"description": "Backup e ripristino dell'intero host per Proxmox VE. Cattura filesystem, configurazione e componenti installati in un unico archivio e riproduce l'host sulla stessa o su una diversa installazione Proxmox senza dipendenze esterne.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Che cos'è, in un paragrafo",
|
||||
"body": "Un backup di ProxMenux acquisisce lo stato completo di un host Proxmox: <strong>il filesystem</strong>, con le directory pertinenti in <code>/etc</code>, <code>/root</code> e <code>/var/lib/pve-cluster</code> e gli eventuali percorsi personalizzati; <strong>un manifesto strutturato</strong> in JSON con hardware rilevato, parametri del kernel, configurazione di rete, stato di ZFS, utenti e voci cron; e <strong>un inventario delle applicazioni</strong>, con i pacchetti contrassegnati da APT come installati manualmente e i componenti installati da ProxMenux, completi delle versioni esatte. Le tre destinazioni supportate — archivio locale, Proxmox Backup Server (consigliato) e Borg — ricevono lo stesso contenuto autonomo. Ognuna consente di ricostruire l’host di destinazione senza che l’host di origine debba essere raggiungibile durante il ripristino."
|
||||
},
|
||||
"video": {
|
||||
"heading": "Video tutorial",
|
||||
"intro": "Preferisci guardare Backup e ripristino in azione prima di configurarlo? Questa procedura dettagliata copre una demo completa end-to-end della funzionalità in ProxMenux.",
|
||||
"title": "ProxMenux — Procedura dettagliata di backup e ripristino",
|
||||
"caption": "Video esterno su YouTube. Riproduce in modalità di privacy avanzata (nessun cookie finché non premi Riproduci)."
|
||||
},
|
||||
"whatItIsNot": {
|
||||
"heading": "Cosa non è",
|
||||
"intro": "Questa sezione riguarda il backup e il ripristino <strong>dell’host</strong>: l’installazione di Proxmox, non le applicazioni e i sistemi guest che vi vengono eseguiti.",
|
||||
"items": [
|
||||
"<strong>Non è uno strumento di backup delle VM/CT.</strong> Questa funzione non acquisisce i dischi o lo stato della RAM dei guest: a questo serve <code>vzdump</code>. I <strong>file di configurazione</strong> dei guest (<code>/etc/pve/nodes/<node>/qemu-server/*.conf</code> e <code>lxc/*.conf</code>) vengono <strong>invece</strong> salvati. Dopo il ripristino ricompare l’inventario e i dischi possono essere ripristinati o ricollegati da un backup esistente su PBS o in locale.",
|
||||
"<strong>Non è un’operazione sull’intero cluster.</strong> Ogni nodo salva il proprio backup. L’appartenenza al cluster è inclusa in <code>/etc/pve</code>, così un nodo ripristinato può esservi reintegrato; il ripristino di tutto il cluster richiede però il coordinamento dei singoli nodi.",
|
||||
"<strong>Non è un’immagine completa del disco.</strong> Non vengono salvati i binari del kernel, l’initramfs o la partizione di avvio. Durante il ripristino ProxMenux usa i file di avvio dell’host di destinazione, rigenerati automaticamente da <code>update-initramfs</code> e dallo strumento del bootloader, e installa i driver compatibili con il kernel in esecuzione sulla destinazione."
|
||||
]
|
||||
},
|
||||
"threePillars": {
|
||||
"heading": "I tre pilastri di un backup",
|
||||
"intro": "Un archivio ProxMenux è strutturato attorno a tre payload autonomi. Il ripristino li utilizza tutti e tre insieme per riprodurre l'host di origine su una destinazione che potrebbe non avere nemmeno lo stesso kernel installato.",
|
||||
"diagramCaption": "Ogni backup spedisce gli stessi tre payload indipendentemente dalla destinazione. Il ripristino utilizza tutti e tre: rootfs per depositare i file, manifest per rilevare deviazioni e differenze tra kernel e inventario delle applicazioni per reinstallare pacchetti e componenti sul kernel della destinazione.",
|
||||
"pillar1Label": "Filesystem",
|
||||
"pillar1Detail": "rootfs/\n(rsync di /etc,\n/etc/systemd/network,\n/root, più uno\nsnapshot sqlite3\ndi /var/lib/pve-cluster,\n+ percorsi opzionali)",
|
||||
"pillar2Label": "Manifesto",
|
||||
"pillar2Detail": "manifest.json\n(hardware, parametri\ndel kernel, rete,\nZFS, utenti, cron,\npool ZFS, archiviazione)",
|
||||
"pillar3Label": "Applicazioni",
|
||||
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(pacchetti APT manuali + programmi\ndi installazione ProxMenux con versioni)"
|
||||
},
|
||||
"restoreIsUniversal": {
|
||||
"heading": "Il ripristino riproduce l'host di origine, non l'archivio",
|
||||
"body": "Il ripristino di un backup ProxMenux non si limita ad estrarre il filesystem. Il flusso di ripristino legge il manifest per rilevare la deviazione tra l'origine e la destinazione (differenze hardware, rinomina della scheda NIC, versione del kernel, identità del pool ZFS), riproduce il file system, quindi attiva il programma di installazione del componente corretto per ogni servizio installato sull'origine (driver NVIDIA, Coral TPU, strumenti GPU AMD, strumenti Intel GPU). Ogni programma di installazione viene eseguito sul <strong>kernel corrente della destinazione</strong>, quindi l'host ripristinato non dipende dalla presenza del kernel di origine. Quando il kernel della destinazione è più recente di quello del backup, un passaggio di <strong>idratazione</strong> indipendente dal kernel unisce l'ottimizzazione dell'utente (token IOMMU, ID dispositivo VFIO, quirk personalizzati, chiavi GRUB) nella nuova configurazione di avvio della destinazione senza copiare testualmente i file legati al kernel."
|
||||
},
|
||||
"twoInterfaces": {
|
||||
"heading": "Due interfacce, un backend",
|
||||
"intro": "Ogni fase del flusso di lavoro di backup e ripristino è disponibile da due punti di ingresso. Entrambi chiamano la stessa libreria di shell, producono archivi identici e leggono lo stesso registro dei lavori.",
|
||||
"cliLabel": "ProxMenux Scripts (TUI)",
|
||||
"cliDetail": "menu → Utilità →\nBackup/Ripristino dell'host\n\nFlusso basato su dialoghi,\nSSH-friendly, scriptabile\nper uso non presidiato.",
|
||||
"webLabel": "ProxMenux Monitor (Web UI)",
|
||||
"webDetail": "Scheda Backups\nnell’interfaccia web di Monitor.\n\nRipristino con un clic, log\nin tempo reale, integrazione con\nle notifiche e il visualizzatore\ndelle differenze di rollback."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Dove andare da qui",
|
||||
"intro": "Ogni sottosezione seguente copre in modo approfondito un aspetto del flusso di lavoro. Inizia con <em>Come funziona</em> se l'obiettivo è capire cosa contiene l'archivio e perché. Vai a <em>Destinazioni</em> per configurare la destinazione per la copia. Leggi <em>Ripristino</em> e <em>Ripristino cross-kernel</em> per la parte di ripristino.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Come funziona",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "— i tre payload (rootfs, manifest, applicazioni) in dettaglio, con i raccoglitori che li producono e il formato di ciascun file."
|
||||
},
|
||||
{
|
||||
"label": "Destinazioni",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": " — confronto tra locale, Proxmox Backup Server (consigliato) e Borg e come configurarli."
|
||||
},
|
||||
{
|
||||
"label": "Creazione di backup",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": " — backup una tantum, profilo di percorso predefinito, aggiunta di percorsi personalizzati, crittografia per PBS."
|
||||
},
|
||||
{
|
||||
"label": "Lavori pianificati",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": " — nuovi lavori rispetto al collegamento a un lavoro vzdump PVE esistente, formati di pianificazione, finestra dei dettagli del lavoro."
|
||||
},
|
||||
{
|
||||
"label": "Ripristino",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — le tre azioni su un archivio (visualizzazione, download, ripristino), ripristino completo e personalizzato, il dispatcher post-avvio e perché gli ultimi dieci minuti sono importanti."
|
||||
},
|
||||
{
|
||||
"label": "Ripristino tra kernel",
|
||||
"href": "/docs/backup-restore/cross-kernel",
|
||||
"tail": " — comportamento che tiene conto della direzione del cambio di versione quando il kernel di destinazione è diverso da quello del backup, filtro del sottoinsieme sicuro e quattro fasi di idratazione."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Attività pianificate — timer, modalità di collegamento, conservazione | ProxMenux",
|
||||
"description": "Attività pianificate di backup dell’host ProxMenux. Due modalità di creazione (timer systemd dedicato o collegamento a un’attività vzdump PVE esistente), regole di conservazione applicate per attività tramite proxmox-backup-client, Borg o pulizia locale, file in /var/lib/proxmenux/backup-jobs e script di esecuzione che produce gli stessi archivi del flusso interattivo.",
|
||||
"ogTitle": "ProxMenux Backup — lavori programmati",
|
||||
"ogDescription": "Backup host programmati non presidiati con modalità di aggancio, ritenzione e le stesse tre destinazioni del flusso interattivo.",
|
||||
"twitterTitle": "Lavori programmati | ProxMenux",
|
||||
"twitterDescription": "Attività pianificate di backup dell’host senza intervento, con modalità di collegamento e conservazione."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lavori programmati",
|
||||
"description": "Lavori di backup incustoditi. Due modelli di creazione: un nuovo lavoro indipendente con il proprio programma, o un lavoro collegato ad un'attività PVE vzdump esistente che eredita il programma e la ritenzione di tale attività. Entrambi producono archivi identici al flusso interattivo.",
|
||||
"section": "Backup e ripristino"
|
||||
},
|
||||
"intro": {
|
||||
"title": "I due modelli di lavoro programmati",
|
||||
"body": "Un lavoro programmato può essere creato seguendo uno dei due modelli:",
|
||||
"modelsList": [
|
||||
"<strong>Nuovo lavoro indipendente</strong> — ProxMenux definisce il programma di lavoro stesso con il proprio timer systemd, indipendente da qualsiasi altra attività sull'host. Compatibile con tutte e tre le destinazioni: Locale, PBS e Borg.",
|
||||
"<strong>Collega a un’attività vzdump PVE esistente</strong> — l’attività non ha una pianificazione propria; viene eseguita automaticamente quando si attiva l’attività vzdump PVE principale che già esegue il backup di VM e LXC sull’host. Ne eredita pianificazione e conservazione. Compatibile con Locale e PBS (Borg non è supportato perché PVE non ha un pianificatore nativo per Borg)."
|
||||
]
|
||||
},
|
||||
"attachBadge": {
|
||||
"title": "Modalità di aggancio — consigliato quando esiste già un compito PVE vzdump",
|
||||
"body": "Se esiste già un’attività vzdump PVE per VM e LXC del nodo, collegare il backup dell’host lo fa eseguire dopo il backup dei guest, nello <strong>stesso ciclo di backup</strong>. Nel ripristino, le configurazioni dei guest provengono dal backup dell’host (in <code>/etc/pve</code>) e i dischi dai backup vzdump dello stesso ciclo. Questo aiuta a coordinare il recupero dell’intero nodo, ma non è uno snapshot atomico: modifiche durante il ciclo possono lasciare differenze tra configurazione dell’host e stato dei dischi dei guest."
|
||||
},
|
||||
"frequencyBadge": {
|
||||
"title": "Frequenza raccomandata",
|
||||
"body": "Per massimizzare la compatibilità tra backup dell’host e ripristino futuro, esegui backup frequenti. Più la copia è vicina allo stato attuale dell’host, meno differenze di configurazione, pacchetti e componenti dovrà riconciliare il ripristino."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Le due modalità",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Nuova attività pianificata",
|
||||
"backends": "Locale, PBS, Borg",
|
||||
"schedule": "Espressione <code>OnCalendar</code> propria (sintassi del calendario systemd, ad esempio <code>daily</code> o <code>Mon..Fri 03:00</code>).",
|
||||
"retention": "Richiesti separatamente: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applicato dallo script di esecuzione dopo ogni backup di successo."
|
||||
},
|
||||
{
|
||||
"mode": "Attaccare a un lavoro PVE vzdump",
|
||||
"backends": "Locale, PBS (Borg non ha pianificatore lato PVE)",
|
||||
"schedule": "Ereditata dall’attività PVE principale. Non viene installato alcun timer systemd sul lato ProxMenux.",
|
||||
"retention": "Ereditata dalla configurazione <code>prune-backups</code> dell’attività principale (mappata uno a uno alle variabili <code>KEEP_*</code> dello script di esecuzione tramite <code>hb_pve_prune_to_keep_env</code>)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"attachDetail": {
|
||||
"heading": "Come funziona la modalità di collegamento",
|
||||
"intro": "PVE scrive le attività <code>vzdump</code> in <code>/etc/pve/jobs.cfg</code>, con una sezione per attività che indica lo storage dei backup VM e LXC. La modalità di collegamento richiede un backend supportato da ProxMenux (Locale o PBS). Il backup dell’host parte dall’hook job-end dopo il completamento dell’attività di backup dei guest.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"detail": "Durante la creazione dell’attività, ProxMenux elenca le attività PVE genitoriali compatibili tramite <code>hb_pve_list_vzdump_jobs_for_backend</code>. L'utente ne sceglie uno."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"detail": "Il file <code>.env</code> dell’attività è scritto con <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> e i valori ereditati <code>KEEP_*</code>; non viene creato alcun timer systemd."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"detail": "<code>hb_install_vzdump_hook</code> registra un hook in <code>/etc/vzdump.conf</code>. Nella fase job-end di qualsiasi attività vzdump confronta il <code>$STOREID</code> ricevuto con il <code>PVE_STORAGE</code> di ogni attività collegata e abilitata, avviando lo script di esecuzione per quelle corrispondenti. Il confronto usa lo storage, non l’ID dell’attività principale selezionata."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"detail": "L’archivio viene salvato nello stesso storage dei backup vzdump: <code>path/dump/</code> per Locale oppure il repository PBS configurato nella voce di storage PVE."
|
||||
}
|
||||
],
|
||||
"outroBody": "La modalità di collegamento non ha un timer proprio. Disabilitare o eliminare l’attività PVE principale selezionata ferma quel trigger, ma un’altra attività vzdump sullo stesso storage può ancora avviare il backup dell’host. Per impedirlo, disabilita o elimina l’attività ProxMenux stessa. Se disabilitata, la voce resta su disco e può essere riabilitata o ricollegata."
|
||||
},
|
||||
"storageLayout": {
|
||||
"heading": "File che compongono un lavoro",
|
||||
"intro": "Ogni lavoro programmato è completamente descritto da tre o quattro file sul disco. Leggerli dà la configurazione completa del lavoro senza fare affidamento sull'interfaccia.",
|
||||
"rows": [
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
|
||||
"content": "Backend, ID di backup o destinazione, pianificazione (Nuova modalità) o genitore PVE (Modalità allegato), abilitato flag, ritenzione valori <code>KEEP_*</code>, puntatori di credenziali."
|
||||
},
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
|
||||
"content": "Un percorso assoluto per riga: la selezione ricavata dal profilo e fissata alla creazione dell’attività. Modificare il file fa usare la nuova selezione alla successiva attivazione del timer."
|
||||
},
|
||||
{
|
||||
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
|
||||
"content": "Solo modalità nuova attività. Il servizio invoca <code>run_scheduled_backup.sh JOB_ID</code>. Il timer lo programma con <code>Persistent=true</code> (esecuzioni saltate recuperate al prossimo avvio) e un piccolo <code>RandomizedDelaySec=120</code> per diffondere il carico quando più attività condividono la stessa espressione OnCalendar."
|
||||
},
|
||||
{
|
||||
"path": "/etc/vzdump.conf script-hook",
|
||||
"content": "Solo modalità di collegamento. Installato una volta da <code>hb_install_vzdump_hook</code>; confronta <code>PVE_STORAGE</code> di ogni attività collegata con <code>$STOREID</code>, passato da PVE allo script hook."
|
||||
}
|
||||
]
|
||||
},
|
||||
"runner": {
|
||||
"heading": "Cosa fa un’attività quando si avvia",
|
||||
"intro": "Ogni lavoro — se nuovo modello o allegato — esegue la stessa sequenza a tre fasi:",
|
||||
"steps": [
|
||||
"<strong>Prepara il backup.</strong> Legge la configurazione del lavoro (destinazione, profilo, percorsi) e assembla l'albero dell'archivio esattamente come fa il flusso interattivo. Il risultato è lo stesso archivio un backup manuale con quelle impostazioni produrrebbe.",
|
||||
"<strong>Scrivi nella destinazione.</strong> Carica o scrive l'archivio alla destinazione configurata — un file <code>.tar.zst</code> locale, un backup PBS o un archivio Borg — utilizzando esattamente gli stessi strumenti e le credenziali che un backup manuale alla stessa destinazione avrebbe utilizzato.",
|
||||
"<strong>Applica la conservazione.</strong> Rimuove i vecchi backup dalla destinazione, mantenendo i conti <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurati sul lavoro. La potatura viene eseguita dalla destinazione stessa: PBS applica la propria ritenzione, Borg esegue <code>borg prune</code>, e per Local ProxMenux elimina i file che cadono fuori dalla finestra <code>keep-last</code>."
|
||||
]
|
||||
},
|
||||
"management": {
|
||||
"heading": "Gestione dei lavori",
|
||||
"intro": "Il menu scheduler (Script TUI) e la scheda Monitor Backups espongono le stesse azioni su qualsiasi lavoro.",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Esegui ora",
|
||||
"detail": "Richiama subito lo script di esecuzione, senza attendere il timer o l’hook vzdump. Utile per verificare la configurazione senza aspettare la prossima esecuzione pianificata."
|
||||
},
|
||||
{
|
||||
"action": "Attivare / disattivare",
|
||||
"detail": "Nuova modalità: <code>systemctl enable/disable --now</code> il timer. Modalità di aggancio: cambia il flag <code>ENABLED</code> nel job env — lo script gancio lo onora alla prossima esecuzione PVE."
|
||||
},
|
||||
{
|
||||
"action": "Modifica",
|
||||
"detail": "Riapre le richieste di destinazione, pianificazione, profilo e ritenzione e riscrive i file di lavoro. Conserva l'ID del lavoro."
|
||||
},
|
||||
{
|
||||
"action": "Elimina",
|
||||
"detail": "Rimuove il job env, il file dei percorsi, il timer + servizio systemd (Nuova modalità), e disabilita il binding del gancio (Modalità allegato). Non tocca archivi già sulla destinazione."
|
||||
},
|
||||
{
|
||||
"action": "Visualizza log",
|
||||
"detail": "Mostra in tempo reale <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code>: un file di registro per esecuzione. Lo script di esecuzione emette anche una riga di stato compatta a journald sotto il servizio systemd."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Notifiche",
|
||||
"body": "Ogni esecuzione programmata genera gli stessi eventi <code>hb_notify_lifecycle</code> del flusso interattivo (<code>start</code>, <code>complete</code>, <code>fail</code>). Se i canali di notifica sono configurati nel Monitor, i lavori incustoditi mostrano i risultati come fanno i backup manuali — un utente non ha bisogno di controllare il registro per sapere se un lavoro è riuscito."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Dove andare dopo",
|
||||
"items": [
|
||||
{
|
||||
"label": "Creazione di backup",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "— il flusso interattivo che condivide il backend con il pianificatore."
|
||||
},
|
||||
{
|
||||
"label": "Destinazioni",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— configurazione per-backend utilizzata sia dal flusso interattivo che dal pianificatore."
|
||||
},
|
||||
{
|
||||
"label": "Ripristino",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — il flusso che utilizza i backup prodotti dalle attività."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user