I dati contenuti in un software gestionale rappresentano spesso anni di attività dell'azienda: clienti, fornitori, fatture, contabilità, scadenze, ordini, magazzino, documenti, allegati e molto altro.
Un computer può essere sostituito.
Un programma può essere reinstallato.
I dati persi, se non esiste una copia valida, possono invece essere impossibili da ricostruire.
Il backup non deve essere considerato un'operazione occasionale, ma una parte fondamentale dell'infrastruttura informatica aziendale.
Copiare la cartella del programma non significa fare il backup del gestionale
Nelle installazioni basate su Microsoft SQL Server, programma e database sono elementi differenti. Clienti, fornitori, documenti, contabilità, scadenze e altri dati si trovano nei database SQL Server: copiare la sola cartella applicativa non significa aver salvato i database.
Per SQL Server devono essere predisposte procedure specifiche di backup.
Il database è fondamentale, ma non è tutto il gestionale
Nella cartella del programma e nelle relative sottocartelle possono essere presenti file che non fanno parte del database. A seconda dell'installazione possono esserci:
- allegati associati a clienti, documenti o registrazioni
- fatture elettroniche emesse
- fatture elettroniche ricevute
- file XML
- documenti acquisiti dal gestionale
- report e stampe personalizzate
- configurazioni
- altri file specifici dell'installazione
Fare il backup del database non significa necessariamente aver salvato tutto il gestionale.
Un esempio concreto
Il server diventa inutilizzabile, ma disponiamo di un backup SQL Server aggiornato. Possiamo ripristinare clienti, fornitori, articoli, fatture, contabilità, scadenze, magazzino e gli altri dati presenti nel database.
Se però non abbiamo mai salvato le cartelle del gestionale, possiamo aver perso allegati, XML delle fatture elettroniche, report personalizzati e altri documenti. Il database è stato recuperato, ma l'ambiente non è stato ripristinato completamente.
Due tipi di dati da proteggere
Database SQL Server
- backup automatici
- frequenza adeguata
- più backup durante la giornata quando necessario
- conservazione di più copie
- destinazione separata
- controllo dell'esito
File del gestionale
- allegati
- fatture elettroniche
- report personalizzati
- documenti
- configurazioni
- backup periodico delle cartelle
Database e file hanno esigenze di backup differenti, ma entrambi devono essere protetti.
“Lo facciamo ogni tanto” non è una strategia di backup
Le operazioni manuali prima o poi vengono dimenticate. I backup dei database devono essere automatizzati, schedulati ed eseguiti senza dipendere dall'intervento dell'utente.
Quante ore di lavoro possiamo permetterci di perdere?
La frequenza dipende dall'attività. Una possibile pianificazione dimostrativa può essere:
- 08:00
- 12:00
- 16:00
- 20:00
Se il problema avviene alle 17:30, la copia delle 16:00 riduce la quantità di lavoro da ricostruire. Questi orari sono soltanto un esempio, non una configurazione standard obbligatoria.
Non avere il backup, ma una cronologia di backup
Un errore può essere scoperto dopo giorni, una copia può risultare inutilizzabile oppure può essere necessario tornare a una situazione precedente. Per questo occorre conservare più generazioni, non una sola copia continuamente sovrascritta.
G3cube g3cBackup
g3cBackup: backup automatici dei database Microsoft SQL Server
Il servizio G3cube g3cBackup può eseguire N backup schedulati al giorno, mantenere le ultime N copie e ruotare automaticamente le versioni. Il numero delle copie è configurabile.
| Database_001 | copia più recente |
|---|---|
| Database_002 | copia precedente |
| Database_003 | copia precedente |
| Database_004 | copia precedente |
| Database_005 | copia più vecchia conservata |
_001 identifica sempre la copia più recente.
Copiare automaticamente i backup su FTP
g3cBackup può trasferire i backup verso un FTP locale o remoto, purché sia messo a disposizione e configurato dal cliente. Questo aiuta a separare una copia dal server principale.
- SQL Server
- g3cBackup
- Backup locale
- FTP remoto
In alternativa il flusso può terminare su un FTP collocato in un'altra infrastruttura locale.
Il backup non dovrebbe rimanere soltanto sul server
- Stesso disco del server
- Altro disco dello stesso server
- NAS o server separato
- FTP remoto
- Cloud
Più il backup è indipendente dal sistema che deve proteggere, maggiore è la sua utilità in caso di guasto.
Anche la destinazione del backup deve essere protetta
NAS, FTP e cloud devono avere credenziali proprie, accessi limitati, controllo dello spazio, protezione da cancellazioni accidentali e da accessi non autorizzati.
Un backup raggiungibile da tutti può essere compromesso
Una cartella condivisa accessibile in scrittura da tutte le postazioni può essere raggiunta anche da malware o ransomware.
Se un PC della rete viene compromesso, può raggiungere, modificare o cancellare anche i nostri backup?
Una strategia completa
Flusso database
- SQL Server
- g3cBackup
- N backup al giorno
- Ultime N copie
- FTP locale o remoto
Flusso file
Cartelle del gestionale:
- allegati
- fatture elettroniche emesse e ricevute
- report personalizzati
- altri file dell'installazione
- Backup periodico
Destinazione separata e protetta
Entrambi i flussi devono concludersi con copie protette e indipendenti dal sistema principale.
g3cBackup è una parte della strategia, non tutta la strategia
g3cBackup automatizza il backup SQL Server, la conservazione delle copie e il trasferimento FTP. Non sostituisce la necessità di salvare i file esterni al database, proteggere la destinazione e verificare periodicamente il funzionamento.
Fare il backup non basta: bisogna controllare che venga eseguito
Il processo può interrompersi per disco pieno, destinazione non disponibile, credenziali cambiate, servizio arrestato, spazio FTP o cloud esaurito, errori di rete o errori durante il backup.
Un backup automatico che ha smesso di funzionare crea una falsa sensazione di sicurezza.
Un backup è utile soltanto se può essere ripristinato
Se oggi perdiamo completamente il server, siamo in grado di ripartire?
Lo scopo non è produrre un file `.bak`, ma poter ricostruire l'ambiente.
Il backup minimo da ricordare
Database SQL Server
Backup automatico, frequenza adeguata e più copie storiche.
Copia separata
Almeno una copia fuori dal server principale.
File del gestionale
Backup periodico di allegati, fatture elettroniche, report e altri file.
Protezione
Accessi limitati e credenziali dedicate.
Controllo
Verificare che i backup vengano realmente creati.
Ripristino
Verificare che le copie siano utilizzabili.
La domanda corretta non è “Fate il backup del database?”
Se domani dovessimo sostituire completamente il server, abbiamo tutto ciò che serve per ricostruire il gestionale?
Database presente ma allegati mancanti: backup incompleto .
Database e file presenti ma tutti sul server guasto: backup inutilizzabile .
Copie presenti ma processo fermo da mesi: protezione solo apparente .
Quando ci si accorge dell'importanza del backup è spesso troppo tardi
Un guasto hardware, un errore umano, un malware o un ransomware possono rendere indisponibili anni di lavoro.
Automatizzare i backup, conservarne più versioni, proteggere anche i file esterni al database e mantenere almeno una copia separata dal sistema principale significa trasformare il backup da semplice copia di sicurezza a vera strategia di protezione dei dati aziendali.
Per i database Microsoft SQL Server, g3cBackup può effettuare più backup schedulati durante la giornata, conservare le ultime N copie, mantenere _001 come copia più recente e trasferire automaticamente i backup verso un server FTP locale o remoto messo a disposizione dal cliente.