COPIE E RIPRISTINO DEI DATI

Nel pianificare la copia e l'eventuale ripristino dei dati, il reparto tecnico dell’azienda deve conoscere la giusta collocazione del software, del database e dei file dati associati che consentono a Gea.Net di operare. Non ci stancheremo mai di dirlo ma è fondamentale fare le copie di sicurezza dei dati. Non si tratta solo di una buona norma ma con il D.Lgs. 196/2003 è diventato un obbligo. 

Configurazione con database in Locale o su LAN

Per configurazione in Locale si intende una installazione monoutente (installata su un solo PC che funge sia da server che da client) o una distribuita su rete LAN dove il PC su cui risiede il database è identificato come serve mentre i PC che accedono al servizio sono identificati come client.

Copie dei dati

Se l’installazione è stata fatta secondo gli standard consigliati, tutto ciò che serve copiare dovrebbe trovarsi all’interno della cartella \geanet che nelle configurazioni stand-alone di Gea.Net Pro è anche l’unica da copiare. Nella sottocartella \geanet\bin\DATI troviamo solitamente i file di configurazione e il database più una serie di sottocartelle che contengono file allegati o documenti che possono essere riprodotti. In linea di principio occorre essere consapevoli che il database è la componente da salvaguardare a tutti i costi mentre tutto il resto potrebbe essere ripristinato e reinserito anche se con alcuni sacrifici, tuttavia se si copia tutta la cartella \geanet non si sbaglia. Le copie andrebbero pianificate in un momento in cui gli operatori non lavorano (alla sera o di primo mattino).

Occorre precisare che :

• In configurazione di rete locale (LAN) potremmo avere installato una sola cartella sul server, che quindi sarebbe l’unica da salvare, ma si potrebbe avere optato per l'installazione del software su ogni client. In questo caso ogni installazione client dovrebbe essere simile alle altre e soprattutto non dovrebbe contenere dati importanti se non quelli delle configurazione operative e sarebbe facilmente ripristinata copiando quella presente su un altro client. Si può pensare a copiare giornalmente il contenuto del server e solo una tantum l’installazione client.
• Se il database è stato disposto su una cartella separata dall’applicazione occorre salvarle entrambe.
• Se si usa un database diverso da Microsoft Access occorre disporre le regole di copia secondo quanto disposto dal produttore del database.
• Anche se la soluzione migliore sarebbe creare tante cartelle geanet quante sono le aziende che si vogliono gestire, in caso di configurazione multiaziendale la cartella \geanet potrebbe avere diverse sottocartelle \DATI_* quante sono le aziende gestite e di conseguenza devono essere copiate tutte.

