Mise en place d'une stratégie de backup/restore

[zomurn]

Bonjour,

Après moult documentation lue sur le sujet : wiki, presentation pdf online, forum, formation, etc.
Je souhaiterais faire le point sur cette stratégie de backup/restore afin d'avoir l'esprit tranquille le jour où j'utilise réellement mon backup (ça m'est arrivé une fois où un process avait ruiné la base suite à sa coupure en arrêtant le serveur "alfresco.sh stop").

Je vais résumer ce que j'ai compris ici, n'hésitez pas à me reprendre si quelque chose est faux :
Les règles à connaître :

1) Le backup de la base doit être antérieur au backup du alf_data
2) Les fichiers .bin dans le alf_data sont considérés comme orphelin lorsqu'ils ne sont plus référencés en base.
3) Un scheduler qui se lance tous les 7 jours (par défaut) nettoie les fichiers orphelins en les déplaçant du contentstore au contentstore.deleted.
4) Une base référençant des fichiers .bin (et donc plus récente que le alf_data) non existant abouti à un repository corrompu
5) Un alf_data contenant des fichiers .bin non référencés en base (et donc plus ancienne que le alf_data) abouti à un repository fonctionnel.

Je souhaiterais donc à partir de là mettre en place une stratégie de backup.
Un expert alfresco m'a recommandé de sauvegarder souvent la base et moins fréquemment le alf_data, pourquoi ?

Scénario 1 :

Le mercredi 2 du mois je sauvegarde la base + alf_data.
Chaque jour suivant, je sauvegarde uniquement la base.
Le lundi 7 du mois, un crash matériel survient, je décide de restorer.
Selon les règles citées ci-dessus, je ne peux restorer que la sauvegarde du mercredi 2 car mon plus récent backup de alf_data et du mercredi 2 : conclusion , 3-4jours de travail perdu. Le client rentre en conflit avec le prestataire .
En quoi l'affirmation de l'expert est-elle donc juste ?

Scénario 2

Le mercredi 2 du mois je sauvegarde la base + alf_data.
Aucune sauvegarde n'est faite par la suite.
Le lundi 7 du mois, un crash matériel survient uniquement sur le serveur de base de donnée, je décide de restorer juste la base.
L'application tourne donc avec une base du mercredi 2 et un alf_data à jour du lundi 7.
Tous les documents injectés dans l'application entre le 2 et le 7 sont donc orphelin car non référencés en base.
Au jour 2+7=9 du mois, le scheduler effectue son job et décide donc de supprimer définitivement tous les documents injectés entre le 2 et le 7 du mois : conclusion , 3-4jours de travail perdu. Le client rentre en conflit avec le prestataire .
En quoi la notion de la durée autorisée pour la protection (propriété "protectDays") est-elle "safe" car les documents orphelins ont été nettoyés ?

Merci de vos éclaircissements.

[rguinot]

Il y a beaucoup d'erreurs et d'approximations dans votre message. quelques commentaires inline.

Après moult documentation lue sur le sujet : wiki, presentation pdf online, forum, formation, etc.
Je souhaiterais faire le point sur cette stratégie de backup/restore afin d'avoir l'esprit tranquille le jour où j'utilise réellement mon backup (ça m'est arrivé une fois où un process avait ruiné la base suite à sa coupure en arrêtant le serveur "alfresco.sh stop").

Je ne vois pas bien ce qui a "ruiné" votre base à l'arrêt, il faudra être plus explicite.

1) Le backup de la base doit être antérieur au backup du alf_data

C'est une bonne pratique en effet. Vous ne mentionnez nulle part le backup des indexes Lucene. relire donc la page "Backup and restore". Vous pouvez backuper les indexes J-1 et faire une indexation différentielle à la restauration. vous devrez rédindexer la dernière partie manquante, à mesurer en fonction de vos SLA.

2) Les fichiers .bin dans le alf_data sont considérés comme orphelin lorsqu'ils ne sont plus référencés en base.

