Funzionalità

BombVault è semplice di default e profondo quando serve. L'interfaccia mostra solo l'essenziale finché non attivi l'interruttore Vista semplice / Vista avanzata. Questa pagina raggruppa l'insieme completo delle funzionalità.

Ambito del backup

I contenitori, ciascuno con il proprio interruttore di pianificazione, ordine di backup e cronologia.

Cosa	Cosa viene salvato
Container Docker	La directory appdata più la definizione del container (immagine, variabili d'ambiente, porte, label, volumi). Di default l'intera directory appdata; Scegli le cartelle sul container spunta esattamente le cartelle coperte dal backup, con un conteggio in tempo reale dei percorsi, un elenco di ciò che hai lasciato fuori e un interruttore Salta le cartelle di cache per ogni radice (CACHEDIR.TAG).
VM KVM / libvirt	L'immagine (o le immagini) disco della VM, la definizione XML e la NVRAM UEFI (spegnimento ordinato o snapshot a caldo, via SSH). Gli snapshot a caldo ripiegano automaticamente su un backup ordinato se lo snapshot non può essere creato, così un backup di VM non va mai semplicemente in errore. Con Solo blocchi modificati attivo, una VM in esecuzione con dischi qcow2 viene letta tramite i checkpoint di libvirt, quindi un backup legge solo i blocchi scritti dal precedente, e ogni snapshot ripristina comunque da solo l'intero disco. I dischi su zvol ZFS vengono trasferiti con zfs send sullo stesso collegamento SSH, così una VM i cui dischi sono zvol viene salvata come un'unica VM. Lo stato di un vTPM in passthrough viene salvato accanto alla NVRAM quando l'XML del dominio ne indica il percorso. Un vTPM emulato, che TrueNAS configura per i guest Windows 11, non pubblica quel percorso, quindi tieni a portata di mano la chiave di ripristino di un guest del genere. Vedi la guida al backup delle VM.
Flash Unraid	L'intera chiavetta USB flash (/boot): SO, licenza, configurazione dell'array, condivisioni, rete e configurazione dei plugin. Il ripristino è un download .zip con un clic e non sovrascrive mai il flash in esecuzione.
Configurazione dell'app	Il /config di BombVault stesso (database delle impostazioni, credenziali off-site, coppia di chiavi SSH di libvirt), di cui viene fatto uno snapshot con VACUUM INTO di SQLite così che un database in modalità WAL non venga mai catturato durante una scrittura. Ripristinato tramite un auto-riavvio, così il database in esecuzione non viene mai sovrascritto sotto un handle aperto.
File e cartelle	Set di file con nome: qualsiasi cartella sul server (una condivisione, i tuoi documenti, una libreria di foto), ciascuno con pattern di esclusione opzionali per set. Piena parità con gli altri domini (calendari, conservazione, copia off-site, controlli di integrità ed esercitazioni di ripristino).
Dataset ZFS	Un dataset insieme a tutti i dataset sottostanti, letto da un unico snapshot ZFS così che provengano tutti dallo stesso istante, e salvato con restic come una cartella: deduplicato, navigabile, con ripristino dei singoli file. I nuovi dataset figli entrano da soli, si possono escludere singolarmente, e uno che non si può leggere viene saltato e indicato per nome. Se vuoi, alcuni container vengono fermati o un comando viene eseguito solo per l'istante dello snapshot. I volumi non sono inclusi: il volume di una VM viene salvato con la sua VM, un volume senza VM non viene ancora salvato. Vedi Dataset ZFS.

Ripristino

Il ripristino guidato porta un'installazione nuova attraverso il caso disastro, in un unico posto.

• Ripristino completo con un clic. Scegli uno snapshot, clicca Ripristina. Fatto.
• Una cronologia unica per elemento. Container, VM, set di file, la flash e la configurazione dell'app elencano i propri backup come un'unica cronologia su ogni luogo in cui si trovano, il repository su cui vengono scritti e ogni destinazione off-site. Un backup copiato off-site compare una sola volta, contrassegnato con ogni luogo. I luoghi off-site vengono letti quando li apri, ed eliminare in un luogo dice se era l'ultima copia.
• I container vengono reinstallati automaticamente. La definizione del container viene rieseguita contro l'API Docker, così il container riappare nella scheda Docker di Unraid esattamente com'era.
• GPU, limiti e link tornano. Un container ripristinato riottiene i suoi limiti di risorse, il driver dei log, le impostazioni DNS, i vecchi link e la sua GPU o il suo runtime (--gpus, --runtime=nvidia). Su un host senza quel driver GPU o quel runtime, il ripristino lo dice e offre Ripristina senza GPU e runtime, anche dopo il ripristino di più container o di uno stack. Un link a un container mancante, o fermo quando parte quello ripristinato, viene tralasciato, e la cronologia delle esecuzioni lo indica.
• Le VM vengono ricreate automaticamente. L'XML viene reimportato via SSH così la VM riappare nel VM Manager con il suo disco e la NVRAM UEFI ricollegati, anche dopo che la VM è stata eliminata. Scopri backup ricostruisce una voce che è del tutto scomparsa (per esempio dopo un'installazione pulita).
• Ripristino individuale. Ripristina un container, una VM o un set di file senza toccare gli altri.
• Il ripristino del flash è un download .zip. Viene trasmesso al tuo browser come flash-<id>.zip, pronto per essere depositato nel creatore USB di Unraid. Il /boot in esecuzione non viene mai toccato.
• Un plugin alla volta. La pagina Flash elenca i plugin di ogni backup del flash con versione e dimensione, e rimette un singolo plugin nella chiavetta in uso: il suo file .plg, la sua cartella in config/plugins e i file dei pacchetti presenti nel backup. Nient'altro cambia sulla chiavetta. Unraid installa il plugin al prossimo avvio, oppure subito da Plugins, Install Plugin.
• Esportazione zip del flash pianificata. Dopo ogni backup del flash, puoi facoltativamente scrivere lo snapshot come semplice .zip in una cartella a tua scelta (un unico flash-latest.zip sovrascritto o una cronologia a rotazione). Puntala a una cartella Syncthing o rclone così il tuo backup della USB avviabile lascia il server automaticamente.
• Verifica dei conflitti pre-volo. Prima che qualcosa venga fermato o rimosso, il ripristino verifica che l'IP statico del container e le porte host pubblicate siano liberi, e si interrompe con un messaggio chiaro invece di lasciare un ripristino a metà.
• Controlli prima del ripristino. Ogni finestra di ripristino controlla prima che il repository risponda, che la chiave salvata lo apra, che il punto di ripristino esista e che la destinazione abbia spazio per ciò che il ripristino scrive. Avvia resta bloccato finché un controllo fallisce, e la (i) nel pulsante dice quale.
• Piano di ripristino. Prima della conferma, la finestra mostra cosa fa il ripristino rispetto allo stato attuale: file nuovi, sostituiti e invariati, con l'elenco su richiesta, e i file della destinazione che non sono nel backup e restano dove sono. Per container e VM confronta anche le impostazioni ricreate con quelle in uso: immagine e tag, porte, nomi delle variabili e volumi, oppure memoria, vCPU, dischi e rete. restic lo calcola con una simulazione su dimensione e data di modifica, senza leggere i file; un albero molto grande si ferma dopo 30 secondi e lo dice. Il ripristino di uno stack controlla e pianifica ogni membro e nomina quello che lo blocca.
• Cartelle condivise. Un ripristino sul posto nomina ogni altro container, in esecuzione o no, il cui mount raggiunge una cartella in cui scrive, per esempio "questo percorso è usato anche da nextcloud-db". Avvisa e non blocca.
• Ripristino a livello di file. Espandi i File di uno snapshot di container, filtra, spunta un numero qualsiasi di file e cartelle, poi ripristina la selezione nella posizione originale o in una cartella a tua scelta.
• Ripristino di set di file. Ripristina uno snapshot di un set di file nella posizione originale (dopo una conferma esplicita) o in una cartella a tua scelta, mai in silenzio. Anche qui funziona il ripristino selettivo.
• Ripristino di un dataset ZFS. Ripristina un dataset di un elemento al suo posto (dopo uno snapshot ZFS di sicurezza che resta finché non lo elimini), in una cartella o solo i file che scegli, oppure tutti i dataset di un backup in una cartella. Un dataset non viene mai riportato indietro con un rollback né sostituito.
• Il ripristino mantiene lo stato di esecuzione. Un container o una VM che era in esecuzione al momento del backup torna in esecuzione; uno che era fermo resta fermo. Spunta Lascia fermo dopo il ripristino per ricreare senza avviare.
• Ripristino di un intero stack. I container dello stesso progetto Docker Compose vengono raggruppati in un pannello Stack. Ripristina stack… ricostruisce ogni membro dal suo ultimo backup lasciato fermo, poi facoltativamente li avvia in ordine depends_on.
• Progresso dal vivo, annullamento e feedback di occupazione. Un ripristino lungo mostra una barra di percentuale dal vivo e può essere annullato con una conferma consapevole del tipo. Un ripristino annullato viene registrato come annullato, non fallito.
• Ripristino guidato. Una scheda Ripristino dedicata accompagna un'installazione pulita attraverso il caso di disastro. Vedi Off-site e ripristino.
• Ripristino da un altro repo BombVault. Una sessione monouso e in sola lettura apre il repo di un'altra istanza BombVault con l'APP_KEY di quell'istanza, così puoi estrarre un container dal server A al server B senza toccare le tue impostazioni. Vedi Off-site e ripristino.
• Le proprietà ZFS tornano. Ogni backup ZFS conserva le proprietà impostate localmente di ogni dataset, come compressione, dimensione del record, quota e sensibilità alle maiuscole. Un ripristino in un nuovo dataset lo crea con queste, e un ripristino in un dataset esistente le mostra e le imposta solo se lo chiedi. Vedi Dataset ZFS.
• Importa dal plugin Appdata.Backup. Nella pagina Ripristino indica a BombVault la cartella di backup del plugin. Ogni archivio di container diventa un punto di ripristino del suo container, con la data in cui il plugin l'ha creato. Gli archivi già importati vengono saltati e gli archivi stessi vengono solo letti. Il container ha bisogno prima di un backup in BombVault, così il ripristino ha la sua definizione. La conservazione non tocca i punti di ripristino importati, quindi elimina tu quello che non ti serve più.

