SnapMirror S3 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, 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
|
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.
-
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)
-
-
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).
-
-
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. For more information, see the following topics: