Wiki source code of Surveiller les sauvegardes ReaR
Last modified by Equipe Opération on 14 - 01 - 2019
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{box cssClass="floatinginfobox" title="**Table des matières**" width="50%"}} | ||
| 2 | {{toc start="2" depth="6" numbered="true" scope="page"/}} | ||
| 3 | {{/box}} | ||
| 4 | |||
| 5 | == Objet == | ||
| 6 | |||
| 7 | |||
| 8 | Les sauvegardes ReaR disposent de mécanismes spécifiques de stockage des logs | ||
| 9 | |||
| 10 | |||
| 11 | == Gestion des logs == | ||
| 12 | |||
| 13 | Les logs de sauvegarde rear sont stockés par défaut dans(% style="background-color:null" %) {{info}}/var/log/rear/-rear-[nomserveur].log.{{/info}} | ||
| 14 | |||
| 15 | De plus, lors de la sauvegarde, ce fichier de log est copié sur le stockage de sauvegarde (Comme votre NAS ou un serveur de stockage intermédiaire). | ||
| 16 | |||
| 17 | |||
| 18 | Ces journaux pouvant être très verbeux (plusieurs milliers de lignes !), en premier lieu vous pouvez tenter d'exécuter les commandes suivantes pour potentiellement afficher l'erreur: | ||
| 19 | |||
| 20 | {{code language="bash"}} | ||
| 21 | rear -v mkrescue | ||
| 22 | rear -v mkbackuponly | ||
| 23 | {{/code}} | ||
| 24 | |||
| 25 | La première ligne construit l'image de recovery (RAW ou ISO), la seconde créé une sauvegarde de votre serveur. Vous pouvez ainsi déjà déterminer si le problème vient d'une des deux commandes particulières. | ||
| 26 | |||
| 27 | Si le problème n'est pas clair, vous pouvez tenter d'explorer les logs. Comme évoqué précédemment, les journaux peuvent être assez longs, c'est pourquoi vous pouvez vous contenter de la dernière centaine de ligne, qui contiendra généralement l'erreur. Cherchez le mot-clé "Stack trace". Cette trace, en plus d'indiquer le fichier qui a posé problème, montre quel commande a échoué. Pour plus d'informations de contexte de l'erreur vous pouvez regarder juste au dessus de cette stack trace. | ||
| 28 | |||
| 29 | |||
| 30 | == Exemple de log == | ||
| 31 | |||
| 32 | Par exemple, voici la stack trace d'une sauvegarde dont le chemin de stockage distant n'est pas bon : | ||
| 33 | |||
| 34 | {{code}} | ||
| 35 | 2018-09-26 12:28:12.264778589 Mounting with 'mount -v -o cred=/etc/rear/.cifs_credentials //share.entreprise.net/LinuxShare /tmp/rear.FPLfXf0Sng3dUyZ/outputfs' | ||
| 36 | domain=entreprise.net | ||
| 37 | mount.cifs kernel mount options: ip=192.168.1.138,unc=\\share.entreprise.net\LinuxShare,user=Srv_Backup_Linux,domain=entreprise.net,pass=******** | ||
| 38 | Retrying with upper case share name | ||
| 39 | mount.cifs kernel mount options: ip=192.168.1.138,unc=\\SHARE.ENTREPRISE.NET\LINUXSHARE,user=Srv_Backup_Linux,domain=entreprise.net,pass=******** | ||
| 40 | mount error(6): No such device or address | ||
| 41 | Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) | ||
| 42 | 2018-09-26 12:28:12.547050552 ERROR: Mount command 'mount -v -o cred=/etc/rear/.cifs_credentials //sfic2.int.ysosecure.com/LinuxBacku2 /tmp/rear.FPLfXf0Sng3dUyZ/outputfs' failed. | ||
| 43 | ==== Stack trace ==== | ||
| 44 | Trace 0: /usr/sbin/rear:543 main | ||
| 45 | Trace 1: /usr/share/rear/lib/mkbackup-workflow.sh:9 WORKFLOW_mkbackup | ||
| 46 | Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage | ||
| 47 | Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source | ||
| 48 | Trace 4: /usr/share/rear/prep/NETFS/default/060_mount_NETFS_path.sh:11 source | ||
| 49 | Trace 5: /usr/share/rear/lib/global-functions.sh:441 mount_url | ||
| 50 | Trace 6: /usr/share/rear/lib/_input-output-functions.sh:371 StopIfError | ||
| 51 | Message: Mount command 'mount -v -o cred=/etc/rear/.cifs_credentials //share.entreprise.net/LinuxShare /tmp/rear.FPLfXf0Sng3dUyZ/outputfs' failed. | ||
| 52 | == End stack trace == | ||
| 53 | 2018-09-26 12:28:12.629192845 Exiting rear mkbackup (PID 31126) and its descendant processes | ||
| 54 | {{/code}} |