Newsgroup: it.comp.os.linux.sys
Titolo: Clonare disco in remoto

Ci sono controindicazioni a clonare in remoto con netcat un disco in 
uso? Io credo di si, purtroppo, ma vorrei un po' di conforto :D
Ciao ... Dino

 uso? Io credo di si, purtroppo, ma vorrei un po' di conforto :D
Su, non fare così, non è così grave, ...
Ok, adesso che ti ho dato un po' di conforto, passiamo alla domanda.
Controindicazioni?
Dipende da cosa ti aspetti di poter fare poi con la copia, che non è
un clone, visto che il disco è vivo e si muove, e che strumento usi
per clonare.
Un dd a disco vivo è un suicidio, ad esempio.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net


Dovresti definire meglio in "uso". Se hai la possibilità potresti
mettere il disco in sola lettura. Ti risparmierebbe un suicidio.
Ciao.

 mettere il disco in sola lettura. Ti risparmierebbe un suicidio.
Si, proprio con dd. Lo immaginavo. In uso nel senso che e' in funzione 
ed e' per giunta il disco dove ci sta un po' tutto l'os. Chiaro che 
mentre sto leggendo il disco le operazioni di scrittura vanno a 
pasticciarmi tutto. Vabbe', faro' il boot da un cd live.
Ciao ... Dino

 mettere il disco in sola lettura. Ti risparmierebbe un suicidio.
Eh, dillo a ginopilotino, è lui che avrà un SL che vuole fargli fare
un clone a macchina viva e vitale e non ci ha detto cosa intende per
disco in uso.
Se va bene, è il data space di un oracle da un tera e mezzo.
PS: per favore, dai una lettura veloce a questo:
http://usenet.marco5x.net/quoting-3.php


 pasticciarmi tutto. Vabbe', faro' il boot da un cd live.
Il problema non è che ti pasticcia il contenuto dei file, ad esempio
dei log, ma che ti riscrive la struttura del file system e se avessi
poi un fs journaled ottieni probabilmente un frullato misto di bit.
Oh, se ti serve come generatore di entropia per la crittografia, può
anche essere quello che ti fornisce il miglior risultato possibile.


  uso? Io credo di si, purtroppo, ma vorrei un po' di conforto :D
Per la mia esperienza diciamo dipende :-)
Nel senso che io avevo una macchina in condizioni critiche:
Una vecchia Debian in housing su un serverino (in realta` un pc
economico) con disco morente (niente raid, costava troppo) con tanto di
"I/O error" nel syslog. Usata per fare hosting di mail/domini.
Se avessi riavviato probabilmente non sarebbe riuscito a completare il
sicuro fsck.
A quel punto ho aperto una sessione ssh e con dd | gzip | netcat mi sono
trasferito il disco su una macchina virtuale su un altro server e dopo
un fsck ho avuto la fortuna di avere tutta l'installazione funzionante.
-- 
Vincenzo


Ma senza neanche stoppare i servizi e tutto cio' che puo' scrivere su 
disco qualcosa?
Ciao ... Dino

 disco qualcosa?
Il suo caso rientra nei "dipende cosa ti aspetti".
Non saprà mai se e quanta posta ha perso, ad esempio.
Dei log può anche fregargliene poco o nulla, ma torniamo al "dipende".
Cosa c'è su quella macchina?
Cosa è altamente dinamico?
Quanto stressa (creazione/cancellazione di file) il file system?
Che file system c'è?
Ha journaling?
ecc.ecc.


 Ha journaling?
Evidentemente si.
Ciao ... Dino

 uso? Io credo di si, purtroppo, ma vorrei un po' di conforto :D
... secondo te ? ;-O
(dalla domanda cmq. mi inizio a spiegare molte cose).
In ogni caso se vuoi una copia di un disco "live" ALMENO inizia a
paventare LVM + snapshots, poi da lě ragioni sul come farla ... ma
almeno falla consistente.
ciao, f.

 almeno falla consistente.
Niente lvm.
Ciao ... Dino

 Niente lvm.
Metticelo se hai questa esigenza ...
Non è che tu possa girarci troppo intorno ... se vuoi una copia
consistente con sè stessa o lo fai offline oppure fai uno snapshot e
cloni quello. Non credo ci siano altre soluzioni che siano serie e
risk-free. Poi, se stai backuppando roba "statica" puoi anche usare tar
o cp, ma non mi pare questo il caso ...
ciao, f.

 apache, proftpd, hylafax e ssh. Mi pare non ci sia altro.
Ecco, ssh è un pochino vago, capisci? ;-)
Con ssh io cambio il 95% del file system tutti i giorni, su
alcune macchine.
Per il resto, la cosa potrebbe anche funzionare a basso
tasso di guai: ci provi, sul disco clone esegui fsck e,
volendo, dopo con rsync pareggi le differenze.


  disco qualcosa?
Ovviamente stoppando tutti i servizi che potevo. Avro` avuto fortuna ma
non ho perso praticamente nulla. O almeno nessun utente si e` lamentato.
-- 
Vincenzo

 non ho perso praticamente nulla. O almeno nessun utente si e` lamentato.
# init S
# mount <file_system_vari> -o remount,ro
;-)
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.


In un'unico colpo no, però con qualche passaggio si.
Io farei un sfdisk per estrarmi la struttura delle partizioni e poi 
ricrearla dall'atlra parte.
Eventualmente un dd dei primi 63 settori (mbr & co.) giusto per sicurezza.
Poi rsync di tutto il disco escludendo /proc e /sys. Qualora tu abbia 
dei database degni di tale nome, escludi le loro data dir dall'rysnc e 
usi la procedura specifica del database per farti un backup.
Reinstalli grub/lilo.
Fatto per backuppare una macchina remota in hosting buttandola su una vm 
in locale, è andato tutto bene.

 almeno falla consistente.
posso dissentire non nel metodo, ma nel merito?
Se una persona deve clonare un disco già esistente, su un server già
esistente, in una server farm già esistente, che cavolo gli si
consiglia a fare una cosa che in quel preciso contesto non è fattibile?
Magari lo aggiungi come postilla: la prossima volta vedi di usare LVM o
BTRFS. In questo modo, potrai fare il clone degli snapshot.
Adesso, posso dissentire nel metodo e non nel merito?
A senso clonare uno snapshot, se nel frattempo intervengono modifiche
sull'immagine originale? A senso se si vuole un backup giornaliero. Ma
non ha senso in diversi altri casi, in cui la copia va fatta comunque a
biglie ferme.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 
ci sono tante variabili di mezzo:
- XFS ha una funzione di freeze delle partizioni, che però è
  difficilmente utilizzabile sulla partizione root
- puoi vedere se quella partizione può essere rimontata in "ro" senza
  fare danni alle applicazioni.
- i volume manager dispongono degli snapshot, però se la copia ti serve
  per rimpiazzare il server, allora non va bene, perché mentre tu fai
  la copia, interveranno modifiche sul server.


 snapshot.
non mi si dica "migra sul volume manager". Perché lo snapshot necessita
di ulteriore spazio sullo storage, che potrebbe non essere disponibile.
