Sauvegarder un serveur Linux : méthode 3-2-1, automatisation et test de restauration

Une panne matérielle, une erreur de manipulation, une mise à jour défectueuse ou une attaque peuvent rendre les données d’un serveur indisponibles.

Une sauvegarde permet de restaurer les fichiers et les services après un incident. Pourtant, une copie qui n’a jamais été testée peut se révéler inutilisable au moment où elle devient indispensable.

Pour protéger efficacement un serveur Linux, il faut définir ce qui doit être sauvegardé, choisir une méthode adaptée, automatiser les copies et vérifier régulièrement que la restauration fonctionne.

1. Identifier les données à sauvegarder

Avant de choisir un outil, établissez la liste des données importantes.

Selon votre serveur, il peut s’agir de :

• fichiers applicatifs et documents ;
• bases de données ;
• fichiers de configuration ;
• données persistantes des conteneurs ;
• certificats et paramètres nécessaires au déploiement ;
• scripts et fichiers d’infrastructure ;
• données utilisateur.

Il n’est pas toujours nécessaire de copier intégralement le système d’exploitation. Un serveur peut parfois être reconstruit à partir d’une image propre, de configurations versionnées et de sauvegardes de données.

En revanche, les bases de données et les fichiers métier nécessitent une attention particulière. Une copie réalisée pendant une écriture peut être incohérente si la méthode de sauvegarde ne tient pas compte de l’application.

2. Comprendre la règle de sauvegarde 3-2-1

La règle 3-2-1 est un principe classique de protection des données :

• 3 copies des données, en comptant les données originales ;
• 2 types de supports ou de systèmes de stockage distincts ;
• 1 copie hors site, séparée de l’environnement principal.

Cette règle aide à réduire le risque qu’un incident unique détruise toutes les copies.

Par exemple, un serveur de production peut conserver ses données principales, disposer d’une sauvegarde sur un stockage distinct et envoyer une autre copie vers un emplacement distant.

Pour les environnements exposés aux ransomwares ou aux suppressions accidentelles, envisagez également des sauvegardes immuables ou hors ligne, lorsque c’est possible. L’accès aux sauvegardes doit être limité et protégé par des identifiants distincts.

La règle 3-2-1 est un point de départ, pas une garantie absolue. La stratégie doit correspondre à la valeur des données et aux conséquences d’une interruption.

3. Créer une première sauvegarde de fichiers avec tar

Pour sauvegarder un répertoire de fichiers, l’utilitaire tar peut créer une archive.

Par exemple :

sudo tar -czf /tmp/config-backup.tar.gz /etc

Cette commande crée une archive compressée du répertoire /etc. Le système peut afficher un avertissement concernant le retrait du premier / dans les chemins : ce comportement est normal pour éviter de restaurer accidentellement les fichiers directement à la racine.

Le fichier créé dans /tmp est une copie temporaire sur le même serveur. Il ne constitue donc pas une sauvegarde suffisante à lui seul.

Pour vérifier le contenu de l’archive :

tar -tzf /tmp/config-backup.tar.gz | head

Pour restaurer des fichiers, choisissez un emplacement temporaire et examinez le contenu avant de remplacer les fichiers existants. Une restauration directe sur un système actif peut écraser des configurations importantes.

Pour une vraie stratégie de sauvegarde, transférez les archives vers un stockage séparé et protégez-les conformément à la sensibilité des données.

4. Copier les fichiers vers un serveur distant avec rsync

rsync permet de synchroniser des fichiers entre des machines et de transférer uniquement les différences nécessaires dans de nombreux cas.

Exemple de copie d’un répertoire local vers un serveur distant :

rsync -a --human-readable /srv/documents/ [email protected]:/backups/serveur1/documents/

Remplacez les chemins, le nom d’utilisateur et le nom d’hôte par les valeurs de votre environnement.

L’option -a conserve plusieurs attributs utiles des fichiers, notamment les permissions et les dates. Pour des données particulières, d’autres options ou méthodes peuvent être nécessaires.

Avant d’automatiser une commande rsync, comprenez bien la différence entre la source et la destination. L’option --delete, par exemple, peut supprimer sur la destination les fichiers absents de la source. Elle ne doit pas être ajoutée sans avoir évalué les conséquences.

Une synchronisation simple ne fournit pas automatiquement un historique complet : si un fichier est modifié ou supprimé, la copie peut refléter cette modification. Pour conserver plusieurs versions, utilisez une stratégie de snapshots, de versions ou un outil de sauvegarde adapté.

5. Sauvegarder correctement une base de données

Les fichiers d’une base de données active ne doivent pas être copiés comme de simples fichiers sans tenir compte du moteur et de son état.

Pour PostgreSQL, une sauvegarde logique d’une base peut être réalisée avec pg_dump :

pg_dump -Fc -d nom_base -f sauvegarde.dump

Cette commande suppose que l’outil est installé et que l’utilisateur dispose des droits nécessaires pour accéder à la base. L’authentification doit être configurée de manière sécurisée.

Pour restaurer une sauvegarde au format personnalisé dans une base existante :

pg_restore -d nom_base sauvegarde.dump

La restauration peut nécessiter une base préparée, des rôles ou des droits spécifiques. Testez-la dans un environnement séparé avant de l’utiliser en production.

Pour les bases de données importantes, définissez également une stratégie couvrant les rôles, les paramètres, les sauvegardes complètes et, si les objectifs l’exigent, les journaux permettant une restauration à un instant précis.

La méthode exacte dépend du moteur de base de données et des objectifs de récupération.

6. Automatiser les sauvegardes

Une sauvegarde manuelle est facile à oublier. L’automatisation permet de respecter une fréquence régulière.

Sous Linux, cron peut exécuter une tâche à une heure déterminée. Ouvrez le crontab de l’utilisateur approprié :

crontab -e

Une tâche planifiée peut appeler un script dédié :

0 2 * * * /usr/local/sbin/backup-documents.sh

Cette ligne exécute le script chaque jour à 2 h, selon l’heure du serveur.

Le script doit gérer les erreurs, enregistrer les résultats et vérifier que la sauvegarde a réellement été créée. Une simple absence de message d’erreur ne suffit pas toujours à prouver que la copie est complète.

Pensez également à surveiller l’espace disque et à définir une politique de conservation afin que les sauvegardes ne remplissent pas progressivement le stockage.

7. Protéger les sauvegardes

Les sauvegardes peuvent contenir des données personnelles, des mots de passe, des clés ou des informations commerciales. Elles doivent donc être protégées comme les données originales, parfois davantage.

Quelques mesures importantes :

• chiffrer les copies lorsque leur contenu est sensible ;
• limiter les comptes autorisés à lire ou supprimer les sauvegardes ;
• séparer les identifiants du serveur de production et ceux du stockage distant ;
• conserver une copie hors du serveur principal ;
• protéger les clés de chiffrement et prévoir leur récupération ;
• surveiller les échecs de sauvegarde ;
• définir une durée de conservation adaptée.

Si le stockage distant permet l’immuabilité ou le verrouillage des objets, ces fonctions peuvent aider à protéger certaines copies contre les suppressions ou les modifications non autorisées.

Ne considérez pas une sauvegarde comme sûre uniquement parce qu’elle se trouve sur un autre répertoire ou un autre volume du même serveur.

8. Tester la restauration

La restauration est l’étape qui permet de vérifier si votre stratégie fonctionne réellement.

Prévoyez des tests périodiques dans un environnement isolé. Vérifiez notamment :

1. que les fichiers attendus sont présents ;
2. que les archives peuvent être lues ;
3. que les permissions et les propriétaires sont corrects ;
4. que les bases de données peuvent être restaurées ;
5. que l’application démarre avec les données restaurées ;
6. que les secrets et configurations nécessaires sont disponibles.

Un fichier de sauvegarde présent sur le disque peut être incomplet, corrompu ou inutilisable sans une configuration complémentaire.

Documentez les étapes de restauration et mesurez le temps nécessaire. Cette information permet de vérifier si votre procédure répond aux besoins de l’activité.

9. Définir RPO et RTO

Deux notions aident à construire une stratégie adaptée.

RPO — Recovery Point Objective : quantité maximale de données que l’organisation accepte de perdre, exprimée en temps. Un RPO d’une heure implique généralement de pouvoir récupérer un état suffisamment récent pour limiter la perte à cette période.

RTO — Recovery Time Objective : durée cible pour rétablir le service après un incident.

Ces objectifs influencent directement la fréquence des sauvegardes, le choix du stockage, le niveau d’automatisation et la complexité de la restauration.

Un petit site personnel et une application critique n’ont pas nécessairement besoin de la même architecture. Définissez les objectifs avant d’investir dans des solutions complexes.

10. Checklist de sauvegarde pour un serveur Linux

• Les données importantes ont été identifiées.
• Les bases de données sont sauvegardées avec une méthode adaptée.
• Les copies sont stockées en dehors du serveur principal.
• Les sauvegardes sensibles sont protégées.
• Les accès au stockage sont limités.
• Une politique de rétention est définie.
• Les tâches automatiques produisent des journaux.
• Les échecs de sauvegarde déclenchent une alerte.
• Les restaurations sont testées régulièrement.
• Les objectifs de récupération sont documentés.

FAQ

À quelle fréquence faut-il sauvegarder un serveur ?

La fréquence dépend de la quantité de données qui peut être perdue sans conséquences importantes. Les données qui changent souvent peuvent nécessiter des copies plus fréquentes que les fichiers statiques.

Une copie sur un deuxième disque suffit-elle ?

Elle protège contre certaines pannes du disque principal, mais pas nécessairement contre une suppression accidentelle, une compromission de l’ensemble du serveur ou un incident physique affectant les deux supports. Une copie distante ou isolée apporte une protection supplémentaire.

Puis-je sauvegarder une base de données en copiant son répertoire ?

Cela dépend du moteur et de son état. Une copie directe de fichiers actifs peut être incohérente. Utilisez une méthode de sauvegarde adaptée au moteur ou un mécanisme garantissant une copie cohérente.

Comment savoir si une sauvegarde est fiable ?

La méthode la plus importante consiste à tester la restauration, puis à vérifier l’intégrité des données et le fonctionnement de l’application. La réussite d’une tâche de copie ne garantit pas à elle seule une restauration réussie.

Conclusion

Une stratégie de sauvegarde fiable repose sur plusieurs éléments : des copies régulières, un stockage séparé, une protection adaptée des données et des tests de restauration.

La règle 3-2-1 fournit une base utile, tandis que les objectifs RPO et RTO aident à déterminer la fréquence et les moyens nécessaires.

N’attendez pas une panne pour vérifier vos sauvegardes. Une restauration testée et documentée est l’un des moyens les plus efficaces de réduire les conséquences d’un incident sur un serveur Linux.