A prescindere dalle divergenze di opinione, quello del sovraccarico
dell'hardisk con l'uso di dd è un aspetto da tenere in debita
considerazione, mi hai convinto! A questo punto, avendo l'immagine,
meglio usare rsync.
Il 28/04/2017 20:06, Filippo Meloni ha scritto:
Se sei di questa idea e pensi che per te sia la più azzeccata, in base
alle tue esigenze, no problem.
Io rimango della mia idea perché sono anni che la metto in pratica e
io per lavoro, al contrario tuo non potrei permettermi il fermo di una
macchina per ripristinare un backup avviando live ecc....
Inoltre, l'uso di dd per effettuare dei backup mi sembra alquanto
esoso, a livello di tempo, prestazioni e a livello HW, Il disco sarà
abbastanza stressato con conseguente riduzione della vita del HDD.
Io uso dd per fare il primo clone, per preparare l'ambiente, dopodiché
decido se utilizzare i /dev/* e fregarmene altamente degli UUID,
oppure una volta fatto il clone, cambiiare gli UUID delle partizioni
clonate, ma questo lo faccio solo la prima volta, configuro
opportunamente fstab del disco clonato, e infine utilizzo rsync a
vita, semplicemente escludendo alcuni file che non devono essere
modificati. Come ad esempio appunto fstab.
In questo modo da qualsiasi disco tento di fare il boot, il sistema
parte tranquillamente.
Detto ciò, tralascio la lezione sulla differenza tra bruto e brutto,
grazie della spiegazione ma la mia era una battuta.
Buon dd ;)
On 28 Apr 2017 9:16 am, "Giancarlo Dessì" <[email protected]
<mailto:[email protected]>> wrote:
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
<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] <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
