Sauvegardes et surveillance de la disponibilité pour cinq sites et un serveur de messagerie

Nous gérons cinq sites web d'entreprise et un serveur de messagerie. Les sauvegardes existent dans le sens où le panneau d'hébergement montre une ligne verte : quelque chose est écrit quelque part du côté du fournisseur, sur la même machine, ouverte par les mêmes identifiants qui ouvrent le serveur lui-même. Personne ici n'a jamais téléchargé une telle archive, l'a décompressée ou essayé de restaurer un site à partir de celle-ci. Au printemps, une mauvaise mise à jour de module nous a coûté une partie de nos commandes, et nous avons passé deux jours simplement à découvrir s'il y avait quelque chose à restaurer. Nous préférerions apprendre cette réponse un mardi calme plutôt qu'au milieu de la prochaine panne.

Ce que nous voulons, c'est une routine ennuyeuse, écrite et testable. Bases de données et fichiers selon leurs propres calendriers, avec un nombre raisonnable de générations conservées. Deux emplacements de stockage à la fois, le second étant complètement en dehors du compte d'hébergement. Un serveur de test où une copie n'est pas seulement stockée mais décompressée et démarrée, de sorte que le rapport indique "site ouvert, administrateur connecté, dernière commande présente" plutôt que "l'archive fait quatre gigaoctets". Séparément, des vérifications de disponibilité qui examinent le contenu de la page et pas seulement le code de réponse, car un stub mis en cache répond avec un code de succès et ment pendant des heures. L'expiration du certificat et l'espace disque libre devraient nous alerter des semaines à l'avance, pas le matin où ils expirent.

Quelques conditions que nous insistons, car nous avons déjà été brûlés par le contraire :

— une sauvegarde ne compte comme fonctionnelle que lorsqu'une restauration a effectivement été effectuée à partir de celle-ci ; jusqu'à ce moment, ce n'est pas une sauvegarde, c'est de l'espoir ;
— les identifiants pour le stockage de sauvegarde sont séparés des identifiants pour le serveur, sinon une intrusion emporte les sites et les copies en un seul mouvement ;
— les alertes sont réglées de manière à ce que les gens les lisent au lieu de les mettre en sourdine : le seuil et le destinataire sont convenus avec nous avant que quoi que ce soit ne soit activé ;
— un manuel de récupération en langage clair, écrit pour notre propre personnel, afin que quiconque de service la nuit ne lise pas les scripts de quelqu'un d'autre ;
— un court message quotidien nous informant que les copies d'hier ont été faites et vérifiées.