bruto con una t, non brutto ;)
Il 27/04/2017 23:52, Filippo Meloni ha scritto:
Non riesco a capire cosa intenda con soluzioni brutte. È normale
prassi utilizzare lo standard /dev/** nella configurazione di grub e
fstab. Inoltre usando i device hai anche meno problemi con il BIOS è
il disco di first boot.
È molto più brutto modificare l'uuid di un disco ogni volta,
soprattutto se si tratta di procedure automatiche.
On 27 Apr 2017 7:32 pm, "Giancarlo Dessì" <[email protected]
<mailto:[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]
<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] <mailto:[email protected]>
http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
<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] <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
