Newsgroup: it.comp.os.linux.sys
Titolo: Clonare installazione

Ciao,
ho una debian installata su un vecchio disco da 40Gb.
Ora ho acquistato un disco piu' capiente (120Gb) e mi piacerebbe trovare 
un modo rapido per "clonare" l'installazione invece di rifare tutto da capo.
Uso ext3 come filesystem e ho fatto partizioni specifiche per /home /var 
/usr /tmp più una /dati dove metto varie cose.
Esiste un sistema per fare quello che chiedo o è comunque meglio fare 
una nuova installazione ?
Grazie
Fabrizio

 ... 
man dd
man sfdisk



E` abbastanza semplice. Io uso mc, monto le nuove partizioni ricreando la 
struttura del disco sotto /mnt, copio tutti i file mantenendo permessi e 
proprietario. Alla fine reinstalo grub.
Al posto di mc puoi usare tar per mantenere i permessi.
Ci sono comunque degli upgrade howto in giro che lo spiegano 
dettagliatamente.
Bye.

 tutto da capo.
Se avessi due macchine distinte: apt-get install systemimager
Per il tuo caso monta le partizionei del nuovo disco e vai di rsync.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 man sfdisk
Confermo, non conosco un modo più rapido ed efficace che far partire un 
liveCD e dargli in pasto i due dischi:
dd if=/dev/hdx of=/dev/hdy
per poi eventualmente ridimensionare la partizione con parted.
Ciao,
Paolo Costanzo

 una nuova installazione ?
man tar
e procurati una live cd.

Paolo Costanzo ha scritto:

Quindi il suggerimento è copia blocco a blocco delle partizioni in modo 
da ricreare sul secondo disco la struttura identica del primo e poi 
ridimensiono sfruttando lo spazio in piu'?

 ridimensiono sfruttando lo spazio in piu'?
Esatto. Occhio però che devi anche ridimensionare il filesystem con i tools
del filesystem, e che il filesystem deve supportare il ridimensionamento
(reiserfs lo fa di sicuro, ext3 credo anche, altri non so)
Perchè sennò lo spazio nuovo che dai alla partizione non è formattato e non
funzionerà.
-- 
Vide

 Al posto di mc puoi usare tar per mantenere i permessi.
cp -a...

 Ciao, Micky
nooo. E' un buon software, ma per clonare una singola installazione non 
si puo' suggerire di configurare systemimager.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

Il Thu, 26 Jul 2007 12:05:05 +0000, fg ha scritto:

Mi stupisce che nessuno ti abbia suggerito partimage
boh, lo faccio io: usa partimage :)
'dd' e' rudimentale. Non ti consenti di passare i dati su una partizione 
piu' grande, e 'dd' copia tutto, anche i settori vuoti: se hai una 
partizione da 100 giga, con un mega di dati, con 'dd' sarai costretto a 
copiare tutti e 100 giga.



Enorme cazzata.  Conviene formattare una partizione del nuovo disco, 
montarla e poi:
tar cCf / - <lista di directories da copiare> | \
tar xvCf <directory dove è montato nuovo disco> -
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 tar xvCf <directory dove è montato nuovo disco> -
rsync -a -v -H <lista di directory da copiare> \
        <directory dove è montato nuovo disco>
quasi sicuramente è più efficiente.


 quasi sicuramente è più efficiente.
Da prove effettuate, se la destinazione è vergine, il più efficiente è il
banale "cp -a".
Il "migliore" sarebbe star al posto di tar perché presenva anche eventuali
acl, anche se praticamente nessuno le usa.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

Io farei un tar della vecchia installazione
poi monterei le nuove partizioni sotto /mnt
poi tar con -p impostato per mantenere i permessi e -C /mnt per copiare
tutto nelle nuove partizioni
poi chroot nella /mnt
poi grub-install
Se non lo sapete, fg va in giro per it.comp.os.linux.sys a spifferare che:

-- 
Website:                
www.vairasas.net
eBay Shop:      
http://stores.ebay.it/Albireo-Store

 acl
Urca, mica ci avevo pensato...:-)

 eventuali acl, anche se praticamente nessuno le usa.
secoli fa ho fatto una migrazione a XFS delle partizioni (in pratica e' 
come se avessi clonato l'installazione).
Ricordo che usai tar (vecchia versione quindi) e ricordo che mi ha 
"fottuto" gli sticky bit. A quel ho risolto utilizzando 'cpio' .
Se devo essere onesto, oggi non userei ne cpio, ne tar, ne star, ne pax, 
ma semplicemente partimage. Caspita, se non ricordo male, consente 
proprio di riversare i dati su partizioni piu' grosse.


 banale "cp -a".
E dd+resize2fs?
Fabio

 Enorme cazzata.  Conviene formattare una partizione del nuovo disco, 
Mi spieghi per cortesia cosa ti sembra una cazzata? Non riesco a 
comprenderti.
Dato che siamo su .sys e non su .dibattiti sono realmente interessato ad 
apprendere controindicazioni che probabilmente ignoro.
Grazie,
Ciao,
Paolo

 comprenderti.
In fase di formattazione, molti fs (tra cui ext2/3) si auto-ottimizzano 
per le dimensioni della partizione. Possono essere espansi, ma perdi 
alcuni vantaggi (come i superblock sparsi sul disco).
Inoltre, in fase di creazione delle partizioni dovresti ricordarti di 
lasciare il buco nel punto giusto, per poterle espandere dopo.
E, in alcuni casi, rischi di trovarti un "buchetto" non riempibile (per 
problemi di allineamento di cilindri e testine).
Anche io sono dell'idea che e` meglio (e meno rischioso) fare 
direttamente le partizioni delle dimensioni giuste e copiarci la roba 
con tar (o "cp -a" o "mc").
Bye.

 E dd+resize2fs?
