Altre considerazioni sul backup della distro

[omino]

Dunque, come mi era stato consigliato, ho fatto un backup della mia distro: ho utilizzato tar senza però comprimerla (perchè non lo so se il mio pc ce l'avrebbe fatta a comprimere tutta quella roba). La distro sul disco occupa 2.9 Gb

io ho fatto tar cvpf /hda5/bklinux.tar /hda9

poi ho controllato le dimensioni del tar ed ho visto che occupa 2.4 Gb

Secondo voi è normale? Non dovrebbe occupare 2.9 Gb come tutta la distro?

poi per sicurezza mi faccio dei backup anke con gli altri metodi... così sto tranquillo... però non ho capito come mai il tar occupi meno spazio....

Grazie!!! Ciaooooo!!!!

[aschenaz]

Beh, tar comprime oltre che archiviare (meno degli altri formati, ma comprime).

[omino]

grazie!!!!

[albatros]

Beh, tar comprime oltre che archiviare (meno degli altri formati, ma comprime).

Veramente, che io sappia, tar comprime solo se nel creare l'archivio gli dici di comprimere con bzip2 (j), gzip (z) o compress, altrimenti di solito gli archivi tar sono più grandi della somma dei files immagazzinati, contenendo altri dati sulla struttura delle directory e sui permessi, ovvero informazioni contenute nel filesystem che ospita questi files, senza contare gli "spazi vuoti" che tar include o inserisce per il suo modo di gestire i dati (quale di preciso non so, non conosco in dettaglio il suo funzionamento interno e come prelevi i dati dal filesystem e li metta nell'archivio).
Ho creato ad esempio un archivio di prova con due files di testo di 183 e di 371 bytes ottenendo un file .tar di 10240 bytes e visualizzandolo con un editor esadecimale si possono chiaramente vedere migliaia di 0 (oltre al testo dei files a destra (usando khexedit), evidentemente non compresso, più altre informazioni sugli stessi).

Nel caso di omino ipotizzo che 2.9GB sia in realtà la dimensione della partizione /dev/hda9 montata in /hda9 e che tar abbia ovviamente non incluso lo spazio vuoto.
Diverso sarebbe stato il comportamento di un dd if=/dev/hda9 ....

[aschenaz]

Boh, io ho notato che, se i file da archiviare sono molti, alla fine l'archivio è sempre o minore o pressappoco uguale alla somma dei file. Con due o tre file, effettivamente, è come dici tu.

[omino]

nono... la partizione è di 4.5 Gb...... 2.9 Gb è lo spazio occupato a quanto vedo con:
df -h

è possibile che il tar non abbia archiviato tutti i file?
All'inizio avevo pensato che potesse aver saltato i file nascosti... ma facendo una piccola prova ho visto che archivia anche quelli.... e d'altra parte sarebbe molto strano che abbia saltato dei file... tra l'altro non ci sono stati errori durante l'operazione... insomma è andato tutto liscio......... mi vengono in mente solo due ipotesi:
1 - il tar occupa meno spazio poikè è meno frammentato
2 - occupa meno spazio perchè l'ho messo su una fat32 e magari li lo spazio è gestito in maniera diversa
però mi sa strano di aver risparmiato mezzo giga...

[albatros]

Effettivamente lo spazio viene gestito in maniera diversa a seconda del filesystem usato, che può aver bisogno fra l'altro di registrare un diverso numero di metadati.
Posto qui di seguito un mini-esperimento (ho usato un ramdisk per comodità):

Codice: Seleziona tutto

modprobe rd rd_size=100000
modprobe reiserfs
modprobe ext3
mkdir /alfa
mkreiserfs /dev/ram0
mount -t reiserfs /dev/ram0 /alfa

df
Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su
/dev/hda1             30763864  19056012  11707852  62% /
/dev/rd/0                99960     32840     67120  33% /alfa

ls -l /alfa
totale 0

ls -la /alfa
totale 4
drwxr-xr-x  4 root root   80 2007-11-28 21:22 .
drwxr-xr-x 29 root root 4096 2007-11-28 21:09 ..

du /alfa
0       /alfa

umount /alfa
mkfs.ext3 /dev/ram0
mount -t ext3 /dev/ram0 /alfa

df
Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su
/dev/hda1             30763864  19056012  11707852  62% /
/dev/rd/0                96828      5664     86164   7% /alfa

ls -l /alfa/
totale 12
drwx------ 2 root root 12288 2007-11-28 21:39 lost+found

du /alfa
12      /alfa/lost+found
13      /alfa

umount /alfa
mke2fs -m0 /dev/ram0
mount /dev/ram0 /alfa

df
Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su
/dev/hda1             30763864  19056012  11707852  62% /
/dev/rd/0                96828      1550     95278   2% /alfa

ls -l /alfa/
totale 12
drwx------ 2 root root 12288 2007-11-28 21:42 lost+found

du /alfa
12      /alfa/lost+found
13      /alfa

Ci sono delle sensibili differenze a seconda che si scelga un filesystem o l'altro...

