Corretto approccio e sistema di backup

[KIDDO1412]

Salve a tutti, come da oggetto sono a richiedere consiglio sul come e dove fare il backup di un server il cui utilizzo è controller di dominio, file server e database gestionale.

Premetto che vi è un unico hard disk ridondato per sistema operativo e i ruoli sopra decritti e che la capacità massima dello stesso è dimensionata a 500 GB (utilizzo attuale 100 GB in tutto, si è ultra abbondato), pertanto non vi sono grosse richieste in merito allo storage di backup.

In particolare pensavo a un backup completo notturno di tutto l'hd, os e file inclusi (sarebbe il famoso ghost? :D ) settimanale e poi per i restanti 6 giorni un backup notturno solo dei nuovi file o di quelli che son stati modificati, da decidere se conviene farlo per tutto l'hd o solo per le cartelle di database e file server, considerando anche che nella condizione ideale al server non viene mai fatto nulla: è già installato tutto quello che serve, si limita ad offrire i ruoli che gli sono stati impostati.

Per quanto riguardo lo storage io pensavo ad un nas anch'esso con sistema ridondante raid 1, basterebbe un due bay 2x3TB, magari con gli hard disk Western Digital Red. Su questa linea stavo valutanto i classici qnap e synology, diciamo però che il ds-214+ della synology è in media 200 euro meno caro rispetto alla controparte qnap ts-269 pro e considerando che dovrebbe fare solo da backup probabilmente credo possa bastare... sbaglio?

Inoltre, per far fronte ad eventuali situazioni di disaster recovery pensavo di alternare due hard disk esterni di settimana in settimana, su cui sarebbe eseguito il backup completo totale assieme a quello sul nas...
Purtroppo conosco i limiti e problemi che può dare questa situazione ma non ho edifici contigui alla sede aziendale ove stoccare un eventuale altro nas e la velocità di internet fa passare la voglia anche solo a pensarle certe soluzioni cloud o similia...
Cosa ne pensate? Si potrebbero valutare altre soluzioni per tal cosa? Non vorrei che prendesse fuoco la sede e ciao ciao server e backup :(

Passiamo infine al software... cos'è consigliabile utilizzare? Ho letto sfogliandomi discussioni simili che è bene ricorrere ad un software specifico che consenta la copia di tutti i file, perchè diversamente soluzioni come copian backup avrebbero problemi a raggiungere tal obbiettivo...
Come se la caverebbero in tal senso Backup Assist o Backup Exec?

Grazie mille in anticipo per le risposte! :)

[Tasslehoff]

Se, come sembrerebbe dalla tua descrizione, tutto gira su Windows potresti usare il leggerissimo, ottimo e molto economico Drive Snapshot (licenza server 89 €), che usa VSS per fare snapshot (ovvero ghost a caldo).

Supporta anche snapshot differenziali per cui nel week end potresti schedulare uno snapshot full e durante la settimana snapshot differenziali.

Attenzione solo al database del gestionale, verifica come "digerisce" un restore da snapshot, in particolare come si comportano eventuali transazioni in corso durante lo snapshot.
Questo vale con Drive Snapshot come con qualsiasi sistema di snapshot/ghost a caldo.
Per stare tranquillo potresti schedulare un backup del database (secondo la logica che preferisci, full + archivelogs oppure full tutti i giorni) sul filesystem stesso, così facendo lo snapshot notturno si porterebbe dietro anche un backup sicuro e consistente del db.

[KIDDO1412]

Innanzitutto grazie per il consiglio sul programma, che è davvero leggero e semplice da usare! :)


Per stare tranquillo potresti schedulare un backup del database (secondo la logica che preferisci, full + archivelogs oppure full tutti i giorni) sul filesystem stesso, così facendo lo snapshot notturno si porterebbe dietro anche un backup sicuro e consistente del db.
Allora, secondo coloro che han installato il gestionale basta che backuppo una derminata cartella (ovviamente con gli utenti disconnessi dal gestionale) per essere tranquillo, che alla fine è quello che facevo anche prima.

Perdona l'ignoranza, ma quando dici che mi conviene fare un backup del database sul filesystem e poi uno snapshot intendi il fare un backup della cartella sopra descritta, ad esempio con windows backup, sullo stesso hard disk e poi fare il ghost di tutto con backup annesso? :D

