Gestion des sauvegardes AWS : vos sauvegardes existent-elles, fonctionnent-elles, et restaurez-vous assez vite?

Gérer des sauvegardes sur AWS, ce sont trois questions distinctes, et la plupart des équipes ne peuvent répondre qu’à la première. Est-ce que tout ce qui compte est sauvegardé? Est-ce que les tâches de sauvegarde réussissent vraiment, chaque nuit, sans que personne ait à y penser? Et pouvez-vous restaurer — une vraie restauration, chronométrée — dans le délai que l’entreprise tient pour acquis? Un plan de sauvegarde configuré une fois en 2023 ne répond à aucune de ces questions. La gestion des sauvegardes, c’est le travail continu d’y répondre en permanence.

Ce que vous décidez

La vraie décision, c’est de savoir si la sauvegarde est une case à cocher ou un système opéré. AWS vous donne les pièces : AWS Backup pour les plans et coffres centralisés, les sauvegardes automatiques RDS avec restauration à un instant précis, les instantanés EBS, le versionnage S3. Configurer n’importe laquelle de ces pièces prend un après-midi. Ce que les pièces ne donnent pas, c’est une garantie de couverture dans le temps. De nouvelles ressources sont créées sans l’étiquette qui les rattache à un plan. Une tâche se met à échouer parce qu’une politique de clé KMS a changé, et le courriel d’échec part vers une liste de distribution que personne ne lit. La rétention reste au réglage par défaut, qui supprime des points de récupération dont vous aviez besoin ou accumule des coûts de stockage sans fin.

L’autre moitié de la décision, ce sont les objectifs de reprise. Le RPO — la quantité de données que vous pouvez vous permettre de perdre — détermine la fréquence des sauvegardes. Le RTO — la durée d’interruption tolérable — détermine si une restauration par instantané est même viable, parce que restaurer un gros volume ou une grosse base de données à partir d’un instantané n’est pas instantané. Si personne n’a écrit un RPO et un RTO par système, l’horaire de sauvegarde relève de la devinette.

Quoi vérifier en premier

La couverture contre l’inventaire. Listez ce qui devrait être sauvegardé (bases de données de production, volumes EBS, EFS, tables DynamoDB) et comparez avec ce qui est réellement dans un plan de sauvegarde. L’écart, ce sont généralement les ressources créées après la mise en place du plan.
Les tâches échouées et expirées des 30 derniers jours. Une tâche échouée, c’est du bruit; la même ressource qui échoue chaque nuit depuis trois semaines, c’est un système sans protection.
Où vont les notifications d’échec. Un sujet SNS sans abonné actif, c’est des échecs silencieux.
La date du dernier test de restauration. Pas la dernière sauvegarde — la dernière fois que quelqu’un a restauré quelque chose en le chronométrant.
Où vivent les points de récupération. Si tous les points de récupération sont dans le même compte et la même région que la charge de travail, un seul jeu d’identifiants compromis ou un seul incident régional emporte les deux.

Comment vérifier

Tirez l’historique des tâches et la couverture depuis la CLI :

# Tâches de sauvegarde échouées récemment
aws backup list-backup-jobs --by-state FAILED --max-results 50

# Ce qu'AWS Backup croit protéger
aws backup list-protected-resources --max-results 100

# Points de récupération réellement présents dans le coffre
aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name Default --max-results 20

Dans la console, AWS Backup > Jobs > Backup jobs filtré sur Failed montre la même chose avec la raison de l’échec. Comparez ensuite les ressources protégées avec ce qui existe :

# Tout ce qui est étiqueté comme données de production (adaptez à votre convention)
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters "rds:db" "ec2:volume" "dynamodb:table" \
  --tag-filters Key=env,Values=prod

La commande la plus révélatrice, c’est l’historique des restaurations :

aws backup list-restore-jobs --max-results 20

Si elle ne retourne rien pour le dernier trimestre, personne n’a testé de restauration, et vos sauvegardes sont de l’espoir, pas de la reprise.

La marche à suivre

