Spesso capita di dover copiare una VM da un post a un altro per n+1 ragioni, ci sono fondamentalmente 2 modi molto comodi o quanto meno io ne conosco 2 ma saranno sicuramente molti di più.

Il primo è questo, ammettiamo di essere sul server pedretti e di dover copiare la VM vesuvio sul server sanmarco:
dd if=/dev/xen2/vesuvio bs=100M | ssh root@sanmarco ‘( dd of=/dev/xen2/vesuvio bs=100M )’
1. Lettura dei dati (Server Locale)

• dd: Richiama il programma di copia a basso livello.
• if=/dev/xen2/argo: Definisce l’Input File. Indica alla macchina locale di leggere direttamente i blocchi binari del volume argo (un volume logico Xen o una partizione).
• bs=100M: Definisce il Block Size. Forza il sistema a leggere i dati in blocchi sequenziali da 100 Megabyte alla volta. Questo riduce drasticamente il numero di operazioni di lettura sul disco locale, saturando la cache della RAM.

2. Il reindirizzamento (Pipe)

• |: Questo operatore prende l’output binario generato dal dd locale (i blocchi da 100MB appena letti) e, invece di mostrarli a schermo o salvarli in un file locale, li “incanala” direttamente nello standard input del comando successivo.

3. Il trasporto sicuro (SSH)

• ssh root@sanmarco: Apre una sessione crittografata verso il server remoto denominato sanmarco (risolto tramite DNS o file /etc/hosts), autenticandosi direttamente come utente amministratore root.

4. L’esecuzione remota e la scrittura (Server Remoto)

• ‘ ( dd of=/dev/xen2/argo bs=100M ) ‘: Tutto ciò che si trova dentro le virgolette singole viene inviato al server remoto e racchiuso in una subshell (creata dalle parentesi tonde ( … )).
• dd: Avvia l’istanza remota del programma.
• of=/dev/xen2/argo: Definisce l’Output File. Indica al server remoto di prendere i dati che stanno arrivando dalla rete tramite la pipe e di scriverli direttamente, byte per byte, dentro il volume /dev/xen2/argo locale di sanmarco.
• bs=100M: Imposta la dimensione del blocco di scrittura a 100MB sulla macchina remota. In questo modo il server remoto alloca un buffer in RAM della stessa identica dimensione dei pacchetti in arrivo, ottimizzando la scrittura sul disco di destinazione.
Funziona molto bene ma è abbastanza lento, se siamo all’interno della LAN e le macchine sono fidate la cosa diventa penosa o quasi, quindi a furia di cercare in Internet ho trovato una soluzione decisamente più veloce che è questa:
su pedretti che è il mittente scrivo
dd if=/dev/xen2/vesuvio bs=100M status=progress | mbuffer -m 256M -q | nc -q 10 sanmarco 9000

ddLegge e scrive dati grezzi (raw), bit per bit.
if=/dev/xen2/vesuvioInput File: legge dal device (disco/volume) di origine.bs=100MBlock Size: legge a blocchi da 100 MB. Blocchi grandi migliorano le prestazioni su device e rete.
status=progressMostra avanzamento in tempo reale (byte copiati e velocità).
|Pipe: passa l’output del comando precedente come input al successivo.
mbuffer -m 256M -qBuffer in memoria da 256 MB. Serve a “ammortizzare” le differenze di velocità tra disco e rete.
-q = quiet (meno messaggi).
nc -q 10 sanmarco 9000netcat apre una connessione TCP verso l’host sanmarco sulla porta 9000 e invia i dati. -q 10 = dopo che l’input finisce (EOF da dd), aspetta 10 secondi prima di chiudere la connessione. Questo aiuta a non troncare i dati.

su sanmarco che è il destinatario scrivo
nc -l -p 9000 | mbuffer -m 256M -q | dd of=/dev/xen2/vesuvio bs=100M status=progress conv=fsync
nc -l -p 9000netcat in modalità listen (-l) sulla porta 9000. Resta in ascolto e, quando arriva la connessione da pedretti, inoltra i dati ricevuti.

|Pipe.
mbuffer -m 256M -qStesso buffer da 256 MB del lato mittente. Utile perché la scrittura su disco può essere più lenta o irregolare della ricezione di rete.
ddScrive i dati grezzi.of=/dev/xen2/vesuvioOutput File: scrive sul device di destinazione (sovrascrive tutto quello che c’era).
bs=100MStessa dimensione di blocco del mittente (consigliato per coerenza).
status=progressMostra avanzamento della scrittura.
conv=fsync Dopo ogni blocco (o a fine scrittura) forza il flush sul disco (fsync). Riduce il rischio che i dati restino solo in cache e vadano persi in caso di crash o spegnimento improvviso.

L’ordine di esecuzione è importante
prima lanciare il comando sul destinatario in questo caso sanmarco

poi sul mittente in questo caso pedretti

Decisamente molto più rapido, il contro è che il traffico non è criptato, ma in LAN e ripeto tra macchine fidate fa decisamente la differenza.

Tagged with: dd | mbuffer | netcat | SSH

Categorised as: Linux | Work

Comments are disabled on this post