Backup Alfresco Linux

[dranakan]

Hello,

Je désire améliorer ma procédure de sauvegarde d'Alfresco (32r2 sous Redhat).

Actuellement je crée un fichier tar avec un dump de la base, le alf_data, tout le répertoire d'Alfresco et les logs (/var/log). Je garde sur le disque un copie de fichier backup et je l'envoie sur un partage réseau (lequel est sauvé sur bande). Cette procédure dure 40 minutes maintenant et va augmenter avec les données… Avant de sauver, les fichiers de sauvegardes plus vieux que 24 heures sont effacés avec crontab.
Je fais une sauvegarde à chaud à 12H00 et une autre la nuit.

Cela tourne depuis une année mais récemment j'ai des erreurs à midi car je mettais dans le tar des répertoires où des données pouvaient être supprimées pendant le traitement (Alfresco/alf_data/lucene-indexes/ ou Alfresco/tomcat/temp/). Je vais corriger ceci est excluant ces répertoires pour les hot backups.

Je me pose la question si le principe du tar est le plus judicieux car cela prend beaucoup de temps et de CPU… j'ai lu aussi que certaines personnes utilisaient RSYNC… Je vais aussi migrer vers une version plus récente d'Alfresco (3.4d pour le moment). Avez-vous des commentaires pour améliorer ma stratégie de backup ? D'autres idées ?

Merci bien

[rguinot]

procédure générale la :
http://wiki.alfresco.com/wiki/Backup_and_Restore

possible de faire des backups incrémentaux sur le contentstore, un fichier écrit dans le contentstore n'est jamais changé in place.

n'oubliez pas qu'il n'y a pas de backups a chaud des indexes lucene (interdit!)

[dranakan]

Merci bien d'avoir répondu.

Je fais donc un tar.gz que je copie sur un partage. Cela utilise de la CPU mais fais gagner de la place disque.
Quel est la méthode que vous recommandez ? (pas de compression ? backup incrémentaux ? )

Merci bien.

[dranakan]

J'ai médité un peu… J'ai constaté que la compression avait un facteur de 2 avec mes données, essentiellement PDF (22G -> 11 G, avec 40 minutes pour compression et transfert sur partage).

Mon nouveau plan de sauvegarde

1. Dump
2. Rsync sur un partage (dump, alf_data, logs…)
Si erreur avec rsync, créer un tar (contenant dump, alf_data, logs…) sur le serveur lui-même et envoyer une alarme.

On perd l'avantage de réduire les données sur le partage mais on gagne considérablement en temps CPU, trafic réseau. Avec cette méthode on peut augmenter le nombre de sauvegarde par jour.

Les commentaires sont les bienvenus.

[rguinot]

attention à l'ordre : http://wiki.alfresco.com/wiki/Backup_and_Restore#Summary:_Time_ordering_of_data
attention aux backups des indexes, pas de backup a chaud du repertoire lucene-indexes, utilisez backup-lucene-indexes si backup a chaud, avec recovery AUTO des indexes a la restauration.

[dranakan]

Merci rguinot,

J'ai suivi l'ordre et les recommandations. J'ai aussi effectué des tests de restauration pour valider.

Mes questions sont plus générales… cela concerne plus précisément la manière de faire lorsqu'il commence à y avoir beaucoup de données (>10GO).

[dranakan]

Je pense utiliser Rsync mais une simple copie sur un partage n'est pas suffisant à mon avis.

Si les données du serveurs sont corrompues (mauvaise manipulation, secteur disque défaillants, virus, …) les mauvaises données sont transmises sur le partage dès la sauvegarde et la restauration devient impossible.

Il faut prévoir de garder des copies des sauvegardes sur plusieurs jours (le temps de voir la panne)… Mais quelle est la manière recommandée pour faire ceci ? Il faudrait, une fois la sauvegarde terminée, démarrer une copie sur le partage ? où utiliser un autre système qui permettrait d'historiser chaque sauvegarde sur plusieurs jours (comme Acronis par exemple) ?

[dranakan]

re…