Infine, relativamente al programma avrei qualche domanda:
- non ho visto che gestisca eventuali pianificazioni, suppongo quindi di dover configurare il tutto con la pianificazione di windows, ovviamente fornendo le informazioni da riga di comando?
- l'estensione che utilizza il programma per le immagini è proprietaria oppure può essere gestita da altri programmi? lo chiedo perchè, si sa mai che si corrompa un backup nel momento in cui serve (ok, bisogna avere sfiga), sarebbe comodo che tale file corrotto sia gestibile da più software in modo che, laddove alcuni non lo aprono nemmeno, magari con altri qualcosa si riesce a ricavare...
- non ho trovato nessun report del programma o comunque una segnalazione via mail, come ad esempio su backup assist... c'è un modo per ovviare a tal cosa? Anche tramite la pianificazione di windows, si può controllare che sia tutto ok? Perchè l'ideale sarebbe che al mattino uno arriva in ufficio, legge le mail e trova il report positivo, diversamente si attiverebbe la procedura per controllo ed eventuale backup alternativo a mano...

[Tasslehoff]

Allora, secondo coloro che han installato il gestionale basta che backuppo una derminata cartella (ovviamente con gli utenti disconnessi dal gestionale) per essere tranquillo, che alla fine è quello che facevo anche prima.

Perdona l'ignoranza, ma quando dici che mi conviene fare un backup del database sul filesystem e poi uno snapshot intendi il fare un backup della cartella sopra descritta, ad esempio con windows backup, sullo stesso hard disk e poi fare il ghost di tutto con backup annesso? :D Da quello che dici e ti ha riportato il tecnico che ti ha fatto l'installazione devo presumere che il gestionale in questione utilizzi un file access come database (oppure salvi su filesystem il repository, che a fini pratici per il backup cambia poco).
In quel caso ti basta fare lo snapshot, il mio appunto sul fare prima il backup e poi lo snapshot si riferiva a database ospitati su database server (es MySQL, IBM DB2, Microsoft SQL Server, Oracle, Postgresql etc etc) con i quali non serve a nulla copiare i datafile presenti sul filesystem ma devi fare prima un backup usando le apposite utility di backup (o dump) messe a disposizione del prodotto, e poi fare lo snapshot in modo da salvare i file generati dal backup.

Infine, relativamente al programma avrei qualche domanda:
- non ho visto che gestisca eventuali pianificazioni, suppongo quindi di dover configurare il tutto con la pianificazione di windows, ovviamente fornendo le informazioni da riga di comando?C'è proprio un articolo nelle FAQ (http://www.drivesnapshot.de/en/schedule.htm) per questo, dato che per schedulare uno snapshot basta un file .bat non hanno perso tempo a reinventare la ruota ma consigliano di sfruttare lo schedulatore del sistema operativo.

- l'estensione che utilizza il programma per le immagini è proprietaria oppure può essere gestita da altri programmi? lo chiedo perchè, si sa mai che si corrompa un backup nel momento in cui serve (ok, bisogna avere sfiga), sarebbe comodo che tale file corrotto sia gestibile da più software in modo che, laddove alcuni non lo aprono nemmeno, magari con altri qualcosa si riesce a ricavare...Dovrebbe essere proprietaria.

- non ho trovato nessun report del programma o comunque una segnalazione via mail, come ad esempio su backup assist... c'è un modo per ovviare a tal cosa? Anche tramite la pianificazione di windows, si può controllare che sia tutto ok? Perchè l'ideale sarebbe che al mattino uno arriva in ufficio, legge le mail e trova il report positivo, diversamente si attiverebbe la procedura per controllo ed eventuale backup alternativo a mano...Ti correggo, l'ideale sarebbe non ricevere nulla se tutto è ok, e ricevere una mail se qualcosa è andato storto :)
Se il controllo del log è una attività manuale e ripetitiva non serve a nulla, a forza di vederti passare davanti agli oggi giorno dopo giorno gli stessi log non riusciresti a notare un errore nemmeno se fosse grande come una casa, lo dico per esperienza (per fortuna risalente a tanti anni fa :D).

