mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
docs: review backup and restore documentation in all seven translations
This commit is contained in:
Jonatan
@@ -0,0 +1,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."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user