Finché le divergenze sono costruttive ben vengano On 28 Apr 2017 8:25 pm, "Giancarlo Dessì" <[email protected]> wrote:
> 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]> 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 > [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
