Project

General

Profile

Demande #1059

vérification de la restauration des sauvegardes

Added by Loic Dachary over 6 years ago. Updated almost 3 years ago.

Status:
Fermé
Priority:
Normale
Assignee:
-
Category:
Story
Target version:
Start date:
11/29/2012
Due date:
12/29/2012
% Done:

0%

Difficulté:
4 Fastidieux

Description

pour chaque service faire une sous tache qui
  • décrit ou se trouve la sauvegarde
  • explique comment le restaurer
  • explique comment tester son bon fonctionnement avec des sondes nagios ou des tests unitaires

Related issues

Related to Admins - Anomalie #1364: la machine nagios échoue sur sur mail.april.org Fermé 09/29/2013 09/29/2013

History

#1 Updated by Loic Dachary over 6 years ago

  • Target version changed from Décembre 2012 (1/2) to Backlog

#2 Updated by Loic Dachary almost 6 years ago

  • Assignee set to Nicolas Vinot

#3 Updated by Nicolas Vinot almost 6 years ago

  • Status changed from Nouveau to En cours de traitement
  • Target version changed from Backlog to Octobre 2013

#4 Updated by Loic Dachary almost 6 years ago

Le lancement d'une sauvegarde incrémentielle manuellement sur nagios-hetzner et nagios a fonctionné. Il s'agit peut etre d'un effet de bord du probleme lié a la corruption due a mail.april.org qui a été corrigé aujourd'hui.

#5 Updated by Nicolas Vinot almost 6 years ago

Pas de backup incrémental
Sur beaucoup de machines sauvegardées, il n'existe quasiment aucun backup incrémental, la totalité des sauvegardes sont des sauvegardes intégrales. Exemple controller.vm.april-int.
Je soupçonne un conflit de configuration avec les périodes d'interdiction (lun-ven, 7h-19h), les heures de polling (2h-7h) et les durées de rétention (6.97 pour les full, 0.97 pour les incr)
En 5h, aucune machine n'a le temps de se backuper et encore moins l'intégralité des machines. Passé 7h, plus aucun backup n'est lancé, jusqu'à 2h le lendemain.
Du coup, le reliquat ne sera fait que le jour suivant.
Un tour complet des machines n'arrive que tous les X jours (X>7 à ce que j'ai vu), délai qui dépasse la rétention incrémentale et donc déclenche une sauvegarde intégrale à chaque fois.
Ça explique aussi l'aléatoire observé dans les sauvegardes, avec des backups qui sont faites au petit bonheur la chance et en tout cas pas quotidiennement.
Il reste à confirmer tout ça, c'est pas vraiment clair et difficilement traçable.
Prévoir une nuit de veille pour voir de visu ce qui se passe.
Quelque chose qui me confirme quand même ce diagnostique est que seule 4 machines ont des incrémentales, ce qui correspond exactement au nombre de backups exécutables en parallèle.
Chaque jour, seules 4 machines seraient backupées avant 7h du matin, et donc toujours les mêmes (avec incrémentaux), au détriment des autres machines qui se contentent des miettes.
h1. Durée de backup
Il y a des problèmes de durée de backup. On dépasse la 10aine d'heure, voire 24h pour des machines de moins de 10Go (hertzner).
Les IO ne semblent pas en cause (<30%), ni la charge de la machine (<1), ni le réseau (<100kbs), en tout cas chez hertzner.
Il est difficile de debugger le problème, backuppc lançant les rsync en mode serveur et communiquant ensuite par la socket ouverte.
On ne peut donc pas simuler ce que backuppc fait ni ce qui se passe.
h1. Plantage de backup
Des backups échouent avec comme erreur
fileListReceive() failed
Done: 0 files, 0 bytes
Got fatal error during xfer (fileListReceive failed)

Idem, difficile à débugger car on ne connait pas les commandes envoyées à « rsync --server » par la socket.
Le cas le plus bizarre est le backup de la machine hertzner, où l'erreur n'est apparu qu'au bout de 24h aujourd'hui…
Il reste aussi le cas de spip.libre-en-fete.org, qui ne semble même pas avoir d'accès ssh ouvert, mais que backuppc tente quand même de sauvegarder.
h1. Surcharge des machines.
Les machines en charge des backups écroulent l'infrastructure régulièrement.
On a un double problème, interne à chaque machine de backup et entre les machines de backup.
En interne, backuppc possède une limite qui interdit plus de X backup à la fois (4 dans notre cas).
Mais il peut lancer 4 backups simultanés vers 4 machines virtuelles hébergées par le même host, ce qui va écrouler les têtes de lecture des disques du host ainsi que la bande passante.
En externe, on backup depuis plusieurs sources et personne ne se synchronise pour interdire de déclencher des backups sur une machine déjà en cours de travail.
L'exemple le plus frappant est pavot, qui peut se retrouver avec 5 ou 6 processus de copies en parallèle (4 en tant que machine de backup + 1 ou 2 en tant que machine en cours de sauvegarde par hertzner ou ovh).
Tous ces accès simultanés explosent le load des machines (>70 pendant 4h sur pavot), les io (100+%) et le réseau.
Les têtes de disque doivent aussi être fortement sollicitées par 5 processus concurrents d'accès aux données.
Ce problème peut expliquer en partie les durées de sauvegarde.

#6 Updated by Loic Dachary almost 6 years ago

il n'y a plus de problèmes, tous les hosts sont sauvegardés

#7 Updated by Loic Dachary almost 6 years ago

  • Target version changed from Octobre 2013 to Backlog

#8 Updated by Nicolas Vinot about 3 years ago

  • Description updated (diff)
  • Assignee deleted (Nicolas Vinot)

#9 Updated by François Poulain almost 3 years ago

  • Status changed from En cours de traitement to Fermé

Perso je ne vois pas comment on fait ça, d'une parce qu'on n'a pas une approche orientée service (il y a des interdépendances, un service dépend en général de plusieurs confs et logiciels sur plusieurs machines) et d'autre part car on n'a pas de gestion de conf qui nous permette facilement d'instancier des services pour jouer.

Amha la validation des backups est nécessaire, mais pas praticable sous cette forme.

Also available in: Atom PDF