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]
<mailto:[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] <mailto:[email protected]>
http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
<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
--
*********************************************************
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
