1. Sauvegarder #
Une sauvegarde non testée n'existe pas.
Stratégie #
| Question | À définir |
|---|---|
| RPO | perte de données acceptable (ex. 24 h → sauvegarde quotidienne) |
| RTO | durée de remise en service acceptable |
| Périmètre | /etc, données applicatives, bases (export cohérent), clés |
| Rétention | ex. 7 quotidiennes, 4 hebdomadaires, 12 mensuelles |
Outils #
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_dataRestaurer #
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restic # parcourir les sauvegardes comme un répertoireBonne 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 #
| Ressource | Seuil d'alerte typique |
|---|---|
| Disque | > 85 % ou plein dans moins de 24 h (tendance) |
| Inodes | > 90 % |
| Mémoire | available < 10 %, OOM kills |
| CPU / charge | charge > 2 × cœurs pendant 15 min |
| Services | unité systemd en échec, port fermé |
| Sauvegarde | dernière réussite > 26 h |
| Certificats | expiration < 14 jours |
| Mises à jour | correctifs 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.
3. Dépanner #
Les incidents les plus fréquents.
La démarche #
Fiches réflexes #
| Symptôme | Premières commandes |
|---|---|
| Le service ne démarre pas | systemctl 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 plein | df -h, df -i, du -xh --max-depth=1, lsof +L1, purge des journaux |
| Serveur lent | uptime, vmstat 1, iostat -xz 1, top, dmesg -T |
| Inaccessible par le réseau | ip -br a, ip route, ss -tlnp, pare-feu, curl -v depuis le serveur puis depuis l'extérieur |
| Connexion SSH refusée | console hors bande, sshd -t, journalctl -u ssh, fail2ban, droits de ~/.ssh |
| Ne démarre plus | mode 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 ; exit4. 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.
