Qu'est-ce que la réplication ?

La réplication copie les objets nouvellement créés et les mises à jour d'objets d'un bac source vers un bac cible.

• Seuls les nouveaux objets ou les nouvelles versions des objets existants (créés après l'ajout de la règle de réplication au seau) sont copiés dans le seau cible. Les objets existants peuvent être répliqués en les copiant sur eux-mêmes, créant ainsi une nouvelle version répliquée.
• Les métadonnées de l'objet source sont appliquées à l'objet répliqué.
• La réplication bidirectionnelle entre deux buckets nécessite que les règles soient actives sur les deux buckets.
• Les filtres (composés de préfixes et/ou de balises) peuvent être utilisés pour limiter la règle de réplication à un sous-ensemble d'objets. Plusieurs règles peuvent être définies dans une seule politique et ces règles peuvent spécifier différentes destinations. De cette manière, les différents objets d'un même panier peuvent être répliqués vers différentes destinations.

Pourquoi utiliser la réplication?

• Conserver une copie des données dans un bac situé dans un autre lieu géographique.
• Respectez les règles de conformité relatives à la souveraineté des données en définissant des règles de réplication qui stockent les répliques uniquement dans les emplacements autorisés.
• Les données de production et de test restent synchronisées, car la réplication conserve les métadonnées des objets telles que l'heure de la dernière modification, l'identifiant de la version, etc.
• Gérer la classe de stockage et les règles de cycle de vie des objets répliqués indépendamment de la source, en définissant une classe de stockage différente et/ou des règles de cycle de vie pour le seau cible. De même, vous pouvez stocker des répliques dans un bac dans une instance de service distincte ou même dans un compte IBM Cloud, et contrôler indépendamment l'accès aux répliques.

Démarrer avec la réplication

Pour commencer, voici quelques conditions préalables à remplir :

• Définissez le rôle de plate-forme Writer ou Manager sur le seau source, ou un rôle personnalisé avec les actions de réplication appropriées (tel que cloud-object-storage.bucket.put_replication).
• Il n'est pas nécessaire d'avoir accès au panier cible, mais il faut avoir suffisamment de rôles de plate-forme pour créer de nouvelles politiques IAM qui permettent au panier source d'écrire dans le panier cible.
• Le seau cible ne doit pas être doté d'un pare-feu de seau hérité, mais il peut utiliser des restrictions basées sur le contexte.
• Les objets cryptés à l'aide de SSE-C ne peuvent pas être répliqués, bien que le cryptage géré(SSE-KMS)comme Key Protect soit entièrement compatible avec la réplication.
• Les objets archivés ne peuvent pas être répliqués.
• Si les buckets source et cible se trouvent dans des comptes IBM différents, veillez à créer les buckets dans chaque compte.
• Activer le Versioning sur les buckets source et cible.

Le versionnage étant une exigence de la réplication, il est impossible de répliquer des objets dans des buckets configurés avec une politique Immutable Object Storage.

Utilisation d'un compte IBM

Pour répliquer des objets entre les buckets d'un même compte IBM, procédez comme suit :

1. Après avoir navigué jusqu'au seau source choisi, cliquez sur l'onglet Configuration.
2. Cherchez Bucket replication et cliquez sur le bouton Setup replication.
3. Sélectionnez la source de réplication, puis cliquez sur Suivant.
4. Sélectionnez l'instance et le godet dans les menus déroulants. Vous pouvez également basculer le bouton radio sur Non et coller le CRN du seau cible.
5. Cliquez sur le bouton Vérifier les autorisations.

Vous devez maintenant accorder au seau source Writer des autorisations sur le seau cible. Il y a plusieurs façons de le faire, mais la plus simple est d'utiliser IBM Cloud Shell et le CLI IBM Cloud.

1. Ouvrir IBM Cloud Shell dans une nouvelle fenêtre ou un nouvel onglet.
2. Copiez la commande CLI IBM Cloud affichée dans la console de stockage d'objets et collez-la dans le nouveau shell.
3. Revenez à la fenêtre ou à l'onglet de configuration du compartiment, puis cliquez à nouveau sur le bouton Vérifier les autorisations.

Vous allez maintenant créer une règle de réplication.

1. Assurez-vous que la case d'option Statut de la règle est réglée sur Activé.
2. Attribuez un nom et une priorité à la règle, ainsi que tout préfixe ou filtre de balise limitant les objets soumis à la règle de réplication.
3. Cliquez sur Terminé.

Utilisation de différents comptes IBM

Pour répliquer des objets entre des comptes IBM différents, procédez comme suit :

1. Configurer une politique IAM sur le compte de destination IBM. Pour plus d'informations sur la création d'une politique IAM, voir Qu'est-ce qu'une politique IAM et qui peut l'attribuer?

2. Trouvez l'identifiant du compte et l'identifiant de l'instance de service au format CRN sur la page de configuration du réservoir.

3. Dans l'interface utilisateur IBM Cloud du compte de destination, cliquez sur Manage>Access**(IAM)**.

4. Cliquez sur Authentification dans le panneau de gauche.

5. Cliquez sur Créer pour créer une nouvelle politique IAM.

6. Accorder la configuration d'une page d'autorisation de service. Il s'agit de la page sur laquelle vous arrivez après avoir créé une nouvelle politique IAM.

7. Sélectionnez Autre compte et indiquez l'ID du compte source.

8. Fournir un accès aux services comme Cloud Object Storage.

9. Dans le champ d'accès, sélectionnez Ressources spécifiques.

10. Sélectionnez Instance de service source et saisissez l'ID de l'instance de service pour le seau source.

11. Sous Cible, sélectionnez Cloud Object Storage pour l'accès au seau source.

12. Pour Target Scope, sélectionnez Specific resources> Service** Instance.

13. Sélectionnez l'ID de l'instance de service du compte de destination dans le menu déroulant.

14. Sélectionnez le rôle Rédacteur d'objets ou Rédacteur, selon le cas.

    Le rôle d' écrivain d'objets est suffisant pour permettre la réplication.

Terminologie

Source bucket: Le godet pour lequel une politique de réplication est configurée. C'est la source des objets répliqués.

Godet cible: Le seau défini comme destination dans la politique de réplication du seau source. C'est la cible des objets répliqués. Également appelé "seau de destination".

Réplique: Le nouvel objet créé dans un godet cible à la suite d'une demande faite à un godet source.

Qu'est-ce qui est reproduit?

Les nouveaux objets créés à l'aide de CopyObject, PutObject, ou CompleteMultipartUpload sont répliqués du compartiment source vers le compartiment cible. Les objets répliqués héritent des champs de métadonnées suivants de l'objet source : Etag, Last Modified Time, Version ID, user-attributes, et Tags.

Les marqueurs de suppression sont répliqués s'ils sont configurés par la politique de réplication.

Les mises à jour des balises d'une version sont répliquées du compartiment source vers le compartiment cible.

Les éléments suivants ne sont pas répliqués :

• Actions initiées par les événements du cycle de vie
• Objets écrits directement dans l'archive
• Objets restaurés à partir d'un niveau d'archivage
• Objets chiffrés à l'aide de SSE-C
• ACL d'objets

Utilisation de la réplication pour la continuité des activités et la reprise après sinistre

La réplication peut être utilisée pour assurer la continuité du service en cas de panne :

• Veillez à ce que les fichiers source et cible se trouvent à des endroits différents.
• Vérifier que les dernières versions des objets sont synchronisées entre les deux ensembles. Un outil tel que Rclone (la commande rclone check ) peut être utile pour vérifier le synchronisme à partir de la ligne de commande.
• En cas de panne, le trafic d'une application peut être redirigé vers le seau cible.

Cohérence et intégrité des données

Alors que IBM Cloud Object Storage assure une grande cohérence pour toutes les opérations d'entrée-sortie de données, la configuration des seaux n'est jamais cohérente. Après avoir activé les règles de réplication pour la première fois sur un bucket, il peut s'écouler quelques instants avant que la configuration ne se propage à travers le système et que les nouveaux objets ne commencent à être répliqués.

Gestion des erreurs

Des échecs de réplication peuvent survenir pour de nombreuses raisons, notamment (mais sans s'y limiter) des erreurs de configuration des compartiments, des interruptions de service et des interactions de l'utilisateur avec le compartiment de destination.

Object Storage dispose d'une résilience intégrée permettant de gérer les échecs de réplication. En cas d'échec, Object Storage peut réessayer pendant 30 jours maximum. La fréquence des nouvelles tentatives peut varier en fonction de la nature de la défaillance. Par exemple, les échecs dus à des erreurs d'E/S rares peuvent faire l'objet d'une nouvelle tentative en l'espace de quelques heures, tandis que ceux dus à des erreurs de configuration des compartiments utilisateur peuvent faire l'objet d'une seule nouvelle tentative par jour. Si une erreur n'est pas résolue dans un délai de 30 jours, le système ne tente plus automatiquement de la résoudre. Toutes les défaillances de longue durée peuvent être répertoriées à l'aide de la méthode ListBucketReplicationFailures.

Si vous souhaitez réessayer de traiter des échecs « anciens » datant de plus de 30 jours, vous pouvez déclencher une nouvelle tentative à l'aide de la balise PutBucketReplicationFailureReattempt.

Actions IAM

De nouvelles actions IAM sont associées à la réplication.

Événements Activity Tracker

La réplication génère des événements supplémentaires.

Pour les événements cloud-object-storage.bucket-replication.create, les zones suivantes fournissent des informations supplémentaires:

Lorsque la réplication est active, les opérations sur les objets peuvent générer les informations supplémentaires suivantes:

Vous pouvez tracer un objet à partir du moment où il est écrit dans la source jusqu'à ce qu'il soit écrit sur la cible. Recherchez l'ID de demande associé à l'écriture d'objet et trois événements doivent apparaître:

• Le PUT d'origine.
• Demande de synchronisation de la source.
• Demande PUT sur la cible.

L'un de ces trois éléments manquants indique un échec.

Utilisation et comptabilité

Toutes les répliques sont elles-mêmes des objets et contribuent à l'utilisation comme toutes les autres données. Une réplication réussie se traduit par des demandes facturables PUT, GET et HEAD, bien que toute bande passante consommée dans le processus de réplication ne soit pas facturée.

La réplication génère des mesures supplémentaires à utiliser avec IBM Cloud Monitoring:

• ibm_cos_bucket_replication_sync_requests_issued
• ibm_cos_bucket_replication_sync_requests_received

Interactions

Réplication d'objets existants

Une règle de réplication ne peut agir que sur les objets écrits après la configuration de la règle et son application à un compartiment. S'il existe des objets existants dans un compartiment qui doivent être répliqués, les processus de réplication doivent être informés de l'existence des objets. Pour ce faire, vous pouvez facilement utiliser l'opération PUT copy pour copier des objets sur eux-mêmes.

Ce processus réinitialise certaines métadonnées d'objets, notamment les horodatages de création. Cela a une incidence sur les politiques de cycle de vie et sur tout autre service utilisant des horodatages de création ou de modification (tels que les réseaux de diffusion de contenu). Assurez-vous que toutes les interruptions pouvant survenir lors de la réinitialisation des métadonnées d'objet sont traitées de manière appropriée.

Le processus implique:

1. Création d'une liste de tous les objets d'un compartiment qui doivent être soumis à des règles de réplication,
2. Itération sur cette liste, en exécutant une opération PUT copy sur chaque objet, la source étant identique à la cible de la demande.

Cet exemple ne réplique que la nouvelle version de l'objet créée par la requête PUT copy. Pour répliquer toutes les versions de l'objet, il faudrait également copier chacune d'entre elles individuellement.

L'exemple suivant est écrit en Python, mais l'algorithme peut être appliqué dans n'importe quel langage de programmation ou contexte.

import os
import sys
import ibm_boto3
from ibm_botocore.config import Config
# Create client connection
cos = ibm_boto3.client("s3",
                       ibm_api_key_id=os.environ.get('IBMCLOUD_API_KEY'),
                       ibm_service_instance_id=os.environ['SERVICE_INSTANCE_ID'],
                       config=Config(signature_version="oauth"),
                       endpoint_url=os.environ['US_GEO']
                       )
# Define the bucket with existing objects for replication
bucket = os.environ['BUCKET']
def copy_in_place(BUCKET_NAME):
    print("Priming existing objects in " + bucket + " for replication...")
    paginator = cos.get_paginator('list_objects_v2')
    pages = paginator.paginate(Bucket=bucket)
    for page in pages:
        for obj in page['Contents']:
            key = obj['Key']
            print("  * Copying " + key + " in place...")
            try:
                headers = cos.head_object(
                    Bucket=bucket,
                    Key=key
                    )
                md = headers["Metadata"]
                cos.copy_object(
                    CopySource={
                        'Bucket': bucket,
                        'Key': key
                        },
                    Bucket=bucket,
                    Key=key,
                    TaggingDirective='COPY',
                    MetadataDirective='REPLACE',
                    Metadata=md
                    )
                print("    Success!")
            except Exception as e:
                print("    Unable to copy object: {0}".format(e))
    print("Existing objects in " + bucket + " are now subject to replication rules.")
copy_in_place(bucket)

Exemples d'API REST

Les exemples suivants sont présentés à l'aide de cURL pour une utilisation plus facile. Les variables d'environnement sont utilisées pour représenter des éléments spécifiques à l'utilisateur, tels que $BUCKET, $TOKEN et $REGION. Notez que $REGION inclut également toutes les spécifications de type de réseau. Par conséquent, l'envoi d'une demande à un compartiment dans us-south à l'aide du réseau privé nécessite de définir la variable sur private.us-south.

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>SimpleReplication</ID>
              <Priority>1</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Disabled</Status>
              </DeleteMarkerReplication>
              <Filter/>
              <Destination>
                <Bucket>$DESTINATION_CRN</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>ProjectA</ID>
              <Priority>10</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_a/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_A</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>ProjectB</ID>
              <Priority>5</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_b/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_B</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>AcmeCorp</ID>
              <Priority>20</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Tag>
                  <Key>Client</Key>
                  <Value>ACME</Value>
                </Tag>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_C</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Rule>
    <ID>SimpleReplication</ID>
    <Status>ENABLED</Status>
    <DeleteMarkerReplication>
      <Status>DISABLED</Status>
    </DeleteMarkerReplication>
    <Destination>
      <Bucket>crn:v1:bluemix:public:cloud-object-storage:global:a/9978e07eXXXXXXXX66c89c428028654:ef1c725e-XXXX-4967-bcc1-734c03a2b846:bucket:replication-destination</Bucket>
    </Destination>
    <Priority>1</Priority>
    <Filter/>
  </Rule>
</ReplicationConfiguration>

curl -X "DELETE" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-failures" \
     -H 'Authorization: bearer $TOKEN'

<ListReplicationFailureResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Name>example</Name>
    <FirstSyncAttemptedBefore>2025-12-15T00:00:00.000Z</FirstSyncAttemptedBefore>
    <MaxKeys>10</MaxKeys>
    <IsTruncated>false</IsTruncated>
    <EncodingType>false</EncodingType>
    <KeyCount>2</KeyCount>
    <Contents>
        <Key>test-obj+*1765434016787</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114413</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.787Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.787Z</LastSyncAttempted>
        <SyncFailureCause>Versioning disabled on destination bucket</SyncFailureCause>
    </Contents>
    <Contents>
        <Key>test-obj+*1765434016786</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114412</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.786Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.786Z</LastSyncAttempted>
        <SyncFailureCause>Replication operation not authorized on target bucket</SyncFailureCause>
    </Contents>
</ListReplicationFailureResult>

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-reattempt" \
     -H 'Authorization: bearer $TOKEN'

HTTP/1.1 204 No Content
Connection: close
...
x-ibm-replication-reattempt-scheduled-time: Fri, 12 Dec 2025 00:00:00 GMT

Exemples SDK

Les exemples suivants utilisent les SDK IBM Cloud Object Storage pour Python et Node.js, bien que la mise en œuvre du versionnage des objets doive être entièrement compatible avec toute bibliothèque ou tout outil S3-compatible permettant de définir des points de terminaison personnalisés. L'utilisation d'outils tiers nécessite des données d'identification HMAC pour calculer les signatures AWS V4. Pour plus d'informations sur les données d'identification HMAC, voir la documentation.

#!/usr/bin/env python3
import ibm_boto3
from ibm_botocore.config import Config
from ibm_botocore.exceptions import ClientError
# Define constants
API_KEY = os.environ.get('IBMCLOUD_API_KEY')
SERVICE_INSTANCE = os.environ.get('SERVICE_INSTANCE_ID')
ENDPOINT = os.environ.get('ENDPOINT')
BUCKET = "my-replication-bucket" # The bucket that will enable replication.
# Create resource client with configuration info pulled from environment variables.
cosClient = ibm_boto3.client("s3",
                         ibm_api_key_id=API_KEY,
                         ibm_service_instance_id=SERVICE_INSTANCE,
                         config=Config(signature_version="oauth"),
                         endpoint_url=ENDPOINT
                         )
response = cosClient.put_bucket_versioning(
    Bucket=BUCKET,
    ReplicationConfiguration={
        'Rules': [
            {
                'ID': 'string',
                'Priority': 123,
                'Filter': {
                    'Prefix': 'string',
                    'Tag': {
                        'Key': 'string',
                        'Value': 'string'
                    },
                    'And': {
                        'Prefix': 'string',
                        'Tags': [
                            {
                                'Key': 'string',
                                'Value': 'string'
                            },
                        ]
                    }
                },
                'Status': 'Enabled'|'Disabled',
                'Destination': {
                    'Bucket': 'string',
                },
                'DeleteMarkerReplication': {
                    'Status': 'Enabled'|'Disabled'
                }
            },
        ]
    }
)

resp = cosClient.list_object_versions(Prefix='some-prefix', Bucket=BUCKET)

const IBM = require('ibm-cos-sdk');
var config = {
    endpoint: '<endpoint>',
    apiKeyId: '<api-key>',
    serviceInstanceId: '<resource-instance-id>',
};
var cos = new IBM.S3(config);
var params = {
  Bucket: 'STRING_VALUE', /* required */
  ReplicationConfiguration: { /* required */
    Role: 'STRING_VALUE', /* required */
    Rules: [ /* required */
      {
        Destination: { /* required */
          Bucket: 'STRING_VALUE', /* required */
        },
        Status: Enabled | Disabled, /* required */
        Filter: {
          And: {
            Prefix: 'STRING_VALUE',
            Tags: [
              {
                Key: 'STRING_VALUE', /* required */
                Value: 'STRING_VALUE' /* required */
              },
              /* more items */
            ]
          },
          Prefix: 'STRING_VALUE',
          Tag: {
            Key: 'STRING_VALUE', /* required */
            Value: 'STRING_VALUE' /* required */
          }
        },
        ID: 'STRING_VALUE',
        Prefix: 'STRING_VALUE',
        Priority: 'NUMBER_VALUE',
        }
      }
    ]
  },
  ContentMD5: 'STRING_VALUE',
};
cos.putBucketReplication(params, function(err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else     console.log(data);           // successful response
});