Replicação de objetos

A replicação permite que você defina regras para a cópia automática e assíncrona de objetos de um bucket de origem para um bucket de destino na mesma conta. Além disso, você pode copiar objetos de um bucket para outro bucket em contas diferentes.

O que é replicação?

A replicação copia objetos recém-criados e atualizações de objetos de um bucket de origem para um bucket de destino.

  • Somente novos objetos ou novas versões dos objetos existentes (criados depois que a regra de replicação foi adicionada ao bucket) são copiados para o bucket de destino. Os objetos existentes podem ser replicados copiando-os sobre si mesmos, criando uma nova versão que é replicada.
  • Os metadados do objeto de origem são aplicados ao objeto replicado.
  • A replicação bidirecional entre dois buckets exige que as regras estejam ativas em ambos os buckets.
  • Os filtros (compostos de prefixos e/ou tags) podem ser usados para que a regra de replicação seja aplicada somente a um subconjunto de objetos. Várias regras podem ser definidas em uma única política e essas regras podem especificar destinos diferentes. Dessa forma, diferentes objetos no mesmo bucket podem ser replicados para diferentes destinos.

Por que usar a replicação?

  • Mantenha uma cópia dos dados em um bucket em uma localização geográfica diferente.
  • Atenda às normas de conformidade para a soberania dos dados, definindo regras de replicação que armazenam réplicas somente dentro dos locais permitidos.
  • Mantenha os dados de produção e de teste sincronizados, pois a replicação retém os metadados do objeto, como a hora da última modificação, o ID da versão e assim por diante.
  • Gerencie a classe de armazenamento e as políticas de ciclo de vida dos objetos replicados independentemente da origem, definindo uma classe de armazenamento diferente e/ou regras de ciclo de vida para o bucket de destino. Da mesma forma, você pode armazenar réplicas em um bucket em uma instância de serviço separada ou até mesmo em uma conta IBM Cloud e também controlar independentemente o acesso às réplicas.

Primeiros passos com a replicação

Para começar, aqui estão alguns pré-requisitos que devem ser atendidos:

  • Defina a função de plataforma Writer ou Manager no bucket de origem ou uma função personalizada com as ações de replicação apropriadas (como cloud-object-storage.bucket.put_replication) atribuídas.
  • Você não precisa ter acesso ao bucket de destino, mas precisa ter funções de plataforma suficientes para criar novas políticas de IAM que permitam que o bucket de origem grave no bucket de destino.
  • O bucket de destino não deve ter um firewall de bucket legado ativado, mas pode usar restrições baseadas em contexto.
  • Os objetos criptografados usando SSE-C não podem ser replicados, embora a criptografia gerenciada(SSE-KMS), como Key Protect, seja totalmente compatível com a replicação.
  • Os objetos em um estado arquivado não podem ser replicados.
  • Se os buckets de origem e de destino estiverem em contas IBM diferentes, certifique-se de criar os buckets em cada conta.
  • Habilite o controle de versão nos buckets de origem e de destino.

Como o controle de versão é um requisito para a replicação, é impossível replicar objetos em buckets configurados com uma política Immutable Object Storage.

Usando uma conta IBM

Para replicar objetos entre buckets na mesma conta IBM, faça o seguinte:

  1. Depois de navegar até o bucket de origem escolhido, clique na guia Configuration (Configuração ).
  2. Procure a replicação do Bucket e clique no botão Setup replication (Configurar replicação ).
  3. Selecione a fonte de replicação e clique em Avançar.
  4. Selecione a instância e o bucket nos menus suspensos. Como alternativa, alterne o botão de opção para Não e cole o CRN do bucket de destino.
  5. Clique no botão Check permissions (Verificar permissões ).