Vrai jusqu'en 3.2, une référence est alors gardée dans une table à part.

3) Un scheduler qui se lance tous les 7 jours (par défaut) nettoie les fichiers orphelins en les déplaçant du contentstore au contentstore.deleted.

Un scheduler ne se lance pas. Un scheduler lance des jobs qui sont schedulés. Erreur de terminologie. Le job auquel vous faites référence (contentStoreCleaner) se lance tous les jours à 4 heures du matin. Les contenus supprimés il y a plus de 14 jours (par défaut) identifiés par ce job sont déplacés dans contentstore.deleted.

4) Une base référençant des fichiers .bin (et donc plus récente que le alf_data) non existant abouti à un repository corrompu

Ca dépend des versions d'Alfresco, et de la position des .bin manquants dans l'historique des transactions, et de certaines options de démarrage. Le repository n'est pas corrompu, c'est la cohérence de l'ensemble qui n'est pas respectée.

5) Un alf_data contenant des fichiers .bin non référencés en base (et donc plus ancienne que le alf_data) abouti à un repository fonctionnel.

Ce n'est pas un aboutissement, mais c'est vrai.

Je souhaiterais donc à partir de là mettre en place une stratégie de backup.
Un expert alfresco m'a recommandé de sauvegarder souvent la base et moins fréquemment le alf_data, pourquoi ?

Affirmation pour le moins étrange. Je ne connais pas votre cas d'usage. Vous ne modifiez que des métadonnées et n'ajoutez jamais ni ne modifiez de documents dans votre repository ? Comme expliqué sur la page wiki Backup and restore que vous dites avoir lu, le plus important est la cohérence de l'ensemble. pour faciliter cela, il est utile de backuper les 3 composants ensemble ( repository, base de données, indexes Lucene qu'encore une fois vous ne mentionnez pas).
En revanche, une fois un fichier écrit dans le repository, il n'est jamais changé. vous pouvez donc concentrer votre outil de backup du repository sur les fichiers récents. Comme vous avez peut être remarqué, le layout des fichiers dans le repository suit une structure temporelle.

Vos scénarios sont donc à revoir . comme toujours , il ne suffit pas de les décrire, il faut aussi les tester "en vrai".

Scénario 1 :

Le mercredi 2 du mois je sauvegarde la base + alf_data.
Chaque jour suivant, je sauvegarde uniquement la base.
Le lundi 7 du mois, un crash matériel survient, je décide de restorer.
Selon les règles citées ci-dessus, je ne peux restorer que la sauvegarde du mercredi 2 car mon plus récent backup de alf_data et du mercredi 2 : conclusion , 3-4jours de travail perdu. Le client rentre en conflit avec le prestataire .
En quoi l'affirmation de l'expert est-elle donc juste ?

Pas de mention des indexes. Vous pouvez les reconstruire, mais le temps de reconstruction sera à peu près proportionnel à votre volumétrie.
Ce scénario n'est pas valable pour les points cités ci-dessus (quand bien même le serveur démarrerait, ce n'est pas acceptable selon moi de restaurer un backup avec du contenu manquant).

Scénario 2

Le mercredi 2 du mois je sauvegarde la base + alf_data.
Aucune sauvegarde n'est faite par la suite.
Le lundi 7 du mois, un crash matériel survient uniquement sur le serveur de base de donnée, je décide de restorer juste la base.
L'application tourne donc avec une base du mercredi 2 et un alf_data à jour du lundi 7.
Tous les documents injectés dans l'application entre le 2 et le 7 sont donc orphelin car non référencés en base.
Au jour 2+7=9 du mois, le scheduler effectue son job et décide donc de supprimer définitivement tous les documents injectés entre le 2 et le 7 du mois : conclusion , 3-4jours de travail perdu. Le client rentre en conflit avec le prestataire .
En quoi la notion de la durée autorisée pour la protection (propriété "protectDays") est-elle "safe" car les documents orphelins ont été nettoyés ?

