Sign in Subscribe
linux

Les sauvegardes : Piqûre de rappel

Stéphane Codazzi

• 4 min read
Les sauvegardes : Piqûre de rappel

Que vous ayez un serveur dédié, un serveur virtuel, un hébergement mutualisé ou un raspberry pi dans votre cave, vous devriez toujours sauvegarder vos données importantes.

Pourquoi protéger mes services

La sauvegarde des données, n'est pas la seule façon de protéger vos données. Bien que celle-ci permette la récupération de vos données en cas de panne physique de votre serveur, ou encore d'incendie de votre hébergeur.
Néanmoins, si votre seule protection contre la perte de données est la mise en place de sauvegarde, sachez que ça n'évitera pas une rupture de service (le temps de la restauration des données), et la perte de données (entre la sauvegarde, et la panne).

En effet, suivant le service que vous fournissez, vous allez peut être avoir besoin de plus qu'une simple sauvegarde des données. Et voir encore aujourd'hui tant de personnes n'ayant rien sauvegardé me pousse à faire une petite piqûre de rappel.

Je vais essayer de classer les actions à prendre, suivant le type de service fournis.

Avant toute choses, souvenez vous qu'une sauvegarde ne doit pas être située au même endroit géographiquement que votre service. Si vous avez votre serveur chez un hébergeur, voyez si vous pouvez sauvegarder dans un autre datacenter, si vous ne pouvez pas, sauvegardez chez un autre hébergeur. Si vos données sont vraiment importantes, doublez la sauvegarde. Il vaut mieux être trop prudent !

Mon service n'est pas important.

Si votre service n'est pas important, qu'il ne participe pas à une rentrée d'argent, qu'il n'est pas orienté business, et qu'il peut rester hors ligne plus de 24 heures, alors je peux me permettre de n'utiliser qu'une sauvegarde des données. C'est à vous de choisir quoi sauvegarder, et à quelle fréquence. Mais pensez à :

  • Vos bases de données. Si vous avez des données, sauvegardez les !
  • Vos fichiers de sites. Tout est déjà sur un dépôt git ? C'est très bien, mais qu'en est t'il de votre configuration, vos fichier uploadés, ... Vous n'avez pas tout, sur votre dépôt git !
  • Vos différentes configurations système : vos vhosts pour les services web par exemple.
  • Quand vous créez un serveur, pensez si ce n'est pas encore le cas à sauvegarder votre infra, en utilisant des scripts comme Ansible.
  • Pensez à faire un PRA (Plan de reprise d'activité). Quelque soit votre activité, pensez au jour où vous perdez tout, et faite vous une doc ou un script sur comment remonter toute votre infra. Vous ne savez pas comment faire ? Faites le test : Prenez une de vos sauvegarde, et tentez de remonter toute votre infra. Vous n'y arrivez pas ? Alors sauvegardez plus de choses.

Mon service est important

Votre service est important, il est orienté business, et il ne peut pas être hors ligne (ou du moins, pas longtemps). Vous aurez aussi besoin de sauvegarder vos données. Prenez le temps de lire le paragraphe précédent.
Mais les sauvegardes ne vous seront pas suffisantes. Vous devrez alors mettre un place une redondance de vos services. Là encore, c'est à vous qu'il incombe de choisir quelle solution vous conviens le mieux. Quelques exemples :

  • La première option, est de permettre à votre service de fonctionner sur plusieurs serveurs. Plutôt que d'avoir un gros serveur, vous allez avoir besoin de plusieurs serveurs (peut être moins performant). Vous aurez l'avantage d'avoir la charge de vos utilisateurs sur plusieurs serveurs, ainsi, si vous voulez augmenter la puissance de votre service, vous n'avez qu'a ajouter un nouveau serveur à votre infra. Par contre, il faudra vous assurer que votre service est compatible: si ça ne pose pas de problème pour l’exécution de PHP, ça ne sera peut être pas le cas pour votre base de données.
  • La deuxième option, est d'avoir un serveur de secours. Si vous pouvez vous permettre d'avoir moins de puissance (mais un service qui continue de fonctionner), vous pouvez prendre un serveur un peu moins puissant (et onéreux), le temps de remettre en place le serveur principal. Dans cette configuration, le serveur de secours se synchronisera en temps réel sur le serveur principal, et prendra le relais qu'une fois que le serveur principal sera hors ligne. L'avantage, c'est que vous n'aurez pas à retoucher votre service pour qu'il puisse fonctionner sur plusieurs serveurs. L'inconvénient majeur, c'est que vous allez payer pour un serveur qui ne sera peut être jamais utilisé.
  • Votre service est dans un cloud, et vous êtres à l'abris de toute panne physique ? Alors relisez cette page, et remplacez le mot "serveur" par "cloud". En effet, même si vous évitez un certain nombre ne pannes, le cloud ne permet pas toujours d'être à l'abris de pannes. Si votre service est important, alors pensez à mettre une infra sur au moins deux hébergeurs cloud, de sorte que si l'un tombe, l'autre puisse prendre le relais.

Comment sauvegarder mes données

Plusieurs options s'offriront à vous. Si vous utilisez un serveur dédié, vous devrez sauvegarder vous même vos données. Vous pouvez alors créer votre propre script de sauvegarde, ou utiliser une solution déjà existante :

Si vous utilisez un hyperviseur, vous devrez alors sauvegarder vos VM / conteneurs. Voici une liste de services qui pourrait vous intéresser :

Où sauvegarder les données

Là encore, à vous de choisir où déposer vos sauvegardes. Là encore plusieurs choix s'offres à vous :

  • Dans un cloud type dropbox / google drive. (Vous devrez impérativement crypter vos données !).
  • Dans un cloud openstack (exemple, chez OVH: https://www.ovhcloud.com/fr/public-cloud/cloud-archive/ 0,01€/Go/mois).
  • Sur un/plusieurs de vos serveur/Nas, géographiquement éloigné de votre service.

Sign up for more like this.

Enter your email
Subscribe