Agora, você precisará conceder ao bucket de origem as permissões Writer no bucket de destino. Há várias maneiras de fazer isso, mas a mais fácil é usar o IBM Cloud Shell e a CLI do IBM Cloud.

  1. Abra o site IBM Cloud Shell em uma nova janela ou guia.
  2. Copie o comando IBM Cloud CLI mostrado no console do armazenamento de objetos e cole-o no novo shell.
  3. Retorne à janela ou guia de configuração do bucket e clique novamente no botão Check permissions (Verificar permissões ).

Agora você criará uma regra de replicação.

  1. Certifique-se de que o botão de rádio de status da regra esteja definido como Ativado.
  2. Dê à regra um nome e uma prioridade, bem como qualquer prefixo ou filtro de tag que limitará os objetos sujeitos à regra de replicação.
  3. Clique em Pronto.

Usando diferentes contas IBM

Para replicar objetos entre buckets em diferentes contas IBM, faça o seguinte:

  1. Configure uma política de IAM na conta de destino IBM. Para obter informações sobre como criar uma política de IAM, consulte O que são políticas de IAM e quem pode atribuí-las.
  2. Localize o ID da conta e o ID da instância do serviço no formato CRN na página Configuração do Bucket.
  3. Usando a interface do usuário IBM Cloud da conta de destino, clique em Manage>Access**(IAM)**.
  4. Clique em Authentication (Autenticação ) no painel esquerdo.
  5. Clique em “Criar” para criar uma nova política do IAM.
  6. Conceder uma configuração de página de autorização de serviço. Esta é a página em que você chegará depois de criar uma nova política de IAM.
  7. Selecione Outra conta e forneça o ID da conta de origem.
  8. Fornecer acesso ao serviço como Cloud Object Storage.
  9. Em Escopo de acesso, selecione Recursos específicos.
  10. Selecione Source Service Instance (Instância de serviço de origem) e insira o ID da instância de serviço do bucket de origem.
  11. Em Target (Destino), selecione Cloud Object Storage para o acesso ao bucket de origem.
  12. Em Target Scope (Escopo de destino), selecione Recursos específicos>**Service Instance (Instância de serviço).
  13. Selecione o ID da instância de serviço da conta de destino no menu suspenso.
  14. Selecione a função Object Writer ou Writer, conforme necessário.

A função de escritor de objetos é suficiente para ativar a replicação.

Terminologia

Bucket de origem: O bucket para o qual uma política de replicação está configurada. É a origem dos objetos replicados.

Compartimento de destino: O bucket definido como o destino na política de replicação do bucket de origem. É o destino dos objetos replicados. Também chamado de balde de "destino".

Réplica: O novo objeto criado em um bucket de destino devido a uma solicitação feita a um bucket de origem.

O que é replicado?

Novos objetos criados por meio de CopyObject, PutObject ou CompleteMultipartUpload serão replicados do bucket de origem para o bucket de destino. Os objetos replicados herdarão os seguintes campos de metadados do objeto de origem: Etag, Last Modified Time, Version ID, user-attributes, e Tags.

Os marcadores de exclusão serão replicados se configurados pela política de replicação.

As atualizações das tags de uma versão serão replicadas do bucket de origem para o bucket de destino.

Os itens a seguir não são replicados:

  • Ações iniciadas por eventos do ciclo de vida
  • Objetos gravados diretamente no arquivo
  • Objetos restaurados de uma camada de arquivo
  • Objetos criptografados via SSE-C
  • ACLs de objeto

Utilização da replicação para continuidade de negócios e recuperação de desastres

A replicação pode ser usada para fornecer continuidade de serviço em caso de interrupção:

  • Certifique-se de que os buckets de origem e de destino estejam em locais diferentes.
  • Verifique se as versões mais recentes dos objetos estão sincronizadas entre os dois buckets. Uma ferramenta como o Rclone (o comando rclone check ) pode ser útil para verificar a sincronicidade a partir da linha de comando.
  • No caso de uma interrupção, o tráfego de um aplicativo pode ser redirecionado para o bucket de destino.

Consistência e integridade dos dados