Riassumendo possiamo dire che le informazioni più importanti si trovano sul database che risiede sul server (o sull'unico PC usato in caso di monoutenza) e che per impostazione predefinita è di tipo Microsoft Access e si trova in \geanet\bin\DATI. Però si potrebbe avere deciso di cambiarne la locazione oppure avere installato un database diverso come SqlServer che dispone di funzioni proprie di backup e che non possono risolversi con un semplice copia di un file.

Ripristino dei dati

Se le copie sono state pianificate ed eseguite correttamente il ripristino dovrebbe solamente prevedere:

• Installazione del Framework.NET 4.6.1 (per vecchie versioni di Windows in cui non già presente).
• Ripristino della cartella \geanet sui vari client/server
• Ripristino del/dei database qualora questi non sono situati nella cartella \geanet

In casi di reti locali, in particolare dovrebbero, essere rassegnati i diritti in lettura e scrittura alle cartelle a livello di sistema operativo. In alcuni casi può essere necessario ripristinare anche i permessi gestiti da Framework.Net attraverso il comando CASPOL.

Configurazione con database in Cloud

In caso di configurazione Cloud non esiste un modo univoco per eseguire le copie dei dati, tutto dipende da dove risiede il database.

Se il database risiede su un server proprio o un server in hosting la cui gestione compete all’azienda la gestione delle copie non è molto dissimile da quanto analizzato la configurazione con database Locale.

Se invece è stato acquistato un servizio cloud, la maggior parte dei provider garantisce il backup dei dati con una modica spesa annuale e questo è certamente il primo livello di sicurezza da adottare ma è bene fare un passo in più e organizzarsi per avere anche una copia locale dei dati. Quindi se si è depositato il database su hosting condiviso occorre ricordare di eseguire un download sistematico a scopo precauzionale.

Copie dei dati da server Hosting condiviso

Per ragioni di economicità del servizio, nella maggior parte dei casi la configurazione Cloud di Gea.Net Pro si appoggia ad un Hosting condiviso la cui gestione è in carico ad un provider. Questa soluzione presenta vantaggi in tutto ma per motivi di sicurezza i provider consentono l'accesso solo alla propria area dedicata e solo attraverso client FTP o servizi dedicati. Ne consegue anche la semplice copia di una cartella richiede operazioni più lunghe. 

Come per la configurazione Locale, anche da Cloud potremo copiare facilmente un database Access, ma per database diversi occorre fare riferimento ai servizi dei provider, che comunque mettono sempre a disposizione la possibilità di scaricare in locale una copia dei propri dati. 

Copiare database Access da Gea.Net DbService

Se si è optato per un database Access accessibile da Gea.Net DbService, in aggiunta a quelle che sono le funzioni di copia principale, gli utenti amministratori possono anche eseguire un download locale direttamente da Gea.Net Pro o da Gea.Net Web.

Trattandosi di download attraverso un servizio che potrebbe non essere autorizzato per questo scopo, questa opzione è da considerarsi non sempre possibile e quindi è da utilizzare solo in aggiunta ad altri sistemi di copia. Inoltre è buona norma aprire il database un volta scaricato per assicurarsi che non sia stato ricevuto incompleto o corrotto.

Dalla voce Profilo della Home Page di Gea.Net (anche sulla barra comandi Configurazione à Profilo - Dati Anagrafici)

da Gea.Net Web la funzione di importazione e disponibile solo per gli utenti con profilo di Amministratore ("ADMIN").

Da Archivi à Impostazioni

Purtroppo entrambe le funzioni non hanno la barra di avanzamento del processo e solo al termine si riceve la segnalazione di operazione terminata. Si consideri che i tempi dipendono da tanti fattori (velocità del collegamento Internet, carico dei server, ecc.) ma possiamo considerare che se si dispone della Fibra il download dovrebbe durare pochi secondi mentre per la ADSL potrebbe impiegare all’incirca un minuto per ogni 10 MB.

Il ripristino di un database Access su hosting condiviso è moderatamente complicato. Se si è avvezzi ad operare su client FTP, il più delle volte è sufficiente copiare il file MDB, altrimenti è bene richiedere che le operazioni vengano eseguite da un tecnico qualificato. 

Gea.Net Pro e il backup locale temporizzato

Per offrire una soluzione che potesse essere apprezzata in diversi scenari e scongiurare perdite di dati per gli utenti che non pianificano i backup, nelle versioni più recenti di Gea.Net Pro è stato introdotto un sistema di backup locale temporizzato.
Uno degli obiettivi era rendere l’operazione semplice, automatica e pianificata (cioè farla partire quando serve) senza creare disagi all’utente.
Ma l’obiettivo principale era soprattutto quello di prevenire due potenziali “disastri” di cui trattati sul blog :

• Il database Access che si corrompe a causa di una LAN instabile

• Disdetta involontaria del proprio spazio cloud

Dovendo creare un processo senza interazione con l’utente, non era possibile trovare una soluzione che avesse le caratteristiche di sicurezza previste dalla normativa vigente, che per forza di cosa devono prevedere uno scenario specifico e diversi parametri da impostare.
Di fatto quello adottato deve essere visto come un processo che si affianca ma non sostituisce le normali copie pianificate dall’amministratore. Insomma è “meglio che niente” ma non deve essere vista come una soluzione che declina le responsabilità dell’amministratore.
Inoltre si ritiene che le aziende “vulnerabili”, cioè quelle che nonostante tutte le raccomandazioni non fanno correttamente i backup, siano quelle che utilizzano il database standard usato da Gea.Net, quindi questo processo è pensato solo per Microsoft Access.

Premesso ciò, vediamo nello specifico come opera la soluzione adottata.
Come anticipato non è per nulla invasiva, infatti non ha bisogno di impostare variabili, parte alla chiusura di Gea.Net Pro ed esegue una copia del database senza che l’operatore debba ricordarsene o eseguire alcuna operazione.
Chiudendo l’ERP, se il sistema ritiene sia necessario, archivia il database nella cartella \geanet\bin\DATI\Backup\[nome azienda]

Al termine dell’operazione, se tutto è andato a buon fine, un algoritmo calcola la data (tra i 7 e i 30 giorni) in cui verrà pianificato il backup successivo.
Quindi l’unica accortezza richiesta all’utente è quella di non spegnere il PC prima della fine del processo di copia. Il tempo di attesa può essere nell’ordine dei secondi se i dati si trovano su rete locale o in cloud ed è disponibile la fibra ottica, mentre può essere anche di un paio di minuti se deve essere eseguito il download attraverso una ADSL.
Lo spazio su disco richiesto è pari alle dimensioni del database stesso, anche se in realtà nella cartella di Backup viene sempre mantenuta la copia precedente in un file in formato ZIP, mentre le copie più vecchie vengono spostate nel Cestino di Windows e lì rimangono fintanto che l’utente non decide di rimuoverle.
Il processo di backup non può essere disattivato. Al massimo può essere posticipato intervenendo sulla data pianificata nelle Impostazioni che però non può andare oltre i 3 mesi.

Errore causato dalla dimensione del database (cloud)
Se si sta lavorando su una installazione monoutente o con database presente su rete locale non ci sono problemi ma se il database risiede in cloud la sua dimensione potrebbe causare qualche grattacapo.
Alla base di questo potenziale problema c’è il fatto che il download non viene frazionato in tempi diversi ma avviene in un’unica soluzione, quindi si deve avere sufficiente RAM per poterlo gestire.
Nella configurazione standard, Gea.Net Pro può scaricare correttamente database di circa 200 MB, che per un database Microsoft Access cominciano ad essere volumi importanti.
Di solito quando si raggiunge quella dimensione si dovrebbe pensare a rimuovere i documenti degli anni precedenti o passare a database più performanti come SQL Server.
Ma non è raro vedere database Access anche di 500 MB che continuano ad offrire prestazioni soddisfacenti quindi vediamo come risolvere, anche se il consiglio è di confrontarsi prima con un tecnico di Gea.Net. Naturalmente non proseguite oltre senza avere prima fatto una copia dei dati.

Lo spazio della RAM che vogliamo dedicare al servizio Gea.Net DbService, che è quello che colloquia con il database in cloud, è parametrizzabile dal file \geanet\bin\GeaNet.exe.config
Dalla immagine seguente possiamo vedere che aprendo il file di configurazione dovreste ritrovarvi i parametri interessati allo scopo (sottolineati in rosso) valorizzati a circa 222 Milioni di Byte.

La soluzione per andare oltre al limite prefissato è piuttosto semplice: basta modificare anche solo la prima cifra di ognuno di questi valori, inserendo 5 invece di 2 renderemmo possibile il download di un database di oltre 500 MB.
Ma come per tutte le cose non bisogna esagerare, infatti Windows gestisce le app in modo che non possano usare troppa RAM perché questo potrebbe creare un crash del sistema quindi se avete 8GB di RAM non dovreste riuscire a destinarne più di 2 a Gea.Net.
Personalmente non ho mai visto un azienda mettere in produzione un database Access di 2GB ma se questo fosse il vostro caso non rimane che fare il download con FileZilla o altri client FTP.

Una piccola raccomandazione: Framework.Net è un po’ permaloso per queste cose e se si inseriscono valori fuori scala o non previsti, Gea.Net non riuscirà ad accedere al database in cloud (e forse neppure ad avviarsi). Per esempio “maxBufferSize” e “maxReceivedMessageSize” devono necessariamente avere lo stesso valore.
Quindi salvare il file di configurazione prima di manipolarlo è cosa buona e giusta.