In merito al primo rilievo ("non mi è chiara l'utilità di ricambiare ...")
Alcuni motivi li puoi ad esempio estrapolare da quanto scritto qui:
https://wiki.debian.org/it/Part-UUID (al paragrafo Panoramica UUID,
etichette, fstab). In sostanza siamo in una fase di transizione in cui
coesistono diversi standard e allo stato attuale , ma la tendenza è che
il software a basso livello userà in un prossimo futuro la denominazione
persistente (gli UUID, per intenderci). Come avevo detto in precedenza,
i sistemi Linux non danno attualmente problemi in proposito, ma altre
piattaforme, come Windows e Oracle, sono già più orientate verso la
denominazione persistente. È chiaro che se questa tendenza andrà avanti,
quelli che attualmente sono problemini accidentali, in un prossimo
futuro saranno sempre più frequenti qualora si trovino device con lo
stesso UUID, sia a livello di macchina sia a livello di rete. Conflitti
che possono essere generati sia dal software a basso livello sia
dall'errore umano. Questa è la ragione per cui preferisco evitare
situazioni che possono generare errori accidentali. Finché si tratta di
prevenire o correggere errori o conflitti nella configurazione di GRUB o
fstab poco male, più difficile se non impossibile, almeno per me, è
invece prevedere, capire e aggirare il comportamento del software a
basso livello (kernel, controller, protocolli, ecc.) di fronte ad una
possibile situazione di ambiguità.
Ergo, perché farsi male? Se un software mi assegna lo stesso UUID a due
device e ho la possibilità di correggere l'ambiguità preferisco farlo
piuttosto che lasciare una possibile causa di conflitto.
In merito al secondo punto ("se ti serve invertire i dischi come hai
detto e il tutto è configurato usando gli uuid ...")
Probabilmente ti è sfuggito un passo che avevo scritto. È chiaro che se
dovessi fare l'eventuale inversione dei dischi, metterei mano alla
configurazione di base. GRUB non avvierebbe il sistema, ma non è un
problema: farei il primo avvio da un disco di installazione o da una
live, ritoccherei manualmente il grub.cfg, fstab e qualche link
simbolico per rendere provvisoriamente operativo il disco di riserva. Il
tutto è finalizzato al recupero di una serie di configurazioni impostate
nei file delle partizioni di sistema (in gran parte in /etc, in
/usr/share e in /usr/local). Recuperati questi file e accantonati in una
delle partizioni dei dati, a questo punto procederei ad una
reinstallazione: meglio avere un sistema reinstallato e riconfigurato in
pochi passaggi che avere a che fare con un sistema riciclato in cui
rischi di passare mesi a risolvere problemini che saltano fuori di tanto
in tanto. Certo, l'uso del RAID mi eviterebbe tutto questo, ma dal
momento che ho parecchi limiti e di RAID non ne capisco un tubo, ricorro
ad una strategia di backup e restore più grezza ma nella quale posso
muovermi con cognizione.
Spero di essere stato chiaro, non vorrei scrivere noiosi papiri :-D
In merito al malinteso brutto/bruto, i due aggettivi hanno significati
completamente diversi. Non avrei mai usato l'aggettivo "brutto" per
etichettare un suggerimento, a cui va comunque tutto il mio rispetto!
L'ho etichettato come "bruto" perché la soluzione contempla
l'accantonamento di un possibile problema sulla base del fatto che
apparentemente il problema non si pone. Nei limiti del possibile
preferisco prevenire alla radice l'eventualità di un conflitto, anche se
questa non dovesse mai verificarsi.
Il 28/04/2017 00:12, Filippo Meloni ha scritto:
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]
<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