Il problema di dd risiede nel fatto che per avere garanzia di riuscita i
dischi dovrebbero avere la stessa geometria. Per questo si usano in genere
programmi ad-hoc come partimage
E se proprio vogliamo essere pignoli, meglio di dd, ci sarebbe il banale
cat, che è fino al doppio più veloce.


 cat, che è fino al doppio più veloce.
Non mi sembra. Dovrei andare a spulciare nei log di putty di 4 o 5 anni
fa, ma mi pare di ricordare di avere fatto varie prove da cui risultava
una sostanziale parita'.
Una differenza grossa potrebbe essere legata a spazio allocato e numero
e dimensione dei file: se ci sono pochi file di grosse dimensioni cp -a
(o tar, o star, o...) e' piu' veloce, ma se i file sono tanti+piccoli e
occupano una parte rilevante della partizione originale, dd puo' essere
molto piu' veloce.
Fabio


dd va bene solamente per copiare dischi uguali.  Ma migrare da un 
disco ad un altro non significa farne un immagine speculare.
In genere ogni disco ha una propria geometria ottimizzata e fare una 
copia a basso livello su di un disco diverso può dare pessimi 
risultati su di un disco diverso.
Il vantaggio di usare tar è anche che i file vengono deframmentati. 
Non che questo abbia importanza enorme visto che la gestione dei fs 
tende a ridurla ma è un miglioramento dei tempi di accesso.


 mai (a memoria) avuto noie. In quali casi potrebbe dare problemi?
si si ... se fai partizione, per partizione funziona.
Pero' poi devi fare il resize e ci vuole altro tempo, poi (come ho gia' 
detto) se la partizione e' 100 giga e i dati sono 1 mega, con dd copierai 
inevitabilmente 100 giga, poi se a 99,99 giga avviene un minimo errore dd 
esce (quindi forse meglio usare ddrescue).
partimage e' una killer application per queste cosette ed e' banalissima 
da usare. L'ultima volta che l'ho usato ho notato che aveva ancora 
qualcosina mancante, ma roba da poco ... per quel che e' stato richiesto 
e' piu' che soddisfacente.
ok. Ai tempi facevo del testing e dovevo ricostruire delle macchine fino 
a 5 volte al giorno. Inizialmente usavamo uno script facente uso di 'dd'. 
Con 'dd' impiegavo ere geologiche. Sono passato a partimage e i tempi si 
sono letteralmente decimati, in quanto partimage copiato solo i dati e 
*non* i blocchi vuoti. Senza contare che con partimage, buttavo i dati 
anche su partizioni piu' grandi.


 una sostanziale parita'.
