Skip to main content

SnapMirror S3 overview

Contributors netapp-lenida netapp-dbagwell netapp-ahibbard netapp-aherbin netapp-mwallis netapp-mdavidson johnlantz netapp-bhouser netapp-forry
PDFs

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

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

Yes

Yes

StorageGRID

No

Yes

AWS S3

No

Yes

Cloud Volumes ONTAP for Azure

Yes

Yes

Cloud Volumes ONTAP for AWS

Yes

Yes

Cloud Volumes ONTAP for Google Cloud

Yes

Yes

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

SnapMirror S3 requirements

  • ONTAP version

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

    Note SnapMirror S3 is not supported on MetroCluster configurations.

  • Licensing

    The following licenses are available in the ONTAP One software suite are required on ONTAP source and destination systems to provide access for:

    • ONTAP S3 protocol and storage

    • SnapMirror S3 to target other NetApp object store targets (ONTAP S3, StorageGRID, and Cloud Volumes ONTAP)

    • SnapMirror S3 to target third-party object stores, including AWS S3 (available in the ONTAP One Compatibility bundle)

    • If your cluster is running ONTAP 9.10.1, a FabricPool license is required.

  • 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), and the intercluster LIFs of the source and destination cluster can connect to the source and destination S3 server data LIFs.

    • 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 SnapMirror S3 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).

Note 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 SnapMirror S3 relationships; ONTAP does not assign them by default. The first time you create an SnapMirror S3 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

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

SnapMirror S3 does not support fan-in deployments (data protection relationships between multiple source buckets and a single destination bucket). SnapMirror S3 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.

Although SnapMirror S3 replicates objects from the source bucket to a destination bucket, it does not replicate group and bucket policies from the source object store to the destination object store.

Users, group policies, permissions, and similar components must be configured on the destination object store so that clients can access the destination bucket during a failover event.

For more information, see the following topics:

Use S3 Object Lock and versioning with SnapMirror S3

You can use SnapMirror S3 on Object Lock and versioning enabled ONTAP buckets, with a few considerations:

  • To replicate a source bucket with Object Lock enabled, the destination bucket must also have Object Lock enabled. In addition, both the source and destination must have versioning enabled. This avoids issues mirroring deletions to the destination bucket when both buckets have different default retention policies.

  • S3 SnapMirror will not replicate historical versions of objects. Only the current version of an object is replicated.

When Object Locked objects are mirrored to a destination bucket, they maintain their original retention time. If unlocked objects are replicated, they will adopt the default retention period of the destination bucket. For example:

  • Bucket A has a default retention period of 30 days and Bucket B has a default retention period of 60 days. Objects replicated from Bucket A to Bucket B will maintain their 30-day retention period, even though it is less than the default retention period of Bucket B.

  • Bucket A does not have a default retention period and Bucket B has a default retention period of 60 days. When unlocked objects are replicated from Bucket A to Bucket B, they will adopt the 60-day retention period. If an object is manually locked in Bucket A, it will maintain its original retention period when replicated to Bucket B.

  • Bucket A has a default retention period of 30 days and Bucket B does not have a default retention period. Objects replicated from Bucket A to Bucket B will maintain their 30-day retention period.