wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>cours administration système sysadmin linux}}

Notes et transcriptions du cours "[[https://openclassrooms.com/fr/courses/2356316-montez-un-serveur-de-fichiers-sous-linux|Montez un serveur de fichiers sous Linux]]" disponible sur la plateforme [[https://openclassrooms.com|Openclassrooms]].


====== Sécurisez vos données ======

Dans la partie précédente, vous avez appris à vous prémunir des défaillances matérielles grâce aux technologies RAID. C’est une étape importante pour fiabiliser le stockage de vos données mais n’allez pas croire que cela vous dispense de faire des sauvegardes régulières.

**La sauvegarde est un élément** tellement **essentiel** dans les systèmes informatiques que je trouvais important de consacrer un chapitre pour approfondir cette notion. Derrière ce terme simple se cache tout un monde et vous devez comprendre certains concepts clés pour pouvoir définir la stratégie de sauvegarde la plus adaptée à vos besoins.

Tout d’abord, il faut distinguer :

  - les **sauvegardes synchrones** ;
  - et les **sauvegardes asynchrones**.


===== Sauvegardes synchrones et asynchrones =====

Les **sauvegardes synchrones**, ce sont les sauvegardes qui se font **en temps réel** comme dans le cas du RAID 1. À chaque instant, vous avez  un double des données sur un autre support. Un des seuls moyens d’avoir du "vrai" temps réel est d’écrire les données sur tous les supports en même temps. Vous pouvez dans ce cas vous permettre de lire les données aléatoirement sur un support ou un autre et d’avoir ainsi un système actif-actif.

{{schema_sauvegarde_synchrone.png|Sauvegardes asynchrones temps réel et presque temps réel}}

Parfois, il est plus simple et suffisant de faire toutes ses écritures sur un seul support et de **synchroniser ou répliquer** les données immédiatement sur d’autres supports. Dans ce cas-là, vous avez du "presque" temps réel. En fonction de la fréquence de changement de vos données et de la vitesse de votre synchronisation, vous pourrez choisir d’avoir :

  * un système **actif-actif** où vous lisez sur les deux supports aléatoirement ;
  * ou un système **actif-passif** dans lequel le support passif n’est utilisé qu’en cas de problème avec le système actif.

L’avantage des sauvegardes synchrones, c’est que vous avez toujours une copie "fraîche" de vos données. Vous évitez ainsi de perdre des données qui n’auraient pas encore été sauvegardées.

<note>
L’inconvénient, c’est qu’en cas de bug ou de mauvaise manipulation, **vous pouvez perdre vos données partout en même temps**.

Par exemple, si vous effacez par erreur un fichier sur un système en RAID 1, il est effacé des deux disques en même temps. Et là, c’est le drame…
</note>

Pour éviter ça, vous pouvez réaliser des **sauvegardes asynchrones**. Ce sont des sauvegardes à faire à intervalle régulier. En cas de problème, ça permet de revenir dans le passé mais vous pouvez perdre toutes les mises à jour depuis la dernière sauvegarde. La durée de l’intervalle est donc une affaire de compromis.

Alors sauvegardes synchrones ou asynchrones ?

Comme les erreurs sont toujours possibles, il vous faudra TOUJOURS des sauvegardes asynchrones mais idéalement, il vous faudrait avoir les deux !

Mais ça va me prendre beaucoup de place toutes ces sauvegardes ?

Oui, les sauvegardes peuvent prendre beaucoup de place. En même temps, il faut comparer le coût de stocker toutes ces sauvegardes avec le coût de... tout perdre.

Généralement, on met en place une **rotation des sauvegardes**, c’est-à-dire qu’on détermine une fréquence de sauvegarde et le nombre de sauvegardes qu’on veut conserver. Une fois qu’on a atteint ce nombre, chaque nouvelle sauvegarde entraîne la suppression de la plus ancienne. Pour gagner de la place, vous pouvez faire des sauvegardes moins souvent et en garder moins mais avant d’en arriver là, d’autres solutions pour gagner de l’espace sont envisageables.

{{schema_fenetre_sauvegarde.png|Fonctionnement de la rotation des sauvegardes}}


===== Réduisez la taille de vos sauvegardes par la compression, les sauvegardes différentielles et incrémentielles =====

La première chose à envisager pour **réduire la taille** de vos sauvegardes c’est de les **compresser**. Si vous sauvegardez des formats de fichiers qui sont déjà compressés comme des images JPEG, vous n’y gagnerez pas grand chose mais si vous sauvegardez des fichiers texte, le gain de place pourra être énorme. Il y a très peu de cas dans lesquels vous n’auriez pas intérêt à compresser vos sauvegardes, donc pensez-y.

Ensuite, des gens intelligents ont remarqué que quand vous faisiez une **sauvegarde complète** de vos données chaque jour, vous conserviez souvent beaucoup de données en double pour rien. Prenons l’exemple simple d’un système avec 1Go de données. Chaque jour, il n’y a pas de modifications mais vous ajoutez 100Mo de nouvelles données. Sur une semaine, une sauvegarde complète quotidienne donnerait :

{{estimation_stockage_sauvegardes.png|Estimation du stockage avec des sauvegardes complètes sur une semaine}}

Vous voyez qu’une manière plus économe de sauvegarder ces données serait de faire une sauvegarde complète le lundi. Ensuite chaque jour de la semaine, vous n’auriez à sauvegarder que ce qui a changé depuis le lundi. On parle alors de **sauvegardes différentielles**. Ça peut effectivement faire gagner beaucoup de place. Il faut juste vous rappeler que si vous voulez restaurer le système à l’état du jeudi, il faut à la fois la sauvegarde du lundi et la sauvegarde du jeudi.

{{sauvegarde_differentielle.png|Estimation du stockage avec des sauvegardes différentielles sur une semaine}}

On peut pousser le raisonnement encore plus loin et se dire qu’il y a encore beaucoup de données en double entre tous nos petits bouts de sauvegardes. Le plus efficace serait alors de ne sauvegarder chaque jour que les données qui ont changé depuis la veille. On parle alors de **sauvegardes incrémentales ou incrémentielles**. Pour restaurer le système à l’état du jeudi, il faudra à la fois les sauvegardes de lundi, mardi, mercredi et jeudi. C’est généralement le système qui limite le plus la taille des sauvegardes mais il est plus complexe à mettre en place et à gérer.

{{sauvegarde_incrementale.png|Estimation du stockage avec des sauvegardes incrémentielles sur une semaine}}

Comme je vous l’ai dit, **les sauvegardes asynchrones permettent de voyager dans le passé** puisqu’elles permettent d’accéder à votre système tel qu’il était à une date antérieure. Parfois, votre but ne sera pas seulement de limiter la perte de données due à un problème mais bien de pouvoir disposer d’un historique des changements de votre système. Dans ce cas, certaines technologies sont spécialement adaptées.

===== Sauvegardes et gestion de l’historique =====

On a vu dans la partie précédente, le cas particulier des **snapshots**. Un snapshot n’est pas à proprement parler une sauvegarde puisqu’il ne crée pas de double des données et qu’il s’appuie sur le même support de stockage que le système d’origine mais il peut avantageusement remplacer une sauvegarde dans certains contextes. Par exemple, il est fortement recommandé de faire une sauvegarde avant tout changement majeur sur votre système. Malheureusement, c’est parfois difficile à faire car une sauvegarde peut prendre beaucoup de temps et de ressources en termes de CPU, d’accès disques ou d’espace de stockage. Dans ces cas là, les snapshots, qui sont quasi-instantanés et consomment très peu de ressources, sont alors une bonne alternative pour vous permettre de retrouver votre système tel qu’il était avant le changement.

Si vous voulez conserver un historique des changements, en particulier si vos données sont au format texte, vous pouvez vous orienter vers un **système de gestion de versions** tel que Git ou SVN. Ces logiciels, indispensables dans le monde du développement logiciel, sont également très utiles pour gérer des fichiers de configuration système. Ils vous permettent de savoir qui a changé quoi, quand et même pourquoi grâce aux commentaires. De plus, à tout moment, vous pourrez revenir à une version antérieure.

Enfin, vous avez parfois besoin de conserver des sauvegardes sur de longues durées pour des raisons légales ou par nostalgie ;-) On parle alors d’**archivage**. Généralement, on souhaite garder ces archives :

  * très longtemps (plus d’un an) ;
  * avec un haut niveau de sécurité

mais :

  * on n’a pas besoin d’y accéder souvent ;
  * on peut tolérer un temps de restauration plus long.

Ces caractéristiques amènent à s’orienter vers des solutions spécifiques. Pendant longtemps, la norme était de copier ses données sur bande (support réputé fiable et pérenne) puis de les déposer dans un coffre à la banque. Aujourd’hui, les opérateurs cloud proposent des alternatives intéressantes comme par exemple l’offre [[https://aws.amazon.com/fr/glacier/|Amazon Glacier]] d’AWS.

Évidemment, les sauvegardes n’ont d’intérêt qu’à partir du moment où vous êtes capable de les restaurer. Pour ça, il est nécessaire de vous assurer de quelques points importants.


===== Sauvegardes et restaurations =====

Toute bonne stratégie de sauvegarde doit inclure une **stratégie de restauration**. Oui ça paraît bête mais vous seriez surpris du nombre de gens qui ne savent pas quoi faire de leur sauvegarde en cas de problème.

Je vous encourage donc fortement à formaliser et à **documenter la manière de restaurer des données** dès la création de vos premières sauvegardes. Il est aussi important de prendre le temps de faire régulièrement des **tests de restauration** pour vérifier que vos sauvegardes sont valides et que votre procédure est à jour. C’est comme les tests d’alarme incendie, sur le moment ça paraît parfois être une perte de temps mais le jour où un feu se déclenche vraiment, on est content d’avoir une procédure efficace à suivre sans réfléchir.

Penser à la restauration, c’est aussi penser à l’avenir et s’assurer que vous serez toujours en mesure d’avoir accès à vos sauvegardes. Aujourd’hui, les débats sur la fiabilité des supports de stockage sont un peu obsolètes. La chute des coûts du stockage fait qu’on préfère avoir des données en double sur des supports peu fiables comme les disques durs plutôt qu’utiliser des supports plus pérennes mais plus contraignants à utiliser comme les bandes magnétiques.

En revanche, il est toujours largement d’actualité de mener une réflexion sur le **format des fichiers de sauvegarde**. En particulier, le fait d’utiliser un format propriétaire lié à un logiciel et à une entreprise spécifique entraîne une **relation de dépendance** qu’il est important de bien évaluer. De même, l’utilisation de certains services en ligne pose parfois la question de la **possibilité de récupérer vos données**.

J’espère vous avoir sensibilisé à l’importance de bien sauvegarder vos données. Vous avez maintenant une vision plus complète de toutes les techniques à votre disposition.

===== En résumé =====

  * Des sauvegardes peuvent être synchrones ou asynchrones, les deux sont utiles mais vous devez toujours avoir des sauvegardes asynchrones ;
  * Vous pouvez réduire la taille de vos sauvegardes en les compressant et en utilisant des techniques de sauvegardes différentielles ou incrémentielles ;
  * En complément des sauvegardes, vous pouvez gérer l’historique de vos données à l’aide de snapshots ou de systèmes de gestion de versions ;
  * Vous pouvez avoir besoin de solutions spécifiques pour gérer l’archivage de vos données sur de longues périodes.
  * Une bonne stratégie de sauvegarde implique une bonne stratégie de restauration.

Dans le prochain chapitre, vous verrez comment partager des fichiers sur un réseau Linux grâce au protocole de partage de données NFS.




[[250_quiz_stockage_fichiers|◁ Précédent]] | [[000_start|⌂ Retour au sommaire]] | [[320_partage_nfs|Suivant ▷]]
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
