Newsgroup: it.comp.os.linux.sys
Titolo: file di backup: meglio compressi o no?

Quando si scrive uno script che esegue il backup di una certa directory 
di dati (per esempio una maildir), preferite che la copia venga poi 
compressa in tar.gz per limitare lo sapzio occupato oppure la lasciate 
sotto forma di directory in modo tale da evitare il problema che la 
corruzione del file compresso renda inutilizzabile l'intero backup?


Se posso permetterlo non comprimo.

 corruzione del file compresso renda inutilizzabile l'intero backup?
Perchï¿œ l'archivio dovrebbe corrompersi? Se ï¿œ un problema di FS non potrebbe 
comunque corrompersi la directory Maildir? Perchï¿œ la corruzione di un 
archivio dovrebbe rendere inutilizzabile l'intero backup?
-- 
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.

 
Con "intero backup" intendevo il file tar.gz che contiene i miei n-mila 
dati. Puo' capitare che risulti impossibile aprirlo per un bit mal 
messo, e se mi capita sulla directory non compressa al massimo perdo un 
file e non anche tutti i suoi vicini.
Mi interessava piu' che altro un parere da chi lo fa di mestiere.

 Mi interessava piu' che altro un parere da chi lo fa di mestiere.


> Mi interessava piu' che altro un parere da chi lo fa di mestiere.
Dimenticavo. Io in genere comprimo sempre i backup, sia per una questione di 
spazio (al posto di un bck ne faccio stare 2) sia perchï¿œ spesso ï¿œ una 
necessitï¿œ (il tape ï¿œ piï¿œ piccolo della quantitï¿œ di dati da salvare) sia 
perchï¿œ in certi casi trasferisco i backup via rete su altre macchine, 
talvolta in altre sedi, quindi si risparmia tempo e banda.


 
Ok grazie per il tuo consiglio. alla fine procedero' facendo la 
compressione della mia directory.
Ciao.

 
Quoto: si risparmia un mucchio di spazio e di tempo per le copie.

 Mi interessava piu' che altro un parere da chi lo fa di mestiere.
Io ho due cents di appunti (copy & paste)
Vantaggi di afio:
- velocita'
- preserva soft e hard link piu' altre cosette.
- i file vengono zippati SINGOLARMENTE
- Trattamento di archivi danneggiati "piu' morbido"
[ Copia da directory a directory con afio (Debian reference manual) ]
=====================================================================
# find . -depth -print0 | afio -px -0a /new/path
[ Creating afio archive: ]
==========================
# cd /path/origine/backup
# find . -depth -print0 | afio -0a -x -v -L ../archiveLog -o ../archive.afio
(oppure con Compressione dei SINGOLI FILE!!!)
# find . -depth -print0 | afio -0a -x -Z -v -L ../archiveLog -o 
../archive.afio
NB: Opzione utile di find: -xdev = non discende le directory su altri 
filesystem
[ Restoring afio archive: ]
===========================
# cd /where/to/extract
# afio -i -v -x -L ../extractLog ../archive.afio
(oppure con Compressione dei SINGOLI FILE!!!)
# afio -i -v -x -Z -L ../extractLog ../archive.afio
 (Opzioni per ripristino file specifici - con globbing)
# afio -i -v -x -Z -y '/home/me/thedir/thedir/thefile*' /dev/tape (o 
/path/archivio.afio)
(protegge file esistenti con -n )
# afio -i -v -Z -n archive.afio
[ List di un archivio: ]
========================
# afio -t  archive.afio    (-tZ  se zippati i singoli files)
# afio -tv archive.afio    (-tvZ se zippati i singoli files)
[ Verifica di un archivio ]
===========================
# cd /path/of/the/source/archive
# afio -r  ../archive.afio                       (-rZ)
# afio -rv ../archive.afio                       (-rvZ)
# afio -rv -L ../verificaLog ../archive.afio     (-rvZ)
[ Splitting e ripristino ]
==========================
# cd /path/origin/backup
# find . -depth -print0 | afio -0a -v -o - | split -b 1m -
../archive.afio_split.
# cd /where/to/extract
# cat ../archive.afio_split* | afio -i -v -
Ovviamente, '-Z' a piacere.
  Sono appunti del 2007, spero siano ancora validi.Uso questo comando 
