Alfresco Backup

BACKUP E RESTORE

Appunti del corso di formazione per sysadmin

Alfresco non possiede meccanismi di backup interni essendo un prodotto adattabile ad ambienti multipli (db, s.o. file server ecc), bisogna quindi andare ad analizzare l'ambiente per decidere come fare il backup. Bisogna decidere cosa e come backuparlo.
I file properties con le info del db e le altre configurazioni non vengono mai modificati da alfresco quando è in funzione. Al contrario quello che varia è il database, il content store (che si trova nella variabilie dir.root), indici e file di log.
L'eventuale perdita degli indici non è un danno irreparabile in quanto possono essere ricostruiti settando la proprietà a FULL, conviene backuparli perchè per sistemi con molti documenti è necessario parecchio per rigenerarli.
I log possono essere utili per motivi di analisi forense
Il db deve essere backupato con tool tipici del db, indici e content store sono nel file system.
Nella configurazione in cluster ogni nodo ha la propria copia degli indici quindi che possono essere diseallineati in base alla frequenza con cui effettuano l'aggiornamento.

A Caldo o a Freddo

Con il backup a freddo tutto molto più semplice, fermando il sistema posso usare qualsiasi procedura
Con il backup a caldo, serve un backup sul db che garantisca l'integrità referenziale in modo che eventuali insert effettuate durante la procedura di backup possono esserci delle chiavi corrotte nel backup. Mysqldump ed exp di Oracle, non garantiscono l'integrità referenziale.
Il content store non è un problema perchè quando il file viene scritto non viene più modificato.
Se effettuo il restore se db e content store non sono allineati alfresco si lamenta. Se faccio il backup del content store prima del db, potrei avere dei file che esistono nel db mentre nel content store non sono presenti. Facendo il contrario invece ho un content store con dei file in più rispetto al db, questi sono detti orfani. Nella alf_node ci sono i riferimenti al content store. I documenti orfani nelle pulizie finiscono in deleted e dopo la soglia vengono effettivamente cancellati.
Gli indici non li posso backupare a caldo, non esiste un tool che li rende consistenti, esiste un tool che produce uno snapshot. Questo gira ogni notte alle 3 e fa un backup degli indici, e mette il sistema in read only. La cartella è backupluceneindexes, di default vengono messi nella stessa cartella degli indici che per un backup non è la soluzione consigliata. Posso spostarla successivamente oppure cambiare la property dir.indexes.backup= mettendo un riferimento diverso e quindi memorizzarla in una posizione più sicura.
Per effettuare la procedura di restore corretta elimino la lucene indexs e metto quella di backup. Se effettuo un backup alle 4, lui si trova gli indici alle 3 e quindi effettuo una reindicizzazione di una sola ora che è sicuramente un'operazione più veloce. Per far questo la property deve essere settata su index.recovery.mode=AUTO che è il default. Anche per gli indici vale come il db, devono essere più vecchi altrimenti si crea un errore.
L'ordine temporale con cui fare le cose è:

  1. INDICI
  2. DB
  3. CONTENT STORE

Se si usa solr inveced di lucene lui fa il backup interno perchè è un application server a se stante.

La proprietà index.recovery.mode=FULL al riavvio di alfresco distrugge gli indici e li ricrea. NONE non fa nessun controllo sugli aggiornamento degli indici, ma conviene farlo così si risolvono eventuali problemi su indici parzialmente non validi. VALIDATE controlla se sono aggiornati e se non sono aggiornati si rifiuta di partire.

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License