S3 SnapMirror overview

Contributors

Beginning with ONTAP 9.10.1, you can protect buckets in ONTAP S3 object stores using familiar SnapMirror mirroring and backup functionality. In addition, unlike standard SnapMirror, S3 SnapMirror can have non-NetApp destinations.

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

StorageGRID

checkmark

AWS S3

checkmark

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

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

S3 SnapMirror requirements

  • ONTAP version
    ONTAP 9.10.1 or later must be running 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 NetApp object store targets (ONTAP S3, StorageGRID, and Cloud Volumes ONTAP).

    • Data Protection Bundle and Hybrid Cloud Bundle
      For S3 SnapMirror to target 3rd party object stores (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).

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

S3 SnapMirror considerations and restrictions

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

The following standard SnapMirror functionality is not supported in the current S3 SnapMirror release:

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