Embora o site IBM Cloud Object Storage ofereça uma consistência forte para todas as operações de E/S de dados, a configuração do bucket acaba sendo consistente. Depois de ativar as regras de replicação pela primeira vez em um bucket, pode levar alguns instantes para que a configuração se propague pelo sistema e novos objetos comecem a ser replicados.

Tratamento de erros

Podem ocorrer falhas de replicação por diversos motivos, incluindo (mas não se limitando a) configurações incorretas do bucket, interrupções no serviço, interações do usuário com o bucket de destino, etc.

O COS possui resiliência integrada para lidar com falhas de replicação. Quando ocorre uma falha, o COS pode tentar novamente por até 30 dias. A frequência das tentativas pode variar dependendo da natureza da falha. Por exemplo, falhas causadas por erros raros de E/S podem ser repetidas em questão de horas, enquanto falhas decorrentes de configurações incorretas do bucket do usuário podem ser repetidas uma vez por dia. Se uma falha não for resolvida em até 30 dias, o sistema não tentará mais corrigi-la automaticamente. Todas as falhas de longo prazo podem ser listadas por meio de ListBucketReplicationFailures.

Se você desejar tentar novamente falhas “antigas” que ocorreram há mais de 30 dias, é possível acionar uma nova tentativa usando o PutBucketReplicationFailureReattempt.

Causas de falha

Na resposta da API do ListBucketReplicationFailures , o parâmetro SyncFailureCause é fornecido em cada elemento de falha, indicando a última causa conhecida da falha. A tabela a seguir descreve as possíveis causas:

Causa Explicação
Controle de versões desativado no bucket de destino O controle de versões não está habilitado no bucket de destino. É provável que o usuário tenha suspendido o controle de versão após a configuração da replicação.
Operação de replicação não autorizada no bucket de destino O serviço COS não está autorizado a modificar o bucket de destino em nome do usuário. Verifique se a autorização entre serviços ainda existe entre os recursos dos buckets de origem e de destino no IAM.
Bucket remoto não encontrado Não foi possível localizar o bucket de destino. É possível que o usuário tenha excluído o bucket de destino. Verifique se o bucket de destino ainda existe.
O bucket de origem/remoto não foi encontrado ou está desativado O balde não foi encontrado ou está inutilizável. Verifique se o bucket ainda existe. Se isso acontecer, entre em contato com o suporte ao cliente.
Objeto de destino não encontrado Tentou replicar uma alteração nos metadados (por exemplo, bloqueio de tag/objeto), mas o objeto de destino não existe. É provável que o usuário tenha excluído o objeto do bucket de destino antes que a alteração pudesse ser replicada.
Objeto local não encontrado O objeto de origem não foi encontrado ao tentar a replicação. É provável que o usuário tenha excluído o objeto de origem logo após criá-lo ou modificá-lo.
O bloqueio de objetos não está ativado no bucket de destino Tentou replicar as configurações do Object Lock em um objeto, mas o bucket de destino não tinha o Object Lock ativado.
A chave de criptografia não está ativa ou foi excluída O COS tentou recuperar a chave de criptografia de Key Protect (o bucket de origem tem SSE-KP/SSE-HPCS configurado), mas a chave foi excluída.
Faltam as informações do endpoint da instância do KMS Não foi possível recuperar o ponto de extremidade do Serviço de Gerenciamento de Chaves necessário para ler a chave de criptografia. Se o erro persistir, entre em contato com o suporte ao cliente.
Permissões insuficientes para consultar informações sobre o endpoint do KMS O recurso do bucket de origem não possui permissões para consultar o endpoint do Serviço de Gerenciamento de Chaves necessário para ler a chave de criptografia. Verifique sua política de autorização entre serviços do IAM.
Erro interno Vários problemas internos que impedem a replicação. Entre em contato com o suporte ao cliente.

Ações do IAM

Há novas ações de IAM associadas à replicação.