Scénario complètement à revoir au vu des précisions ci-dessus. Un fichier n'est jamais physiquement supprimé par Alfresco par défaut, il n'est que déplacé dans contentstore.deleted. la gestion de ce répertoire est à la charge de l'admin système (suppression régulière, archivage sur bande, ….). Les délais sont faux. 
Autre point: la fréquence de vos backups est également à définir plus clairement en fonction de vos plages d'activités.

Merci de vos éclaircissements.

De rien. Je note toutefois qu'à partir du moment où il y a des clients, des prestataires, des contrats , et visiblement des lacunes, un contrat de souscription au support permettrait de vous aider à faire les bons choix et à vous aider avec des engagements contractuels en cas de problème.

[zomurn]

Oui il est possible de ruiner la base à l'arrêt après un processus lourd.
Par exemple, j'ai déplacé plusieurs milliers de fichiers dans une seule et même transaction.
Les logs étant terminés (ceux décrivant le process), je pensais que ce processus lourd était terminé.
Faux, des traitements arrière plan ont eu lieu : par ex. maj des indexes.
C'est très dommage, cela à corrompu la base, une restauration a été nécessaire.
On devrait avoir une estimation en temps d'un tel processus.

Pour le backup des indexes, c'est sous entendu tout ce qu'il y a à l'intérieur du alf_data (entre autre les indexes) bien sûr.

OK pour la 3.2, je ne savais pas.

Pour le point 3) 4) et 5), vous jouez sur les mots (peut être plus adaptés en effet, bien que le résultat soit le même)

En fait en y repensant, sauvegarder souvent la base n'est pas faux. Cette composante est plus sensible que le contenu de alf_data (qui contient des données binaires alors que la base est l'issue de tous  les traitements via l'application). J'ai préféré conseiller à mon client de sauvegarder souvent la base et le alf_data (et tout ce qu'il contient) 1 fois chaque soir. Le alf_data est "seulement" victime d'un crash matériel (disque dur), la base de données étant plus sensible.

Pour les 2 scénarios, je préfère ne pas y avoir affaire .

Le support alfresco il existe ? Personnellement, je les sollicite le moins possible au vu de leur réponse qui ne sont que des questions
On ne peut que s'appuyer sur les forums (où il y a beaucoup de problème cités plutôt que des réponses).

[michaelh]

Par exemple, j'ai déplacé plusieurs milliers de fichiers dans une seule et même transaction.
Les logs étant terminés (ceux décrivant le process), je pensais que ce processus lourd était terminé.
Faux, des traitements arrière plan ont eu lieu : par ex. maj des indexes.

Hum … ça sent à plein nez le non respect des bonnes pratiques, en ce qui concerne la gestion des transactions par exemple.

[zomurn]

en fait, je sais que les actions qui étendent ActionExecuterAbstractBase (et qui implémentent executeImpl()) sont dans une transaction, donc je n'ai aucun code relatif à la gestion de transaction dans ma classe executant ce lourd process.
Cependant, je ne pense pas qu'une "énorme" transaction soit judicieuse non plus. J'ai donc déplace 1000 par 1000 mes documents dans un dossier dans une seule transaction, le commit (en base, maj des indexes) étant moins lourd.
En ce qui concerne la gestion des transactions, j'en utilise qu'une seule : les RetryingTransactionHelper qui ont toujours cette forme ci :

 RetryingTransactionCallback<Object> txnWork = new RetryingTransactionCallback<Object>()
                {
                    public Object execute() throws Exception
                    {
                        // Do stuff
                        Object result = …
                        return result;
                    }
                };
                TransactionService transactionService = serviceRegistry.getTransactionService();
                Object result = transactionService.getRetryingTransactionHelper().doInTransaction(txnWork, true);
‍‍‍‍‍‍‍‍‍‍‍‍

Je pense que c'est la bonne façon de procéder, me trompe-je ?