Newsgroup: it.comp.os.linux.sys
Titolo: backup remoto

Hola, tempo fa avevo un link su un programmino per fare il backup remoto da 
server linux/windows, in modalità incrementale e adatto anche per linee 
povere (ovvero adsl). Ovviamente tale link è andato perso :-(
QUalche consiglio?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
"A power so great, it can only be used for Good or Evil!"
		-- Firesign Theatre, "The Giant Rat of Summatra"

 QUalche consiglio?
comincia facendo un *backup* del tuo bookmark :-)
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 QUalche consiglio?
A parte farsi a manina gli rsync, hai provato a vedere Bacula?

 A parte farsi a manina gli rsync, hai provato a vedere Bacula?
Non capisco come non vi agiti l'idea di mettere i vostri backup dentro un
server MySQL. 
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 QUalche consiglio?
rdiff-backup.


DeepBlue ha scritto:

'mo lo segno e lo guardo
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Some programming languages manage to absorb change but withstand
progress.

 un server MySQL.
??? che intendi dire?
Grazie, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

DeepBlue ha scritto:

mmmm.... non gira su win in modo semplice direi
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Good leaders being scarce, following yourself is allowed.

 
questo come ti sembra? Era quello che citavo all'inizio
http://www.cis.upenn.edu/~bcpierce/unison/
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Flappity, floppity, flip
The mouse on the m" obius strip;
	The strip revolved,
	The mouse dissolved
In a chronodimensional skip.

 
http://www.cis.upenn.edu/~bcpierce/unison/
Ma tu devi fare un backup? E allora il concetto di numero di versione non ti
serve.


 ??? che intendi dire?
Significa che i dati di backup devono essere memorizzati in modo tale che
sia il piu' immediato possibile recuperarli, perche' quando stai sotto
tensione che devi ripristinare un backup, non devi avere nulla che POSSA
andar male o richiedere configurazioni o parametri o qualsiasi altra cosa.
Se hai dei dati su un db MySQL, certo sicurissimo che funziona tutto e va
tutto bene, ma hai uno strato in piu' per l'accesso agli stessi.


 QUalche consiglio?
BackupPC (
http://backuppc.sourceforge.net
)

 
Mah, mi sa che tutti i piů famosi sw di backup fanno cosě. A parte i 
"windowsiani" Backup Exec e Arcserve/Brighstore cxhe usano database SQL 
(il primo) e proprietari il secondo, EMC Legato usa un DB e sarei quasi 
certo al 90% che anche IBM TSM faccia lo stesso.
Se hai la sfiga somma (perdita totale globale e qualcosa di Piů), ritiri 
su il sistema di backup, ci colleghi la libreria e poi parti con i 
comandi per ricostruire il db (ogni oggetto ha i propri) e poi fai i 
restore.
D'altra parte, su DB c'č il "catalog" che usi quando devi fare il browse 
dei nastri alla ricerca di un determinato file, salvandoti un sacco di 
tempo, dato che nel 99,9% dei casi il backup si usa per ripristinare 
files che gli utenti cancellano o (al massimo) server che si fiammano, e 
solo nello 0,1% per un vero e proprio Disaster Recovery
Ah, prima che qualcuno lo chieda: si ho provato (sempre fortunatamente 
in test) e funziona! Poi in caso reale certamente non andrŕ un c...zo!
Se hai alternative (a parte casalinghi tar e gz, utilissimi comunque), 
sarň ben lieto di sentirle
P.S.
io voto per bacula, anche se č relativamente "complesso" da implementare 
poi non perde un colpo

 saro' ben lieto di sentirle
rdiff-backup
oppure fai cp su una directory di un NAS/SAN che ha un sistema operativ che
fa di suo gli snapshot, allora sono disposto a credere che sia realmente
stabile.


 Ho dubbi che sia conveniente fare un backup su nastro, oggi.
Ah beh...
quindi useresti? I dischi usb? I dvd? Un NAS?
-- 
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.

 
http://www.cis.upenn.edu/~bcpierce/unison/
Unison e' bidirezionale, a te non serve.
Bacula usa VSS, potrebbe fare la differenza con windows,
anche se non ci dici nulla su cosa devi backuppare. 
Rsync penso che sia quello che lavora meglio se la banda
e' poca. Eventualmente sotto forma di backuppc, ma anche
no, se i server sono pochi.
Fabio

 quindi useresti? I dischi usb? I dvd? Un NAS?