Ação do IAM Função
cloud-object-storage.bucket.get_replication Gerenciador, Gravador, Leitor
cloud-object-storage.bucket.put_replication Gerenciador, gravador
cloud-object-storage.bucket.delete_replication Gerenciador, gravador
cloud-object-storage.bucket.get_replication_failures Gerenciador, Gravador, Leitor
cloud-object-storage.bucket.put_replication_reattempt Gerenciador, gravador

Eventos do Activity Tracker

A replicação gera eventos adicionais..

Ação de Evento Gerado em Descrição
cloud-object-storage.bucket-replication.create Depósito de origem Quando o usuário faz uma solicitação à API PutBucketReplication
cloud-object-storage.bucket-replication.read Depósito de origem Quando o usuário faz uma solicitação à API GetBucketReplication
cloud-object-storage.bucket-replication.delete Depósito de origem Quando o usuário faz uma solicitação à API DeleteBucketReplication
cloud-object-storage.bucket-replication-failures.list Depósito de origem Quando o usuário faz uma solicitação à API ListBucketReplicationFailures
cloud-object-storage.bucket-replication-failures.update Depósito de origem Quando o usuário faz uma solicitação à API PutReplicationFailureReattempt
cloud-object-storage.object-replication.sync Depósito de origem Quando o COS replica um objeto do bucket de origem
cloud-object-storage.object-replication.create Depósito de destino Quando o COS cria uma nova versão de réplica no bucket de destino
cloud-object-storage.object-replication.update Depósito de destino Quando o COS replica uma atualização de metadados em uma réplica existente no bucket de destino
cloud-object-storage.object-replication.delete Depósito de destino Quando o COS replica um marcador de exclusão no bucket de destino

Para eventos cloud-object-storage.bucket-replication.create, os campos a seguir fornecem informações extras:

Campo Descrição
requestData.replication.num_sync_remote_buckets O número de buckets de destino especificados nas regras de replicação do bucket
requestData.replication.failed_remote_sync Os CRNs dos depósitos que falharam na verificação de réplica

Quando a replicação está ativa, as operações em objetos podem gerar as seguintes informações extras:

