[Article] Backup, monitoring and troubleshooting

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
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 #

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 #

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.

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ô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 ; 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.

Backup, monitoring and troubleshooting

1. Sauvegarder #

Stratégie #

Outils #

Restaurer #

2. Superviser #

Quoi surveiller #

Outils #

3. Dépanner #

La démarche #

Fiches réflexes #

Réparer depuis un système de secours #

4. Exploiter dans la durée #

Routines #

My progress

Recommended Articles

Package managers