Projet

Général

Profil

Demande #1059

vérification de la restauration des sauvegardes

Ajouté par Loïc Dachary il y a plus de 11 ans. Mis à jour il y a environ 3 ans.

Statut:
Fermé
Priorité:
Normale
Assigné à:
Catégorie:
Story
Version cible:
Début:
29/11/2012
Echéance:
29/12/2012
% réalisé:

0%

Temps estimé:
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

Demandes liées

Lié à Admins - Anomalie #1364: la machine nagios échoue sur sur mail.april.orgFermé29/09/201329/09/2013

Actions

Historique

#1

Mis à jour par Loïc Dachary il y a plus de 11 ans

  • Version cible changé de Décembre 2012 (1/2) à Backlog
#2

Mis à jour par Loïc Dachary il y a plus de 10 ans

  • Assigné à mis à Nicolas Vinot
#3

Mis à jour par Nicolas Vinot il y a plus de 10 ans

  • Statut changé de Nouveau à En cours de traitement
  • Version cible changé de Backlog à Octobre 2013
#4

Mis à jour par Loïc Dachary il y a plus de 10 ans

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

Mis à jour par Nicolas Vinot il y a plus de 10 ans

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

Mis à jour par Loïc Dachary il y a plus de 10 ans

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

#7

Mis à jour par Loïc Dachary il y a plus de 10 ans

  • Version cible changé de Octobre 2013 à Backlog
#8

Mis à jour par Nicolas Vinot il y a plus de 7 ans

  • Description mis à jour (diff)
  • Assigné à Nicolas Vinot supprimé
#9

Mis à jour par François Poulain il y a plus de 7 ans

  • Statut changé de En cours de traitement à 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.

#10

Mis à jour par Christian P. Momon il y a environ 3 ans

  • Assigné à mis à François Poulain

Formats disponibles : Atom PDF