Esattamente... però pensandoci bene i risultati che si ottengono sono equivalenti come accennavo nel post precedente:
1- l'immagine chiamiamola raw compresa con gzip non è montabile. Anche l'immagine speciale compressa con gzip non è montabile.
Intendo che in entrambi i casi non abbiamo un'immagine da dare in paasto direttamente a mount... entrambe sono compresse.. E giustamente alla fine, perchè così tengono poco spazio.
2- la dimensione delle due immagini compresse è circa identica. Quindi in entrambi i casi possiamo mettere i backup su supporti poco capienti.
3- Il restore è in entrambi i casi possibile. Con l'immagine speciale sfruttiamo la funzionalità e l'efficenza di ntfsclone. Con limmagine raw ci affidiamo al vecchio dd. Il risultato alla fine non cambia anche se si tratta di vedere i tempi in gioco... con i test che sto facendo in qemu i due ripristini sono pressochè identici, forse con immagini di filesystem più capienti e pieni si noterebbero differenze rilevanti.. questo non lo so.
4- Vediamo ora la questione mount al volo. Con l'immagine raw basta gzip, si scompatta e si monta senza problemi. Con l''immagine speciale invece non basta scompattarla... Ma un comando del tipo:
Codice: Seleziona tutto
gunzip -c special.img.gz | ntfsclone -r -o special_2_raw.img -
ci consegna un'immagine raw del nostro filesystem... come se avessi fatto il backup raw senza opzione --save-image di ntfsclone. L'ho testato e l'immagine che che ne esce è tranquillamente montabile in loop.
Quindi entrambe le immagini sono montabili però l'operazione, avendo già in partenza l'immagine raw è più rapida perchè basta scompattare... qua i tempi non sono trascurabili ntfsclone -r impiega ovviamente molto di più rispetto al semplice gunzip.
Conclusioni:
- se siamo pressochè sicuri di non dover usare le immagini del backup montandole al volo in loop è meglio clonarle con il formato speciale di ntfsclone. Perchè il restore sarà ottimizzato e un po' più rapido.
- se invece quasi sicuramente dobbiamo montare le immagini al volo ecco che l'immagine raw è meglio in quanto basta scompattare con gzip, operazione piuttosto rapida. Inoltre consente comunque il restore grazie a dd, ancorchè accettando tempistiche lievemente peggiori.
- I tool coinvolti per backuppare un disco con partizione NTFS allora sarebbero gunzip (o chi per esso) dd (per il mbr serve comunque) ntfsclone, ntfsresize. Poi se il disco dobbiamo clonarlo su un disco "vergine" allora anche blockdev (o chi per esso, anche fdisk può rileggere le partizioni, o partprobe per dirne un altro) torna utile.
Direi che è tutto.
Aggiungo (visto che è andato tutto perso col problema al server) che ho lavorato esclusivamente dal CD live di Clonezilla. Si è rivelata una distribuzione dotata di tutto il necessario, anche se un po' lenta ad avviarsi in qemu (ma lì devo dare prima di tutto la colpa al mio hardware obsoleto).
Aggiungo anche che avevamo concluso che prima di maneggiare il filesystem con ntfsresize ecc, è meglio per sicurezza fare una copia dell'interol disco su un file immagine usando il wizard di clonezilla.
Devo dire che ho testato la cosa ed è filato tutto liscio durante l'operazione. Ma rilevo un problemino dopo una simulazione di ripristino su un disco identico a quello di partenza.
Infatti ho ripristinato l'immagine del disco (virtuale)di partenza su un secondo disco (Sempre virtuale).
Ho poi avviato qemu dandogli in pasto questo secondo disco. Ma all'avvio non succede nulla. Devo chiudere qemu. Al successivo tentativo appare la schermata di window dove richiede di avviare inmodalità provvisoria o normalmente ecc. Se scelgo di avviare normalmente windows clonato parte. Però alsuccessivo riavvio ho lo stesso problema... probabilmente clonezilla non ha ripristinato il disco proprio come avrebbe dovuto, non so neanche come si possa risolvere. se avete esperienze in merito o idee benvengano.
Ad ogni modo usando i tool semplici l'operazione mi è parsa molto più rapida, almeno su qemu... però per sicureza un'immagine dell'intero disco prima di mettervi mano va fatta.
Alla prossima!