RousselTMLEARNING

Article · Administration Linux : de la découverte à l'expertise

Sauvegarde, supervision et dépannage

1. Sauvegarder #

Une sauvegarde non testée n'existe pas.

Stratégie #

Règle 3-2-1
Une copie hors site et chiffrée protège aussi contre les rançongiciels et l'incendie.
QuestionÀ définir
RPOperte de données acceptable (ex. 24 h → sauvegarde quotidienne)
RTOdurée de remise en service acceptable
Périmètre/etc, données applicatives, bases (export cohérent), clés
Rétentionex. 7 quotidiennes, 4 hebdomadaires, 12 mensuelles

Outils #

Cycle restic
Planifiez la sauvegarde avec un timer systemd et supervisez la date du dernier succès.
rsync -aHAX --delete /srv/ backup01:/backups/app01/srv/   # miroir (attention, --delete propage les suppressions)
tar -czf /var/backups/etc_$(date +%F).tar.gz /etc
pg_dump -Fc appdb > /var/backups/appdb.dump                # base : export cohérent, pas de copie des fichiers à chaud

# restic : dédupliqué, chiffré, incrémental
export RESTIC_REPOSITORY=s3:https://s3.example.com/backups-app01 RESTIC_PASSWORD_FILE=/root/.restic
restic init
restic backup /etc /srv /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic snapshots ; restic check
# snapshot LVM : figer un volume le temps de la sauvegarde
sudo lvcreate -s -n snap_data -L 5G /dev/vg_data/lv_data
sudo mount -o ro /dev/vg_data/snap_data /mnt/snap && restic backup /mnt/snap
sudo umount /mnt/snap && sudo lvremove -y /dev/vg_data/snap_data

Restaurer #

restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restic        # parcourir les sauvegardes comme un répertoire
Bonne Pratique : Planifiez un test de restauration régulier sur une machine de test, et chronométrez-le : c'est votre RTO réel.

2. Superviser #

Être prévenu avant les utilisateurs.

Quoi surveiller #

RessourceSeuil d'alerte typique
Disque> 85 % ou plein dans moins de 24 h (tendance)
Inodes> 90 %
Mémoireavailable < 10 %, OOM kills
CPU / chargecharge > 2 × cœurs pendant 15 min
Servicesunité systemd en échec, port fermé
Sauvegardedernière réussite > 26 h
Certificatsexpiration < 14 jours
Mises à jourcorrectifs de sécurité en attente, redémarrage requis

Outils #

# métriques : Prometheus node_exporter
sudo apt install prometheus-node-exporter
curl -s localhost:9100/metrics | grep node_filesystem_avail_bytes
# journaux : envoi vers une plateforme centrale (Loki, Elasticsearch...) avec Alloy, Fluent Bit ou rsyslog
# vérification simple d'un service
systemctl is-active app || echo "app arrêtée" | mail -s "ALERTE app01" ops@example.com
À savoir : Les formations Prometheus, Zabbix, Grafana et Loki de RousselTM Learning détaillent la supervision d'un parc de serveurs.
Chaîne de supervision
Les formations Prometheus, Loki, Grafana et Alertmanager détaillent chaque brique.

3. Dépanner #

Les incidents les plus fréquents.

La démarche #

Méthode de dépannage
Changer une seule chose à la fois, et noter ce qu'on a fait.

Fiches réflexes #

SymptômePremières commandes
Le service ne démarre passystemctl status app, journalctl -u app -n 50, tester la configuration (nginx -t, sshd -t), droits sur les fichiers, port déjà pris (ss -tlnp), SELinux (ausearch -m avc)
Disque pleindf -h, df -i, du -xh --max-depth=1, lsof +L1, purge des journaux
Serveur lentuptime, vmstat 1, iostat -xz 1, top, dmesg -T
Inaccessible par le réseauip -br a, ip route, ss -tlnp, pare-feu, curl -v depuis le serveur puis depuis l'extérieur
Connexion SSH refuséeconsole hors bande, sshd -t, journalctl -u ssh, fail2ban, droits de ~/.ssh
Ne démarre plusmode rescue via GRUB, journalctl -b -1 -p err, fstab (findmnt --verify), système live puis chroot

Réparer depuis un système de secours #

# démarré sur un ISO live ou la console de secours du cloud
lsblk ; sudo mount /dev/sda2 /mnt
for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt
# corriger /etc/fstab, réinstaller GRUB, réinitialiser un mot de passe...
passwd root ; update-grub ; exit

4. Exploiter dans la durée #

Les routines de l'administrateur.

Routines #

  • Quotidien : alertes, sauvegardes réussies, espace disque.
  • Hebdomadaire : correctifs de sécurité, journaux d'authentification, comptes inutilisés.
  • Mensuel : test de restauration, revue des accès sudo et des clés SSH, mises à jour de version.
  • À chaque intervention : ticket, commandes notées, changement versionné (Ansible, Git), retour arrière prévu.

📄 Sauvegarde, supervision et dépannage d'un serveur Linux →

Mon suivi

  • ⏱ Durée estimée : ≈ 8 min

Connectez-vous pour suivre votre progression et prendre des notes. Se connecter

✉️ Poser une question

Articles recommandés

Bonnes Pratiques Kubernetes

Meilleures pratiques pour sécuriser et optimiser les déploiements Kubernetes.

Comparaison Offres Kubernetes

Analyse complète des offres managées de Kubernetes avec points forts, fonctionnalités, tarificati...

Stratégies de placement Kubernetes

Présentation des stratégies de placement dans Kubernetes pour optimiser la gestion des charges de...

CNI Kubernetes : Flannel, Calico et Cilium comparés

Kubernetes CNI : comprendre les plugins réseau (Container Network Interface) et comparer Flannel,...

Gestionnaires de packages

Les différents gestionnaires de packages pour Kubernetes et leurs avantages.

Jobs vs Serverless

Comparaison entre les Jobs Kubernetes et le modèle Serverless pour le calcul de tâches en arrière...

PersistentVolume, PersistentVolumeClaim et StorageClass dans Kubernetes

PersistentVolume (PV), PersistentVolumeClaim (PVC) et StorageClass dans Kubernetes : différences,...

Resource Quota Kubernetes

Guide complet sur les quotas de ressources Kubernetes pour la gestion des namespaces.

ConfigMaps et Secrets

Guide complet sur les ConfigMaps et Secrets dans Kubernetes.