Au boulot, pour gérer l’ensemble des sauvegardes des différents serveurs, j’utilise BrightStor ARCserve (Version 11.5) de CA (Computer Associates) relié à un lecteur de bande LTO PowerVault 114T (Dell). Ensemble permet de sauvegarder 800 Go au maximum sur une seule bande et ceci émanant de plusieurs serveurs. Le bouzin en question fonctionnait bien jusqu’au jour où on a eu une coupure de courant qui a, pour une raison que j’ignore (ou presque, vu qu’il faut régulièrement réviser les batteries), foutu en l’air l’onduleur et, par conséquent, le serveur de sauvegarde.
Dans la plupart du temps, tout redémarre comme si de rien n’était sauf que, cette fois-ci, c’est la sauvegarde qui a ramassé. Le phénomène suivant se produisait souvent mais de manière non systématique : E4101 – Impossible de se connecter au moteur de base de données.
Connement, j’ai cru que le problème venait juste du service associé « CA BrightStor Database Engine » qui s’arrêtait de manière intempestive après l’élagage de la base sans que je sache pourquoi. Mais le problème était (est?… j’espère que non) plus profond que ça.
En fait, Arcserve utilise par défaut une base de données interne : la base de données très volumineuse (VLDB) RAIMA BrightStor ARCserve Back (à tes souhaits). L’avantage étant de ne pas avoir à créer et utiliser une base de données Sql server, ce qui est le cas concernant mon serveur de sauvegarde. L’inconvénient… étant que c’est une grosse merde quand on a un arrêt inopiné comme se fut dernièrement.
VLDB comporte dix bases de données, chacune permettant de stocker des informations spécifiques. Les bases de données VLDB sont les suivantes :
- asjob
- aslogerr
- asmedia
- asmsg
- asmsgdat
- asobject
- asrhost
- astape
- astpdrv
- astpsdat (mon amour, ma peine, ma souffrance)
On appréciera au passage la documentation d’Arcserve à propos de VLDB :
Si le serveur comprenant VLDB rencontre des problèmes imprévus, comme des coupures de courant ou autre, il risque d’y avoir des incohérences dans la base de données. Si la base de données est incohérente, vous ne pouvez pas afficher les enregistrements de session détaillés. Vous risquez de ne pas pouvoir restaurer correctement par session, arborescence ou requête.
Ils auraient aussi pu dire que tout pouvait se mettre en l’air et empêcher toute sauvegarde.
Bref, entrons dans le vif du sujet et voici comment j’ai pu résoudre mon problème (du moins j’espère… réponse ce soir avec la sauvegarde du vendredi).
- Tout ce passe dans le répertoire d’Arcserve, au moins on a pas à aller chercher à gauche et à droit ce dont on a besoin.
- Je vous conseille d’utiliser les fichiers de procédure pour les services, afin d’être sur que les services sont arrêtés/démarrés :
..\ CA\BrightStor ARCserve Backup\Cstop.bat
..\ CA\BrightStor ARCserve Backup\Cstart.bat
- Une fois les services lancés proprement, vérifier qu’il n’y ai aucun job (sauvegarde, restauration, élagage) qui vienne interférer la vérification des bases
- A titre d’information, les bases (Velocis) peuvent être accessible via l’utilitaire ..\ CA\BrightStor ARCserve Backup\admin.exe. L’interface est ultramoche :
On voit tout de suite la sale application NT 4.0 recompilée pour fonctionner… ou pas
- Coté mots de passe, c’est tout par défaut (et donc rien à voir avec le compte NT « caroot » où je me suis fourvoyé) chez tout le monde : secret (ouep ça roxxe du poney).
- Pour vérifier les différentes bases, il faut lancer la commande dos suivante (où [bdd] est l’une des bases précédemment vues) :
dbcheck -a -L casdb;admin;secret [bdd]
- En cas d’erreur, il convient de lancer l’utilitaire suivant : Dbfix, qui corrigera les entrées dans la base de données
dbfix -a -L casdb;admin;secret [bdd]
Bon, faut être patient car, en plus d’être incapable de gérer le multicore, il met 3 plombes. Le traitement de la base asptsdat (la plus grosse forcément) dans mon cas a duré plusieurs heures (au moins plus de 6 heures)
Une fois ce traitement effectué, vous pouvez lancer d’autres utilitaires tels que dbdefrag (réduction du temps que met l’élagage de la base. CA conseille de lancer un élagage avant), keybuild (reconstruction des index de la table, à lancer après dbdefrag) et dbdlt (réduction de la taille d’une base).
Avec ces quelques éléments, vous devriez vous en sortir avec vos bases Arcserve, du moins je l’espère, tout comme j’espère que mes soucis actuels sont derrière moi.
