すべてのアプリケーションとワークロードがオブジェクトロックと互換性があるわけではありません。もう1つの方法は、同じグリッド内（アクセスが制限された別のテナントを推奨）、またはStorageGRIDプラットフォームサービスCloudMirrorを使用する他のS3エンドポイントのいずれかのセカンダリバケットにオブジェクトをレプリケートする方法です。

StorageGRID CloudMirrorはStorageGRIDのコンポーネントです。定義されたデスティネーションにバケットのオブジェクトがソースバケットに取り込まれたときにレプリケートされ、削除はレプリケートされません。CloudMirrorはStorageGRIDに統合されたコンポーネントであるため、S3 APIベースの攻撃によって無効にしたり操作したりすることはできません。このレプリケートされたバケットは、バージョン管理を有効にして設定できます。このシナリオでは、レプリケートされたバケットの古いバージョンを破棄しても安全な自動クリーンアップが必要です。そのためには、StorageGRID ILMポリシーエンジンを使用できます。最新でない時間に基づいてオブジェクトの配置を管理するルールを作成し、攻撃を特定してリカバリします。

このアプローチの欠点は、バケットの完全な2つ目のコピーを作成し、オブジェクトの複数のバージョンをしばらくの間保持することで、より多くのストレージを消費することです。また、プライマリバケットから意図的に削除されたオブジェクトは、レプリケートされたバケットから手動で削除する必要があります。NetApp CloudSyncなど、製品以外にも、同様のソリューションで削除をレプリケートできるレプリケーションオプションがあります。セカンダリバケットのバージョン管理が有効でオブジェクトロックが有効でない場合のもう1つの欠点は、セカンダリの場所に損傷を与える可能性がある特権アカウントが多数存在することです。長所は、そのエンドポイントまたはテナントバケットに対して一意のアカウントである必要があり、プライマリロケーションのアカウントへのアクセスやプライマリロケーションのアカウントへのアクセスが侵害されない可能性があることです。

ソースバケットとデスティネーションバケットが作成され、デスティネーションでバージョン管理が設定されたら、次のようにレプリケーションを設定して有効にすることができます。