Durante i backup puoi usare l'opzione --LogFile che redirige su un file di test tutto l'output.
Sempre tramite bat puoi cercare nel file di log eventuali stringhe di errore e fare in modo che il bat ti invii una mail utilizzando un client SMTP (es l'ottimo e gratuito Blat (http://www.blat.net/)).
Purtroppo non ti so dire se Drive Snapshot abbia dei codici di errore specifici (es delle stringhe che puoi cercare e che se trovi nel log significa che si è generato un errore ==> invia una mail), per questo dovresti provare a scrivere una mail agli sviluppatori (ti risponderanno a breve, garantisco per esperienza diretta :) ).
Io uso generalmente Drive Snapshot per backup una tantum durante attività di manutenzione straordinaria oppure per virtualizzare macchine Windows.
Avendo eliminato quasi tutte le macchine Windows non ho avuto occasioni per usare Drive Snapshot schedulato, sulle poche che rimangono uso Tivoli Storage Manager (che tra l'altro ha delle sue features per fare snapshot simili sempre tramite VSS).

[KIDDO1412]

Finalmente posso aggiornare il topic in quanto essendomi arrivato il supporto per il backup (finalmente!!!) ho iniziato a smanettare con l'ottimo Drive Snapshot suggerito da Tasslehoff :)

Ho provato più o meno tutte le opzioni che mi possono interessare, ponendo quindi come obbiettivo la realizzazione di un backup completo ogni domenica e backup differenziali sullo stesso per tutta la settimana successiva ossia dal lunedì al sabato (giorno lavorativo :mad: ).
Tutto chiaro: creo due file batch (uno per il backup completo e uno per il differenziale) e li faccio eseguire da utilità di pianificazione, molto semplice.

Il problema sorge volendo dare un minimo di ordine ai backup e lavorando quindi con le date, ad esempio se eseguissi un comando del genere:

snapshot c: x:\backup\$DATE_full.sna

mi creerebbe il file 20140517_full.sna, che sarebbe il backup completo di oggi.
Come faccio poi a dire all'ipotetico batch che verrà eseguito domani di utilizzare tale file come origine? Perchè la variabile $DATE è appunto dinamica e di conseguenza sorge il "problema" di come richiamare i file precedenti su un batch...

L'alternativa sarebbe non usare le date e consentire che di volta in volta vengano sovrascritti i vecchi i backup ma secondo me non sarebbe tanto sicuro in quanto se uno non ha un seconda copia del backup completo precedente e se nel mentre questo viene sovrascritto dal nuovo che si corrompe, si perdono tutti i backup!

Oppure soluzione estrema: creare ogni giorno un backup completo con la sua data... :sofico:

Qualche consiglio? :confused:

[conzi]

L'alternativa sarebbe non usare le date e consentire che di volta in volta vengano sovrascritti i vecchi i backup ma secondo me non sarebbe tanto sicuro in quanto se uno non ha un seconda copia del backup completo precedente e se nel mentre questo viene sovrascritto dal nuovo che si corrompe, si perdono tutti i backup!

Oppure soluzione estrema: creare ogni giorno un backup completo con la sua data... :sofico:

Qualche consiglio? :confused:

se vuoi uno storico di 7 gg completi usa $weekday, se lo vuoi di un mese $day

se vuoi farti inviare l'errore drivesnapshot restiuisce un codice se non e' andato tutto liscio.
oppure con un grep cerchi "error" nel log generato (deve sempre essere presente anche "end of snapshot" per avere la sicurezza di un log completo)

una cosa come la vuoi tu con report ecc.. la trovi qui: www.telebackup.it

[conzi]

Ti correggo, l'ideale sarebbe non ricevere nulla se tutto è ok, e ricevere una mail se qualcosa è andato storto :)


ma la mail puo' non arrivare per due motivi:
- non e' partita perche' non ci sono stati problemi e quindi non e' stata generata
- e' partita ma non è arrivata per mille mila problemi di altro tipo

dovrebbe arrivare sempre qualcosa, sia che il backup sia schedulato sia che non sia previsto.
se non arriva la notifica... o se arriva con "error" allora c'e' un problema e bisogna controllare.

ma se by design c'e' il caso che non arrivi nulla... quel nulla potrebbe generare un falso senso di sicurezza...

[KIDDO1412]

se vuoi uno storico di 7 gg completi usa $weekday, se lo vuoi di un mese $day
Scusami, con storico intendi l'intervallo di tempo tra un backup completo e l'altro, intervallato da backup differenziali?
Perchè in ogni caso anche così sarebbe previsto prima o poi che il backup completo venga sovrascritto da un altro... e se poi ci son guai? Si perderebbero tutti i backup...
Per questo io pensavo che la soluzione migliore sarebbe un backup completo a settimana ma senza cancellare il precedente (da qui la necessità di usare un elemento univoco come la data estesa)... ovviamente una soluzione del genere richiede che ogni tot tempo vengano cancellati i backup più vecchi ma con un determinato margine, cioè tenendo sempre almeno due partite di backup completi + differenziali.

una cosa come la vuoi tu con report ecc.. la trovi qui: www.telebackup.it
Ci ho dato un'occhiata... praticamente fa gestire attraverso un servizio esterno le notifiche dei backup, sarei curioso di sapere i prezzi :D


ma se by design c'e' il caso che non arrivi nulla... quel nulla potrebbe generare un falso senso di sicurezza...
Anche questo è vero... diciamo che io son stato abituato con Backup Assist che integra tal funzione... basterebbe quantomeno la possibilità di cambiare l'oggetto della mail in caso di guasto in modo da attirare l'attenzione :D

[conzi]

Scusami, con storico intendi l'intervallo di tempo tra un backup completo e l'altro, intervallato da backup differenziali?
Perchè in ogni caso anche così sarebbe previsto prima o poi che il backup completo venga sovrascritto da un altro... e se poi ci son guai? Si perderebbero tutti i backup...
intendo backup completi.
per avere uno storico con i backup differenziali basta che fai uno script che di settimana in settimana ti sposta/rinomina l'ultimo set e cancella quello precedente...

ma se hai 100Gb di dati e pensi ad un nas decente non vedo il vantaggio di avere un backup differenziale... lo spazio di storage costa poco ormai, e su synology sono arrivato a 5GB/min... in mezz'ora fai il backup completo.



Anche questo è vero... diciamo che io son stato abituato con Backup Assist che integra tal funzione... basterebbe quantomeno la possibilità di cambiare l'oggetto della mail in caso di guasto in modo da attirare l'attenzione :D
anche telebackup lo fa. ti manda sempre un report, pallino verde per backup ok (o backup non previsto), rosso per errore...

[Tasslehoff]

ma la mail puo' non arrivare per due motivi:
- non e' partita perche' non ci sono stati problemi e quindi non e' stata generata
- e' partita ma non è arrivata per mille mila problemi di altro tipo

dovrebbe arrivare sempre qualcosa, sia che il backup sia schedulato sia che non sia previsto.
se non arriva la notifica... o se arriva con "error" allora c'e' un problema e bisogna controllare.

ma se by design c'e' il caso che non arrivi nulla... quel nulla potrebbe generare un falso senso di sicurezza...Beh proprio per evitare questo è buona norma catchare gli errori negli script verificando l'exit status, non soltanto catturare eventuali stringhe di errore.
Le best practices di sviluppo non si applicano solo ai linguaggi evoluti, anche ai semplici script ;)