Campo Descrição
requestData.replication.replication_throttled Indica se a replicação do objeto foi atrasada na origem devido a um mecanismo de regulagem
requestData.replication.destination_bucket_id O CRN do depósito de destino
requestData.replication.sync_type O tipo de operação de sincronização.
- content indica que os dados do objeto e quaisquer metadados foram gravados no destino.
- tag indica que as tags do objeto foram replicadas.
- retention indica que as configurações de retenção do Object Lock foram replicadas.
- legal_hold indica que as configurações de retenção legal do Object Lock foram replicadas.
- delete indica que o marcador de exclusão foi gravado no destino.
responseData.replication.source_bucket_id O CRN do depósito de origem
responseData.replication.result Os valores podem ser success, failure (indica um erro do servidor), user (indica um erro do usuário.
responseData.replication.message A mensagem de resposta HTTP (como OK).

É possível rastrear um objeto a partir de quando ele é gravado na origem até ser gravado no destino. Procure o ID de solicitação associado à gravação do objeto e três eventos devem aparecer:

  • O PUT original..
  • A solicitação de sincronização da origem.
  • A solicitação PUT no destino..

Qualquer um desses três ausentes indica uma falha

Uso e contabilidade

Todas as réplicas são objetos em si e contribuem com o uso como qualquer outro dado. A replicação bem-sucedida resulta em solicitações PUT, GET e HEAD faturáveis, embora qualquer largura da banda consumida no processo de réplica não seja faturado

A replicação gera métricas adicionais para uso com IBM Cloud Monitoring:

  • ibm_cos_bucket_replication_sync_requests_issued
  • ibm_cos_bucket_replication_sync_requests_received

Interações

Versionamento

A versão é obrigatória para ativar a replicação. Depois de ativar a versão nos depósitos de origem e de destino e configurar a replicação no depósito de origem, é possível encontrar os problemas a seguir:

  • Se você tentar desativar a versão no depósito de origem, o Object Storage retornará um erro. Deve-se remover a configuração de replicação antes de poder desativar a versão no depósito de origem.
  • Se você desativar a versão no depósito de destino, a replicação falhará.

Bloqueio de objeto

O Object Lock pode ser ativado em buckets com replicação. Quando os objetos de origem são criados com o Object Lock (retenção e/ou retenção legal) ou se o Object Lock for atualizado em objetos existentes, ele será replicado para o destino.

O Object Lock só pode ser replicado se estiver ativado no bucket de destino. Portanto, recomenda-se ativar o Object Lock no bucket de destino, caso ele esteja ativado no bucket de origem.

A tabela abaixo descreve o comportamento quando os buckets de origem e de destino apresentam configurações diferentes de Object Lock:

Bloqueio do objeto de origem Bloqueio do objeto de destino Comportamento
Ativado Ativado Todos os estados de bloqueio de objetos da origem serão replicados para o destino.

Se o objeto de origem for criado sem o Object Lock, a retenção padrão do bucket de destino poderá ser aplicada à réplica.

A replicação do Object Lock segue todas as restrições do Object Lock do S3. Por exemplo, nunca é possível reduzir o período de retenção na réplica no modo de conformidade se o usuário tiver feito alterações de forma independente no destino.
Desativado Ativado Os objetos de origem não podem ter o Object Lock; portanto, os estados do Object Lock nunca serão propagados da origem para o destino.
Se o bucket de destino tiver uma retenção padrão definida, ela será aplicada às novas réplicas criadas.
Ativado Desativado Os objetos de origem criados com o Object Lock não serão replicados. Essas falhas são repetidas pelo COS e podem ser replicadas assim que o Object Lock for ativado no bucket de destino. Quaisquer atualizações relacionadas à retenção do Object Lock ou à retenção legal em objetos existentes também não podem ser replicadas até que o Object Lock seja ativado no destino.

Os objetos de origem criados sem o Object Lock ainda podem ser replicados.

Criptografia Key Protect

Os objetos de origem serão criptografados usando a chave raiz do depósito de origem e as réplicas serão criptografadas usando a chave raiz do depósito de destino

Configurações do ciclo de vida

Se uma política de ciclo de vida do estiver ativada em um depósito de destino, as ações de ciclo de vida serão baseadas no horário de criação original do objeto na origem, não no horário em que a réplica se torna disponível no depósito de destino

Immutable Object Storage

O uso de políticas de retenção é impossível em um depósito com versão ativada e, como a versão é um requisito para replicação, é impossível replicar objetos para ou a partir de um depósito com o Object Storage ativado.

Firewalls de depósito anteriores

Os depósitos que usam firewalls anteriores para restringir o acesso com base em endereços IP não podem usar a replicação, pois os serviços de segundo plano que replicam os objetos não possuem endereços IP fixos e não podem transmitir o firewall

Em vez disso, recomenda-se usar restrições baseadas em contexto para controlar o acesso com base nas informações de rede

Cloud Functions e Code Engine

A configuração da replicação não fornece um acionador para eventos do Cloud Functions ou do Code Engine neste momento, mas as gravações e exclusões de objetos criarão notificações Object:Write e Object:Delete para os depósitos de origem e de destino. Esses eventos são anotados com um campo notifications.replication_type que indica se o evento acionou uma sincronização ou foi acionado pela sincronização.

Replicando objetos existentes

Uma regra de réplica só pode agir em objetos que são gravados após a regra ser configurada e aplicada a um depósito Se houver objetos existentes em um depósito que devem ser replicados, os processos de replicação precisam ser informados sobre a existência dos objetos. Isso pode ser facilmente realizado usando a operação PUT copy para copiar objetos para si mesmos

Esse processo reconfigurará alguns metadados do objeto, incluindo registros de data e hora de criação Isso afetará as políticas de ciclo de vida e quaisquer outros serviços que usem registros de data e hora de criação ou modificação (como redes de entrega de conteúdo). Assegure-se de que quaisquer interrupções que possam surgir da reconfiguração de metadados do objeto sejam tratadas apropriadamente.

O processo envolve:

  1. Criando uma lista de todos os objetos em um depósito que devem estar sujeitos a regras de replicação,
  2. Iterando sobre essa lista, executando uma operação PUT copy em cada objeto com a origem sendo idêntica ao destino da solicitação

Este exemplo replicará apenas a nova versão do objeto criado pelo pedido PUT copy Para replicar todas as versões do objeto, seria necessário copiar cada versão individual também.

O exemplo a seguir é gravado em Python, mas o algoritmo poderia ser aplicado em qualquer linguagem de programação ou contexto

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)

