Versions S3 : récupérer un objet écrasé ou supprimé

La gestion des versions S3 conserve les versions antérieures des objets d'un bucket Amazon S3. Elle peut permettre de récupérer un fichier écrasé ou un objet supprimé par une requête ordinaire, à condition que la version recherchée existe encore et reste accessible. Commencez par lister les versions, téléchargez celle qui semble convenir pour l'examiner, puis copiez-la vers la même clé pour en faire la version actuelle.

Ce guide concerne les buckets à usage général d'Amazon S3. Il ne confirme pas la disponibilité de ces fonctions chez un autre service compatible S3. Pour situer le service, consultez notre guide du stockage cloud Amazon.

Que change l'activation des versions S3 ?

La clé d'un objet désigne un emplacement comme recovery-demo/config.json. Lorsque la gestion des versions est activée, remplacer le contenu à cette clé crée une nouvelle version stockée. La plus récente devient la version actuelle ; la précédente reste accessible grâce à son identifiant de version.

Cet identifiant est opaque : ce n'est ni une date ni un numéro de séquence. Conservez la valeur exacte renvoyée par Amazon S3. Appuyez-vous sur les dates, les tailles, les traces de l'application et le contenu téléchargé pour choisir la version à récupérer.

Le réglage concerne l'ensemble du bucket, sans sélection par dossier. Son activation ne reconstitue pas des données déjà écrasées ou définitivement supprimées. Les objets existants conservent leur identifiant null ; des modifications ultérieures peuvent créer d'autres versions. AWS décrit ces limites dans sa présentation de la gestion des versions.

Activer les versions avant d'en avoir besoin

Dans la console S3, ouvrez le bucket à usage général, puis Properties. Modifiez Bucket Versioning et sélectionnez Enable. Vérifiez le compte AWS et le bucket avant d'enregistrer ce changement global. AWS recommande d'attendre 15 minutes après la première activation avant toute écriture ou suppression d'objet ; consultez ses instructions d'activation.

La commande AWS CLI suivante consulte le réglage sans le modifier. Remplacez le nom du bucket et utilisez le profil AWS et la région voulus.

aws s3api get-bucket-versioning --bucket "amzn-s3-demo-recovery-bucket"

La valeur Enabled du champ Status indique que les nouvelles écritures reçoivent des identifiants de version. Le comportement de Suspended diffère, comme expliqué plus bas. L'absence de Status indique un bucket sans gestion des versions. Après activation, cette fonction peut être suspendue, mais le bucket ne peut plus revenir à son état initial sans versions.

Pourquoi un objet supprimé peut rester récupérable

Dans un bucket où la gestion des versions est activée, une suppression sans identifiant de version crée normalement un marqueur de suppression. Ce marqueur devient actuel : une requête GET ordinaire renvoie donc une erreur 404, même si les versions contenant les données existent encore. Le marqueur possède une clé et un identifiant, mais aucun contenu. AWS précise le comportement des marqueurs de suppression.

Supprimer une version de données en désignant son identifiant la retire définitivement, sauf si un mécanisme de protection bloque la requête. La gestion des versions ne rend pas les données immuables. Une erreur 404 ne suffit pas non plus à prouver une suppression : vérifiez la clé exacte, le bucket et les droits avant d'engager la récupération.

Récupérer une version antérieure en quatre étapes

1. Lister les versions de la clé exacte

Cette commande AWS CLI liste les versions de données et les marqueurs de suppression. Un préfixe peut correspondre à plusieurs clés : la requête filtre donc les deux tableaux sur la clé exacte de l'exemple. Remplacez cette clé aux trois endroits concernés.

aws s3api list-object-versions --bucket "amzn-s3-demo-recovery-bucket" --prefix "recovery-demo/config.json" --query "{Versions:Versions[?Key=='recovery-demo/config.json'],DeleteMarkers:DeleteMarkers[?Key=='recovery-demo/config.json']}" --output json

La CLI traite normalement la pagination. N'ajoutez pas --no-paginate ou une limite --max-items restrictive en supposant obtenir tout l'historique. L'opération nécessite s3:ListBucketVersions, comme indiqué dans la référence de la commande.

Examinez VersionId, LastModified, Size et IsLatest. Choisissez une version de données dans Versions, et non une entrée de DeleteMarkers. Consulter l'historique ne vérifie pas le contenu.

2. Télécharger et examiner la version candidate

aws s3api get-object --bucket "amzn-s3-demo-recovery-bucket" --key "recovery-demo/config.json" --version-id "EXACT_VERSION_ID" recovered-config-review.json

Remplacez EXACT_VERSION_ID par l'identifiant choisi. Utilisez un nouveau nom de fichier local : cette commande peut écraser un fichier déjà présent. Examinez son contenu, comparez-le aux traces de l'application et vérifiez qu'il correspond à l'état recherché.

La lecture d'une version précise nécessite s3:GetObjectVersion. Le chiffrement peut imposer des droits supplémentaires sur la clé. Une version archivée peut nécessiter une restauration préalable. AWS documente ces conditions pour GetObject. Arrêtez la procédure si les conditions d'accès ou de restauration ne sont pas remplies.

3. Copier la version vérifiée vers la même clé

Copier une version conservée vers sa clé d'origine crée une nouvelle version actuelle lorsque la gestion des versions est activée. Les autres versions restent en place, y compris le contenu remplacé. AWS décrit cette méthode de récupération.