Certamente può verificarsi un problema anche sull'SMTP, se uno non è sicuro del proprio servizio può sempre appoggiarsi altrove oppure usare più di un SMTP.

Io resto del parere che inviare notifiche che non contengono errori è una perdita di tempo che genera caos.
Ci siamo passati tutti, le prime email le controlli, poi quando i giorni passano e le mail si ripetono sempre uguali a se stesse non noti un errore nemmeno se fosse grande come una casa.
Anche la verifica di un pannello di amministrazione che ti indica l'esecuzione dei backup diventa alla lunga una cosa ripetitiva e dipendente dalla propria disponibilità/voglia/tempo, quindi tendenzialmente fallace dal mio punto di vista.

[conzi]

Io resto del parere che inviare notifiche che non contengono errori è una perdita di tempo che genera caos.
Ci siamo passati tutti, le prime email le controlli, poi quando i giorni passano e le mail si ripetono sempre uguali a se stesse non noti un errore nemmeno se fosse grande come una casa.


quindi:
- se non ti arrivano notifiche non sai in realtà se le cose stanno andando bene o no ( e potenzialmente potrebbero essere andate male)
- se te ne arrivano tutti i giorni rischi l'assuefazione e al momento buono non ti accorgi di quella con l'errore.

quindi un rischio c'è: fault del sistema o fault di chi deve controllare

