ONTAP 9 Manuals ( CA08871-402 )

S3 SnapMirror overview

Beginning with ONTAP 9.10.1, you can protect buckets in ONTAP S3 object stores using SnapMirror mirroring and backup functionality. Unlike standard SnapMirror, S3 SnapMirror enables mirroring and backups to non-Fujitsu destinations like AWS S3.

S3 SnapMirror supports active mirrors and backup tiers from ONTAP S3 buckets to the following destinations:

Target Supports active mirrors and takeover? Supports backup and restore?

ONTAP S3

  • buckets in the same SVM

  • buckets in different SVMs on the same cluster

  • buckets in SVMs on different clusters

checkmark

checkmark

AWS S3

checkmark

Cloud Volumes ONTAP for Azure

checkmark

checkmark

Cloud Volumes ONTAP for AWS

checkmark

checkmark

Cloud Volumes ONTAP for Google Cloud

checkmark

checkmark

You can protect existing buckets on ONTAP S3 servers or you can create new buckets with data protection enabled immediately.

S3 SnapMirror requirements

  • ONTAP version
    ONTAP 9.10.1 or later must be running on source and destination clusters.

  • Licensing
    The following license bundles are required on ONTAP source and destination systems:

    • Core Bundle
      For ONTAP S3 protocol and storage.

    • Data Protection Bundle
      For S3 SnapMirror to target other Fujitsu object store targets (ONTAP S3, StorageGRID and Cloud Volumes ONTAP).

    • Data Protection Bundle and Hybrid Cloud Bundle
      For S3 SnapMirror to target third-party object stores, including AWS S3.

  • ONTAP S3

    • ONTAP S3 servers must be running source and destination SVMs.

    • It is recommended but not required that CA certificates for TLS access are installed on systems that host S3 servers.

      • The CA certificates used to sign the S3 servers' certificates must be installed on the admin storage VM of the clusters that host S3 servers.

      • You can use a self-signed CA certificate or a certificate signed by an external CA vendor.

      • If the source or destination storage VMs are not listening on HTTPS, it is not necessary to install CA certificates.

  • Peering (for ONTAP S3 targets)

    • Intercluster LIFs must be configured (for remote ONTAP targets).

    • Source and destination clusters are peered (for remote ONTAP targets).

    • Source and destination storage VMs are peered (for all ONTAP targets).

  • SnapMirror policy

    • An S3-specific SnapMirror policy is required for all S3 SnapMirror relationships, but you can use the same policy for multiple relationships.

    • You can create your own policy or accept the default Continuous policy, which includes the following values:

      • Throttle (upper limit on throughput/bandwidth) - unlimited.

      • Time for recovery point objective: 1 hour (3600 seconds).

You should be aware that when two S3 buckets are in a SnapMirror relationship, if there are lifecycle policies configured so that the current version of an object expires (is deleted), the same action is replicated to the partner bucket. This is true even if the partner bucket is read-only or passive.
  • Root user keys
    Storage VM root user access keys are required for S3 SnapMirror relationships; ONTAP does not assign them by default. The first time you create an S3 SnapMirror relationship, you must verify that the keys exist on both source and destination storage VMs and regenerate them if they do not. If you need to regenerate them, you must ensure that all clients and all SnapMirror object-store configurations using the access and secret key pair are updated with the new keys.

For information about S3 server configuration, see the following topics:

For information about cluster and storage VM peering, see the following topic:

Supported SnapMirror relationships

S3 SnapMirror supports fan-out and cascade relationships. For an overview, see Fan-out and cascade data protection deployments.

S3 SnapMirror does not support fan-in deployments (data protection relationships between multiple source buckets and a single destination bucket). S3 Snapmirror can support multiple bucket mirrors from multiple clusters to a single secondary cluster, but each source bucket must have its own destination bucket on the secondary cluster.

Control access to S3 buckets

When you create new buckets, you can control access by creating users and groups. For more information, see the following topics:

Top of Page