La fonction Python ci-dessous utilise un client S3 Boto3 configuré. Elle vérifie le propriétaire et l'état du bucket, puis copie la version source indiquée. Son appel modifie l'objet renvoyé par les requêtes GET ordinaires. Suspendez les écritures de l'application et les changements de configuration pendant l'opération : les vérifications préalables ne verrouillent pas le bucket.

def restore_version(s3, bucket, key, version_id, owner_account_id):
    """Create a new current version from a reviewed, retained version."""
    state = s3.get_bucket_versioning(
        Bucket=bucket, ExpectedBucketOwner=owner_account_id
    )
    if state.get("Status") != "Enabled":
        raise ValueError("Enable versioning before using this recovery helper")
    source = s3.head_object(
        Bucket=bucket, Key=key, VersionId=version_id,
        ExpectedBucketOwner=owner_account_id
    )
    # Conservative single-copy limit; larger objects need multipart copy.
    if source["ContentLength"] > 5_000_000_000:
        raise ValueError("Use a multipart-copy recovery workflow for this object")
    result = s3.copy_object(
        Bucket=bucket, Key=key,
        CopySource={"Bucket": bucket, "Key": key, "VersionId": version_id},
        ExpectedBucketOwner=owner_account_id,
        ExpectedSourceBucketOwner=owner_account_id,
        MetadataDirective="COPY"
    )
    return result["VersionId"]

Fournissez le client S3, le nom du bucket, la clé exacte, l'identifiant choisi et les 12 chiffres du compte propriétaire. La fonction est définie sans appel automatique. Gardez les identifiants d'accès dans votre configuration AWS habituelle plutôt que dans le script.

CopyObject accepte une copie unique jusqu'à 5 Go ; cette fonction applique une limite prudente de 5 000 000 000 octets. Au-delà, utilisez une copie multipartie. Le dictionnaire CopySource évite de construire manuellement une URL contenant la clé et l'identifiant de version. Vérifiez le chiffrement de destination, la classe de stockage, les métadonnées, les tags et les droits avant d'adapter cet exemple minimal. Copier le contenu ne garantit pas la reproduction de chaque propriété source.

4. Vérifier le nouvel objet actuel

Enregistrez l'identifiant de version renvoyé. Récupérez l'objet sans préciser de version, comparez-le au fichier examiné et testez l'application qui le lit avant de reprendre les écritures. Un autre processus peut créer une version plus récente pendant la récupération : une réponse de copie réussie ne suffit pas à établir l'état final vu par l'application.

Faut-il plutôt retirer le marqueur de suppression ?

Supprimer le marqueur actuel en désignant son identifiant exact peut rendre une version antérieure accessible. Examinez d'abord l'historique : un autre marqueur peut encore masquer les données voulues. Une nouvelle requête DELETE ordinaire n'annule pas la précédente ; elle peut ajouter un autre marqueur.

Copier la version de données choisie facilite souvent la vérification : le choix est explicite et l'historique intermédiaire reste conservé. Si vous préférez retirer le marqueur, suivez les instructions AWS et distinguez son identifiant de celui d'une version de données. Supprimer cette dernière est définitif.

Que se passe-t-il lorsque les versions sont suspendues ?

La suspension laisse les versions numérotées existantes dans le bucket, mais les nouvelles écritures utilisent un identifiant null. Une nouvelle écriture vers la même clé peut écraser définitivement une version null existante. Consultez le comportement des écritures après suspension.

Une suppression ordinaire dans un bucket suspendu peut retirer la version de données null et insérer un marqueur null. Les anciennes versions numérotées restent présentes, sauf suppression distincte. Ces règles de suppression après suspension expliquent pourquoi la suspension n'offre pas une protection équivalente avec moins de versions stockées.

Maîtriser les coûts sans perdre l'historique utile

Amazon S3 conserve des versions complètes, et pas seulement leurs différences. Vingt versions de 10 Mo représentent 200 Mo de données, avant les éventuels minimums facturables des classes de stockage ou frais supplémentaires. Ajoutez aux coûts de stockage ceux des requêtes, de récupération et de transfert.

Choisissez la durée de conservation selon le temps nécessaire pour détecter un problème et effectuer la récupération. Une règle de cycle de vie utilisant NoncurrentVersionExpiration supprime définitivement les anciennes versions éligibles. L'expiration de la version actuelle dans un bucket avec versions activées ajoute généralement un marqueur au lieu de retirer immédiatement l'historique. Lisez les règles d'expiration avant de configurer le nettoyage. Une conservation de 30 jours ne convient pas à tous les besoins.

Intégrer les versions dans un plan de récupération

Séparez les accès habituels de l'application des droits permettant de supprimer des versions précises ou de modifier leur conservation. Pour protéger les versions contre la suppression, examinez S3 Object Lock, ses durées de rétention et ses mises en conservation légale. L'activation des versions seule ne fournit pas ces protections.

L'historique des objets ne constitue pas non plus un instantané coordonné d'une base de données ou de plusieurs fichiers interdépendants. Prévoyez des sauvegardes cohérentes pour l'application, l'accès aux clés de chiffrement et des tests de restauration. Notre guide de la sauvegarde cloud aborde ces décisions plus larges.