Ero curioso e ho fatto prima a rifare tutto da capo.
Sui 256 MB di hda4 ci sono le directory di build di snort 2.6.1.5 e 2.7.0
dopo make (piu' le due tarball originali). 68MB in 2675 file. hdc1 e' una
partizione da circa 4 GB su un vecchio disco che avevo nel rottamaio. 
Riporto i tempi di: dd, cat, fsck+resize2fs, mkfs e cp -a. Ne deduco che:
1) dd=cat (real)
2) cp~=dd|cat, ma se solo ci fosse stato qualche file in piu' da copiare,
   i tempi sarebbero stati a favore di dd|cat.
$ time dd if=/dev/hda4 of=/dev/hdc1
498015+0 records in
498015+0 records out
254983680 bytes (255 MB) copied, 21,9945 seconds, 11,6 MB/s
real    0m22.066s
user    0m0.924s
sys     0m8.917s
$ time cat /dev/hda4 > /dev/hdc1
real    0m21.936s
user    0m0.052s
sys     0m5.000s
$ time fsck.ext3 -f /dev/hdc1
e2fsck 1.40-WIP (14-Nov-2006)
Passo 1: Controllo di inode, blocco(i) e dimensioni
Passo 2: Analisi della struttura delle directory
Passo 3: Controllo della connettivitÃ  di directory
Pass 4: Controllo del numero dei riferimenti
Pass 5: Checking gruppo summary information
/dev/hdc1: 2684/62496 files (1.0% non-contiguous), 81832/249004 blocks
real    0m3.316s
user    0m0.144s
sys     0m0.276s
$ time resize2fs /dev/hdc1
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/hdc1 to 4208996 (1k) blocks.
The filesystem on /dev/hdc1 is now 4208996 blocks long.
real    0m11.394s
user    0m0.228s
sys     0m1.696s
$ time mkfs.ext3 /dev/hdc1
mke2fs 1.40-WIP (14-Nov-2006)
Etichetta del filesystem=
Tipo SO: Linux
Dimensione blocco=4096 (log=2)
[...]
real    0m10.672s
user    0m0.392s
sys     0m3.336s
$ mount /dev/hdc1 /mnt/hdc1
$ mount /dev/hda4 /mnt/hda4
$ time cp -a /mnt/hda4/* /mnt/hdc1
real    0m18.664s
user    0m0.220s
sys     0m2.468s

 e' piu' che soddisfacente.
Uhmmmm... ma partimage non mi pare che possa copiare la partizione al
volo: devi passare attraverso i file immagine e poi farne il restore.
In effetti, a ben guardare...
$ time partimage -bcdz0 save /dev/hda4 /root/saveimage
real    0m16.743s
user    0m2.904s
sys     0m4.168s
$ time partimage -b restore /dev/hdc1 /root/saveimage.000
real    0m8.581s
user    0m2.460s
sys     0m2.932s
... non e' male, ma in fondo i tempi sono comunque paragonabili (e si
tratta solo di pochi file) ed occorre lo spazio per l'immagine. 
O si puo' fare al volo? 
Ci sono casi piu' favorevoli? Quali? 
Fabio

 proprio di riversare i dati su partizioni piu' grosse.
Questo lo fa qualsiasi programma che agisce ad un alto
livello (rsync, tar etc etc).

    i tempi sarebbero stati a favore di dd|cat.
Se invece il volume fosse stato di 1GB con gli stessi file, cp avrebbe avuto
un vantaggio netto di oltre il 400% ;-)
IMHO comunque, non essendo operazioni che si fanno 10 volte al giorno, non è
tanto importante il tempo effettivo di esecuzione quanto il trovare la
soluzione che meglio rispetta le proprie necessità.
Io in genere preferisco evitare quando possibile dd e cat della partizione
in quanto a) copiano anche cose inutili, b) mantengono i files frammentati
anche sul disco di destinazione, c) possono dare problemi con le geometrie
dei dischi.
Preferisco quindi usare cp o star perché a) copiano solo lo stretto
necessario, b) il filesystem è nuovo, controllato e perfettamente
deframmentato, c) non subiscono l'effetto nefasto delle geometrie.
Tra questi due poi se possibile uso star perché uso le acl e mi evito di
fare il lavoro in due step. Poi ognuno ha le proprie "filosofie" :-)


proprio di riversare i dati su partizioni piu' grosse.
Ho installato il bellissimo partimage qui sulla Etch.
Ho anche fatto una prova con una partizione da 30 giga, ma
con solo 1.2 giga occupati: e' veramente formidabile e
velocissimo e m'ha fatto questo file:
-rw------- 1 root root 1,7G 2007-07-27 20:55 sda14.partimg.000
dunque non ha incluso lo spazio vuoto quasi per niente (anche
se sarei curioso di sapere perche' m'ha fregato 1/2 giga):
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/sda14             30G  1,2G   28G   5% /mnt/s14
Ora ho pensato di fare questo.
-- Io mi clono tutta questa Deb che prende 4 giga ed e' un'
installazione perfetta e salvo poi il file in un solo dvd
-- poi la verso (mi serve come seconda distro per fare prove)
in un'altra partizione.
Ebbene, adesso mi domando e vi domando: a cosa tutto devo
stare attento per la diversita' tra /dev/sda8 attuale ed
invece /dev/hda11 futura?
Per dire: fstab sarebbe senz'altro da cambiare, ma questo lo
conosco e lo so.
Ma tutti quelli che non conosco? ce ne saranno molti? 
-- 
Saluti, Dalet

 una nuova installazione ?
La butto lì... Clonezilla?!?
http://clonezilla.sourceforge.net/
Ciaoo
-- 
MaoX Blog:
Problemi e soluzioni di un sistemista informatico:
http://maox.blogspot.com

 Ma tutti quelli che non conosco? ce ne saranno molti? 
L'unica cosa che mi viene in mente è nel menu.lst di grub il parametro root
del kernel, sempreché come sopra non abbia usato LABEL o UUID anche lì.


 con tar (o "cp -a" o "mc").
Sì, il concetto è chiaro e operativo; tuttavia per dischi comprendenti 
partizioni non-linux dd permette di dormire tranquilli...
Partimage, invece, ha sì diversi vantaggi ma necessita anche di un luogo 
dove memorizzare il file generato e a volte questo è un problema.
Ciao,
Paolo Costanzo



chiaro.... ma (scusate) sticazzi con i permessi, controlla questo l'altro.
comunque, per una singola installazione tar, rsync vanno bene.


 Ci sono casi piu' favorevoli? Quali?
il caso in cui lo usavo io ^_^
dovevo reinstallare la macchine fino a 5 volte al giorno e tramite script 
richiamavo l'immagine e usavo sfdisk per sistemare la tebella partizioni.
Vuol dire che l'immagine la creavo una volta sola, per cui il tempo 
richiesto per generare l'immagine non incideva per nulla.


 Ciaoo
bellino. 
p.s.: quando la smetteranno con queste transazioni over ssh sara' sempre 
troppo tardi ^_^ Per file di queste dimensioni non ha veramente nessun 
senso ... e poi chi cazzo ti deve sniffare i dati di una partizione raw 
trasmessi su una LAN? mah.


del kernel, sempreché come sopra non abbia usato LABEL o UUID anche lě.
Molto bene! allora solo fstab e lilo.conf, TNX!
-- 
Saluti, Dalet

whiplash wrote:

Volendo c'è anche 'dar' che gestisce le ACL. Forse uno dei tool migliori
per copie di backup...
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 richiesto per generare l'immagine non incideva per nulla.
Aspetta, partimage e' ottimo come strumento per fare copie multiple (o 
anche dei backup): piu' veloce dei *ar, cpio o cp e nessun overhead in 
termini di spazio perche' devi comunque avere l'immagine, ma... non e'
proprio la situazione presentata da fg.
Fabio

 dei dischi.
Continua a sfuggirmi la questione geometria. A parte le coordinate del 
kernel, che potrebbero essere diverse nella copia e pregiudicare cosi'
un boot immediato nel caso usi lilo (problema trascurabile e presente,
in ogni caso, anche in altri metodi di copia) quando e come emergono i 
problemi che citi?
Fabio

 problemi che citi?
Nell'allineamento del fs alla partizione; assolutamente nulla di non
risolvibile ma che comunque può rompere le scatole (per esempio possono
esserci problemi se il FS è parte di un raid software).


 esserci problemi se il FS è parte di un raid software).
Ok.
Se ti interessa, ecco il valore dei time di dd e cat ottenuti 
indicando un bs pari alla dimensione della cache del disco di 
destinazione:
$ time dd if=/dev/hda4 of=/dev/hdc1
498015+0 records in
498015+0 records out
254983680 bytes (255 MB) copied, 21,8276 seconds, 11,7 MB/s
real    0m21.949s
user    0m0.888s
sys     0m8.981s
$ time dd if=/dev/hda4 of=/root/hda4.dd bs=2048k
121+1 records in
121+1 records out
254983680 bytes (255 MB) copied, 25,4349 seconds, 10,0 MB/s
real    0m21.750s
user    0m0.122s
sys     0m5.032s
$ time cat /dev/hda4 > /dev/hdc1
real    0m21.734s
user    0m0.084s
sys     0m4.848s
Il tempo user tra dd con bs e cat e' circa il doppio, come
dicevi tu, ma il real e' sempre lo stesso in tutti i casi,
compreso dd con bs=512 (default).
Fabio

 compreso dd con bs=512 (default).
Sì, + o - stessi risultati che avevo ottenuto io a suo tempo. Come detto la
poca differenza di real time è dovuta al collo di bottiglia dei dischi; se
fosse su un device veloce come una SAN probabilmente si vedrebbe qualche
differenza extra.
Una bella prova sarebbe anche quella di separare lettura e scrittura, per
vedere quale delle due operazioni è maggiormente limitante :-)
time dd if=/dev/hda4 of=/dev/null bs=2048k
time dd if=/dev/zero of=/dev/hdc1 bs=2048k


 vedere lo stato di avanzamento della copia (in cat non e' fattibile),
A titolo informativo, in rete trovi lo script 'bar', che ti fornisce una
progress bar con percentuale ed ETA. Il neo è che appesantisce
abbastanza l'esecuzione, ne sconsiglio l'utilizzo su file grandi..


 mai (a memoria) avuto noie. In quali casi potrebbe dare problemi?
Immagino che sia indispensabile avere LBA.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 acl, anche se praticamente nessuno le usa.
Ho come l'impressione che riceviamo la stessa newsletter :D


raccomandate rsync o tar cpio... 
ma con i file in lock come fate?
E' sottinteso che utilizzate una distro live o no?
e per le partizioni di boot?
tempo fa' usai la dd per copiare la boot e il resto con rsync , il
clone cmq non era esattamente perfetto e inoltre la dd e' lentissima
con spazi > 80 gb 
Grazie 

On Thu, 26 Jul 2007 12:05:05 GMT, fg <fg_NOSPAM@_NOSPAMinfitsrl.com>
wrote:
se non ricordo male utilizzando solo la tar rsync o cpio poi ho cmq
auto problemi con le LABEL delle partizioni.. occhio!