[omino]

quindi supponi anche tu che il tar che ho creato.... che sulla partizione in fat32 mi occupa 2.4gb, se trasferito sulla ext3 occuperebbe 2.9gb?

non posso fare la prova poichè non ho abbastanza spazio.

[albatros]

No, per un singolo file non ci dovrebbe essere differenza (almeno per mia esperienza e perché altrimenti avrebbe poco senso indicare sui server ftp la dimensione di un file da scaricare), almeno nella misura della sua dimensione in byte, quello che cambia è lo spazio occupato dai metadati a seconda del filesystem scelto e di come questo è internamente strutturato.
Nell'esempio che ho postato prima, creato un filesystem SENZA DATI dentro, usando df nel caso di reiserfs risultava usato al 33%, con ext3 al 7% e con ext2 al 2%: non so quanto questi dati possano variare cambiando la dimensione del filesystem, né con il suo riempimento, non so, infine, fino a che punto sia consigliabile usare un ramdisk per queste prove, ma si notano comunque differenze notevoli...

[omino]

ok, allora il fatto che il singolo tar su fat32 occupi 2.4Gb è imputabile al fatto che si tratta di un singolo file mentre su hda9 c'è una moltitudine di file?

però lo ritengo comunque strano... visto che precedentemente mi avete fatto notare che l'archivio a se dovrebbe occupare più spazio rispetto a tutti i file che lo compongono.

[albatros]

ok, allora il fatto che il singolo tar su fat32 occupi 2.4Gb è imputabile al fatto che si tratta di un singolo file mentre su hda9 c'è una moltitudine di file?

Quello che sto dicendo è che, se guardi lo spazio occupato con df, il valore che ottieni dipende anche in maniera sensibile dal filesystem usato, tant'è che, nell'esempio che ho riportato sopra, filesystem privi di files (vedi gli output di ls e di du) risultavano occupati dal 2% al 33%...

precedentemente mi avete fatto notare che l'archivio a se dovrebbe occupare più spazio rispetto a tutti i file che lo compongono.

E lo confermo nel mio caso personale usando ext2: quando creo un archivio di files immagazzinati su un filesystem ext2 questo occupa più spazio della somma dei file componenti perché include altre informazioni oltre ai files stessi e spazi vuoti, non so però quale sia il comportamento con altri filesystem (es. ninobi dice di ottenere un file archivio più piccolo). Considera che comunque si tratta di dispositivi a blocchi, che du conteggia come occupati interamente anche se lo sono solo parzialmente con i dati (ma il blocco è comunque occupato).
Un esempio:

Codice: Seleziona tutto

 
mkdir prova
g@darkenergy:~$ cd prova
g@darkenergy:~/prova$ echo "one two three" > qaz
g@darkenergy:~/prova$ for i in $(seq 1 1000)
> do
> cp qaz qaz$i
> done
g@darkenergy:~/prova$ du
4020    .
g@darkenergy:~/prova$ ls -l qaz
-rw-r--r-- 1 g users 14 2007-11-29 09:36 qaz

Come vedi con 1000 files ho occupato 4Mb, mentre teoricamente dovrei aver occupato circa 14KB, evidentemente perché si va a quanti di 4KB.

Scusa se non sono chiaro e preciso e posso anzi sembrare contraddittorio, purtroppo ho pochissimo tempo. Quello che voglio dire è che:
-concorrono più fattori allo spazio occupato da un insieme di files
-tar in sé non comprime i dati (era questa in realtà l'affermazione principale del primo post che ho fatto)
Scusa, ma devo scappare, ciao!

[omino]

quindi è appurato che tar non comprime ed è appurato che un insieme di file su file sistem differenti occupa spazi differenti in quanto non vengono riempiti tutti i cluster.

dunque pensandoci bene se creo un file tar piccolo è normale che esso sia più grande di tutti i file messi insieme poikè aggiunge delle informazioni.
se però prendo un file tar grande mi viene da pensare che l'aggiunta delle informazioni diventa trascurabile in quanto è molto maggiore lo spazio che si va a risparmiare dovuto al riempimento di tutti i cluster (difatti si tratta di un unico file grande e quindi i cluster li riempie tutti) - mentre i file non archiviati non riempiono tutti i cluster.... e questo dovrebbe andare aldilà del file sistem che uso... poi ovviamente con file sistem differenti la differenza può accentuarsi poikè magari i cluster hanno dimensioni differenti.

Alla fine di tutto: ti sembra accettabile il fatto che ho risparmiato mezzo giga? oppure pensi ci sia il rischio che il backup non sia buono?

Ciaooo

[albatros]

Alla fine di tutto: ti sembra accettabile il fatto che ho risparmiato mezzo giga?

Si, per due motivi:
-non vedo errori nel comando che hai dato e non ne hai ottenuti da tar
-credo che in realta' non abbia risparmiato mezzo giga, ma meno, dato che un filesystem 'vuoto' puo' comunque risultare occupato in maniera significativa dando df