As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.
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").
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 2Le 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.
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.
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);