saltuariamente con knoppix o systemrescue. -- UrT 

Ale wrote:

tar + gzip non + come il formato zip, tar è un formato di archiviazione
progressivo e quindi anche la compressione è progressiva (sotto qualche
dettaglio), quindi in caso di corruzione si perde qualche dato in più,
mentre con il formato zip è molto più probabile di non potere accedere
completamente all'archivio (però il formato zip è più efficiente in
compressione/decompressione).
Per capire cosa intendo con progressivo prova a scaricare un archivio
tar/tgz e ad interrompere lo scaricamento, noterai che è possibile accedere
e scompattare l'archivio senza problemi, e anzi, se non si presta
attenzione all'errore di prematura fine del file, c'è il rischio di non
accorgersi di non aver a disposizione tutto il contenuto.

 compressa in tar.gz per limitare lo sapzio occupato oppure la lasciate
]zac[
A proposito, perché "POI COMPRESSA", se intendevi usare prima tar poi gzip
secondo me conviene comprimerla al volo (per esempio con l'opzione -z di
tar).
Altrimenti, come non detto.

 Altrimenti, come non detto.
Beh si certo quando possibile!
Per il discorso dello zip, adesso ho un server imap che per certi motivi 
deve essere su windows. La funzione di backup inserita nel software 
(hmailserver) genera un file compresso con formato zip, ora vedro' se 
posso modificare lo script in visualbasic e fargli fare un tgz.
Grazie per il contributo.

 
Anche io spezzo una lancia in favore di afio, qualche anno fa mi salvò un 
ripristino da un DAT bizzoso (subito dopo sostituito con un DLT).
-- 
Tobe

 Grazie per il contributo.
Forse ti ho portato fuori strada, ma sia i formati tar che zip sono
discretamente affidabili per un uso come backup (è un discorso generele è
evidente che siano casi in cui evitare certi formati).
Poi il porsi il problema del recupero del backup in caso di corruzione
dell'archivio è solo una questione teorica, se c'è una corruzione
l'archivio non è da utilizzare.
In sintesil'unica soluzione è quella di avere backup rotativi/giornalieri,
il formato dell'archivio è nel 99,99% dei casi ininfluente sulla
affidabilità del recupero dei dati.
P.S. Immagina che il danno sia nella parte iniziale dell'archivio o magari
su più punti, o altri casi simili, e vedrai che il formato dell'archivio e
della compressione perde molto di importanza.

 deve essere su windows
Se il motivo e` dato dal fatto che hMailserver esegue lo storage delle
email su database, prova dbmail
Enrico
P.S. spero per te che tu non abbia usato SQL Server o MySQL per lo
storage...

 storage...
Allora, la versione 5 di hmailserver lavora di default su Microsoft SQL 
Server Mobile Edition, comunque si tratta di una piccola installazione 
con due account per ora e mezzo giga di email.
Mi serviva l'imap per avere la possibilita' di accesso concorrente da 
piu' client. In realta' poi credo che le mail vengano salvate su file 
system, e nel db ci siano solo gli indici o roba del genere.

 system, e nel db ci siano solo gli indici o roba del genere.
Molto probabile, credo che funzioni cosi anche mdaemon + asm archiver, in
alcune directory sono archiviate le e-mail in formato raw, e nel database
c'è l'indicizzazione delle e-mail.
Cosa che poi consentirebbe di ripristinare il database riparsando le e-mail
memorizzate.
Poi anche asm usa msql, e funziona piuttosto bene.

 system, e nel db ci siano solo gli indici o roba del genere.
A parte che cosi` mi sembra una boiata (o salvi tutto su db, o usi un
altro metodo per indicizzare), se le mail sono in formato raw allora
sono facilmente portabili su di un server linux (alla peggio, visto che
dici che sono solo due account, implementi il server in parallelo e fai
una migrazione IMAP to IMAP)
Enrico

 Enrico
Si certo, ma visto che il server windows deve funzionare comunque 
(abbiamo un applicativo che si appoggia a MSDE), almeno concentrando 
tutti gli altri server sulla stessa macchina risparmio corrente, spazio 
e manutenzione.
Comunque il discorso da cui ero partito, che e' di carattere generale, 
e' ormai chiarito. Grazie a tutti.