Durante una prova di recupero arriva un momento in cui la barra di avanzamento smette di essere la cosa più interessante. Scolleghi il disco originale, avvii quello ripristinato e aspetti di vedere se parte davvero.
È successo nell’ultima sessione di sviluppo di VaultSync 1.9.0. I componenti di recupero installati hanno acquisito un disco Linux, pubblicato una copia verificata per il recupero, ripristinato il contenuto attraverso l’interfaccia grafica e riletto il disco destinazione. Un confronto separato ha trovato identici i contenuti del disco originale e di quello recuperato. Poi il disco ripristinato si è avviato da solo, ha raggiunto un terminale grafico e ha accettato comandi da tastiera.
Volevo arrivare qui da un po’. Per me è un passaggio importante: VaultSync sta andando oltre il conservare un’altra copia di una cartella di progetto, verso la possibilità di rimettere in funzione una macchina.
Questo è un aggiornamento sullo sviluppo, non l’annuncio della beta 1. La stabile rimane la 1.8.9. Ci sono ancora difetti e verifiche di rilascio da completare, che spiego più avanti. Adesso, però, abbiamo un ciclo completo di recupero con i componenti installati da mostrare, insieme al lavoro meno appariscente accumulato intorno al motore.
Abbiamo anche un server Discord ufficiale: entra nella community di VaultSync. Vorrei che diventasse un posto utile per seguire lo sviluppo, discutere i flussi di recupero e, quando arriverà la beta, confrontare i risultati delle prove.
Nuova cattura nativa del 10 novembre. Il profilo di prova è privato e vuoto: l’app segnala l’assenza di progetti e punti di ripristino, senza mostrare una cronologia inventata.
Cosa è cambiato dalla 1.8.9
Il motore per i dischi è la parte più grande di questa release. Nel frattempo è continuato anche il lavoro sul backup di tutti i giorni.
- La navigazione ricorda dove eri. Indietro, Avanti, scorciatoie e ripristino della pagina visitata hanno ricevuto correzioni, comprese l’inizializzazione all’avvio e la conservazione delle bozze nella pagina History.
- I progetti importati sono riconoscibili. La cronologia importata può comparire in Projects con l’etichetta Imported e l’indicazione esplicita che manca una cartella sorgente locale collegata. Sapere che esiste un backup non significa sapere dove si trovi il suo progetto su questo computer.
- La scoperta dei metadati richiede meno interventi. Le destinazioni abilitate vengono ricontrollate periodicamente dopo l’avvio; anteprime e importazioni in sola lettura lavorano su copie private. Le macchine possono così trovare la cronologia condivisa senza scambiare i percorsi di un altro computer per cartelle locali.
- I preset di esclusione hanno ricevuto correzioni concrete. La selezione dei preset indicizzati viene applicata coerentemente tra progetti, CLI e backup. Il lavoro su Unity comprende anche le acquisizioni salvate del profiler, oltre ai dati generati che possono far crescere molto un progetto composto quasi soltanto da codice.
- Sono stati sistemati piccoli difetti dell’interfaccia. La modifica dei preset usa un’icona coerente senza dipendere da un carattere disponibile solo su alcuni sistemi. Ci sono anche correzioni per le schede strette dei progetti e i totali dello spazio sulle destinazioni.
- I grafici dello spazio sono disegnati con Avalonia. Rimangono colori dei progetti, legende ordinabili e suggerimenti, eliminando una dipendenza separata per i grafici.
- La localizzazione fa parte di ogni modifica alla UI. Finestre, errori, accessibilità e risultati dell’aggiornamento richiedono traduzioni reali nelle lingue mantenute. Il controllo delle stringhe e la revisione dell’interfaccia renderizzata verificano aspetti diversi.
Sono modifiche in sviluppo e revisione, non l’annuncio di una nuova stabile già distribuita. E l’importazione tra macchine non rende magicamente intercambiabile ogni configurazione: cartelle locali, permessi, credenziali e identità del dispositivo vanno gestiti con attenzione.
Recovery e clonazione hanno due compiti diversi
L’app desktop ha una pagina dedicata, Disk cloning. Il recupero dei progetti e le informazioni sulla loro preparazione rimangono sotto Recovery. Separare i due compiti rende la navigazione più comprensibile: recuperare un progetto e sostituire un disco di sistema hanno conseguenze molto diverse.
Interfaccia reale di sviluppo, 10 novembre. La pagina dichiara il limite attuale: il worker di verifica delle immagini richiede l’ambiente di recupero Linux x64. Questa schermata macOS non dimostra un ripristino nativo dei dischi macOS.
La pagina desktop è ancora limitata. Non offre già il comando unico «ripristina questa macchina al prossimo riavvio». La scrittura riuscita mostrata più avanti passa attraverso l’ambiente separato di recupero offline installato nella VM.
Il profilo vuoto non contiene punti di recupero misurati. Queste schede servono a spiegare le evidenze disponibili sui backup dei progetti; un pannello rassicurante non dimostra che un’immagine del sistema operativo possa avviarsi.
La prova reale: acquisire, verificare, ripristinare, avviare
L’ultima sessione ha usato un disco Linux Debian da 3 GiB, usa e getta, con GPT, avvio UEFI, ext4 e settori logici da 512 byte. Conteneva una vera installazione con systemd e un ambiente grafico leggero basato su Xorg e xterm. Le dimensioni ridotte permettono di ispezionarlo e ripetere le prove mantenendo limitato lo spazio di lavoro locale.
Durante l’acquisizione il kernel vedeva la sorgente in sola lettura. L’archivio delle immagini si trovava su storage separato. Durante il ripristino il disco sorgente era scollegato. Nell’avvio finale erano assenti sia la sorgente sia l’archivio: il disco recuperato doveva partire autonomamente, con variabili del firmware nuove. Queste fasi non avevano rete.
È una misurazione su un ambiente preciso. Non è una verifica di tutte le distribuzioni Linux, dei dischi da più terabyte, dell’hardware fisico o del recupero Windows/macOS.
1. Acquisizione dalla console offline
La console di acquisizione richiede una scelta esplicita della sorgente. Dopo la copia, il contenuto viene verificato prima della pubblicazione e viene preparata una copia verificata accessibile all’interfaccia di recupero.
Output reale della prova del 10 novembre. Percorsi e identificatori dei dischi appartengono alla macchina usa e getta. L’immagine originale e la copia accessibile al recupero sono distinte: l’originale rimane privato.
Questa distinzione ha richiesto lavoro. Il processo privilegiato che acquisisce il disco e l’interfaccia di recupero senza privilegi non possono condividere liberamente l’accesso ai file. L’implementazione conserva l’originale privato e mette a disposizione una copia verificata separatamente, invece di cambiare i permessi di un backup esistente per far funzionare la UI.
Il primo formato è un’immagine raw completa. Comprende i settori inutilizzati e può conservare residui di dati cancellati. Richiede spazio proporzionato alla capacità del disco e va trattato come una copia sensibile. Acquisizione a sistema acceso, gestione dei sistemi cifrati e Secure Boot hanno requisiti propri: questa prova non li rende implicitamente disponibili.
2. Trovare l’immagine senza ricordare il percorso
La procedura grafica elenca le copie candidate al recupero. Per la selezione normale non serve più cominciare digitando il nome esatto di una cartella. Si può aggiornare l’elenco; l’inserimento di una cartella conosciuta rimane tra le opzioni avanzate.
È proprio l’immagine della prova, trovata dalla procedura installata. L’etichetta dice esplicitamente «not yet verified»: trovare una copia non equivale ad averne verificato l’integrità.
Dopo la selezione, l’immagine viene controllata indipendentemente e preparata in uno spazio privato. Prima di usarla come sorgente del ripristino viene chiuso l’accesso in scrittura alla copia preparata. Il parser lavora nel lettore isolato: metadati malformati, GPT incoerente o un lettore attendibile non disponibile devono fermare l’operazione, non diventare motivi per saltare la verifica.
3. Controllare la destinazione e confermarla indipendentemente
Nella lista delle destinazioni compariva soltanto il disco vuoto usa e getta. Il disco dell’ambiente di recupero e quello contenente l’archivio delle immagini non venivano proposti come normali destinazioni da sovrascrivere.
La schermata successiva collega la revisione all’immagine scelta, all’hash della radice dei contenuti, all’identità della destinazione, alla sequenza del disco, alla capacità e alla geometria dei settori.
Confermare di aver letto questa schermata non autorizza da solo la scrittura. La console fisica indipendente presenta una nuova conferma vincolata a quella destinazione.
La conferma mostrata appartiene soltanto alla prova già terminata. Non è un comando riutilizzabile né un’istruzione da applicare ai propri dischi.
Qui rimane lavoro sull’esperienza d’uso. Identificare e confermare il disco corretto deve essere comprensibile anche quando si lavora sotto pressione; l’intero percorso dal supporto installato al recupero deve essere semplice da seguire. Servono sia il limite di sicurezza sia un flusso rifinito.
4. Scrivere, rileggere e conservare l’esito reale
Dopo la conferma, l’interfaccia entra nella fase di ripristino e mostra i byte riconosciuti dal writer.
Il writer mantiene un journal persistente. Alla scrittura segue la rilettura; interruzioni o pulizie dall’esito incerto devono conservare il proprio stato reale, senza trasformarsi in un rifiuto apparentemente pulito o in un successo inventato.
Esito finale della sessione: 3.221.225.472 byte riconosciuti. Il servizio è terminato con successo e la ricevuta finale persistita conferma anche la pulizia dello spazio temporaneo di proprietà dell’operazione.
5. Avviare il disco appena ripristinato
Prima che l’avvio del sistema modificasse il filesystem, ho confrontato l’intero contenuto della sorgente con la destinazione. Il risultato è stato contenuto identico.
Poi il disco recuperato è stato avviato da solo. systemd ha risposto running; erano presenti le identità originali di ext4 e della partizione, insieme ai file della prova. Il terminale grafico ha accettato i comandi e un nuovo marcatore è stato osservato indipendentemente nella console seriale prima dello spegnimento normale.
Interazione reale con il sistema recuperato, con sorgente e archivio scollegati. È un ambiente X11 leggero di prova, non una qualifica generale di desktop o hardware.
Per chi vuole i dettagli: gli eseguibili di recupero erano legati al sorgente congelato 7ac4ee5, il runtime aggiornato era .NET 10.0.13 e l’inventario dell’installazione grafica conteneva 675 file. L’intera fase di acquisizione è durata 421,009 secondi, la sessione di recupero 622,670 secondi. Sono tempi di sessione che comprendono avvio, verifiche e interazione, non benchmark della velocità dei dischi.
Un difetto di prestazioni che rifaceva due volte il lavoro
L’ispettore isolato leggeva integralmente il payload due volte. Con l’immagine da 3 GiB conservata per le prove, la versione precedente raggiungeva il limite previsto prima di terminare.
La correzione riutilizza internamente il digest calcolato mentre viene verificato interamente l’unico payload. Non si fida di un hash dichiarato nel manifest e non elimina le verifiche indipendenti durante acquisizione, esportazione e preparazione. Anche GPT e cancellazione devono completare correttamente il proprio percorso prima che esista un digest verificato.
Con gli stessi limiti, la prova nativa mirata ha verificato l’immagine in 73,807 secondi, con 24.583 letture attraverso il broker e il worker terminato correttamente. Questo risolve il difetto immediato del lavoro duplicato. Non dimostra che il budget sia adeguato a dischi di qualsiasi capacità: rimane una parte della qualifica.
Compressione: miglioramenti utili e ricerca separata
I normali backup dei file continuano a usare archivi ZIP/DEFLATE compatibili. Le modifiche in sviluppo applicano una compressione più densa ai formati testuali Unity adatti, tra cui scene, prefab e metadati, mantenendo la compatibilità del lettore esistente. I contenuti binari richiedono scelte diverse: comprimere tutto più aggressivamente non garantisce automaticamente archivi più piccoli o tempi migliori.
Il compressore sperimentale separato esplora scelte guidate dal contenuto, corrispondenze di tipo LZ, codifica Huffman canonica e canali reversibili per dati ricchi di numeri o GUID. La parola importante è sperimentale. I suoi frame personalizzati non vengono scritti nei backup ZIP o nelle immagini dei dischi. Le misurazioni non dimostrano che superi i codec maturi sui dati generici; completare la beta 1.9.0 rimane prioritario rispetto a questa ricerca.
Diagnostica utile anche per blocchi ed errori
Il lavoro sulla diagnostica comprende eventi tecnici strutturati, errori e segnalazioni di operazioni che non avanzano. Non dipende soltanto da una segnalazione di crash quando il processo è già scomparso.
La politica beta abilita per impostazione iniziale la raccolta strutturata più ampia soltanto negli eseguibili compilati con il canale esatto beta. Stabili, candidate e normali build di sviluppo mantengono l’attivazione esplicita. Un rifiuto precedente viene rispettato; scelte e code beta rimangono separate, e passando alla stabile non viene trasferito automaticamente il permesso di invio della beta.
I report usano campi ammessi e limitati: versioni di build e runtime, sistema e architettura, codici di operazione ed errore, intervalli approssimati per tempi e quantità e riferimenti numerici nel codice. Non devono caricare log o dump grezzi, contenuti dei file, nomi, percorsi, credenziali o identificatori persistenti di utenti, dispositivi e sessioni. Revisione, disattivazione e cancellazione rimangono parte del flusso.
La nuova build macOS fotografata per questo articolo era una normale build QA di sviluppo, con report mantenuti in locale e rete limitata. Le sue schermate non dimostrano l’invio inizialmente attivo della beta né qualificano il servizio di ricezione in produzione.
Perché questo rimane un aggiornamento e non la beta 1
Il ciclo riuscito è un traguardo sostanziale. Ci sono anche motivi concreti per cui non gli sto allegando un annuncio di rilascio:
- La schermata di recupero ha ancora un difetto di ridisegno. Alcuni aggiornamenti parziali rendono nera gran parte della finestra. Esporre nuovamente il terminale virtuale ha permesso di rivederla durante la prova, ma non è un’interazione finale accettabile. Una correzione circoscritta al rendering compila; la conferma nativa del risultato è ancora da fare.
- La qualifica finale di supporto e profili rimane aperta. Al ciclo installato nella VM devono aggiungersi le prove di interruzione e rifiuto pertinenti, i limiti di capacità e il percorso completo del supporto confezionato. Anche la presenza di VaultSync dopo il ripristino dipende da cosa contiene l’immagine: questa prova non consegna una reinstallazione universale con riconciliazione della configurazione.
- Il gate di qualità separato non passa ancora. Nell’analisi verificata sul commit
3ad6461, sicurezza, affidabilità e manutenibilità erano A, con revisione degli hotspot completa. La copertura del nuovo codice era 78,9%, sotto la soglia invariata dell’80%. Servono casi mancanti utili; spostare la soglia non risolve il problema. - I pacchetti hanno verifiche proprie. Aggiornamento dalla precedente 1.8.9, comportamento del canale nell’updater, provenienza, verifica degli asset finali e review protette richiedono ancora le evidenze previste. L’attestazione del workflow è distinta dalla firma del produttore e dalla notarizzazione delle singole piattaforme.
È un ridisegno fallito reale, incluso volutamente. Il recupero della stessa sessione è arrivato in fondo, ma la visualizzazione dell’avanzamento va ancora sistemata. Un backend funzionante non giustifica una schermata illeggibile.
Il programma dei dischi rimane beta 1: Linux, beta 2: aggiunta di Windows, beta 3: aggiunta di macOS. La normale applicazione desktop continua a essere prevista per Windows, macOS e Linux in tutte le beta. Le tappe riguardano la qualifica delle nuove funzioni di acquisizione, clonazione e recupero dei dischi, non la rimozione del supporto desktop esistente. Il recupero macOS/APFS richiede implementazione e prove di avvio dedicate.
Una beta può essere costruita da un commit qualificato del ramo di preparazione mantenendo aperta la PR di release. L’updater segue versione e canale del pacchetto e gli asset pubblicati per l’aggiornamento: un nuovo commit qualsiasi nella PR non diventa automaticamente un update. I download diretti della prima beta sono previsti senza asset per Microsoft Store.
Vale anche la pena chiarire un punto della roadmap: la CLI orientata alle risorse e all’automazione mostrata nei primi diari appartiene alla 1.9.5, mentre discovery e help appartengono alla 1.9.1. Le console offline di acquisizione e conferma mostrate qui appartengono alla 1.9.0. Il lavoro precedente sulla CLI è conservato, ma non entra tutto in questo eseguibile.
Aiutami a dare forma alla beta
Questa release conta per il futuro di VaultSync. Voglio che la prima beta dia alle persone qualcosa di concreto da provare, con un limite onesto intorno a ciò che è stato dimostrato e a ciò che manca. Vedere un sistema recuperato avviarsi è un buon motivo per essere contenti. È anche il momento giusto per essere precisi sul lavoro rimasto.
Per seguire lo sviluppo, entra nel Discord ufficiale. Porta le combinazioni di hardware e filesystem che ti interessano, le situazioni scomode affrontate durante un recupero e i passaggi che sarebbero poco chiari con una macchina già ferma. Tieni contenuti dei backup, credenziali e log privati grezzi fuori dai canali pubblici.
La domanda di questo aggiornamento è: dopo un ripristino, cosa vorresti vedere prima di fidarti di nuovo della macchina: l’avvio, il controllo dei file, un’applicazione funzionante o qualcos’altro?
L’implementazione rimane nella PR #736 in bozza. La ricevuta del ciclo installato del 10 novembre, il programma beta progressivo e il piano sulla compressione documentano i limiti tecnici descritti qui.
Nota sulle immagini: tutte e dodici sono catture native non modificate del 10 novembre. Tre mostrano la build QA desktop isolata su macOS; nove provengono dalla prova reale di recupero e avvio nella VM Linux. Sono stati usati profili vuoti e dischi usa e getta. Nessuna è concept art e nessuna, da sola, dimostra la qualifica generale di una piattaforma. La UI fotografata è in inglese.