oggi ci sono tabe-library incredibili, software che fanno cose che voi 
umani non immaginate nemmeno blablablabla. 
Ma il punto e' che la richiesta iniziale di fare dei backup over adsl fa 
pensare di piu' a una cosa spiccia, che funzioni subito, senza troppi 
fronzoli.... e invece tutti subito giu' a far vedere che sanno usare il 
search engine di freshmeat; ed eccoci qua alle tape-libraries.
p.s.: ce ne e' una abbastanza spaziale di IBM che io mi divertito 
tantissimo a guardare mentre era in azione :) era abbastanza strana: 
aveva i bracci al centro, e le cassette attorno, iniziava a muoversi, a 
scorrersi tutti i codici a barre ... una figata.
Potremmo dire a roberto di usare questa per i suoi backup over adsl :)


bio ha scritto:

una serie di server web, per i db faccio il dump e salvo quello.
Il mio problema è che non ho un backup lontano dai server, quindi mi 
servirebbe solo per disaster recovery (ma di quelli grossi, tipo il pc che 
prende fuoco e brucia anche il disco di backup interno)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Passionate hatred can give meaning and purpose to an empty life.
		-- Eric Hoffer

 quindi useresti? I dischi usb? I dvd? Un NAS?
Ne' i dvd ne' i dischi USB, ma un NAS grande ha un costo per GB piu' basso
di un nastro, senza considerare la velocita'. Ti consiglio di leggere
"Backup and Recovery" della O'Reilly, anche io pensavo di implementare una
soluzione di backup via nastro ma quel libro e' stato illuminante.
"Do not make the mistake of comparing only the price of the media: tape 
will always win"
"The biggest advantage that disk-as-disk targets have over most VTL targets
is their cost. Most disk-as-disk systems cost less per gigabyte than VTL
systems because you're not paying for the value of the VTL software."
Allora una regola generale non esiste, e uno centro molto grande magari usa
un NAS come staging area di una VTL, ma il costo vero che c'e' nei nastri
(intesi come una unita' molto capiente) e' che ci vuole qualcuno che
fisicamente metta il nastro dentro e poi lo vada a ritirare. Questo e'
ottimo quando devi fare dei backup e vuoi conservarli in un'altra sede, ma
se hai due sedi diventa solo un costo in piu' dell'omino che ritira il 
nastro e lo archivia.


 servirebbe solo per disaster recovery 
Vedi se non ti convenga usare Amazon S3 o altri servizi analoghi.


 un NAS come staging area di una VTL,
Appunto. Come staging.


 Ma non soddisfa tutti i requisiti di un backup.
Cioe` ?
-- 
Vincenzo

 Cioe` ?
Per esempio il fatto di poter essere mantenuto inaccessibile dal resto del
sistema mentre non in uso, o poter essere riposto in luogo sicuro una volta
scritti i dati.
Se per esempio ti appoggi su un NAS hai i dati sempre accessibili. Questo è
un vantaggio in caso di restore urgente, ma significa anche che chiunque
dall'interno della rete può comprometterli, 
p.es
. un potenziale attaccante o
un worm, o ...
Inoltre nessuna banca accetta NAS nelle cassette di sicurezza.
Si possono fare mille cose in base alle esigenze (io stesso uso backuppc per
fare il backup di 120 "server" Linux), ma la destinazione finale dei dati in
un sistema di backup realmente efficace, è sempre un media che soddisfi i
requisiti di affidabilità, economicità, capacità e rimovibilità.
Non è detto che si tratti obbligatoriamente dei nastri, ma per il momento i
media ottici non garantiscono l'affidabilità e la capacità, i magneto-ottici
non sono economici, i dischi non sono né rimuovibili né affidabili, ecc.ecc.
I nastri invece durano almeno 30 anni (e non è un tempo calcolato ma è
*reale* dato che nastri di 30 anni fa sono stati effettivamente letti ai
giorni nostri), sono economici (70euro a tape), sono capienti (1.6TB per
tape), sono rimovibili.
Oggi, volenti o nolenti, lo strumento elettivo per fare i backup è e resta
il *nastro*.


 il *nastro*.
E io che temevo fosse solo una mia convinzione da vecchio retrogrado
nonno monomediale. ;-)
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 il *nastro*.
Quoto.
C.

 *reale* dato che nastri di 30 anni fa sono stati effettivamente letti ai
