Stratégie de sauvegarde avec cron ou systemd et tests de restauration

Prompt

Agis comme un ingénieur système responsable des sauvegardes et de la reprise après sinistre.

Contexte :
- Ce qu’il faut protéger et sa taille : {{donnees}}
- Serveur et système d’exploitation : {{serveur}}
- Destination des sauvegardes : {{destination}}
- Perte de données et durée d’interruption acceptables (RPO et RTO) : {{objectifs}}
- Planificateur : {{planificateur}}

Livrables :
1. La stratégie globale : application de la règle 3-2-1, type de sauvegarde adapté à chaque donnée (logique, physique, incrémentale, archivage continu des WAL ou binlogs pour une restauration à un instant donné) et pourquoi il respecte le RPO.
2. Un calendrier sous forme de tableau : ce qui est sauvegardé, à quelle fréquence, à quelle heure et en combien de temps environ (ou [À COMPLÉTER] faute de données).
3. Une rétention grand-père/père/fils (quotidienne, hebdomadaire, mensuelle) et une estimation indicative de l’espace nécessaire à partir de mes volumes.
4. La sécurité : chiffrement en transit et au repos, gestion des clés (et conséquences de leur perte), copies immuables ou à suppression différée contre les rançongiciels, droits minimaux pour le compte de sauvegarde.
5. Des scripts prêts à l’emploi, en mode strict, avec logs et codes de sortie, s’appuyant sur des outils standard (par exemple `pg_dump` ou `mysqldump`, et un outil de sauvegarde dédupliquée comme restic ou borg pour les fichiers).
6. La planification avec {{planificateur}} : entrées crontab ou unités `.service` et `.timer` complètes, avec verrou contre les chevauchements.
7. La supervision : alerte si une sauvegarde échoue ou ne se lance pas (heartbeat), contrôle d’intégrité et détection de taille anormale.
8. Une procédure de restauration pas à pas pour chaque type de donnée, y compris la restauration à un instant donné si besoin.
9. Un plan de tests de restauration réguliers dans un environnement isolé, avec ce qu’il faut vérifier et documenter.

Contraintes :
- N’invente ni prix de stockage ni durées exactes ; explique comment les mesurer.
- S’il manque une information critique (volume de modifications quotidien, présence de réplicas…), demande-la d’abord.
- Rappelle qu’une sauvegarde jamais restaurée n’est pas vérifiée.
- Ne lance jamais de restauration de test sur la production.

Comment l'utiliser

Exemple d'utilisation

Exemple de résultat

# /etc/systemd/system/sauvegarde-fichiers.service
[Unit]
Description=Sauvegarde restic des fichiers utilisateurs
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/bin/flock -n /run/lock/sauvegarde-fichiers.lock \
  /usr/bin/restic backup /srv/uploads --tag fichiers
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/sauvegarde-fichiers.timer
[Timer]
OnCalendar=hourly
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

Informations clés

Catégorie

Programmation et développement · DevOps

Type de résultat

Code

Niveau

Intermédiaire

Conçu pour

ChatGPT, Claude, Gemini et Microsoft Copilot

Vérifié sur

En attente de vérification éditoriale

Variables

Données et taille, Serveur et système, Destination des sauvegardes, RPO et RTO et Planificateur

Langue

Français

Prix

Gratuit, sans inscription

Mis à jour

07/11/2026

Questions fréquentes