Exemplos da API REST

Os exemplos a seguir são mostrados usando cURL para facilidade de uso.. Variáveis de ambiente são usadas para representar elementos específicos do usuário, como $BUCKET, $TOKEN e $REGION. Observe que o $REGION também incluiria quaisquer especificações de tipo de rede, portanto, enviar uma solicitação para um depósito no us-south usando a rede privada exigiria a configuração da variável como private.us-south.

Ativar replicação em um depósito

A configuração de replicação é fornecida como XML no corpo da requisição Novas solicitações sobrescreverão quaisquer regras de replicação existentes presentes no depósito.

Uma configuração de replicação deve incluir pelo menos uma regra e pode conter no máximo 1.000. Cada regra identifica um subconjunto de objetos para replicar filtrando os objetos no depósito de origem. Para escolher subconjuntos adicionais de objetos para replicação, inclua uma regra para cada subconjunto.

Para especificar um subconjunto dos objetos no depósito de origem para aplicar uma regra de replicação, inclua o elemento Filter como um filho do elemento Rule. É possível filtrar objetos com base em um prefixo de chave de objeto, uma ou mais tags de objeto ou ambas. Ao incluir o elemento Filter na configuração, você também deve incluir os elementos a seguir: DeleteMarkerReplication, Status e Priority.

Cabeçalhos opcionais

Cabeçalhos opcionais
Cabeçalho Tipo Descrição
Content-MD5 Sequência O hash de 128 bits do payload, codificado no formato “ base64 ” ( MD5 ), é utilizado como verificação de integridade para garantir que o payload não tenha sido alterado durante a transmissão.
x-amz-checksum-crc32 Sequência Esse cabeçalho é a soma de verificação Base64 codificada e de 32 bits CRC32 do objeto.
x-amz-checksum-crc32c Sequência Esse cabeçalho é a soma de verificação Base64 codificada e de 32 bits CRC32C do objeto.
x-amz-checksum-crc64nvme Sequência Esse cabeçalho é a soma de verificação Base64 codificada e de 64 bits CRC64NVME do objeto. A soma de verificação CRC64NVME é sempre uma soma de verificação completa do objeto.
x-amz-checksum-sha1 Sequência Esse cabeçalho é o Base64 codificado, 160 bits SHA1 digest do objeto.
x-amz-checksum-sha256 Sequência Esse cabeçalho é o Base64 codificado, 256 bits SHA256 digest do objeto.

Um cabeçalho Content-MD5 ou um cabeçalho checksum (incluindo x-amz-checksum-crc32, x-amz-checksum-crc32c, x-amz-checksum-crc64nvme, x-amz-checksum-sha1 ou x-amz-checksum-sha256) é necessário como uma verificação de integridade para a carga útil. O corpo da solicitação deve conter um bloco XML com o esquema a seguir:

Elemento Tipo Filhos Antecessor Restrição
ReplicationConfiguration Contêiner Rule Nenhum Limite 1.
Rule Contêiner ID, Status, Filter, DeleteMarkerReplication, Destination, Priority ReplicationConfiguration Limite 1000.
ID Sequência Nenhum Rule Deve ser composto por (a-z,A-Z0-9) e pelos seguintes símbolos: ! _ . * ' ( ) -
Destination Contêiner Bucket Rule Limite 1.
Bucket Sequência Nenhum Destination O CRN do depósito de destino
Priority Integer Nenhum Rule Uma prioridade é associada a cada regra. Pode haver casos em que várias regras podem ser aplicáveis a um objeto transferido por upload. Nessas situações, o armazenamento de objeto aplicará a regra aplicável com a prioridade mais alta ao replicar esse objeto Assim, apenas uma única regra de replicação pode ser aplicada a qualquer objeto, independentemente de quantas regras na política de replicação podem ser correspondentes para o objeto. Observe que quanto maior o número, maior a prioridade.
Status Sequência Nenhum Rule Especifica se a regra está ativada. Os valores válidos são Enabled ou Disabled.
DeleteMarkerReplication Contêiner Status Rule Limite 1.
Status Sequência Nenhum DeleteMarkerReplication Especifica se o Object Storage replica marcadores de exclusão. Os valores válidos são Enabled ou Disabled.
Filter Sequência Prefix, Tag, AND Rule Um filtro que identifica o subconjunto de objetos ao qual a regra de duplicação se aplica. Um Filter deve especificar exatamente um elemento filho Prefix, Tag ou And.
Prefix Sequência Nenhum Filter Um prefixo de nome de chave de objeto que identifica o subconjunto de objetos ao qual a regra se aplica...
Tag Sequência Nenhum Filter Um contêiner para especificar uma chave e valor de tag. A regra aplica-se apenas a objetos que possuem a tag em seu conjunto de tags
And Sequência Nenhum Filter Um contêiner para especificar filtros de regras. Os filtros determinam o subconjunto de objetos ao qual a regra se aplica.. Esse elemento será necessário apenas se você especificar mais de um filtro
Key Sequência Nenhum Tag A chave de tag
Value Sequência Nenhum Tag O valor da tag.

Este exemplo replicará quaisquer novos objetos, mas não replicará marcadores de exclusão.

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

Este exemplo replicará quaisquer objetos com uma chave (nome) que começam com project_a/ para o depósito identificado com $DESTINATION_CRN_A e quaisquer objetos com uma chave (nome) que começam com project_b/ para o depósito identificado com $DESTINATION_CRN_B e quaisquer objetos que tenham uma tag de objeto com a chave Client e o valor ACME para um terceiro depósito identificado com $DESTINATION_CRN_C e replicarão os marcadores de exclusão em todos os casos.

Suponha que os quatro objetos a seguir sejam incluídos no depósito de origem Eles serão replicados para depósitos de destino conforme descrito abaixo:

  1. project_a/foo.mp4
  2. project_a/bar.mp4
  3. project_b/baz.pdf
  4. project_b/acme.pdf. Este quarto objeto também tem uma tag de objeto com a chave Client e o valor ACME..

Devido às regras a seguir, os objetos 1 e 2 serão replicados para $DESTINATION_CRN_A. O objeto 3 será replicado para $DESTINATION_CRN_B O objeto 4 será replicado somente para $DESTINATION_CRN_C porque a regra com o ID AcmeCorp tem um valor de prioridade mais alto do que a regra com o ID ProjectB e, embora atenda aos requisitos para ambas as regras, estará sujeito apenas ao primeiro...

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

Uma solicitação bem-sucedida retorna uma resposta de 200

Visualizar configuração de replicação para um depósito

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

Isso retorna um corpo de resposta XML com o esquema apropriado:

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

Excluir a configuração de replicação de um bucket

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

Uma solicitação bem-sucedida retorna uma resposta de 204

Listar falhas de replicação de um bucket

Exemplo de solicitação usando curl

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

Parâmetros de consulta opcionais