Un disco ventilato opportunamente puo` durare anche 10 anni. In ogni 
caso c'e` il raid che mi mette al sicuro. E poi devi anche vedere se 
dopo 20-30 anni hai ancora il lettore funzionante per leggere quel nastro.
-- 
Vincenzo

 quelli. Poi li sostituisco con dischi nuovi e mi ricostruisco il raid.
Tutte le settimane?
C.

 il *nastro*.
Dipende sempre dal tipo di dato di cui devi fare il backup (che è un
concetto molto ampio). Se sono dinamici, il nastro non serve manco per le
balle. Se devi fare backup di dati storici, il nastro è perfetto.
-- 
Vide

 
Bacula NON mette i dati backuppati su rdbms, ma solo le info relative 
all'inventario dei file backuppati.
I file archiviati puoi ripristinarli in qualsiasi momento con utility a 
riga di comando.
Inoltre NON supporta solo mysql, ma anche sqlite e postgres.
Ciao.

 dopo 20-30 anni hai ancora il lettore funzionante per leggere quel nastro.
lo stesso discorso vale per controller raid et similia...
ilSimo
-- 
now playing: 
I'm a rebel - rebel - don't you just know it
I'm a rebel - rebel
And they're all laughing at me
                                Accept - I'm A Rebel

 lo stesso discorso vale per controller raid et similia...