KIDDO1412, ti fidi di più del sistema o di te stesso?

scelta difficile... :-D

[Tasslehoff]

quindi:
- se non ti arrivano notifiche non sai in realtà se le cose stanno andando bene o no ( e potenzialmente potrebbero essere andate male)Beh come dicevo se fare il catch delle eccezioni e a seguito di un exit status errato fai inviare una notifica tramite mail (magari usando più smtp, giusto per non rischiare) minimizzando questo rischio.
Si tratta poi appunto di minimizzare, perchè la certezza assoluta non la può dare nessuno, puoi anche avere una tape library da 200k euro con sopra Tivoli Storage Manager, ma qualsiasi software può tirare eccezioni e non funzionare a dovere, il trucco sta appunto nel cercare di prevedere le eccezioni e minimizzarne l'effetto.

KIDDO1412, ti fidi di più del sistema o di te stesso?

scelta difficile... :-DPer me no (e sottolineo per me), mi fido più del peggior script del mondo piuttosto che di me stesso :asd:

[conzi]

Beh come dicevo se fare il catch delle eccezioni e a seguito di un exit status errato fai inviare una notifica tramite mail (magari usando più smtp, giusto per non rischiare) minimizzando questo rischio.
Si tratta poi appunto di minimizzare, perchè la certezza assoluta non la può dare nessuno, puoi anche avere una tape library da 200k euro con sopra Tivoli Storage Manager, ma qualsiasi software può tirare eccezioni e non funzionare a dovere, il trucco sta appunto nel cercare di prevedere le eccezioni e minimizzarne l'effetto.


mah... sono dell'idea che le condizioni siano due:
- notifica ok (tutto bene)
- notifica di errore o mancanza di notifica (intervenire subito)

se ammetti che da progetto possano non arrivare le notifiche come la metti con la condizione di "sistema spento" oppure "mancanza di connettività"?
Non arriva la notifica.... e nel primo caso anche niente backup.... e qualcuno sta bello tranquillo nella convinzione che sia tutto ok....

[Tasslehoff]

se ammetti che da progetto possano non arrivare le notifiche come la metti con la condizione di "sistema spento" oppure "mancanza di connettività"?
Non arriva la notifica.... e nel primo caso anche niente backup.... e qualcuno sta bello tranquillo nella convinzione che sia tutto ok....Beh quelle sono casistiche gestite da altro, ad esempio Nagios (o fork tipo Icinga o prodotti simili tipo Zabbix).
Non l'ho citata come necessità perchè la davo per scontata, però va considerato che generalmente uno non fa un solo backup (se è uno solo buon per lui, ma se ha esigenze così limitate difficilmente la società per cui lavora potrà permettersi di dedicare una persona per mansioni sistemistiche).

Io l'unico modo che ho per tenere il conto degli script di backup che ho sparso tra clienti e macchine interne è verificando il repository git dove li ho versionati e dove ho accuratamente segnato le schedulazioni e se sono attivi.

Se dovessi ricevere una mail di conferma per ciascun backup sarei sommerso da decine e decine di mail ogni giorno, praticamente dovrei dedicare almeno mezza giornata per verificarle una a una, capisci bene che una cosa del genere è impensabile, soprattutto perchè si somma alle notifiche dei servizi di monitoraggio, e alle normali email.
I software che gestiscono i backup non fanno un lavoro molto diverso da quello che ho descritto, monitorizzano dei job schedulati e inviano notifiche in caso di errori.

Solo una volta mi è capitato di incappare in un cliente (ovviamente un ente di PA :doh: ) dove qualcuno si spazzolava a mano i log di backup ogni giorno per verificare se avevano girato correttamente, si trattava di una dba Oracle (parola grossa nel suo caso, visto che non era in grado nemmeno di configurare una entry nel tnsnames.ora... :rolleyes: ), un lavoro talmente noioso e inutile da essere tranquillamente classificabile come mobbing, e ovviamente ogni tipo di errore le passava costantemente sotto il naso senza che se ne accorgesse...
Evidentemente fare un grep -E "ORA-|RMAN-" era troppo per le sue skill da dibbbiaaaaa... :doh: