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]> 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 (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]> 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 > [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