Nessun controller hardware, raid 1 software. Pulito e garantito.
-- 
Vincenzo

 Non e` una situazione rischiosa.
mah, dipende dai punti di vista....
ilSimo
-- 
now playing: 
"Suddenly I awoke. I must have fallen asleep under the oak,
where I used to sit and dream as a child
The dawn was soon to come, and the air was crisp and cold
Yet I felt warm
I remembered my strange dreams and knew I had the strength
and love in my heart to create something in my life.
The world was waiting I was reborn"
                                Candlemass - Dawn

 dopo 20-30 anni hai ancora il lettore funzionante per leggere quel nastro.
Mentre i dischi di 30 fa tu li leggi ogni giorno, vero?
Se il dato è importante non è un problema tecnologico leggerlo dai nastri; è
solo una questione di costi.


 Ah... e dimmi, ti mette al sicuro anche da un rm -rf / ?
Ti prego non scriverlo piu'..... sento i brividi lungo la schiena solo a 
vedere una cosa simile !!!
brrrrr :( :( :(
Rizio

 solo una questione di costi.
Lo stesso posso dire dei dischi. Li rinnovo periodicamente. E` solo una 
questione di costi.
Comunque si`, mi avete convinto il nastro e` piu` comodo.
-- 
Vincenzo

 ...
mmh ... normalmente questa non e' un'esigenza, ma una operazione di 
routine settimanale.
c'e' da dire invece che si possono avere avere storage replicati tra sedi 
lontane tra loro. Addirittura dei cluster in fail-over con i server 
ubicati in due sedi differenti.... ma ... per il ripristino dei dati ad 
uno stato precedente (in seguito a classica cancellazione o errore 
dell'utente), questa soluzione non e' assolutamente di aiuto.


 il *nastro*.
Questo e' il tuo pensiero, non una verita' inconfutabile.


 riga di comando.
Utility a livello di tar o cose piu' esotiche?


 solo una questione di costi.
Anche prendere il disco e mandarlo ad un laboratorio specializzato.
Ripeto, nel costo di tutto devi mettere tutto, compreso il fatto che il
nastro richiede un operatore e un NAS no. Secondo quanto devi backuppare,
e perche', puo' essere un fattore critico o meno, per cui dire che il nastro
e' la scelta corretta non e' vero, e' una generalizzazione eccessiva.


 Ah... e dimmi, ti mette al sicuro anche da un rm -rf / ?
Sì ma qui stai mischiando cose e cose. Manco un nastro ti salva da un
rm -rf /, visto che avrai un downtime prolungato. Anzi, probabilmente se
stai salvando su dischi/nas/ immagini intere della macchina, la soluzione
nas in questo caso ti protegge anche dal rm -rf /, o almeno recuperi più
velocemente.
-- 
Vide

 Sì ma qui stai mischiando cose e cose.
No, nessuna mischia. Semplicemente in questo caso si parlava del RAID. :-)


 Questo e' il tuo pensiero, non una verita' inconfutabile.
diciamo che dipende dalle circostanze?
Come si fa (con le tecnologie a disposizione) a catalogare i dischi?
E' chiaro che potrebbe essere fattibile, ma le tecnologie attuali fanno 
questo con le cassette e non con i dischi.
Penso che una GRANDE azienda che ha l'esigenza di salvare ogni mese tutti 
i dati degli ultimi 10 non usera' dei dischi.
Anche perche' non esiste una tecnologia come quella della tape-library.
Non esistono robot che smontano i dischi, ma esistono robot che prelevano 
le cassette dalle "scaffalature", e li catalogano tramite i bar-code.


 :-)
si pero' state mischiando piccole, medie e grandi aziende.
E questo incasina la discussione piu' di tutto.
In una piccola azienda, probabilmente io scrivero' le etichette sulle 
cassette (ci scrivo lunedi' settimana I, e cosi' via), faccio la 
rotazione settimanale e fine della discussione.
In teoria questo diventa quasi fattibile anche con i dischi.
In una grande azienda io non posso scrivere le etichette e ci vuole la 
tape-library che cataloga le cassette, che le prende automaticamente in 
base alla richiesta fatta dall'operatore per il restore richiesto e cosi' 
via. Questo oggi con i dischi non credo sia fattibile.
quindi la discussione a seconda dei casi prevede 2 risposte diverse.


 e' la scelta corretta non e' vero, e' una generalizzazione eccessiva.
Difatti ho detto che il nastro è lo "strumento elettivo", non l'unico o
quello migliore in assoluto. Certamente quello adatto al 99% dei casi.


 Questo e' il tuo pensiero,
Mi pare che sia il pensiero di molti, specie di chi ha già perso i dati e sa
cosa significa avere un backup.


 
E verificare con un restore ogni tanto...


LOL... mi viene in mente un mio cliente.
Gli era stato detto di verificare giornalmente l'esito del backup, ma
comunque gli veniva spedita giornalmente una mail in caso di esito negativo.
Ovviamente il cliente, una volta visto che la in caso di problemi arrivava
la mail, ha smesso di verificare l'esito del backup dal programma, fidandosi
del report e fregandose delle mie indicazioni.
Poi un bel giorno ha deciso di cambiare IP al server di posta, senza
ovviamente cambiarlo nel server di backup. Visto che la sfiga ci vede
benissimo, dopo pochi giorni, a seguito di un aggiornamento, il software di
backup ha iniziato a non eseguire più correttamente il backup, ma la
segnalazione di errore ovviamente non veniva inviata e il pirla non
controllava il software, ed intanto i giorni passavano, passavano, passavano
superando i tre mesi.
Tutto questo finché non ha avuto necessità di recuperare i dati
importantissimi erroneamente cancellati. Ha quindi aperto il software di
backup e si è ritrovato con pagine e pagine di righe rosse dal misterioso
significato, chiamando quindi l'assistenza tecnica.
Risultato: 1500 euro per il recupero dei files cancellati, un giorno di
fermo servizio, e un cliente che tutti i giorni verifica l'esito del backup
dal programma.


 diciamo che dipende dalle circostanze?
E' satto.


 quello migliore in assoluto. Certamente quello adatto al 99% dei casi.
E' quello "adottato" nel 99% dei casi, non quello adatto. 


 cosa significa avere un backup.
Guarda, a Tor Vergata per il centro in cui sono sistemista abbiamo due sedi, 
a circa un km di distanza, gli informatici stanno tutti da una parte,
insieme ai server, il server di backup via NAS stara' all'altra sede, ora tu
_realmente_ pensi che abbia senso mettere un backup via nastro come sistema
d'uso quotidiano, cosi' che ogni giorno io faccia su e giu' a ritirare i
nastri? Oppure li lascio ritirare a persone che informatici non sono? Prima
che rispondi, prendi "Practical Internet and Unix Security" e cerca il box
"What tapes", la storia di un non informatico che per mesi faceva i backup
senza infilare il nastro perche' il programma a monitor non lo chiedeva
_esplicitamente_.
Cio' detto, io posso fare due cose: a) comprare un backup a nastro e
chiedere un altro informatico il cui compito sia l'estrazione e l'inserzione
del medesimo, e non posso pagarlo 100 euro al mese per il lavoro, e' uno
stipendio in piu'; b) usare un NAS, un bel NetApp non pizza e fichi, e
averlo unattended (monitorato ovviamente via SNMP e sistemi di mail
automatiche da illo generate). Tu che consigli di fare, dall'alto delle tue
convinzioni? Metto 20k in budget in piu' all'anno per avere un ritorno quasi
nullo, o ne spendo 20k per un buon NAS? 


 Utility a livello di tar o cose piu' esotiche?
Il formato in cui salva i backup e' suo "proprietario", ma con utility a 
riga di comando (sempre "proprietarie") estrai i file .
Ciao

 nullo, o ne spendo 20k per un buon NAS? 
Dico che evidentemente non hai capito nulla di tutto quel che è stato detto
(cosa che non è una novità in effetti), che quella della persona dedicata è
una cazzata galattica, che se i dati sono importanti la tua strategia di
backup è inadeguata (se fossi una banca oggi saresti fuori regola) e che non
vale la pena continuare il discorso.
Sono tutti cazzi tuoi per come fai il tuo backup, ti auguro solo di non
perdere i dati, ma soprattutto spero che per colpa delle tue scelte non ci
rimettano altri (come talvolta accade).
Ora ti lascio nell'ignore list dove stavi bene; purtroppo la mia fiducia
nell'umanità mi porta sempre a dare nuove occasioni alle persone, ma in
questo caso hai effettivamente dimostrato come io sia in errore.


certo al 90% che anche IBM TSM faccia lo stesso.
A conferma di quanto dice il mio caro collega qua sopra, aggiungo che
non solo TSM usa un DB, ma è un DB veramente particolare. La scorsa
settimana un cliente mi ha illustrato (seppur con poco dettaglio) le
meraviglie del DB di TSM. Ad esempio, anzitutto in una libreria con
due drive e 48 di LTO-4 (con nastri quindi discretamente capienti),
anche se il backup dovesse essere di 1 TB, TSM in virtù del modo in
cui usa il DB, spalma i dati su diversi nastri (anche 4 o 5) in modo
sempre da ottimizzare il restore. Ad una mia osservazione "ma voi il
full quando lo fate" la risposta è stata "mai, perchè per il TSM non
c'è bisogno"; quindi ho contestato "si ma vi si fiamma un server e
dovete recuperare, che so, 2 TB di dati, dove magari c'era roba di
qualche mese fa, vi ci vogliono 3 giorni per recuperare tutto",
risposta loro: "ci è già successo per 1 TB, il dati erano su in meno
di 3 ore"
a questo punto vorrei approfondire il funzionamento di tale DB per
confermare/smentire la veridicità di queste tesi :-)
PS: era una realtà con incrementali giornalieri di 4 TB, in cui a loro
dire, il full non lo fanno da almeno 2 anni.
-- 
The Alley Cat
alley...@gmail.com

will always win"
Un mesetto fa circa, leggevo dal dentista mentre attendevo, un
bellissimo articolo, in una rivista peraltro NON informatica ma
manageriale (era qualcosa del Sole24Ore), sul fatto che negli ultimi
5/8 anni, le aziende che forniscono soluzioni enterprise per il backup
e per il disaster recovery in generale, stanno godendo di un periodo
esageratamente positivo; perchè? perchè i CIO delle enterprise più
rinomate si rendono conto, e non ci vuole molto a convincerne anche i
CEO, che i dati sono il vero tesoro dell'azienda. Provate a pensare ad
una multinazionale che produce una bevanda gassata, piuttosto che una
sigaretta, piuttosto che abbigliamento di qualità; provate a toglierle
tutti i sistemi informatici (meglio, toglietele da oggi a domani tutte
le informazioni di cui dispongono in formato elettronico). L'azienda
improvvisamente muore. Pensate ad una catena di montaggio dove i pezzi
si, continuano ad essere prodotti perchè la catena va avanti, ma non
si sa COSA, quanto e COME si sta producendo. 
Dove voglio arrivare? Semplice. La salvaguardia delle informazioni e
la business continuity sono molto più importanti di qualsiasi cosa.
Pensate che in questi casi si guardi come prima cosa il costo? 
Il disco USB, il NAS e soluzioni simili, vanno bene a casa mia dove
devo farmi un backup dei miei dati personali, non certo per le aziende
(piccole o grandi che siano). 
Natuarlmente il tutto IMHO. 


 dire, il full non lo fanno da almeno 2 anni.
Normale.


 Il disco USB, il NAS e soluzioni simili, vanno bene a casa mia dove
Se a casa tua ti puoi permettere un Net App, vorrei diventare la tua colf.


 Ora ti lascio nell'ignore list dove stavi bene; purtroppo la mia fiducia
No, e' la tua presunzione.


 sede, ora tu _realmente_ pensi che abbia senso mettere un backup via
se casca la connessione, i backup COME li fai ?

 Bacula ho un server da 4TB (in raid 1 - 8 dischi sata da 1TB) che
Perché 8 dischi in raid 1 (suppongo sia raid 10 in realtà ovvero 4
dischi in raid 0 mirrorati su altri 4) e non ad esempio 5 dischi in 
raid 5?
Grazie, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

raid 5?
E' una configurazione più sicura: con 5 dischi in RAID5 si può rompere
solo un disco alla volta, con 8 dischi in RAID1 se ne possono rompere
fino a 4 (non tutte le combinazioni, ovviamente).
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 come fare un full everyday con il traffico di un incrementale.
Yep, lo fa anche netbackup. Si chiama "backup sintetico": in pratica
dagli incrementali ricostruisce lui i full.
bye!

 fino a 4 (non tutte le combinazioni, ovviamente).
Quindi non è più sicura :-)
Il raid 0+1 è indicato se ti servono le performance massime possibili ma con
un minimo di ridondanza, ma non garantisce assolutamente più "sicurezza" del
RAID5 proprio perché tu non puoi sapere a priori quale sarà il secondo disco
a saltare. Affidarsi alla minore *probabilità* di un secondo guasto sulla
stessa coppia significa lasciarsi "corrompere" da un *falso* senso di
sicurezza; la protezione c'è o manca, non può esserci con il 50% di
probabilità :-) (e ho già visto più d'un raid 0+1 andato per la rottura di
due dischi)
Se vuoi maggiore sicurezza puoi configurare un disco di hotspare (che ti
permette di restare scoperto per un tempo inferiore) o, se supportato dal
controller, utilizzare il raid6 (che ha un carico computazionale abbastanza
elevato ma ti protegge *realmente* dal guasto di due dischi).
Con 8 dischi poi guadagni lo spazio di due dischi (il 50% in più) a fronte
di una penalizzazione di performance comunque ridotta ed impercettibile nel
90% dei casi.


 se casca la connessione, i backup COME li fai ?
Se casca la connessione ho altri problemi, anzi molti altri ne avranno di
gran lunga peggiori, perche' e' una fibra nel campus che collega due facolta'.


 backup di dati storici
Che intendi?

permette di restare scoperto per un tempo inferiore) o,
E anche qui si può rimanere a piedi: a me è capitato pochi mesi fa.
Smartarray 641, 3 dischi in RAID1+Spare: un bel giorno sono arrivati
degli errori di scrittura su disco negli eventi di Windows relativi al
controller.
Visto che il diagnostico rilevava l'array e i dischi come "OK" HP ha
pensato di aggiornare il firmware e i driver.
Aggiornati e non è risolto nulla.
Si sono decisi a mandare i dischi ma non è stato possibile
sincronizzare l'array da nessuno dei due dischi perché venivano
rilevati come difettosi.
Un esempio di dubbia coerenza da parte del controller: se considerava
un disco "bad" da rifiutarlo come sorgente per la sincronizzazione,
perché non l'ha buttato off-line subito e sostituito con lo spare?


 E anche qui si può rimanere a piedi: a me è capitato pochi mesi fa.
Il tuo problema però non era imputabile alla struttura RAID scelta, ma ad un
bug del controller; la stessa cosa sarebbe potuta accadere con un RAID6.
Il RAID serve per consentire di mantenere l'operatività in caso di rottura
di uno o più dischi, ma contro la sfiga non c'è raid che resista. :-)


 Che intendi?
Che se sono dati che ogni minuto/ora/giorno cambiano e per cui ho bisogno
solo dell'ultima versione nel caso muoia fisicamente il server su cui
stanno, oppure poter recuperare file cancellati/modificati per sbaglio da
utenti, fare un backup su disco è meglio sotto tutti i punti di vista
(velocità di backup e ripristino, fondamentalmente). Poi, dipendendo
dall'importanza dei dati, si può anche fare uno snapshot giornaliero del
disco di backup su nastro, nel caso di vero disaster-recovery (ti va a
fuoco l'ufficio).
Se invece devo fare copia di backup di access log o qualunque altra cosa che
ormai non si cambia più ma che si deve poter recuperare, il nastro è
perfetto, il non plus ultra.
Sottolineo che parlo di ambienti medio/piccoli.
-- 
Vide

 resta il *nastro*.
quoto alzandomi in piedi :-)
ciao
stefano 

 anni. Un nastro invece *dura* trenta.
<umorismo>
Confermo, io ho ancora delle audiocassette con i dati tuttora leggibili 
del mio primo Commodore Vic20! :)
</umorismo>
Comunque anch'io penso che, sebbene non sia praticissimo, il nastro sia 
la migliore soluzione per l'archiviazione a lungo termine.
Mi chiedo se sono l'unico ad avere CDrom masterizzati una decina d'anni 
fa di buona marca, a bassa velocità e con macchine decenti (per l'epoca) 
che oggi risultano quasi illeggibili...
Ah, nei CD non ci sono backup, eh.

 server ce li hai in giro e non protetti da firewall?
il fatto č che i dati sono su dischi attaccati ad una macchina accesa.. 
contro l'allagamento, l'incendio, l'esplosione o altri problemi di carattere 
NON informatico (in senso stretto) il firewall e la stanza blindata fanno 
poco.. riporre le cassette in altra sede in ambiente protetto č certamente 
piů semplice e sicuro
tutto IMO
ciao
Stefano 

 BackupPC (
http://backuppc.sourceforge.net
)
concordo.. con una particolare versione di rsync che ho trovato da qualche 
parte è supportato anche il VSS; io lo uso per farmi il backup del portatile 
anche in vpn.. non mi accorgo di nulla
Saluti
Stefano 

Ad occhio e croce dopo 22 ore
Sì, considerando un RAID5 + HS mi trovo d'accordo.


Stefano Zamboni ha scritto:

Ok, discussione molto interessante, anche se non pensavo di suscitare un 
simile vespaio
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Without ice cream life and fame are meaningless.

 un simile vespaio
capisco la tua posizione.. ti dirò invece che qualche volta "vespai" del 
genere servono.. ho imparato molto anche da questa discussione.. perchè 
magari si scopre che quello che si fa tutti i giorni (magari frutto di una 
consolidata routine) ha degli aspetti/limiti che non ti sono mai venuti in 
mente.. ma che secondo murphy si riveleranno quando meno te lo aspetti.
Giusto per sapere.. come hai pensato di fare? :-D
Ciao
Stefano 

 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Anybody can win, unless there happens to be a second entry.

 l'epoca) che oggi risultano quasi illeggibili...
è successo anche a noi, la causa del problema l'abbiamo individuata
nell'inchiostro del pennarello usato per scrivere sul cd, con l'andare
degli anni è penetrato letteralmente nel cd e quindi il laser non veniva
riflesso e quindi non si leggeva più nulla, i cd erano di una marca
famosa: ireongvz.
Ciao, Micky