Nome Tipo Descrição
tipo de codificação Sequência Se forem utilizados caracteres Unicode não suportados pelo XML em um nome de objeto, este parâmetro pode ser definido como “url” para codificar corretamente a resposta.
max-keys Sequência Limita o número de falhas a serem exibidas na resposta. O padrão e o máximo são 1.000.
primeira-tentativa-de-sincronização-anterior Sequência Especifica o carimbo de data e hora a partir do qual a lista deve começar, em ordem cronológica inversa. A hora corresponde ao momento em que a replicação foi acionada originalmente ( campo na entrada). Assim, a lista conterá todas as falhas de replicação cuja data seja pelo menos tão antiga quanto o carimbo de data e hora especificado.
token de continuação Sequência Especifica a falha a partir da qual a lista deve começar, em ordem cronológica inversa. Isso é usado para fins de paginação, caso haja mais entradas além das retornadas na última solicitação de listagem.

Exemplo de resposta

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

Elementos de resposta

Nome Tipo Descrição
ListReplicationFailureResult Contêiner Tag de nível raiz
Name Sequência Nome do bucket que está sendo listado.
FirstSyncAttemptedBefore Sequência ISO-8601 data e hora da solicitação ?first-sync-attempted-before
MaxKeys Número Número máximo de chaves solicitado neste anúncio.
IsTruncated Booleano Se a lista atual foi truncada (ou seja, há mais falhas após o último elemento retornado nesta lista). Se true, NextContinuationToken é sempre fornecido.
EncodingType Sequência Tipo de codificação solicitado nesta listagem.
KeyCount Número Número de elementos com falha exibidos nesta lista.
ContinuationToken Sequência O token de continuação que foi especificado para esta listagem.
NextContinuationToken Sequência Próximo token de continuação a ser usado para paginação, caso a lista atual tenha sido truncada.

Agendar uma nova tentativa para falhas de replicação antigas em um bucket

Isso agenda uma nova tentativa para todas as falhas de replicação, incluindo quaisquer falhas “antigas” com mais de 30 dias e que não sejam mais elegíveis para novas tentativas automáticas pelo sistema. Falhas de replicação de longo prazo são processadas em ciclos de 24 horas. Ao enviar essa solicitação, são agendadas novas tentativas para as falhas antigas no ciclo que começa à meia-noite GMT seguinte. Por exemplo, se uma solicitação for enviada às 2026-01-01T01:00:00Z, o horário mais cedo em que essas falhas serão processadas é às 2026-01-02T00:00:00Z. Caso a solicitação seja bem-sucedida, esse carimbo de data/hora também é fornecido no cabeçalho da resposta x-ibm-replication-reattempt-scheduled-time. Várias solicitações que chegam no mesmo dia no fuso horário GMT (ou seja, que resultam na mesma hora agendada) são idempotentes.

Cada falha por tempo de espera será tentada novamente uma vez, com base no princípio do “melhor esforço” — elas serão executadas, mas não há garantias quanto ao momento em que ocorrerão.

Exemplo de solicitação usando curl

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

Exemplo de resposta

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

Exemplos SDK

Os exemplos a seguir usam os SDKs do IBM COS para Python e Node.js, embora a implementação de versão do objeto deva ser totalmente compatível com qualquer biblioteca ou ferramenta S3-compatible que permita a configuração de terminais customizados. O uso de ferramentas de terceiros requer credenciais HMAC para calcular assinaturas do AWS V4. Para obter mais informações sobre credenciais HMAC, consulte a documentação.

Python

A ativação da versão usando o IBM COS SDK for Python pode ser feita usando a sintaxe do cliente de baixo nível.

Usando um cliente:

#!/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'
                }
            },
        ]
    }
)

Listando as versões de um objeto usando o mesmo cliente:

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

Observe que as APIs do Python são muito flexíveis e há muitas maneiras diferentes de realizar a mesma tarefa

Node.js

Ativando a versão usando o SDK do IBM COS SDK for Node.js:

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
});