Scusa mi è partita l'emI prima...Non mi è chiara comunque l'utilità di "ricambiare" l'uuid del disco di backup, parlo in caso di recovery. Se tu cambi l'uuid al disco di backup, il giorno che ti serve invertire i dischi come hai detto, e il tutto è configurato usando gli uuid, grub ed fstab in questo caso, cosa fai? Se grub ed fstab cercano l'uuid del vecchio disco master ma il disco di backup ha un uuid diverso perché l'hai modificato?
On 27 Apr 2017 7:32 pm, "Giancarlo Dessì" <[email protected]> wrote: > Ma si tratta di soluzioni brute che accantonano il problema e possono > generare il conflitto nei casi non previsti. Ad esempio, GRUB configurato > dalla slackware non incontra problemi, il fstab della slackware l'avevo già > impostato per riferire allo standard /dev/sdx, ma avevo dimenticato di > adattare il fstab di Ubuntu. E infatti ubuntu mi montava entrambe le > partizioni sullo stesso punto di mount! Peraltro mi risulta che l'UUID è > tenuto in particolare considerazione in ambiente Windows. Non è il mio caso > dato che non ho sistemi Windows installati (alleluja, ho da un po' tagliato > definitivamente il cordone ombelicale) però non credo che sia cosa buona e > giusta mantenere due partizioni con UUID e etichette di volume uguali nella > stessa macchina se ospita anche un sistema Windows. > > Comunque, Roberto Metere mi ha dato l'imbeccata giusta, dopo i vari > aggiustamenti penso di essere riuscito a superare il problema, devo solo > fare il test finale. Il primo si è interrotto a causa di un errore di > sintassi nello script al momento di fare e2fsck. > > Il 27/04/2017 17:59, Filippo Meloni ha scritto: > > Puoi ovviare al cambio di UUID configurando GRUB in modo che utilizzi il > device /dev/sd* invece che l'UUID e configurando fstab nello stesso modo, > evitando gli UUID > > Il giorno 27 aprile 2017 10:12, Giancarlo Dessì <[email protected]> ha > scritto: > >> Ciao lista, >> >> dopo anni e anni di rischi di perdita dei dati, pur disponendo dei dischi >> di riserva, mi sono finalmente deciso a predisporre un sistema di backup. >> Il disco master ha tre partizioni primarie (per ubuntu, slackware e swap) e >> 5 partizioni logiche per i dati, di cui due usate per tenere separate le >> directory /var/lib e /var/www della slackware, allo scopo di mantenere i >> database MySQL e il sito web in caso di reinstallazione. Il disco di >> riserva ha un partizionamento uguale. >> >> Il backup è impostato con una serie di script bash, uno per ciascuna >> partizione, ad eccezione della swap, che possono essere eseguiti >> all'occorrenza in modo indipendente oppure richiamati in concatenazione da >> uno script genitore. Quest'ultimo è avviato da cron ogni lunedì alle 7.15: >> a quell'ora esco per andare al lavoro, perciò lascio il computer acceso per >> eseguire i job, al termine dei quali si avvia lo shutdown. Il tutto gira >> sulla slackware. Per ogni script la sequenza di operazioni è la seguente: >> mount della partizione del disco di riserva (1) registrazione dell'avvio su >> un file di log (2) esecuzione del backup (3) registrazione del >> completamento sul file di log (4) smontaggio della partizione di backup. >> >> Ogni script usa rsync per fare la copia completa di ciascuna partizione >> ad eccezione di quello relativo alla partizione della slackware (su >> /dev/sda2). Quando è avviata la slackware le altre partizioni sono montate >> e quindi rsync lavorerebbe anche sulle partizioni montate, con conseguente >> saturazione della partizione di backup su /dev/sdb2. Per evitare una >> concatenazione di comandi rsync per ciascuna directory della radice della >> slackware ho perciò pensato di fare il backup a basso livello con dd >> if=/dev/sda2 of=/dev/sdb2. Peraltro credo che sia una soluzione migliore >> nel caso dovessi avviare, all'occorrenza, il sistema dal disco sdb: >> basterebbe invertire i cavi e ritoccare alcuni collegamenti simbolici da >> una live. >> >> Dopo varie prove per correggere gli errori, alla fine il tutto funziona, >> sia manualmente sia con il cron. Tranne un piccolo dettaglio. Facendo un >> sistema di backup analogo nel computer di mia moglie, in cui gira di >> default la Ubuntu, ho notato che l'esecuzione del backup con dd cambia >> anche lìUUID della partizione immagine (/dev/sdb1) assegnandogli lo stesso >> UUID della partizione master (/dev/sda1). Nel mio pc non me ne ero accorto >> perché monto le partizioni identificandole con il tradizionale /dev/sdX >> invece dell'UUID. Con blkid ho però verificato che la partizione di backup >> della slackware ha lo stesso UUID della partizione master. >> >> La cosa mi urta perché non vorrei che un giorno saltasse fuori qualche >> conflitto a causa di qualche applicazione che pasticcia con due partizioni >> che hanno lo stesso identificatore. Apparentemente sembra che il sistema >> non ne risenta, anche perché le partizioni di sdb sono normalmente smontate >> e lo stesso GRUB, pur usando l'UUID, carica regolarmente il kernel dal >> disco sda, ma non mi fido. A questo punto la sola alternativa che mi viene >> in mente è quella di fare il backup con una serie di comandi rsync >> concatenati per ciascuna directory, escludendo i punti di mount delle altre >> partizioni, ma vorrei una soluzione più semplice. Mi vengono in mente due >> opzioni (ammesso che siano possibili): >> >> 1) eseguire dd evitando che modifichi l'UUID della partizione di backup >> >> 2) eseguire in automatico una sovrascrittura dell'UUID subito dopo >> l'esecuzione di dd riassegnandogli quello precedente >> >> Non so se sia possibile farlo o se esistono altre strade possibili, >> perciò ben venga qualsiasi suggerimento. >> >> Ringrazio per l'attenzione, ciao. >> >> PS: visto che mi sto facendo un'esperienza in proposito, potrebbe essere >> utile per farne un talk per il prossimo linux day? >> >> -- >> ********************************************************* >> Giancarlo Dessì >> http://www.giand.it >> http://twitter.com/gian_d_gian >> >> Slackware Linux... because it works! >> ********************************************************* >> >> _______________________________________________ >> Gulchelp mailing list >> [email protected] >> http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >> > > > > _______________________________________________ > Gulchelp mailing > [email protected]http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp > > > -- > ********************************************************* > Giancarlo Dessìhttp://www.giand.ithttp://twitter.com/gian_d_gian > > Slackware Linux... because it works! > ********************************************************* > > > _______________________________________________ > Gulchelp mailing list > [email protected] > http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp > >
_______________________________________________ Gulchelp mailing list [email protected] http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
