Un backup diventa davvero utile quando riesci a usarlo per tornare a lavorare. Con VaultSync 1.9.0 sto portando questo ragionamento oltre i singoli file: acquisire un disco, verificare l’immagine, avviare un ambiente indipendente e ripristinare un sistema che non parte più.
È un passaggio importante per il progetto. Richiede anche un modo diverso di verificare il lavoro: vedere un’immagine nell’interfaccia o completare una build non dimostra ancora che un computer ripartirà dopo il ripristino.
Voglio raccontare cosa sta cambiando, quali parti sono già state provate e come intendo distribuire le beta.
Prima di tutto: l’app resta su Windows, macOS e Linux
Tutte le beta continueranno a mantenere il supporto dell’applicazione su Windows, macOS e Linux. La suddivisione per sistema riguarda clonazione, immagini di sistema e recupero dei dischi.
Il piano è lavorare su queste capacità per tappe, dedicando prove e correzioni a una piattaforma alla volta:
| Tappa prevista | App desktop | Nuova capacità disco da verificare |
|---|---|---|
| Beta 1 | Windows, macOS e Linux | Acquisizione e recupero di sistemi Linux nei profili dichiarati |
| Beta 2 | Windows, macOS e Linux | Aggiunta dei sistemi Windows, mantenendo Linux |
| Beta 3 | Windows, macOS e Linux | Aggiunta di macOS dopo la verifica del percorso APFS e di avvio |
Queste sono le tre tappe funzionali del rollout. Potrebbero servire ulteriori build per correggere problemi nella stessa tappa: ogni build pubblicata avrà una versione distinta, senza sostituire silenziosamente i file di una versione già rilasciata.
Le normali funzionalità di backup dei progetti rimangono disponibili sui tre sistemi durante tutto il percorso.
Il percorso che deve funzionare dall’inizio alla fine
Il lavoro sui dischi comprende cinque passaggi collegati:
- Acquisire il disco sorgente in condizioni coerenti.
- Verificare struttura e contenuto dell’immagine prodotta.
- Avviare un ambiente di recupero indipendente dal sistema da ripristinare.
- Ripristinare sul disco corretto, dopo una conferma esplicita.
- Verificare di nuovo, controllando contenuti e avvio del sistema ripristinato.
Il risultato utile è l’intero percorso. Un test che copia correttamente pochi dati sintetici aiuta a trovare errori, ma il supporto a un sistema operativo richiede anche un vero avvio e un’interazione con il sistema recuperato.
Per questo sto mantenendo una matrice esplicita dei profili: tabella delle partizioni, firmware, filesystem, dimensione dei settori, ambiente di recupero e limiti. La prima direzione Linux parte da GPT/UEFI ed ext4. Il supporto viene dichiarato soltanto per le combinazioni effettivamente verificate.
Perché partire da un’acquisizione offline
La prima implementazione lavora su un disco offline e in sola lettura. In questo modo il contenuto non continua a cambiare mentre viene acquisito. Il repository che riceve l’immagine deve trovarsi su un disco fisico distinto dalla sorgente, e questa separazione viene controllata prima di creare o riservare i file di output.
L’immagine iniziale è raw: conserva il contenuto completo del disco nel profilo supportato. Questo significa anche settori inutilizzati e possibili dati cancellati che non sono stati ancora sovrascritti. Va conservata come una copia sensibile e richiede spazio adeguato.
Acquisizione a caldo, cifratura e Secure Boot hanno requisiti propri. Verranno dichiarati soltanto quando esisteranno implementazione e prove specifiche; la prima beta disco avrà limiti chiaramente documentati.
Una pagina dedicata e due livelli di conferma
Nell’app è stata introdotta una pagina dedicata alla clonazione dei dischi. Il recupero comprende inoltre un’interfaccia separata nell’ambiente offline: scelta dell’immagine, osservazione dei dischi disponibili, revisione e risultato dell’operazione.
Interfaccia reale del prototipo nella VM di verifica. Questa schermata dimostra la presentazione del flusso; non è una dichiarazione di supporto a un profilo disco.
La selezione nell’interfaccia e il consenso alla sovrascrittura sono passaggi distinti. La conferma fisica deve riferirsi al disco e alla revisione correnti: cambiare selezione o usare osservazioni ormai scadute deve invalidare il consenso precedente.
L’interfaccia non riceve un accesso generico con privilegi elevati. Le operazioni sensibili passano attraverso un ingresso fisso del supporto di recupero, che verifica il proprio ambiente, i file installati e le identità coinvolte. Anche l’analisi delle immagini usa un lettore separato con accessi limitati.
Elenco reale in una VM con un piccolo disco sintetico. Il test mostrato riguarda selezione e annullamento, senza autorizzare scritture.
Salvato, interrotto e non confermato devono significare cose precise
Una parte consistente del lavoro riguarda ciò che accade quando qualcosa va storto: annullamenti, spazio esaurito, errori di lettura, problemi di visualizzazione e interruzioni durante la pubblicazione dell’immagine.
Se un’immagine è già stata verificata e pubblicata, un errore successivo della schermata non deve riscrivere la storia dicendo che quell’immagine non è mai stata creata. Allo stesso tempo, un problema del processo o dell’ambiente deve restare visibile. Sono due informazioni da conservare separatamente.
Vale anche il contrario: se la pubblicazione non è confermata, l’app non deve presentarla come un backup completo. File parziali e operazioni interrotte richiedono uno stato esplicito.
Prima di arrivare alla beta, il percorso deve comprendere anche l’accesso alle immagini prodotte da VaultSync. L’originale privato e la copia resa disponibile all’interfaccia di recupero hanno responsabilità diverse. Il collegamento per esportare una copia verificata è ora implementato e ha superato i controlli mirati: l’originale mantiene permessi restrittivi, mentre una copia verificata separatamente diventa leggibile dall’interfaccia. Restano aperte la verifica nativa dell’installazione e il ciclo completo sul sistema operativo.
Cosa è stato verificato finora
Nella VM di sviluppo il wizard ha già mostrato la scelta dell’immagine e l’elenco dei dischi; sono stati verificati annullamento, chiusura e rimozione delle risorse del controller, con il disco sintetico invariato. Il nuovo ingresso di acquisizione ha superato prove mirate e una revisione delle condizioni di sicurezza.
Questi risultati sono componenti del percorso. Restano da completare e misurare l’acquisizione reale dal supporto installato, l’accesso all’immagine prodotta e il recupero completo di un sistema operativo. La beta disco sarà pronta quando quel percorso sarà qualificato, insieme ai controlli di distribuzione.
Anche l’uso quotidiano conta
La 1.9 include lavoro che riguarda l’app sui tre sistemi: progetti importati riconoscibili, controllo periodico dei metadati nelle destinazioni abilitate, preset di esclusione, navigazione e localizzazione.
L’obiettivo è ridurre il lavoro ripetuto quando si passa da una macchina all’altra, mantenendo chiaro quali dati sono locali, quali provengono da altri computer e quando serve una scelta dell’utente. Le impostazioni e le possibilità di controllo restano importanti anche per chi vuole configurare ogni dettaglio.
Diagnostica più utile durante le beta
Per trovare problemi durante l’uso reale, le build compilate come beta prevedono diagnostica tecnica strutturata attiva per impostazione iniziale, con un avviso tradotto e controlli per consultarla, disabilitarla e rimuovere i dati locali.
I report usano campi prestabiliti e limiti di dimensione e conservazione. Servono a distinguere operazioni, fasi, errori, crash e blocchi. Non caricano log grezzi, dump di memoria, contenuti dei file, percorsi, credenziali o identificatori persistenti dell’utente o del dispositivo.
Una precedente scelta di rifiuto viene rispettata. Le preferenze e le code delle beta sono separate da quelle delle versioni stabili. La versione stabile mantiene l’invio su consenso esplicito. Scegliere il canale beta nell’updater non cambia da solo la politica di un eseguibile stabile.
Compressione: ricerca parallela, compatibilità davanti
Sto lavorando anche su una strategia di compressione adattiva, capace di scegliere approcci diversi in base ai dati. Ci sono esperimenti ibridi e misurazioni, ma il formato sperimentale non sostituisce oggi il formato dei backup del prodotto.
Per introdurre un cambiamento servono confronti su dati rappresentativi, misure di CPU e memoria, verifica dei contenuti ripristinati e una strada di compatibilità. ZIP resta il riferimento per i backup che lo usano già. Questa ricerca procede in parallelo e non deve ritardare il completamento delle funzionalità previste per la beta.
Dalle beta alla release finale
Ogni tappa aggiunge capacità disco verificate e conserva quelle già supportate. Windows richiederà il proprio ciclo completo su NTFS. L’ambiente offline iniziale rimane Linux x64: il sistema contenuto nell’immagine e quello avviato per eseguire il recupero sono due elementi distinti del profilo.
macOS richiede un lavoro specifico su APFS, avvio e vincoli della piattaforma. Il piano di rollout include questa tappa; la sua implementazione e qualifica sono ancora aperte, compresi i vincoli dell’hardware Apple.
Per la finale serviranno le funzionalità previste, una matrice di supporto verificata, le correzioni emerse dalle beta e la prova dell’aggiornamento dalla 1.8.9 preservando i dati. Pacchetti, manifest e asset dovranno essere collegati al sorgente esatto e verificati secondo la politica di firma e provenienza. Queste attestazioni sono distinte dalle firme native dei singoli sistemi operativi.
Le beta potranno essere distribuite dal ramo di preparazione mantenendo aperta la PR di sviluppo. L’updater dovrà trovare una release con identità coerente, tag sul commit corretto e asset verificati. La pubblicazione non dipende dal chiudere in anticipo la PR.
Quando una beta sarà disponibile, l’annuncio includerà profili verificati, istruzioni, limiti e problemi noti. Chi la proverà potrà concentrarsi su un percorso preciso e segnalare cosa succede davvero. È così che voglio arrivare a una 1.9 utile da testare e affidabile da usare.
Stato del lavoro al 6 novembre, commit 37d7b80. Le due schermate reali della VM sono del 5 novembre, build di sviluppo caa8ebf; non mostrano una qualificazione del recupero. Il programma beta registra le tappe previste. A questo punto non è ancora disponibile una beta 1.9.0.