Écrivez d’abord l’inventaire. Listez chaque système dont la perte ferait mal, avec un RPO et un RTO par système convenus avec la personne qui porte l’impact d’affaires. Tout le reste découle de ce document.
Affectez par étiquette, pas à la main. Utilisez l’affectation de ressources par étiquette dans le plan de sauvegarde pour que les nouvelles ressources soient couvertes dès leur création, à condition que le processus de provisionnement applique l’étiquette. Imposez l’étiquette au provisionnement, pas par un ménage trimestriel.
Alarmez sur les échecs de tâches. Une alarme CloudWatch sur NumberOfBackupJobsFailed par coffre, acheminée là où un humain la voit dans la journée. Le traitement des échecs, c’est la différence entre gérer des sauvegardes et les avoir configurées.
Copiez hors du rayon d’impact. Les copies de coffre entre comptes et entre régions protègent contre la compromission d’identifiants et les incidents régionaux. La mécanique — et le test de restauration qui prouve que la copie fonctionne — est dans AWS Backup avec copie inter-région et inter-compte.
Faites une restauration chronométrée chaque trimestre. Restaurez un vrai système dans un environnement jetable, chronométrez de bout en bout, et comparez au RTO écrit. Le premier exercice trouve presque toujours une surprise : un droit KMS manquant, un groupe de sécurité qui n’existe pas dans le compte cible, un RTO qui relevait de la fiction.
Fixez la rétention délibérément. Le stockage des points de récupération est le principal facteur de coût, et les copies inter-région ajoutent des frais de transfert. Le stockage chaud coûte plus cher que le froid; AWS Backup peut faire passer les points de récupération admissibles au stockage froid après une période chaude minimale. La rétention doit venir du document d’inventaire, pas du réglage par défaut de la console.

Quand c’est la mauvaise approche

Si toute votre couche de données tient dans une seule instance RDS, un déploiement complet d’AWS Backup est peut-être plus de machinerie que nécessaire — les sauvegardes automatiques RDS avec une stratégie PITR et instantanés testée couvrent la base de données, et AWS Backup ne devient utile que lorsque EBS, EFS ou DynamoDB entrent en jeu. Si votre RPO se compte en minutes plutôt qu’en heures, aucun horaire d’instantanés n’y arrivera — c’est le territoire de la réplication (Multi-AZ, réplicas de lecture inter-région), avec les sauvegardes en deuxième ligne. Et dans une organisation multi-compte, les plans de sauvegarde par compte dérivent; déléguez l’administration et gérez les plans de façon centralisée.

Erreurs courantes

Confondre une tâche verte et une restauration testée. Une tâche de sauvegarde terminée prouve que l’instantané a été écrit, pas qu’il se restaure en quelque chose d’utilisable.
La dérive des étiquettes. Le plan couvre env=prod, quelqu’un provisionne avec Environment=Production, et la nouvelle base de données reste sans protection pendant des mois.
Le coffre dans le rayon d’impact. Des points de récupération dans le même compte que la charge de travail disparaissent avec elle si les identifiants sont compromis.
La rétention par défaut. Soit les points de récupération expirent avant que la comptabilité demande une restauration vieille d’un an, soit le coût de stockage s’accumule en silence pour toujours.

Garder le contrôle

Passez en revue les tâches échouées chaque semaine; traitez une ressource qui échoue à répétition comme un incident, pas comme une ligne de journal.
Faites une restauration chronométrée par trimestre et notez la durée à côté du RTO écrit.
Imposez l’étiquette de sauvegarde dans votre chaîne de provisionnement (valeurs par défaut du module IaC, ou règle SCP/Config qui signale les magasins de données non étiquetés).
Utilisez le verrouillage de coffre ou la copie inter-compte pour tout ce qu’un rançongiciel viserait.
Relisez l’inventaire RPO/RTO chaque année — l’importance des systèmes change.

Les sauvegardes échouent en silence et les restaurations échouent bruyamment, et l’écart entre les deux est là où les entreprises se font mal. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.