Archiviazione e pianificazione

• Backup incrementali e deduplicati tramite restic, così anche i dischi VM di grandi dimensioni non gonfiano il repo.
• Destinazioni: un percorso locale, oppure off-site. Condivisioni SMB e server WebDAV (Nextcloud, ownCloud, SharePoint) direttamente da un modulo in Impostazioni, Accesso cloud, rclone, senza mount sull'host; NFS (monta l'export su Unraid e puntaci un Percorso di backup); backend restic nativi senza rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), o qualsiasi remote rclone tramite rclone:<remote>:<bucket>/path. Tutte le credenziali vengono memorizzate cifrate.
• Le destinazioni SSH non richiedono nulla di installato sull'altro lato. sftp: richiede solo un server SSH, così un semplice Raspberry Pi (senza Docker, senza restic) funziona come destinazione off-site. Le chiavi host vengono fissate automaticamente al primo contatto.
• Copia off-site (locale + remota). Mantieni il backup locale veloce e aggiungi una o più repliche off-site, replicate con restic copy su base best-effort (un intoppo off-site non fa mai fallire il backup locale). Ogni dominio ha il proprio calendario off-site, più un pulsante Replica ora.
• Più destinazioni off-site per dominio. Ogni dominio (container, VM, flash, config, set di file e dataset ZFS) può replicare verso più destinazioni off-site contemporaneamente, non solo una. Aggiungi destinazioni extra nella pagina Off-site, ciascuna con il proprio repository, classe di archiviazione S3, flag append-only, conservazione e budget di crescita. La tua copia off-site esistente viene riportata come prima destinazione, così nulla cambia finché non ne aggiungi una seconda, e ogni destinazione di un dominio replica secondo il calendario off-site di quel dominio.
• Repository con nome. Annota una volta sola le tue posizioni di backup in Impostazioni, Archiviazione, Repository, un percorso locale o qualsiasi remote restic con il proprio set di credenziali, poi scegline uno come posizione di un elemento sulla sua scheda. Ogni riga mostra quanti elementi puntano a quel repository, e un repository usato da un elemento o da una collocazione predefinita non può essere spostato né eliminato, perché BombVault non sposta mai un backup già scritto.
• Più set di credenziali cloud. Le credenziali cloud condivise valgono ovunque di default, ma qualsiasi destinazione può scegliere invece un set di credenziali con nome (Impostazioni, Accesso cloud, Set di credenziali aggiuntivi), così un bucket S3 di Hetzner e un server Garage locale possono funzionare fianco a fianco, ciascuno con la propria chiave. Questo vale anche per le destinazioni off-site e per un percorso di backup che è a sua volta un repository remoto.
• Destinazioni. Una destinazione off-site si imposta una sola volta, con una procedura guidata che elenca i servizi di archiviazione S3, il tuo server S3, il tuo server e le condivisioni, e ogni storage cloud supportato da rclone, con l'accesso, una prova di connessione, un selettore di cartelle e una parola sincera sulla protezione dall'eliminazione. Compare poi come pulsante su ogni dominio e su ogni elemento. Vedi Destinazioni.
• Collocazione per elemento. Ogni scheda di container, VM e set di file ha una riga di pulsanti, Locale e uno per ogni destinazione off-site, e quelli accesi ricevono i suoi backup. Una condivisione che vive già su un NAS non deve più andare anche su B2. La posizione è fissa dal primo backup in poi, le copie possono cambiare in qualsiasi momento, e la scheda indica quante sedi custodiscono l'elemento e se il 3-2-1 è rispettato. Vedi Collocazione per elemento.
• Collocazioni predefinite. Una riga per dominio imposta dove vengono scritti i nuovi elementi e su quali destinazioni vengono copiati gli elementi senza una scelta propria. Cambiarla non sposta nessun backup e indica in anticipo quali destinazioni guadagnano o perdono elementi.
• Ordine di backup manuale. Imposta l'ordine esatto in cui i tuoi container vengono sottoposti a backup dal pannello ordine di backup nella pagina Container. Le esecuzioni pianificate e a selezione multipla lo seguono; qualsiasi container che lasci non ordinato mantiene il precedente comportamento dal più in ritardo per primo, e un backup di un singolo container è invariato.
• Conservazione configurabile: keep-last / giornalieri / settimanali / mensili / annuali, potati automaticamente dopo ogni backup, impostati per sorgente (sia locale che off-site su Impostazioni, Conservazione, così puoi conservare le copie off-site più a lungo come archivio). Ogni origine può anche seguire regole proprie, in locale e off-site (Regole di conservazione per origine), per esempio 7 backup giornalieri per i container che cambiano ogni giorno e meno per le VM che cambiano di rado.
• Compressione per repository: Disattivato, Automatico (il valore predefinito di restic) o Massimo, impostabile in Impostazioni, Archiviazione per ogni percorso di backup e ogni repository con nome, e in Impostazioni, Off-site per ogni destinazione off-site. Backup, copie off-site e potatura scrivono con essa, e il kit di ripristino la riporta, così restic da solo può continuare a scrivere allo stesso modo.
• Pianificazione per dominio (giornaliera / settimanale inclusi set multi-giorno / ogni-N-giorni / cron grezzo), tutto modificato in un unico posto su Impostazioni, Pianificazioni. Un singolo container, VM, set di file o elemento ZFS può avere una cadenza propria, e Ogni N giorni funziona anche per l'esercitazione di ripristino, il tamper test e il riepilogo settimanale.
• Attendi che l'app sia inattiva. Un container può far attendere il suo backup pianificato finché la sua app è occupata, al massimo per le ore che imposti, e avviarlo appena l'app è inattiva. Un media server è inattivo quando non trasmette, ogni altro container quando CPU e traffico restano per qualche minuto sotto i limiti di Impostazioni, Pianificazioni (sulla rete dell'host conta solo la CPU). Il backup in attesa compare nel registro attività e sul container con motivo e scadenza. Non tiene alcun blocco, quindi gli altri container proseguono. I backup manuali non aspettano mai. I membri di uno stack compose previsti nella stessa esecuzione attendono insieme, e un'attesa prosegue con la sua scadenza dopo un riavvio. Spegnere i container annulla tutti i backup in attesa, e spegnere la loro pianificazione annulla quelli trattenuti dalle sue esecuzioni. Ridurre le ore accorcia anche un'attesa già iniziata.
• Limiti di banda off-site. Limita la velocità di upload/download di restic così la replica non satura la tua WAN.
• Prima lo streaming. Mentre un media server come Plex, Jellyfin o Emby trasmette, le copie off-site caricano con un limite più basso e tornano a quello normale qualche minuto dopo la fine dello stream. BombVault legge da Docker il traffico in uscita dei media server. REST, S3, B2, Azure, Google Cloud, Swift e rclone su HTTP rallentano a metà copia; SFTP e le cartelle locali o montate prendono il limite basso al passaggio di copia successivo. Un media server sulla rete dell'host non si può misurare. In Impostazioni, Off-site.
• Classe di archiviazione fredda e d'archivio (S3). Per un repo off-site S3 nativo puoi scegliere la classe di archiviazione, ristretta ai livelli leggibili in ripristino (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval) così i prezzi d'archivio non compromettono mai silenziosamente un ripristino. I livelli deep-archive che richiedono prima uno scongelamento asincrono (Glacier Flexible, Deep Archive) sono intenzionalmente esclusi. Solo backend S3 nativi; i remote rclone impostano la loro classe nella configurazione rclone.
• Le cartelle di backup restano copiabili fuori dalla macchina. Dopo ogni backup BombVault rilassa l'albero del repo locale a dir 0755 / file 0644 (i repo sono cifrati, quindi nulla è esposto) così un utente di sincronizzazione non-root via SMB non resta escluso. Le definizioni di ripristino risiedono dentro ogni repo, così una cartella di repo copiata è completamente autonoma.

Insight, verifica e monitoraggio

• Pausa dalla scheda. Ogni scheda di container, VM e set di cartelle ha Sospendi pianificazione, che toglie l'elemento dal calendario e da Backup totale, e Riprendi pianificazione per rimetterlo. Imposta lo stesso interruttore di Includi nel calendario, quindi i due concordano sempre. Un elemento in pausa porta un badge grigio Pianificazione sospesa, e Esegui backup ora continua a funzionare.
• Stato di protezione (RPO). La Dashboard mostra un indicatore verde / ambra / rosso per dominio, confrontando l'ultimo backup riuscito con il suo calendario, così un backup in ritardo diventa rosso invece di nascondersi in un log.
• Heatmap della salute dei backup. Un calendario in stile contributi GitHub degli esiti dei backup per giorno e per dominio, con un interruttore Container / VM / Flash / Auto-backup / Cartelle.
• Tempi di esecuzione ovunque. Ogni voce della cronologia esecuzioni riporta inizio, fine (durata), e ogni container e VM porta il proprio elenco Esecuzioni recenti sulla sua pagina.
• Una dashboard che puoi riorganizzare. Attiva la modalità di personalizzazione per trascinare le schede nell'ordine che vuoi e nascondere quelle che non ti servono. Il layout viene salvato per browser.
• Dimensione del repository e trend di dedup. Dimensione attuale del repo, rapporto di deduplicazione e conteggio degli snapshot per dominio, con una sparkline della crescita dell'archiviazione.
• Esercitazioni di verifica del ripristino. BombVault dimostra periodicamente che i tuoi backup sono ripristinabili (restic check --read-data-subset, limitato) e mostra un badge Ripristinabilità verificata per dominio.
• Controllo di ripristino dopo il primo backup. Quando il primo backup di un elemento è concluso, BombVault ne ripristina un campione (fino a 100 file e 256 MiB) in una cartella temporanea dentro la cartella di ripristino, fa rileggere a restic ogni file rispetto ai suoi hash e confronta le dimensioni con il backup. Di un file troppo grande per il campione, come un disco VM, vengono riletti invece i primi 64 MiB. La scheda dell'elemento mostra il risultato, un errore arriva come notifica e Verifica ripristino esegue lo stesso controllo sul backup più recente quando vuoi. I backup successivi non lo ripetono.
• Test di avvio. Controllare i byte non dimostra che l'app riparta. Test di avvio sulla scheda di un container ripristina il backup più recente in una copia isolata e la avvia: un nome che inizia con bombvault-test-, una rete Docker interna propria senza porte pubblicate né accesso alla LAN, 1 CPU e 2 GiB di memoria, e i dati in una cartella temporanea dentro la cartella di ripristino. Il test è superato quando l'healthcheck del container segnala sano, senza healthcheck quando la sua prima porta esposta risponde dall'interno di quella rete, e senza nessuno dei due quando resta in esecuzione. Il container originale non viene mai fermato né modificato, e copia, rete e dati vengono rimossi dopo, anche se BombVault si riavvia a metà test. I container sulla rete dell'host, privilegiati, con dispositivi o che dipendono da un altro container sono indicati come non testabili. Attiva Test di avvio nei controlli di ripristino pianificati per testare un container a ogni esecuzione, partendo da quello testato meno di recente. Il risultato compare sulla scheda e nella dashboard. La copia non porta nessuna etichetta dell'originale e gira senza le capabilities, le opzioni di sicurezza, i sysctl e il cgroup parent che l'originale aggiunge. Un container che ne ha bisogno non supera il test, e il risultato dice senza cosa è girata la copia.
• Operazioni auto-riparanti. Un lock restic dimostrabilmente orfano (lasciato da un riavvio a metà operazione) viene forzatamente rimosso e ritentato una volta, automaticamente. La conservazione è stabile per identità (potata per elemento, immune ai cambi di percorso o host) e un fallimento della conservazione invia una notifica.
• Avvisi che la scansione delle cartelle non vede. L'assistente per le esclusioni risponde a una domanda di dimensioni. Alcuni degli errori di backup più costosi non sono domande di dimensioni, quindi porta anche avvertenze specifiche per applicazione su come un'app conserva i propri dati. Quella per cui esiste: Immich tiene album, volti e date di ogni foto in un database PostgreSQL che gira in un container separato, così un backup a livello di file del container di Immich ripristina le immagini senza nulla di tutto questo, e il ripristino sembra riuscito. L'avviso compare che venga offerta un'esclusione o no, anche su un container senza nulla selezionato da scansionare, perché l'avvertenza vale in ogni caso.
• Senza backup (copertura). Una scheda della Dashboard che nomina tutto ciò che sul server non è coperto da nessun backup automatico, con il motivo per ciascuno: mai aggiunto a BombVault, presente ma non incluso nella pianificazione, con la propria pianificazione disattivata, o nessuna pianificazione attiva da nessuna parte. L'indicatore di protezione sopra risponde a un'altra domanda, cioè se i backup che sono pianificati sono partiti in tempo, e non può vedere il container che nessuno ha mai configurato: quello manca da ogni elenco e da ogni errore, quindi per lui non diventa ambra nulla. I container vengono letti dall'elenco Docker in tempo reale anziché dalle righe di BombVault stesso, perché un elemento senza riga è proprio quello da nominare. Un tipo di backup che hai disattivato resta del tutto fuori dal conteggio, dato che è stata una tua scelta.
• Anteprima della conservazione. Il pannello accanto alle impostazioni di conservazione mostra cosa la prossima esecuzione sta per eliminare, prima che succeda: per repository e per elemento, con i punti di ripristino nominati. Non prende nessun lock sul repository e non cambia nulla, quindi risponde anche mentre un backup è in corso. Una conservazione disattivata lo dice invece di mostrare un elenco vuoto, un repository append-only è indicato come tale (lì la conservazione non gira mai), e un repository non raggiungibile viene nominato invece di mancare in silenzio. In Impostazioni, Conservazione sia per la policy locale sia per quella off-site, ciascuna con la propria anteprima.
• Anomalie. Ogni backup di un container, di una VM, di un set di cartelle, di un dump di database, della chiavetta flash e dell'auto-backup viene confrontato con la cronologia propria di quell'elemento. I controlli guardano i nuovi dati di un'esecuzione, rispetto alle quantità abituali più grandi dei backup recenti e al ritmo orario abituale; un backup che ha salvato di nuovo la maggior parte dei dati, compresi file rinominati e riscritti; la dimensione della sorgente e il numero di file che restic riporta per ogni elemento e ogni dump; il tempo di backup di restic stesso; serie di errori ed errori intermittenti; controlli di ripristino che non passano più; e lo spazio libero dei repository locali, SFTP e rclone, proiettato dalla crescita del repository. Un elemento impara dai suoi primi 10 backup, mentre una sorgente quasi vuota, la riscrittura della maggior parte dei dati e gli errori sono controllati fin dall'inizio. All'aggiornamento la cronologia viene letta una volta dai riepiloghi degli snapshot che restic 0.17 conserva, così un'installazione esistente non parte da zero. La sensibilità (Rigorosa, Equilibrata, Permissiva) e la gravità minima che invia una notifica si impostano globalmente in Impostazioni, Integrità e si possono cambiare per elemento. Gli avvisi si chiudono da soli quando la causa sparisce; i rilevamenti critici su dati persi e su un disco che si riempie restano finché non li confermi, e un rilevamento confermato non viene segnalato di nuovo finché la sua causa non è sparita almeno una volta. Segna come attesa rende normale un nuovo livello dopo 10 backup, ma non disattiva mai il controllo della sorgente quasi vuota, e una selezione cambiata fa ripartire da sola la cronologia dell'elemento. Finché una sorgente è quasi vuota, si è ridotta molto o un backup ha salvato di nuovo la maggior parte dei dati, la conservazione tiene i vecchi backup di quell'elemento finché non confermi il rilevamento o lo segni come previsto, e il rilevamento rimanda all'ultimo backup buono. Una notifica parte una volta per episodio, e gli errori e i controlli di ripristino che notificano già non vengono segnalati due volte. Cosa non fa: i repository S3, B2 e REST non hanno un dato di spazio libero, sulla condivisione utente di Unraid lo spazio libero è quello dell'intero array, e i backup precedenti a restic 0.17 non hanno una cronologia delle dimensioni. Anche gli elementi ZFS vengono controllati, dataset per dataset: ogni dataset di un albero ha la propria cronologia, uno che è stato svuotato o non si è più potuto leggere conta come perdita di dati, e si conservano solo i vecchi backup di quel dataset. Come un elemento ZFS viene sorvegliato dataset per dataset è descritto in Dataset ZFS, e un assistente può leggere le anomalie aperte tramite il server MCP. Una segnalazione sulla dimensione o sul numero di file di un'origine viene datata al primo backup in cui è comparsa, e Confronta con il backup precedente elenca le cartelle in cui dei file sono spariti, arrivati o cambiati, con una nota quando quasi tutto si trova in un indice di ricerca, una cache o delle miniature che l'app ricostruisce da sola.
• Esclusioni consigliate per app. Per le immagini note (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism e Tautulli, di linuxserver, hotio, binhex o dell'editore ufficiale) l'Assistente esclusioni propone le cartelle che l'app riempie di nuovo da sola: cache, log, immagini di anteprima e poster. Ogni voce dice cosa contiene, ognuna si può disattivare e nulla viene escluso finché non premi Escludi selezionati.
• Pacchetto di supporto. Uno ZIP ripulito, con un clic, per una segnalazione di bug: il controllo dell'integrazione con l'host, la tua configurazione con ogni segreto rimosso, le esecuzioni recenti, cosa è pianificato dopo e il log recente. Contiene anche com'è andato l'ultimo dump di ogni database, gli elementi ZFS con i mount che vede il container, le anomalie aperte e quante chiavi MCP esistono (mai i loro nomi). Password, token, la configurazione rclone, le credenziali di notifica e qualsiasi password inserita nella posizione di un repository vengono tolti, e il pacchetto lo dice nel proprio manifest, perché un file di supporto non deve mai essere scambiato per un backup della configurazione. Richiede una password di accesso per lo stesso motivo del kit di ripristino. Il log che contiene è l'output di questo container dal suo ultimo avvio; per un crash che ha riavviato il container, il posto dove guardare resta docker logs.
• Kit di ripristino della chiave di crittografia. Download con un clic della chiave master, della password restic derivata e delle posizioni e comandi esatti del repo, così puoi ripristinare senza un BombVault in esecuzione. Vedi Off-site e ripristino.
• Esporta e importa le tue impostazioni. Una scheda Esporta / importa impostazioni nella pagina Impostazioni, Sistema scrive l'intera configurazione (impostazioni di dominio, destinazioni off-site, calendari, conservazione, notifiche) in un file JSON portatile, così passare a una nuova macchina o clonare una configurazione non significa reinserire tutto a mano. Scegli tu se includere le credenziali off-site e di notifica; con esse il file è sensibile quanto il tuo kit di ripristino. L'importazione mostra un'anteprima e chiede conferma, e non tocca mai i tuoi dati di backup o la cronologia.
• Notifiche. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, email (SMTP), un server Apprise API self-hosted, e il sistema di notifiche nativo di Unraid. Policy per backup: mai / in caso di errore / sempre. Un'esecuzione pianificata di molti elementi può inviare un unico riepilogo N di M riusciti. Healthchecks riceve l'intero ciclo di vita (/start, poi successo o /fail) ogni volta che è impostato un URL.
• Riepilogo settimanale. Un messaggio a settimana tramite gli stessi canali: numero di esecuzioni, quanti nuovi dati di backup sono arrivati, se l'off-site è aggiornato e i fallimenti principali. Disattivato di default, con una cadenza propria in Impostazioni, Notifiche, così anche una settimana tranquilla viene segnalata.
• Prometheus /metrics. Opt-in (disattivato di default, bearer token opzionale) per Grafana o Uptime Kuma. Espone stato dei backup, dimensioni e timestamp, senza segreti o percorsi nelle label.
• API HTTP, Home Assistant e mDNS. Script e dashboard hanno un'API sotto /api/v1 con token con nome, in sola lettura o autorizzati ad avviare backup. Home Assistant trova BombVault tramite la discovery MQTT, come dispositivo con sensori e, se lo consenti, un pulsante di backup per dominio. Inoltre BombVault si annuncia in rete come bombvault.local. Vedi API e integrazioni.
• Spazio libero e settimane all'esaurimento. I repository locali, i repository SFTP e le destinazioni SMB o WebDAV che lo comunicano mostrano lo spazio libero e quante settimane restano al ritmo di crescita attuale. I repository S3, B2 e REST indicano "Spazio libero sconosciuto", perché quei backend non lo comunicano.
• Dimensione per cartella. Nella sezione Backup di un container, di una VM o di un insieme di cartelle, Dimensione per cartella mostra quali cartelle e file occupano spazio nel backup più recente e quanto ne ha portato di nuovo o modificato l'ultimo backup, un livello alla volta. BombVault lo legge dall'indice del repository senza leggere i file e, dopo che l'hai aperto una volta, lo aggiorna dopo ogni backup.
• Perché un backup è stato lento. Durante un backup BombVault osserva quanto sono occupati CPU, dischi e rete. Quando un backup dura molto più del solito e una sola cosa era chiaramente al limite, l'esecuzione lo dice, per esempio "Il disco di destinazione disk1 era occupato al 98%" o "BombVault ha usato il 100% del limite di CPU del suo container". Altrimenti non dice nulla.
• Modificato dall'ultimo backup. Un container ricreato con un'altra immagine, altre porte, variabili o volumi dal suo ultimo backup riceve un segno accanto al nome. Il suo (i) elenca cosa è cambiato, le variabili solo per nome. È solo una nota e scompare con il backup successivo.

Protezione dal ransomware

• Off-site immutabile (append-only). Contrassegna un repo off-site come append-only così ransomware o un host compromesso non possano eliminare o riscrivere i tuoi backup. L'altro lato (un restic/rest-server in modalità --append-only) lo impone; BombVault lo verifica soltanto e non mostra mai verde sulla sola affermazione di una configurazione.
• Tamper test. BombVault dimostra periodicamente la garanzia append-only tentando effettivamente un'eliminazione contro il repo off-site (mirata a un oggetto inesistente): rifiutata significa protetto, accettata significa non protetto. Un risultato inconcludente non ribalta mai il verdetto memorizzato.
• Configurazione off-site guidata. Una procedura guidata ti accompagna dalla scelta del backend attraverso uno snippet di deploy del rest-server pronto da incollare, un test di connessione, l'interruttore immutabile e una strategia di conservazione.
• Esercitazioni DR (off-site). Ripristina una destinazione reale dal repo off-site in una sandbox usa e getta, verificala file per file e byte per byte, poi ripulisci. Vedi Off-site e ripristino.
• Scorecard della protezione dal ransomware. Una scheda della Dashboard con una postura verde / ambra / rossa per dominio e una checklist con marca temporale; ogni riga rossa collega direttamente alla soluzione. Diventa verde solo su fatti verificati.
• Allarme del budget di crescita. Per un off-site immutabile (dove i vecchi snapshot non vengono deliberatamente mai potati), imposta un budget di dimensione e ricevi un avviso prima che sfugga di mano.
• Associazione tramite frase. Le istanze si uniscono a un unico gruppo con dodici parole: crea la frase su una, digitala sulla successiva. I membri sulla stessa rete si parlano direttamente, gli altri passano da un relay (il relay del progetto, il tuo, o nessuno), e ogni chiamata tra loro è cifrata end-to-end. Il gruppo porta le scorecard della pagina Istanze, le offerte di storage fuori sede del Mesh e ciò di cui un Ricevitore o una fonte di Prelievo ha bisogno, mai i dati di backup e mai l'APP_KEY. Vedi Off-site e ripristino.
• Pagina Istanze. Attiva Istanze nelle Impostazioni per avere una pagina con una scheda per ogni istanza del tuo gruppo, compresa questa: il suo indirizzo, se è connessa e lo stato di protezione di ogni dominio con il suo ultimo backup, con lo stesso rosso, ambra e verde della Dashboard locale. Controlla ora chiede a un membro di verificare il repository di un dominio. Niente in questa pagina può avviare un backup, ripristinare o eliminare qualcosa su un'altra macchina.
• Mesh off-site. Un membro può offrire il proprio storage off-site a un altro membro tramite il gruppo. L'amministratore dell'altra istanza vede l'offerta nella pagina Istanze e la accetta o la rifiuta; accettarla crea un normale set di credenziali e una normale destinazione off-site. Per questa via passano solo i dati di connessione, mai i dati di backup.
• Dashboard ricevente (lato ricevente). Sulla macchina che riceve copie off-site immutabili da un altro BombVault, attiva l'interruttore Ricevitore (Impostazioni) per rivelare una scheda Ricevitore. Registra un repository ricevuto in sola lettura (aperto con la password restic dell'istanza mittente, che arriva tramite il gruppo di associazione) per vedere il suo inventario di snapshot raggruppato per sorgente, quando ogni sorgente è arrivata l'ultima volta, ed eseguire un restic check indipendente sull'hardware ricevente. Ti avvisa quando una sorgente smette di inviare entro una finestra che imposti (un dead-man's switch) o quando un controllo di integrità fallisce. Rigorosamente in sola lettura, così non scrive mai nel repository ricevuto, e disattivato di default. Vedi Off-site e ripristino.
• Prelievo da un'altra istanza (lato prelievo). L'immagine speculare della replica off-site: invece che questa macchina spinga fuori i propri snapshot, tira dentro quelli di qualcun altro. Attiva l'interruttore Prelievo (Impostazioni) per rivelare la scheda Prelievo della pagina Istanze, scegli l'altra istanza dal tuo gruppo di associazione e la posizione del suo repository, poi scegli che tipo di backup contiene e ogni quanto prelevarlo. La sua password restic arriva tramite il gruppo, mai il suo APP_KEY. Il lato remoto non ha più nulla da configurare e non deve essere in esecuzione. Il repository sorgente viene soltanto letto: viene aperto per verificare la password, elencato, e indicato come sorgente della copia, e mai inizializzato, sbloccato, potato o scritto. Ciascun lato mantiene le proprie credenziali, e una sorgente rclone: viene rifiutata perché rclone la raggiungerebbe con i remote di questa istanza. Vedi Off-site e ripristino.

Esportazioni in chiaro

• Esportazione in chiaro di container. Un pulsante Esporta (tar semplice) per container scrive una copia sfogliabile e senza bisogno di strumenti accanto al repo: <name>.tar.gz delle cartelle di backup più il template Unraid <name>.xml. Restic resta il motore; questa è una copia di comodità aggiuntiva.
• Esportazione in chiaro di VM. Le VM hanno lo stesso Esporta (tar semplice): <name>.tar.gz dell'immagine (o delle immagini) disco più <name>.xml, ripristinabile con virsh define più il disco, senza bisogno di BombVault o restic.
• Cifra le esportazioni in chiaro (age). Le esportazioni stanno fuori da restic, quindi sono in chiaro di default. Attiva la cifratura age sotto Impostazioni e aggiungi uno o più destinatari (una chiave pubblica age o una chiave pubblica SSH). Ogni esportazione (.tar.gz di container e VM, i loro sidecar .xml e lo ZIP del flash) viene poi sigillata per quei destinatari, e la decifri in seguito fuori dalla macchina con la chiave privata corrispondente. Come regola di sicurezza, con la cifratura attiva e nessun destinatario valido impostato, un'esportazione fallisce con un errore chiaro invece di scrivere mai testo in chiaro.
• Anche il kit di ripristino viene sigillato. Con la stessa impostazione attiva, il kit si scarica come bombvault-recovery-kit.md.age. È in formato ASCII armor anziché binario, quindi resta testo leggibile: puoi ancora incollarlo in un password manager o stamparlo, che è lo scopo del kit. Vale la stessa regola di sicurezza: con la cifratura attiva e nessun destinatario utilizzabile il download viene rifiutato, invece di consegnare la chiave master in chiaro. Una cosa da fare bene quando la attivi: ti serve la tua chiave privata age per aprire il kit, quindi tieni quella chiave in un posto che non dipenda dal kit stesso.

Assistenti IA (MCP)

BombVault ha un server MCP integrato con cui un assistente come Claude Code o Claude Desktop può leggere lo stato dei backup, la copertura, la cronologia delle esecuzioni, i punti di ripristino e l'attività in corso. Con una chiave che lo consente, l'assistente può anche avviare il backup di un elemento, di un dominio o di tutto, e annullare i backup che ha avviato. Ripristini, eliminazioni, prune e impostazioni restano nell'interfaccia web. Ogni client riceve la propria chiave in Impostazioni, Integrazioni, Server MCP; una chiave viene mostrata una sola volta, salvata solo come impronta e si può rinominare, sostituire o revocare in qualsiasi momento. Gli avvii sono limitati per ora e per elemento, e una protezione della conservazione impedisce ai backup di un assistente di far uscire i tuoi punti di ripristino da una politica "conserva gli ultimi N". Ogni esecuzione avviata da un assistente è segnata "via MCP" con il nome della chiave. Vedi Server MCP. I dump dei database e i dataset ZFS sono tra gli elementi e i punti di ripristino che legge, e può elencare le anomalie che BombVault ha notato.

App e componenti aggiuntivi

• App Android. Tutti i server del tuo gruppo sul telefono, con il registro attività di tutti quanti in un'unica schermata. Si associa al tuo gruppo tramite codice QR e apre ogni server con l'accesso già eseguito. Vedi App Android.
• Server ricevente. La macchina che riceve le copie off-site può avviare con un clic un rest-server append-only e offrirlo alle altre istanze del tuo gruppo, ciascuna con un accesso proprio. Vedi Server ricevente.
• Impostazioni, App. Una pagina che inizia con l'app Android, il suo APK per la release che il server esegue e un codice QR, seguita da una scheda per ogni componente aggiuntivo. La scheda di ParleyPort offre il suo template Unraid, copia il comando Docker che lo avvia e porta al suo repository e alle impostazioni del relay in Associazione. La scheda di BombVault Widget offre il suo template e il suo repository, e installa o rimuove il plugin tramite la connessione SSH all'host.
• BombVault Widget. Un riquadro nella Dashboard di Unraid con il registro attività di BombVault e la prossima esecuzione pianificata. Senza una connessione SSH all'host, la scheda ti fornisce l'indirizzo .plg da installare in Plugins, Install Plugin, e lì il plugin si può rimuovere come qualsiasi altro.
• Registro attività incorporabile. Genera un token in sola lettura in Impostazioni, Integrazioni e ottieni un indirizzo per qualsiasi dashboard che mostri un iframe, come Homepage, Organizr o Heimdall: una piccola pagina con il solo registro attività in tempo reale. Il token dà accesso a quel registro e a nient'altro, e Disattiva lo revoca subito. La pagina incorporata è solo in inglese.

Altro

• Fermare un backup in corso. Ogni scheda che può avviare un backup ha un pulsante Annulla backup accanto alla barra di avanzamento mentre l'esecuzione è attiva. L'esecuzione viene registrata come annullata, non come fallita. Fermarla è sicuro, perché restic scrive il suo snapshot per ultimo, quindi un'esecuzione interrotta lascia dati non referenziati e nessuno snapshot.
• Backup di molti in una volta. Seleziona più container e premi Backup selezione. Il batch gira lato server, così continua anche se chiudi la scheda o perdi la connessione. BombVault non esegue mai il backup (e quindi non ferma mai) del proprio container.
• Browser degli snapshot con un elenco di punti di ripristino, eliminazione per snapshot e un albero di cartelle richiudibile per il ripristino a livello di file.
• Manutenzione del repository per dominio: Verifica (restic check), Sblocca (rimuove un lock bloccato) e Pota (applica la policy di conservazione su richiesta quando ne è impostata una, altrimenti un semplice recupero di spazio).
• Avanzamento di verifica, controlli di ripristino e pulizia. Mentre una di queste operazioni è in corso, il registro attività e la scheda Integrità mostrano fin dove è arrivato il conteggio di restic, per esempio 12 di 47 pack, con il tempo rimanente del passo appena ci sono dati sufficienti per stimarlo. Qui restic conta pack, snapshot e file di indice, non byte, ed è questo che mostra la barra; prima del primo conteggio scorre senza numero.
• Dump automatici dei database. I container PostgreSQL, MySQL e MariaDB riconosciuti (le immagini ufficiali, PostGIS, TimescaleDB, pgvector, pgautoupgrade, le immagini di database di Immich, linuxserver, yobasystems e jc21 MariaDB, e il mysql-server di Oracle) vengono dumpati prima di ogni backup, dal server in funzione. I container che somigliano soltanto a un database ricevono la stessa opzione sulla loro scheda, spenta finché non la scegli tu. Il dump scorre dritto nel repository e lì diventa un punto di ripristino a sé, accanto al backup dei file; su disco non viene mai scritto. Le credenziali arrivano dalle variabili del container stesso, compresi i segreti *_FILE, e non lo lasciano. Ogni scheda mostra se la cartella dati del database viene salvata a container fermo, copiata mentre gira, o non salvata affatto. Un dump fallito non fa fallire il backup: compare come esecuzione fallita con il suo motivo e un suggerimento per risolverlo, e invia una notifica. I dump non vengono mai ricaricati da soli. Scaricane uno (semplice o compresso), salvalo in una cartella, importalo con un clic in un database appena avviato, oppure prendilo con la CLI di restic. Puoi spegnerlo per singolo container, con l'etichetta bombvault.dbdump=false, o per tutti i container nelle Impostazioni. Il rilevamento delle anomalie controlla anche la dimensione di ogni dump, e un assistente può elencare i dump di un container tramite il server MCP.
• Hook pre/post-backup per container. Comandi shell eseguiti dentro il container (per esempio scaricare una cache su disco); un pre-hook fallito annulla il backup. I database riconosciuti vengono dumpati automaticamente e non hanno bisogno di alcun hook.
• Ferma altri container durante il backup, con un riavvio gestito dallo stato di salute. Nomina i container dipendenti (per esempio un database) da fermare mentre questo viene sottoposto a backup. In seguito BombVault li riporta nel loro ordine depends_on di Compose e, di default, attende che ciascuno segnali di essere sano (o in esecuzione, se non ha healthcheck) prima di avviare i container che dipendono da esso, così una dipendenza come Pi-hole, un database o un gateway VPN è effettivamente attiva prima dei servizi che ne hanno bisogno, invece che questi tornino a un connection refused. L'attesa è limitata da un timeout per container (120 secondi di default) così un container lento o mai sano non può mai bloccare l'esecuzione; sia l'attesa che il timeout risiedono su Impostazioni, Container (disattiva l'attesa per il precedente riavvio tutto-in-una-volta). Lo stesso riavvio ordinato e gestito dallo stato di salute avvolge anche l'aggiornamento dell'immagine post-backup, così in un giorno in cui arriva un aggiornamento i dipendenti vengono tenuti fermi durante la ricreazione e riportati su, gestiti dallo stato di salute, solo una volta terminata.
• Pattern di esclusione per container. Elenca le sottodirectory da saltare dentro un volume sottoposto a backup, una per riga. Digita i percorsi come li vedi dentro il container; un'anteprima dal vivo mostra a cosa si risolve ogni riga e avvisa quando una riga non escluderebbe nulla.
• Aggiorna dopo un backup riuscito (avanzato, disattivato di default). Attivalo su un container e BombVault scarica l'immagine più recente e lo ricrea, ma solo quando c'è effettivamente un'immagine più nuova, così esiste sempre prima un punto di ripristino fresco. Extra opzionali: una notifica per container aggiornato e la pulizia dell'immagine (un'immagine base condivisa da altri container non viene mai eliminata). Dopo l'aggiornamento BombVault chiede anche a Unraid di ricontrollare lo stato di aggiornamento di quel container, così il banner update available obsoleto della scheda Docker si cancella da sé invece di persistere (gli aggiornamenti Unraid passano direttamente attraverso l'API Docker, quindi il suo stato in cache, e su alcune versioni un digest in cache, continuerebbe altrimenti a mostrare il banner). È best-effort, non influisce mai sul backup, attivato di default e ha un interruttore in Impostazioni.
• Ripristino in una cartella alternativa per clonazione o ispezione.
• Diff e tag degli snapshot. Confronta due snapshot per vedere cosa è cambiato, e assegna tag agli snapshot per filtrarli.
• Novità dopo un aggiornamento. Le note di rilascio compaiono una volta per ogni nuova versione, servite da note incorporate nel binario, così la finestra funziona offline.
• HTTPS pronto all'uso (autofirmato, o porta il tuo certificato dietro un reverse proxy).
• Healthcheck Docker. Il container segnala sano/non sano dal proprio /api/health, così uno strumento di auto-heal può riavviarlo se il motore dovesse mai incepparsi.
• Interfaccia scura/chiara in 42 lingue con un selettore di bandiere.
• Le impostazioni si salvano da sole. Sposta un interruttore o lascia un campo e la modifica viene scritta subito, con un breve lampo sul controllo e una scossa se il server la rifiuta. Tre punti mantengono un pulsante Salva, perché salvarli a metà sarebbe rischioso: il riquadro della configurazione rclone, l'editor dei set di credenziali e la password di accesso.
• Pop-up silenziosi. In Impostazioni, Generale puoi silenziare le conferme di routine, così solo gli errori continuano a interromperti. Vale per singolo browser e non tocca le notifiche inviate da BombVault.
• Come piace a te. Impostazioni, Aspetto imposta i colori (un solo accento, oppure la Modalità arcobaleno con una tavolozza di otto), gli angoli (arrotondati, morbidi o squadrati) e l'animazione (disattivato, sobrio, selvaggio o scatenato), memorizzati per browser. Quando il tuo sistema chiede meno movimento, ha sempre la precedenza.